Field Device Control Across Dual Runtime Environments
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing FDT frame applications are limited by their defined operating capabilities, preventing them from implementing advanced field device management features, especially those supported by newer FDT specifications, due to outdated technology and lack of HTML user interface capabilities, making it difficult for older systems to benefit from improved functionalities without costly upgrades.
Innovation Solution
A system that utilizes a device type manager (DTM) to extend field device management capabilities beyond the defined limits of an FDT frame application by employing a dual runtime environment approach, where components are configured to operate within both an older CLR version (e.g., CLR 2) and a newer version (e.g., CLR 4), enabling HTML user interface controls and other advanced features not supported by earlier specifications.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If FDT frame application uses older CLR version (e.g., CLR 2) to maintain compatibility with existing systems, then system stability and compatibility are preserved, but advanced features like HTML user interface capabilities and newer FDT specification support are lost
Solution Approach 1:
The system is divided into two separate runtime environment components: an older CLR version (e.g., CLR 2) for maintaining compatibility with existing FDT frame applications, and a newer CLR version (e.g., CLR 4) for enabling advanced features. This segmentation allows each component to operate independently with its required capabilities without forcing a complete system upgrade.
Solution Approach 2:
A runtime environment component acts as an intermediary layer between the older FDT frame application and the newer FDT specification requirements. This intermediary enables the application to access advanced features (HTML capabilities, newer specification support) through the newer CLR while maintaining its original compatibility layer, effectively mediating between old and new requirements.
2Adaptability or versatility
If FDT frame application is upgraded to newer CLR version (e.g., CLR 4) to access advanced features, then HTML user interface capabilities and newer specification support are enabled, but system complexity and upgrade costs increase
Solution Approach 1:
Instead of upgrading the entire FDT frame application to the newer CLR version, the system segments the runtime environment into two versions. The application itself remains unchanged and compatible with the older CLR, while only the runtime environment component is enhanced to include the newer CLR version for accessing advanced features when needed.
Solution Approach 2:
The system applies partial action by implementing the newer CLR version only where needed for advanced features, rather than upgrading the entire system. This allows selective activation of HTML capabilities and newer specification support only when required, avoiding unnecessary complexity in parts of the system that don't need these features.
3Adaptability or versatility
If FDT frame application implements newer FDT specification capabilities, then field device management functionality is enhanced, but resource consumption and processing requirements increase
Solution Approach 1:
The newer FDT specification capabilities and HTML user interface features are implemented as optional, on-demand components rather than mandatory system-wide changes. The runtime environment provides these enhanced capabilities only when specifically invoked, allowing the system to maintain lower resource consumption for basic operations while enabling advanced features when needed.
Solution Approach 2:
The runtime environment is designed to be dynamic, allowing it to switch between older and newer CLR versions based on the specific operational requirements. This dynamic approach enables the system to consume computational resources efficiently by using the lighter older version for routine tasks and only activating the resource-intensive newer version when advanced field device management capabilities are actually required.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
The invention enables a device type manager (DTM) to implement through a field device tool (FDT) frame application, field device management capabilities that are outside the defined operating capabilities of the FDT frame application. The enables controlling a field device, through a device type manager (DTM) configured to control a field device based on control instructions received from a field device tool (FDT) frame application. The FDT frame application and the DTM and /or a DTM wrapper within the DTM may be implemented based on a first runtime environment and a first set of specifications that defines a first set of operating capabilities for the FDT frame application. The DTM wrapper may be configured to communicate with the FDT frame application based on one or more messaging protocols defined by the first set of specifications and further to communicate through inter-process communication, with (i) a DTM framework controller configured to implement the communication and control instructions that enable the DTM to communicate with or control the field device, wherein the DTM framework controller is configured for implementation based on a second runtime environment that is different from the first runtime environment, and (ii) a DTM user interface controller configured to implement one or more user interface controls for controlling the field device.