Graphical partitioning for parallel execution of executable block diagram models

Background

Various classes of graphical models or graphical programming describe computations that can be performed on application specific computational hardware, such as a computer, microcontroller, field programmable gate array (FPGA), or custom hardware. Graphical models can be complex and computationally intensive. As a result, executing the models in real-time may not be feasible in conventional processing environments using a single processing device, such as a single core.

Brief description of the drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate one or more embodiments of the invention and, together with the description, explain the invention. In the drawings,

FIG. 1 illustrates an exemplary system for practicing embodiments of the invention;

FIG. 2 illustrates an exemplary environment for performing distributed processing;

FIG. 3 illustrates an exemplary model that can be configured for concurrent computing;

FIG. 4 illustrates an exemplary user interface for interacting with model partitions;

FIG. 5 illustrates a model that includes unmapped sub graphs;

FIG. 6 illustrates a user interface for mapping sub graphs to tasks;

FIG. 7 illustrates an alternative implementation of a user interface for performing mapping operations for a graphical model;

FIG. 8 illustrates an exemplary user interface that includes icons for identifying sub graphs or components in a model;

FIG. 9 illustrates a model configured to support drag and drop operations for mapping sub graphs or tasks;

FIGS. 10A and 10B illustrate application program interfaces for mapping sub graphs to tasks;

FIG. 11 illustrates a model having graphical elements that identify communication modes;

FIG. 12A illustrates a model that includes visual affordances for determining a mapping;

FIG. 12B illustrates a model that includes highlighting to identify sub graphs sharing characteristics;

FIG. 13 illustrates techniques for identifying task execution periods;

FIGS. 14A-D illustrate code examples for implementing a model on concurrent computing resources;

FIG. 15 illustrates code for a function that performs dispatch operations;

FIG. 16A illustrates a code example for a deterministic transfer communication between sub graphs;

FIG. 16B illustrates a code example for ensuring data integrity for communications between sub graphs;

FIG. 16C illustrates a code example for ensuring deterministic transfer delay for communications between sub graphs;

FIG. 17A illustrates an exemplary model for generating code;

FIG. 17B illustrates a block that can be inserted into a model to ensure data integrity;

FIG. 18A illustrates a code example for implementing an S function in an embodiment of the invention;

FIG. 18B illustrates an exemplary TLC implementation of an embodiment of the invention;

FIG. 19 illustrates an exemplary model having two task groups and a model that includes an interrupt timer;

FIG. 20A illustrates an exemplary model for a periodic task;

FIG. 20B illustrates an alternative implementation of the model of FIG. 20A;

FIG. 21 illustrates an exemplary data store for use with proxy blocks in an embodiment of the invention;

FIG. 22 illustrates an exemplary embodiment for interacting with target platforms;

FIGS. 23A and 23B illustrate an embodiment that accounts for computational complexity of certain sub graphs in a model;

FIG. 24 illustrates an exemplary architecture for performing computing operations consistent with principles of the invention; and

FIG. 25 illustrates exemplary processing for practicing an embodiment of the invention.

Detailed description

The following detailed description of implementations consistent with principles of the invention refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims and their equivalents.

Overview

Exemplary embodiments partition executable graphical models into units that can be mapped onto parallel processing resources and then concurrently processed. For example, embodiments can identify model components sharing characteristics, such as a sample rate, and may group the components together into units (e.g., sub graphs, sub systems, modules, etc.). These units may be mapped for processing onto a resource (e.g., a core, processor, thread, process, etc.) that can be separate from another processing resource. In addition, the units may further be mapped to be processed in parallel with other units in the model. Concurrent processing of the units may allow a model to be executed in a fraction of the time that it would take if the model were executed on a single processing device using conventional techniques.

Embodiments can allow a user to graphically specify how portions of a model should be partitioned and mapped for concurrent processing. And, embodiments can be configured to programmatically partition and map models on behalf of the user. For example, programmatic partitioning and mapping of models may be particularly beneficial to users when models are large and/or complex.

Embodiments can include user interfaces that allow users to identify how a model is partitioned and mapped, concurrent computing resources for processing respective portions of a model, parameters for code generated from the model, etc. Still further embodiments can provide tools that allow users to verify, validate, test, document, publish, etc., models that interact with concurrent processing resources.

