WO2007027622A2

WO2007027622A2 - System and method for creating and using graphical object instances in a statechart environment

Info

Publication number: WO2007027622A2
Application number: PCT/US2006/033554
Authority: WO
Inventors: Vijay Raghavan; Beth Cockerham
Original assignee: The Mathworks, Inc.
Priority date: 2005-08-30
Filing date: 2006-08-30
Publication date: 2007-03-08
Also published as: WO2007027622A3; US20070074184A1; US20120291003A1; EP1929399A2; US8881097B2; US8201140B2

Abstract

A method of providing multi-instantiable state templates to a statechart environment is discussed. The method includes the step of providing a graphical definition of an independent state machine object belonging to a statechart. The method further includes the step of instantiating a first instance and a second instance of the independent state machine object in the statechart. The method additionally includes the steps of starting execution of the first instance of the independent state machine object and then stopping execution of the first instance of the state machine object. Additionally, the method includes the step of starting the execution of the second instance of the independent state machine object in the state diagram.

Description

SYSTEM AND METHOD FOR CREATING AND USING GRAPHICAL OBJECT INSTANCES IN A STATECHART ENVIRONMENT

Related Application This application claims the benefit of U.S. Patent Application Serial No.

11/216,246, filed August 30, 2005, the contents of which are hereby incorporated by reference.

Field of the Invention Implementations relate generally to statecharts and more particularly to the use of graphical objects in statecharts.

Background

Statechart based environments may be used to represent states related to a system. For example, a statechart environment may be used to graphically model a portion of a control system that includes a number of components using a computer. Statechart environments may be cumbersome for users when modeling components that can be represented by more than one state. For example, a component of the control system may be related to a state machine within the statechart environment. Components having more than one state may require the use of multiple state machines. The use of multiple state machines may cause conflicts with parameters related to the statechart environment, such as variables. As a result, modeling results may be inaccurate and/or operation of the model may be adversely impacted, e.g., because of degraded model performance. Brief Summary

Exemplary implementations described herein may provide a mechanism for the use of single-instantiatable or multi-instantiable state templates in a state diagram environment that allow the graphical definition of an independent state machine object. Other implementations may be implemented without the use of templates. As used herein, "a template" may be a class definition, which may be instantiated into objects (also referred to herein as "object instances"). A state machine class may be apart of a class hierarchy, with additional classes deriving from it or being its base classes. The state machine class may include methods and variables. A method of a class can be referred to as a 'function.'

In an exemplary embodiment, objects instances may be instantiated during run time , i.e., during the execution of a statechart. The class variables may be resolved during the run time on the level of the object instance and/or during the pre-processing, e.g., globally on the state chart level. The graphical definition of the independent state machine object may include techniques to start and stop the graphical object instances as well as techniques to interrogate the instances for internal data and/or state activity. The use of the graphical objects in the statechart may allow for rapid transitions from one independent state machine instance to another for systems that may require expedient switching of state machine data associated with a component.

In an exemplary implementation, a distributed system for providing single- instantiable or multi-instantiable state templates for a statechart environment may include a server hosting a state diagram environment that can include a statechart. The statechart may include a graphical definition of an independent state machine object belonging to the statechart. The graphical definition of the independent state machine object may support an instantiation of at least a first instance and a second instance of the independent state machine in the statechart. The system may further include a client system communicating over a network with the statechart environment. The client system may be operated by a user. The user may enter input via the client system, and the client system may send the input to the statechart environment. The client system may receive one or more results of the statechart execution from the statechart environment and/or a device operating on behalf of the statechart environment. Additionally, the system may further include a display device in communication with the client system to display output received from the statechart environment to the user.

Brief Description of the Drawirms

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

Figure 1 depicts an environment suitable for practicing an exemplary implementation; Figure 2 depicts an alternate distributed architecture suitable for practicing an exemplary implementation;

Figure 3 is a flow chart of a sequence of steps that can be used to execute one or more instances of an independent state machine object in a statechart; , Figure 4 depicts a sequence of steps that may be used to swap configuration data from a previously executed instance of a graphical object to a second instance of the graphical object within a statechart;

Figure 5 A is a screenshot depicting a graphical definition of an independent state machine object belonging to a statechart; Figure 5B is a screenshot showing a listing of two instances of the independent state machine object defined in Figure 5 A;

