Graphical Programming Environment Supporting Multiple Models of Computation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current graphical programming systems, such as LabVIEW, are limited by their homogenous data flow model of computation, which restricts the ability to efficiently handle multiple rates of execution, feedback cycles, and dynamic scheduling, making it difficult to develop applications like multi-rate systems and simulations that require different models of computation.
Innovation Solution
A graphical programming environment that allows the creation of heterogeneous systems by supporting multiple models of computation within a single graphical program, enabling the use of different data flow semantics for various portions of the program, such as homogenous and heterogeneous data flow, to accommodate diverse application requirements.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If a homogenous data flow model of computation is used in graphical programming systems, then the system is simpler to implement and operate, but the ability to handle multiple rates of execution and complex simulations is limited
Solution Approach 1:
The programming environment is segmented into different execution contexts (simulation context and real-time context) that can operate independently with different data flow models. This allows the system to maintain simplicity in each individual context while achieving versatility at the system level through context switching and coordination.
Solution Approach 2:
The graphical programming system is designed to support multiple data flow models (homogenous and heterogeneous) within a single unified platform. The system can accommodate different execution rates, feedback cycles, and scheduling requirements through a universal architecture that translates between different computational models.
2Device complexity
If a homogenous data flow model is used, then the programming environment is easier to implement, but it cannot efficiently handle feedback cycles and dynamic scheduling
Solution Approach 1:
The system incorporates dynamic scheduling capabilities that allow execution contexts to switch between different data flow models based on the requirements of the program being executed. This enables efficient handling of feedback cycles and dynamic scheduling without requiring a completely complex implementation architecture.
Solution Approach 2:
A translation layer or intermediary mechanism is introduced that converts between different data flow models (homogenous and heterogeneous) into a unified execution framework. This intermediary handles the complexity of feedback cycles and dynamic scheduling by translating them into standard operations that the execution engine can process efficiently.
3Adaptability or versatility
If multiple models of computation are supported within a single graphical program, then the versatility and adaptability improve, but the device complexity and difficulty of implementation increase
Solution Approach 1:
The programming environment is divided into distinct execution contexts (e.g., simulation context and real-time context) that each operate with a specific data flow model. This segmentation isolates the complexity of different computational models into separate manageable units while maintaining overall system versatility through context coordination.
Solution Approach 2:
The system changes key parameters such as execution rate, data flow semantics, and scheduling policy to accommodate different models of computation. By parameterizing these aspects rather than requiring fundamentally different architectural components, the system achieves versatility while controlling implementation complexity.
4Productivity
If multiple models of computation are integrated, then the ability to develop complex applications improves, but the ease of operation and user friendliness decreases
Solution Approach 1:
Complex applications are segmented into separate execution contexts that can be developed and executed independently. Each context maintains a consistent data flow model that is easy to understand and operate, while the overall system achieves high productivity by coordinating these segmented contexts to handle complex applications.
Solution Approach 2:
An intermediary translation layer is provided that automatically converts between different data flow models and execution contexts. This intermediary handles the operational complexity behind the scenes, allowing users to work with familiar graphical programming interfaces while the system translates between different computational models to enable complex application development.
Data Source
AI summary
System and method for creating a graphical program that uses multiple models of computation (MoC). A first plurality of graphical program elements is assembled in a graphical program in response to first input, where the assembled first plurality of graphical program elements have a first MoC. A structure is displayed in the graphical program indicating use of a second MoC for graphical program elements comprised within the interior of the structure. A second plurality of graphical program elements is assembled within the structure in response to second input, where the assembled second plurality of graphical program elements have the second MoC. The graphical program is executable to perform a function, for example, by executing the assembled first plurality of graphical program elements in accordance with the first model of computation, and executing the assembled second plurality of graphical program elements in accordance with the second model of computation.