Embodiments allow graphical models, such as executable block diagrams, to be configured as parallel deployment diagrams. Diagrams operating as parallel deployment diagrams may include components, such as:

a mechanism for graphically partitioning a block-diagram into sub graphs that capture potential parallelism in the design without requiring that final deployment hardware for the design be fully known/identified,

a mechanism for graphically expressing actual compute elements present on a concurrent computing platform on which the design will be deployed or targeted, and

a mechanism for mapping sub graphs to the actual compute elements.

Exemplary System

FIG. 1 illustrates an exemplary system 100 for practicing an embodiment. For example, system 100 may be used to design, simulate, test, and/or deploy models that make use of concurrent computing resources. System 100 may include computer 110, input device 125, network 140, and target environment 130. The system in FIG. 1 is illustrative and other embodiments of system 100 can include fewer devices, more devices, and/or devices in configurations that differ from the configuration of FIG. 1.

Computer 110 may include a device that performs processing operations, display operations, communication operations, etc. For example, computer 110 may include logic, such as one or more processing or storage devices, that can be used to perform and/or support processing activities on behalf of a user. Embodiments of computer 110 may include a desktop computer, a laptop computer, a client, a server, a mainframe, a personal digital assistant (PDA), a web-enabled cellular telephone, a smart phone, smart sensor/actuator, or another computation or communication device that executes instructions for performing one or more activities and/or to generate one or more results.

Computer 110 may further perform communication operations by sending data to or receiving data from another device, such as a server (not shown in FIG. 1). Data may refer to any type of machine-readable information having substantially any format that may be adapted for use in one or more networks and/or with one or more devices. Data may include digital information or analog information. Data may further be packetized and/or non-packetized.

An embodiment of computer 110 may include simulation environment 120 and operating system 115. Simulation environment 120 may provide a computing environment that allows users to perform simulation or modeling tasks related to disciplines, such as, but not limited to, mathematics, science, engineering, medicine, business, etc. Simulation environment 120 may support one or more applications that execute instructions to allow a user to construct a model having executable semantics. In an embodiment, simulation environment 120 may execute the model to produce a result.

Models used with exemplary embodiments of the invention may include information in a textual or graphical form. For example, a model may be a textual model or graphical model that can be a time-based model (e.g., differential equation models, difference equation models, discrete-time models, or continuous-time models with or without algebraic constraints, etc.), event-based model, state transition model, data flow model, component diagram, entity flow diagram, equation-based language diagram, etc.

In an embodiment, simulation environment 120 can include a component, such as a software module, that partitions graphical models in a manner that supports concurrently processing the partitions. Simulation environment 120 can further provide user interfaces that facilitate user interactions with respect to graphically partitioning and concurrently executing graphical models.

Operating system 115 may manage hardware and/or software resources associated with computer 110. For example, operating system 115 may manage tasks associated with receiving user inputs, operating computer 110, allocating memory, prioritizing system requests, etc. In an embodiment, operating system 115 may be a virtual operating system. Embodiments of operating system 115 may include Linux, Mac OS, Microsoft Windows, Solaris, UNIX, etc. Operating system 115 may further run on a virtual machine, which can be provided by computer 110.

Computer 110 can further include one or more display devices for displaying information to a user. In an embodiment, the display may include a cathode ray tube (CRT), plasma display device, light emitting diode (LED) display device, liquid crystal display (LCD) device, etc. Embodiments of the display may be configured to receive user inputs (e.g., via a touch sensitive screen) when desired. In an embodiment, the display can provide one or more graphical user interfaces (GUIs) to a user. The GUIs may display a model, inputs for a model (e.g., user specified objectives, constraints, display characteristics, task/sub graph mappings, etc.), model outputs, graphical representations of registers, representations of tasks, representations for concurrent computing resources, etc.

Input device 125 may include logic to receive input from a user. For example, input device 125 may transform a user motion or action into a signal or message that can be interpreted by computer 110. Input device 125 can include, but is not limited to, keyboards, pointing devices, biometric devices, accelerometers, microphones, cameras, haptic devices, etc.

Network 140 may include any network capable of transferring data (e.g., packet data or non-packet data). Implementations of network 140 may include local area networks (LANs), metropolitan area networks (MANs) and/or wide area networks (WANs), such as the Internet, that may operate using substantially any network protocol, such as Internet protocol (IP), asynchronous transfer mode (ATM), synchronous optical network (SONET), user datagram protocol (UDP), IEEE 802.10, etc.

