The Mathworks, Inc.

Hidayet Tunc Simsek

Ramamurthy Mani

Pieter Johannes Mosterman

Jay Ryan Torgerson

Claudia G Wey

Mojdeh Shakeri

Peter S Szpak

Katalin Maria Popovici

Matthew J Englehart

Vijaya Raghavan

Farid Antoine Abizeid

Srinath Avadhanula

Zhihong Zhao

Aravind Pillarisetti

Rajiv Ghosh-Roy

Farid Antoine Abi-Zeid

Nirmal K Gunaseelan

John Edward Ciolfi

Xiaocang Lin

Michael David Tocci

Sankalp Sandeep Modi

Thomas G Bolton

Sina Yamac Caliskan

Qingmin Shi

Benjamin Charles Martin

Systems and methods analyze an executable simulation model to identify existing concurrency, determine opportunities for increasing concurrency, and develop proposed modifications for realizing the opportunities for increased concurrency. The systems and methods may label locations at the simulation model where concurrency exists, and provide information regarding the proposed modifications to increase the model's concurrency. The systems and methods may modify the simulation model if the additional concurrency is accepted. The systems and methods may operate within a higher-level programming language, and may develop the proposed modifications without lowering or translating the simulation model to a lower abstraction level. The systems and methods may also undo a modification, rolling the simulation model back to a prior design state. Accepting the proposed modifications may cause the simulation models to execute more efficiently, e.g., faster.

Systems and methods for performing concurrency analysis in simulation environments

A first request is received for one or more service interface specifications. The first request includes information about one or more model element interface specifications usable for identifying the service interface specifications. The model element interface specifications are part of or extracted from one or more executable model elements of an executable graphical model. The service interface specifications correspond to respective services that include features complying with the model element interface specifications and are associated with information necessary for implementing semantics of the model elements. The information about the model element interface specifications is analyzed, comprising evaluating semantics of the executable model elements within the executable graphical model. The service interface specifications are identified based on the analyzing. Information is provided representing the identified service interface specifications for display and selection. A selection of at least one of the identified service interface specifications is stored after the selection is made.

Managing discovery and selection of service interface specifications

A device may receive a model for code generation. The device may determine to preserve continuity with a first generated code associated with the model. The device may receive, based on determining to preserve continuity, a first generation record associated with the first generated code. The first generation record may include information associated with generation of the first code. The device may generate second code based on the model and the first generation record. The device may create a second generation record based on the second generated code. The second generation record may include information associated with generation of the second code. The device may provide the second generated code.

Code continuity preservation during automatic code generation

A system and method may generate executable models having message sending objects and message receiving objects. A message may include a fixed data payload, and the message may persist for only a determined time interval of a total execution or simulation time of model. Message queues may be established for the messages, and the queues may have attributes. The model may include a state-based portion having states and transitions. States may be configured to generate and send messages, and to receive and process messages. In addition, transitions may be guarded by particular messages. The system and method also may generate standalone code, such as source code, for the model. The standalone code may include code that establishes a message passing service to support the sending and receiving of messages.

Message-based modeling

In an embodiment, a system may receive information regarding a group of physical devices; receive information regarding a set of functional blocks associated with a functional model; and receive mapping information that indicates a mapping between the set of functional blocks and one or more physical devices of the group of physical devices. The system may further generate at least one functional effect associated with the functional model. The generating may be based on: the set of functional blocks, the mapping information, and the information regarding the one or more physical devices. The system may also store or output the at least one functional effect.

Automatic modeling, mapping, and code generation for homogeneous and heterogeneous platforms

A device may generate code for a caller element of a first graphical model and a called element of a second graphical model by generating a first function and a second function. The first function may represent an interface between the caller element and the called element. The first function may include a first input argument corresponding to an input variable and a first output argument corresponding to an output variable. The second function may represent an underlying function of the called element. The underlying function may include the input variable passed from the caller element and the output variable. The underlying function may further include an internal input variable and an internal output variable. The second function may include second input arguments corresponding to the input variable and the internal input variable, and may include second output arguments corresponding to the output variable and the internal output variables.

Code generation for using an element in a first model to call a portion of a second model

A system may receive a model, extract information from the model, form a group of tags using the extracted information, and associate the group of tags with the model. The system may further receive a search query including one or more sequences of characters and determine whether to provide the model in a list of models created for the search query, based on the one or more sequences of characters and the group of tags.

Collaborative modeling environment

A device may receive function information that describes a caller element that calls a called element that is separate from the caller element. The function information may identify a name or reference of the called element, a passed input, and a passed output. The passed input may be provided by the caller element to the called element, and the passed output may be received by the caller element from the called element. The caller element may be associated with a caller model, and the called element may be associated with a called model. The device may identify the called element, and may execute the caller element in a simulation environment. Execution of the caller element may cause execution of the called element without causing execution of an entirety of the called model. The device may receive the passed output from the called element based on executing the called element.

Using an element in a first model to call a portion of a second model

A system and method may generate executable block diagrams in which at least some of the blocks run in accordance with message-based execution semantics. A message may include an input data payload that does not change over time, and the message may persist for only a determined time interval during execution of block diagram. A message-based execution engine may control execution of message-based blocks in which a source block may generate a message at a particular point in time, the message may be sent to one or more destination blocks triggering execution of those blocks, and the message may be destroyed on or after a determined time interval. Other execution domains, such as a time-based or state-based execution domain, may be provided, and the system may implement a hybrid execution model.

A device receives information associated with a functional model, and generates the functional model based on the received information and with a technical computing environment (TCE), where the functional model including nodes, inputs, and outputs. The device also automatically detects architecture information from an architecture model associated with the functional model, and automatically assigns, based on the architecture information, at least one signal between two nodes of the functional model, a node and an input of the functional model, or a node and an output of the functional model. The device obtains information for code generation based on the assigned at least one signal, and stores the information for code generation.

Automatic assignment of signals for a functional model

Exemplary embodiments allow executable graphical models, such as block diagram models, to be graphically partitioned for execution on concurrent computing resources. Embodiments allow model components to be grouped into subtasks that are affiliated with tasks associated with concurrent computing resources. Tasks and sub graphs can be mapped to concurrent computing resources according to characteristics, such as sample time, solver type, etc. Embodiments further allow mappings to be visually indicated to a user via various display techniques including color, text, icons, shading, grouping of identifiers, etc. Concurrently executing portions of a model allows model results to be obtained faster than can be obtained when models are executed on a single computing resource, such as a single processor.

Graphical partitioning for parallel execution of executable block diagram models

A system and method may generate executable block diagrams in which at least some of the blocks run in accordance with message-based execution semantics. A message may include an input data payload that does not change over time, and the message may persist for only a determined time interval during execution of block diagram. A message-based execution engine may control execution of message-based blocks in which a source block may generate a message at a particular point in time, the message may be sent to one or more destination blocks triggering execution of those blocks, and the message may be destroyed on or after a determined time interval. Other execution domains, such as a time-based or state-based execution domain, may be provided, and the system may implement a hybrid execution model. A verification engine may provide one or more tools for evaluating and verifying operation of message-based blocks. The verification engine may support one or more verification blocks that may be added to the block diagram and associated with the diagram's message-based blocks. The verification blocks may capture and present messages exchanged among the message-based blocks. The verification blocks may also specify an expected interaction of messages, and determine whether the actual messages are equivalent to the expected interaction. If not, the verification block may perform one or more predefined actions, such as suspending further execution of the block diagram.

Growing community of inventors

Newton, MA, United States of America

Hidayet Tunc Simsek