|
|
|
| R2012a Documentation → Simulink | |
Learn more about Simulink |
|
| Contents | Index |
Actions are part of Stateflow diagram execution. The action can be executed as part of a transition from one state to another, or depending on the activity status of a state. Transitions can have condition actions and transition actions. For example,
States can have entry, during, exit, and, on event_name actions. For example,
If you enter the name and backslash followed directly by an action or actions (without the entry keyword), the actions are interpreted as entry actions. This shorthand is useful if you are specifying only entry actions.
The action language defines the categories of actions you can specify and their associated notations. An action can be a function call, an event to be broadcast, a variable to be assigned a value, and so on.
Sometimes you want actions to take place as part of Stateflow diagram execution. The action can be executed as part of a transition from one state to another, or it can depend on the activity status of a state. Transitions can have condition actions and transition actions. States can have entry, during, exit, and, on event_name actions. An action can be a function call, an event to be broadcast, a variable to be assigned a value, etc.
The action language defines the categories of actions you can specify and their associated notations. Violations of the action language notation are flagged as errors by the parser. This section describes the action language notation rules.
A chart instance is a link from a Stateflow model to a chart stored in a Simulink library. A chart in a library can have many chart instances. Updating the chart in the library automatically updates all the instances of that chart.
A condition is a Boolean expression to specify that a transition occur, given that the specified expression is true. For example,
The action language defines the notation to define conditions associated with transitions.
Connective junctions are decision points in the system. A connective junction is a graphical object that simplifies Stateflow diagram representations and facilitates generation of efficient code. Connective junctions provide alternative ways to represent the system behavior you want. This example shows how connective junctions (displayed as small circles) are used to represent the flow of an if code structure.
Or the equivalent squared style
| Name | Button Icon | Description |
|---|---|---|
| Connective junction |
| One use of a Connective junction is to handle situations where transitions out of one state into two or more states are taken based on the same event but guarded by different conditions. |
Data objects store numerical values for reference in the Stateflow diagram.
A state machine can store and retrieve data that resides internally in its own workspace. It can also access data that resides externally in the Simulink model or application that embeds the state machine. When creating a Stateflow model, you must define any internal or external data referenced by the state machine's actions.
The data dictionary is a database where Stateflow diagram information is stored. When you create Stateflow diagram objects, the information about those objects is stored in the data dictionary, once you save the Stateflow diagram.
A state has decomposition when it consists of one or more substates. A Stateflow diagram that contains at least one state also has decomposition. Representing hierarchy necessitates some rules around how states can be grouped in the hierarchy. A superstate has either parallel (AND) or exclusive (OR) decomposition. All substates at a particular level in the hierarchy must be of the same decomposition.
Parallel (AND) State Decomposition. Parallel (AND) state decomposition is indicated when states have dashed borders. This representation is appropriate if all states at that same level in the hierarchy are active at the same time. The activity within parallel states is essentially independent.
Exclusive (OR) State Decomposition. Exclusive (OR) state decomposition is represented by states with solid borders. Exclusive (OR) decomposition is used to describe system modes that are mutually exclusive. Only one state, at the same level in the hierarchy, can be active at a time.
Default transitions are primarily used to specify which exclusive (OR) state is to be entered when there is ambiguity among two or more neighboring exclusive (OR) states. For example, default transitions specify which substate of a superstate with exclusive (OR) decomposition the system enters by default in the absence of any other information. Default transitions are also used to specify that a junction should be entered by default. A default transition is represented by selecting the default transition object from the toolbar and then dropping it to attach to a destination object. The default transition object is a transition with a destination but no source object.
| Name | Button Icon | Description |
|---|---|---|
| Default transition |
| Use a Default transition to indicate, when entering this level in the hierarchy, which state becomes active by default. |
Events drive the Stateflow diagram execution. Define all events that affect the Stateflow diagram. The occurrence of an event causes the status of the states in the Stateflow diagram to be evaluated. The broadcast of an event can trigger a transition to occur and/or can trigger an action to be executed. Events are broadcast in a top-down manner starting from the event's parent in the hierarchy.
A finite state machine (FSM) is a representation of an event-driven system. FSMs are also used to describe reactive systems. In an event-driven or reactive system, the system transitions from one mode or state, to another prescribed mode or state, provided that the condition defining the change is true.
A flow graph is the set of Flowcharts that start from a transition segment that, in turn, starts from a state or a default transition segment.
A Flowchart is an ordered sequence of transition segments and junctions where each succeeding segment starts on the junction that terminated the previous segment.
A flow subgraph is the set of Flowcharts that start on the same transition segment.
Using hierarchy you can organize complex systems by placing states within other higher-level states. A hierarchical design usually reduces the number of transitions and produces neat, more manageable diagrams.
A History Junction specifies the destination substate of a transition based on historical information. If a superstate has a History Junction, the transition to the destination substate is defined to be the substate that was most recently visited. The History Junction applies to the level of the hierarchy in which it appears.
| Name | Button Icon | Description |
|---|---|---|
| History Junction |
| Use a History Junction to indicate, when entering this level in the hierarchy, that the last state that was active becomes the next state to be active. |
An inner transition is a transition that does not exit the source state. Inner transitions are most powerful when defined for superstates with XOR decomposition. Use of inner transitions can greatly simplify a Stateflow diagram.
A library link is a link to a chart that is stored in a library model in a Simulink block library.
A Stateflow library model is a Stateflow model that is stored in a Simulink library. You can include charts from a library in your model by copying them. When you copy a chart from a library into your model, Stateflow does not physically include the chart in your model. Instead, it creates a link to the library chart. You can create multiple links to a single chart. Each link is called a chart instance. When you include a chart from a library in your model, you also include its state machine. A Stateflow model that includes links to library charts has multiple state machines. When Stateflow simulates a model that includes charts from a library model, it includes all charts from the library model even if there are links to only some of its models. However, when Stateflow generates a stand-alone or Simulink Coder™ target, it includes only those charts for which there are links. A model that includes links to a library model can be simulated only if all charts in the library model are free of parse and compile errors.
A machine is the collection of all Stateflow blocks defined by a Simulink model exclusive of chart instances (library links). If a model includes any library links, it also includes the state machines defined by the models from which the links originate.
Blocks that perform a calculation, such as a Gain block.
A notation defines a set of objects and the rules that govern the relationships between those objects. Stateflow notation provides a common language to communicate the design information conveyed by a Stateflow diagram. Stateflow notation consists of:
A set of graphical objects
A set of nongraphical text-based objects
Defined relationships between those objects
A system with parallelism can have two or more states that can be active at the same time. The activity of parallel states is independent. Parallelism is represented with a parallel (AND) state decomposition.
A system that uses actual hardware to implement algorithms, for example, digital signal processing or control applications.
Simulink Coder software includes an automatic C language code generator for Simulink. It produces C code directly from Simulink block diagram models and automatically builds programs that can be run in real-time in a variety of environments.
An executable built from code generated by the Simulink Coder product.
A customized Simulink block written in C or MATLAB-code. S-functions written in C can be inlined in the Simulink Coder software. When using Simulink together with Stateflow for simulation, Stateflow generates an S-function (MEX-file) for each Stateflow machine to support model simulation. This generated code is a simulation target and is called the S-Fun target within Stateflow.
Process used by Simulink to determine attributes of signals and blocks, such as data types, labels, sample time, dimensionality, and so on, that are determined by connectivity.
The signal source is the block of origin for a signal. The signal source may or may not be the true source.
Simulink is a software package for modeling, simulating, and analyzing dynamic systems. It supports linear and nonlinear systems, modeled in continuous time, sampled time, or a hybrid of the two. Systems can also be multirate, that is, have different parts that are sampled or updated at different rates.
Simulink allows you to represent systems as block diagrams that you build using your mouse to connect blocks and your keyboard to edit block parameters. Stateflow is part of this environment. The Stateflow block is a masked Simulink model. Stateflow builds an S-function that corresponds to each Stateflow machine. This S-function is the agent Simulink interacts with for simulation and analysis.
The control behavior that Stateflow models complements the algorithmic behavior modeled in Simulink block diagrams. By incorporating Stateflow diagrams into Simulink models, you can add event-driven behavior to Simulink simulations. You create models that represent both data and control flow by combining Stateflow blocks with the standard Simulink blockset. These combined models are simulated using Simulink.
A state describes a mode of a reactive system. A reactive system has many possible states. States in a Stateflow diagram represent these modes. The activity or inactivity of the states dynamically changes based on events and conditions.
Every state has hierarchy. In a Stateflow diagram consisting of a single state, that state's parent is the Stateflow diagram itself. A state also has history that applies to its level of hierarchy in the Stateflow diagram. States can have actions that are executed in a sequence based upon action type. The action types are: entry, during, exit, or on event_name actions.
| Name | Button Icon | Description |
|---|---|---|
| State |
| Use a state to depict a mode of the system. |
The Stateflow block is a masked Simulink model and is equivalent to an empty, untitled Stateflow diagram. Use the Stateflow block to include a Stateflow diagram in a Simulink model.
The control behavior that Stateflow models complements the algorithmic behavior modeled in Simulink block diagrams. By incorporating Stateflow blocks into Simulink models, you can add complex event-driven behavior to Simulink simulations. You create models that represent both data and control flow by combining Stateflow blocks with the standard Simulink and toolbox block libraries. These combined models are simulated using Simulink.
Use the Stateflow Debugger to debug and animate your Stateflow diagrams. Each state in the Stateflow diagram simulation is evaluated for overall code coverage. This coverage analysis is done automatically when the target is compiled and built with the debug options. The Debugger can also be used to perform dynamic checking. The Debugger operates on the Stateflow machine.
Using Stateflow, you create Stateflow diagrams. A Stateflow diagram is also a graphical representation of a finite state machine where states and transitions form the basic building blocks of the system.
Use the Stateflow Explorer to add, remove, and modify data, event, and target objects.
Use the Finder to display a list of objects based on search criteria that you specify. You can directly access the properties dialog box of any object in the search output display by clicking on that object.
A state is a substate if it is contained by a superstate.
A state is a superstate if it contains other states, called substates.
An executable program built from code generated by Stateflow or Simulink Coder software.
Top-down processing refers to the way in which Stateflow processes states. In particular, Stateflow processes superstates before states. Stateflow processes a state only if its superstate is activated first.
A transition describes the circumstances under which the system moves from one state to another. Either end of a transition can be attached to a source and a destination object. The source is where the transition begins and the destination is where the transition ends. It is often the occurrence of some event that causes a transition to take place.
A transition path is a Flowchart that starts and ends on a state.
A transition segment is a single directed edge on a Stateflow diagram. Transition segments are sometimes loosely referred to as transitions.
A tunable parameter is a parameter that can be adjusted in the model and in generated code.
The true source is the block which creates a signal. The true source is different from the signal source because the signal source may be a simple routing block such as a Demux block.
When creating models, be aware that Simulink blocks fall into two basic categories: nonvirtual and virtual blocks. Nonvirtual blocks play an active role in the simulation of a system. If you add or remove a nonvirtual block, you change the model's behavior. Virtual blocks, by contrast, play no active role in the simulation. They help to organize a model graphically. Some Simulink blocks can be virtual in some circumstances and nonvirtual in others. Such blocks are called conditionally virtual blocks. The following table lists Simulinks virtual and conditionally virtual blocks.
| Block Name | Condition Under Which Block Is Virtual |
|---|---|
| Bus Selector | Virtual if input bus is virtual |
| Demux | Always virtual |
| Enable | Virtual unless connected directly to an Outport block |
| From | Always virtual |
| Goto | Always virtual |
| Goto Tag Visibility | Always virtual |
| Ground | Always virtual |
| Inport | Virtual when the block resides within any subsystem block (conditional or not), and does not reside in the root (top-level) Simulink window. |
| Mux | Always virtual |
| Outport | Virtual when the block resides within any subsystem block (conditional or not), and does not reside in the root (top-level) Simulink window. |
| Selector | Virtual except in matrix mode |
| Signal Specification | Always virtual |
| Subsystem | Virtual unless the block is conditionally executed and/or the block's Treat as Atomic Unit option is selected. |
| Terminator | Always virtual |
| Trigger | Virtual if the Outport port is not present. |
Using a virtual scrollbar, you can set a value by scrolling through a list of choices. When you move the mouse over a menu item with a virtual scrollbar, the cursor changes to a line with a double arrowhead. Virtual scrollbars are either vertical or horizontal. The direction is indicated by the positioning of the arrowheads. Drag the mouse either horizontally or vertically to change the value.
 | Signals and Signal Labels | Modeling Guidelines for High-Integrity Systems |  |
Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