Network 140 may include network devices, such as routers, switches, firewalls, and/or servers (not shown). Network 140 may be a hardwired network using wired conductors and/or optical fibers and/or may be a wireless network using free-space optical, radio frequency (RF), and/or acoustic transmission paths. In an implementation, network 140 may be a substantially open public network, such as the Internet. In another implementation, network 140 may be a more restricted network, such as a corporate virtual network. Implementations of networks and/or devices operating on networks described herein are not limited to any particular data type, protocol, architecture/configuration, etc. For example, in an embodiment, network 140 may be a quantum network that uses quantum-compatible networking protocols.

Target environment 130 may include logic that executes instructions to perform one or more operations. In an embodiment, target environment 130 can include registers for storing information and processing logic adapted to concurrently execute code generated from one or more models. In an embodiment, target environment 130 can include real-time logic for performing processing operations in real-time using two or more processing devices, threads, etc. For example, target environment 130 may include a real-time operating system and hardware that are configured to process received signals or events in real-time or to execute simulations in real-time.

Exemplary embodiment of target environment 130 can include FPGAs, application specific integrated circuits (ASICs), application specific instruction-set processors (ASIPs), digital signal processors (DSPs), graphics processor units (GPUs), programmable logic devices (PLDs), etc. Target environments 130 can further include a single processor that includes two or more types of logic, such as cores. Target environments 130 can be configured to support multi-threaded or multi-process applications using FPGAs, ASICs, ASIPs, DSPs, GPUs, PLDs, cores, etc.

Exemplary Distributed Environment

Distributed implementations may allocate processing activities across two or more cores in a single processing device, allocate processing across multiple processing devices installed within a single enclosure, and/or allocate processing across multiple types of processing logic connected by a network. For example, a distributed environment may make remote concurrent computing resources available to computer 110 to allow simulation environment 120 to parallel process portions of a graphical model.

FIG. 2 illustrates an exemplary system that can be used to practice embodiments of the invention using a distributed computing environment. System 200 may include computer 110, network 140, service provider 240, remote database 250 and cluster 260. The implementation of FIG. 2 is exemplary and other distributed implementations of the invention may include more devices and/or components, fewer devices and/or components, and/or devices/components in configurations that differ from the exemplary configuration of FIG. 2.

Computer 110 and network 140 may be configured as described in connection with FIG. 1. Service provider 240 may include a device that makes a service available to another device. For example, service provider 240 may include an entity that provides one or more services to a destination using a server and/or other devices. Services may include instructions that are executed by a destination to perform an operation. Alternatively, a service may include instructions that are executed on behalf of a destination to perform an operation on the destination's behalf.

Assume, for sake of example, that a service provider operates a web server that provides one or more web-based services to a destination, such as computer 110. The web-based services may allow computer 110 to perform distributed processing on behalf of block diagrams. The web-based services may also allow computer 110 to view results of the concurrent processing via a display device. In one implementation, a customer (user) may receive services on a subscription basis.

A subscription may include substantially any type of arrangement, such as monthly subscription, a per-use fee, a fee based on an amount of information exchanged between service provider 240 and the customer, a fee based on a number of processor cycles used by the customer, a fee based on a number of processors used by the customer, etc.

Remote database 250 may include a device that stores machine-readable information for use by other devices, such as computer 110. In one embodiment, remote database 250 may include a data store, an array or grid of storage devices (e.g., hard disks, optical disks, solid-state storage devices, etc.) for storing information and/or data, e.g., variables, results, models, generated code, specifications, constraints, application program interfaces (APIs), processing configurations, etc. Units of execution 270 may include applications that are running on computer 110, e.g., copies of a technical computing environment.

Cluster 260 may include a group of processing devices, such as units of execution 270A, B, and C, that can be used to perform remote processing (e.g., distributed processing, parallel processing, etc.). Units of execution 270 may include hardware and/or hardware/software based logic that perform processing operations on behalf of a requesting device, such as computer 110. In an embodiment, units of execution 270A, B, and C may each compute a partial result that can be combined into an overall result and/or units of execution 270A, B, and C may each compute independent results. Devices in cluster 260 may be configured to support virtual machines and/or other techniques for making a plurality of processing resources and/or applications available over a network.

Exemplary Model Partitioning Technique