. Figure 5C is a screenshot showing a statechart utilizing the two instancea of Figure 5B;

Figures 6A-C illustrate an implementation of a statechart that employs a user interface to receive information about objects used in the statechart; and Figure 7 illustrates an implementation of a statechart

Detailed Description

Implementations of state machines described herein may be provided in graphical and/or textual form. For example, a first implementation may employ a user interface (such as a menu, pop-up window, etc.) to allow a user to enter information related to a state machine. A second implementation, may allow a user and/or device to provide information via text (e.e., via a command line prompt). Information in a state machine may be displayed graphically and/or textually regardless of whether information was received via a user interface or a textual mechanism.

Figure 1 depicts an environment suitable for practicing an exemplary implementation. A computational device 2 may support a statechart environment 4. The computational device 2 may host the statechart environment 4 or may provide access to the statechart environment. The computational device 2 may be a server, client, workstation, mainframe, laptop, smartphone, smart sensor/actuator, PDA or some other type of device with computational power that executes instructions to perform one or more tasks and/or to generate one or more results. The computational device 2 may further be configured to support one or more statechart environments 4 operating on one or more platforms (e.g., on a standalone device or spread across multiple devices in a distributed and/or parallel implementation). The statechart environment 4, such as STATEFLOW from The MathWorks, Inc. of Natick, Massachusetts, provides an environment in which to execute statecharts that include instances of graphical objects. Statechart environment 4 may further include a statechart 6 that can include a graphical definition of an independent state machine object 8.

The statechart 4 may graphically depict the functionality of a system being modeled. The graphical definition of the independent state machine object 8 may be depicted as a chart including symbols and logic which are interpreted by a symbol resolution process 16 to provide the functionality used by the statechart environment 4. The symbol resolution process 16 may be included in the statechart environment 4 or may be integrated with the statechart environment 4 (e.g., via an external source device or code). The statechart 6 may include a first instance of the independent state machine object 10 and a second instance of the independent state machine object 12. The statechart 6 may include a third instance of the independent state machine object 14 that can include local data 15. In one implementation, local data 15 may be restricted in scope to the third instance of the independent state machine object 14. The computational device 2 may be accessed by a user 22 and may be in communication with a display device 20. Those skilled in the art will recognize that the exemplary implementation of Figure 1 may also be implemented in other architectures, such as distributed architectures, parallel architectures, etc.

Figure 2 depicts an alternate distributed architecture suitable for practicing the exemplary implementation of Figure 1. A computational device 30 may support a statechart environment 32. The statechart environment 32 may include a statechart 34 graphically depicting the functionality of a system being modeled. Included in the statechart 34 is a graphical definition of an independent state machine object 36 and a first and second instance of the independent state machine object 38 and 40, respectively. The computational device 30 may communicate with a client device 60 over a network 50. The network 50 may be the Internet, a local area network (LAN), a wide area network (WAN), an extranet, an intranet, wireless network, satellite network, or some other type of network capable of allowing a user 62 accessing the client 60 to communicate with the statechart environment 32 and computational device 30. The user 62 may use client 60 to view the output of operations performed in the statechart environment 32 via a monitor 64. Client 60 may receive the output from computational device 30 over network 50.

The graphical definition of the independent state machine object 8 may contain a complete state hierarchy with local data and local events and may have multiple data inputs and data outputs. The instances of the independent state machine object 8 may be instantiated textually, graphically, and/or via other techniques in the statechart diagram using instance variables. The instance variables may be defined as local data in the statechart diagram with the type set to the name of the independent state machine object. For example, instance variables may be used to start, suspend, stop, etc., the evaluation and/or operation of that instance variable within a statechart. hi one implementation, a statechart may use nested instance variables. When a statechart uses nested instance variables, the statechart may issue an error when the operation of two or more nested variables is outside of a determined range. Alternatively, the statechart may resolve inconsistencies between the operation of two or more nested variables, hi one implementation, a history junction may be used to determine where execution should begin. For example, a history junction may include one or more graphic symbols that indicate where execution should start. The graphic symbols may include logic that causes a device running a statechart to begin execution at a determined location.

