Abstract: A method of specifying and configuring a causal relationship between the dynamics of a graphical model and the execution of components of the model is disclosed. Model component execution is tied to the occurrence of model events. Model events are first defined in the modeling environment. The occurrence of conditions in the model specified in the definition of the event causes the event to be “posted”. Model components that have been associated with the occurrence of the event “receive” the notice of the posting of the event and then execute. Random components within a subsystem may be designated to execute upon the occurrence of an event, as may non-contiguous components within a model. The association between model events and component execution may be specified without drawing graphical indicators connecting components in the view of the model.

Abstract: 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.

Abstract: A device may receive, from a user, a selection of one of a graphical representation of a data store included in a model or a string of text that identifies a variable associated with the model. The device may provide, based on the selection, a user interface for providing pattern information associated with the data store. The device may receive, via the user interface, the pattern information associated with the data store. The pattern information may identify one or more elements included in the model and a pattern associated with the one or more elements accessing the data store during an execution of the model. The device may analyze the model based on the pattern information and may output a result. The result may indicate whether the model accesses the data store in compliance with the pattern.

Abstract: 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.

Abstract: 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.

Abstract: A device may receive a model including a group of blocks, and may receive a command to execute the model. The device may assign a parameter sample time to a subset of blocks of the group of blocks. The parameter sample time may permit a block, of the subset of blocks, to be executed based on a parameter change event detected during the execution of the model. The device may cause the model to be executed after assigning the parameter sample time to the subset of blocks. The device may detect a parameter change event, associated with the model, prior to the execution of the model being completed. The parameter change event may include an event that is external to the execution of the model. The device may cause at least one block, of the subset of blocks, to be executed based on the detecting the parameter change event.

Abstract: A method of specifying and configuring a causal relationship between the dynamics of a graphical model and the execution of components of the model is disclosed. Model component execution is tied to the occurrence of model events. Model events are first defined in the modeling environment. The occurrence of conditions in the model specified in the definition of the event causes the event to be “posted”. Model components that have been associated with the occurrence of the event “receive” the notice of the posting of the event and then execute. Random components within a subsystem may be designated to execute upon the occurrence of an event, as may non-contiguous components within a model. The association between model events and component execution may be specified without drawing graphical indicators connecting components in the view of the model.

Abstract: 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.

Abstract: 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.

Abstract: A code verification tool verifies that code generated from a model represents all of the functionality of the model and does not contain any unintended functionality. The code verification tool may receive for examination a model or an intermediate representation (IR) of the model and the generated code or an intermediate representation of the generated code. The code verification tool may create further intermediate representations of the model and/or the generated code in order to compare the functionality presented in both.

Abstract: A device may receive a model including a group of blocks, and may receive a command to execute the model. The device may assign a parameter sample time to a subset of blocks of the group of blocks. The parameter sample time may permit a block, of the subset of blocks, to be executed based on a parameter change event detected during the execution of the model. The device may cause the model to be executed after assigning the parameter sample time to the subset of blocks. The device may detect a parameter change event, associated with the model, prior to the execution of the model being completed. The parameter change event may include an event that is external to the execution of the model. The device may cause at least one block, of the subset of blocks, to be executed based on the detecting the parameter change event.

Abstract: A mechanism in a block diagram environment allows the modeling of an execution behavior of a block in a block diagram, where a user selects the execution behavior from a plurality of functions related to the block diagram and where the execution behavior of the block is performed when at least one model variable associated with the block satisfies a user-specified condition is disclosed. States and other internal data in the designated block are initialized upon the satisfaction of the user-specified condition. The illustrative embodiment of the present invention also allows the internal data to be reset upon the ending of the event, such as the modeled introduction or withdrawal of power. The execution behavior may be suspended and resumed multiple times during the simulation in response to multiple occurrences of the specified event. The present invention also allows for selected data to be exempt from the reset process so that the selected data is non-volatile.

Abstract: A mechanism in a block diagram environment allows the modeling of an execution behavior of a block in a block diagram, where a user selects the execution behavior from a plurality of functions related to the block diagram and where the execution behavior of the block is performed when at least one model variable associated with the block satisfies a user-specified condition is disclosed. States and other internal data in the designated block are initialized upon the satisfaction of the user-specified condition. The illustrative embodiment of the present invention also allows the internal data to be reset upon the ending of the event, such as the modeled introduction or withdrawal of power. The execution behavior may be suspended and resumed multiple times during the simulation in response to multiple occurrences of the specified event. The present invention also allows for selected data to be exempt from the reset process so that the selected data is non-volatile.

Abstract: A multiple-fail-operational fault-tolerant clock having a plurality of interconnected and identical clock modules, that provides a fault tolerant clock signal despite some clock module failures. The clock incorporates fault-tolerant operational diagnostics so that a working clock module may be voted for supplying the output clock signal.