Conditional Trigger-Point Mechanism for Diagnostic Model Visibility

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Diagnostic model elements in technical computing environments often introduce cognitive noise by being visible during model execution, making it difficult for users to focus on core model elements unless verifying functionality, leading to clutter and increased processing requirements.

Innovation Solution

Implementing a conditional trigger-point mechanism that obscures diagnostic model elements until a user-defined condition is met, allowing users to selectively view diagnostic elements and reduce visual noise, thereby improving model clarity and optimizing processing by omitting unnecessary elements from execution and code generation.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If diagnostic model elements are always visible during model execution, then users can continuously verify model functionality, but cognitive noise increases and model clarity decreases

Engineering Contradiction:

Improvemodel functionality verificationVSAvoidcognitive noise

Core Design Contradiction:

ReliabilityVSObject-affected harmful factors

Solution Approach 1:

The patent applies dynamics by making the visibility of diagnostic model elements conditional rather than static. The diagnostic elements are dynamically shown or hidden based on whether the model execution has reached a trigger point, allowing the interface to adapt its state based on execution progress

Inventive Principle:

Principle #15Dynamics

Solution Approach 2:

The patent applies local quality by differentiating the treatment of model elements based on their function. Core model elements remain visible throughout execution, while diagnostic model elements are selectively hidden or shown based on whether a trigger point is reached, allowing different visibility qualities for different parts of the model

Inventive Principle:

Principle #3Local quality

2Reliability

If diagnostic model elements are included in code generation, then complete functionality is preserved, but processing and storage resources are wasted on unnecessary elements

Engineering Contradiction:

Improvecomplete functionalityVSAvoidprocessing and storage resources

Core Design Contradiction:

ReliabilityVSLoss of energy

Solution Approach 1:

The patent applies extraction by separating diagnostic model elements from core model elements in the code generation process. When a trigger point is not reached, diagnostic elements are extracted and omitted from the generated code, while core elements are retained, allowing the system to generate minimal viable code that preserves essential functionality without including unnecessary diagnostic components

Inventive Principle:

Principle #2Taking out (Extraction)

Data Source

PatentUS10460047B1Tentative model components

Publication Date: 2019.10.29 MATHWORKS INC

AI summary

A method may include causing a model, including a set of core model elements and a set of diagnostic model elements, to be executed. The set of diagnostic model elements may be associated with a conditional trigger-point. The conditional trigger-point may be associated with a condition of the model for triggering the conditional trigger-point. The method may include determining that the condition of the model has been satisfied. The method may include causing the set of diagnostic model elements to be displayed via a user interface based on determining that the condition of the model has been satisfied. The set of diagnostic model elements may not have been displayed, during execution of the model, prior to determining that the condition of the model has been satisfied.