The state transition actions in the independent state machine object 8 may follow hierarchical symbol resolution rules within an object instance, such as one or more standard hierarchical symbol resolution rules. For atomic independent state machine objects (which maybe resolved without global data), the symbol resolution may stop at the boundary of the object. For non-atomic independent state machine objects, an attempt can be made to hierarchically resolve symbols that are not resolved within the object hierarchy in the statechart that contains the object definition. Atomic objects can be useful when defining a library of state diagram templates that do not depend on the external environment. Non-atomic objects can be useful in extending the power of objects to access global data more efficiently.

The graphical definition of the independent state machine object 8 may be implemented using a variety of techniques. For example, in one implementation, a graphical definition of the independent state machine object 8 may include a start act, a stop act, a start again act, a reset act, a restart act, an execute act, a get act, and/or a set act. The start act may be called to initiate an object instance of an independent state machine object, such as an instance of independent state machine object 8. The start act may cause processing to follow one or more default transition paths for the object instance. Implementations may be configured so that an object instance cannot be called prior to running the start act without causing a run-time error. The stop act may cause instances related to a start act to suspend or stop.

Information related to the start act may be stored in a memory when the stop act is called and/or run. For example, state configurations related to the start act may be stored in volatile memory when the stop act is called. Implementations may further allow write access (e.g., to memory) when the stop act is called. Calling the stop act may further mark an object instance (e.g., by marking an object instance as not valid for execution).

The start again act may be called after the stop act in one implementation. An object instance related to the start act may retain its state information when the start again act is called. For example, calling the start again act may recall state configuration information from memory. Maintaining state configuration information on behalf of an object may not require re-execution of default paths when the start again act is called. In one implementation, a configuration may be manually set so that an object instance is marked as valid with respect to execution. State consistency evaluations may be performed when the object instance is marked as valid.

The reset act may reset a state configuration when called. In one implementation, calling the reset state may reset local data and/or may allow another time object (e.g., a time object that is supposed to operate subsequent to an earlier object) to be started. Calling the reset act may start default processes (acts, and/or methods) in one implementation.

The restart act may include functionality related to the stop act and the reset act. The execute act may be called and/or executed via textual invocation in one implementation. For example, the execute act may be called in a manner similar to calling a graphical function. Other implementations may call the execute act and/or other acts in other ways without departing from the spirit of the invention.

The get act may obtain state activity and/or local data related to an instance of an object. The set act may set state activity and/or local data for an instance of an object. Graphical definition of the independent state machine object 8 may employ the acts described above as well as other acts. For example, the independent state machine object definition may include a start act. An object instance of the independent state machine object may be initiated and started by calling the start act. Upon an initial call to the start act for the object instance, default transition paths of the object instance may be followed. When the object instance is stopped and then started again, the object instance may retain the previous state configuration and may not re-execute the default paths. The retention of previous state configuration may be done selectively in one implementation, such as by varying the retention of state configuration based on a level in a hierarchy of states. The object instance may also be marked as valid to execute and may perform state consistency checks. For example, in one implementation state consistency checks may be performed to determine whether the state configuration was previously manually set. The graphical definition of the independent state machine object may also include a stop method which marks the object instance as not valid to execute. If the object instance is executed after it stops a run-time error may be generated.

Figure 3 is a flowchart of the sequence of steps that can be implemented via an exemplary implementation to utilize one or more (single-instantiated and/or multiple- instantiated) independent state machine objects in a single statechart. The use of multiple independent state machine objects in a single statechart may allow for rapid switching from one independent state machine to another during execution of the statechart. The sequence of steps may begin with the instantiation of a first and second instance of the independent state machine object defined in the statechart (step 100). The first instance of the independent state machine object may begin execution (step 102) as a result of the execution of the statechart in which it is instantiated. Subsequently during the execution of the statechart the execution of the first instance may be stopped and the final state configuration data may be saved (step 104). The execution of the second instance of the independent state machine may begin (step 106) and the second instance receive the state configuration data previously saved from the execution of the first instance of the independent state object as a starting state (step 108). Logic may be called/run in the executing second instance to perform a desired action (step 110). For example, the logic may implement a get act, a set act, a start act, a stop act, or another type of act defined in the graphical definition of the independent state machine object.

