Method, system and apparatus for dynamically facilitating management of M:N working configuration systems

Abstract

A system for dynamically load-balancing at least one reallocated element across a set of computing resources is shown, which facilitates at least one aspect of an industrial execution process constructed in an M:N working configuration. The system includes: accessing configuration component operational data, capabilities, or characteristics associated with the M:N working configuration from a central or distributed data store; identifying a load-balancing opportunity to trigger reallocation of at least one reallocated element to a reallocation target selected from a pool of reallocation targets defined by remaining computing resource components associated with the M:N computing resource working configuration; selecting at least one reallocation target for redeployment; redeploying at least one reallocated element to the reallocation target; determining that the redeployment to at least one selected reallocation target is a feasible redeployment; and executing the industrial execution process using the at least one reallocated element at the selected reallocation target.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is a divisional application of an invention patent application with an application date of June 23, 2017, application number 201780051426.1, and invention name “Methods, systems and devices for dynamically promoting management of M:N working configuration systems”. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Figure 1A to Figure 1B is a block diagram illustrating aspects of a reliable system and an available system.

[0004] Fig.1C1 is a block diagram illustrating an example of a system implementing a 1:1 hardware failover / redundancy architecture.

[0005] Figure 1C2 is a block diagram illustrating an example of a borderless, high availability ("BCHA") system implementing an M:N working configuration architecture according to some embodiments of the disclosed technology.

[0006] Figure 2A Aspects of components associated with a borderless control high availability (BCHA) architecture are shown.

[0007] Figure 2B is a flow chart showing how the BCHA commissioning module develops aspects of the BCHA system.

[0008] Figure 3A Aspects of a BCHA architecture developed using instantiations of a BCHA delegation module and a BCHA data service module are shown.

[0009] Figure 3B Aspects of providing Boundaryless Control High Availability (BCHA) computing resources are shown.

[0010] Figure 3C Aspects of delegating a Boundaryless Control High Availability (BCHA) application are shown.

[0011] Figure 3D Various aspects of providing Boundaryless Control High Availability (BCHA) control application-high availability control are shown.

[0012] Figure 3E Aspects of providing a Boundaryless Control High Availability (BCHA) work item are shown.

[0013] Figure 3F is a block diagram illustrating example aspects of a hierarchical inheritance relationship for BCHA architecture attributes

[0014] Figure 4Showing aspects of how Boundaryless Control High Availability (BCHA) BCHA applications perform;

[0015] Figure 5A Shows how the BCHA system monitors operational status to facilitate aspects of resource failure detection load balancing and HA-M:N verification load balancing;

[0016] Figure 5B1 is a flow chart illustrating aspects of resource failure detection load-balancing;

[0017] Figure 5B2 is a flow chart illustrating aspects of resource failure detection load-balancing repair operation state determination;

[0018] Figure 5C is a flow chart illustrating aspects of HA-M:N verification load-balancing;

[0019] Fig. 6A is a system diagram showing aspects of a BCHA system M:N working configuration;

[0020] Fig.6B1 is an operational state data graph showing an operational state evaluation prior to a computing resource failure;

[0021] Figure 6B2 is an operating status data diagram showing fault detection - CR4 fault / fault detected;

[0022] Figure 6B3 is an operational status data diagram illustrating aspects of BCHA system reallocation element capability / characteristic determination;

[0023] Figure 6B4 is an operational status data diagram illustrating aspects of BCHA system reallocation pool capability / characteristic determination;

[0024] Figure 6B5 is an operational status data diagram illustrating aspects of reallocation target selection by a BCHA system;

[0025] Figure 6B6 is an operational status data diagram showing aspects of BCHA system redistribution repair

[0026] Figure 6B7 is an operational state data diagram showing aspects of a BCHA system performing target selection / non-critical application suspension;

[0027] Figure 6B8 is an operational status data diagram illustrating aspects of repairing operational status determination / verification of an M:N working configuration;

[0028] Fig. 7Ais a flow chart illustrating aspects of developing supplemental BCHA computing resources into an M:N+R working configuration;

[0029] Figure 7B is an operational status data diagram showing aspects of supplemental BCHA computing resources as an M:N+R working configuration;

[0030] Figure 7C is a system diagram showing aspects of supplementary BCHA computing resources as an M:N+R working configuration; Background Art

[0031] Existing systems utilize specialized 1:1 physical, redundant failover configurations to facilitate high availability features and functionality by using identical or nearly identical hardware. Such 1:1 physical, redundant failover configurations are both expensive and difficult to scale effectively and efficiently. Furthermore, existing systems using such 1:1 failover configurations often require extended operational time of several decades before replacement is completed. Thus, 1:1 physical, redundant failover configurations involve significant engineering challenges to support legacy hardware modules with obsolete components as various components experience end-of-life hardware failures and require physical replacement. This is further complicated because existing systems often require formal hardware / software system definitions that require engineering efforts to adjust as the factory scales to increase production. Summary of the invention

[0032] At least one aspect of the present disclosure relates to a system for dynamically load-balancing at least one reallocated element across a set of computing resources, which facilitates an industrial execution process and / or components of an industrial execution process constructed in an M:N working configuration, the system comprising: a system configured to access operational data, capabilities, or characteristics related to the M:N working configuration from a central data storage M:N working configuration component; identify load-balancing opportunities to trigger reallocation of at least one reallocated element to a reallocation target selected from a reallocation target pool defined by remaining M computing resource components associated with the M:N computing resource working configuration; select at least one reallocation target for redeploying the at least one reallocated element selected from the target reallocation pool; redeploy the at least one reallocated element to the at least one selected reallocation target; and determine that redeploying the at least one reallocated element to the at least one selected reallocation target is a feasible redeployment.

[0033] In some embodiments, the system may further include: facilitating redeployment when the load-balancing opportunity involves resource failure detection load balancing. In addition, the at least one reallocation element may be associated with a failed M:N working configuration component or computing resource.

[0034] In some embodiments of the system, the at least one reallocated element may be an application executed on the failed M:N working configuration component or computing resource. In addition, the at least one reallocated element may include an application and a corresponding work item executed on the failed M:N working configuration component / computing resource. In addition, the operating data, capabilities, or characteristics associated with the at least one reallocated element may be compared with the operating data, capabilities, and characteristics associated with the reallocation target pool component or computing resource. In addition, the at least one reallocated element may be associated with an active M:N working configuration component.

[0035] In some embodiments, the system may further include performing a repair operation status determination to determine a feasible redeployment that maintains the integrity of the M:N working configuration.

[0036] In some embodiments, the system may also include maintaining a high availability requirement for the M:N working configuration.

[0037] In some embodiments of the system, the M:N working configuration integrity may be maintained and at least one M:N working configuration component application or work item may be suspended to maintain the M:N working configuration integrity.

[0038] In some embodiments, the system may further include performing a repair operation status determination to determine that the feasible redeployment; and determining that the M:N working configuration integrity may be maintained but has not been maintained.

[0039] In some embodiments, the system may further include generating a supplemental M:N working configuration component request indicating minimum supplemental component requirements needed to transition back to a viable M:N working configuration.

[0040] In some embodiments, the system may further include facilitating redeployment when the load-balancing opportunity involves component failure simulation verification.

[0041] In some embodiments, the system may further include iteratively simulating a M:N working configuration component failure for each component in the M:N working configuration.

[0042] In some embodiments, the system may further include performing a Z-verification degree computing resource failure simulation, where Z is greater than or equal to 1; and verifying that the M:N working configuration is robust using a supplemental M:N working configuration resource.

[0043] In some embodiments, the system may further include generating a robust M:N working configuration repair supplemental M:N working configuration component and / or computing resource request to facilitate transitioning to the robust M:N working configuration.

[0044] In some embodiments, the system may further include activating a reallocated element upon or near a computing resource failure and corresponding application or work item operation data stored in the data service module.

[0045] According to one embodiment, a method for dynamically load-balancing at least one reallocated element across a set of computing resources is provided, which facilitates an industrial execution process and / or components of an industrial execution process constructed in an M:N working configuration, the method comprising: accessing operational data, capabilities, or characteristics related to the M:N working configuration from a central data storage M:N working configuration component; identifying a load-balancing opportunity to trigger reallocation of at least one reallocated element to a reallocation target selected from a reallocation target pool defined by remaining M computing resource components associated with the M:N computing resource working configuration; selecting at least one reallocation target for redeploying the at least one reallocated element selected from the target reallocation pool; redeploying the at least one reallocated element to the at least one selected reallocation target; and determining that redeployment of the at least one reallocated element to the at least one selected reallocation target is feasible.

[0046] In some embodiments, the method may further include facilitating redeployment when the load-balancing opportunity involves resource failure detection load balancing. In addition, the at least one reallocation element may be associated with a failed M:N working configuration component or computing resource.

[0047] In some embodiments of the method, the at least one reallocated element may be an application executed on the failed M:N working configuration component or computing resource. In addition, the at least one reallocated element may include an application and a corresponding work item executed on the failed M:N working configuration component / computing resource. In addition, the operating data, capabilities, or characteristics associated with the at least one reallocated element may be compared with the operating data, capabilities, and characteristics associated with the reallocation target pool component or computing resource. In addition, at least one reallocated element is associated with an active M:N working configuration component.

[0048] In some embodiments, the method may further include performing a repair operation status determination to determine a feasible redeployment that maintains the integrity of the M:N working configuration.

[0049] In some embodiments, the method may further include maintaining a M:N working configuration high availability requirement.

[0050] In some embodiments of the method, the M:N working configuration integrity may be maintained and at least one M:N working configuration component application or work item may be suspended to maintain the M:N working configuration integrity.

[0051] In some embodiments, the method may further include performing a repair operation status determination to determine that the redeployment is feasible; and determining that the M:N working configuration integrity is maintainable but has not been maintained.

[0052] In some embodiments, the method may further include generating a supplemental M:N working configuration component request indicating minimum supplemental component requirements needed to transition back to a viable M:N working configuration.

[0053] In some embodiments, the method may further include facilitating redeployment when the load-balancing opportunity involves component failure simulation verification.

[0054] In some embodiments, the method may further include iteratively simulating an M:N working configuration component failure for each component in the M:N working configuration.

[0055] In some embodiments, the method may further include performing a Z-verification computing resource failure simulation, where Z is greater than or equal to 1; and verifying that the M:N working configuration is robust using a supplemental M:N working configuration resource.

[0056] In some embodiments, the method may further include generating a robust M:N working configuration repair supplemental M:N working configuration component and / or computing resource request to facilitate transitioning to the robust M:N working configuration.

[0057] In some embodiments, the method may further include activating the reallocated elements and corresponding application or work item operation data stored in the data service module upon or near a computing resource failure.

[0058] According to one aspect, a non-transitory computer-readable medium storing a sequence of computer-executable instructions for dynamically load-balancing at least one reallocated element across a set of computing resources, which facilitates at least one aspect of an industrial execution process and / or components of an industrial execution process constructed in an M:N working configuration, the sequence of computer-executable instructions including instructions that instruct at least one processor to perform the following operations: access operational data, capabilities, or characteristics associated with the M:N working configuration from a central data storage M:N working configuration component; identify load-balancing opportunities to trigger reallocation of at least one reallocated element to a reallocation target selected from a reallocation target pool defined by remaining M computing resource components associated with the M:N computing resource working configuration; select at least one reallocation target for redeploying the at least one reallocated element selected from the target reallocation pool; redeploy the at least one reallocated element to the at least one selected reallocation target; and determine that redeploying the at least one reallocated element to the at least one selected reallocation target is a feasible redeployment.

[0059] According to one aspect, a system for dynamically load-balancing at least one reallocated element across a set of computing resources is provided, which facilitates at least one aspect of an industrial execution process constructed in an M:N working configuration, including: the system is configured to: access operational data, capabilities, or characteristics associated with the M:N working configuration from a data store M:N working configuration component, wherein the data store is a central data store or a distributed data store that is independent of local storage at the corresponding computing resource and accessible by the corresponding computing resource; identify load-balancing opportunities to trigger reallocation of at least one reallocated element to a reallocation target selected from a reallocation target pool defined by the remaining M computing resource components associated with the M:N computing resource working configuration; select at least one reallocated element for redeploying the at least one reallocation target selected from the reallocation target pool; redeploy the at least one reallocated element to the at least one selected reallocation target; determine that redeploying the at least one reallocated element to the at least one selected reallocation target is a feasible redeployment; and execute the industrial execution process using the at least one reallocated element at the selected reallocation target.

[0060] According to one aspect, a method for dynamically load-balancing at least one reallocated element across a set of computing resources is provided, which facilitates at least one aspect of an industrial execution process constructed in an M:N working configuration, including: accessing operational data, capabilities, or characteristics associated with the M:N working configuration from a data store M:N working configuration component, wherein the data store is a central data store or a distributed data store that is independent of local storage at the corresponding computing resource and accessible by the corresponding computing resource; identifying a load-balancing opportunity to trigger reallocation of at least one reallocated element to a reallocation target selected from a reallocation target pool defined by the remaining M computing resource components associated with the M:N computing resource working configuration; selecting at least one reallocated element for redeploying at least one reallocation target selected from the reallocation target pool; redeploying the at least one reallocated element to the at least one selected reallocation target; determining that redeploying the at least one reallocated element to the at least one selected reallocation target is a feasible redeployment; and executing the industrial execution process using the at least one reallocated element at the selected reallocation target.

[0061] According to one aspect, a non-transitory computer-readable medium is provided that stores a sequence of computer-executable instructions for dynamically load-balancing at least one reallocated element across a set of computing resources that facilitate at least one aspect of an industrial execution process constructed in an M:N working configuration, the sequence of computer-executable instructions comprising instructions that instruct at least one processor to perform the following operations: access operational data, capabilities, or characteristics associated with the M:N working configuration from a data store M:N working configuration component, wherein the data store is a central data store or a distributed data store that is independent of local storage at the corresponding computing resource and accessible by the corresponding computing resource; identify a load-balancing opportunity to trigger reallocation of at least one reallocated element to a reallocation target selected from a reallocation target pool defined by remaining M computing resource components associated with the M:N computing resource working configuration; select at least one reallocated element for redeploying the at least one reallocated target selected from the reallocation target pool; redeploy the at least one reallocated element to the at least one selected reallocation target; determine that redeploying the at least one reallocated element to the at least one selected reallocation target is a feasible redeployment; and execute the industrial execution process using the at least one reallocated element at the selected reallocation target. DETAILED DESCRIPTION

[0062] The present disclosure describes features and functionality that facilitate a BCHA system that manages BCHA computing resources to achieve a specified availability of a BCHA system (e.g., an industrial control system) so that the BCHA system can deliver and maintain the required availability and / or functionality with a specified quality and lower cost without providing 1:1 physical failover redundancy for each computing resource / machine. The disclosed technology utilizes multiple BCHA computing resource pools to facilitate dynamically achieving and maintaining the necessary high availability requirements of a specific BCHA system. In some embodiments, the disclosed technology monitors and reports key performance indicators (KPIs), such as BCHA system and / or BCHA computing resource availability, and generates operating system metrics / recommendations for system operators to achieve real-time reliability and availability goals established for a specific BCHA system. The described BCHA system can also simulate how certain actions (e.g., adding or removing one or more computing resources) will act and affect such availability and reliability metrics, and dynamically load-balance accordingly to facilitate achieving reliability and availability goals for the BCHA system / or specific BCHA system components.

[0063] Figure 1A to Figure 1B is a block diagram illustrating aspects of the relationship between reliable systems and available systems, which are two key issues addressed by a Boundless Computing High Availability ("BCHA") system - more specifically, a BCHA system that analyzes the BCHA system, BCHA component computing resources, BCHA component applications, and required BCHA component work item availability in order to allocate the BCHA system reallocates elements, including BCHA applications and BCHA work items ("WI"), in order to dynamically manage and maximize system availability.

[0064] Figure 1A A generalized Markov graph for a fault that has not been repaired is shown on the left side of the figure. Figure 1A The right side of shows a general Markov graph of the faults that can be repaired, and thus shows the aspect of "availability". Figure 1A and Figure 1B In the example shown, availability ("A") is the probability that a system / system application will function properly when it is needed for use. In other words, availability is the probability that a system is working (i.e., not failing) or is undergoing a repair action and is therefore unavailable. Reliability takes into account the time it takes for a component, part, or system to fail while in operation. It does not reflect how long it takes to restore the unit to a working state, be repaired, or need to be replaced. For example, a light bulb is a reliable element - eventually it will fail. However, once it fails, it cannot be repaired and is discarded. A building's lighting system is an available system. When a light bulb fails, it can be replaced with another light bulb, but replacing a system component involves resource coordination and possible system component downtime.

