Module Class Versioning for Phased Plant Control Upgrades
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current process plant configurations require a one-to-one mapping between module classes and instances, leading to challenges when upgrading hardware, as all instances must be updated simultaneously, which is resource-intensive and can cause version control issues and potential malfunctions.
Innovation Solution
A module-based system that allows for the generation of a second version of a module class based on modifications to the first version, enabling selective upgrade of process control elements with new module instances while ignoring non-upgraded elements, allowing phased roll-out and tracking of module instances with a configuration record.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a one-to-one mapping is maintained between module class and instances, then version control is simplified, but all instances must be updated simultaneously which increases resource requirements and can cause malfunctions
Solution Approach 1:
The patent segments the update process by introducing version identifiers and selective instantiation. Module instances are divided into groups based on their version compatibility, allowing some instances to be updated while others remain on the original version. This segmentation enables phased rollouts without requiring simultaneous updates of all instances.
Solution Approach 2:
The system dynamically manages the mapping between module classes and instances by allowing a single module class to support multiple versions. The configuration database dynamically tracks which instances are associated with which versions, enabling flexible, staged updates rather than rigid simultaneous updates.
2Stability of the object's composition
If all module instances are updated simultaneously, then consistency across the system is maintained, but the upgrade process becomes resource-intensive and risky
Solution Approach 1:
The patent implements preliminary actions by creating a second version of the module class before fully deploying it to all instances. Configuration records are prepared in advance with version identifiers, and a roll-out mechanism is established that can progressively instantiate new versions. This preliminary setup allows for controlled, staged updates rather than forced simultaneous updates.
Solution Approach 2:
The system changes the parameter of version compatibility by allowing module classes to have multiple version identifiers. Instances can be selectively associated with different versions based on readiness, hardware compatibility, or testing requirements. This parameter change enables progressive updates while maintaining system stability.
3Quantity of substance
If hardware upgrades are performed in phases, then resource requirements are reduced, but the one-to-one mapping between module class and instances is broken
Solution Approach 1:
The patent makes the module class universal by allowing it to serve multiple versions simultaneously. A single module class can have associated configuration records for both the original version and the second version, enabling it to support phased hardware upgrades. This multi-functionality eliminates the need for separate module classes for different hardware generations.
Solution Approach 2:
The configuration database acts as an intermediary that manages the relationship between module classes and instances across different versions. It tracks version identifiers and manages instantiation selectively, simplifying the complexity of phased upgrades by providing a centralized coordination mechanism rather than requiring complex point-to-point management.
4Adaptability or versatility
If a new module class is created for upgraded hardware, then compatibility with new hardware is achieved, but all existing instances must be migrated which increases risk of malfunctions
Solution Approach 1:
The patent creates a copy of the original module class with version identifiers marked as the second version. This copy contains the necessary modifications for new hardware compatibility while the original remains unchanged for existing instances. The copying approach allows new hardware support without forcing migration of all instances, reducing migration risk.
Solution Approach 2:
The system provides beforehand cushioning by maintaining both the original module class and the second version simultaneously. Existing instances continue to operate with the original version, providing a safety buffer. The new version is instantiated selectively for upgraded hardware, allowing testing and rollback capabilities before full deployment.
Data Source
AI summary
Module-based systems and methods are described for controlled roll-out of module classes for configuring a process plant. In various aspects the module-based systems and methods generate a second version of a module class based on a modification to a first version of the module class, where the module class is associated with one or more module instances that are each associated with a process control element of the process plant. The module-based systems and methods execute a roll-out instruction to update an upgraded process control element, where the upgraded process control element is associated with a new module instance based on the second version of the module class. The roll-out instruction is also designed to ignore or skip a non-upgraded process control element, where the non-upgraded process control element remains associated with a previous module instance based on the first version of the module class.