Figure 4 depicts a sequence of steps followed by an exemplary implementation of the present invention to start and restart instances 10 and 12 of an independent state machine object in a statechart using previously saved state configuration data. The sequence may begin when the first instance 10 of the independent state machine object is instantiated and started in the statechart 6 (step 120). During the execution of the statechart 6, the executed first instance 10 may be stopped and state configuration information is saved (step 122). The second instance 12 in the statechart 6 may be executed and subsequently stopped (step 124). The first instance 10 of the independent state machine object may then be restarted and the state configuration information retrieved and restored from the previously executing second instance 12 (step 126). Or alternatively, the first instance 10 of the independent state machine object may have its own configuration information restored to it upon the restart. The execution of the first instance 10 may then be stopped a second time (step 128). The first instance 10 may then be restarted with a reset command which may result in a default transition path being executed and state configuration information being restored to the first instance 10 prior to the first instance beginning execution following the reset command (step 130). The exemplary implementation of the present invention may provide automatic code generation which generates code in an efficient manner. For example, a code- generation process maybe run in the statechart environment and/or in cooperation with the statechart environment to transform a higher-level representation of an entire or partial statechart into a lower-level representation. For example, a statechart may operate using a high-level language. The statechart may produce lower-level code, such as C code. Implementations may generate object based code (e.g., C++) and/or non- object code. Implementations may further generate code that accommodates dynamic typing and/or vectorized operations. Other implementations may generate still other types of code, such as hardware based code (e.g., hardware description language (HDL), Verilog, etc.).

In an implementation, a code generation process may have three distinct phases, such as the parsing of textual action language statements that comprise state/transition actions and conditions, the construction of an in-memory intermediate representation of the statechart, and the transformation of the intermediate representation. The parsing of textual action language statements that comprise state/transition actions and conditions may create a set of Abstract Syntax Trees (ASTs) that are attached to the statechart objects (states and transitions). The construction of an in-memory intermediate representation of the state-diagram may use the ASTs to capture the semantics of the state diagram. The output of this stage may include a high-level representation that consists of a call-graph of functions (which contain control-flow graphs consisting of nodes and edges) and high-level nodes, operators, and types to account for matrix, complex and fixed-point quantities that arise from the front-end languages (e.g.: Stateflow and Embedded MATLAB). The transformation phase may gradually lower this intermediate representation to a lower-level representation that is convertible to other languages, such as C. During the lowering, optimizations for computational complexity, resource usage, readability, etc., may be applied.

Object instantiations of an independent state machine object may yield a set of functions corresponding to the states contained therein. These functions may differ from other types of state functions in that they have an additional input parameter that can contain information representing the current-state configuration. For example, an exit_atomic function for a state contained in an object instance may be implemented as:

Exit_Atomic(CurrentState Variables)

{

Perform Exit Actions(CurrentState Variables); Mark State Inactive(CurrentState Variables);

} Similar functions for a state outside of an object instance may not carry the additional parameter "CurrentStateVariables".

hi addition, object instances may include additional functions such as:

1. Start 2. Stop

3. Reset

4. Restart

5. Execute

Start(CurrentStateVariables)

{

Mark Object Instance Active;

}

Stop(CurrentState Variables) {

Mark Object Instance Inactive; }

Reset(CurrentStateVariables)

{

Set CurrentState Variables to their default values(usually zero) }

Restart(CurrentState Variables)

{

Call Reset(CurrentState Variables)

Call Start(CurrentStateVariables) }

Execute(CurrentStateVariables)

{

If(Object Instance is active) {

Call the During() of the Object Instance }

}

Implementations described herein may allow the computation of the total number of object instance variables needed for every object instance. The computations may be performed using graph-search algorithms to identify the definitions of the total number of object instance variables across all control- flow graphs corresponding to the chart. Live-range analysis on the object instance variables may be performed to establish which object instances can share the same memory. A compiler analysis called "live- range analysis" can be used to track the uses and definitions of the object instance variables across the control-flow graphs to establish which ones can be reused. This may further minimize the number of object instance variables. Implementations may further allow the identification of singleton object instances to avoid "pointer- dereferencing". If there is only a single object instance variable that is required, then an additional input "CurrentState Variables" may not be provided to the object instance functions. The object instance variables corresponding to the object instance can be treated as global variables with direct access. This may yield run-time efficiencies by minimizing indirect accesses. Inline-analysis to remove function-call overhead for the object instances may also be performed to minimize the number of function calls and correspondingly limit the function-call overhead. The types of analysis discussed above may result in the generation of code allowing the object instances to be realized as a combination of functions and local data.