[0065] If the system can be divided and managed across multiple computing resources, the reliability of the system can be increased relative to a single computing resource system. Determine the improved reliability / availability. In the example where sixteen machine nodes are grouped and managed into four discrete systems, the following calculations are involved: The example system has five times more availability, which means that if full capacity is to be maintained and the single system has a mean time between failures (MTBF) of ten years, the split system has an MTBF of fifty years. If the system is split into k parts, the chance of losing more than 1 / k of capacity is many times smaller than the change if a single system implemented on a single computing resource loses all of its capacity. Depending on the scope / scale of the system, distributed availability can be measured in centuries.

[0066] In a BCHA system, which may include BCHA computing resources, including software and hardware elements (e.g., applications, components, modules, machines, logical hardware elements, software frameworks, communication frameworks, etc.) that control processing or processing segments, availability ensures that important control algorithms, applications, and work items continue to run without interruption. Therefore, system availability is based on the availability of computing of machines, computing resources, control applications, redundant schemes of applications, etc., and the ability to maintain a high-availability operating state (which ensures system availability by managing and coordinating BCHA computing resources, BCHA applications, and BCHA work items).

[0067] like Fig.1C1 As shown in , existing implementations achieve high availability of industrial control systems ("ICS") by building systems with duplicate, physically redundant backup / failover hardware. These one-to-one (1:1) redundant hardware dedicated computing resource pairs high availability solutions may be cost-prohibitive, depending on the scope and scale of the system. Such systems use multiple one-to-one (1:1) redundant hardware dedicated computing resource pairs, where the control application deployed on the primary machine can fail over to the secondary or backup computing resource / machine when the primary computing resource / machine fails. This 1 to 1 redundant hardware dedicated computing resource pair setting provides high availability, but has the disadvantage of requiring two dedicated computing resources / machines for each control application, resulting in doubling the machine cost and poor scalability. In addition, the prior art uses the mean time between failures and mean time to repair (MTBF and MTTR) function sets to determine the reliability metrics of traditional hardware component failure calculations. These calculations are performed during design and manufacturing and are primarily static and can only be updated when hardware elements (and their redundant failover hardware) are introduced into the system and / or when system components change.

[0068] These and various other shortcomings of the 1:1 architecture and the MTBF and MTTR reliability metrics are overcome by the features and functionality of the Unbounded Computing High Availability ("BCHA") system described herein. Figure 1C2 The M:N working configuration redundant system shown in , utilizing BCHA computing resources, BCHA applications, and BCHA work items, can achieve additional benefits. For example, for a BCHA system:

[0069] (a) Availability can be specified as needed for a specific application and based on associated control requirements, rather than simply adhering to a 1:1 redundant control requirement;

[0070] (b) Application engineers do not have to worry about assigning control loops to specific hardware - thus reducing engineering time and simplifying engineering work;

[0071] (c) Eliminating the 1:1 hardware requirement opens up the possibility of supporting availability requirements by using virtualized BCHA computing resources provided on IT servers; and

[0072] (d) In some cases, IO can be located far away from BCHA computing resources.

[0073] As used herein, Boundaryless Control (BC or BC) is the use of boundaryless computing to control an industrial process, plant, or operation. More specifically, Boundaryless Control involves a flexible set of architectural principles, techniques, methods, and tools that facilitate scalable and extensible systems by leveraging evolving IT technologies and abstracting high-level functions to enable optimization of automation solutions throughout their lifecycle without being constrained by the constraints of underlying operating hardware or software components, platforms, or applications. Boundaryless control systems facilitate and enable this flexibility by leveraging a software-defined application layer, a flexible and reliable communications backbone, smart connected assets, and hardware platforms designed to work in tandem with hardware resources leveraging current technology in a scalable and updateable manner as technology continues to evolve.

[0074] Advantageously, a BCHA machine or BCHA computing resource can be a physical machine or a virtual machine with an operating system capable of hosting one or more BCHA applications. As used herein, a virtual machine (VM) includes a BCHA computing resource that emulates a specific (or part of) computer system. VMs operate based on computer architecture and the functionality of real or hypothetical computers, and their implementation may involve dedicated hardware, software, or a combination of both. According to some embodiments, a BCHA computing resource has a BC software resource that has three components / aspects that facilitate the BCHA system / component operating infrastructure features / functions: (1) BCHA machine configuration aspects, (2) BCHA physical computing resources / machine aspects, and (3) system management aspects. As used herein, a BCHA computing resource is a resource capable of running one or more BC applications. In some embodiments, a BCHA application may have four aspects. These include (1) role aspects, (2) instance (runtime) aspects, (3) visualization aspects, and (4) system management aspects.

[0075] A BCHA application or BCHA control application has executable code that performs one or more functions within a BCHA computing resource. In some embodiments, a BCHA application (runtime) instance is provided as a separate executable program independent of other BCHA applications. In various embodiments, a BCHA application can facilitate processing control features and functionality, such as control algorithms, processing optimization, cyber-physical computing, etc. In some implementations, a BCHA application can be configured to execute a BCHA work item.

[0076] For BCHA work items, the basic concept is that software and firmware applications perform work, such as compute or control elements. This work can be the execution of control algorithms, scanning of IO, multivariable calculations, network physical calculations, etc. BCHA applications are deployed as software / firmware to BCHA computing resources, which in turn are computing elements defined as BCHA computing resources / machines (which bind infrastructure elements to computing elements). The computing engines that form BCHA computing resources / machines can be physical computers, virtual machines, or containers.

[0077] BCHA applications can use BCHA data services to exchange information with other BCHA applications, applications, legacy services, IA runtimes, etc. In some embodiments, groups outside the development organization can create BC applications, thereby enabling full third-party extensibility of BC applications or a range of applications (and / or some combination thereof) executed in the cloud / fog / edge / mist. BCHA applications can be provider endpoints (EPs) and / or consumer EPs.

[0078] In an example BCHA system implementation involving an industrial control system (ICS), some BCHA control applications dedicated to process control are used to control critical processes, such as operating safely within thresholds set by safety systems (e.g., to avoid being shut down by the safety system) and producing products that meet specific specifications at the lowest possible cost. Some BCHA applications can also be used to optimize processes (and / or aspects of processes) and / or ensure compliance with BCHA system regulatory controls associated with ICS process operations. For example, some control applications help run processes more economically, e.g., using less energy, reducing peak power usage, reducing the use of expensive raw materials while maintaining quality, reducing the footprint of the solution, etc.

[0079] The BCHA system and architecture described herein manage BCHA computing resources in a manner that load balances BCHA applications while managing and coordinating BCHA system components to achieve system availability metrics. BCHA system availability requirements can be established to maintain BCHA application features / functionality. In some implementations, BCHA system availability can be established using additional thresholds for initiating reoperation based on the risk tolerance of the system operator, characteristics / operational constraints associated with specific processes and / or applications, and / or various other operational metrics. In some implementations, the BCHA system includes operational characteristic / constraint optimization features and functionality to achieve the desired availability, as well as functionality to balance one or more operational constraints (e.g., at a specified manufacturing quality, acceptable safety metrics, and / or lowest possible cost).

[0080] In an M:N working configuration operational implementation, one-to-one redundancy requirements for each machine are avoided, resulting in further system / operational cost efficiencies. In an M:N operational implementation, the BCHA control module manages and coordinates BCHA applications 268 across current BCHA computing resources to achieve and dynamically maintain the necessary high availability operational state utilizing only existing BCHA system components. In an M:N+R operational implementation, the BCHA control module manages and coordinates BCHA applications across current BCHA computing resources, but requests additional resources "R" in addition to the existing BCHA computing resources provided to achieve the necessary high availability operational state. Advantageously, in an M:N+R working configuration, hardware requirements for 1:1 physical redundancy can still be avoided - the BCHA control module can calculate / determine the appropriate number of "R" supplementary / additional requested BCHA computing resources to supply existing BCHA computing resources to achieve and maintain established availability requirements, and transition to a feasible M:N working configuration after configuring additional BCHA computing resources. The BCHA control module can determine, coordinate and manage BCHA computing resources based on BCHA system attributes to achieve real-time machine / overall system availability - including BCHA system component capabilities and characteristics of BCHA computing resources, BCHA applications, BCHA work items and allocation / management of BCHA system components. As used herein, BCHA capabilities or characteristics are BCHA attributes that define the operating parameters or constraints of BCHA computing resources, BCHA applications and / or BCHA work items. Examples include, but are not limited to: CPU impact, hosting requirements, memory requirements, data service requirements, CPU type requirements and co-location with other BC applications, application process criticality, etc.

[0081] In some embodiments, the BCHA system achieves high availability through a BCHA control application to deploy, coordinate and manage BCHA applications / BCHA work items across computing resources in an M to N working configuration. As long as the BCHA attributes - BCHA system component capabilities / features make it a suitable host, the BCHA computing resource can host any configuration of the BCHA application provided. A single BCHA computing resource does not necessarily need to be fully redundant in nature, but more than one BCHA computing resource may be required to achieve high availability.

[0082] The following sequence of figures discuss various examples of additional BCHA system features / functionality that compound the high availability efficiencies achieved through BCHA applications. For example, a BCHA system can have (1) an increased reliability metric, (2) provide reliable BCHA system components / computing resources, (3) reduce / minimize BCHA system downtime, (4) reduce the time to detect BCHA computing resource / BCHA application failures, (5) reduce the time to read / write data from / to BCHA data services, 6) reduce the time to redeploy BCHA applications, (8) provide backup BCHA computing resources without the need for 1:1 physical, redundant failover requirements, (9) dynamically allocate BCHA applications across BCHA computing resources, creating an optimal physical / virtual / BCHA computing resource balanced usage, (10) switch BCHA applications to backup BCHA computing resources or an appropriate M:N+R working configuration when a BCHA computing resource fails in an M:N working configuration, (11) minimize the time it takes for BCHA to redeploy elements (e.g., BCHA applications and / or BCHA work items) and to redeploy and proceed to backup BCHA computing resources, as well as other BCHA benefits, solutions, features, and functionality described in more detail with respect to the accompanying drawings.

[0083] In some embodiments, the BCHA system high availability requirement can be implemented by a BCHA reliability engine module, which uses constraints (e.g., resource constraints, application constraints, processing constraints alone or in coordination with BCHA system component capabilities, characteristics and / or operational data) to calculate the availability of the BCHA system. In some embodiments, the BCHA reliability engine module can be implemented as a component integrated with the BCHA control module and make availability improvement suggestions or take actions such as the following:

[0084] (i) taking into account potential actions of safety systems, using available (e.g., recovered) computing resources / capacity to move and restart critical applications; and / or

[0085] (ii) When resources are limited, shut down the least important or non-critical applications.

[0086] The BCHA system facilitates optimization and load balancing based on availability selection by providing real-time feedback on overall BCHA system availability and / or many other BCHA system balancing optimization characteristics (e.g., computing resource application load levels). The optimal availability M:N working configuration may not involve active redundancy of certain BCHA applications (e.g., non-critical control applications may be disabled or deactivated in the event of a machine or resource failure and / or susceptible to restart on other BCHA computing resources). In other examples, optimal availability may involve even more availability by running active redundant BCHA computing resources / BCHA applications (e.g., N to N redundancy, where each online BCHA computing resource may potentially be used for failover; M:N redundancy, if one BCHA computing resource fails, the BCHA applications / BCHA work items executed on the BCHA computing resource are reallocated to the remaining MBCHA computing resources associated with the M:N working configuration). The required or specified availability of the BCHA system enables processing to deliver products at a specified quality and at a lower cost without the need to provide 1:1 physically redundant hardware for each computing resource.

[0087] Another advantage of the disclosed technology is that the system is self-healing. In a control system with M:N redundancy and / or if the BCHA control module requests additional BCHA computing resources (e.g., M:N+R working configuration), redeployment targets are selected (and / or configured and available for the M:N+R working configuration) that can be used to promote increased availability metrics and reduce production costs.

[0088] According to the disclosed technology, high availability (e.g., in the event of a failure of a BCHA computing resource) can be achieved by:

[0089] (i) dynamically manage M:N working configurations to facilitate redundant system architectures; and / or

[0090] (ii) BCHA control application activities monitor system health / dynamically manage BCHA system components as BCHA computing resources, BCHA applications and / or BCHA work items to facilitate industrial execution processes or industrial system control components associated with industrial execution processes.

[0091] In some implementations, the BCHA control module may temporarily or indefinitely suspend BCHA applications with lower priority / criticality and use available BCHA computing resources to run higher priority / critical BCHA applications. As used herein, BCHA application priority / criticality is an indication of how important a particular BCHA application is to an industrial execution process. In some implementations, a high BCHA application priority / criticality indicates that failure of a BCHA application may cause the safety system to bring the process to a safe state more quickly than a low BCHA application priority. This is a useful measure for determining which types of BCHA computing resources can be requested and provided quickly and efficiently to facilitate BCHA system repair time that occurs before the safety system shuts down the industrial execution process.

[0092] Figure 1C2 Aspects of the BCHA system architecture are introduced, as well as aspects of core BCHA system features and functionality - both of which are discussed in more detail in the subsequent figures and corresponding text in the specification.

[0093] In some embodiments, the high availability controller works in conjunction with the reliability engine to provide real-time metrics for the entire BCHA system to provide an indication of the reliability and availability metrics of the control system. For example, certain metrics may indicate that some standby machines may provide higher availability than a dedicated one-to-one redundancy approach could provide.

[0094] Fig.1C1 1 is a block diagram illustrating an example of a system that implements a 1:1 physical hardware failover / redundancy architecture. More specifically, each of computing resources 105A1-105E1 has a dedicated 1:1 physical redundant computing resource that is operably connected in parallel to 105A2-105E2. In this type of example, each computing resource has a dedicated redundant computing resource that can be inactive until a failure is detected. Alternatively, in some time-sensitive implementations, computing resources 105E1 and 105E2 can run the same application at the same time, with only one active participating system. Therefore, if computing resource 105E1 fails, computing resource 105E2 steps into the active role while minimizing any data and time switching losses. However, as described above, this type of system has significant disadvantages.

[0095] Figure 1C2is a block diagram illustrating an example of a BCHA system 100 that implements an M:N work configuration architecture according to some embodiments of the disclosed technology. A BCHA application ("BCHA App X") can be distributed across multiple computing resources 105A3-105E3. One or more BCHA applications (BCHA App) can be provided to a BCHA computing resource. For example, BCHA computing resource 105B can execute BCHA App A and BCHA App D. The BCHA system 100 also includes a BCHA control module 115 having a BCHA reliability engine module 120. Additional improvements in efficiency and system efficacy are also achieved by implementing a BCHA data service module 130. Depending on the specific implementation, the data storage service can be distributed or centralized. For the purposes of this discussion, the BCHA data service is shown as a central data store, and each computing resource connects and provides BCHA computing resources, BCHA applications, and BCHA work item configuration data, status data, output data, and other related BCHA system operation data parameters. As used herein, provisioning is the ability to install and activate computing resources on a hardware starting instance, as well as the ability to launch BCHA applications and / or BCHA work items on specific BCHA computing resources.

[0096] In some embodiments, the BCHA control module 115 and the BCHA reliability engine module 120 monitor system health and operational data, such as BCHA computing resource availability and loading of each BCHA application instance executing on each respective computing resource 105A-105E across the M:N working configuration. Figure 1C2 In the example, the BCHA control module 115 can detect whether the BCHA computing resource 105E3 fails and work to reallocate BCHA App E to an appropriate backup BCHA computing resource within the M:N working configuration. As shown, BCHA App 3 is redeployed to BCHA computing resource 105A3. In addition, in some implementations, the BCHA control module 115 can also temporarily suspend BCHA App A or redeploy BCHA App A to a different, appropriate BCHA computing resource to facilitate redeployment. As shown, the BCHA control module transfers BCHA App A to BCHA computing resource 105B3 to facilitate the redeployment of BCHA App E to BCHA computing resource 105A3. Aspects of BCHA system load balancing will be referred to. Figures 5A-7C Discuss in more detail.