Exemplary embodiments can make use of computational elements, such as processors, cores, etc., to process portions of a model. Embodiments can further use computing tasks (hereinafter tasks), such as operating system threads, fibers, processes, etc., to concurrently process portions of a model. Embodiments can further use methodologies for graphically partitioning a model in a way that supports concurrently processing the model faster than if the entire model were processed using a single computational element or task. For example, a first methodology can separate a model design into components, where the components are coupled together using signal interconnections. Component boundaries can indicate potential points at which the design can be broken into a separate section, or partition. In the first methodology, respective sections may be deployed to different concurrent computing resources.

Still referring to the first methodology, a component can contain a piece of the original block-diagram. This diagram piece can include one or more sub graphs, where each sub graph, in a time-based diagram, is intended to run at a specified sample time or rate. In the first methodology, the block diagram portion within a component may be viewed as being partitioned into sub graphs, where each sub graph is contracted to run at a specific rate. This arrangement may be referred to as rate-grouping sub graphs and the sub graphs may be considered to be rate grouped sub graphs.

Sub graphs within a particular component may be configured to facilitate concurrent execution using concurrent computing resources. For example, if a model includes two components each including a sub graph, the components may be configured for concurrent processing using two cores residing in computer 110. This configuration may allow a model to execute faster than if the entire model were executed using a single core.

A second methodology may include a graphical technique that allows two or more computing elements or tasks to be represented collectively as a task group. In the second methodology, a task group can contain tasks that execute synchronously in time based on a single triggering condition, such as an event, a time, etc. For example, a triggering condition can include an interrupt from a timer running on a multi-core platform, an interrupt from an external source such as an external timer circuit, interrupt from an external physical source such as the detection of rotation of shaft in an automotive system, etc.

A task group further allows specification of task and task group properties useful for scheduling the running of computing resources. For instance, each task may be associated with a priority that allows the scheduler to determine execution order. Tasks can also be associated with policies, such as tie-breaking policies that handle situations where two tasks of identical priority contend for execution. In an embodiment, parameters can be used to specify properties for tasks. For example, two sets of parameters may be used within a task group to specify task properties. Here a first parameter, or a first set of parameters, can apply to an entire task group and a second parameter or set of parameters may apply to individual tasks in the group. Examples of a first parameter can include an interrupt source and a contention policy, and a second parameter can include timing of execution, priority, and core affinity.

FIG. 3 illustrates an exemplary graphical model 300 that can be configured to support concurrent computing capabilities. For example, model 300 may include partitions that can be grouped or assigned to various concurrent computing resources, such as hardware or software units of execution. Model 300 may include user inputs 305, plant section-1 310, plant section-2 315, controller section-1 320, controller section-2 325 and task group-1 330.

Model 300 may be considered to include three primary sections, namely user inputs 305 to plants 310, 315; the plant, which is made up of plants 310 and 315; and the controller, which is made up of controllers 320 and 325. The three sections of model 300 may be allocated to concurrent computing resources to speedup simulation (as compared to simulating on a single resource) during model design or for real-time hardware in the loop (HIL) simulation setup. In model 300, the plant and the controller are broken into two portions, respectively, to further exploit parallelism. For example, the plant is broken into plant section 310 and plant section 315. In embodiments, sections can be referred to as partitions, portions, sub graphs, etc., without departing from the spirit of the invention.

Plants 310 and 315 each contain a continuous-time section and two distinct discrete-time sample time sections (having sample times of 0.01 sec and 0.001 sec). In FIG. 3, these sections form the basis for breaking plants 310 and 315 into 3 different sub graphs. Sections or sub graphs in model 300 may be denoted using icons, such as continuous identifier 335, and sample time identifiers 340, 345, and 350. For example, sample time identifiers can represent a first fast sample time of 0.001 sec (identifier 340), a second fast sample time identifier of 0.001 sec (identifier 345), and a slow sample time identifier of 0.01 sec (identifier 350). Other implementations can use other types of identifiers such as symbols, text, highlighting, shading, fading, etc., for denoting sections of a model.

Continuous component 335 can be used to model the dynamics of the plant as a set of ordinary differential equations. Solving the set of equations numerically may require executing a solver of a certain type. For example, model 300 may use a fixed step or variable step solver. Model 300 may further use solvers that employ Euler's method, Heun's method, Bogacki-Shampine formula, Runge-Kutta formula, Dormand-Prince formula, etc.

