Graphical Program with Physical Simulation and Data Flow Portions
Various embodiments of systems and methods are described in which system simulation techniques are combined with graphical programming techniques in a common environment. For example, various embodiments of the methods comprise displaying a graphical data flow diagram connected to a system diagram, e.g., where the graphical data flow diagram and the system diagram are displayed together in a compound diagram. In the displayed compound diagram, the graphical data flow diagram may be connected to the system diagram, e.g., by a line or wire. In one embodiment the wire may visually indicate that the graphical data flow diagram is executable to produce a value that is provided as an input signal for a simulation performed based on the system diagram. In another embodiment the wire may visually indicate that the graphical data flow diagram receives an output value from the system simulation as input.
This application is a continuation of Ser. No. 11/550,431 titled “System Simulation and Graphical Data Flow Programming in a Common Environment Using Wire Data Flow” and filed Oct. 18, 2006, whose inventor was Alain G. Moriat and which is hereby incorporated by reference in its entirety as though fully and completely set forth herein.
FIELD OF THE INVENTIONThe present invention relates to the field of graphical data flow programming. The present invention also relates to the field of system simulation, e.g., simulation of a system such as a circuit or other physical system. More particularly, the invention relates to a method for creating a diagram including a graphical data flow diagram portion and a system diagram portion, where the graphical data flow portion is executable to produce an input signal for a simulation performed based on the system diagram and/or where the graphical data flow portion receives an output value from the simulation as input.
DESCRIPTION OF THE RELATED ARTThe present invention relates to the field of graphical data flow programming. Traditionally, high level text-based programming languages have been used by programmers in writing application programs. Many different high level text-based programming languages exist, including BASIC, C, Java, FORTRAN, Pascal, COBOL, ADA, APL, etc. Programs written in these high level text-based languages are translated to the machine language level by translators known as compilers or interpreters. The high level text-based programming languages in this level, as well as the assembly language level, are referred to herein as text-based programming environments.
Increasingly, computers are required to be used and programmed by those who are not highly trained in computer programming techniques. When traditional text-based programming environments are used, the user's programming skills and ability to interact with the computer system often become a limiting factor in the achievement of optimal utilization of the computer system.
There are numerous subtle complexities which a user must master before he can efficiently program a computer system in a text-based environment. The task of programming a computer system to model or implement a process often is further complicated by the fact that a sequence of mathematical formulas, steps or other procedures customarily used to conceptually model a process often does not closely correspond to the traditional text-based programming techniques used to program a computer system to model such a process. In other words, the requirement that a user program in a text-based programming environment places a level of abstraction between the user's conceptualization of the solution and the implementation of a method that accomplishes this solution in a computer program. Thus, a user often must substantially master different skills in order to both conceptualize a problem or process and then to program a computer to implement a solution to the problem or process. Since a user often is not fully proficient in techniques for programming a computer system in a text-based environment to implement his solution, the efficiency with which the computer system can be utilized often is reduced.
To overcome the above shortcomings, various graphical programming environments now exist which allow a user to construct a graphical program or graphical diagram, also referred to as a block diagram. U.S. Pat. Nos. 4,901,221; 4,914,568; 5,291,587; 5,301,301; and 5,301,336; among others, to Kodosky et al disclose a graphical programming environment which enables a user to easily and intuitively create a graphical program. Graphical programming environments such as that disclosed in Kodosky et al can be considered a higher and more intuitive way in which to interact with a computer. A graphically based programming environment can be represented at a level above text-based high level programming languages such as C, Basic, Java, etc.
A user may assemble a graphical program by selecting various blocks or icons which represent desired functionality, and then connecting the blocks or icons together to create the graphical program. Thus the block diagram may include a plurality of interconnected blocks such that the diagram created graphically displays a procedure or method for accomplishing a certain result, such as manipulating one or more input values and/or producing one or more output values. In response to the user constructing a block diagram or graphical program using the block diagram editor, data structures and/or program instructions may be automatically constructed which characterize an execution procedure that corresponds to the displayed procedure. The graphical program may be compiled or interpreted by a computer.
A graphical program may have a graphical user interface. For example, in creating a graphical program, a user may create a front panel or user interface panel. The front panel may include various graphical user interface elements or front panel objects, such as user interface controls and/or indicators, that represent or display the respective input and output that will be used by the graphical program, and may include other icons which represent devices being controlled.
Thus, graphical programming has become a powerful tool available to programmers. Graphical programming environments such as the National Instruments LabVIEW product have become very popular. Tools such as LabVIEW have greatly increased the productivity of programmers, and increasing numbers of programmers are using graphical programming environments to develop their software applications. In particular, graphical programming tools are being used for applications such as test and measurement, data acquisition, process control, man machine interface (MMI), supervisory control and data acquisition (SCADA) applications, modeling, image processing/machine vision applications, and motion control, among others.
The blocks in the block diagram of a graphical program may be connected by lines or wires representing one or more of data flow, control flow, and/or execution flow. A graphical program in which the blocks are connected primarily according to a data flow representation is referred to as a graphical data flow program. The block diagram for a graphical data flow program is also referred to as a graphical data flow diagram. Connections (e.g., lines or wires) between blocks in a graphical data flow diagram visually indicate that data produced by one block is used by another block. For example, a graphical data flow diagram may include a first block connected by a wire to a second block, where the wire visually indicates that output data produced by the first block is passed as input data to the second block.
The present invention also relates to the field of system simulation. Simulation of a system may be implemented using software, hardware, or a combination of both. Creating a system simulation typically involves creating a model of the system, where the model represents the system or represents certain aspects of the system. For a given system, the system may be modeled in any number of different ways. Thus, the type of model that is created may depend on the particular aspects of the system that the modeler is interested in or the particular purpose of performing the simulation.
Creating a model of a system generally involves simplifying or approximating certain aspects of the system. For some systems or problems, a simple, abstracted model may serve to solve the problem at hand quite well, whereas for other systems or problems, a more complex model representing many details of the actual system may be desirable.
There are many reasons why it may be necessary or desirable to simulate a system. One common situation where simulation is useful is when the real system has not yet been created. In this instance, the system may be simulated in order to test design variations and predict whether the planned system will operate as desired.
Any of various types of systems may be simulated. In general, a system model may model physical, mechanical, electrical, chemical, thermodynamic, and/or other types of behavior of the system under simulation. As a few illustrative examples, simulation may be performed for systems such as an electronic circuit or other electronic system, an engine or engine component, an object in motion, a chemical reaction, a petroleum refining process, a room maintained at a setpoint temperature, a system of liquids flowing among different tanks, etc.
SUMMARYVarious embodiments of systems and methods are described in which system simulation techniques are combined with graphical programming techniques in a common environment. For example, various embodiments of the methods comprise displaying a graphical data flow diagram connected to a system diagram, e.g., where the graphical data flow diagram and the system diagram are displayed together in a common diagram (also referred to herein as a “compound diagram”). In the displayed compound diagram, the graphical data flow diagram may be connected to the system diagram, e.g., by a line or wire. In one embodiment the wire may visually indicate that the graphical data flow diagram is executable to produce a value that is provided as an input signal for a simulation performed based on the system diagram. In another embodiment the wire may visually indicate that the graphical data flow diagram receives an output value from the system simulation as input.
A better understanding of the present invention can be obtained when the following detailed description of the preferred embodiment is considered in conjunction with the following drawings, in which:
While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and are herein described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present invention as defined by the appended claims.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Incorporation by ReferenceThe following references are hereby incorporated by reference in their entirety as though fully and completely set forth herein:
U.S. Pat. No. 5,481,741 titled “Method and Apparatus for Providing Attribute Nodes in a Graphical Data Flow Environment”.
U.S. Pat. No. 6,173,438 titled “Embedded Graphical Programming System” filed Aug. 18, 1997.
U.S. Pat. No. 6,219,628 titled “System and Method for Configuring an Instrument to Perform Measurement Functions Utilizing Conversion of Graphical Programs into Hardware Implementations,” filed Aug. 18, 1997.
U.S. Pat. No. 7,210,117, published as U.S. Patent Application Publication No. 20010020291 (Ser. No. 09/745,023) titled “System and Method for Programmatically Generating a Graphical Program in Response to Program Information,” filed Dec. 20, 2000.
U.S. Pat. No. 7,076,411, filed as U.S. patent application Ser. No. 10/046,861 titled, “System and Method for Performing a Hardware in the Loop Simulation Using a Plurality of Graphical Programs that Share a Single Graphical User Interface,” filed Jan. 15, 2002.
U.S. patent application Ser. No. 10/892,829 titled, “A Graphical Program Which Executes a Timed Loop,” filed Jul. 16, 2004.
U.S. patent application Ser. No. 11/203,816 titled, “Combination Structure Nodes for a Graphical Program,” filed Aug. 15, 2005.
U.S. patent application Ser. No. 11/356,711 titled, “Solver for Simulating a System in Real Time on a Programmable Hardware Element,” filed Feb. 17, 2006.
TermsThe following is a glossary of terms used in the present application:
Memory Medium—Any of various types of memory devices or storage devices. The term “memory medium” is intended to include an installation medium, e.g., a CD-ROM, floppy disks 104, or tape device; a computer system memory or random access memory such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; or a non-volatile memory such as a magnetic media, e.g., a hard drive, or optical storage. The memory medium may comprise other types of memory as well, or combinations thereof. In addition, the memory medium may be located in a first computer in which the programs are executed, or may be located in a second different computer which connects to the first computer over a network, such as the Internet. In the latter instance, the second computer may provide program instructions to the first computer for execution. The term “memory medium” may include two or more memory mediums which may reside in different locations, e.g., in different computers that are connected over a network.
Carrier Medium—a memory medium as described above, as well as signals such as electrical, electromagnetic, or digital signals, conveyed via a communication medium such as a bus, network and/or a wireless link.
Medium—includes one or more of a memory medium, carrier medium, and/or programmable hardware element; encompasses various types of mediums that can either store program instructions/data structures or can be configured with a hardware configuration program. For example, a medium that is “configured to perform a function or implement a software object” may be 1) a memory medium or carrier medium that stores program instructions, such that the program instructions are executable by a processor to perform the function or implement the software object; 2) a medium carrying signals that are involved with performing the function or implementing the software object; and/or 3) a programmable hardware element configured with a hardware configuration program to perform the function or implement the software object.
Program—the term “program” is intended to have the full breadth of its ordinary meaning. The term “program” includes 1) a software program which may be stored in a memory and is executable by a processor or 2) a hardware configuration program useable for configuring a programmable hardware element.
Software Program—the term “software program” is intended to have the full breadth of its ordinary meaning, and includes any type of program instructions, code, script and/or data, or combinations thereof, that may be stored in a memory medium and executed by a processor. Exemplary software programs include programs written in text-based programming languages, such as C, C++, Pascal, Fortran, Cobol, Java, assembly language, etc.; graphical programs (programs written in graphical programming languages); assembly language programs; programs that have been compiled to machine language; scripts; and other types of executable software. A software program may comprise two or more software programs that interoperate in some manner.
Hardware Configuration Program—a program, e.g., a bit file, that can be used to program or configure a programmable hardware element.
Graphical Program—A program comprising a plurality of interconnected blocks or icons, wherein the plurality of interconnected blocks or icons visually indicate functionality of the program.
The following provides examples of various aspects of graphical programs. The following examples and discussion are not intended to limit the above definition of graphical program, but rather provide examples of what the term “graphical program” encompasses:
The blocks in a graphical program may be connected in one or more of a data flow, control flow, and/or execution flow format. The blocks may also be connected in a “signal flow” format, which is a subset of data flow.
Exemplary graphical program development environments which may be used to create graphical programs include LabVIEW, DasyLab, DiaDem and Matrixx/SystemBuild from National Instruments, Simulink from the Math Works, VEE from Agilent, WiT from Coreco, Vision Program Manager from PPT Vision, SoftWIRE from Measurement Computing, Sanscript from Northwoods Software, Khoros from Khoral Research, SnapMaster from HEM Data, VisSim from Visual Solutions, ObjectBench by SES (Scientific and Engineering Software), and VisiDAQ from Advantech, among others.
The term “graphical program” includes models or block diagrams created in graphical modeling environments, wherein the model or block diagram comprises interconnected blocks or icons that visually indicate operation of the model or block diagram; exemplary graphical modeling environments include Simulink, SystemBuild, VisSim, Hypersignal Block Diagram, etc.
A graphical program may be represented in the memory of the computer system as data structures and/or program instructions. The graphical program, e.g., these data structures and/or program instructions, may be compiled or interpreted to produce machine language that accomplishes the desired method or process as shown in the graphical program.
Input data to a graphical program may be received from any of various sources, such as from a device, unit under test, a process being measured or controlled, another computer program, a database, or from a file. Also, a user may input data to a graphical program or virtual instrument using a graphical user interface, e.g., a front panel.
A graphical program may optionally have a GUI associated with the graphical program. In this case, the plurality of interconnected blocks are often referred to as the block diagram portion of the graphical program.
Block—In the context of a graphical program, an element that may be included in a graphical program. A block may have an associated icon that represents the block in the graphical program, as well as underlying code or data that implements functionality of the block. Exemplary blocks include function blocks, sub-program blocks, terminal blocks, structure blocks, etc. Blocks may be connected together in a graphical program by connection icons or wires.
The blocks in a graphical program may also be referred to as graphical program nodes or simply nodes (not to be confused with the nodes that connect components in a circuit diagram).
Graphical Data Flow Program (or Graphical Data Flow Diagram)—A graphical program or diagram comprising a plurality of interconnected blocks, wherein at least a subset of the connections among the blocks visually indicate that data produced by one block is used by another block. A LabVIEW VI is one example of a graphical data flow program.
Graphical User Interface—this term is intended to have the full breadth of its ordinary meaning. The term “Graphical User Interface” is often abbreviated to “GUI”. A GUI may comprise only one or more input GUI elements, only one or more output GUI elements, or both input and output GUI elements.
The following provides examples of various aspects of GUIs. The following examples and discussion are not intended to limit the ordinary meaning of GUI, but rather provide examples of what the term “graphical user interface” encompasses:
A GUI may comprise a single window having one or more GUI Elements, or may comprise a plurality of individual GUI Elements (or individual windows each having one or more GUI Elements), wherein the individual GUI Elements or windows may optionally be tiled together.
A GUI may be associated with a graphical program. In this instance, various mechanisms may be used to connect GUI Elements in the GUI with blocks in the graphical program. For example, when Input Controls and Output Indicators are created in the GUI, corresponding blocks (e.g., terminals) may be automatically created in the graphical program or block diagram. Alternatively, the user can place terminal blocks in the block diagram which may cause the display of corresponding GUI Elements front panel objects in the GUI, either at edit time or later at run time. As another example, the GUI may comprise GUI Elements embedded in the block diagram portion of the graphical program.
Front Panel—A Graphical User Interface that includes input controls and output indicators, and which enables a user to interactively control or manipulate the input being provided to a program, and view output of the program, while the program is executing.
A front panel is a type of GUI. A front panel may be associated with a graphical program as described above.
In an instrumentation application, the front panel can be analogized to the front panel of an instrument. In an industrial automation application the front panel can be analogized to the MMI (Man Machine Interface) of a device. The user may adjust the controls on the front panel to affect the input and view the output on the respective indicators.
Graphical User Interface Element—an element of a graphical user interface, such as for providing input or displaying output. Exemplary graphical user interface elements comprise input controls and output indicators
Input Control—a graphical user interface element for providing user input to a program. Exemplary input controls comprise dials, knobs, sliders, input text boxes, etc.
Output Indicator—a graphical user interface element for displaying output from a program. Exemplary output indicators include charts, graphs, gauges, output text boxes, numeric displays, etc. An output indicator is sometimes referred to as an “output control”.
Computer System—any of various types of computing or processing systems, including a personal computer system (PC), mainframe computer system, workstation, network appliance, Internet appliance, personal digital assistant (PDA), television system, grid computing system, or other device or combinations of devices. In general, the term “computer system” can be broadly defined to encompass any device (or combination of devices) having at least one processor that executes instructions from a memory medium.
Measurement Device—includes instruments, data acquisition devices, smart sensors, and any of various types of devices that are operable to acquire and/or store data. A measurement device may also optionally be further operable to analyze or process the acquired or stored data. Examples of a measurement device include an instrument, such as a traditional stand-alone “box” instrument, a computer-based instrument (instrument on a card) or external instrument, a data acquisition card, a device external to a computer that operates similarly to a data acquisition card, a smart sensor, one or more DAQ or measurement cards or modules in a chassis, an image acquisition device, such as an image acquisition (or machine vision) card (also called a video capture board) or smart camera, a motion control device, a robot having machine vision, and other similar types of devices. Exemplary “stand-alone” instruments include oscilloscopes, multimeters, signal analyzers, arbitrary waveform generators, spectroscopes, and similar measurement, test, or automation instruments.
A measurement device may be further operable to perform control functions, e.g., in response to analysis of the acquired or stored data. For example, the measurement device may send a control signal to an external system, such as a motion control system or to a sensor, in response to particular data. A measurement device may also be operable to perform automation functions, i.e., may receive and analyze data, and issue automation control signals in response.
Referring now to
The graphical data flow diagram may comprise a plurality of interconnected blocks that visually indicate a process, e.g., an algorithm or function. The graphical data flow diagram may be executable to perform the process, e.g., after being compiled or interpreted into executable program instructions. The blocks in the graphical data flow diagram may be interconnected by lines or wires that represent data flow among the blocks. For example, the graphical data flow diagram may include a first block connected by a wire to a second block, where the wire visually indicates that output data produced by execution of the first block is passed as input data to the second block.
The system diagram may comprise a diagram of a system, e.g., a physical system. As one example, the system diagram may comprise a diagram of a circuit, e.g., an analog circuit or other electrical circuit. The system diagram may represent a model of the system and may be used to simulate the system, possibly after first being converted into another format, e.g., one or more data structures or equations describing the system. For example, as described below, in some embodiments the system diagram may be automatically converted into a set of mathematical equations that represent the system, where the mathematical equations are used by a solver to perform a simulation of the system, such as a time domain solver that performs a time domain simulation or a frequency domain solver that performs a frequency domain simulation.
The system diagram may include a plurality of components, e.g., where each component represents a physical component of the system. The system diagram may also include lines or wires that interconnect the components. However, the lines or wires in the system diagram may differ from the lines or wires in the graphical data flow diagram in that the lines or wires in the system diagram do not directly represent data flow among the system components. For example, the lines or wires in the system diagram may represent physical connections or other physical relationships between physical components in the system. For example, in a circuit diagram, a wire (node) may be displayed between a first resistor component and a second resistor component, where the wire represents a physical connection between the resistors.
The system diagram may also differ from the graphical data flow diagram in that the system diagram does not directly represent an executable program process. For example, instead of being compiled or interpreted into executable program instructions, the system diagram may be used by other program logic to perform a simulation of the system, possibly after being converted into data structures or equations that represent the system, as described above.
In the displayed compound diagram, the graphical data flow diagram may be connected to the system diagram, e.g., by a line or wire. In one embodiment the wire may visually indicate that the graphical data flow diagram is executable to produce a value that is provided as an input signal for the simulation performed based on the system diagram. In another embodiment the wire may visually indicate that the graphical data flow diagram receives an output value from the system simulation as input.
In some embodiments the compound diagram may include multiple graphical data flow diagrams. For example, the compound diagram may include a first wire between a first graphical data flow diagram and the system diagram, where the first wire visually indicates that the first graphical data flow diagram is executable to produce a value that is provided as an input signal for the simulation performed based on the system diagram. The compound diagram may also include a second wire between the system diagram and a second graphical data flow diagram, where the second wire visually indicates that the second graphical data flow diagram receives an output value from the system simulation as input.
Also, in some embodiments the compound diagram may include multiple system diagrams. For example, the compound diagram may include a first wire between a first system diagram and the graphical data flow diagram, where the first wire visually indicates that the graphical data flow diagram receives an output value from a first simulation performed on the first system diagram. The compound diagram may also include a second wire between the graphical data flow diagram and a second system diagram, where the second wire visually indicates that the graphical data flow diagram is executable to produce a value that is provided as an input signal for a second simulation performed on the second system diagram.
In some embodiments the software executed by the computer system 82 may also be operable to create the compound diagram, e.g., in response to user input. Exemplary methods for creating the compound diagram are described below.
In some embodiments the software executed by the computer system 82 may also be operable to run the compound diagram. Running the compound diagram may comprise executing the graphical data flow diagram and performing a simulation based on the system diagram. In some embodiments, running the compound diagram may also comprise providing an output value of the graphical data flow diagram as an input signal for the simulation, e.g., in embodiments where the compound diagram includes a connection visually indicating this behavior. In other embodiments, running the compound diagram may also comprise providing a value computed by the simulation as an input value to the graphical data flow diagram, e.g., in embodiments where the compound diagram includes a connection visually indicating this behavior.
The functions described above of creating, displaying, and running a compound diagram that includes a graphical data flow diagram portion connected to a system diagram portion may be implemented by one or more software applications or programs collectively referred to herein as “diagramming software”. In one embodiment the diagramming software may comprise a single software application, e.g., development environment application, operable to create, display, and run the compound diagram. In other embodiments, two or more software applications may operate together to implement one or more of these functions. As one example, the compound diagram may be created and displayed in a first application, and the first application may interface with a second application in order to run the compound diagram, e.g., may interface with a simulation application that performs a simulation on the system diagram and/or may interface with a graphical program runtime engine that executes the graphical data flow diagram. As another example, the graphical data flow diagram may be created in a first application, the system diagram may be created in a second application, and the system diagram may be imported into the first application and displayed together with the graphical data flow diagram in a compound diagram.
Referring again to
It is noted that in some embodiments, the functions described above of creating, displaying, and running a compound diagram may be performed by multiple computer systems or computing devices. For example, in some embodiments the compound diagram may be created and displayed on a first computer system 82A, and may then be transferred to another computer system 82B that runs the compound diagram.
As another example, in some embodiments, multiple computer systems or computing devices may operate in conjunction with each other to run the compound diagram. For example, in one embodiment a first computer system 82A may execute the graphical data flow diagram, and another computer system 82B may perform the simulation based on the system diagram. The computer systems may communicate to exchange data, e.g., to provide data produced by execution of the graphical data flow diagram as an input signal for the simulation and/or to provide a simulation value computed by the simulation as input data to the graphical data flow diagram.
As another example, the computer system 82 may couple to a device that includes programmable hardware in order to run the compound diagram. For example,
In the illustrated embodiment, the computer system 82 includes at least one central processing unit or CPU (processor) 160 which is coupled to a processor or host bus 162. The CPU 160 may be any of various types, including an x86 processor, e.g., a Pentium class, a PowerPC processor, a CPU from the SPARC family of RISC processors, as well as others. A memory medium, typically comprising RAM and referred to as main memory, 166 is coupled to the host bus 162 by means of memory controller 164. The main memory 166 may store diagramming software such as described above with reference to
The host bus 162 may be coupled to an expansion or input/output bus 170 by means of a bus controller 168 or bus bridge logic. The expansion bus 170 may be the PCI (Peripheral Component Interconnect) expansion bus, although other bus types can be used. The expansion bus 170 includes slots for various devices that couple to the computer system 82, such as a GPIB card 122 and a Data Acquisition (DAQ) card 114. In the illustrated embodiment, the computer system 82 further comprises a video display subsystem 180 and hard drive 182 coupled to the expansion bus 170.
In the illustrated embodiment, an FPGA device 200 is also coupled to the computer system 82. As discussed above, in some embodiments the FPGA device 200 may be configured to perform a simulation based on the system diagram portion of a compound diagram. In other embodiments, the FPGA device 200 may not be present (e.g., the simulation may be performed by the diagramming software executing on the computer system 82 or executing on another computer system), or the FPGA device 200 may be coupled to the computer system 82 through techniques other than an expansion bus, or the simulation may be performed on a device other than the FPGA device 200, e.g., a device that includes another type of programmable hardware element.
In other embodiments, one or more instruments such as shown in
The one or more instruments may include a GPIB instrument 112 and associated GPIB interface card 122, a data acquisition board 114 and associated signal conditioning circuitry 124, a VXI instrument 116, a PXI instrument 118, a video device or camera 132 and associated image acquisition (or machine vision) card 134, a motion control device 136 and associated motion control interface card 138, and/or one or more computer based instrument cards 142, among other types of devices.
The GPIB instrument 112 may be coupled to the computer 82 via the GPIB interface card 122 provided by the computer 82. In a similar manner, the video device 132 may be coupled to the computer 82 via the image acquisition card 134, and the motion control device 136 may be coupled to the computer 82 through the motion control interface card 138. The data acquisition board 114 may be coupled to the computer 82, and may interface through signal conditioning circuitry 124 to the UTT. The signal conditioning circuitry 124 may comprise an SCXI (Signal Conditioning eXtensions for Instrumentation) chassis comprising one or more SCXI modules 126.
The GPIB card 122, the image acquisition card 134, the motion control interface card 138, and the DAQ card 114 are typically plugged in to an I/O slot in the computer 82, such as a PCI bus slot, a PC Card slot, or an ISA, EISA or MicroChannel bus slot provided by the computer 82. However, these cards 122, 134, 138 and 114 are shown external to computer 82 for illustrative purposes. These devices may also be connected to the computer 82 through a serial bus or through other means.
The VXI chassis or instrument 116 may be coupled to the computer 82 via a VXI bus, MXI bus, or other serial or parallel bus provided by the computer 82. The computer 82 may include VXI interface logic, such as a VXI, MXI or GPIB interface card (not shown), which interfaces to the VXI chassis 116. The PXI chassis or instrument may be coupled to the computer 82 through the computer's PCI bus.
A serial instrument (not shown) may also be coupled to the computer 82 through a serial port, such as an RS-232 port, USB (Universal Serial bus) or IEEE 1394 or 1394.2 bus, provided by the computer 82. In typical instrumentation control systems an instrument will not be present of each interface type, and in fact many systems may only have one or more instruments of a single interface type, such as only GPIB instruments.
The instruments may be coupled to a unit under test (UUT) or process 150, or may be coupled to receive field signals, typically generated by transducers. The system 100 may be used in a data acquisition and control application, in a test and measurement application, an image processing or machine vision application, a process control application, a man-machine interface application, a simulation application, or a hardware-in-the-loop validation application.
In one embodiment, one or more of the various instruments illustrated in
In various embodiments, the system diagram displayed in the compound diagram may represent any of various kinds of systems. For example, in some embodiments the system diagram may represent a physical system that includes electrical, mechanical, chemical, thermodynamic, or other types of physical components. In particular, in some embodiments the system diagram may represent a physical device. The flowchart of
In 301, the circuit diagram may be created in response to user input, where the circuit diagram represents a circuit to be simulated. For example, in some embodiments the user may arrange icons representing components of the circuit within a window displayed on the display device of the computer system 82 in order to create a visual representation of the circuit. For example, the diagramming software may provide a graphical user interface enabling the user to select from a library of circuit components, such as transistors, resistors, capacitors, inductors, switches, voltage and current sources, etc., and display the selected circuit components in the circuit diagram in response to user input. The graphical user interface may also enable the user to create wires, also referred to as nodes, connecting the various circuit components. Thus, in some embodiments the user may create the circuit diagram in a direct graphical manner, e.g., by directly creating a visual representation of the circuit.
In other embodiments the user may create the circuit diagram in an indirect manner, e.g., by specifying lines of text in a circuit description language, where the lines of text describe the circuit, such as the components in the circuit and how they are connected to each other. The circuit diagram may be automatically generated based on the text describing the circuit.
In yet other embodiments the user may interact with one or more graphical user interface dialogs to select various options indicating desired features of the circuit, and the diagramming software may then automatically create a circuit diagram having the features selected by the user.
In addition to specifying the components of the circuit and the nodes connecting the components together, the user may also specify various properties or parameters of the components. For example, for a resistor component, the user may specify the resistance value. As another example, for a voltage source component, the user may specify the voltage value. The component properties may be specified in various ways, such as by interacting with graphical user interface dialogs for configuring the property values for various circuit components, specifying the property values in a text language, or displaying property value icons representing the property values within the circuit diagram and connecting the property value elements to the respective circuit component icons in the circuit diagram.
In some embodiments, creating the circuit diagram may also comprise specifying an input signal to the circuit diagram. For example, the circuit diagram may represent an analog circuit or other electrical circuit operable that operates with an electrical signal as input. In various embodiments the diagramming software may allow the user to specify the input signal for the circuit diagram in various ways, e.g., by connecting an icon representing the input signal to a component or wire in the circuit diagram or interacting with a graphical user interface dialog to configure the input signal. Also, in some embodiments the input signal may be provided as output from a graphical data flow diagram, as described below with reference to
Referring again to
For example, the user may create the graphical data flow diagram by selecting desired blocks from a palette or menu of available blocks and placing or “dragging and dropping” the selected blocks into the graphical data flow diagram. For example, the blocks included in the graphical data flow diagram may include function blocks (e.g., blocks operable to perform a particular function), sub-program blocks (e.g., blocks that encapsulate another graphical data flow diagram), control blocks (e.g., blocks operable to perform control flow functions such as looping or case selections, also referred to as structure blocks or structure nodes), etc.
The user may also interconnect the blocks in the graphical data flow diagram in a desired fashion, e.g., by creating lines or wires among the blocks. In particular, the user may interconnect the blocks to visually indicate data flow among the blocks. For example, the user may utilize a wiring tool or wiring function provided by the diagramming software to display a wire connecting an output terminal of a first block to an input terminal of a second block, such that the wire visually indicates that the first block produces output data that is passed as input data to the second block.
Thus, the blocks in the graphical data flow diagram may be interconnected in response to user input in order to visually indicate desired functionality of the graphical data flow diagram. For example, the plurality of interconnected blocks may visually indicate a process or function performed by the graphical data flow diagram when the graphical data flow diagram is executed. In various embodiments the user may create a graphical data flow diagram operable to perform any process, function, or algorithm.
The graphical data flow diagram may thus include a plurality of blocks that execute according to data flow semantics during execution of the graphical data flow diagram. For example, blocks in the graphical data flow diagram may obey the following semantic principles: a) The order of execution of the blocks is not explicitly specified by the user; b) The order of execution of the blocks is implied by data interdependencies; c) A block in the graphical data flow diagram begins execution in response to all of its necessary inputs becoming available.
In some embodiments, the graphical data flow diagram may also include one or more blocks that do not completely follow data flow semantic principles, e.g., blocks providing functionality or capabilities that do not adhere to data driven execution. These blocks may be referred to as “control flow blocks,” “structure blocks,” or “structure nodes”. For example, these blocks may support various types of control flow (or execution flow), as opposed to data flow, such as iteration, looping, conditional branching, sequencing, event-driven execution, and other non-data flow behavior.
As one example, the LabVIEW graphical programming environment includes a While Loop structure node, a For Loop structure node, a Sequence structure node, and a Case structure node. In the While Loop structure node, graphical code associated with the While Loop structure node repeatedly executes for a plurality of iterations while a condition is true. In the For Loop structure node, graphical code associated with the For Loop structure node executes for a pre-determined number of iterations set by the user. In the Sequence structure node, the user can specify different portions of graphical code to execute according to a desired sequence, without regard to data flow principles. In the Case structure node, different portions of graphical code may execute dependent on a condition.
A graphical code portion, i.e., one or more of the blocks in the graphical data flow diagram, may be associated with a structure node or control flow block, typically in a visual fashion, to indicate that this graphical code portion is executed according to the control flow function performed by the structure node. In other words, execution of the blocks in the graphical code portion associated with the structure node is controlled by the structure node, whereas execution of graphical code that is not associated with the structure node is not controlled by the structure node, but instead follows normal data flow principles.
Execution of the graphical code portion associated with a structure node or control flow block may be controlled in any of various ways, depending on the control flow function performed by the structure node. It is noted that once the execution of the graphical code portion associated with the structure node has begun, the graphical code portion may execute according to data flow principles. For example, in the case of a While Loop structure node, blocks in the graphical code portion associated with the While Loop structure node may execute according to data flow principles during each iteration of the loop. However, the While Loop controls the overall execution of the graphical code portion and causes the iteration to occur, whereas iteration may not normally occur in a data flow program.
It is also noted that various structure nodes or control flow blocks may obey data flow principles at their inputs and outputs. For example, a structure node or control flow block itself may be connected to other blocks in the graphical data flow diagram according to a data flow format. As one example, a function block may be connected to an input terminal of a For Loop structure node, where the function block outputs an integer value used to specify the desired number of iterations for the For Loop. As another example, output data produced by the graphical code portion associated with the For Loop may be passed as input to other blocks in the graphical data flow diagram.
In some embodiments the graphical data flow diagram may also include a user interface portion or front panel portion. Where the graphical data flow diagram includes a user interface portion, the user may assemble the user interface on the display, e.g., by arranging various user interface elements on the display.
Although the creation of the graphical data flow diagram in 303 is described above in terms of the user arranging and interconnecting blocks in the graphical data flow diagram as desired, in other embodiments the graphical data flow diagram may be created in any of various other ways. For example, in some embodiments the user may interact with one or more graphical user interface dialogs to select various options indicating desired execution functionality, and the diagramming software may then automatically generate a graphical data flow diagram operable to perform the functionality selected by the user.
Referring again to
In some embodiments, the user may create the circuit diagram and the graphical data flow diagram using a common development environment application. For example, the development environment application may display a window in which the user creates both the circuit diagram and the graphical data flow diagram, as described above with reference to 301 and 303.
In another embodiment the user may create the circuit diagram and the graphical data flow diagram separately from each other, e.g., in separate windows or possibly using different software applications. In this embodiment the circuit diagram and the graphical data flow diagram are preferably displayed together in the compound diagram after being separately created. For example, after the user has created the circuit diagram and the graphical data flow diagram, the user may then request the circuit diagram to be imported into the graphical data flow diagram so that it is displayed together with the graphical data flow diagram, or vice versa.
As indicated in 307, the method may further comprise displaying a connection between the circuit diagram and the graphical data flow diagram in response to user input. For example, the user may use a wiring tool or wiring function to create a wire, line, or other connection icon connecting the circuit diagram to the graphical data flow diagram. The connection may visually indicate that a first simulation value computed in response to a simulation performed on the circuit diagram is passed as input to the graphical data flow diagram, as described below.
For example, the user may provide user input causing a first wire to be displayed, where the first wire connects a wire (node) in the circuit diagram to an input terminal of a block in the graphical data flow diagram. The first wire may visually indicate that a value associated with the circuit wire (e.g., a voltage value along the circuit wire or other electrical characteristic of the circuit wire) is computed by the simulation and is passed as input to the block in the graphical data flow diagram.
As another example, the user may provide user input causing a first wire to be displayed, where the first wire connects a component icon in the circuit diagram to an input terminal of a block in the graphical data flow diagram. The first wire may visually indicate that a value associated with the component (e.g., an electrical characteristic of the component) is computed by the simulation and is passed as input to the block in the graphical data flow diagram.
As discussed above, the circuit diagram represents a model of the circuit and may be used to perform a simulation of the circuit, e.g., a time domain simulation or other simulation. In 309, the simulation of the circuit is performed. Performing the simulation of the circuit may comprise computing various simulation values that characterize operation of the circuit, such as voltage and current values along the wires in the circuit, or other simulation values that represent electrical characteristics of various components or wires in the circuit. In particular, the simulation may compute the first simulation value, i.e., the simulation value that the connection created in 307 visually indicates as being passed as input to the graphical data flow diagram. For example, where the connection created in 307 connects a wire in the circuit diagram to a block in the graphical data flow diagram, performing the simulation may comprise computing a voltage value for the wire in the circuit diagram.
The method may further comprise executing the graphical data flow diagram, as indicated in 311. The first simulation value computed in the circuit simulation may be passed as input to the graphical data flow diagram. For example, where the connection created in 307 connects a wire in the circuit diagram to an input terminal of a first block in the graphical data flow diagram, a voltage value may for the circuit wire may be computed by the simulation in 309 and passed as input data to the first block in the graphical data flow diagram in 311. Executing the graphical data flow diagram may comprise executing the first block (e.g., executing program instructions corresponding to the first block), where the first block uses the first simulation value computed in the circuit simulation as an input parameter.
In various embodiments the graphical data flow diagram may execute to perform any of various functions, processes, or algorithms, where the first simulation value received from the circuit simulation may be used by the graphical data flow diagram in any of various ways. Examples of several graphical data flow diagrams that use simulation values computed by circuit simulations are described below.
In further embodiments of the method of
As another example, the user may create multiple graphical data flow diagrams and connect each graphical data flow diagram to the circuit diagram such that blocks in each respective graphical data flow diagram receive one or more simulation values computed by the circuit simulation as input parameter values.
In various embodiments, the simulation of the circuit in block 309 of
In 331, the circuit diagram may be automatically analyzed to determine components in the circuit and wires (nodes) connecting the components. For example, the diagramming software may programmatically examine one or more data structures representing the circuit diagram to determine what components are in the circuit, how the components are connected to each other, properties of the components, etc.
In 333, a netlist describing the circuit diagram may be automatically generated. Generating the netlist may comprise generating one or more data structures that characterize the circuit, e.g., where the data structures specify what components are in the circuit, specify the circuit wires that connect the components to each other, specify properties of the components, etc. The one or more data structures representing the netlist may be stored in memory of the computer system 82.
In 335, a set of mathematical equations representing the circuit may be automatically generated, based on the netlist. In 337, the simulation of the circuit may be performed based on the set of equations. For example, in one embodiment the set of equations generated in 335 may represent time domain response behavior of the circuit. Thus, in 337 performing the simulation of the circuit may comprise a solver solving the equations to perform a time domain response simulation of the circuit.
The set of equations generated in 335 may be represented in any of various ways. For example, in one embodiment the netlist may be automatically converted into a set of matrix coefficients, where the matrix coefficients specify the set of equations. The matrix coefficients may be stored as one or more data structures.
As described above, performing the simulation of the circuit may comprise computing various simulation values that characterize operation of the circuit, such as voltage and current values along the wires in the circuit, or other simulation values that represent electrical characteristics of various components or wires in the circuit. In particular, the simulation may compute the first simulation value, i.e., the simulation value that the connection created in 307 visually indicates as being passed as input to the graphical data flow diagram.
As described above, in creating the circuit diagram, the user may also specify an input signal to the circuit. The simulation of the circuit may utilize the input signal in computing the various simulation values. Thus, the simulation of the circuit may depend on both the circuit itself (e.g., the components in the circuit, the properties of the components, and the connections among the components) and the input signal. For example, in a time domain simulation the solver may utilize data representing the input signal as parameters in solving the equations that represent the circuit, and/or the equations may be generated based on the input signal as well as the netlist.
As discussed above, in some embodiments the circuit simulation may be performed on an FPGA device 200 or other programmable hardware device. For example, the FPGA device 200 may be configured to implement a generic time domain solver 206. The computer system 82 may communicate with the FPGA device 200, e.g., to upload the set of matrix coefficients to the FPGA device 200. The generic time domain solver 206 on the FPGA device 200 may perform a time domain response simulation of the circuit based on the matrix coefficients.
In one embodiment where the circuit simulation is performed on the FPGA device 200, the graphical data flow diagram may execute on the computer system 82. The computer system 82 may communicate with the FPGA device 200 to receive the first simulation value computed by the circuit simulation and pass the first simulation value to the graphical data flow diagram. In another embodiment the graphical data flow diagram may also be performed on the FPGA device 200 together with the circuit simulation, e.g., by automatically converting the graphical data flow diagram into a hardware configuration program and configuring the FPGA device 200 with the hardware configuration program.
In another embodiment, the circuit simulation may be performed on the computer system 82, where the graphical data flow diagram is also executed on the computer system 82. In another embodiment the circuit simulation may be performed on a different computer system to which the computer system 82 is coupled via a network.
In an actual display of a compound diagram such as shown in
Thus, when the compound diagram of
In 351, a circuit diagram may be created in response to user input, similarly as described above.
In 353, a graphical data flow diagram in response to user input, similarly as described above.
In 355, the circuit diagram and the graphical data flow diagram may be displayed together within a common diagram, similarly as described above.
In 357, a connection may be displayed between the graphical data flow diagram and the circuit diagram in response to user input, wherein the connection visually indicates that first output data of the graphical data flow diagram is passed as an input signal to the circuit diagram. For example, the user may use a wiring tool or wiring function to create a wire, line, or other connection icon connecting the graphical data flow diagram to the circuit diagram.
For example, the user may provide user input causing a first wire to be displayed, where the first wire connects an output terminal of a block in the graphical data flow diagram to a wire or component in the circuit diagram. The first wire may visually indicate that data produced by the block in the graphical data flow diagram is provided as an input signal to the circuit diagram. For example, the data produced by the block in the graphical data flow diagram may represent voltage or other electrical characteristics of an input signal to the circuit.
In 339, the graphical data flow diagram may be executed. The graphical data flow diagram may execute to produce the first output data. In various embodiments the graphical data flow diagram may be operable to perform any function, process, or algorithm in order to produce output data useable as an input signal to the circuit.
In 361, the simulation of the may be performed circuit. As described above, the simulation of the circuit may depend on both the circuit itself (e.g., the components in the circuit, the properties of the components, and the connections among the components) and the input signal to the circuit. Thus, the simulation of the circuit may compute different simulation values for the circuit, depending on the input signal data received from the graphical data flow diagram.
In further embodiments of the methods described above, a graphical data flow diagram may execute to dynamically change or provide feedback to a circuit under simulation. The compound diagram may be run for a plurality of iterations or for a plurality of time steps. At each iteration or time step, a simulation value for the circuit may be computed by a simulation of the circuit, and the simulation value may be passed to the graphical data flow diagram. The graphical data flow diagram may perform a process or algorithm based on the simulation value and may then dynamically change or provide feedback to the circuit, depending on results of the process or algorithm. Thus, in the next iteration or time step, the behavior of the circuit or the circuit itself may be changed from the previous iteration or time step. Thus, the circuit simulation and the graphical data flow diagram may operate together to form a type of feedback loop in which simulation values computed by the circuit simulation influences execution of the graphical data flow diagram, and the execution of the graphical data flow diagram influences the circuit.
For example, in some embodiments the graphical data flow diagram may be operable to automatically change the topology of the circuit under simulation, e.g., by adding additional components to the circuit, removing components from the circuit, or changing how components in the circuit are connected to each other. For example, the graphical data flow diagram may execute an algorithm based on a voltage value computed by the circuit simulation, where the algorithm determines whether and how the circuit should be changed. As one simple example, depending on results of the algorithm, an additional resistor may be added to the circuit.
As another example, the graphical data flow diagram may be operable to automatically change properties of components in the circuit. For example, the graphical data flow diagram may execute an algorithm based on a voltage value computed by the circuit simulation, where the algorithm determines whether and how properties of components in the circuit should be changed. As one simple example, depending on results of the algorithm, the resistance of a resistor in the circuit may be increased or reduced.
In other embodiments the graphical data flow diagram may be operable to dynamically change an input signal to the circuit under simulation. For example, the graphical data flow diagram may execute an algorithm based on a voltage value computed by the circuit simulation, where the algorithm determines whether and how the input signal should be changed.
In other embodiments the graphical data flow diagram may be operable to dynamically change or provide feedback to the circuit based on information or events other than simulation values computed by the circuit simulation. As one example, the graphical data flow diagram may include a graphical user interface that is displayed on the display of the computer system 82 while the compound diagram is running. The user may be able to interact with the graphical user interface in order to cause the graphical data flow diagram to dynamically change the circuit or change an input signal to the circuit.
In various embodiments, the ability to dynamically change or provide feedback to a circuit under simulation may have a plethora of benefits. For example, the user may interact with a graphical user interface in order to dynamically change the circuit in various ways and observe the effects on the circuit's operation. For example, the graphical data flow diagram may receive various simulation values at each iteration or time step of the circuit simulation and display the simulation values in output indicators on the graphical user interface. The graphical user interface may also include input controls allowing the user to select various options or set properties affecting the circuit. In response to the user interacting with the input controls, the graphical data flow diagram may dynamically change the circuit as described above. Changing the circuit may cause the simulation values displayed in the output indicators to change in subsequent iterations or time steps, thus enabling the user to see the effects of changing the circuit. This may be useful, for example, for instructors demonstrating the effects of various circuit changes to students or for helping circuit developers design a circuit more efficiently.
As other examples, the ability to dynamically change or provide feedback to a circuit under simulation may be useful for applications such as hardware-in-the-loop simulations and rapid control prototyping simulations.
In various embodiments, dynamically changing the circuit simulation or providing feedback from the graphical data flow diagram to the circuit simulation may be implemented in various ways. For example, in some embodiments the graphical data flow diagram may be operable to change the circuit by automatically changing one or more data structures that represent the circuit diagram. In subsequent iterations or time steps, the simulation of the circuit may be performed based on the changed circuit diagram. For example, in response to the change to the circuit diagram, a new netlist describing the changed circuit may be automatically generated, and the netlist may be converted into updated equations or data structures used in the subsequent iterations or time steps of the circuit simulation. In other embodiments the graphical data flow diagram may directly change the netlist describing the circuit instead of changing the circuit diagram.
In some embodiments the circuit diagram may be displayed on a display of the computer system 82 while the compound diagram is running, and the diagramming software may be operable to update the displayed circuit diagram in response to dynamic changes to the circuit diagram. For example, if the graphical data flow diagram executes to add an additional resistor component to the circuit then the diagramming software may automatically display a changed circuit diagram illustrating the additional resistor.
In various embodiments the user may configure the graphical data flow diagram to dynamically change or provide feedback to the circuit under simulation in any of various ways. For example, in some embodiments the user may create a wire or other graphical information connecting the graphical data flow diagram to the circuit diagram, where the wire visually indicates that the graphical data flow diagram provides feedback to or dynamically changes the circuit under simulation. Thus, for example, a compound diagram may display a first connection from the circuit diagram to the graphical data flow diagram, where the first connection visually indicates that a simulation value computed by a simulation of the circuit is passed as input data to the graphical data flow diagram, and the compound diagram may also display a second connection from the graphical data flow diagram to the circuit diagram, where the second connection visually indicates that the graphical data flow diagram dynamically changes or provides feedback to the circuit under simulation.
In other embodiments the graphical data flow diagram may be configured to set a global variable or change data structures representing the circuit under simulation, without necessarily visually displaying a connection indicating feedback from the graphical data flow diagram to the circuit.
In some embodiments, graphical programming blocks may be incorporated within a circuit diagram. For example,
Thus, various embodiments of the methods described above may be employed in order to implement a development environment in which circuit simulation techniques are combined with graphical programming techniques in a common environment.
It is noted that
As described above, in various embodiments, a graphical data flow diagram may be combined with any of various kinds of system diagrams other than circuit diagrams. Thus, methods similar to those described above may be utilized to integrate graphical data flow programming techniques with simulations performed to model any of various kinds of systems, such as mechanical, chemical, or neural systems, to name a few examples. Furthermore, any of various techniques may be used in simulating the systems, such as time domain response simulations techniques, frequency domain response simulation techniques, etc.
It is noted that various embodiments may further include receiving, sending, or storing instructions and/or data implemented in accordance with the foregoing description upon a computer-readable memory medium. Generally speaking, a computer-readable memory medium may include storage media or memory media such as magnetic or optical media, e.g., disk or CD-ROM, volatile or non-volatile media such as RAM (e.g. SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc. for storing program instructions. Such a computer-readable memory medium may store program instructions received from or sent on any transmission media or signals such as electrical, electromagnetic, or digital signals, conveyed via a communication medium such as network and/or a wireless link.
Although the embodiments above have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.
Claims
1. A computer accessible memory medium comprising program instructions executable by a processor to:
- display on a display a first diagram, wherein the first diagram represents a physical system and is executable to simulate the physical system, wherein the first diagram comprises a plurality of components corresponding to components of the physical system, wherein the plurality of components are interconnected by lines, wherein the lines interconnecting the plurality of components in the first diagram comprise lines of a first type, and wherein the lines of the first type represent physical connections among the components in the physical system;
- display on the display a graphical data flow diagram connected to the first diagram, wherein the graphical data flow diagram comprises a plurality of interconnected blocks that visually indicate functionality of the graphical data flow diagram, wherein the blocks in the graphical data flow diagram are interconnected by lines of a second type, and wherein the lines of the second type represent data flow semantics among the blocks in the graphical data flow diagram;
- execute the first diagram to simulate the physical system; and
- execute the graphical data flow diagram, wherein said executing the graphical data flow diagram comprises one or more of: passing a first simulation value computed by the simulation of the physical system as input to the graphical data flow diagram; or producing output data, wherein the output data is provided as an input signal for the simulation of the physical system.
2. The memory medium of claim 1,
- wherein the physical system comprises a mechanical system, wherein the first diagram comprises a diagram of the mechanical system, and wherein said performing the simulation comprises performing a simulation of the mechanical system.
3. The memory medium of claim 1,
- wherein the physical system comprises a chemical system, wherein the first diagram comprises a diagram of the chemical system, and wherein said performing the simulation comprises performing a simulation of the chemical system.
4. The memory medium of claim 1,
- wherein the physical system comprises a hydraulic system, wherein the first diagram comprises a diagram of the hydraulic system, and wherein said performing the simulation comprises performing a simulation of the hydraulic system.
5. The memory medium of claim 1,
- wherein the physical system comprises a thermodynamic system, wherein the first diagram comprises a diagram of the thermodynamic system, and wherein said performing the simulation comprises performing a simulation of the thermodynamic system.
6. The memory medium of claim 1,
- wherein said displaying the graphical data flow diagram connected to the first diagram comprises displaying a first line from the first diagram to a first block in the graphical data flow diagram, wherein the first line visually indicates that the first simulation value computed by the simulation of the physical system is passed as input to the first block in the graphical data flow diagram;
- wherein said passing the first simulation value to the graphical data flow diagram comprises passing the first simulation value to the first block in the graphical data flow diagram.
7. The memory medium of claim 1,
- wherein said displaying the graphical data flow diagram connected to the first diagram comprises displaying a first line from a first block in the graphical data flow diagram to the first diagram, wherein the first line visually indicates that the output data produced by executing the first block in the graphical data flow diagram is provided as the input signal for the simulation of the physical system.
8. The memory medium of claim 1,
- wherein the lines of the first type have a first appearance, and wherein the lines of the second type have a second appearance to visually distinguish the lines of the first type from the lines of the second type.
9. The memory medium of claim 1,
- wherein said executing the graphical data flow diagram further comprises modifying the first diagram.
10. The memory medium of claim 1, wherein the program instructions are further executable to:
- create the circuit diagram in response to user input; and
- create the graphical data flow diagram in response to user input.
11. A computer-implemented, the method comprising:
- displaying on a display a first diagram, wherein the first diagram represents a physical system and is executable to simulate the physical system, wherein the first diagram comprises a plurality of components corresponding to components of the physical system, wherein the plurality of components are interconnected by lines, wherein the lines interconnecting the plurality of components in the first diagram comprise lines of a first type, and wherein the lines of the first type represent physical connections among the components in the physical system;
- displaying on the display a graphical data flow diagram connected to the first diagram, wherein the graphical data flow diagram comprises a plurality of interconnected blocks that visually indicate functionality of the graphical data flow diagram, wherein the blocks in the graphical data flow diagram are interconnected by lines of a second type, and wherein the lines of the second type represent data flow semantics among the blocks in the graphical data flow diagram;
- executing the first diagram to simulate the physical system; and
- executing the graphical data flow diagram, wherein said executing the graphical data flow diagram comprises one or more of: passing a first simulation value computed by the simulation of the physical system as input to the graphical data flow diagram; or producing output data, wherein the output data is provided as an input signal for the simulation of the physical system.
12. The method of claim 11,
- wherein the physical system comprises a mechanical system, wherein the first diagram comprises a diagram of the mechanical system, and wherein said performing the simulation comprises performing a simulation of the mechanical system.
13. The method of claim 11,
- wherein the physical system comprises a chemical system, wherein the first diagram comprises a diagram of the chemical system, and wherein said performing the simulation comprises performing a simulation of the chemical system.
14. The method of claim 11,
- wherein the physical system comprises a hydraulic system, wherein the first diagram comprises a diagram of the hydraulic system, and wherein said performing the simulation comprises performing a simulation of the hydraulic system.
15. The method of claim 11,
- wherein the physical system comprises a thermodynamic system, wherein the first diagram comprises a diagram of the thermodynamic system, and wherein said performing the simulation comprises performing a simulation of the thermodynamic system.
16. The method of claim 11,
- wherein said displaying the graphical data flow diagram connected to the first diagram comprises displaying a first line from the first diagram to a first block in the graphical data flow diagram, wherein the first line visually indicates that the first simulation value computed by the simulation of the physical system is passed as input to the first block in the graphical data flow diagram;
- wherein said passing the first simulation value to the graphical data flow diagram comprises passing the first simulation value to the first block in the graphical data flow diagram.
17. The method of claim 11,
- wherein said displaying the graphical data flow diagram connected to the first diagram comprises displaying a first line from a first block in the graphical data flow diagram to the first diagram, wherein the first line visually indicates that the output data produced by executing the first block in the graphical data flow diagram is provided as the input signal for the simulation of the physical system.
18. The method of claim 11,
- wherein the lines of the first type have a first appearance, and wherein the lines of the second type have a second appearance to visually distinguish the lines of the first type from the lines of the second type.
19. The method of claim 11,
- wherein said executing the graphical data flow diagram further comprises modifying the first diagram.
20. A system, comprising:
- a processor;
- a display coupled to the processor; and
- a memory medium coupled to the processor, wherein the memory medium stores program instructions executable by the processor to: display on the display a first diagram, wherein the first diagram represents a physical system and is executable to simulate the physical system, wherein the first diagram comprises a plurality of components corresponding to components of the physical system, wherein the plurality of components are interconnected by lines, wherein the lines interconnecting the plurality of components in the first diagram comprise lines of a first type, and wherein the lines of the first type represent physical connections among the components in the physical system; display on the display a graphical data flow diagram connected to the first diagram, wherein the graphical data flow diagram comprises a plurality of interconnected blocks that visually indicate functionality of the graphical data flow diagram, wherein the blocks in the graphical data flow diagram are interconnected by lines of a second type, and wherein the lines of the second type represent data flow semantics among the blocks in the graphical data flow diagram; execute the first diagram to simulate the physical system; and execute the graphical data flow diagram, wherein said executing the graphical data flow diagram comprises one or more of: passing a first simulation value computed by the simulation of the physical system as input to the graphical data flow diagram; or producing output data, wherein the output data is provided as an input signal for the simulation of the physical system.
Type: Application
Filed: Jun 16, 2009
Publication Date: Oct 8, 2009
Patent Grant number: 8146050
Inventor: Alain G. Moriat (Copenhagen)
Application Number: 12/485,174
International Classification: G06G 7/48 (20060101); G06F 17/50 (20060101);