[0097] In some embodiments, the BCHA system coordinates BCHA computing resource activities to achieve availability at least as high as the high availability requirements defined for whichever BCHA application is the highest priority / most critical BCHA application. The BCHA reliability engine module 120 utilizes BCHA application attributes that identify the availability capabilities / characteristics of the BCHA applications / BCHA computing resources ("BCHA system attributes") to manage and monitor the availability of the system. In some embodiments, the BCHA reliability engine module 120 may utilize BCHA computing resource attributes when managing BCHA system availability requirements and ultimately identify which computing resources are suitable as reallocation targets for redeploying a given BCHA application.

[0098] Managing BCHA system availability may include, for example, using BCHA application attributes to determine the BCHA system's requirements for BCHA computing resources, which may then be used to facilitate coordination and management of provisioning rules, active BCHA application management, BCHA computing resource load-balancing, and the like. As used herein, BCHA application attributes are accessible parameters of BCHA computing resources, BCHA applications, and / or BCHC work items. Depending on the BCHA application, application, or work item, the attributes typically have an identification, data type, security, classification (runtime and / or input and / or configuration), and the like. Some BCHA attributes provide users with the possibility of configuring BCHA applications. Runtime attributes may have quality indications and / or time indications. The values ​​of some attributes may be dynamically changed based on another BCHA attribute (i.e., input parameters) in the system. BCHA attributes are data parameters stored in the BCHA data service module 130, and will be discussed in more detail below as features, capabilities, and / or operational constraints.

[0099] In some embodiments, the BCHA reliability engine module 120 may be implemented on a controller (not shown). In other embodiments, the BCHA reliability engine module 120 may be deployed in coordination or integration with the BCHA control module 115, or executed independently on one or more of the BCHA computing resources (e.g., resources 105A-E). The BCHA control application BCHA delegation module 110, BCHA control module 115, and BCHA reliability engine module 120 as described above may facilitate control application provisioning, load balancing, caching of data (e.g., control application data), monitoring status, operation, performance, and the like. In some embodiments, the BCHA computing resources / BCHA applications interface with the control application via an application programming interface (API).

[0100] The BCHA data service module 130 may use a variety of technologies. For example, faster technologies that provide high speed and low latency may be used for runtime and external IO data access, and slower technologies may be used for configuration data access. In some embodiments, some data may be cached more locally to the BCHA application instance, such as on a BC resource, to improve performance. The BCHA data service module 110 ensures that data can be written in a timely manner and that the data is available to the BCHA computing resources, BCHA applications, and BCHA work items in a timely manner. In some embodiments, the data service read / write access capability is at least as fast as required by the accelerated BCHA application.

[0101] According to the disclosed technology, the BCHA control module 115 can actively manage and redeploy BCHA applications / BCHA work items from one BCHA computing resource to another BCHA computing resource. For example, in system 100, the BCHA control module can move BCHA App A from BCHA computing resource 105A3 to resource 105B3 (e.g., due to resource 105A being shut down or creating availability for redeployment). The decision to move to resource 105B can be based on operational characteristics and / or system metrics (e.g., cached and / or accessed from the BCHA data service module 130). For example, BCHA App A can be a critical application, and resource 105B can have computing resources available to execute BCHA App A. BCHA App A moved from one resource to another can be recovered within the time constant of the processing portion or segment controlled by the control application (BCHA App A in this example).

[0102] In some embodiments of the disclosed technology, some BCHA applications may be critical, while other BCHA applications may be non-critical. In some cases, non-critical BCHA applications may be given a lower priority for failover. For example, in the BCHA system 100, BCHA App E may be a non-critical control application, and in order to maintain the availability of the entire system, if there is no processing availability, BCHA App E may be suspended and not restarted on another resource. For example, when BCHA processing availability does exist, on the BCHA computing resource 105A, a non-critical BCHA application App E may be provided thereon, and by accessing the last feasible date status from the BCHA data service module 130, it may be restarted and / or picked up during processing.

[0103] Thus, the described BCHA systems, features and functions facilitate significant gains in the capabilities of BCHA systems to:

[0104] - Implement, monitor and maintain high availability system requirements for many networked connected devices;

[0105] - Significantly reduce hardware and resource requirements and expenses by implementing an M:N failover architecture rather than a 1:1 physically redundant, failover architecture; and

[0106] -Enables improved system architecture management through M:N+R working configurations, ultimately facilitating more robust M:N working configurations through supplemental resource delegation / deployment.

[0107] Therefore, to illustrate various aspects of each of these core BCHA system benefits / optimizations, as well as the related system benefits and efficiencies achieved by implementing the BCHA system architecture, the following description will discuss the following aspects:

[0108] (1) How to develop / delegate a BCHA system;

[0109] (2) The characteristics and functions of the BCHA system and the associated logic flows related to the various operational characteristics and functions of HA-M:N verification load-balancing, as well as fault detection / repair;

[0110] (3) A working example of BCHA load-balancing failure detection / remediation; and

[0111] (4) BCHA system HA-M:N verification load-balancing supplements computing resource delegation / allocation.

[0112] Figure 2A Aspects of components associated with a Boundaryless Control High Availability (BCHA) architecture and components of a BCHA system 200 are shown. The BCHA system delegation module 210 is a BCHA system module that is responsible for receiving and executing the BCHA system development delegation plan during initial BCHA system development. After system delegation, operational management transitions to the BCHA control module 215 to coordinate work item management and BCHA system load balancing (resource fault detection load-balancing, and active load balancing / M:N work configuration verification). In some implementations, the BCHA system delegation module 210 / BCHA control module 215 may also have the role of supplying computing resources, applications and / or work items after the initial BCHA system development because supplemental / additional BCHA computing resources 240 / 250 are provided for the BCHA system 200. Depending on the specific implementation details, the BCHA delegation module 210 may be instantiated on its own BCHA computing resources, merged with the BCHA control module 215, or in some implementations, delegate features / functions or integrate with the BCHA control module 215 and / or execute remotely as a cloud service.

[0113] After the BCHA system delegation module 210 verifies the initial configuration and delegation of the BCHA system 200, the BCHA control module 215 drives the operational runtime management work to achieve the availability requirements / metrics defined in the BCHA system development delegation plan. One or more BCHA computing resources 240 / 250 can be provided by the BCHA system delegation module 210 to effectively host the BCHA applications 268 executed by the BCHA system 200, as well as the BCHA work items 270 executed on the respective BCHA applications. The BCHA system delegation module 210 is configured to implement most of the delegation functions associated with the BCHA system 200, but works with two BCHA control applications 205 with dedicated utilities: (1) BCHA application configurator 211 - used to develop BCHA work items; (2) BCHA control application configurator 212, used to develop BCHA control applications 205, such as the BCHA control module 215, the BCHA reliability engine module 220 and the BCHA WI pool manager module 221. Finally, BCHA computing resources 240 / 250, BCHA applications 268, and corresponding BCHA work items 270 are delegated and managed to facilitate industrial execution processes. Given the flexibility of the BCHA system 200, the industrial execution process can be an entire workflow, an industrial control process, or an element / component workflow within an industrial control process - for example, coordinating a production line or elements of a production line, such as a conveyor component.

[0114] Configuration, operation and BCHA system management data for the BCHA system 200 are stored in the BCHA data service module 230. The BCHA control module 215 manages (or works with the BCHA WI pool manager module 221 to manage) work item allocation. In the event of a BCHA computing resource 240 / 250 failure - a BCHA application / BCHA work item failure, then centrally storing the BCHA computing resources, BCHA applications, BCHA work item configuration data, and operation / output data (or distributed but independent of local storage on the corresponding computing resources) results in significant system flexibility and promotes one of the key advantages of the M:N architecture - if one computing resource fails, the high availability controller can quickly and efficiently reallocate / redeploy applications and work items from one computing resource to another.

[0115] like Figure 2AAs shown, the BCHA data service module 230 is configured as a centralized data store / database that stores and makes accessible various delegated system / computing resource / application characteristics and capabilities. The data stored in the BCHA data service module 230 is used by the BCHA control module 215 (which works in conjunction with the BCHA reliability engine module 220 to actively / passively monitor system health, system operating characteristics) and works to implement the BCHA system availability metrics / requirements for the system 200 and the BCHA work item ("WI") pool manager 221.

[0116] Depending on the nature of the available resources, the BCHA computing resources 240 / 250 associated with a particular BCHA system may be a heterogeneous mix of various physical BCHA computing resources 240 or virtual BCHA computing resources 250 provided based on different spectrums of heterogeneous computing resource hardware starting points. Physical and virtual computing resources may be configured and built on any number of bare metal platforms. For example, Figure 2A , the physical BCHA computing resources 240 are shown as being provisioned based on BCHA HW resources 243, which can be something as simple as a Raspberry Pi, alternatively, the physical computing resources 241 can be developed from pre-built PC-server hardware resources 246. Similarly, the virtual BCHA computing resources 250 can be developed using virtual machines hosted at a computing resource starting point using pre-built PC server hardware (HW) resources 253, pre-built cloud computing resources 256, and / or public cloud computing resources 259. For the BCHA system 200, regardless of the underlying computing resource starting point, the BCHA system delegation module 210 instantiates the BC HW resource starting point 262 with a BC resource operating system 264 and BCHA resources 266 (which include logistics software components such as BCHA technology stack services, BC machine software and / or container management services, and BCHA applications 268). As will be described in Figure 3D As described in more detail in , the BCHA application 268 is the BCHA system element that executes the BCHA work items 270 and ultimately implements the industrial execution process.

[0117] It should be appreciated that the various BCHA system architectures described facilitate significant flexibility and, therefore, a variety of BCHA system 200 implementations are possible. Various aspects of the BCHA system 200 features, functions, data processing, and storage may be reconfigured to meet the operational constraints, needs, and requirements of a variety of different end-implementation / industrial execution processes. For example, while Figure 2ADiscrete system modules are shown for the BCHA data service module 230, the BCHA system delegation module 210, the BCHA control module 215, and the BCHA reliability engine module 220, but features / functionality associated with one or more of these modules may be implemented as discrete modules or, for some BCHA system architecture implementations, combined and / or distributed with one or more other BCHA system control applications 205 and / or other BCHA system modules / computing resources. In addition, depending on the nature of the specific industrial execution process application associated with the BCHA system 200, aspects of the underlying features or functionality may be configured to be executed as event-driven tasks, continuous loop activities, and / or some combination of events / loops.

[0118] Figure 2B is a flow chart illustrating aspects of how the BCHA system delegation module 210 develops the BCHA system 200. More specifically, Figure 2B is a flow chart illustrating aspects of how the BCHA system delegation module 210 develops and delegates the various BCHA computing resources 240 / 250 associated with the BCHA system 200 and works in conjunction with other BCHA control applications 205 in accordance with the BCHA system development delegation plan (at step 273). In step 275, the BCHA system delegation module 210 instantiates the BCHA data service module 230. After establishing the BCHA data service module 230, the BCHA system delegation module 210 compares the available computing resource hardware starting point with the BCHA system development delegation plan to check in step 276 whether sufficient computing resources can be developed for the BCHA computing resources 240 / 250 to facilitate the industrial execution process. Steps 281 and 284 involve identifying any additional bare hardware starting point resource requirements, access, and any additional resources provided.

[0119] In step 287, the BCHA system delegation module 210 iteratively provisions BCHA computing resources 240 / 250 and instantiates appropriate BCHA applications 268 on the respective BCHA computing resources 240 / 250. In step 290, each BCHA computing resource 240 / 250 and respective BCHA application 268 is in turn registered with the BCHA data service module 230 (although shown as discrete steps, instantiation and registration may occur as the delegation module works with each respective computing resource).

[0120] In step 293, the BCHA system delegation module 210 or the BCHA control application configurator 211 works with one of the BCHA computing resources 240 / 250 to instantiate one or more BCHA control applications 205 and corresponding computing resources. More specifically, the BCHA control application can be configured as a BCHA control module 215, which also includes a BCHA reliability engine module 220 and / or a BCHA WI pool manager module 221, both of which are also registered with the BCHA data service module 230. The aspects of delegating / instantiating the BCHA control module 215 and the reliability engine module 220 involve processing various aspects of the BCHA system development delegation plan to develop availability and operational requirement metrics for the BCHA system. The BCHA control module 215, the BCHA reliability engine module 220, and the BCHA WI management pool manager 221 manage and coordinate BCHA work items 270 across the registered BCHA computing resources 240 / 250 to maintain: (1) BCHA system operations, (1A) feasible M:N working configurations, and (1B) BCHA high availability operational requirements.

[0121] In some implementations, the BCHA control module 215 will initiate load balancing activities based on operational status or based on computing resource failure detection. In step 294, as part of the BCHA control module 215 delegation, the BCHA system control application configurator module 212 also instantiates the BCHA WI management pool manager 221. Once the WI pool is created, in step 295, the BCHA system delegation module 210 instantiates and registers an initial set of work items with the BCHA data service module 230, and populates the pool with the registered work items for allocation by the BCHA WI management pool manager 221. After instantiating the various BCHA system elements, in step 297, the BCHA system control application 205 establishes high availability / redundancy for the BCHA system key elements (e.g., the BCHA data service module 230, the BCHA control module 215, and the BCHA reliability engine module 220). The BCHA system delegation module 210 verifies the delegated BCHA system architecture to confirm consistency with the BCHA system development delegation plan. If the verification is successful, the BCHA system 200 then transitions to the operational state in step 298. If there are any issues with the verification, the BCHA system delegation module 210 works with the BCHA system control application 205 to correct any issues / inconsistencies identified during the verification and then transitions to the operational state.