Discrete components, such as components 340, 345 and 350, may reside in none, some, or all sections of a model. For example, plants 310 and 315 may share sample times with controllers 320 and 325, such as sample times of 0.01 sec and 0.001 sec. The sample times between plants 310/315 and controller 320/325 may match even though identifiers differ in appearance. For example, plants 310/315 include fast 1 identifier 340 and controllers 320/325 include fast 2 identifier 345 even though both identifiers represent a sample time of 0.001 sec. The different identifiers may be selected to represent distinct concurrent computing resources on which respective portions of model 300 will be run.

Model 300 may include eleven sub graphs (i.e., one for each identifier 335, 340, 345, 350 in each subgraph). In model 300, the sub graphs may be generated based on an assumption that the different sub graphs can be run concurrently. In an embodiment, the assumption may account for communication between the sub graphs within a component while the model executes. For example, an embodiment may assume that communications between sub graphs are protected by rate transition blocks or other mechanisms.

FIG. 3 includes Task Group 330, which can be shown as a legend-like object on a model canvas. Task group 330 can identify a group of tasks used with model 300. For example, task group 330 can include four distinct tasks. The four tasks may be configured to run on a computer having four cores, to run on four units of execution, or to run in another environment that supports four degrees of parallelism.

In task group 330, a first task is marked as corresponding to the continuous-time section of the model and is represented using identifier 335. A task corresponding to identifier 335 and representing the continuous-time section may ultimately contain a numerical solver that solves the underlying differential equations. When an implementation is configured to solve equations in real-time, model 300 may utilize a class of solvers known as fixed step solvers. Fixed step solvers can produce solutions of the set of differential equations at fixed time steps and can be mapped to tasks that have a fixed execution period. In model 300, the fixed step solver has a period of 0.0001 sec and is indicated in parenthesis in task group 330.

In contrast to the continuous task of task group 330, the remaining three tasks are discrete task and are marked as having execution periods of 0.01, 0.001, and 0.001 sec using identifiers 350, 345, and 340, respectively. This nomenclature implies that there are two compute elements that execute concurrently at the same rate of 0.001 sec, namely those associated with identifier 345 and 350.

Exemplary Setup of Computational Elements

Exemplary embodiments may allow users to enter information related to tasks via user interfaces. In an embodiment, a user may select an element of FIG. 3 by double clicking on the element. In response to the selecting operation, a user interface may open and may be displayed to the user via a display device. In another embodiment, a user may make a selection from a drop down menu to access the user interface. In still other embodiments, other techniques may be used to launch and access user interfaces, such as speech, touch sensitive input devices, textual interfaces (e.g., a command line interface), etc.

FIG. 4 illustrates user interface (UI) 400 that allows users to interact with model partitions. UI 400 can include task buttons 405, color field 410, name field 415, period field 420, priority field 425, core affinity field 430, and action buttons 435.

Task buttons 405 allow a user to create or delete tasks. In an embodiment, selecting insert task may insert a row for a task and selecting delete task may delete a row for a task. UI 400 may include an arrangement of information in which each row corresponds to a task, such as a continuous task which is indicated using identifier 335. Tasks can be described using characteristics or parameters, such as color, name, execution period, priority, and/or core affinity. Other embodiments can include additional or fewer characteristics and/or parameters depending on user preferences, specific parallel platform(s), etc. Still further, other embodiments can employ application programming interfaces (APIs) which may allows users to script the entry of task information into computer 110.

Color field 410 may indicate colors used to represent identifiers that reference units into which a model is broken. For example, color field 410 may identify colors used to identify sub graphs making up model 300. The continuous sub graph may be a first color, the fast sample time sub graphs may be a second color, and the slow sample time may be a third color. In another embodiment, the fast sample time sub graphs may be different colors. Other embodiments may further use shading or other techniques for identifying sub graphs or sub graph identifiers.

Name field 415 may include information identifying a sub graph in model 300. Period identifier 420 may include information identifying sample periods, or sample times, for sub graphs in model 300. Priority identifier 425 may include information identifying an execution priority for a sub graph in model 300, a concurrent computing resource, etc. Core affinity identifier 430 may identify a processing core, a processing device, a thread, a task, etc., on which a sub graph is run. Action buttons 435 may provide a user with access to commonly used functionality such as saving selections, canceling selections, accessing help resources, and applying changes to concurrent computing resources, model 300, etc.

