HMI Development Tool Using SDK Databinding for Non-Programmers
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing HMI development tools for the automation industry are proprietary, costly, and lack openness and flexibility, making them difficult for non-programmers to use and customize, despite advancements in general-purpose GUI tools like .NET Framework and Java SDK.
Innovation Solution
A system utilizing a general-purpose software development kit with common design time components and customization components, including a screen design surface, databinding facility, automation process object interface, and process object picker, allowing non-programmers to create and customize user interface objects by dragging and dropping data objects onto a screen design surface for binding, thus separating UI aspects from process logic.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If proprietary HMI development tools are used, then ease of operation for non-programmers is improved, but cost increases and openness/flexibility deteriorates
Solution Approach 1:
The system separates the HMI development environment into distinct modules: a proprietary HMI tool providing the development environment, a general-purpose SDK providing runtime environment and base components, and customizable process-specific components. This segmentation allows the tool to maintain ease of use through the proprietary interface while gaining openness and flexibility by integrating with standard SDKs and allowing custom component development.
Solution Approach 2:
The system achieves universality by making the HMI development environment compatible with multiple general-purpose SDKs (such as .NET Framework and Java SDK). The runtime environment can execute HMI applications across different platforms and programming environments, providing multi-functionality that enhances both openness and flexibility while maintaining the user-friendly proprietary development interface.
2Adaptability or versatility
If general-purpose SDKs are used for HMI development, then openness and flexibility are improved, but ease of operation for non-programmers deteriorates
Solution Approach 1:
The proprietary HMI tool acts as an intermediary between the user and the general-purpose SDK. It provides a simplified, visual development environment with drag-and-drop components and automatic code generation, masking the complexity of the underlying SDK. This mediator layer allows non-programmers to leverage the power and flexibility of general-purpose SDKs without needing to understand their complex programming interfaces.
Solution Approach 2:
The system implements self-service through automatic code generation and configuration. When users design HMI applications using the proprietary tool's visual interface, the system automatically generates the necessary code in the target general-purpose SDK language and configures the runtime environment, eliminating the need for users to manually write complex programming code.
3Ease of operation
If proprietary HMI tools with proprietary formats are used, then ease of operation is improved, but device complexity increases due to requiring proprietary runtime environment
Solution Approach 1:
Instead of requiring a unique proprietary runtime environment, the system copies and leverages existing, widely-available general-purpose runtime environments (such as .NET Framework and Java Virtual Machine). The HMI applications are compiled to run on these standard platforms using standard bytecode or intermediate language, eliminating the need for specialized proprietary runtime software and reducing overall system complexity.
Data Source
Figure 1~2
Figure 3
Figure 3a
AI summary
There is described a method and system for developing for an automation process a screen viewable on a target computer that has user interface objects. A development computer has a set of common design time components from a general purpose software development kit that also has a databinding facility and a set of customization components. Those components have an interface that allows access to the available for use automation process data objects and a process object picker that act as a user interface to the databinding facility to allow the browsing of a subset of the available for use data objects and selecting of one or more of the objects in the subset for binding by the databinding facility either to one or more members of the user interface objects or one or more of the user interface objects or a combination of the same.