[0122] After the baseline BCHA system 200 is developed and instantiated, the BCHA control module 215 monitors system health / load balancing metrics associated with the BCHA application 268 that processes BCHA work items 270 across corresponding BCHA computing resources 240 / 250 as the BCHA system 200 operates to implement an industrial execution process. The industrial execution process is the ultimate execution goal of the process control system (or corresponding workflow [or sub-workflow], which is the reason for the creation of the BCHA system 200 - driving the production line or components of the production line. The industrial execution process is identified and defined for a specific BCHA system and includes operational / configuration details regarding some aspects of the requirements for the BCHA computing resources 240 / 250, BCHA applications 268, BCHA system availability / reliability metrics, and various other operational characteristics / capability definitions used to develop the BCHA baseline system requirements. The baseline requirements are downloaded to the BCHA system delegation module 210 and effectively used as a roadmap for developing various components / elements associated with the BCHA system delegation plan.

[0123] Aspects of the BCHA system delegation module 210 that provide corresponding system elements and components (e.g., BCHA computing resources 240 / 250, BCHA applications 268, BCHA work items 270, BCHA data service modules) will be referred to. FIG. 3A to FIG. 3F Describe in more detail.

[0124] Figure 3AAspects of the BCHA system delegation module and the instantiation of the BCHA data service module 230 are shown. The BCHA system delegation plan is downloaded to the BCHA system delegation module 210 and is in turn used to instantiate the BCHA data service module 230. The process begins with the BCHA system delegation module 210 instantiating some baseline BCHA system architecture data 300 according to the delegation plan. For example, the BCHA system delegation module 210 instantiates preliminary data records of the BCHA computing resources 240 / 250 associated with the delegation plan. As the BCHA system delegation module 210 continues to develop the BCHA system 200 that executes the configuration / delegation process, the instantiated computing resource data and other BCHA system component data 305 are populated as each other component / element is instantiated. The BCHA data service module 230 includes data parameters associated with the BCHA system architecture 300, the industrial execution process 301, the BCHA component capability / characteristic data 302, and the operational data output data 303. The BCHA data service module 230 also includes data records related to the BCHA control application 205. BCHA system delegation module data 306, BCHA control module data 307, BCHA reliability engine module data 308, and BCHA WI pool manager data 309. BCHA system component data records 310 and related parameter data are also maintained for data associated with respective BCHA computing resources 311, 312, and 319, BCHA applications 313, 314, and 315 executed on the respective computing resources, and BCHA work items 316, 317, and 318 executed by the BCHA application 314.

[0125] The BCHA data service module 230 may be a highly available (centralized or distributed) data storage / service (e.g., to achieve redundancy) that has access to all BCHA computing resources 240 / 250, BCHA applications 268 / work items 270 executed on BCHA computing resources 240 / 250, BCHA delegation module 210, BCHA control module 215, BCHA reliability engine module 220, and BCHA WI pool manager 221. In some embodiments, the data service availability is at least as high as the availability of the most critical BC applications. In some embodiments, the BCHA data service module 230 may also store data, such as, but not limited to:

[0126] - Unbounded namespace manages all BCHA computing resources 240 / 250, BCHA applications 268 and BCHA work items 270 runtime data aspects

[0127] -BCHA application capabilities / characteristic data / parameters, application configuration data / parameters, application constraint data / parameters

[0128] - BCHA application operational status data / parameters; and

[0129] - All external IO data, IO VTQ, collected by the external IO interface and stored in the data service by one or more BC IO applications.

[0130] Figure 3B Aspects of developing a Boundaryless Control High Availability (BCHA) architecture for computing resources are shown. Figure 3B In step 325, the BCHA system delegation module 210 uses the BCHA system delegation plan to develop the BCHA computing resources 240 / 250 necessary to execute the BCHA applications 268 and BCHA work items 270, which in turn execute the industrial execution process. In step 327, the BCHA system delegation module 210 accesses the delegation plan to determine whether the number / type of available BCHA computing resources 240 / 250 meet the requirements established in the delegation plan. More specifically, the BCHA system delegation module 210 confirms that existing physical / virtual bare metal / starting point resource storage is available and can be configured to meet the BCHA computing resource processing requirements of the industrial execution process. In step 329, the BCHA system delegation module 210 requests additional resource starting points to meet any differences between the execution plan computing resource requirements and the available resource starting points. Once the additional resources are provided, in step 331, the BCHA system delegation module revalidates the plan and available startup resources. After verification, the BCHA system delegation module 210 systematically provides each BCHA computing resource origin with logistics software / firmware module configuration to facilitate BCHA services.

[0131] In step 333, the computing resource starting point is configured with an operating system. Once the operating system is instantiated, the BCHA system delegation module 210 may configure (a) computing resource technology stack services, (b) BCHA machine software and / or (c) container management services in step 335. Utilizing appropriate computing resource logical software components, the BCHA system delegation module 210 iteratively instantiates computing resource BCHA applications 268 in steps 337, 338 for the BCHA applications 268 associated with the specific BCHA computing resources 240 / 250 instantiated. The BCHA applications 268 are configured and delegated to specific BCHA computing resources 240 / 250 in accordance with the requirements determined in the delegation plan and facilitate the industrial execution process. BCHA applications are instantiated in Figure 3C. In step 340, the corresponding BCHA computing resources 240 / 250 and the corresponding BCHA applications 268 are registered with the BCHA data service module 230. Although this is shown as discrete steps, depending on the implementation, each BCHA computing resource 240 / 250 and the corresponding BCHA application 268 can be registered with the BCHA data service module 230 after the BCHA system delegation module 210 completes the instantiation process. Step 342 shows the iterative loop as the BCHA system delegation module 210 performs by instantiating and registering each BCHA computing resource 240 / 250 associated with the BCHA system 200. After the BCHA computing resources 240 / 250 and the corresponding BCHA applications 268 have been delegated and registered, in step 344, the BCHA system delegation module 210 begins instantiating the BCHA control application and work items 270 (respectively in Figure 3D and 3E discussed in more detail in ).

[0132] Figure 3C Aspects of delegating borderless control high availability (BCHA) applications are shown. Figure 3B As discussed, one aspect of delegating BCHA computing resources 240 / 250 involves instantiating various BCHA applications 268 that the respective computing resources will execute to facilitate the industrial execution process. Figure 3C Aspects of how each BCHA application 268 is instantiated are shown. For each BCHA application 268 associated with a BCHA computing resource 240 / 250, the BCHA system control application 205 is instantiated as a series of services. More specifically, as shown by the state service 345, WI management service 346, health service 347, and data service 348 established for each BCHA application 268.

[0133] Figure 3D 205. The BCHA control application configurator 212 is responsible for the initial provisioning of the BCHA system control application 205. The BCHA system control application 205 has the same Figure 3C The discussion begins similarly to the BCHA application 268 and begins as a BCHA application 268 instantiated on a BCHA computing resource 240 / 250. The BCHA system delegation module 210 further provides additional enhanced features / functional modules to the BCHA control application (which facilitates the key hierarchical control role 355 within the BCHA system 200). For example, the BCHA control module 215 is developed as a BCHA computing resource 240 / 250 with a BCHA application 268, which is enhanced with additional load balancing operation capabilities, as is the BCHA reliability engine module 220 and the BCHA WI pool manager 221.

[0134] The BCHA reliability engine module 220 is primarily responsible for working with the BCHA control module 215 to facilitate resource failure detection load-balancing deployment and HA-M:N verification load-balancing. The BCHA reliability engine module 220 may also monitor active BCHA system 200 availability / operation metrics to determine when WI load-balancing is appropriate. When the BCHA reliability engine module 220 performs an operational status assessment and determines that load balancing is appropriate, the BCHA control module 215 coordinates with the BCHA WI pool manager module 221 and facilitates redeployment.

[0135] The BCHA reliability engine module 220 / BCHA WI pool manager 221 facilitates various load balancing types by monitoring operational status / load data and redeployment of BCHA work items 270. In resource failure detection load-balancing, the BCHA reliability engine module 220 may detect a BCHA computing resource 240 / 250 failure and initiate a BCHA control module 215 / BCHA WI pool manager 221 reallocation element redeployment to redeploy and load balance the BCHA applications 268 / BCHA work items 270 associated with the failed BCHA computing resource 240 / 250.

[0136] As another example, the BCHA control module 221 may facilitate HA-M:N verification load-balancing and simulate BCHA computing resource failures to determine and verify the M:N working configuration's ability to maintain high availability requirements despite simulated BCHA computing resource failures.

[0137] These two examples of BCHA system load-balancing illustrate aspects of the features and functionality associated with a BCHA system, and it should be understood that other types of BCHA system load-balancing are possible. These two types of BCHA system load-balancing will be Figures 5A-7C Focus

[0138] Figure 3E Illustrate aspects of the work item for developing a Boundaryless Control High Availability (BCHA) architecture. Figure 3E, as part of executing the BCHA system development delegation plan, BCHA work items 270 are created during the BCHA system 200 instantiation process. In step 357, the BCHA system delegation module 210 works with the BCHA application configurator 211 to atomize the elements of the industrial execution process to create BCHA work items 270 as units of computation or control elements that can be executed by the BCHA application 268. More specifically, in step 358, the BCHA system delegation module 210 / BCHA application configurator 211 processes the industrial execution process elements with a specific generation model - for example, the IAS 88 control model 358A or the 61850 control model 358B. In step 360, as part of WI generation, the BCHA system delegation module 210 / BCHA application configurator 211 creates two parts for the work item: (1) a separate, independent compute / control unit based on a concrete model; and (2) a work item abstract model that includes metadata associated with the BC work item 270 (e.g., BCHA application execution type, WI processing execution / load requirements, timing constraints, input / output data element requirements, etc.).

[0139] In step 362, the WI pool manager 221 processes the abstract model to match and allocate the work item 270 BCHA control module 215 for execution by the BCHA process application 268 / BCHA computing resource 240 / 250. For example, in the WI allocation step 364, the BCHA WI pool manager 221 processes the WI abstract model 364A and determines that the WI metadata indicates that the WI has two operational characteristics (1) the WI requires an IEC 61131 BC application to execute; and (2) the WI will consume five execution / load units on any BC computing resource 240 / 250 to which the work item 270 is ultimately allocated. The WI pool manager 221 accesses the BCHA data service module 230 and searches for any BCHA computing resource 240 / 250 that may match and identifies 364B-a computing resource 240 / 250 that has a WI API metric that indicates that the BC application is an IEC 61131 BC application runtime instance; and has 25 execution / load units available. Depending on the nature of the application and implementation, the BCHA Control Module 215 / BCHA WI Pool Manager Module may be configured to assign BC Work Items 270 once a match is found. Alternatively, it may iterate through the BCHA Compute Resources 240 / 250 to identify not only potential matches, but also the best match based on various optimization methods / criteria.

[0140] In an alternative embodiment, the BCHA work items 270 (or work item groups) can be pre-configured for various process controls, preferred failover default targets and / or included as pre-configured components in the BCHA system development delegation plan. The BC applications 268 for control and other functions in PLCs and DCSs focus on high-granularity control applications. High granularity helps to decompose industrial execution processes into these atomic elements and in turn creates the ability to be independent between the work items 270 and the underlying computing resources 240 / 250. As long as the BCHA application 268 capable of executing the BCHA work item 270 is running, the BCHA computing resources 240 / 250 executing the BCHA application 268 are not directly critical. In a PLC environment, a "program" is typically created using any IEC 61131 language. The created program is then sent to the PLC that executes it. In a DCS system, there is a mix of program control applications and configuration-based control applications. However, in both cases, the configuration is targeted at a specific controller in the system.

[0141] BCHA work items 270 define work to be performed by any BCHA application 268 in the BCHA system 200, such as control, IO scanning, alarming, multivariable optimization, asset management, etc. The BCHA work item 270 types will grow and expand as new BC applications are developed. The BCHA system 200 must provide an abstraction around BC work item management to support diversity and scalability. Figure 3E As shown in FIG. 3 , in step 358 , an abstract model / definition of BCHA work items 270 is created by the BCHA delegation module using the BCHA application configurator 211 and the various BCHA applications 268 associated with the BCHA system 200 .

[0142] This information can be used to facilitate the best match with the BCHA application 268 during a WI load-balancing event. The BCHA work item 270 also contains a set of common data parameters / fields common to all BCHA work items 270 (e.g., number of compute load units to execute, etc.). The common information is used to assign the BCHA work item 270 to the BCHA application 268. The common information is the only work item data visible to the BCHA system 200 outside the BCHA application configurator 211. Independent of any user interaction, the BCHA application configurator 211 segments the created definition into BCHA work items 270. The BCHA work items 270 are created based on rules specific to the BCHA application configurator 211.

[0143] As an example, the loop editor may segment the loop definition into multiple BCHA work items 270: main control, auxiliary control, IO for main input, IO for auxiliary input, IO for output. The determination of the number of generated BCHA work items 270 is done by the BC application configurator 211 based on its internal processing rules, the scope / scale of the industrial execution process, and the BCHA system architecture delegation plan and other operational capabilities / characteristics. The abstraction through BCHA work items 270 allows the BCHA system 200 to manage the allocation of BCHA work items 270 to BCHA applications 268 without knowing the information contained in the work allocation or the nature of the underlying computing elements or control elements. This abstraction provides a high level of scalability.

[0144] Another benefit of separating concrete and abstract behaviors into BCHA work items 270 is the ability to apply various concrete models to the BCHA system 200. The concrete models and their concrete definitions are unknown to the BCHA system 200, such as the BCHA control module 215 and / or other BCHA system architectures that manage abstract models. This allows flexibility and scalability of the BCHA system 200. As an example, a BCHA application configurator 211 associated with the BCHA delegation module 210 can present an ISA88 view for control definitions to the user. The same BCHA application configurator 211 can present an IEC61850 view of the BCHA system 200 to the user. In both cases, the BCHA application configurator 211 can present a loop editor to the user to generate concrete work item units for execution. However, in one case, the BCHA application configurator 211 can display process assets alone, or display process assets in combination with a second scenario including power plant components. In this example, two physical asset models are implemented without making architectural changes to the BCHA system 200. The BCHA system 200 and BCHA control module 215 assign the created BCHA work items 270 without knowledge of the underlying concrete units / representations. A new concrete model is simply a new input to the BCHA application configurator and a new BCHA application 268 in the system facilitated by the BCHA delegation module 210, so that, advantageously, the BCHA system 200 can facilitate new data models, features and / or functionality without necessarily requiring BCHA system architecture changes.

[0145] The allocation of BCHA work items 270 to BCHA applications 268 is abstracted based on the BCHA system 200 attributes including characteristics and capabilities. However, the BCHA system 200 does need information about which BCHA application 268 can process the BCHA work item 270 and other information to support the allocation. The BCHA work item 270 abstract model contains metadata information that characterizes the BCHA work item 270 and its intended use without involving details associated with a specific model. The BCHA applications 268 also publish metadata describing their capabilities to work in the BCHA data service module 230. Metadata is not fixed and is extensible as the BCHA system 200 develops. The metadata contained in the BCHA work item 270 may also be updated, supplemented, supplemented or otherwise changed over time. An old BCHA work item 270 may have less metadata information than a newer BCHA work item 270. The BCHA system 200 and the BCHA control module 215 will use as much information as possible to determine allocation and redeployment during a load balancing event. Similarly, a new BCHA work item 270 may contain additional metadata information that is unknown to the BCHA system 200. Again, the BCHA system 200 will use as much metadata as is available and known to determine the allocation. In all cases, the BCHA application 268 may reject an allocation / re-deployment that requires the BCHA system 200 to redeploy the BCHA application 268 to allocate the BC work item 270 to a different target.

[0146] The BCHA system component identifies load-balancing opportunities and performs WI load balancing events by reallocating BCHA components as reallocated elements. Depending on the specific implementation, the type of load balancing implemented can be established by the system operator, and several types of load balancing (e.g., operating status, active system load balancing fault detection, etc.) can be implemented using the described system. In addition, an optimization model can be implemented that optimizes system load balancing based on more than one type of load balancing. However, in order to illustrate the flexibility and benefits achieved by implementing the BCHA control module 215, the following examples may first focus on load balancing events to achieve maintaining the required "availability" level and / or allocating reallocated elements (e.g., BCHA applications 268 / work items 270) to maximize system availability and / or widely distribute work item execution / processor loads on computing resources 240 / 250 associated with the BCHA system 200. The BCHA control module 215 can also achieve load balancing by temporarily pausing key BCHA applications 268 / work items 270. In some cases, non-critical BCHA applications 268 / work items 270 may be suspended indefinitely or until additional resources are provided to the BCHA system 200 .

[0147] BCHA Control Module 215 / BCHA WI Pool Manager 221 utilizes work item metadata to facilitate WI reallocation. A BCHA work item 270 will contain a variable amount of information, including operational data, configuration metadata (as described above with respect to Figure 3E The metadata specifies at least the BCHA application type and performance characteristics. It may also include other capabilities or characteristics, such as WI priority; interrupt / pause capability or other aspects of WI operation execution.

[0148] Although in the following example, the BCHA control module 215 / BCHA WI pool manager 221 reallocates BCHA work items 270 based on matching the type of BCHA application 268 that can execute the BCHA work item 270 and the system computing resource reallocation availability, the auxiliary reallocation metrics involve widely distributing the processing load on the BCHA computing resources 240 / 250. The reallocation metrics and / or work item 270 performance characteristics are not static. The BCHA delegation module 210 that establishes the initial configuration will perform the initial allocation and generate estimates for the load characteristics of the BCHA work items 270. When the BCHA application 268 executes the BCHA work item 270, it can generate and track operational metrics such as actual load characteristics. These operational metrics (and underlying data / statistics) are maintained in the BCHA data service module 230 and may require more information than the information initially generated by the BCHA delegation module 210. Runtime improvements in performance characteristics will be written back to the BCHA work items 270. The BCHA system 200 will use this improved information if a BCHA work item 270 is reallocated to a different BCHA application 268 and the BCHA system delegation module 210, BCHA control module 215 and / or related BCHA control applications for resource planning, adjustment and reallocation of BCHA components.

[0149] Load characteristics are specific to the BCHA application 268 assigned to process the BCHA work item 270. Load is a representation of the computing resources consumed by the BCHA work item 270 in the BCHA application 268 and will be described as units of execution. The BCHA application 268 load is used by the BCHA application manager to instantiate new instances of the BCHA application for load balancing and more importantly to maintain the required availability level of the BCHA system 200. Characteristics in the BCHA work items will be categorized as "must have" and "desirable". The BCHA system 200 must match all "must have" characteristics before reallocation / assignment is made. "Desirable" characteristics will be matched if possible. However, other constraints such as lack of available resources may result in allocations that do not match the "desired" characteristics.

[0150] The rules for allocation will evolve with the BCHA system 200. Initial rules may only consider matching BCHA application types and total execution unit load. However, rules such as multi-core, asset type, platform type, etc. may be applied in the future. The BCHA application configurator can extend these allocation rules when BCHA work items are generated and / or updated. As previously mentioned, BCHA work item allocation may not succeed if metadata is missing or if there is more metadata than is understood. In these cases, suboptimal allocation may occur, but there will be no system failure. The new rules will follow the paradigm of necessary and auxiliary. Note that if the borderless system is not aware of the required rules, the allocation will still be performed, and the BC application runtime instance will expect to reject the allocation (if inappropriate). The BCHA application 268 should match the configurator and understand the latest features specified by the configurator.

[0151] Resource planning is related to but completely separate from BCHA work items and BCHA work item allocation. The BCHA system 200 service for BCHA work item allocation simply allocates BCHA work items 270 to available BCHA computing resources 240 / 250. If there are insufficient resources, an error is generated and the error will be fixed by the BCHA WI Pool Manager module 221. Another BCHA system control application is the BCHA Application Planner module 213. Through the BCHA Application Planner module, BCHA applications 268 as well as core BCHA services and applications are designated for deployment to BCHA computing resources 240 / 250. The output from the BCHA Application Planner module 213 is used by the provisioning service to establish resources for the BCHA system 200 (in Figure 3A ). The BCHA application planner 213 can utilize the information in the BCHA work items 270 as a planning guide. The BCHA application planner 213 can use the capacity capability characteristics in the BCHA work items 270 when calculating the recommended BCHA system 200 configuration, the number of BCHA applications 268 and BCHA computing resources 240 / 250 required to achieve the required availability for a specific industrial execution process. Similarly, the BCHA control module 215 and the BC work item pool manager module 221 can provide system notifications of insufficient available resources. Similarly, additional system loads can be created because the BCHA application configurator 211 generates additional BCHA work items 270 for execution. Users can interact with the BCHA application planner 213 / BCHA system delegation module 210 to provide additional BCHA computing resources 240 / 250.

[0152] BCHA work items provide a finer granularity of work definition compared to traditional configurations deployed to specific PLCs or DCS controllers. One advantage of finer granularity is the automatic BCHA controller module 215 / BCHA WI pool manager module 221 load balancing in the BCHA system 200. Instead of requiring the user computing system to load and distribute the BCHA applications 268 to different BCHA computing resources 240 / 250, the BCHA system 200 can continuously monitor and adjust the load placed on the BCHA computing resources 240 / 250. Load balancing will initially implement preliminary rules, such as maintaining an even number of BCHA work items 270 loads on each BCHA computing resource 240 / 250. However, load balancing can be extended to incorporate more complex rules, such as shifting work to low energy resources, thereby allowing for more favorable BCHA system 200 utilization.

[0153] The granularity also allows for the possibility of failure of BCHA computing resources 240 / 250 (in the following Figure 5A , 5B1 and 5B2), work performed in a given BCHA application 268 can be reallocated among other BCHA applications 268. Instead of transferring all work to a BCHA application in a standby BCHA computing resource 240 / 250, the work can be divided among any BCHA applications associated with the remaining active BCHA computing resources 240 / 250 associated with the M:N working configuration. This BCHA work item management implements an M:N working configuration redundancy model. In some instances, an M:N+R working configuration redundancy model can be implemented, in which one or more additional BCHA computing resources 240 / 250 need to be requested and provided to supplement existing BCHA computing resources 240 / 250 and to provide reallocation targets for specific reallocated elements. Performance considerations may require that BCHA applications 268 have configuration data pre-loaded for BCHA work items 270 that they may be requested to execute but are not currently executing. This allows for faster failover as BCHA work items are reallocated, and will require new BCHA applications 268 to load the latest state data rather than the complete configuration of the BC work item.

[0154] Figure 3F Illustrated is how aspects of the Boundaryless Control High Availability (BCHA) architecture properties, capabilities, and characteristics are managed and coordinated using the BCHA data service module 230. Each BCHA component associated with the BCHA system architecture has BCHA system properties including BCHA component capabilities and characteristics, which are stored in the HA data service module 230 when each component is instantiated / registered during the BCHA system development process. Figure 3F The hierarchical interdependencies of the hierarchical elements associated with the BCHA system components are shown. Figure 3F As shown, each layer of BCHA application work item layer 376, BCHA application layer 377, BCHA control application layer 378, BCHA container / resource layer 379 and BCHA computing resource layer 380 respectively contributes BCHA system attributes as capabilities / characteristics for BCHA system components. BCHA system attributes ultimately affect BCHA system management and / or BCHA redistribution element redeployment in the BCHA control module.

[0155] The BCHA system control application 205 (e.g., BCHA control module and / or BCHA reliability engine module) uses these requirements to determine system requirements for BCHA computing resources 240 / 250 to facilitate load balancing. The BCHA control module 215 can use BCHA system attributes to identify which BCHA computing resources 240 / 250 are suitable for a given application based on predetermined application characteristics (e.g., application metadata). The BCHA reliability engine module 220 can use BCHA application characteristics to manage provisioning rules. The BCHA reliability engine module 220 can also calculate a system availability metric for the BCHA system 200. The algorithm used to calculate the real-time BCHA system 200 availability metric maximizes the opportunity for system users to get the best chance of a response before negative impacts (e.g., providing additional requested resources before the safety system shuts down the BCHA system). In some embodiments, the actual availability of the system is based on the currently available BCHA computing resources 240 / 250 and BCHA active / inactive applications 268, the number of failed resources, the number of running BCHA applications 268, applications and their priority / criticality, the number of inactive applications and their criticality, the number of additional resources that need to be provided to run each required application, etc. The BCHA system facilitates significant flexibility in system implementation and is configured to achieve the described benefits involving BCHA system management in a variety of different implementations / configurations. The following sequence of figures and corresponding descriptions will describe in more detail how these features and functions are implemented, and therefore how efficiency and system efficacy improvements are achieved.

[0156] Figure 4 Shows how to implement aspects of a Boundaryless Control High Availability (BCHA) application. Figure 4 , the BCHA application 268 executes on the BCHA computing resource 240 / 250 as App_1 450. When any changes are detected in the control loop monitoring the BCHA computing resource 240 / 250 data, the capabilities / characteristics registered with the BCHA computing resource 240 / 250 are updated with the BCHA data service 230. App_1 450, connects with the BCHA data service in 451, updates the BCHA application capabilities / characteristics (if applicable) in step 452, and obtains any assigned BCHA work items 270 in step 453.

[0157] While executing the assigned BCHA work item 270, App 1 updates the operational status in step 455, processes the work item 1_1 in step 456, and updates the work item capabilities / features (if appropriate) in step 457. Steps BCHA work item execution 458, operational status update 459, WI data record update in BCHA data service module 220, and loop until completion step 461 illustrate an example of elements associated with application work item processing. In step 462, the BCHA application periodically checks to determine if the BCHA data service module 230 has additional BCHA work items to be assigned to a particular BCHA application.

[0158] Figure 5A Aspects of the BCHA load-balancing opportunities of the BCHA system are shown. A key aspect of the BCHA system 200 functionality is the ability to load balance system elements to achieve high availability requirements associated with specific industrial execution processes and related process control application requirements. Dynamically load balancing is a key feature that also helps make M:N working configurations possible and feasible for the BCHA system 200, where redundancy and high availability are key requirements for the BCHA system 200. Figure 5A Aspects of load balancing types associated with the BCHA system 200, such as resource failure detection load-balancing / reallocation and HA-M:N verification load balancing, are shown. It should be understood that other types of load-balancing are possible, depending on the nature of the particular implementation and the BCHA system components, features and / or capabilities.

[0159] exist Figure 5AIn step 500, when the system transitions to the "Operational" state, the BCHA application configurator 211 provides an initial pool of BCHA work items 270 for allocation. In step 503, the BCHA control application 205 participates in the BCHA system 200. The BCHAWI pool manager module allocates the BCHA work items 270 to the appropriate BCHA applications 268 / BCHA computing resources 240 / 250. In step 506, the BCHA control module 215 / BCHA reliability engine 220 begins monitoring the system health / operational status data maintained in the BCHA data service module 230. The BCHA control module 215 / BCHA reliability engine module 220 is monitoring the BCHA system 200 health / operational status to identify resource failure detection load-balancing opportunities 509 and loops through step 511 and returns to step 506 to continue monitoring until a failure is detected. Depending on the specific implementation and industrial execution process requirements, the loop frequency can be adjusted according to the specific implementation, ranging from a constant loop as a background workflow to 5ms, to 5 seconds, to 5 minutes to every 5 hours, or otherwise adjusted based on what may be suitable for the specific BCHA system 200 implementation.

[0160] In step 509, if a resource failure detection load-balancing opportunity is identified, the resource failure detection load-balancing opportunity is initiated in step 513 and the subsequent steps / timeline of the BCHA system actions will be determined. In step 515, the BCHA system 200 and the BCHA control module resource failure detection load-balancing determine which BCHA system component should be reallocated as a reallocated element based on which BCHA computing resource 240 / 250 has failed. The BCHA control module 215 determines the reallocation type in step 517, the reallocation pool in step 518, and the specific reallocation target in step 519. In step 521, the BCHA control module 215 performs the reallocation of the reallocated element to the reallocation target. The BCHA control module 215 attempts to maintain (1) system feasibility; (1A) system high availability operating characteristics, and therefore a feasible M:N working configuration. For resource failure detection reallocation, despite the failure of actual computing resources 240 / 250, the BCHA system faces the challenge of maintaining (1) system feasibility; and (1A) system high availability operational characteristics.

[0161] In step 523, the BCHA control module 215 runs a background task that iteratively simulates BCHA system 200 computing resource 240 / 250 failures to verify the BCHA system high availability requirements and a feasible M:N working configuration - as HA-M:N verification load-balancing. In step 525, the BCHA control module 215 iteratively loops and simulates the corresponding computing resources 240 / 250 associated with the BCHA system failure and redeployed according to the resource failure detection reallocation. After the resource failure detection reallocation, the BCHA control module 215 determines the repair operation status in step 527. If after simulating each computing resource 240 / 250, the resource failure detection reallocation results in all green state redeployment - the BCHA system is indeed a feasible M:N working configuration. If there is a non-green state after each simulated resource failure detection reallocation, the BCHA system 200 is an M:N+R working configuration - additional computing resources are required to maintain the high availability requirements of the BCHA system 200 and to transform the BCHA system to a feasible M:N working configuration. Respectively with respect to Figure 5B1-5B2 and 5C describe resource failure detection reallocation and activity load balancing / simulation in more detail.

[0162] Figure 5B1 Aspects of BCHA load-balancing opportunities associated with fault detection / repair of a BCHA system are shown. In the event of a failure of a BCHA computing resource 240 / 250, the BCHA system 200 performs resource failure load-balancing reallocation and is used to work to maintain (1) system feasibility, (1A) a feasible M:N working configuration, and (1B) system high availability operating characteristics. Depending on the specific industrial implementation process and application, the BCHA system 200 can be configured to focus primarily on 1 and 1A, while 1B may not be critical to operational requirements. The BCHA system 200 can be quickly and efficiently pre-configured to request, receive, provide, and transform reallocated elements to supplemental resources - effectively operating an M:N+R working configuration. In some implementations, the BCHA system 200 can automatically repair by working with a BCHA computing resource provider to obtain a pre-configured BCHA computing resource 240 / 250 without generating a request for additional resources. Both M:N and M:N+R BCHA system working configurations can achieve the benefit of avoiding all the additional costs / expenses of a 1:1 physical hardware redundant working configuration. In addition, they achieve better operational efficiency and resource utilization characteristics compared to 1:1 physical hardware redundant working configurations.

[0163] exist Figure 5B1In step 531, the BCHA controller 215 / BCHA reliability 220 engine monitoring the BCHA data service module 230 detects a BCHA computing resource 240 / 250 failure. In step 533, after detecting the failure, the BCHA controller 215 determines which BCHA system components are executing on the failed BCHA computing resource 240 / 250 and need to be reallocated as reallocated elements (e.g., BCHA applications 268 and / or BCHA work items 270). Once the reallocated elements are determined, in step 535, in addition to the current reallocation type setting, the characteristics / capabilities associated with the failed BCHA computing resource 240 / 250 and the reallocated elements are analyzed. Various reallocation types are possible, including fastest reallocation, balanced reallocation, optimal reallocation, critical reallocation element redeployment, or maximizing the use of existing resources (supplemental / additional BCHA computing resources 240 / 250 may be scarce and / or difficult to provide). These reallocation types are provided as non-limiting examples, and other types are possible depending on the particular BCHA system implementation, the corresponding industrial execution process, and / or other configuration or operating characteristics / capabilities. In step 538, the BCHA control module 215 begins determining a reallocation target pool (based on the determination and analysis from steps 533 and 535), which identifies possible reallocation targets (e.g., BCHA applications 268 and / or BCHA computing resources 240 / 250) that are potentially available for redeploying the reallocated elements.

[0164] To maximize the likelihood of a feasible existing resource reallocation target pool, the matching matching method focuses on two sets of parameters associated with the BCHA system component capabilities and characteristics - (1) BCHA redeployment requirements (e.g., high availability requirements; specific I / O types; execution unit processing load; and (2) BCHA redeployment preferences (e.g., near real-time execution, etc.). There are generally two possible types of reallocation target pools: (1) a target pool that uses only existing resources (e.g., M:N working configuration), where all BCHA redeployment requirements are met and the redeployment options that maximize the number of satisfied BCHA redeployment preferences are selected; or (2) a target pool that uses existing resources and supplements requested resources (e.g., M:N+1 or M:N+R). Figure 5B1In step 539, step 539 involves determining the best possible solution as a pool of reallocation targets created from existing BCHA system components with multiple options for various reallocation element redeployment targets. A variation of this option is a perfect fit scenario where at least one existing BCHA target can facilitate a single redeployment option - satisfying all BCHA redeployment requirements. In step 539, the BCHA control module determines whether there is an immediate target redeployment option available. If it is determined in step 541 that there are multiple potential reallocation target options, the BCHA control module 215 analyzes the BCHA redeployment requirements and BCHA redeployment preferences to identify an option that meets the reallocation type (e.g., the fastest failover type is the first reallocation option identified, even if others may exist; the best is the reallocation option that satisfies the most redeployment requirements / preferences) and selects a reallocation target in step 543. In step 544, the reallocation element transitions to the reallocation target and is activated in step 544. In some implementations, the reallocation element accesses the BCHA data service module 230 and obtains operational / configuration data associated with the deployment at the time of (or before) the BCHA computing resource failure. Thus, reallocating elements can efficiently pick up where they left off with minimal time / data loss.

[0165] If no immediate target is available in step 539, the BCHA control module 215 may perform a simulated work configuration load reallocation to determine whether transitioning the active BCHA application 268 / BCHA work item 270 creates an available target for the reallocated element without stopping the BCHA component or requesting replenishment of BCHA computing resources 240 / 250 in step 545. If the simulated work configuration load reallocation creates a reallocated target, the BCHA control module reallocates the active BCHA application 268 / BCHA work item 270 to create a target in step 542 and selects a target in step 543. In step 544, the reallocated element is assigned to the reallocated target and made active.

[0166] If the simulated work configuration load redistribution in step 545 does not create an available reallocation target, the BCHA control module 215 attempts to stop non-critical (and / or some implementation low priority) components in step 547 to try to create an available reallocation target. If stopping non-critical BCHA computing resources 240 / 250 creates an available reallocation target, the BCHA control module 215 determines in step 548 whether to enable degraded non-critical time-slicing processing, and if so it transfers the non-critical BCHA components to a time-slicing queue, where the members of the queue are each part of the dedicated processing execution resources in step 549 (if and as additional processing resources are provided). For example, if two non-critical applications are in the queue, each will get normal processing execution resources. The queue can also be rebalanced based on BCHA application priority, for example, if App_1 can get 75% of the processing execution resources because it has a higher priority than App 2, which only gets 25% of the processing execution resources. The BCHA control module 215 stops non-critical BCHA components in step 550 and creates a target pool in step 552. In step 544, the reallocation element is allocated to the reallocation target and activated. If stopping the non-critical components does not create an available reallocation target, the BCHA control module 215 attempts to create an available reallocation target by also stopping the critical BCHA components in step 551. If stopping the critical BCHA components creates an available reallocation target in step 551, the BCHA control module stops at least one critical BCHA component and one or more non-critical components in steps 552 and 550, respectively, to create a target reallocation pool in step 542, respectively, and selects a reallocation target in step 543. In step 544, the reallocation element is allocated to the reallocation target and activated.

[0167] At this point, after performing simulated working configuration load redistribution, checking non-critical components, and checking critical components (alone or in combination with non-critical components), the BCHA control module 215 may have to request (or automatically repair) supplemental BCHA computing resources 240 / 250 in step 553 and provide supplemental BCHA computing resources 240 / 250 in step 554. After each previous check, the BCHA control module can identify which attempt is closest to actually creating an availability reallocation target and define the type, size capabilities / characteristics associated with the requested supplemental BCHA computing resources to minimize cost or provisioning time or the number of BCHA computing resource parameters. In some implementations, supplemental BCHA computing resource configuration can be based on the BCHA control module determining what is necessary to provide to ensure a robust M:N working configuration. Using the provided supplemental BCHA computing resources 240 / 250, the BCHA control module can create a pool of reallocation targets in step 442 and select a reallocation target in 543. In step 544, the reallocation elements are assigned to the reallocation targets and activated.

[0168] Figure 5B2 Aspects of the fault detection / repair load-balancing opportunities associated with restoring the operational state of a BCHA system are shown. Figure 5B2 In step 560, after the BCHA system 200 promotes reallocation / redeployment to maintain system viability as the primary goal of the BCHA system 200, in step 560, the BCHA control module 215 / BCHA reliability engine 220 checks the BCHA operational status in an attempt to comply with the BCHA system goal 1A - compliance with BCHA system high availability requirements. In step 563, the BCHA reliability engine module 220 checks the operational metrics / status data in the BCHA data service module 230 and confirms that a green state repair has been achieved. More specifically, in the state diagram element 565, all BCHA applications 268 and BCHA work items 270 have been redeployed and are fully operational under all BCHA system high availability requirements. If a green state repair has been achieved, then in step 568, the BCHA control module 215 transitions back to periodic / continuous BCHA system health / operational status monitoring.

[0169] In step 563, if the BCHA control module 215 determines that green state repair has not been achieved, the controller will develop and execute a BCHA system recovery plan in step 571. Figure 5B2, the first aspect of developing a BCHA system recovery plan is to determine which non-green state is associated with the BCHA system 200 operational state. If, as a result of a reallocation as a failure detection, the BCHA control module 215 is able to keep the system running but must suspend critical BCHA applications 268 in order to keep higher priority critical BCHA applications 268 running, the BCHA system 200 is considered to be in a red operational state - as shown in state diagram element 573. If the BCHA control module 215 is able to keep the system running but must suspend one or more non-critical BCHA applications 268, the BCHA system 200 is considered to be in an orange operational state - as shown in state diagram element 575. The third non-green operational state is a yellow state (state diagram element 577) in which all reallocated elements have been successfully redeployed, but the BCHA system 200 has one or more BCHA applications 268 that do not meet the BCHA system 200 high availability requirements.

[0170] In some implementations, a suspended non-critical application may be maintained in an active but degraded operating state. More specifically, the suspended non-critical application may be added to a degraded progress queue, and the BCHA control module 215 may sequentially iterate the suspended application to provide a portion of the processing / computing resources for certain aspects of the reallocated element in order to keep the system operational until additional resources can be provided. The BCHA control module 215 sequentially iterates the degraded application 268 / work item 270 queue and systematically provides at least a portion of the requested computing resource execution unit requirement of the reallocated element.

[0171] In all red and orange operating states, the BCHA control module 215 can determine the number and type of supplemental BCHA computing resources required to transition the BCHA system 200 back to a fully green operating state (565). The BCHA system can also determine and report whether the repair time - the time to transition back to the green operating state (565) can be achieved before the industrial execution process safety system transitions to shut down the industrial execution process to avoid unsafe conditions / operations. Depending on the specific implementation, as well as the current operating characteristics, the determined operating state and the availability of supplemental BCHA computing resources 240 / 250, the transition back to the green state can be a full, direct transition from red, orange to green or it can be a gradual transition back to the green state (either path has a repair time that is less than the industrial execution process safety system shutdown time).

[0172] Figure 5B2The operational states discussed as green, yellow, orange, and red operational states are provided to help illustrate how the BCHA system 200 is able to dynamically manage and coordinate aspects of the various BCHA system components, including the BCHA computing resources 240 / 250, the BCHA applications 268, and the BCHA work items, to maintain one or more BCHA system 200 operational integrity, a viable M:N working configuration, and operations in accordance with BCHA system 200 / BCHA application high availability requirements. Depending on the implementation, different functional operational state names, operational characteristics, and even operation times may be implemented. For example, Green may be renamed "Viable MNHA Operational State" and abbreviated to "MNOK_HAOK", Yellow may be renamed "Viable MN Operational State" and abbreviated to "MNOK_HADG", Orange may be renamed "Degraded MN Operational State" and abbreviated to "MNDG_HACRT", Red may be renamed "Critical System 200 Operational State" and abbreviated to "MNDG_HACRT", and Red may be renamed "Critical System 200 Operational State". The BCHA system 200 is referred to as a "operational state" and abbreviated as "CS" or "MNCRT_HACRT". Instead of involving M:N and HA operational states, a subset can also be focused on one BCHA operational parameter. For example, a BCHA system configured with three operational states (or sub-states) focused on one BCHA operational parameter can be "viable HA" or "viable MN"; "degraded HA" or "degraded MN"; "critical HA" or "critical M:N". Other BCHA operational parameters can also be used to develop state controls (e.g., work item execution load distribution as "heavy", "medium" and / or "light". As another example, the BCHA system 200 can be configured with binary operational states, where the system is "operational or not operational". These examples are provided as non-limiting examples, and the BCHA system 200 can be configured to facilitate multiple other operational implementations.

[0173] Figure 5C Shown are aspects of active BCHA system load balancing / healing associated with M:N authentication. Figure 5CAspects associated with HA-M:N verification load balancing and M:N workgroup verification / repair are shown. More specifically, in order to ensure a viable M:N working configuration with sufficient spare computing resources to execute availability without actual 1:1 redundant physical hardware, the BCHA control module 220 performs background activities involving HA-M:N verification load balancing to facilitate M:N workgroup verification / repair scenario testing. M:N workgroup verification / repair is executed as an auxiliary BCHA application 268 to iteratively simulate BCHA computing resource 240 / 250 failures, resource failure detection load balancing, and subsequent operational status testing to determine whether the M:N working configuration has sufficient computing resources to execute availability for a specific BCHA computing resource 240 / 250 failure to facilitate redeployment using only existing computing resources 240 / 250 while maintaining high availability operational requirements associated with the BCHA system 200. HA-M:N verification load balancing is a flexible simulation process and can verify various BCHA system configurations. Figure 5C In the example described in , the BCHA control module 215 steps through and simulates a first level of failure, where the validation report reflects the aggregated repair state - the results of simulating the failure of each BCHA computing resource 240 / 250 associated with the M:N working configuration one at a time - for example, a BCHA system with five BCHA computing resources 240 / 250 will execute five simulation cycles - and during each simulation cycle, a different BCHA computing resource 240 / 250 will fail. If each of the five simulation cycles has a green repair state, then the M:N working configuration has been validated. If any one of the simulation cycles results in a non-green repair state, then the M:N working configuration may have to be further evolved into an M:N+R working configuration, i.e., supplemental resources may be required to achieve a viable M:N working configuration, executed using an optimized balance of spare execution resources, while minimizing additional computing resource requirements and still completely avoiding the old 1:1 redundant physical hardware requirements.

[0174] exist Figure 5CIn step 577, the BCHA controller 220 determines the HA-M:N verification load balancing verification level, such as a first level fault simulation. In some implementations, the simulated fault level can be established as a system default and updated appropriately by the system operator. The verification level sets the number of computing resources 240 / 250 that the BCHA controller 220 will simulate during the iteration (e.g., a first degree fault simulation verifies an M:N working configuration in which one computing resource 240 / 250 fails, a second degree fault simulation verifies an instance in which two computing resources 240 / 250 fail, and so on...). Figure 5C In the example of FIG. 5 , the BCHA controller 220 operates in an isolated segment of the BCHA data service module 230, which is populated with the BCHA system 200 architecture, components, and operational data associated with the system as of the time of starting an instance of HA-M:N verification load balancing. In step 579, the BCHA controller 220 simulates a failure of the first computing resource 240 / 250 associated with the BCHA system 200. In step 581, the BCHA controller module 215 simulates the failure of the first computing resource 240 / 250 associated with the BCHA system 200. Figure 5B1 and Figure 5B2 583, the BCHA controller module 215 determines the repair operation status after redeploying the fault redistribution element to the redistribution target. If the repair operation status involves a green state in step 585, the M:N working configuration is verified for the fault of the corresponding BCHA computing resource 240 / 250. However, for a robust and feasible M:N working configuration, each BCHA computing resource 240 / 250 associated with the BCHA system 200 must also have a green state repair operation status. Therefore, in step 587, the repair operation status is recorded for the corresponding loop of the HA-M:N verification load balancing verification, and the BCHA controller 220 checks in step 589 whether it is necessary to simulate additional BCHA computing resource 240 / 250 failures for verification. In step 591, the M:N working configuration computing resource count is incremented, and the simulation starts the next cycle, simulating the failure of the next BCHA computing resource 240 / 250 in the sequence, and looping back to step 579.

[0175] exist Figure 5CIn step 583, if the repair operation state is not a green state as identified in step 593, the simulated failure of the corresponding computing resource 240 / 250 does not conform to the M:N working configuration. The system may still be operational, but in an M:N+R working configuration, where supplemental / additional computing resources 240 / 250 may be required to transition the repair operation state back to a green state and achieve a feasible M:N working configuration. Based on the capabilities / characteristics of the failed computing resources 240 / 250 and the capabilities / characteristics of the reallocated elements, the BCHA controller 220 may determine what type / how many supplemental / additional computing resources 240 / 250 may be required to transition from the M:N+R working configuration to a feasible M:N working configuration. Depending on the particular system configuration, M:N+R working configuration transition requirements may be reported when they are detected. Alternatively, as in Figure 5C As in the example shown in , the M:N+R working configuration transition requirement is determined in step 593 and recorded in step 587 .

[0176] If all failures were simulated for all working configuration BCHA computing resources 240 / 250 in step 589 associated with the BCHA system 200, step 595 involves developing an M:N working configuration validation report and for confirming the automatic execution of system requests for supplemental / additional BCHA computing resources 240 / 250 based on any M:N+R working configuration transition requirements associated with the performed HA-M:N validation load balancing validation. In some implementations, the M:N working configuration validation report may identify various operational validation results, as well as system-generated remediation actions to address issues identified during the simulation / validation. For example, the system-generated remediation actions may include a list of suggested system-generated supplemental computing resources 240 / 250 that will be required, provided, and supplied to achieve a feasible M:N working configuration for the BCHA system 200. Details may also be included as to how failures of one or more specific computing resources 240 / 250 are considered in the proposed list of system-generated supplemental computing resources.

[0177] In one embodiment, the BCHA control module 215 may include an automatic repair feature as in 595. More specifically, the BCHA control module 215 may be configured to connect to a pre-approved BCHA computing resource 240 / 250 provider (e.g., a public cloud service provider). Once connected to the provider, the BCHA control module 215 may directly access and request the provision of one or more preconfigured or customized BCHA computing resources 240 / 250. Thus, the BCHA control module 215 may quickly and efficiently repair problems identified by HA-M:N validation load balancing, requesting, providing, and redeploying reallocated elements to supplemental BHCA computing resources 240 / 250. The BCHA control module 215 may choose to compare the preconfigured BCHA computing resources 240 / 250 with the capabilities and characteristics required for reallocation to determine the best-fitting preconfigured BCHA computing resource 240 / 250. The BCHA control module 215 may choose to compare preconfigured BCHA computing resources 240 / 250 that have additional capabilities and characteristics than those identified to repair problems identified during the repair operation status determination. The BCHA control module 215 may generate similar requests for the customized BHCA computing resources 240 / 250 - specifically requesting additional capabilities and features from the customized BHCA computing resources 240 / 250 than those identified to repair the problems identified during the repair operation status determination.

[0178] With the additional capabilities and features, the BCHA control module 215 may perform optimal load redistribution to shift applications across available BCHA computing resources to minimize processor load, BCHA work item execution unit load, BCHA application load, and / or a combination of two or more minimization parameters (e.g., a first BCHA work item execution unit load and a second BCHA application load). The BCHA control module 215 may make an optimal load redistribution determination prior to requesting a pre-configured or customized BCHA computing resource 240 / 250.

[0179] Figure 6A-6B7 Aspects of an example of how the BCHA system 200 operates to repair BCHA computing resource 240 / 250 failures and maintain a viable M:N working configuration are shown. Fig. 6A Such a BCHA system is shown, which includes five BCHA computing resources 240 / 250 (in Fig. 6A 610, CR-2 620, CR-3 630, CR-4 640, and CR-5 650), the respective BCHA applications 268 executed on the BCHA computing resources 240 / 250 (in Fig. 6A1 612, App_2 614, App_3 616, App_4 626, App_5 642, App_6 645, and App_7 654) and the BCHA work items 270 executed on the corresponding BCHA applications 268 (in Fig. 6A 1 613, WI 2_1 615, WI 3_1 617, WI 4_1 627, WI5_1 633, WI 6_1 645 and App_7_1 655). Each BCHA system component is in operational communication with the BCHA data service 230 and the BCHA control application 205, and in particular the BCHA control module 215, the BCHA reliability engine module 220 and the BCHA WI pool manager module 221 are actively participating in the BCHA system 200 components.

[0180] Figure sequence 6B1-6B7 is an example implementation of how the BCHA system 200 works to identify and repair failures of BCHA computing resources 240 / 250 and to redeploy reallocated elements associated with the failed BCHA computing resources 240 / 250. The reallocated elements may include BCHA applications 268 executed on the BCHA computing resources and / or corresponding BCHA work items 270 executed by the corresponding BCHA applications 268. Each Figure 6B1-6B7 Key operational states associated with each step that the BCHA system performs to detect and repair resource failures into execution timeline 699 are shown.

[0181] Fig.6B1 BCHA computing resources 240 / 250 and BCHA application 268 capabilities, characteristics, and BCHA operational status associated with BCHA work items 270 are shown. Fig.6B1 In the example, the BCHA system operates in a green state and meets all high availability requirements.

[0182] Fig.6B1 The BCHA system 200 components shown in are a steady-state operational view of the BCHA data service data associated with time / state 160 and stored in the BCHA date service. In State 1, all BCHA computing resources 240 / 250 are executing in a green state as a viable M:N working configuration, where all BCHA system 200 high availability operational requirements are met. State 1 diagram 600 shows the corresponding capabilities / characteristics of computing resources CR1-CR5, APP_1-App_7 and corresponding work items 1_1-7_1, as well as the BCHA system component operational states associated with each BCHA system component as active, inactive, maintained, respectively (after the failure of computing resource CR-4 Figure 6B2Figure 2- "Failure"). The sequence of diagrams is how the BCHA system 200 works to identify and repair BCHA computing resources 240 / 250, Figure 6B2 Example implementation of failures of BCHA application 268 in - BCHA - Failure detection / HA operation assessment - CR4 failure / failure detection;

[0183] Figure 6B2 The operational state when BCHA computing resource CR-4 fails is shown, along with instances of App_5 / work item 5_1 and App6 / work item 6_1. After CR-4 fails, the BCHA control module 215 detects the failure in the BCHA data service module 230 and updates the operational state associated with CR-4.

[0184] exist Figure 6B3 , the BCHA control module 215 determines the capabilities and characteristics associated with the failed computing resources 240 / 250, including computing resource availability requirements and real-time operation requirements. The BCHA control module 215 also determines the capabilities and characteristics associated with App_5 / work item 5_1 and App_65 / work item 6_1, including application priority, application availability requirements, and application real-time requirements. In some BCHA system 200 implementations, the BCHA application 268 priority is used to perform a reallocation type - for example, a higher priority reallocation element can be redeployed to a potential reallocation target with a fast redeployment reallocation type before a lower priority reallocation element. In the best redeployment reallocation type, the BCHA control module can attempt to suspend a lower priority application to support the creation of availability for the redeployment of a higher priority application. Depending on the implementation, other capabilities / characteristics may include dedicated I / O connections associated with a particular computing resource 240 / 250 or BCHA application 268 / BCHA work item 270, as well as processor load capabilities or processor execution requirements.

[0185] exist Figure 6B4, the BCHA control module 215 evaluates the capabilities, characteristics, and availability requirements of other existing computing resources 240 / 250 (e.g., CR-1, CR-2, CR-3, and CR-5) associated with the BCHA system 200. In this example, each computing resource 240 / 250 has the capability with respect to processing memory / processing power to support three BCHA applications 268 / work items 270. Therefore, the BCHA control module 215 excludes CR1 and CR-2 from the reallocation pool of potential redeployment targets. Therefore, the generated reallocation pool includes CR-3 and CR-5. In order to maintain a viable M:N working configuration, the BCHA control module 215 will check the other characteristics / capabilities of CR-3 and CR-5, as well as App_5 / work item 5_1 and App 6 / work item 5_1 and find that CR-3 and CR-5 are both potential targets that can simultaneously adopt the reallocation elements - the failed applications / work items in this example as the reallocation pool.

[0186] The BCHA control module 215 selects CR-3 as the reallocation target for App 5 because CR-3 satisfies the first two checks (i.e., (1) availability of the reallocated element is obtained; and (2) there is already an instance of the reallocation in an active / inactive state). The BCHA control module 215 attempts to balance fast failover while also attempting to balance / spread the reallocated elements among the reallocation pool potential targets to minimize processor load and keep as many available reallocation slots as possible open among the BCHA computing resources 240 / 250 associated with the particular M:N working configuration. By striving to maximize as many available reallocation slots as possible, the BCHA control module maximizes the likelihood of redeployment in an existing M:N working configuration, particularly in such a working configuration that includes a wide range of heterogeneous pools of BCHA computing resources 240 / 250 and BCHA application system types / hardware types with a corresponding wide range of capabilities and features.

[0187] Figure 6B5Aspects of how the BCHA control module 215 selects a specific BCHA computing resource 240 / 250 as a reallocation target for a corresponding reallocation element are shown. In this example, the BCHA control module 215 determines the selected reallocation type (rather than "balanced failover redeployment", "best failover redeployment" or "fastest failover redeployment"). The reallocation type is particularly useful in determining reallocation targets, where there are several possible redeployment target schemes for a specific reallocation pool. Depending on the implementation, M:N working configuration operational data, BCHA system component functions / features, and specific available reallocation types, there may be situations where each redeployment type will result in the selection of the same reallocation target. There may also be some instances, depending on the load characteristics of the specific M:N working configuration and the specific type of resource failure, where supplemental / additional computing resources will be necessary to maintain system feasibility and BCHA system high availability requirements. For balanced reallocation types, after checking existing inactive instances and can be made active and adopt reallocation elements, or have processing load availability (for example, fewer than 3 applications are executing at the time of evaluation).

[0188] In this example, the "Balanced Failover Type" of the BCHA Control Module 215 checks whether any of the reallocation targets in the reallocation pool currently has an existing instance of the application executing in an active / inactive state (this is also the first check for the Fastest Failover Redeployment reallocation type). Figure 6B5 , the BCHA control module 215 identifies an instance of App_5 executing on CR-3 in an inactive state. After confirming that CR-3 does not fully load the processor, the BCHA control module 215 confirms whether CR-3 matches any other required reallocation characteristics / capabilities associated with the failed App_5, and checks whether there are any secondary reallocation characteristics / capabilities associated with the failed App_5 (e.g., specific processing speed / processing power). In the "Balanced Failover Type", if multiple potential reallocation targets in the reallocation pool meet all required reallocation characteristics / capabilities, the potential reallocation target that meets the maximum secondary reallocation characteristics / capabilities can be selected as the reallocation target (this is also true for the Best Failover Redeployment Reallocation Type).

[0189] Figure 6B6The BCHA control module is shown reallocating App_5 / work item 5_1 and App_6 / work item 6_1 from the failed computing resource CR-4 to the selected reallocation target, where App_5 / work item 5_1 is transferred to CR-3 and App_6 / work item 6_1 is instantiated and executes work item 6-1 on CR-5, respectively. For this example, the BCHA controller redeploys the system by developing a reallocation pool from an existing M:N working configuration resource.

[0190] In some embodiments, to ensure that the BCHA system 200 continues to operate using existing BCHA system components in an M:N working configuration, the BCHA controller 215 may temporarily / indefinitely suspend non-critical BCHA applications. Figure 6B7 In the alternative embodiment shown, the Figure 6B1-6B6 Some capabilities / features associated with the example embodiments described in Figure 6B6 In the example shown, CR-4, App_6 has a reallocated capability / feature requirement that cannot be redeployed to CR-5. For example, CR-4, App may have an I / O sensor input requirement that is not connected to CR-5. Instead, in this example, CR-2 is the only other BCHA computing resource 240 / 250 that meets the I / O sensor input requirement when CR-4 fails for the M:N working configuration. Therefore, as in Figure 6B1-6B6 In the example embodiment described in , CR-2 is excluded from the reallocation target pool based on processor / load requirements, where the computing resources 240 / 250 cannot execute more than three BCHA applications at a given time. However, in this example, the BCHA application IO requirements coordinated with App_6 have an application priority of 3, while App_4 has an application priority of 6. BCHA applications can also be marked as "critical" or "non-critical", which is a key parameter in determining whether a BCHA application 268 can be temporarily / indefinitely paused to create processor load availability and accommodate reallocation elements. Figure 6B7 , App_4 is temporarily paused, which creates processor load availability to accommodate the redeployment of the failed App_6.

[0191] Once the reallocated element has been redeployed to the selected target and is active, the BCHA controller 215 performs a repair status determination to verify that the BCHA system availability requirements are maintained even though the BCHA reallocated element has been redeployed and is active. Figure 5B2) is green, then the BCHA system objectives, (1) maintain system operation, (1A) use only existing BCHA system components to facilitate resource failure reallocation; and (1B) maintain BCHA system high availability requirements, have all been met. If the repair operation status is not green, the BCHA system may be implemented only (1) if the status is red or (1) and (1A) if the status is orange or yellow. In any case, if the repair operation status is not green, the BCHA control module may need to request BCHA supplemental / additional resources to perform a transition back to the green operation state, where (1), (1A) and (1B) are all met.

[0192] exist Figure 6B8 In the process, the BCHA control module 215 determines whether each application execution has the required high availability by repairing the status by analyzing the high availability requirements of the specific BCHA application and adding the availability characteristics of each computing resource - the computing resource executing the active / inactive instance of the specific BCHA application. In the example shown, APP_1 has a high availability requirement set to 0.999999; and App-1 is executed on two discrete BCHA computing resources 240 / 250, specifically CR-1 and CR-2. Therefore, despite the failure of computing resource CR-4 and redeploying the reallocated elements using only the existing computing resources 240 / 250 selected from the M:N working configuration, the BCHA system 200 still meets the App_1 high availability requirements. The BCHA control module 215 iteratively checks the high availability requirements of each BCHA application 268 (in Fig. 6A -6B for the example for App_1-App7). If the verification is negative - for example App_5's high availability requirement is 0.99999, then redeploy to CR-3, which has a high availability characteristic of 0.9999. Due to the failure of CR-4, the App_5 high availability requirement of 0.99999 is no longer in the green state. When CR-4 is in the "online" state, CR-4's high availability characteristic of 0.99999 is sufficient to meet App_5's high availability requirement. However, the resource fault detection repair state determination indicates that BCHA system objectives (1) and (1A), 1B have been met because if at least one BCHA application 268 high availability requirement is not met, the BCHA system high availability requirement will also fail.

[0193] It should be understood that the examples used herein are intended to illustrate various features / functionality associated with BCHA system load balancing (both resource failure detection load balancing and active load balancing). The BCHA system may use or implement other methods to calculate high availability requirements / determine high availability compliance. In addition, it should be understood that the addition of BCHA computing resource 240 / 250 high availability characteristics and comparison with BCHA application high availability is merely a non-limiting example of calculating high availability requirements / determining high availability compliance - other BCHA system operating parameter calculations are possible and can be used in coordination with BCHA system components in a manner similar to that described herein to achieve the BCHA system objectives of (1), (1A) and (1B).

[0194] about Figure 6B8 The high availability compliance failure discussed is referenced by Figure 5C Describes examples of failures that have been identified and fixed in BCHA Active Load Balancing. Figure 6B8 In the context of, with Z-degree verification set to 1, prior to the actual failure of CR-4, the BCHA controller 215 will, during execution timeline 699 - State 1 "Green", all BCHA compute resources are online, iterate through each of the simulated failures CR-1, CR-2, CR-3, CR-4, and CR-5. After simulating resource failure detection reallocation for CR-1, CR-2, CR-3, and since App_5 high availability requirement is not met given the loss of CR-4's 0.99999 high availability characteristic, the BCHA controller 215 will simulate the failure of CR-4 and identify the yellow repair action state. Based on Figure 5C In step 595, the BCHA control module develops an M:N working configuration validation report and in this example will identify high availability requirement non-compliance for App_5 (as well as any other non-compliance issues for other BCHA applications based on the iterative BCHA computing resource failure simulation). In addition to generating the report, the BCHA control module may also generate requests to other BCHA computing resources to fix any high availability requirement non-compliance and / or M:N working configuration non-compliance. Such fixes will involve a transition plan to transition from the M:N+R working configuration back to a viable green state M:N working configuration in which all high availability requirements are met.

[0195] Fig. 7AA flow chart is shown that illustrates aspects of how the BCHA control module 215 transitions from a non-green repair operation state to a green repair operation state based on (a) not enough reallocation potential targets to generate a control module for a feasible reallocation pool; or (b) a request for supplemental / additional computing resources 240 / 250 developed by a result report generated by a Z-degree HA-M:N verification load=balance to achieve working configuration verification. In step 700, the BCHA control module 215 identifies the non-green repair operation state and determines the minimum BCHA computing resource capabilities / characteristics to transition the repair operation state back to a green state and achieve an M:N working configuration that also meets the BCHA system 200 BCHA application 268 high availability requirements. In some cases, the BCHA system may perform automatic repair to obtain appropriate BCHA computing resources 240 / 250.

[0196] Depending on the implementation, the minimum BCHA computing resource capabilities / characteristics for transitioning to green state operation can be derived from a validation report generated by Z-degree active load balancing, or include supplemental / additional resource requests generated during resource failure detection load balancing. In some implementations, in step 706, the BCHA control module 215 includes supplemental / additional BCHA computing resource request information, which is included and does not necessarily need to facilitate the transition to green state operation, but the supplemental / additional BCHA computing resource request information can help provide a more powerful M:N working configuration. The supplemental / additional BCHA computing resource request information can be generated and derived from a computing resource failure simulation performed during Z-degree real-time load balancing / M:N working configuration verification. In step 709, the computing resource requests can be combined into a single request, or a request for a minimum computing resource request for facilitating green state transition can be issued separately from the supplemental / additional BCHA computing resource request. In step 715, the BCHA delegation module 210 and the BCHA control module 215 work together to provide any requested BCHA hardware resource starting point provided in step 712 to the online BCHA computing resources 240 / 250. In step 718, the BCHA control module 215 redeploys the appropriate BCHA applications 268 and corresponding BCHA work items 270 to facilitate the transition back to the green state. The BCHA control module determines whether any supplemental / additional BCHAs beyond the minimum requested resources are also provided in step 721, which can be used for additional system utilization or to operate as a more robust M:N working configuration. In step 724, the BCHA control module instantiates BCHA applications to facilitate the more robust M:N working configuration. In step 727, the BCHA control module performs a post-transition operational state verification and loops back to step 700 if any issues are identified. In step 730, the BCHA control module 215 transitions to monitoring BCHA system health / operational data and performing active load balancing.

[0197] Figure 7B The operational diagram shown in illustrates a requested fully provisioned BCHA computing resource 240 / 250 as CR-6735. In this example, the BCHA control module 215 identifies a reallocated element capability / feature requirement involving I / O connections of App_6 that were previously executed on the failed CR-4. In contrast to the example above in 6B8, where CR-2 satisfied the reallocated element capability / feature requirement, in this example only the failed CR-4 is satisfied. Therefore, as part of the resource failure detection load balancing initiated by the BCHA control module 215, the BCHA control module 215 identifies that the current M:N working configuration cannot be complied with and immediately issues a request for supplemental / additional computing resources 240 / 250 that meet the requirements.

[0198] exist Figure 7B In the example, based on active load balancing, the BCHA control module 215 also requests supplementary / additional computing resources to ensure a robust green state, M:N working configuration. Specifically, performing Z=1 degree active load balancing, the BCHA control module 215 identifies an opportunity to promote a more robust green state, and the operation requests a BCHA computing resource with a 0.99999 high availability characteristic, so that App_1, App_2, and App_3 will have a feasible failover target, and if the fully loaded CR-1 fails, then App_3 (also with a 0.99999 application availability requirement) should require computing resources. Figure 7C Shown corresponding to Figure 7B Operational diagram of the deployment of additional CR-6B CHA computing resources.

[0199] In some embodiments, the BCHA control module 215 can use aspects of the reliability monitor metrics to facilitate system load balancing. For example, the reliability engine module can use capabilities, characteristics as reallocation constraints (e.g., OS requirements for specific BC applications, application elements, and / or work item types) to:

[0200] (i) Determine the amount of resources required to run all applications.

[0201] (ii) Determine the required system availability for various applications with different OS requirements. This can be calculated for the entire process or for process segments such as cells, trains and equipment.

[0202] (iii) Determine which applications are critical to the process or running the plant. If a critical application stops and is not restarted on a backup resource, the safety system can terminate the process to bring the plant to a safe state.

[0203] (iv) Determine the criticality required for each BC application.

[0204] (v) Determine what the application constraints are (e.g., two control applications may need to run on the same resource).

[0205] These are some examples / different load balancing / availability management metrics that the reliability engine can monitor. By dynamically coordinating compute resource / application / work item management in conjunction with the high availability controller, these modules help ensure efficient and effective system operating parameters and help achieve the target availability metrics for the system.

[0206] Based on one or more of the above determinations, the BCHA control 120 working in conjunction with the reliability monitor 115 can calculate the availability of the system and facilitate load balancing optimization. For example, in the event of a machine failure or resource-constrained state, the high availability controller 120 / reliability monitor 115 can temporarily or shut down non-critical or least important applications (e.g., optimization control applications) so that available computing power can be used to run critical control applications. The high availability controller 120 / reliability monitor 115 can quickly implement this failover without triggering process termination / safety systems. As another example, the high availability controller 120 / reliability monitor 115 can use available or regained computing resources / availability (or additional / supplemental provided resources (e.g., once the machine is back online) to reallocate moves and restart critical applications taking into account potential actions (e.g., shutdown actions) for safety systems. In some embodiments, the reliability monitor can also distribute BC application instance work items across multiple BC resources to manage resource loading.

[0207] In some embodiments, various system metrics of the BCHA system 200 may be calculated in real time. These system metrics may indicate the reliability and / or availability of the BCHA system 200. In some embodiments, the BCHA system 200 metrics may also be transmitted to a user (e.g., to a client device, a human-computer interface). Examples of BCHA system 200 metrics include, but are not limited to:

[0208] (a) The amount of hardware and resources necessary to run all applications at the desired or required availability.

[0209] (b) The number of machines required to run the application beyond a specified critical point.

[0210] (c) High Availability Number (HAN), key performance indicators (KPIs) representing the overall availability of the system, and BCHA system operational metrics, including:

[0211] i. The actual availability of the BCHA system 200 based on the currently available BCHA computing resources 240 / 250 and active BCHA applications 268 .

[0212] ii. The number of failed BCHA computing resources 240 / 250.

[0213] iii. The number of BCHA applications 268 running and their criticality and / or priority.

[0214] iv. The number of inactive BCHA applications 268 and their criticality and / or priority.

[0215] v. Loss of revenue due to inactivity of non-critical BCHA applications 268.

[0216] vi. The number of additional BCHA computing resources 240 / 250 to be provisioned to run each BCHA application 268 .

[0217] vii. If BCHA computing resources 240 / 250 are added or removed from the pool of available BCHA computing resources 240 / 250, the reliability and availability of the overall BCHA system 200 is changed.

[0218] Computer systematization

[0219] The BCHA system components may include a physical machine or physical computer hardware ("computer system"), wherein a set of instructions for causing the computer system to perform any one or more of the methods discussed herein will now be discussed. Software or firmware used in the BCHA system that facilitates the features and / or functions discussed in the figures and described herein may be stored on a machine-readable storage medium and may be executed by one or more general or special purpose programmable microprocessors.

[0220] The computer system may include a processor, a main memory, a non-volatile memory, and an interface device. For simplicity, various common components (e.g., cache memory) are omitted. The computer system is intended to illustrate a hardware device on which any components and methods described in this specification may be implemented. The computer system may be of any applicable known or convenient type. The components of the computer system may be coupled together via a bus or via some other known or convenient device.

[0221] The processor can be, for example, a conventional microprocessor, such as an Intel Pentium microprocessor or a Motorolapower PC microprocessor, a single-core processor, or any multi-core processor. Those skilled in the relevant art will recognize that the term "machine-readable (storage) medium" or "computer-readable (storage) medium" includes any type of device that can be accessed by a processor.

[0222] The memory is coupled to the processor via, for example, a bus. As an example and not limitation, the memory may include random access memory (RAM), such as dynamic RAM (DRAM) and static RAM (SRAM). The memory may be local, remote or distributed.

[0223] The bus also couples the processor to nonvolatile memory and drive units. Nonvolatile memory is typically a magnetic floppy or hard disk, a magneto-optical disk, an optical disk, a read-only memory (ROM) such as a CD-ROM, EPROM, or EEPROM, a magnetic or optical card, or other forms of storage of large amounts of data. During the execution of software in the computer system, some of this data is typically written to the memory by a direct memory access process. Nonvolatile storage can be local, remote, or distributed. Nonvolatile memory is optional because a system can be created using all applicable data available in the memory. A typical computer system typically includes at least a processor, a memory, and a device (e.g., a bus) that couples the memory to the processor.

[0224] Software is usually stored in non-volatile memory and / or drive unit. In fact, for large programs, it may not even be possible to store the entire program in memory. However, it should be understood that for the running software, if necessary, it is moved to a computer-readable location suitable for processing, and for the purpose of illustration, this location is referred to as memory in this article. Even when the software is moved to the memory for execution, the processor will generally utilize hardware registers to store values ​​associated with the software and local cache. Ideally, this can speed up execution. As used herein, when a software program is referred to as "implemented in a computer-readable medium", it is assumed that the software program is stored in any known or convenient location (from non-volatile memory to hardware registers). When at least one value associated with the program is stored in a processor-readable register, the processor is considered to be "configured to execute the program."

[0225] The bus also couples the processor to a network interface device. The interface may include one or more of a modem or a network interface. It is understood that a modem or a network interface may be considered to be part of a computer system. The interface may include an analog modem, an isdn modem, a cable modem, a token ring interface, a satellite transmission interface (e.g., "direct PC"), or other interfaces for coupling a computer system to other computer systems. The interface may include one or more input and / or output devices. As an example and not limitation, an I / O device may include a keyboard, a mouse or other indicating device, a disk drive, a printer, a scanner, and other input and / or output devices including a display device. As an example and not limitation, a display device may include a cathode ray tube (CRT), a liquid crystal display (LCD), or some other applicable known or convenient display device. For simplicity, it is assumed that the controller of any device not described herein may reside in the interface.

[0226] In operation, a computer system may be controlled by operating system software, which may include a file management system, such as a disk operating system. An example of operating system software with associated file management system software is Microsoft Corporation, known as A family of operating systems and their associated file management systems. Another example of operating system software and its associated file management system software is the Linux operating system and its associated file management system. The file management system is typically stored in a non-volatile memory and / or drive unit and causes the processor to perform various actions required for the operating system to input and output data and store data in memory, including storing files on the non-volatile memory and / or drive unit.

[0227] Some portions of the detailed description may be presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the art of data processing to most effectively convey the substance of their work to others skilled in the art. An algorithm is generally considered to be a self-consistent sequence of operations leading to a desired result. An operation is one that requires physical manipulation of physical quantities. Typically, although not necessarily, these quantities take the form of electrical or magnetic signals that can be stored, transferred, combined, compared, and otherwise manipulated. At times, primarily for common reasons, it has proven convenient to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc.

[0228] It should be remembered, however, that all of these and similar terms are associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless otherwise clearly indicated from the following discussion, it should be understood that throughout this specification, discussions utilizing terms such as "processing" or "computing" or "calculating" or "determining" or "displaying" refer to the actions and processes of a computer system or similar electronic computing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system's memories or registers or other such information storage, transmission or display devices.

[0229] The algorithms and displays presented herein are not inherently related to any particular computer or other device. Various general purpose systems may be used with programs according to the teachings herein, or it may prove convenient to construct more specialized devices to perform the methods of some embodiments. The structures required for various of these systems will be apparent from the following description. In addition, these techniques are not described with reference to any particular programming language, and therefore various embodiments may be implemented using various programming languages.

[0230] In some embodiments, the machine may be connected (e.g., using a network) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client user machine in server-client user network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.

[0231] The machine may be a server computer, a client computer, a personal computer (PC), a tablet, a laptop, a set-top box (STB), a personal digital assistant (PDA), a cellular phone, an iPhone, a Blackberry, a processor, a phone, a network appliance, a network router, a switch or a bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by the machine.

[0232] Although the machine-readable medium or machine-readable storage medium is shown as a single medium in the exemplary embodiments, the terms "machine-readable medium" and "machine-readable storage medium" should be considered to include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) storing one or more sets of instructions. The terms "machine-readable medium" and "machine-readable storage medium" should also be considered to include any medium that can store, encode, or carry a set of instructions for execution by a machine and cause the machine to perform one or more methods of the disclosed techniques and innovations.

[0233] Typically, the routines executed to implement the embodiments of the present disclosure may be implemented as part of an operating system or a specific application, component, program, object, module, or sequence of instructions referred to as a “computer program.” A computer program typically includes one or more instructions that are set at different times in various memories and storage devices in a computer, and when read and executed by one or more processing units or processors in a computer, causes the computer to perform operations to perform elements related to aspects of the present disclosure.

[0234] Furthermore, although the embodiments have been described in the context of fully functioning computers and computer systems, those skilled in the art will appreciate that the various embodiments can be distributed as program products in various forms and that the disclosure applies regardless of the specific type of machine or computer-readable medium used to actually effect the distribution.

[0235] Other examples of machine-readable storage media, machine-readable media, or computer-readable (storage) media include, but are not limited to, recordable-type media such as volatile and non-volatile memory devices, floppy disks and other removable disks, hard drives, optical disks (e.g., compact disk read-only memory (CD ROM), digital versatile disks (DVD), etc.), etc., and transmission-type media such as digital and analog communications links.

[0236] Unless the context clearly requires, throughout the specification and claims, the words "include", "comprising", etc. should be interpreted in an inclusive sense, rather than an exclusive or exhaustive sense; that is, in the sense of "including but not limited to". As used herein, the terms "connected", "coupled" or any variation thereof mean any direct or indirect connection or coupling between two or more elements; the coupling of the connection between the elements may be physical, logical, or a combination thereof. In addition, when used in this application, the words "here", "above", "below" and words of similar meanings shall refer to the entirety of this application rather than to any particular part of this application. Where the context permits, the words in the above-mentioned specific embodiments using the singular or plural may also include the plural or singular, respectively. The word "or" with reference to a list of two or more items covers all the following interpretations of the word: any item in the list, all items in the list, and any combination of items in the list.

[0237] The above detailed description of the embodiment of the present disclosure is not intended to be exhaustive or to limit the teaching to the precise form disclosed above. Although the specific embodiment and example of the present disclosure are described above for illustrative purposes, various equivalent modifications can be performed within the scope of the present disclosure as will be appreciated by those skilled in the relevant art. For example, although processes or blocks are presented in a given order, alternative embodiments can perform routines with steps, or adopt a system with blocks in different orders, and some processes or blocks can be deleted, moved, added, subdivided, combined and / or modified to provide alternatives or sub-combinations. Each of these processes or blocks can be implemented in various different ways. Moreover, although processes or blocks are sometimes shown as serial executions, these processes or blocks can be alternatively executed in parallel, or can be executed at different times. In addition, any specific numbers mentioned herein are only examples: alternative implementations can adopt different values ​​or scopes.

[0238] The teachings of the present disclosure provided herein can be applied to other systems, not necessarily the system described above.The elements and acts of the various embodiments described above can be combined to provide further embodiments.

[0239] Any patents and applications mentioned above and other references, including any references that may be listed in the accompanying documents, are incorporated herein by reference. If necessary, aspects of the present disclosure can be modified to employ the systems, functions, and concepts of the various references above to provide further embodiments of the present disclosure.

[0240] Based on the above detailed description, these and other changes can be made to the present disclosure. Although the above description describes certain embodiments of the present disclosure, and describes the expected best mode, no matter how detailed the above text is, the teaching can be practiced in a variety of ways. The details of the system can be very different in terms of its implementation details, while still being included in the subject matter disclosed herein. As described above, the specific terms used when describing certain features or aspects of the present disclosure should not be considered as implying that the terms are redefined herein to be limited to any specific characteristics, features or aspects of the present disclosure associated with the terms. Generally, the terms used in the following claims should not be interpreted as limiting the present disclosure to the specific embodiments disclosed in the specification, unless the above-mentioned specific implementation section explicitly defines these terms. Therefore, the actual scope of the present disclosure includes not only the disclosed embodiments, but also all equivalent ways of practicing or realizing the present disclosure under the claims.

[0241] From the foregoing it will be appreciated that specific embodiments of the disclosed technology have been described herein for purposes of illustration, but that various modifications may be made without deviating from the spirit and scope of the embodiments.

Claims

1. A system for dynamically load-balancing at least one redistributed element across a set of computing resources, facilitating at least one aspect of an industrial execution process structured in an M:N working configuration, comprising: The system is configured as follows: accessing operational data, capabilities, or characteristics associated with the M:N working configuration from a data store M:N working configuration component, wherein the data store is a central data store or a distributed data store that is independent of local storage at and accessible to respective computing resources within the set of computing resources; identifying a load-balancing opportunity to trigger reallocation of at least one reallocated element to a reallocation target selected from a pool of reallocation targets defined by remaining M computing resource components associated with the M:N computing resource work configuration; selecting at least one reallocation element for redeploying the at least one reallocation target selected from the reallocation target pool; redeploying the at least one reallocation element to the at least one selected reallocation target; determining that redeployment of the at least one reallocation element to the at least one selected reallocation target is a feasible redeployment; as well as An industrial execution process is performed at the selected reallocation target using the at least one reallocation element.

2. The system for dynamically load-balancing at least one redistributed element of claim 1, further comprising: When the load-balancing opportunity involves resource failure detection load balancing, redeployment is facilitated.

3. The system of claim 2, wherein the at least one reallocation element is associated with a failed M:N working configuration component or computing resource.

4. The system of claim 3, wherein the at least one reassigned element is an application executing on the failed M:N working configuration component or computing resource.

5. The system of claim 3, wherein the at least one reallocated element comprises an application and a corresponding work item executing on the failed M:N working configuration component or computing resource.

6. The system of claim 3, wherein operational data, capabilities, or characteristics associated with the at least one reallocation element are compared with operational data, capabilities, and characteristics associated with a reallocation target pool component or computing resource.

7. The system of claim 3, wherein the at least one reallocation element is associated with an active M:N working configuration component.

8. The system of claim 1, further comprising: A repair operation status determination is performed to determine a feasible redeployment that maintains the integrity of the M:N working configuration.

9. The system of claim 1, further comprising: Maintaining M:N working configuration with high availability requirement.

10. The system of claim 1, wherein the M:N working configuration integrity is maintained and at least one M:N working configuration component application or work item is suspended to maintain the M:N working configuration integrity.

11. The system of claim 1 , further comprising: performing a repair operation status determination to determine said feasible redeployment; as well as It was determined that the M:N working configuration integrity has not been maintained.

12. The system of claim 9, further comprising generating a supplemental M:N working configuration component request indicating minimum supplemental component requirements needed to transition back to a viable M:N working configuration.

13. The system for dynamically load-balancing at least one redistributed element of claim 1, further comprising: Redeployment is facilitated when the load-balancing opportunity involves component failure simulation verification.

14. The system of claim 13, further comprising: For each component in the M:N working configuration, iteratively simulate the failure of the M:N working configuration component.

15. The system of claim 14, further comprising: Perform Z-verification degree computing resource failure simulation, where Z is greater than or equal to 1; as well as Verify that the M:N working configuration with supplementary M:N working configuration resources is robust.

16. The system of claim 14, further comprising: Generate a robust M:N working configuration fix to supplement the M:N working configuration components or computing resource requests to facilitate the transition to a robust M:N working configuration.

17. The system of claim 3, further comprising: The reallocated elements and corresponding application or work item operation data stored in the data service module are activated upon or near a computing resource failure.

18. A method for dynamically load-balancing at least one reallocation element across a set of computing resources that facilitates at least one aspect of an industrial execution process structured in an M:N working configuration, comprising: accessing operational data, capabilities, or characteristics associated with the M:N working configuration from a data store M:N working configuration component, wherein the data store is a central data store or a distributed data store that is independent of local storage at and accessible to respective computing resources within the set of computing resources; identifying a load-balancing opportunity to trigger reallocation of at least one reallocated element to a reallocation target selected from a pool of reallocation targets defined by remaining M computing resource components associated with the M:N computing resource working configuration; selecting at least one reallocation element for redeploying at least one reallocation target selected from the reallocation target pool; redeploying the at least one reallocation element to the at least one selected reallocation target; determining that redeployment of the at least one reallocation element to the at least one selected reallocation target is a feasible redeployment; as well as An industrial execution process is performed at the selected reallocation target using the at least one reallocation element.

19. The method for dynamically load-balancing at least one reallocated element of claim 18, further comprising: When the load-balancing opportunity involves resource failure detection load balancing, redeployment is facilitated.

20. The method of claim 19, wherein the at least one reallocation element is associated with a failed M:N working configuration component or computing resource.

21. The method of claim 20, wherein the at least one reallocated element is an application executing on the failed M:N working configuration component or computing resource.

22. The method of claim 20, wherein the at least one reallocated element comprises an application and corresponding work item executing on the failed M:N working configuration component or computing resource.

23. The method of claim 20, wherein operational data, capabilities, or characteristics associated with the at least one reallocation element are compared with operational data, capabilities, and characteristics associated with a reallocation target pool component or computing resource.

24. The method of claim 20, wherein the at least one reallocation element is associated with an active M:N working configuration component.

25. The method of claim 18, further comprising: A repair operation status determination is performed to determine a feasible redeployment that maintains the integrity of the M:N working configuration.

26. The method of claim 18, further comprising: Maintaining M:N working configuration with high availability requirement.

27. The method of claim 18, wherein the M:N working configuration integrity is maintained and at least one M:N working configuration component application or work item is suspended to maintain the M:N working configuration integrity.

28. The method of claim 18, further comprising: performing a repair operation status determination to determine said feasible redeployment; as well as It was determined that the M:N working configuration integrity has not been maintained.

29. The method of claim 26, further comprising generating a supplemental M:N working configuration component request indicating minimum supplemental component requirements needed to transition back to a viable M:N working configuration.

30. The method for dynamically load-balancing at least one reallocated element of claim 18, further comprising: Redeployment is facilitated when the load-balancing opportunity involves component failure simulation verification.

31. The method of claim 30, further comprising: For each component in the M:N working configuration, iteratively simulate the failure of the M:N working configuration component.

32. The method of claim 31 , further comprising: Perform Z-verification degree computing resource failure simulation, where Z is greater than or equal to 1; as well as Verify that the M:N working configuration with supplementary M:N working configuration resources is robust.

33. The method of claim 31 , further comprising: Generate a robust M:N working configuration fix to supplement the M:N working configuration components or computing resource requests to facilitate the transition to a robust M:N working configuration.

34. The method of claim 20, further comprising: The reallocated elements and corresponding application or work item operation data stored in the data service module are activated upon or near a computing resource failure.

35. A non-transitory computer readable medium storing sequences of computer executable instructions for dynamically load-balancing at least one redistributed element across a set of computing resources that facilitates at least one aspect of an industrial execution process configured in an M:N working configuration, the sequences of computer executable instructions comprising instructions that instruct at least one processor to: accessing operational data, capabilities, or characteristics associated with the M:N working configuration from a data store M:N working configuration component, wherein the data store is a central data store or a distributed data store that is independent of local storage at and accessible to respective computing resources within the set of computing resources; identifying a load-balancing opportunity to trigger reallocation of at least one reallocated element to a reallocation target selected from a pool of reallocation targets defined by remaining M computing resource components associated with the M:N computing resource working configuration; selecting at least one reallocation element for redeploying the at least one reallocation target selected from the reallocation target pool; redeploying the at least one reallocation element to the at least one selected reallocation target; determining that redeployment of the at least one reallocation element to the at least one selected reallocation target is a feasible redeployment; as well as An industrial execution process is performed at the selected reallocation target using the at least one reallocation element.

Images