Exemplary Mapping Technique

Embodiments allow users to identify sub graphs that are unmapped with respect to tasks residing in task group 330. For example, in FIG. 3, all sub graphs include a fill color, shading, or other type of visual identifier that indicates that the respective sub graph is mapped to a task in task group 330. Embodiments may not fill/shade a sub graph identifier until the sub graph identifier is mapped to a task. This approach may allow users to quickly identify sub graphs that are unmapped and therefore will not execute on a current computing resource when a model is simulated.

FIG. 5 illustrates an exemplary model that includes unmapped sub graphs. Model 500 may include the model components of FIG. 3; however, in FIG. 5 sub graphs having a sample time of 0.01 sec are unmapped with respect to one or more tasks in task group 330. For example, sub graph identifier 510 may display the sample time for the sub graph and may include a region, such as a square, that visually differs from regions for mapped sub graphs. For example, identifier 510 may be unshaded where other sub graph identifiers are shaded. Alternatively, identifier 510 may be a color that differs from colors of mapped sub graphs.

In an embodiment, sample time identifiers, such as numbers, may be displayed for a sub graph identifier when the identifier is unmapped with respect to a task. When the respective sub graph is mapped, the sample time identifier may be replaced with a color, a shading pattern, or some other type of visual identifier that indicates the sub graph has been mapped to a task. Mapping a sub graph to a task may ensure that the sub graph is allocated to a concurrent computing resource when model 500 is simulated.

Embodiments may employ mapping techniques that enforce desired constraints. For example, a mapping tool may prevent mapping of sub graphs whose sample times do not exactly match the rate of execution of the task. Alternately, the mapping may allow mapping of sub graphs with a different rate as long as the sample time of the mapped sub graph is a multiple of the task execution period.

FIG. 6 illustrates an exemplary user interface for mapping sub graphs to tasks. While the embodiment of FIG. 6 illustrates a UI, the arrangement of information in FIG. 6 can represent information in a computer-readable storage medium, such as a data store, an API, etc., without departing from the spirit of the invention. UI 600 may contain a table that includes a listing of sub graphs in the first column, which is identified via component/sub graph identifier 610. The second column of UI 600 is indicated using sample time identifier 620. Sample time identifier 620 indicates a sample time for a corresponding sub graph or component. The third column of UI 600 includes task identifier 630 for identifying tasks associated with sub graphs. The third column may include drop down menus that can be indicated using drop down identifier 635. Drop down identifier 635 may allow a user to select which task a sub graph is mapped to. Drop down menus may provide the user with an intuitive and easy to use mechanism for selecting available tasks and for graphically associating tasks with sub graphs. An exemplary drop down menu 640 is shown in the upper right portion of FIG. 6 and may include names for available tasks.

FIG. 7 illustrates an exemplary user interface 700 for mapping sub graphs to tasks and/or cores. UI 700 may be based on UI 400 and may include mapped sub graph field 710 and move field 720. Mapped sub graph field 710 may include textual explanations about model components included in a mapped sub graph. For example, text can indicate whether a mapped sub graph is part of a plant, a controller, a user input/control, etc. The text can further describe sample rate information as well as other information related to a sub graph.

Move field 720 may include information that indicates a task on which a sub graph will run. In an embodiment, drop down menus may provide a user with available selections about tasks and/or whether a sub graph will be executed in a batch mode. Initially, move field 720 may be unpopulated and a user may manually populate entries in field 720. In another embodiment, entries in field 720 may be programmatically populated with initial configurations and a user may vary the configurations when desired. UI 700 may include a batch move button 730 that allows the user to move sub graphs associated with a batch mode as a group.

By way of example and referring to FIG. 7, sub graphs mapped to a respective task are listed in a separate column with the name of a component and sample-time. Additionally, unmapped sub graphs are shown as being associated with a special "unmapped" task. Field 720 may include fields having a pull down menu with task names that allow users to pick which task a specific sub graph should be moved into. For example, sub graphs `User Controls (0.01)`, `Plant Section 2 (0.01)`, `Controller Section 2 (0.001)` are being setup to move to tasks `Slow`, `Fast 1`, and `Fast 2`, respectively. Field 720 may further allow users to remap sub graphs from one task to another. In an embodiment, UI 700 may be configured in a manner such that only tasks suitable for receiving items are presented in the `Move to task` pull down menu. For instance, the pull down may only show tasks having a same period that matches a sample period of a corresponding sub graph. In FIGS. 6 and 7, sub graphs are indicated using textual names associated with the icons of the respective components.