The graphical definition of the independent state machine object used in an exemplary implementation may be further explained with reference to Figures 5A- 5C. Figure 5A is a screenshot 200 depicting a graphical definition of a named independent state machine object belonging to a statechart. An independent state machine object transmission maybe graphically defined in connection with Figs. 5A- 5C. The named "transmission" object graphical definition may include three inputs, such as data speed 204, up_th 206, and down_th 208. The transmission object may include an output data gear 210. Additionally, the transmission object definition may include a hierarchy of states, parallel 212 and XOR 214, and local events UP 216 and DOWN 218.

The exemplary implementation may allow multiple instances of the graphically defined object to be instantiated in the same statechart. Figure 5B is a screenshot showing a listing of two instances of the independent state machine object defined in Figure 5A. The two instances trans 1 220 and trans2 222 are both defined to have local scope 224 and be of data type 226 "transmission", the name of the graphically defined independent state machine object.

Figure 5C is a screenshot showing a statechart 230 utilizing the two instances of Figure 5B. The statechart includes states Transmissionl (232), Transmission2 (234) and a component gear 236. The state Transmissionl (232) includes the instance transl 220 while the state Transmission (234) includes the instance trans2 (222). When the state Transmissionl is first activated, the entry action invokes the "start" method 240 of the instance transl 220. The "during" function 242 in Transmissionl (232) executes transl 220 by passing transl its input/output data. When the state Transmissionl (232) exits and the state Transmission2 (234) is entered, the instance transl 220 is stopped and the instance trans2 (222) is started. It should be noted that the final state configuration in transl 220 is interrogated to set a default active state in trans2 (222) which overrides the default transition paths. Figure 6A illustrates an exemplary statechart 60 that can include a task 62, an input signal 64, a first graphical object 66, a second graphical object 68 and a signal path 70. Alternative implementations of statechart 60 may include more or fewer blocks. Task 62 may include one or more input arguments (e.g., El) and may be of a type (here of type mytask). Input 64 may identify input information to first graphical object 66 and/or second graphical object 68. Alternatively, input 64 may identify a location where processing begins when a statechart is run. For example, in statechart 60, processing may begin with first graphical object 66. Graphical objects 66 and 68 may include blocks, or other representations, and/or may include logic that is executed to perform one or more operations. Signal path 70 may include a representation that identifies a signal flow between graphical objects 66 and 68. Signal path 70 may include related logic that allows a data exchange between two or more blocks, modules, components, and/or devices. Figure 6B illustrates a menu 72 that can be used to configure portions of statechart 60. In one implementation, menu 72 may include a model hierarchy 74, a customize contents window 76, and a contents window 78. Model hierarchy 74 may include information that identifies a hierarchy, or relationship, between one or more statecharts, graphical objects (e.g., blocks), and/or parameters related to statecharts. Selecting an item in model hierarchy 74 may cause information about the selected item to be displayed in contents window 78. Customize contents window 76 may include information that can be used by an operator to configure how information is displayed, how a statechart is configured, etc. Contents window 78 may include information related to a statechart. For example, contents window 78 may display information related to one or more graphical objects used in connection with a statechart, such as statechart 60. Contents window 78 may include information about tasks, scopes of variables, data types, sizes of tasks, variables, etc., and/or other information related to one or more statecharts.

Figure 6C illustrates a statechart 75 that can include an input signal 78, a first block 80, a second block 82, a first signal path 84 and a second signal path 86. Input signal 78 may include information that is sent to first block 80 and/or second block 82. Information made available to first block 80 or second block 82 by input signal 78 may be processed by blocks 80/82 to produce one or more outputs. First block 80 may represent an object (e.g., a state machine object) and may include a state Xl. First block 80 may evaluate taskl having argument Yl when first block 80 is run. Second block 82 may operate in a fashion similar to that of first block 80 and may evaluate task2 having argument Y2. The operation of first block 80 may be suspended when second block 82 is running. First signal path 84 may carry information from first block 80 to second block 82 and second signal path 86 may carry information from second block 82 to first block 80.

