Model Event Triggering for Non-Contiguous Block Execution
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional methods for specifying causal relationships between the dynamics of a model and the execution of model components in block diagram modeling environments, such as Simulink, are limited, restricting conditional execution to subsystems, requiring graphical connections, and not naturally mapping to advanced software or operating system constructs, making it difficult to configure and execute non-contiguous blocks or handle exceptions effectively.
Innovation Solution
The introduction of model events that allow for specifying and configuring causal relationships between the dynamics of a model and the execution of components, enabling execution of isolated or non-contiguous components based on event occurrences without graphical indicators, and allowing for exception handling through explicit and implicit events.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If conventional methods are used to specify causal relationships between model dynamics and component execution, then execution can be controlled within subsystems, but the scope is restricted to contiguous blocks only
Solution Approach 1:
The patent segments the model execution control into independent event-triggered components. Instead of requiring subsystem containment, individual blocks can be independently triggered by events, allowing non-contiguous blocks to be grouped logically without physical contiguity in the model diagram.
Solution Approach 2:
The patent introduces an event mechanism as an intermediary between model dynamics and component execution. Events act as mediators that can trigger arbitrary sets of blocks regardless of their spatial arrangement or subsystem membership, eliminating the need for graphical connections while maintaining causal relationships.
2Loss of information
If graphical connections are used to indicate causality between blocks, then causal relationships are explicit, but the diagram becomes cluttered
Solution Approach 1:
The patent extracts the causal relationship indication from graphical connections in the block diagram. Causal relationships are represented through event definitions and trigger associations rather than visual lines, removing clutter while preserving the essential information about which blocks respond to which events.
Solution Approach 2:
The patent moves causal relationship representation from the spatial dimension (graphical connections in 2D block diagram) to a logical dimension (event-triggered execution rules). This dimensional shift allows causal relationships to be defined through configuration rather than visualization, eliminating diagram clutter.
3Ease of operation
If conventional subsystem mechanisms are used for conditional execution, then execution control is provided, but mapping to advanced software constructs is difficult
Solution Approach 1:
The patent creates a universal event mechanism that can map to multiple advanced software constructs including exceptions, tasks, and initialization routines. The event system serves multiple functions: it can represent exceptional conditions, periodic tasks, startup initialization, and conditional triggers, providing a unified framework that adapts to different software paradigms.
Data Source
AI summary
A method of specifying and configuring a causal relationship between the dynamics of a graphical model and the execution of components of the model is disclosed. Model component execution is tied to the occurrence of model events. Model events are first defined in the modeling environment. The occurrence of conditions in the model specified in the definition of the event causes the event to be “posted”. Model components that have been associated with the occurrence of the event “receive” the notice of the posting of the event and then execute. Random components within a subsystem may be designated to execute upon the occurrence of an event, as may non-contiguous components within a model. The association between model events and component execution may be specified without drawing graphical indicators connecting components in the view of the model.