FIG. 8 illustrates UI 800 that can use icons 810 for identifying sub graphs or components corresponding to sub graphs. UI 800 may use the icons in place of using textual descriptions. Users may drag icons 810 directly from one task to another to graphically perform mapping operations. Embodiments, such as UI 800, may prevent users from having to learn special configuration commands for mapping sub graphs to tasks. Instead, users can intuitively move objects, such as icons 810, from one location to another to achieve a desired mapping.

Exemplary embodiments may allow users to specify mapping arrangements directly on a block diagram model. FIG. 9 illustrates model 900 which can be configured to allow a user to map sub graphs to tasks by selecting a sub graph and dragging the sub graph to a location in task group 330. A user may select sub graph identifier 510 using a pointing device and may drag identifier 510 along path 920. The user may drop identifier 510 proximate to task identifier 910 and identifier 510 may change appearance to resemble task identifier 910. The change in appearance of identifier 510 may indicate that the sub graph having an execution period of 0.01 sec is mapped to a task having an execution period of 0.01 sec.

A user may also select task identifier 910 and may drag identifier 910 along path 930 and may drop identifier 910 proximate to unmapped identifier 510 in component 310. Identifier 510 may change appearance after the drag/drop operation to resemble task identifier 910. The resemblance may indicate that identifier 510 of component 310 is mapped to task identifier 910. The embodiments of FIG. 9 may include help windows 940 and 950 that can provide a user with information or instructions regarding an operation to be performed or with respect to an operation that has been performed. In an embodiment, paths 920 and 930 may remain displayed on UI 900 and help windows 940 and 950 may be accessed by hovering a cursor for a pointing device over one of the displayed paths. UI 900 may provide an error indication when a user performs an unauthorized operation, such as attempting to mis-associate a task with a sub graph.

In an embodiment, user interface 700 may be built on top of a `get_param` API of a graphical modeling environment, such as Simulink environment. In an embodiment, the mapping may be expressed as: map=get_param(<block-diagram-name>, `TaskMappingTable`). When a table exists, the map may appear as an object that behaves like an object implemented using, for example, the MATLAB object-oriented class system. In an embodiment, a user may assign a component's sub graph specified by, for example, (component-name, sample-time) to a task specified by its name, which may be: map.mapSub graphToTask(<Component-name>, <sub graph-sample-time>, <task-name>). A programmatic API, such as API 1000 (FIG. 10A), may allow users to script the entire mapping process and/or to explore a design space iteratively. This interactive mapping can include performing a mapping, executing the design, gathering performance data, adjusting the mapping based on the performance data, and then refining the mapping for a subsequent iteration.

Exemplary Communication Between Tasks

FIGS. 10A and 10B illustrate an exemplary technique of configuring communication between tasks. FIG. 10A illustrates user interface 1000 that can be used in an embodiment of the invention. User interface 1000 may include signal name field 1002 for allowing a user to specify information related to a signal in a model. User interface 1000 may further include tabs 1006 that identify panes into which information can be entered or specified, such as by using drop down menus. In an embodiment, one tab may be active, such as task transition property, in FIG. 10A and other tabs may be inactive. Active tabs may be in the foreground of a user interface and inactive tabs may be in the background.

The task transition property tab may include an entry for specifying a task transition type 1004. In an embodiment, a drop down menu may include acceptable selections for task transition type 1004. When a user is satisfied with a configuration of user interface 1000, the user may select OK via buttons 435.

When sub graphs have been mapped to tasks, signals in the model may satisfy two use cases when the model is executed. A first use case may occur when the signal facilitates communication between sub graphs that are mapped to the same task. A second use case may occur when a signal facilitates communication between sub graphs that are mapped to separate tasks. In the first case, communication may behave as a regular signal in a time-based block-diagram. In the second case, users may want flexibility to change between different forms of communication based upon the requirements of a design. Embodiments allow a model canvas to provide the ability for a user to specify communication modes for signals using both graphical user-interface methods and a programmatic API.

The description continues in the full USPTO document.