Figure 7 illustrates an exemplary statechart that can accept user and/or machine inputs via textual entries. For example, a user may enter information via a command prompt and/or editor as opposed to a graphical input mechanism (e.g., a menu). The implementation of Figure 7 may include statechart 90, first block 92, second block 94, signal path 96 and history junction 98. Statechart 90 may be similar to statecharts 60 and 75 and first block 92 and second block 94 may be similar to first block 66/80 and second block 68/82, respectively. First block 92 may include a text-based definition statement (e.g., de: taskl^new mytask()). The definition statement may include information received from a keyboard or read from a storage device. First block 92 may read information related to the definition statement when performing processing related to taskl. In one implementation, first block 92 may instantiate taskl at runtime using the definition statement. First block 92 may generate an output that can be sent to second block 94 via signal path 96.

Second block 94 may include a definition statement (e.g., de: taks2=new mytask ()) and may read information related to the definition statement when performing processing related to task2. History junction 98 may include logic to identify where processing should begin when statechart 90 is run. For example, history junction 98 may store states and may use the stored states to indicate that processing should begin at first block 92 when statechart 90 is run a first time. History junction 98 may indicate that processing should begin at second block 94 when processing has been suspended and restarted. Implementations of history junction 98 may be configured to work with nested blocks, parallelized blocks, and/or other configurations of blocks. History junction 98 may further be configured to work across multiple statecharts if desired.

The present invention may be provided as one or more computer-readable programs embodied on or in one or more mediums. The mediums may be a floppy disk, a hard disk, a compact disc, a digital versatile disc, a flash memory card, a programmable read only memory (PROM)₃ a random access memory (RAM), a read only memory (ROM), or a magnetic tape. Computer -readable programs may be implemented in substantially any programming language. For example, object oriented programming languages (e.g., C++, Java, etc.) and/or other programming languages may be used (e.g., C, C#, Java, Perl, etc.). In addition, textual programming languages that allow dynamic typing and/or vectorized operations may be used. The software programs may be stored on or in one or more mediums as text and/or object code.

Implementations described herein may take alternate forms. For example, an implementation may represent variables as constants when a value associated with the variable remains fixed for a determined period of time. Implementations may receive an operator input or a system input to cause a variable to be replaced with a constant value. Replacing variables with constant values may increase operational speeds of applications and devices using implementations described herein.

Implementations may further preserve states, such as object states. In one implementation, a system (e.g., a desktop computer) may preserve a state for an instance of a state machine object. The system may retrieve the preserved state from memory and may reuse the preserved state in a statechart environment. In another implementation, a first system may preserve a state for an instance of a state machine object and may send the preserved state to another system so that the other system can use the preserved state in a statechart environment running on the other system. Still other implementations may take other forms.

The foregoing description of exemplary implementations of the invention provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. For example, while a series of acts has been described with regard to Figures 3 and 4, the order of the acts may be modified in other implementations consistent with the principles of the invention. Further, non-dependent acts may be performed in parallel. For example, implementations described herein can be implemented using devices and configurations other than those illustrated in the figures and described in the specification without departing from the spirit of the invention. Devices or components may be added or removed from the implementations of Figures 1 and 2 depending on specific deployments or applications. Further, disclosed implementations may not be limited to any specific combination of hardware. No element, act, or instruction used in the description of the invention should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article "a" is intended to include one or more items. Where only one item is intended, the term "one" or similar language is used. Further, the phrase "based on," as used herein is intended to mean "based, at least in part, on" unless explicitly stated otherwise.

The scope of the invention is defined by the claims and their equivalents.

Claims

We Claim:

1. A computer-implemented method of providing state machine objects in a statechart environment, said method comprising: receiving a graphical definition of a state machine object associated with a statechart; instantiating a first instance of the state machine object; and resolving symbols on a level of the first instance of the state machine object.

2. The method of claim 1, wherein the graphical definition of the state machine obj ect is a graphical definition of a state machine class.

3. The method of claim 2, wherein the state machine class is a part of a state machine class hierarchy.

4. The method of claim 2, wherein instantiating the first instance of the state machine object further comprises: instantiating the first instance of the state machine object during execution of the statechart.

5. The method of claim 1, wherein the graphical definition of the state machine object is an object template.

6. The method of claim 1 , further comprising: instantiating a second instance of the state machine object; stopping execution of the first instance of the state machine; and starting execution of the second instance of the state machine.

7. The method of claim 6, further comprising: receiving at the second instance a state configuration; and using the state configuration as a starting state configuration for the second instance.

8. The method of claim 6, wherein the state configuration is a last state configuration from the first instance or a state configuration from a previous execution of the second instance of the state machine object.

9. The method of claim 1 , wherein an instance of the state machine obj ect includes a state hierarchy with local data or local events

10. The method of claim 9, wherein symbol resolution is performed within a boundary of a state machine instance.

11. The method of claim 9, wherein symbol resolution is performed within the state chart containing the definition of the state machine object and external to a boundary of an instance of the state machine object.

12. The method of claim 1, further comprising: resolving symbols in the machine state object definition externally to the machine state object definition.

13. The method of claim 11 or 12, wherein resolving symbols further comprises resolving symbols during an execution of the statechart or resolving symbols during pre-processing.

14. The method of claim 1 wherein the definition of the state machine object comprises at least one of: default transition paths for an initial execution of the first instance of the state machine object and at least one default variable value for the initial execution of the first instance of the state machine object.

15. The method of claim 1, wherein the definition of the state machine object comprises a function to reset an instance of the state machine object to a first configuration.

16. The method of claim 15, wherein the first configuration is a configuration from a previous execution of the first instance of the state machine object, the method further comprising: following, by the first instance upon a subsequent execution, at least one default transition path.

17. The method of claim 1 wherein the definition of the state machine object comprises a function to retrieve a state configuration or local data in an instance of the state machine object.

18. The method of claim 1 wherein the definition of the state machine object comprises a function to set a state configuration or local data in an instance of the independent state machine object.

19. The method of claim 1 , further comprising: analyzing an instance of the state machine object to determine a total number of variables needed; and generating code for the state machine object instance using the total number of variables.

20. The method of claim 1, further comprising: identifying at least two of a plurality of instances of the state machine object containing variables able to share a memory location; and generating code for the at least two of the plurality of instances based on the identification.

21. The method of claim 1, further comprising: performing inline-analysis on an instance of the state machine object; and generating code for the instance based on the analysis.

22. A computer-implemented system for providing a state machine object in a statechart environment, said system comprising: a definition of a state machine object; a first instance of the state machine object instantiated from the definition of the state machine object; and at least one symbol in the first instance of the state machine object.

23. The system of claim 22, wherein the graphical definition of the state machine is a graphical definition of a state machine class.

24. The system of claim 23, wherein the state machine class is a part of a state machine class hierarchy.

25. The system of claim 22, wherein the graphical definition of the state machine is an object template.

26. The system of claim 22, wherein the at least one symbol in the first instance of the state machine object is resolved during an execution of the statechart or before the execution of the statechart.

27. The system of claim 26, wherein the at least one symbol is resolved within the first instance of the state machine object or externally to the first instance of the state machine object.

28. The system of claim 22, further comprising a second instance of the state machine object, the second instance starting execution from a state configuration.

29. The system of claim 27, wherein the state configuration is a state configuration from an execution of the first instance of the state machine object or a state configuration from an earlier execution of the second instance of the machine state object.

30. The system of claim 22, further comprising: generated code for the first instance of the state machine object.

31. A computer-readable medium holding instructions for providing state machine objects in a statechart environment, said instructions comprising: instructions for receiving a graphical definition of a state machine object associated with a statechart; instructions for instantiating a first instance of the state machine object; and instructions for resolving symbols on a level of the first instance of the state machine object.

32. The computer-readable medium of claim 31, wherein the graphical definition of the state machine object is a graphical definition of a state machine class or a template of a state machine object.

33. A system for providing state machine objects in a statechart environment, said system comprising: means for receiving a graphical definition of a state machine object associated with a statechart; means for instantiating a first instance of the state machine object; and means for resolving symbols on a level of the first instance of the state machine object.

34. The system of claim 33, wherein the graphical definition of the state machine object is a graphical definition of a state machine class or a template of the state machine object.