WO2001038978A1 - Configurable state machine driver and methods of use - Google Patents

Abstract

A configurable state machine driver part for assembling software components that implement state machine functionality (Fig. 1). The driver part provides a fine-granularity, easily reusable object that contains the fundamental functionality needed to implement state machines in a wide variety of software applications and systems (Fig. 4). The present invention provides a reusable software object that can be parameterized extensively without modifying its implementation or requiring source code, thus achieving the ability to modify and specialize its behavior to suit many different specific purposes as required (Fig. 8). Methods for using the part to design and implement state machines with various features are also disclosed.

Description

CONFIGURABLE STATE MACHINE DRIVER AND METHODS OF USE

BACKGROUND OF THE INVENTION This application claims priority from U.S. Provisional Patent Application No.

60/167,414, entitled CONFIGURABLE STATE MACHINE DRIVER, filed November 24,

2000, the disclosure of which is herein incorporated by reference.

1. Field of the Invention

The present invention relates generally to the field of object-oriented software engineering, and more specifically to configurable state machine drivers.

2. Description of the Related Art

Over the last twenty years, the object paradigm, including object-oriented analysis, design, programming and testing, has become the predominant paradigm for building software systems. A wide variety of methods, tools and techniques have been developed to support various aspects of object-oriented software construction, from formal methods for analysis and design, through a number of object-oriented languages, component object models and object-oriented databases, to a number of CASE systems and other tools that aim to automate one or more aspects of the development process.

With the maturing of the object paradigm, the focus has shifted from methods for programming akjects as abstract data types to methods for designing and building systems of interacting objects. As a result, methods and means for expressing and building structures of objects have become increasingly important. Object composition has emerged and is rapidly gaining acceptance as a general and efficient way to express structural relationships between objects. New analysis and design methods based on object composition have developed and most older methods have been extended to accommodate composition. Composition methods

The focus of object composition is to provide methods, tools and systems that make it easy to create new objects by combining already existing objects. An excellent background explanation of analysis and design methodology based on object composition is contained in

Real-time Object-Oriented Modeling (ROOM) by Bran Selic et al., John Wiley & Sons, New York, (1994), herein incorporated by reference, in which Selic describes a method and a

system for building certain specialized types of software systems using object composition.

Another method for object composition is described in HOOD : Hierarchical Object-

Oriented Design by Peter J. Robinson, Prentice-Hall, Hertfordshire, UK, 1992, and "Creating

Architectures with Building Blocks" by Frank J. van der Linden and Jϋrgen K. Miiller, IEEE

Software, 12:6, November 1995, pp. 51-60.

Another method of building software components and systems by composition is

described in a commonly assigned international patent application entitled "Apparatus,

System and Method for Designing and Constructing Software Components and Systems as Assemblies of Independent Parts", serial number PCT US96/19675, filed December 13,

1996, and published June 26, 1997, which is incorporated herein by reference and referred to

herein throughout as the '"675 application."

Yet another method that unifies many pre-existing methods for design and analysis of

object-oriented systems and has specific provisions for object composition is described in the OMG Unified Modeling Language Specification, version 1.3, June 1999, led by the Object

Management Group, Inc., 492 Old Connecticut Path, Framingham, MA 01701.

Composition-based development Composition - building new objects out of existing objects - is the natural way in which

most technical systems are made. For example, mechanical systems are built by assembling together various mechanical narts and electronic svstems are built by assembling and connecting chips on printed circuit boards. But today, despite its many benefits, the use of

composition to build software systems is quite limited. One reason for this is that supporting software design by composition has proven to be extremely difficult. Instead, inferior approaches, which are limited and often hard-to-use, have been used because they were easier to support. Approaches such as single and multiple inheritance, aggregation, etc., have been

widely used, resulting in fragile base classes, lack of reusability, overwhelming complexity,

high rate of defects and failures.

Early composition-based systems include HOOD (see earlier reference), ObjecTime

Developer by ObjecTime Limited (acquired by Rational Software Corp.), Parts Workbench

by Digitalk, and Parts for Java by ObjectShare, Inc. (acquired by Starbase Corp.). Each of these systems was targeted to solve a small subset of problems. None of them provided a

solution applicable to a broad range of software application types without severely impeding

their performance. Specifically, use of these systems was primarily in (a) graphical user interfaces for database applications and (b) high-end telecommunication equipment. One system that supports composition for a broad range of applications without performance impediments is the system described in the commonly assigned '675 application,

with which it is possible to create new, custom functionality entirely by composition and

without new program code. This system was commercialized in several products, including ClassMagic and DriverMagic, and has been used to create a variety of software components

and applications ranging from graphical user interface property sheets, through Microsoft

COM components, to various communications and device drivers.

Since 1996, other composition approaches have been attempted in research projects such as Espresso SCEDE by Faison Computing, Inc., and in commercial products such as Parts for Java by ParcPlace-Digitalk (later ObjectShare, Inc.), and Rational Rose RealTime by Rational Software Corp. None of these oroducts has been widelv accented or proven to be able to create commercial systems in a broad range of application areas. The only system known to the inventors that allows effective practicing of object composition in a wide area of

commercial applications is the system described in the '675 application. The system described in the '675 application and its commercial and other implementations are referred to hereinafter as the '"675 system."

State machines A state machine is a system with discrete inputs and outputs. The system can be in any

one of a finite number of internal states. The state of the system summarizes the information

concerning past inputs that is needed to determine the behavior of the system on subsequent inputs. State machines are widely used in electronics and computer systems. Frequently,

they are implemented in hardware. One of the simplest state machines is a bit of computer

memory. It has two states, 0 and 1. Inputs to the bit can be "set-to-0", "set-to-1" and "invert".

The output is a value, 0 or 1. Every digital system contains a large number of state machines of varying complexity. In software, state machines are traditionally used in text parsing and communication protocols. Most modern compilers for computer languages use state machines to parse the

input program and properly generate the corresponding machine instructions.

Communication protocol software uses state machines to control and ensure reliable

communication between two or more network nodes over unreliable communication links. Another wide-spread use of state machines is in embedded computer software which

typically controls various electro-mechanical devices, such as elevators, car anti-lock brakes,

industrial robots and many others. Such software accepts input from various sensors and exerts control using actuators. The device controlled by this software needs to respond predictably and within a predetermined amount of time to various events that occur in the physical world. In embedded software, state machines are mostly used to determine what the response of the controlled system needs to be, depending on the incoming stimulus (input)

and the history of previous incoming stimuli (as represented by the state). In addition, state

machines can improve the deterministic response time of the controlled devices - the unified

model of choosing an output reaction based on input and state replaces arbitrarily complex

sequence of nested if-then-else conditions.

In all of the above examples, state machines solve a problem that is not adequately addressed by the predictable, sequential nature of software. The software programs in these

examples can receive non-deterministic input and must be able to provide adequate reaction. Furthermore, in applications such as communication protocols and embedded software, the

input is not always available when the program needs it, but can arrive at any time, or even not arrive at all.

State machines, and the underlying mathematical theory of finite automata, enable

software systems to be designed and implemented so that they can adequately process non-

deterministic or semi-deterministic input reliably. Formal methods associated with the finite automata theory help ensure that the software designer has taken into account all possible combinations of input and state, increasing at least the theoretical reliability of the software systems designed using these methods. By providing much higher predictability, reliability

and determinism, state machines have become critical components of practically all

advanced, complex and high-performance software systems today. State machines are typically implemented in software by assigning one or more variables as "state" variables, and providing individual functions for each input. The output is represented by the various actions taken by the input functions, depending on the state

variables. More sophisticated implementations designate a separate function for each

input/state combination that needs to be served and the function to be invoked on each input is determined by indexing a table with the innut and current state values. These methods of implementing state machines, although widely used, bring about several important problems. Most of the problems stem from the fact that each different state

machine requires separate, custom software code to be written, tailored specifically for that

state machine. Translating state machines to code by hand is an extremely complicated, time- consuming and error-prone activity. It requires significant amount of effort from highly

qualified software engineers. Unlike the state machine design process, the translation of a

state machine to code is not a well formalized process and frequently invites personal judgment, interpretation and errors. This method of implementing state machines also makes

it possible that a state machine may be translated to code differently by two different engineers, and may have subtly different behavior, causing interoperability problems between

products of different vendors, or even between different releases of one and the same product.

Other methods for implementing state machines, such as the lex and yacc Unix utilities,

generate program code automatically by processing a more or less formal description of the

state machine. This approach requires that the application area be limited (in the case of lex

and yacc, to parsing of lexemes and computer language grammar). Furthermore,

interoperability problems may be caused by different implementations and subtle defects in

the translation utilities. Also, these utilities generate program code that needs to be further translated to machine code by a compiler; this limits the ability of modifying the state

machine at run-time. Finally, this approach has the problem inherent to all code generating

tools: it quickly increases the total amount of code that needs to be loaded in the system and maintained by software engineers.

Another problem that arises when implementing state machines is a problem with the state machine model. The theory looks at the state machine as an ideal automaton in which

all inputs and outputs are unidirectional and carry no data, and in which all transitions are atomic and take zero time. In practice, a software system has to deal with many real-world issues:

1. Inputs may be bi-directional, requiring a synchronous response that indicates the

success or failure of the input request and/or provide response data; 2. Inputs typically carry data (e.g., the payload of a network packet that arrived in the system);

3. Outputs may be bi-directional, where the action taken by the state machine may succeed or fail;

4. Outputs may need to carry data; 5. As the actions taken by the software during processing of an input are non-atomic, another input may enter the software implementation before the processing of the previous

input has completed, causing subtle and hard-to-find defects;

6. As the actions are embedded in the code that ensures the proper operation of the state

machine, the actions cannot be changed without danger of affecting the state machine

operation, nor the state machine can be easily changed while preserving the actions.

While many of these problems are resolvable through theoretical knowledge, large

amount of practical experience and significant engineering effort, they severely limit the

practice of using state machines in most commercial systems and cause significant harm in cost, reliability and interoperability where state machines are actually used in the implementation.

Further information on state machines and finite automata as used in today's computer

systems for various purposes is available in the following publications, the disclosures of which are herein incorporated by reference:

• Introduction to Automata Theory. Languages and Computation, ISBN 0-201-02988-

X, by John E. Hopcroft and Jeffrev D. Ullman. 1979. Addison- Wesley; • Digital Logic and State Machine Design. ASIN 0-03-094904- 1 , by David J. Comer, 1995, Saunders College Publishing;

• Lex & Yacc, ISBN 1-565-92000-7, by John R. Levine et al., 1992, O'Reilly & Associates, Inc. Sebastopol, California;

• 8802-2 : 1994 (ISO/TEC) fANSI/TEEE 802.2. 1994 Editionl Information technology-

Telecommunications and information exchange between systems— Local and Metropolitan area networks— Specific requirements— Part 2: Logical link control, an IEEE standard.

State machines in object-oriented software As understood by many practitioners, object-oriented programming is orthogonal to the application of state machines: i.e. there is no intersection between the two. This is, of course,

false, and many respected texts relate the two, usually by associating the behavior of an object

with a state transition diagram, also known as a statechart.

Objects and their close cousins, the components, are extremely good embodiments of state machines. Unlike traditional, structured programming code, objects provide well-

defined boundaries for state machines. Just like state machines, objects typically have inputs

and, in some object models, outputs. All objects have formally defined state, which

represents the history of inputs that had been applied to the object and provide sufficient information to determine how the object must react on a subsequent input. Object-oriented

systems also provide a model and a system for instantiating state machines. This model allows a program to create more than one instance of a given state machine by using the same

code among all instances of the state machine.

While this makes the outside boundary of a state machine better defined and reproducible across different implementations, object-oriented methods and systems provide nothing to support the implementation of «tatι^» tτmr-hin^p« ⁽nth^r than t p instantiation of state variables). All implementation problems described in the previous section remain: manual translation to code, subtle defects and interoperability problems, model inconsistencies, and race conditions. Even greater expertise is required to implement state machines in object systems: in order to implement a state machine properly within a given object model, the engineer

needs to be experienced both in object-oriented methods and in state machines. As a result,

while state machine models are frequently used in the analysis and design of object-oriented systems, objects are rarely implemented using state machine formalisms.

State machines are extremely important in real-time systems. Some object-oriented development systems targeting real-time applications, such as ObjecTime Developer and I-

Logix Rhapsody, provide support for implementing state machines. They allow the engineer

to define a state machine using a state transition diagram, and then enter action-specific code that needs to be executed on each transition. The development system then generates code that implements the defined state machine. While this approach is a significant advancement over the lex and yacc approach described above, it carries many of the same problems. First,

for each state machine, a separate, custom code fragment or file is being generated, which

increases the total footprint of the compiled system, slows the system down by reducing instruction cache hits, and adds more code to be maintained. Second, the state machine is

fixed at system built time and cannot be modified at run-time. Also, this approach combines the code that implements the state machine itself with the action code specific for the given

object. Moreover, the solution is limited to the specific application area for which the development system is targeted. And finally, most of the model-related problems described earlier remain.

The root of most of these problems lies in the lack of separation of the state machine itself and the code that executes the actions required as output of the state machine operation. Yet another problem with the state machines supported bv these development systems is that they impose a very rigid threading model on the implementation. Typically the input to the state

machine is queued and the state machine runs in a single thread. In the cases where a dedicated thread and a queue are assigned to each state machine, this model increases significantly the resource requirements to the system, both in memory and processing power, and effectively prohibits the use of state machine implementations for all but the most

complex state machines in a given system. In the cases where a common thread is shared

between all state machines, this model significantly reduces the ability of the system to respond to events in real time and in a deterministic fashion, which also results in engineers

not using state machine-based implementations as often as they are needed.

SUMMARY OF THE INVENTION In general, the present invention is a configurable state machine driver part for assembling software components that implement state machine functionality and methods of use for the driver part. The driver part provides a fine-granularity, easily reusable object that

contains the fundamental functionality needed to implement state machines in a wide variety

of software applications and systems. The present invention further provides a reusable

software object that can be parameterized extensively without modifying its implementation or requiring source code, thus achieving the ability to modify and specialize its behavior to

suit many different specific purposes as required. Methods for using the part to design and

implement state machines with various features are also provided.

More particularly, in one implementation the present invention can be configured as a

part in a software system, the part comprising a first terminal for receiving state machine inputs, a second terminal for sending state machine action events, a state variable for keeping the current state of a state machine, a property for configuring said part with a state transition table, means for changing the value of said state variable based on a first input received through said first terminal and based on the value of said state variable at the time said first input was received, and means for choosing either one or no action event to be sent through

said second terminal based on said first input and based on the value of said state variable at the time said first input was received.

The present invention includes a method for designing a state machine in a software system. The method comprises designing a state machine driver object class that receives at

least one first state machine input, keeps at least one state variable, performs at least one state

transition, and emits at least one first state machine output. The method further comprises

designing an action handler object class that receives at least one second input and takes one or more actions in response to said at least one second input, and designing a structure of

connected objects in which an instance of said state machine object class is connected to an instance of said action handler object class so that said first state machine output is received

as said second input.

The present invention also includes a method for implementing a hierarchical state machine in a software system, wherein the software system contains a plurality of state machine driver objects and the hierarchical state machine has a plurality of master states and

a plurality of subordinate states. The method comprises creating a first state machine driver

object that controls said plurality of master states and creating a second state machine driver object that controls said plurality of subordinate states.

Alternatively, the present invention includes a method for designing a state machine in a software system, said software system having at least one object class and having at least

one configurable state machine driver class, said method comprising designing a state

transition chart for said state machine, identifying the state machine actions that need to be performed on the state transitions, converting said state transition chart to a state machine descriptor in a format required bv said confieurable state machine driver class, designing an action handler class that implements the identified state machine action, and designing a

structure of connected instances that includes at least an instance of said configurable state machine driver class and an instance of said action handler class.

These and other embodiments and alternatives of the present invention are described in further detail below.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be readily understood by the following detailed description in conjunction with the accompanying drawings, wherein like reference numerals designate like structural elements, and in which:

Figure 1 illustrates a preferred boundary of a DM FSM part constructed according to the present invention;

Figure 2 illustrates an advantageous use of the DM_FSM part;

Figure 3 illustrates the internal structure of a state machine assembly utilizing the

present DM FSM part;

Figure 4 illustrates an application of the DM FSM part;

Figure 5 illustrates an advantageous use of the DM FSM part in which a synchronous

event buffer with a postpone, SEBP, is used to buffer events that cannot be accepted in the

current state; Figure 6 illustrates using reusable parts to reduce the size of the state machine table of the present DM_FSM part;

Figure 7 illustrates the use of a pre-processor to translate incoming events to inputs on

the inventive DM FSM part;

Figure 8 illustrates an application of the present DM FSM part to handle events from two event streams; Figure 9 illustrates the use of the present DM FSM part to build a hierarchical state

machine;

Figure 10 is a state transition diagram for the sample hierarchical state machine of

Figure 9; Figure 11 illustrates the use of the present DM_FSM part to build a pair of synchronized state machines;

Figure 12 is a state transition diagram for a sample device controller state machine;

and

Figure 13 is a state transition diagram for a sample lexical analyzer state machine.

DETAILED DESCRIPTION OF THE INVENTION

The following description is provided to enable any person skilled in the art to make

and use the invention and sets forth the best modes contemplated by the inventor for carrying

out the invention. Various modifications, however, will remain readily apparent to those

skilled in the art, since the basic principles of the present invention have been defined herein

specifically to provide a configurable state machine driver and methods of use. Any and all such modifications, equivalents and alternatives are intended to fall within the spirit and

scope of the present invention.

Glossary The following definitions are provided to assist the reader in comprehending the

following description of a preferred embodiment of the present invention. All of the following definitions are presented as they apply in the context of the present invention.

Adapter apart which converts one interface, logical connection contract and/or physical connection mechanism to another. Adapters are used to establish connections between parts that cannot be

connected directly because of incompatibilities.

Alias an alternative name ox path representing apart, terminal or

property. Aliases are used primarily to provide alternative identification of an entity, usually encapsulating the exact structure of the original name or path.

Assembly a composite object most of the functionality of which is provided

by a contained structure of interconnected parts. In many cases

assemblies can be instantiated by descriptor and do not require

specific program code.

Bind or binding an operation of resolving a name of an entity to a pointer, handle or other identifier that can be used to access this entity. For example, a

component factory provides a bind operation that gives access to

the factory interface of an individual component class by a name associated with it.

Bus, part a part which provides a many-to-many type of interaction between other parts. The name "bus" comes from the analogy with network

architectures such as Ethernet that are based on a common bus through which every computer can access all other computers on the network.

Code, automatically generated program code, such as functions or parts of functions, the source code for which is generated by a computer program.

Code, general purpose program code, such as functions and libraries, used by or on more thf" ^r,*nfi flαcc rsf r Wi^prio COM an abbreviation of Component Object Model, a component model defined and supported by Microsoft Corp. COM is the basis of OLE2 technologies and is supported on all members of the

Windows family of operating systems.

Component an instantiable object class or an instance of such class that can be manipulated by general purpose code using only information

available at run-time. A Microsoft COM object is a component, a Win32 window is a component; a C++ class without run-time type

information (RTTI) is not a component.

Component model(s) a class of object model based on language-independent definition of objects, their attributes and mechanisms of invocation. Unlike object-oriented languages, component models promote modularity

by allowing systems to be built from objects that reside in different

executable modules, processes and computers.

Connecting process of establishing a connection between terminals of two parts in which sufficient information is exchanged between the parts to establish that both parts can interact and to allow at least

one of the parts to invoke services of the other part.

Connection an association between two terminals for the purposes of transferring data, invoking operations or passing events.

Connection broker an entity that drives and enforces the procedure for establishing connections between terminals. Connection brokers are used in the

present invention to create connections exchanging the minimum necessary information between the objects being connected.

Connection, direction of a characteristic of a connection defined by the flow of control on it. Connections can be uni-directional, such as when only one of the

participants invokes operations on the other, or bi-directional, when each of the participants can invoke operations on the other one.

Connection, direction of data flow a characteristic of a connection defined by the dataflow on it. For

example, a function call on which arguments are passed into the function but no data is returned has uni-directional dataflow as

opposed to a function in which some arguments are passed in and

some are returned to the caller .

Connection, logical

contract a defined protocol of interaction on a connection recognized by more than one object. The same logical contract may be implemented using different physical mechanisms.

Connection, physical

mechanism a generic mechanism of invoking operations and passing data through connections. Examples of physical mechanisms include

function calls, messages, v-table interfaces, RPC mechanisms, inter-process communication mechanisms, network sessions, etc.

Connection point see terminal.

Connection,

synchronosity a characteristic of a connection which defines whether the entity that invokes an operation is required to wait until the execution of the operation is completed. If at least one of the operations defined by the logical contract of the connection must be synchronous, the connection is assumed to be synchronous,

Container an object which contains other objects. A container usually

provides interfaces through which the collection of multiple objects that it contains can be manipulated from outside,

Control block see Data bus.

CORBA Common Object Request Broker Architecture, a component model

architecture maintained by Object Management Group, Inc., a consortium of many software vendors.

Critical section a mechanism, object or part the function of which is to prevent

concurrent invocations of the same entity. Used to protect data

integrity within entities and avoid complications inherent to multiple threads of control in preemptive systems,

Data bus a data structure containing all fields necessary to invoke all operations of a given interface and receive back results from them.

Data buses improve understandability of interfaces and promote

polymorphism. In particular interfaces based on data buses are easier to de-synchronize, convert, etc.

Data flow direction in which data is being transferred through a function call,

message, interface or connection. The directions are usually

denoted as "in", "out" or "in-out", the latter defining a bidirectional data flow.

Descriptor table an initialized data structure that can be used to describe or to direct a process. Descriptors are especially useful in conjunction with general rmrnnse nroσram c. sΛe. T Tsing properly designed descriptor tables, such code can be directed to perform different functions in a flexible way .

De-serialization part of a persistency mechanism in object systems. A process of

restoring the state of one or more objects from a persistent storage

such as file, database, etc. See also serialization.

De-synchronizer a category of parts used to convert synchronous operations to

asynchronous. Generally, any interface with unidirectional data flow coinciding with the flow of control can be de-synchronized using such a part.

Event in the context of a specific part or object, any invocation of an operation implemented by it or its subordinate parts or objects.

Event-driven designs model objects as state machines which

change state or perform actions in response to external events. In the context of a system of objects, a notification or request typically

not directed to a single object but rather multicast to, or passed through, a structure of objects. In a context of a system in general,

an occurrence.

Event, external An event caused by reasons or originated outside of the scope of a

given system.

Execution context State of a processor and, possibly of regions of memory and of system software, which is not shared between streams of processor

instructions that execute in parallel. Typically includes some but

not necessarily all processor registers, a stack, and, in multithreaded operating systems, the attributes of the specific thread, such as nrinritv. secnritv etc. Factory- abstract a pattern and mechanism for creating instances of objects under the

control of general purpose code. The mechanism used by OLE COM to create object instances is an abstract factory; the operator "new" in C++ is not an abstract factory .

Factory, component

or part portion of the program code of a component ox part which handles creation and destruction of instances. Usually invoked by an external abstract factory in response to request(s) to create or destroy instances of the given class,

Flow of control a sequence of nested function calls, operation invocations,

synchronous messages, etc. Despite all abstractions of object-

oriented and event-driven methods, on single-processor computer systems the actual execution happens strictly in the sequence of the

flow of control.

Group property a property used to represent a set of other properties for the

purposes of their simultaneous manipulation. For example, an

assembly containing several parts may define a group property

through which similar properties of those parts can be set from outside via a single operation.

Indicator a category of parts that provides human-readable representation of the data and operations that it receives. Used during the development process to monitor the behavior of a system in a given

point of its structure,

Input a terminal with incoming flow of control. As related to terminals, directional attributes such as incoming and outgoing are always defined from the viewpoint of the object on which the terminal is defined.

Interaction an act of transferring data, invoking an operation, passing an event,

or otherwise transfer control between objects, typically on a single connection between two terminals.

Interaction, incoming in a context of a given object, an interaction that transfers data,

control or both data and control into this object. Whenever both

control and data are being transferred in one and the same interaction, the direction is preferably determined by the direction of the transfer of control.

Interaction, outgoing in a context of a given object, an interaction that transfers data,

control or both data and control out of this object. Whenever both

control and data are being transferred in one and the same interaction, the direction is preferably determined by the direction

of the transfer of control

Interface a specification for a set of related operations that are implemented

together. An object given access to an implementation of an

interface is guaranteed that all operations of the interface can be invoked and will behave according to the specification of that interface.

Interface,

message-based an interface the operations of which are invoked through messages

in message-passing systems. "Message-based" pertains to a physical mechanism of access in which the actual binding of the requested operation to code that executes this operation on a given object is performed at call time.

Interface, OLE COM a standard of defining interfaces specified and enforced by COM.

Based on the virtual table dispatch mechanism supported by C++ compilers.

Interface, remoting a term defined by Microsoft OLE COM to denote the process of

transferring operations invoked on a local implementation of an interface to some implementation running on a different computer

or in a different address space, usually through an RPC mechanism.

Interface, v-table a physical mechanism of implementing interfaces, similar to the one specified by OLE COM.

Marshaler a category of parts used to convert an interface which is defined in the scope of a single address space to a logically equivalent

interface on which the operations and related data can be transferred between address spaces.

Multiplexor a category of parts used to direct a flow of operations invoked on

its input through one of several outgoing connections. Multiplexors

are used for conditional control of the eve«t flows in structures of interconnected parts .

Name a persistent identifier of an entity that is unique within a given scope. Most often names are human-readable character strings; however, other values can be used instead as long as they are persistent.

Name space the set of all defined names in a given scope. Name space, joined a name space produced by combining the name spaces of several parts. Preferably used in the present invention to provide unique

identification of properties and terminals of parts in a structure that

contains those parts.

Object, composite an object that includes other objects, typically interacting with each other. Composites usually encapsulate the subordinate objects,

Output a terminal with outgoing flow of control. See also Input.

Parameterization a mechanism and process of modifying the behavior of an object by

supplying particular data values for attributes defined by the object,

Part an object or a component preferably created through an abstract factory and having properties and terminals. Parts can be assembled into structures at run-time.

Property a named attribute of an object exposed for manipulation from

outside through a mechanism that is not specific for this attribute or

object class.

Property interface an interface which defines the set of operations to manipulate properties of objects that implement it. Typical operations of a

property interface include: get value, set value, and enumerate properties.

Property mechanism a mechanism defining particular ways of addressing and accessing properties. A single property interface may be implemented using different property mechanisms, as it happens with parts and

assemblies. Alternatively, the same property mechanism can be exposed through a number of different roperty interfaces. Proxy program code, object or component designed to present an entity or a system in a way suitable for accessing it from a different system.

Compare to a wrapper.

Repeater a category of parts used to facilitate connections in cases where the number of required connections is greater than the maximum

number supported by one or more of the participants.

Return status a standardized type and set of values returned by operations of an interface to indicate the completion status of the requested action,

such as OK, FAILED, ACCESS VIOLATION, etc.

Serialization part of a persistency mechanism in object systems. A process of

storing the state of one or more objects to persistent storage such as file, database, etc. See also de-serialization.

Structure of parts a set of parts interconnected in a meaningful way to provide specific functionality.

Structured storage a mechanism for providing persistent storage in an object system where objects can access the storage separately and independently

during run-time.

Terminal a named entity defined on an object for the purposes of establishing

connections with other objects.

Terminal, cardinality the maximum number of connections in which a given terminal can

participate at the same time. The cardinality depends on the nature of the connection and the way the particular terminal is implemented. Terminal, exterior a terminal, preferably used to establish connections between the

part to which it belongs and one or more objects outside of this part.

Terminal, interior a terminal, of an assembly, preferably used to establish connections between the assembly to which it belongs and one or more subordinate objects of this assembly.

Terminal interface an interface which defines the set of operations to manipulate terminals of objects that implement it.

Terminal mechanism a mechanism defining particular ways of addressing and connecting

terminals. A single terminal interface may be implemented using

different terminal mechanisms, as happens with arts and assemblies.

Thread of execution a unit of execution in which processor instructions are being executed sequentially in a given execution context. In the absence

of a multithreaded operating system or kernel, and when interrupts are disabled, a single-processor system has only one thread of

execution, while a multiprocessor system has as many threads of

execution as it has processors. Under the control of a multithreaded operating system or kernel, each instance of a system thread object defines a separate thread of execution.

Wrapper program code, object or component designed to present an entity or

a system in a way suitable for inclusion in a different system. Compare to a proxy. The preferred embodiment of the present invention is implemented as software component objects (parts). The present part is preferably used in conjunction with the

method and system described in the '675 application, as well as with parts described in U.S.

Patent Application Serial No. 09/640,898, entitled SYSTEM OF REUSABLE SOFTWARE

PARTS AND METHODS OF USE, filed August 16, 2000, and in PCT Patent Application Serial No. US00/22630, entitled SYSTEM OF REUSABLE SOFTWARE PARTS FOR

IMPLEMENTING CONCURRENCY AND HARDWARE ACCESS, AND METHODS OF USE, the disclosures of which are herein incorporated by reference.

The terms ClassMagic and DriverMagic, used throughout this document, refer to commercially available products incorporating the inventive "System for Constructing

Software Components and Systems as Assemblies of Independent Parts" (referenced above) in general, and to certain implementations of that system. Moreover, an implementation of the system is described in the following product manuals:

• "Reference - C Language Binding - ClassMagic™ Object Composition Engine", Object Dynamics Corporation, August 1998, which is incorporated herein in its

entirety by reference;

• "User Manual - User Manual, Tutorial and Part Library Reference - DriverMagic

Rapid Driver Development Kit", Object Dynamics Corporation, August 1998, which is incorporated herein in its entirety by reference;

• "Advanced Part Library - Reference Manual", version 1.32, Object Dynamics

Corporation, July 1999, which is incorporated herein in its entirety by reference;

• "WDM Driver Part Library - Reference Manual", version 1.12, Object Dynamics Corporation, July 1999, which is incorporated herein in its entirety by reference. Appendix 1 describes preferred interfaces used by the parts described herein.

1. Events

One inventive aspect of the present invention is the ability to represent many of the

interactions between different parts in a software system in a common, preferably

polymorphic way, called event objects, or events. Events provide a simple method for associating a data structure or a block of data, such as a received buffer or a network frame, with an object that identifies this structure, its contents, or an operation requested on it. Event objects can also identify the required distribution discipline for handling the event, ownership

of the event object itself and the data structure associated with it, and other attributes that may simplify the processing of the event or its delivery to various parts of the system. Of

particular significance is the fact that event objects defined as described above can be used to express notifications and requests that can be distributed and processed in an asynchronous

fashion.

The term "event" as used herein most often refers to either an event object or the act of

passing of such object into or out of a part instance. Such passing preferably is done by

invoking the "raise" operation defined by the I DRAIN interface, with an event object as the operation data bus. The I DRAIN interface is a standard interface as described in the '675 application, it has only one operation - "raise", and is intended for use with event objects. A

large portion of the parts described in this application are designed to operate on events. Also in this sense, "sending an event" refers to a part invoking its output I DRAIN terminal and

"receiving an event" refers to a part's I_DRAIN input terminal being invoked. 1.1. Event Objects

An event object is a memory object used to carry context data for requests and for

notifications. An event object may also be created and destroyed in the context of a hardware interrupt and is the designated carrier for transferring data from interrupt sources into the normal flow of execution in systems based on the '675 system. An event object preferably

consists of a data buffer (referred to as the event context data or event data) and the following "event fields":

. event ID - an integer value that identifies the notification or the request.

size - the size (in bytes) of the event data buffer.

. attributes - an integer bit-mask value that defines event attributes. Half of the bits in

this field are standard attributes, which define whether the event is intended as a

notification or as an asynchronous request and other characteristics related to the use

of the event's memory buffer. The other half is reserved as event-specific and is defined differently for each different event (or group of events).

• status - this field is used with asynchronous requests and indicates the completion status of the request (see the Asynchronous Requests section below).

The data buffer pointer identifies the event object. Note that the "event fields" do not necessarily reside in the event data buffer, but are accessible by any part that has a pointer to the event data buffer. The event objects are used as the operation data of the I_DRAIN

interface's single operation - raise. This interface is intended for use with events and there

are many parts that operate on events.

The following two sections describe the use of events for notifications and for asynchronous requests. 1.2. Notifications

Notifications are "signals" that are generated by parts as an indication of a state change or

the occurrence of an external event. The "recipient" of a notification is not expected to

perform any specific action and is always expected to return an OK status, except if for some reason it refuses to assume responsibility for the ownership of the event object.

The events objects used to carry notifications are referred to as "self-owned" events

because the ownership of the event object travels with it, that is, a part that receives a

notification either frees it when it is no longer needed or forwards it to one of its outputs.

1.3. Asynchronous Requests

Using event objects as asynchronous requests provides a uniform way for implementing an essential mechanism of communication between parts:

. the normal interface operations through which parts interact are in essence function

calls and are synchronous, that is, control is not returned to the part that requests the

operation until it is completed and the completion status is conveyed to it as a return status from the call.

• the asynchronous requests (as the name implies) are asynchronous, control is returned

immediately to the part that issues the request, regardless of whether the request is

actually completed or not. The requester is notified of the completion by a "callback", which takes a form of invoking an incoming operation on one of its terminals, typically, but not necessarily, the same terminal through which the original request was issued. The "callback" operation is preferably invoked with a pointer to the

original event object that contained the request itself. The "status" field of the event

object conveys the completion status. Many parts are designed to work with asynchronous requests. Note, however that most events originated by parts are not asynchronous requests - they are notifications or

synchronous requests. An event recoder part, in combination with other parts may be used to transform notifications into asynchronous requests.

The following special usage rules preferably apply to events that are used as asynchronous requests:

1. Requests are used on a symmetrical bi-directional I DRAIN connection.

2. Requests may be completed either synchronously or asynchronously.

3. The originator of a request (the request 'owner') creates and owns the event object. No

one except the 'owner' may destroy it or make any assumptions about its origin.

4. A special data field may be reserved in the request data buffer, referred to as "owner context" - this field is private to the owner of the request and may not be overwritten by

recipients of the request.

5. A part that receives a request (through an I_DRAIN.raise operation) may:

a) Complete the request by returning any status except ST PENDING (synchronous

completion);

b) Retain a pointer to the event object and return ST_PENDING. This may be done only

if the 'attr' field of the request has the CMEVT_A_ASYNC_CPLT bit set. In this case, using

the retained pointer to execute I DRAIN.raise on the back channel of the terminal through which the original request was received completes the request. The part should store the completion status in the "status" event field and set the CMEVT A COMPLETED bit in the "attributes" field before completing the request in this manner. 6. A part that receives a request may re-use the request's data buffer to issue one or more requests through one of its I_DRAIN terminals, as long as this does not violate the rules

specified above (i.e., the event object is not destroyed or the owner context overwritten and the request is eventually completed as specified above).

Since in most cases parts intended to process asynchronous requests may expect to receive any number of them and have to execute them on a first-come-first-served basis, such

parts are typically assembled using desynchronizers which preferably provide a queue for the pending requests and take care of setting the "status" field in the completed requests.

1.4. The notion of event as invocation of an interface operation

It is important to note that in many important cases, the act of invoking a given operation

on an object interface, such as a v-table interface, can be considered an event, similar to the events described above. This is especially true in the case of interfaces which are defined as

bus-based interfaces; in such interfaces, data arguments provided to the operation, as well as, data returned by it, is exchanged by means of a data structure called bus. Typically, all

operations of the same bus-based interface are defined to accept one and the same bus structure.

Combining an identifier of the operation being requested with the bus data structure is

logically equivalent to defining an event object of the type described above. And, indeed,

some of the reusable parts use this mechanism to convert an arbitrary interface into a set of

events or vice- versa.

The importance of this similarity between events and operations in bus-based interfaces becomes apparent when one considers that it allows to apply many of the parts, design patterns and mechanisms for handling, distributing, desynchronizing and otherwise processing flows of events, t" ^αnv hnc-hao^H interf* τ« thio manner, an outgoing interaction on a part that requires a specific bus-based interface can be distributed to multiple parts, desynchronized and processed in a different thread of execution, or even converted to

an event object. In all such cases, the outgoing operation can be passed through an arbitrarily

complex structure of parts that shape and direct the flow of events and delivered to one or

more parts that actually implement the required operation of that interface, all through the use of reusable software parts.

2. Timers

Another inventive aspect of the present invention is that the time-based transitions in state

machines may be initiated not by the state machine driver itself but by an external reusable

part, called a "timer." Timers are event sources that generate outgoing events spontaneously, upon expiration of a given period of time, as is the case with a watchdog timer, or

periodically on some time interval, as is the case with a periodic timer. When assembled in

structures with other parts, timers provide the ability to perform time-dependent functionality,

such as timeouts, in response to events generated by them.

Timers preferably have a bi-directional terminal, through which they generate, or "fire", outgoing events and receive control events, preferably "enable" and "disable". In addition, timers preferably define properties through which their operation can be parameterized, such

as the time period, periodic versus watchdog mode of operation, and others. Other means of

controlling the operation of the timer are possible.

When assembled in a structure with other parts, a timer preferably remains inactive until it receives the first "enable" event from one of these parts. After becoming enabled, the timer

will generate one or more outgoing events, which are used by other parts to perform their operations. At some point in time, even before the timer generates its first outgoing event, a part other than the timer may generate a "disable" event. On receiving this event, the timer becomes disabled and does not generate outgoing events until enabled again. Reusable timers have many advantages, among them the ability to insulate the rest of the application from an

important class of operating system or hardware-dependent interactions.

3. DM_FSM - CONFIGURABLE STATE MACHINE DRIVER

3.1. Functional overview

The DM FSM of the present invention is a configurable finite state machine driver that maintains the current state and performs state transitions for a state machine implementation. This eliminates the requirement for state machine handlers to have specific knowledge about

the current state, next state, or the set of events and transitions allowed in the current state.

The state machine that DM_FSM drives is specified by a descriptor and passed to the

DM FSM as a property. The descriptor contains information about the possible states and the set of possible events that can be received in each state. For each (state, event) pair, the

descriptor specifies the next state and an action to be taken. Each action may contain

additional information that the DM FSM needs to carry out the specified action. Preferably

one action may be specified for each (state, event) pair.

When the DM FSM receives events on its "in" terminal, it locates in the descriptor the corresponding (state, event) pair, makes the specified state transition, and performs the specified action. The DM FSM may emit notifications out its "nfy" terminal upon entering a

state, and leaving a state. The notifications may be useful to synchronize the state of multiple state machines. The DM FSM may not be re-entered with the process of sending "enter

state" and "leave state" notifications. This is to prevent actions from being executed in the wrong order. In addition, the DM FSM generates an additional notification out its nfy terminal upon any state transition after the action has been performed. The DM FSM is parameterized with

the event ID that it sends. The DM FSM may be re-entered during the context of sending this notification.

3.2. Boundary

The preferred boundary of the DM FSM is illustrated in Fig. 1.

Terminals

Name Dir Type Notes in 1° I DRAIN Incoming events are received on this terminal which prompt the DM FSM to perform some action based on the current state and the event received.

O_ut Out DRAIN Events are sent out this terminal as specified by the action taken for a specific (state, incoming event) pair.

Nf Out j DRAIN Output for state transition notifications. This terminal may remain unconnected.

Events and notifications

The events and notifications that the DM FSM receives on its in terminal and/or generates out its out terminal are specified in the state machine descriptor that parameterizes the DM_FSM.

The DM_FSM sends the following events out its nfy terminal:

Outgoing Event Bus Description

(enter_state_id) CMEVENT This ^{event is sent u}P^on

HDR entering a state. The event

^~ ID is specified in the state machine descriptor. Outgoing Event Bus Description

(leave_state_id) CMEVENT This event is sent upon HDR leaving a state. The event

ID is specified in the state machine descriptor.

(state_chg_ev) CMEVENT This event is sent upon any

HDR state transition after the DM FSM has performed the required action. The ID is specified by the state_chg_ev property.

EV EXCEPTION B EV EXC The DM_FSM has found an error in the state machine descriptor during operation or has failed to allocate memory when generating an event.

The exception data contains two DWORD fields that contain the following information:

• Current State ID

• Incoming Event ID

Preferred Event Structure

The events received and sent by the DM FSM are preferably defined to have a common

header, as described below. Other event definitions may be used, as appropriate for the target

system.

Struct CMEVENT HDR

{ unsigned sz; // size of event, bytes unsigned id; // event ID unsigned attr; // attributes, CMEVT A xxx

} ;

The following attribute may be defined: #define CMEVT A COMPLETED 1 Property name Type Notes

Initial state uint32 Identifier for initial state. The default value is 0.

Unrecognized_s uint32 Status returned for unrecognized incoming events. The default value is CMST_NOT_SUPPORTED.

Busy_s uint32 Status returned for incoming events when the DM FSM is in a non-atomic state while sending enter/leave state notifications. The default value is CMST UNEXPECTED.

State_chg_ev uint32 Specifies the event ID that the DM FSM sends out its nfy terminal on each state transition. If the value is 0, the DM_FSM does not generate "state changed" notifications. The default value is 0.

Gen attr and uint32 The DM FSM performs a logical AND between this value and the incoming event attributes when setting the attributes for a generated event. This property must not contain the CMEVT_A_ASYNC_CPLT and CMEVT_A_COMPLETED attributes. The default is

~(CMEVT_A_ASYNC_CPLT | CMEVT_A_COMPLETED).

Gen attr or uint32 The DM FSM performs a logical OR between this value and the incoming event attributes when setting the attributes for a generated event. This property must not contain the CMEVT_A_ASYNC_CPLT attribute. The default is 0.

Exc_part_name asciz Part name to use when generating exception events. The default is "DM FSM".

38 State Machine Descriptor

The DM FSM is parameterized with a state machine descriptor that specifies a next state and action for each (state, input) pair. Each state contains a state identifier and event Ids for notifications to send when entering and/or leaving the state. The DM FSM accepts state identifiers between 0 and 63 for a total of 64 states.

The "input" consists of an event identifier and a flag optionally specifying the required

value of the asynchronous completion attribute in the incoming event bus. The flag specifies one of the following:

• Any attributes may be set (i.e., the event can be of any type)

• The CMEVT A COMPLETED attribute is not set (i.e., the event is a request).

• The CMEVT A COMPLETED attribute is set (i.e., the event is a completion event for a previous request)

There may be duplicate event JD's specified for a single state provided that the event attributes are not duplicated. For example, if one event specifies that the

CMEVT A ASYNC CPLT attribute must be cleared, there cannot be another event that specifies that the attribute must be cleared or ignored.

Each entry in the descriptor, indexed by the (state, input) pair, specifies the following

data: next state - Specifies the next state that the

DM FSM transitions to before performing the action. If the value of this parameter is _SAME_ (-1), then the DM FSM performs no state transition.

Action - Specifies the action that the DM FSM is to take. The actions are described below.

35 Action-specific data - Specifies any additional parameters necessary for the DM_FSM to carry out the action. The action specific data for each action is described below.

The descriptor is preferably defined using a set of macros. See the DM_FSM State Machine Reference herein for a complete reference of the descriptor macros and examples of their use.

Types of Actions

For each (state, input) pair, the DM FSM can perform one of three actions:

• The DM FSM can forward the event (as is) through to its out terminal or modify the

event id in the bus before forwarding the event. The DM_FSM provides the option to

restore the event id before returning. This action also has the option of having the

DM FSM return a status other than the status returned from the forwarded event.

• The DM FSM can generate a new event out its out terminal. This action has additional parameters that specify how the DM_FSM is to deal with the event data:

(1) Generate event with no data (void);

(2) Copy incoming event data to the generated event;

(3) Copy data from the completed generated event to the original event bus;

(4) Copy incoming data to the generated event and copy data from the completed generated event to the original event bus.

This action also has the option of having the DM FSM return a status other than the

status returned from the generated event.

• The DM FSM can serve the incoming event by returning a specified status.

Supported Event Types

The DM FSM supports the following categories of incoming events:

36 • Notifications - A notification is an event where the issuer does not expect any return data or status.

• Synchronous Completion Requests - These are requests that must be completed synchronously. The issuer expects return status and/or data.

• Asynchronous Completion Requests - These events may be processed asynchronously meaning that the event may complete at a later time.

The DM FSM preferably does not treat the different event categories differently, but it

provides support for handling these categories. The state machine designer should take into

account the type of event being received (e.g., not to postpone synchronous completion

requests).

Exceptions

The DM FSM will preferably generate EV EXCEPTION events out its nfy terminal if it

encounters an error during operation. There are two cases in which the DM FSM may generate an exception. The cases are:

• The new state specified in the descriptor for a particular input does not exist as a state in the descriptor.

• The DM FSM fails to allocate an event bus when performing a generate action.

The DM FSM is parameterized with the exception Ids that it generates for each of the

above cases. The DM FSM can generate other exceptions on other types of errors.

Properties

Property name Type Notes fsm descp uint32 Pointer to a state machine

^~ descriptor.

This property is mandatory.

37 Property name Type Notes

Exc missing state uint32 Exception ID to generate when

^~ the specified new_state does not exist in the descriptor or is out of range.

The default is 0 (do not generate exception) exc no memory uint32 Exception ED to generate when the DM_FSM fails to allocate memory during the processing of a generate action. The default is 0 (do not generate exception) 3.3. Responsibilities

The DM FSM preferably has the following responsibilities:

1. Validate state machine descriptor upon activation.

2. Transition state and perform the action specified in the state machine descriptor for the

(current state, input) pair

3. Generate "enter state" and or "leave state" notifications out the nfy terminal upon state

transition if specified in the state descriptor.

4. Generate state_chg_ev notifications out the nfy terminal upon state transition, after the

action is performed. 5. Return status specified by busy s property when event is received while sending "enter

state" and "leave state" notifications (signals illegal recursion into the DM FSM).

6. Return value specified by unrecognized s property for incoming events not found in the

descriptor for the current state.

7. Generate EV EXCEPTION event out nfy terminal when error occurs and corresponding

exception ID property is not 0. 4. Theory of operation

4.1 State machine

The DM FSM implements the state machine provided to it via its fsm_descp property. The organization of the state machine is (state, event) -> (new state, action).

4.2 Mechanisms

Validating the State Machine

The checked build of the DM FSM validates the correctness of the state machine descriptor upon activation. The DM FSM performs the following validation:

• Verifies that there are no duplicate states and the state identifiers are within the allowed range (0 - 63).

• Verifies that for each state there are no duplicate inputs (i.e., (event, completion attribute) pairs).

• Verifies that each specified "new state" exists and is within range.

If the DM_FSM encounters an error in the state machine descriptor, it will fail to activate.

Resolving (state, input) Pair

When the DM_FSM receives an event on its in terminal, it indexes into the descriptor based on the current state and locates an entry with event ID matching the incoming event ID.

Then it performs a bitwise AND between the incoming event attributes and the attribute mask specified in the entry. Next it compares the result with the attribute value specified in the entry. If the values match, the DM FSM performs the action specified by the entry.

Sending State Change Notifications

When the DM_FSM has resolved the correct (state, input) pair, it first makes the necessary state change as specified by the new state value in the descriptor and then emits any required state enter/leave notifications as specified below. Macro Description

STATE (id,enter_id, leave id) Specify a state entry. The id parameter specifies the state identifier.

The enter_id parameter specifies the ID of the notification to send when entering the state or EVJNULL to not generate a notification. The leave id parameter specifies the ID of the notification to send when leaving the state or EV NULL to not generate a notification.

ON(event,state,action) Specify an event entry. The event parameter specifies the incoming event. Use the eve«t definition macros defined below to specify this parameter. The state parameter specifies the next state

The action parameter specifies the action to take. Use the action definition macros defined below to specify this parameter. To specify no state change, set state to _SAME_. The STATE_MACHINE and END_STATE_MACHINE macros define a new part similar to the one described at the beginning of the DM_FSM Application Notes.

The remaining macros simply expand to the initialization data for the descriptor entry

(FSM_ENTRY) described above.

Event Definition Macros

The DM_FSM defines the following macros to specify the event parameter of the ON

macro.

Macro Description eventX (id, attr, mask) Generic definition for an incoming event. event (id) Specify incoming event where any attributes may be set (i.e., the

DM_FSM accepts any type of event).

46 Macro Description request (id) Specify an incoming event that is a request (i.e.,

CMEVT_A_COMPLETED attribute is cleared). completion (id) Specify an incoming event where the CMEVT_A_COMPLETED attribute is set.

Action Definition Macros

The DM FSM defines the following macros to specify the action parameter of the ON

macro.

Macro Description actionX (type, status, id, attr) Generic definition for an action.

The type parameter specifies the action type [FSM_AT_XXX].

The status parameter specifies the status to return if overriding the return status.

The id field specifies the event ID to generate.

The attr field specifies additional action-specific attributes

[FSM_AF_XXX]. serve (status) Define an event where the DM_FSM services the event by returning the status specified by status. postpone Define an event where the DM FSM postpones the event by returning

CMST_POSTONE.

This macro is defined as serve (CMST_POSTPONE). fwd Define an event where the DM FSM fwd_override (status) services the event by forwarding the event to its out terminal without modification.

If the fwd override macro is used,

DM_FSM returns the status specified by the status parameter.

47 If the previous state specifies that the DMJFSM is to emit a "state leave" notification, the DM FSM sends the notification out its nfy terminal.

If the new state specifies that the DM FSM is to emit a "state enter" notification, the DM_FSM sends the notification out its nfy terminal.

After sending the state change notification, the DM_FSM performs the specified action,

followed by emitting a "state changed" event out its nfy terminal if its state chg ev property is non-zero. The event ID that is sent is the value specified in the state_chg_ev property.

The return statuses on all notifications are ignored.

Processing SERVE Actions

The DM FSM processes SERVE actions by returning the status specified by the action

for the (state, input) pair.

Processing FORWARD Actions

When the DM FSM processes a FORWARD action, it first checks if it needs to modify

the event ID in the incoming event bus. If so, the DM FSM sets the event ID to the one

specified in the descriptor entry. The DM_FSM then forwards the event out its out terminal.

If the DM_FSM had modified the event ID and the restore flag is set to TRUE, the DM FSM restores the original event ED. If it is specified to override the return status, the DM_FSM

returns the status from the descriptor entry; otherwise it returns the status from the forwarded

call.

Processing GENERATE Actions

The DM_FSM processes a GENERATE action by performing the following steps:

• If the "copy in" and "copy out" flags are not set, the DM FSM allocates an event bus of size CMEVENT_HDR;

• If the "copy in" flag is set, the DM FSM duplicates the incoming event.

41 • If only the "copy out" flag is set, the DM_FSM allocates a bus with the same size and attributes as the incoming event bus.

• Performs a logical AND between the attr field of the new event bus and the value of the DM FSM's gen attr and property.

• Performs a logical OR between the attr field of the new event bus and the value of the

DM_FSM's gen_attr_or property.

• The DM FSM sends the new event out its out terminal.

• If specified, the DM_FSM copies all data following the CMEVENT HDR portion of the new event bus to the original event bus before returning.

• If specified to return a status other than the one returned, the DM_FSM returns the

specified status; otherwise, it returns the status from the outgoing call.

Generating Exceptions

When the DM_FSM encounters an error that requires an exception notification to be generated, the DM_FSM verifies that the property that specifies the exception ED to raise is

non-zero. Ef the property is non-zero, the DM FSM generates an exception; otherwise no

exception is generated. En both cases, the DM FSM returns the corresponding bad status. The DM_FSM provides the following information in the B EV EXC bus:

B_EV_EXC Field Value _exc id value of corresponding exc_xxx

- property exc_class CMERR_ERROR class name value of exc_part_name property line line number where error occurred in the descriptor. Cm stat DriverMagic status that corresponds to the error (e.g., CMST_ALLOC if fail to allocate memory) format "^dd" data <current state EDxincoming event id>

42 4.3 Illustrative Use Case

A simple example of a preferred use of the DM FSM is illustrated in Fig. 2. In this

scenario, there is a DM FSM part and a HDLR part that contains the action handlers for the

events forwarded or generated by the DM_FSM. It must be noted here that the HDLR part need not be a coded part - it may be assembled out of other parts.

En this scenario, the DM_FSM receives events from an external source on its in terminal.

The DM FSM makes the required state change and performs the specified action. The action

may result in the DM FSM sending the same event or a different event out its out terminal to be processed by the HDLR.

When the HDLR part receives an event, it performs the necessary processing. The HDLR part has a feedback terminal (fbk) through which it can feed events into the state machine for

the purpose of handling error conditions or other processing.

For additional usage examples, see the DM_FSM Application Notes herein.

5. DM_FSM State Machine Descriptor Reference

The DM FSM uses a state machine descriptor (supplied from outside by the property

(fsm descp). This descriptor describes the supported states, a list of recognized inputs for

each state, and for each (state, input) pair describes the next state and an action to be taken.

The descriptor is preferably an array of the following structure:

Entry Types

#define FSM_ET_END ° End of descriptor

#define FSM_ET_STATE 1 ^Entry specifies a state

#define FSM_ET_EVENT ^{2 Entr}y specifies an event (input)

Action Types

#define FSM_AT_SERVE ° service the event

43 #define FSM_AT_FORWARD 1 pass the event to out with same bus #define FSM_AT_GENERATE 2 generate a new event out out

Action Flags #define FSM_AF_OVRD_ED 0x01 replace event ED if action =

FSM_AT_FORWARD #define FSM_AF_RESTORE_ID 0x02 restore event ED if action =

FSM_AT_FORWARD #define FSM AF OVRD STAT 0x04 override return status if action =

FSM_AT_GENERATE or

FSM_AT_FORWARD

#define FSM AF CPY IN 0x08 copy input data if action =

FSM_AT_GENERATE

#define FSM AF CPY OUT Ox 10 copy output data if action =

FSM AT GENERATE

44 FSM Descriptor Definitions typedef struct FSM_ENTRY

{ byte entry type entrytype [FSM_ET_XXX] uint32 id state ED if entry type is

FSM_ET_STATE event ED if entry type is

FSM_ET_EVENT uint32 attr if entry type is FSM_ET_ENTRY, specifies event attributes that must be set uint32 attr mask if entry type is FSM_ET_ENTRY, specifies an attribute mask that is

ANDED with the incoming event attributes before comparing to attr value. byte new_state new state id or _S AME_ byte act_code action to perform [FSM_AT_XXX] byte act attr action-specific attributes [FSM_AF_XXX] uint32 status specifies return status uint32 event idl Ef entry type is FSM_ET_STATE, specifies the "state enter" notification event ED; otherwise specifies the outgoing event ED if action is FSM_AT_GENERATE or FSM_AT_FORWARD uint32 event id2 If entry type is FSM_ET_STATE, specifies the "state leave" notification event ED.

};

Defining a State Machine Descriptor

The DM FSM preferably defines several convenience macros that aid in defining the state machine descriptor. The macros are described below:

Macro Description

STATE_MACEEENE(name) Begin declaration of state machine descriptor. END_STATE_MACHENE(name) End declaration of state machine descriptor

45 Macro Description fwd_modify (new_ev_id, restore) Define an event where the DM FSM fwd_modify_override (new_ev_id, services the event by modifying the status, restore) event id to new_ev_id before forwarding the event to its out terminal.

If the restore parameter is TRUE, the

DM FSM restores the original event

ID before returning

If the fwd_modify_override macro is used, the DM_FSM returns the status specified by the status parameter. gen(new_ev_id) Define an event where the DM_FSM gen override (new ev id, status) generates a new event of size

CMEVENT_HDR with an event id specified by new_ev_id and forwards the new event to its out terminal.

If the gen override macro is used, the DM FSM returns the status specified by the status parameter. gen cpy in (new ev id, cpy_out) Define an event where the DM FSM gen_cpy_in_override (new_ev_id, generates a new event with same size status, cpy_out) as incoming event bus and event id specified by new ev id and copies the data following the

CMEVENT HDR portion of the bus to the new event bus. The DM FSM forwards the event to its out terminal.

The cpy out parameter specifies whether the DM FSM is to copy the contents of the new event bus to the original event bus before returning.

If the gen_cpy_in_override macro is used, the DM FSM returns the status specified by the status parameter. Macro Description gen cpy out (new evjd) Define an event where the DM FSM gen_cpy_out_override (new_ev_id, generates a new event with same size status) as incoming event bus and event id specified by new_ev_id and copies the incoming data following the CMEVENT_HDR portion of the bus to the new event bus. The DM FSM forwards the event to its out terminal and before returning, copies the bus data from the new event bus back to the original event bus before returning.

If the gen cpy out override macro is used, the DM FSM returns the status specified by the status parameter.

6. DM_FSM Application Notes

Overview

The following sections provide detailed use cases and examples of how to use the DM_FSM.

Declaring a State Machine

When a state machine is declared using the STATE MACHENE and

END STATE MACHENE macros, a part having the same boundary as the DM FSM is defined. The name that is given to the STATE MACHENE macro is used as the part's class name. For this reason, the state machine descriptor should be declared in a separate source file. The part that is declared by the STATE_MACEEINE and END_STATE_MACEflNE

macros has the architecture illustrated in Fig. 3.

The resulting part exposes all properties of the DM FSM except for the fsm descp and exc_part_name properties, which are hard parameterized by the part. Using the DM_FSM

The DM FSM part may be used in a number of different scenarios. The following

sections describe in detail several example use cases for the DM FSM. For each use case, the following information is provided:

• Architecture diagram - the state machine is named FSMX in all diagrams.

• The use case

• One or more examples of situations where the use case could be advantageously applied.

• implementation notes.

6.1. Simple usage

Overview

The simple use case is useful when the flow of events generally moves in a left to right manner, incoming event EDs are unique, and there is no need to postpone events for later

processing. This use case is illustrated in Fig. 4.

This use case illustrates the most straightforward usage of the DM FSM. En this scenario,

there is a FSMX part, which is the state machine (FSMX is an assembly containing the

DM_FSM, as described in the Declaring a State Machine section above), and a EEDLR part

that contains the action handlers for the events forwarded or generated by FSMX. Et must be noted here that the HDLR part need not be a coded part - it may be assembled from other parts.

Events are fed into FSMX from an external source on its in terminal. FSMX makes the

required state change and performs the specified action. The action may result in FSMX

sending the same event or a different event out its out terminal to be processed by the HDLR.

When the HDLR part receives an event, it performs the necessary processing. The EEDLR part has a feedback terminal (fbk) through which it can feed events into the state machine for the purpose of handling error conditions or other processing. En very simple cases, the feedback terminal and connection may not necessary. Examples of Use

• Lexical analysis

6.2 Postpone

Overview

The postpone use case enables the state machine to postpone processing of received events that are received at an inappropriate time (i.e., invalid state) until such a time that the event may be processed (i.e., valid state). This use case is illustrated in Fig. 5. It is similar to

the simple usage of DM FSM except that FSMX (i.e., state machine) postpones certain

incoming events for later processing by returning CMST POSTPONE.

The postponed events are resubmitted to FSMX upon each state change. FSMX sends the "state change" notification, which causes the NFY part to generate an EV FLUSH event to

the SEBP part. Upon receiving EV FLUSH, SEBP resubmits all postponed events to FSMX.

For each event, FSMX can either process the event or postpone it again.

Examples of Use

• The network link layer described in the EEEE/1SO 802.2 standard. The standard requires that events not recognized in the current state be held until a state in which they are

recognized.

Implementation Notes

The designer of the state machine and the HDLR should take care not to postpone

synchronous completion requests when using the SEBP part. Flushing of postponed events should only occur on the "state change" notifications and not "state enter/leave" notifications.

This is because the DM FSM may not be re-entered while sending "state enter/leave" notifications. When there are many events that may need to be postponed and to save the state machine designer from having to specify postpone actions for each event and to reduce the size of the

descriptor table, a distributor for service (DM DSV) may be placed in front of the state machine as illustrated in Fig. 6.

The DM DSV is parameterized to recognize events that are not recognized by the state

machine (i.e., FSMX returns CMSTJSTOT SUPPORTED). The DM_DSV then passes the unrecognized events out its out terminal which are then filtered by the FLT part into the set of events that need to be postponed and the set of events that are actually unrecognized. 6.3 Translate inputs to events on state machine

Overview

It may be necessary to pre-process some events to inputs on the state machine. This preprocessing may involve translating one event ID to another, re-coding the event ED based on some field in the event bus, or generating multiple events from a single input event.

The pre-processing of events is performed by the XLT part as illustrated in Fig. 7. This

part intercepts the incoming events to the state machine and performs any necessary pre¬

processing. It must be noted that the XLT part can be a coded part or assembly of reusable

parts.

Examples of Use

• The translation of events is frequently used in communications where different frame types are sent with the same carrier event (e.g., EV FRAME). The XLT part translates

each frame type to a different event using the frame type field in the frame header.

6.4. Two Event Streams

Overview

This use case involves the situation where the state machine must process events from two or more event streams such as in a device driver controller as illustrated in Fig. 8. The event EDs may or may not be unique. Ef incoming event EDs are not unique, then the

incoming events on at least one stream should be pre-processed before being fed into the state machine as illustrated by the XLT part in Fig. 8.

Examples of Use

• device controller

• network protocol

Implementation Notes

A typical device controller has two bi-directional inputs (e.g., cmd and dev as shown in the diagram above). It receives requests and sends completion events via the cmd terminal. Requests and responses are sent/received to/from the device via the dev terminal.

The above use case illustrates how the FSMX and the HDLR parts can be assembled in such a way that the incoming events from each input are fed into the state machine. If the

event Ids sent to each input may be the same, then a part, such as XLT in the above diagram,

may be inserted to pre-process the input into events on the state machine, so that FSMX can distinguish between them. Based on the event received, the HDLR part may send a

completion event out its cplt terminal and/or send a request to the device out its o dev

terminal.

6.5. Hierarchical State Machines

Overview The hierarchical state machine use case provides a solution to the situation where a state of the main state machine has subordinates states. Fig. 9 illustrates an hierarchical state

machine built to implement the state transition table illustrated in Fig. 10. The states of state machine 2 are valid only when state machine 1 is in state S2. En this example, state machine

2 operates only when state machine 1 has entered S2. When state machine 1 leaves S2, state machine 2 does not operate. En this use case the output from the first state machine acts as input to the second state

machine and/or the "state enter/leave" notifications from the first state machine are input for the second state machine. Events that only pertain to the second state machine need not travel

through the first state machine. These events can be redirected to the second state machine by using a splitter part such as DM_SPL.

When DM_FSM is used in a hierarchical manner, this generally produces tight coupling between the state machines.

Examples of Use

• The network link layer described in the EEEE/ESO 802.2 standard. The link state machine has a subordinate state machine for the normal state.

Implementation Notes

There may be a separate HDLR part for each state machine.

If there is more than one subordinate state machine, a multiplexer may be used to direct

the output of the main state machine to the subordinate state machine for the current main state.

The subordinate state machine may transition to a known (disabled) state when the S2

main state is left, or it may retain the sub-state.

6.6. Synchronized State Machines

Overview The synchronized state machine use case provides a solution to the situation where there

are two independent state machines and at least one of the state machines needs to know the current state of the other state machine.

The DM FSM's "state enter/leave" notifications may be used to synchronize the states of

multiple state machines as illustrated in Fig. 11. This mechanism provides a looser coupling

between the state machines than the hierarchical use case because neither state machine need have knowledge about the inputs of the other; they need only have knowledge about one or

more states that the other state machine enters and/or leaves.

The two state machines are entirely separate with separate inputs and separate HDLR parts. However, it is possible that both state machines feed into a single HDLR part. The state enter/leave notifications are used to synchronize the two state machines.

Examples of Use

• Receive and Transmit state machines for reliable connections

7. DM_FSM Descriptor Examples

7.1. A Device Controller

The following is an example of defining a state machine descriptor to be used by FSM for a device controller of a magnetic card reader. The example state machine has the state

transition diagram illustrated in Fig. 12. it has the following states:

STOPPED -^ The device controller is waiting for the start event.

STARTING -^ The device controller has received the start event and is waiting for a response from the device.

EDLE "^ The device controller is idle.

READ PEND -^ The device controller has received a request to read card data and is waiting for a response from the device.

GET PEND -^ The device controller has received a property request that requires communication with the device. The device controller has sent a property request to the device and is waiting for the response.

STOPPING -^ The device controller has received a stop request while waiting for a response from the device.

The state machine has the following incoming events:

EV LFC REQ STAR "^ Request to start normal operation

T

EV LFC REQ STOP "^ Request to stop normal operation EV_CMD_RESET -^ Request to reset the device

EV_CMD_CANCEL "^ Request to cancel a pending command

EV_CMD_GET "^ Command to request a property value

EV_CMD_SET -^ Command to set a property value

EV_CMD_READ "^ Command to request data to be read from a magnetic card

EV_CMD_WRITE "^ Command to write data to a magnetic card

EV RSP READ -> Response to read request [EV CMD READ]

EV_RSP_GET -> Response to get request [EV CMD GET]

EV_START_SUCCES "^ "Start" request was successful S

EV_START_FAELED -> "Start" request failed EV_GET_CPLT "^ Get request has completed EV READ CPLT "^ Read request has completed

The state machine has the following outgoing events:

EV_LFC_REQ_STAR "^ Request to start normal operation

T

EV_LFC_REQ_STOP Request to stop normal operation

EV CMD_RESET Request to reset the device

EV_CMD_CANCEL - Request to cancel a pending command

EV CMD GET -> Command to request a property value

EV_CMD_SET - Command to set a property value

EV_CMD_READ Command to request data to be read from a magnetic card

EV_CMD_WRETE Command to write data to a magnetic card EV_RSP_READ Response to read request [EV CMD READ] EV_RSP_GET Response to get request [EV CMD GET] EV_REFUSE_GET An EV CMD GET command cannot be processed in the current state.

EV REFUSE READ An EV_CMD_READ command cannot be processed in the current state.

EV REFUSE WRITE -» An EV CMD READ command cannot be processed in the current state. EV_CMD_SET_W_PE -^■ An EV_CMD_SET command has been received when ND there is already a pending command.

EV_CMD_GET_W_P -» An EV_CMD_GET command has been received when END there is already a pending command.

The state machine descriptor has the following definition:

STATE_MACHINE (DEVICE_SM)

FSM_STATE (STOPPED, EV_NULL, EV_NULL)

ON (event (EV_LFC_REQ_START), STARTING , fivd )

ON (event (EV_CMD_RESET ), _SAME_ , serve(CMST_OK) )

ON (event (EV_CMD_CANCEL ), _SAME_ , serve(CMST OK) )

ON (event (EV_CMD_GET ), _SAME_ , fwd_modify(EN_REFUSE_GET, TRUE)

)

ON (event (EN_CMD_SET ), _SAME_ , serve(CMST REFUSE) )

ON (event (EV_CMD_READ ), _S AME_ , fwd_modify(EN_REFUSE_READ,

TRUE) )

ON (event (EV_CMD_WPJTE), _SAME_ , fwd_modify(EN_REFUSE_WRETE, TRUE)

)

ON (event (EN_RSP_GET ), _SAME_ , serve(CMST OK) ) ON (event (EV_LFC_REQ_STOP ), _S AME_ , serve(CMST_OK) )

FSM STATE (STARTING, EV_NULL, EV NULL)

ON (event (EV_START_ERROR ), STOPPED , serve(CMST_OK) )

ON (event (EV_START_SUCCESS), EDLE , serve(CMST OK) )

ON (event (EV_RSP_GET ), _SAME_ , fwd )

ON (event (EV_CMD_RESET ), _SAME_ , serve(CMST_OK) )

ON (event (EV_CMD_CANCEL ), _SAME_ , serve(CMST_OK) )

ON (event (EV_CMD_GET ), SAME . fwd ) ON (event (EV_CMD_SET ), _SAME_ , serve(CMST_REFUSE) )

ON (event (EV CMD READ ), _SAME_ , ftvd_modify(EV_REFUSE_READ, TRUE)

)

ON (event (EV_CMD_WRITE), _SAME_ , fwd_modify(EV_REFUSE_WRITE, TRUE) )

ON (event (EV_LFC_REQ_START), _SAME_ , serve(CMST_REFUSE) )

ON (event (EV_LFC_REQ_STOP ), STOPPING), fwd )

FSM_STATE (STOPPING, EV_NULL, EV_NULL)

ON (event (EV_RSP_GET ), STOPPED , serve(CMST_OK) )

ON (event (EV_RSP_READ ), STOPPED , serve(CMST OK) )

ON (event (EV_GET_CPLT ), STOPPED , serve(CMST OK) )

ON (event (EV_READ_CPLT ), STOPPED , serve(CMST_OK) )

ON (event (EV_CMD_RESET ), _SAME_ , serve(CMST_REFUSE) )

ON (event (EV_CMD_CANCEL ), _SAME_ , serve(CMST_OK) )

ON (event (EV_CMD_GET ), _SAME_ , fwd_modify(EV_REFUSE_GET, TRUE)

)

ON (event (EV_CMD_SET ), _SAME_ , serve(CMST_REFUSE) )

ON (event (EV_CMD_READ ), _SAME_ , fwd_modify(EV_REFUSE_READ, TRUE)

) ON (event (EV_CMD_WRETE), _SAME_ , fwd_modify(EV_REFUSE_WRETE,

TRUE) )

FSM_STATE (EDLE, EN NULL, EV_NULL)

ON (event (EV_CMD_RESET ), _SAME_ , serve(CMST_OK) )

ON (event (EV_CMD_CANCEL ), _SAME_ , serve(CMST_OK) ) ON (event (EV_CMD_GET \ GET PEND . fwd ) ON (event (EV_CMD_SET ), _SAME_ , fwd )

ON (event (EV_CMD_READ ), READ PEND, fwd )

ON (event (EV_RSP_GET ), _SAME_ , serve (CMST OK) )

ON (event (EV_LFC_REQ_STOP ), STOPPED , serve (CMST_OK) )

ON (event (EV_CMD_WRITE), _SAME_ , fwd_modify(EV_REFUSE_WRITE,

TRUE) )

ON (event (EV_LFC_REQ_START), _SAME_ , serve (CMST REFUSE) )

FSM STATE (GET_PEND, EV_NULL, EV_NULL)

ON (event (EV_RSP_GET ), EDLE , fwd ) ON (event (EV_CMD_RESET ), EDLE , fwd )

ON (event (EV_CMD_CANCEL ), _SAME_ , fwd )

ON (event (EV_LFC_REQ_STOP ), STOPPING , serve (CMST_PENDENG) )

ON (event (EV_GET_CPLT ), EDLE , serve (CMST_OK) )

ON (event (EV_CMD_GET), _SAME_ , fwd_modify(EV_CMD_GET_W_PEND,

TRUE))

ON (event (EV_CMD_SET), _SAME_ , fivd_modify(EV_CMD_SET_W_PEND,

TRUE))

ON (event (EV_CMD_READ ), _SAME_ , fwd_modify(EV_REFUSE_READ, TRUE)

) ON (event (EV_CMD_WRETE), _SAME_ , fwd_modify(EV_REFUSE_WRETE,

TRUE) )

ON (event (EV_LFC_REQ_START), _SAME_ , serve (CMST_REFUSE) )

FSM_STATE (READ_PEND, EV_NULL, EN_NULL)

ON (event (EV_RSP_READ ), EDLE , fwd ) ON (event (EV_CMD_RESET EDLE . fwd ) ON (event (EV CMD CANCEL ), _SAME_ , fwd )

ON (event (EV_CMD_GET), _SAME_ , fwd_modify(EV_CMD_GET_W_PEND, TRUE))

ON (event (EV_CMD_SET), _SAME_ , fwd_modify(EV_CMD_SET_W_PEND, TRUE))

ON (event (EV_READ_CPLT ), IDLE , serve (CMST_OK) )

ON (event (EV_CMD_READ), _SAME_ , fwd_modify(EV_REFUSE_READ, TRUE)

)

ON (event (EV CMD WRETE), _SAME_ , fwd_modify(EV_REFUSE_WRITE, TRUE) )

ON (event (EV_LFC_REQ_START), _SAME_ , serve (CMST_REFUSE) )

ON (event (EV_LFC_REQ_STOP ), STOPPING , serve (CMST_PENDENG) )

END_STATE_MACHENE (DEVICE SM)

7.2. Lexical Analyzer The following is an example of defining a state machine descriptor to be used by FSM in

a lexical analyzer. Characters are fed into the state machine one at a time. The goal of the lexical analyzer is to parse the following types of fields into tokens:

value field -> <value name>

escape field - \ hh literal excape - \lit literal field -> any other character

The state machine is based on the following grammar:

<data> -^ (<literal> | <escape> | <name>)

<literal> -> <character> | <esccape> <character> -> nrintable ASCII character <escape> \<esc_char>

<esc_char> -> < I ^> I \ I _ I <hex_number>

<hex_number> - (x I X)<hex_dig><hex_dig>

<hex_dig> -> <digit> I (A..F) I (a..f)

<digit> -» 0..9

<name> -> «alpha_ch>(<alpha_ch> | <digit> | _)^*>

<alpha_ch> ^■ a..z I A..Z

The state machine has the state transition diagram illustrated in Fig. 13 (error transitions are omitted for brevity and are not shown). The above state machine has the following states:

EDLE -^ State machine is in an EDLE state ESCAPE -^ State machine has received a BACKSLASH event, which starts an "escape" field.

HEX1 -> State machine has received an X ALPHA event, which specifies that the escape is a hexadecimal number.

HEX2 -^ State machine has received the first hexadecimal number.

VALUE -^■> State machine has received a L ANGLE event which starts a "value" field. NAME ~^ State machine is accumulating a value name.

The incoming events of the above state machine are character categories. The state machine has the following events:

NUMBER -■> '0' ... '9'

EEEX ALPEEA " ^uPP^{er and} lowercase 'A', 'B', 'C\ 'D', 'E', 'F'

X_ALPHA - 'x' or 'X'

ALPEEA -^ all other alpha characters

UNDERSCORE -> ' ' BACKSLASH ^"•> '\'

R_ANGLE ~ '>'

L_ANGLE ^" '<'

OTHER "^ AN characters not in the previous categories

The state machine generates the following events: EVJL1T -^ Process character as a literal

EV_S_NAME "^ Start accumulation of value name

EV_E_NAME -^ End accumulation of value name

EV NAME "^ Character is part of value name

VAL ERR "^ Received invalid character for value name. This event is generated so that HDLR can perform any necessary cleanup. EV S HEX -^ Start accumulation of hexadecimal number

EV E HEX "^ End accumulation of hexadecimal number

EEEX ERR "^ Received invalid character for hexadecimal number.

This event is generated so that EEDLR can perform any necessary cleanup.

The state machine descriptor has the following definition:

STATE_MACHEΝE (LEX_SM) FSM_STATE (IDLE, EV_NULL, EV_NULL)

ON (event (L ANGLE ), VALUE , serve (CMST_OK) )

ON (event (BACKSLASH ), ESCAPE, serve (CMST_OK) )

ON (event (NUMBER ), _SAME_, ftvd_modify (EV_LIT,TRUE) )

ON (event (HEX_ALPHA ), _S AME_, fwd_modify (EV_LIT) ) ON (event (X_ALPHA ), _SAME_, fivd_modify (EV_LIT) )

ON (event (ALPHA ), _SAME_, fwd_modify (EV_LET) )

ON (event (UNDERSCORE), _SAME_, fwd_modify (EV_LIT) )

ON (event (R ANGLE ), SAME , fwd_modify (EVJLET) ) ON (event (OTHER ), _S AME_, fwd_modify (EV_LET) )

FSM_STATE (VALUE , EV_NULL, EV_NULL)

ON (event (HEX_ALPHA ), NAME , fwd_modify (EV_S_NAME, TRUE) )

ON (event (X_ALPHA ), NAME , fwd_modify (EV_S_NAME, TRUE) ) ON (event (ALPHA ), NAME , fwd_modify (EV_S_NAME, TRUE) )

ON (event (L_ANGLE ), EDLE , serve (CMST_BAD_SYNTAX) )

ON (event (NUMBER ), EDLE , serve (CMST_BAD_SYNTAX) )

ON (event (UNDERSCORE), EDLE , serve (CMST_BAD_SYNTAX) ) ON (event (R_ANGLE ), EDLE , serve (CMST_BAD_SYNTAX) )

ON (event (OTHER ), IDLE , serve (CMST_BAD_SYNTAX) )

FSM_STATE (NAME, EV_NULL, EV_NULL)

ON (event (NUMBER ), _SAME_, fwd_modify (EV JNAME, TRUE ) ) ON (event (HEX_ALPHA ), _SAME_, ftvd_modify (EV_NAME, TRUE ) )

ON (event (X_ALPHA ), _SAME_, fwd_modify (EV_NAME, TRUE ) ) ON (event (ALPEEA ), _SAME_, fwd_modify (EV_NAME, TRUE ) )

ON (event (UNDERSCORE), _SAME_, fwd_modify (EV_NAME, TRUE ) ) ON (event (R_ANGLE ), EDLE , fwd modify (EV_E_NAME, TRUE) )

ON (event (L /ANGLE ), IDLE , fwd_modify (VAL_ERR, TRUE ) )

ON (event (OTHER ), EDLE , fwd_modify (VAL_ERR, TRUE ) )

FSM_STATE (ESCAPE, EV_NULL, EV_NULL)

ON (event (NUMBER ), EDLE , fwd_modify (EV_LET, TRUE) )

ON (event (L_ANGLE ), IDLE , fwd modify (EV_LIT, TRUE) )

ON (event (X_ALPHA ), IDLE , fwd_modify (EVJ IT, TRUE) )

ON (event (R ANGLE ), EDLE , fwd_modify (EVJLIT, TRUE) ) ON (event (OTHER ). EDLE . fwd modifV (EV LET, TRUE) ) ON (event (EEEX_ALPEEA ), EDLE , serve (CMST_BAD_SYNTAX) ) ON (event (ALPHA ), EDLE , serve (CMST_BAD_SYNTAX) )

ON (event (UNDERSCORE), EDLE , serve (CMST_BAD_SYNTAX) )

FSM_STATE (HEX1, EN_NULL, EN_NULL) ON (event (NUMBER ), HEX2 , fwd modify (EV_S_HEX, TRUE) )

ON (event (HEX_ALPHA ), EEEX2 , fwd_modify (EV_S_HEX, TRUE) ) ON (event (L_ANGLE ), EDLE , serve (CMST_BAD_SYNTAX) )

ON (event (X_ALPHA ), EDLE , serve (CMST_BAD_SYNTAX) )

ON (event (ALPHA ), EDLE , serve (CMST_BAD_SYNTAX) ) ON (event (UNDERSCORE), EDLE , serve (CMST_BAD_SYNTAX) )

ON (event (R_ANGLE ), EDLE , serve (CMST_BAD_SYNTAX) ) ON (event (OTHER ), IDLE , serve (CMST_BAD_SYNTAX) )

FSM_STATE (HEX2, EV_NULL, EV_NULL)

ON (event (NUMBER ), EDLE , fwd_modify (EV_E_HEX, TRUE) )

ON (event (HEX_ALPHA ), EDLE , fwd_modify (EV_E_HEX, TRUE) )

ON (event (L_ANGLE ), EDLE , fwd_modify (EEEX_ERR, TRUE ) )

ON (event (ALPHA ), EDLE , fwd_modify (HEX_ERR, TRUE ) ) ON (event (UNDERSCORE), EDLE , fwd modify (HEX ERR, TRUE ) )

ON (event (R_ANGLE ), EDLE , fwd_modify (EEEX_ERR, TRUE ) ) ON (event (OTHER ), EDLE , fwd_modify (EEEX_ERR, TRUE ) )

END_STATE_MACHENE (LEX_SM)

8. Appendix 1 - Interfaces

This appendix describes a preferred definition of the i_DRAEN interface used by the parts

described herein. Overview

The Event Drain interface is used for event transportation and channeling. The events are

carried with event ED, size, attributes and any event-specific data. Implementers of this

interface usually need to perform a dispatch on the event ED (if they care). Events are the most flexible way of communication between parts; their usage is highly

justified in many cases, especially in weak interactions. Examples of usage include notification distribution, remote execution of services, etc. Events can be classified in three

groups: requests, notifications and general-purpose events. The events sent through this interface can be distributed synchronously or asynchronously. This is indicated by two bits in the attr member of the bus.

Additional attributes specified within the same member indicate whether the data is

constant (that is, no recipient is supposed to modify the contents), or whether the ownership of the memory is transferred with the event (self-ownership). For detailed description of all

attributes, see the next section. There are two categories of parts that implement I DRAIN: transporters and consumers.

Transporters are parts that deliver events for other parts, without inteφreting any data except

id and, possibly, sz. They may duplicate the event, desynchronize it, marshal it, etc. In

contrast, consumers expect specific events, process them by taking appropriate actions and using any event-specific data that arrives with the event. In this case the event is effectively "consumed".

If the event is self-owned, consumers need to release it after they are done processing. This is necessary, as there will be no other recipient that will receive the same event instance

after the consumer. Transporters do not need to do that, they generally pass events through to other parts. Eventually, all events reach consumers and get released. Emplementations that are mixtures between transporters and consumers need to take about proper resource handling whenever the event is consumed.

Note that the bus for this interface is CMEVENT EEDR.

List of Operations

Name Description raise Raise an event, such as request, notification, etc.

Attribute Definitions

Name Description

CMEVT_A_NONE No attributes specified. CMEVT_A_AUTO Leave it to the implementation to determine the best attributes.

CMEVT_A_CONST Data in the event bus is constant. CMEVT_A_SYNC Event can be distributed synchronously. CMEVT A ASYNC Event can be distributed asynchronously.

All events that are asynchronous must have self-owned event buses. See the description of the

CMEVT_A_SELF_OWNED attribute below.

CMEVT A SYNC ANY Event can be distributed either synchronously or asynchronously. This is a convenience attribute that combines CMEVT_A_SYNC and

CMEVT_A_ASYNC.

Ef no synchronicity is specified, it is assumed the event is both synchronous and asynchronous.

CMEVT_A_SELF_OWNED Event bus was allocated from heap. Recipient of events with this attribute set are supposed to free the event.

CMEVT_A_SELF_CONTAENE Data in the bus structure is self contained. The event

D bus contains no external references.

CMEVT A DFLT Default attributes for an event bus

(CMEVT_A_CONST and CMEVT_A_SYNC). Bus Definition

// event header

typedef struct CMEVENT_HDR

{ uint32 sz; // size of the event data, including the header, in bytes

_id id; // event id flg32 attr; // event attributes

// event data can follow the header

} CMEVENT EJDR;

raise

Description: Raise an event (such as request, notification, etc.)

In: sz Size of event bus, incl. event-specific data, in bytes id Event ED attr Event attributes [CMEVT A XXX]

(any other) Depends on id

Out: void

Return Varies with the event Status:

Example: /* define my event */

EVENTX (MY_EVENT, MY EVENT ED, CMEVT_A_AUTO, CMEVTJ NGUARDED)

dword my event data; END_EVENTX

MY EVENT *eventp; cmstat status;

/* create a new event */ status = evt alloc (MY_EVENT, &eventp); if(status!=CMST_OK)...

/* set event data */ eventp->my_event_data = 128;

/* raise event through E DRAEN output */ out (drain, raise, eventp);

Remarks: The E DRAEN interface is preferably used to send events, requests or notifications. Et only has one operation called "raise." An event is generated by initializing an event bus and invoking the raise operation. The event bus describes the event. The minimum information needed is the size of the bus, event ED, and event attributes. The binary structure of the event bus may be extended to include event-specific information. Extending the event bus structure is done by using the EVENT and EVENTX macros. Parts that don't recognize the ED of a given event should inteφret only the common header: the members of CMEVENTJEDR.

The event attributes are divided into two categories: generic and event-specific. The first 16 bits (low word) of the attribute bit area are reserved for event- specific attributes. The last 16 bits (high word) of the attribute bit area are reserved for generic attributes. These are defined by CMAGIC.H (CMEVT_A_XXX).

The generic attributes include the synchronicity of the event, whether the event data is constant, and if the event bus is self-owned or self-contained. If the event bus is self-owned, this means that it was allocated by the generator of the event and it is the responsibility of the recipient to free it (if the event is consumed). If the event is self-contained, this means the event bus contains no external references. For the event to be distributed asynchronously, the event bus must be self-owned and self-contained.

See also: EVENT, EVENTX

9. Possible Extensions

The following list outlines some of the possible alternative embodiments of the present system, none of which is necessary for practicing the present invention as claimed herein and

none of which is necessarily preferred for the best mode of practicing the invention.

1. The state machine driver may be implemented under a system other than the '675 system. 2. As defined herein, the boundary of the configurable state machine driver provides one main input and one main output. However, its boundary may be modified to

provide multiple event inputs and multiple event outputs. The descriptor will be appropriately modified to include the input number into the indexing tuple,

resulting in the indexing tuple (state, input number, event); and the additional action information will optionally specify through which output number the outgoing event should be sent.

3. The state machine driver can be modified to use polymoφhic v-table interface or

another interface type. 4. The described embodiment implements a finite automaton, but other automata

types can easily be implemented.

5. The state machine driver may be modified to support more or less states than the defined 64 states.

6. As defined herein, the state machine driver implementation looks up for the input event using a sequential search, but a faster implementation can be easily provided.

7. En the present invention, the state transition table is specified as pre-initialized C

data using C macros. Many alternatives are possible, including having the state transition table specified through a user interface application by drawing a statechart.

8. As described above, the state transition table is specified using macros that define

a new part class. This is done for convenience and is not necessary to practice the present invention.

9. A method for designing state machines can also be defined. This method includes designing the state machine driver object, which accepts inputs, performs transitions and emits outputs, then designing the action handler object, which

accepts one or more of the outputs of the state machine driver object and performs actions that need to be taken on the respective state transition. The full required state machine functionality is then built by connecting the state machine driver

object to the action handler object, so that the outputs emitted by the state machine

driver object are received by the action handler object. This method can be further

improved by designing the state machine driver so that the particular states, inputs, outputs and state transitions is configurable.

10. A method for implementing state machines may be defined. This method includes .

taking an instance of a configurable state machine driver object, parameterizing it with a state machine descriptor, which describes the state transition table for the

desired state machine. Next, connect the output of that configurable state machine driver object to an action handler, which implements the specific functionality

required on each state transition. The action handler can be an object coded

specifically for the particular state machine, may be a reused object built for a

different state machine that has the same actions, or may be assembled out of ready made, reusable parts.

11. The connection between the configurable state machine driver and the action

handler can be established in a variety of ways. One possibility is to use the mechanisms described in the '675 application for establishing a connection

between two terminals. Another possibility is to use C++ inheritance, where, for example the action handler object class may derive from the state machine driver class, and the action handler class may implement its input as one or more virtual

methods defined by the state machine driver class. There are many other ways in which the communication between the state machine driver and the action handler can be established; the specific means of communication defined herein is not required for practicing this invention.

12. A method for designing and implementing hierarchical state machines can be

defined. The top-level (master) states are assigned to and handled by one instance of the configurable state machine driver, known as the master driver. A separate configurable state machine driver instance (a subdriver) is assigned to and handles

the subordinate state transitions for each of the master states that have subordinate

states. The master driver is designed as if the state machine consisted only of the master states; in addition, for each of the master states that has substates, the master driver is configured to issue state enter/leave notifications. These notifications are then fed into the appropriate subdriver assigned to handle the substates of that master state. The state machine descriptor for each subdriver is

designed to handle only its substates, as if those substates represented a separate

state machine. The master driver and the subdrivers are assembled together with one or more action handlers, similarly to the structure illustrated in Fig. 9, to produce the required full state machine.

13. A method for handling errors in a subordinate state machine can be defined. For

any conditions that the subordinate state machine cannot handle, either the state machine driver or the action handler issues an exception, indicating that the subordinate state machine cannot handle the current situation. A higher level state machine can then take an appropriate action. As an example, in a network

protocol stack like TCP/EP, a subordinate state machine may handle the packet acknowledgement and recovery protocol between two network nodes; if an error

occurs, that state machine can issue an exception, which will be processed by the TCP/EP connection state machine, which can then either dissolve the connection or use a higher level protocol to recover the communication.

14. A method for uniform processing of state machine input can be defined for

configurable state machines. The method includes the following steps in response

to received input event: locate an entry in the state machine descriptor table, such that the (state, input) pair in that table entry has state equal to the current state and input equal to the received

input;

if the located entry defines that a transition to a new state should be performed, change the state of the state machine to the state defined in the located table entry; if the state changed and the previous state (the state in which the input arrived) required a state-leave notification to be sent, as defined in the state machine

descriptor table, then this notification is sent;

if the state changed and the new state (the state defined in the located table entry) requires a state-enter notification to be sent, as defined in the state machine descriptor table, then this notification is sent; perform the action or send the output event defined in the located entry; and

if the state changed, and state change notifications are desired, send a state-changed

notification. 15. A simplified method for uniform processing of state machine input can be defined, based on the method described above, by removing one or more of the states that send out notifications.

16. The state machine descriptor table may be changed at runtime (assuming a stable

state or while the state machine is in its initial state, 0). This may be done by making the fsp_descp property of the DM FSM modifiable at runtime or by allowing the state machine descriptor to be sent using an event to an input terminal of the DM FSM.

17. The state machine descriptor can be generated in a variety of ways. Some

examples include: compilation of a language, generation of descriptor from a graphical statechart, or dynamic generation by specialized program code.

18. The same state machine driver instance may be parameterized with one of several state machines. An example of this would be a network protocol stack in which the state machine that handles a particular connection to a remote network node

may vary depending on which version of the protocol the remote node

implements. En this case, the protocol stack will find out what version the remote

node implements, and based on this version, will choose which of several state

machine descriptors to parameterize into the configurable state machine driver for the connection with that remote node.

19. En an application that supports persistent configuration, the state machine

descriptor may be downloaded from a remote network node, so that the

configurable state machine driver that will communicate with that node will have the specific state machine required by that node.

20. Also, in an application that supports persistent configuration, the state machine descriptor may be downloaded or selected among multiple pre-defined descriptors

by an operator or a support technician, enabling field upgrades and flexible

protocol support in that application.

21. A method for handling feedback from state machine outputs and actions can be defined, to provide handling of failed actions. In this method, the state machine is designed so that it enters the new state as if the action has succeeded. If the action actually fails, the action handler object sends an "action failed" notification back to the input of the state machine driver, causing a transition to the appropriate state that reflects this failure.

22. Another method for handling feedback from state machine outputs and actions can

be defined, in order to allow rolling back transitions in case the action fails. A

transition which requires the execution of an action that can fail is divided in two: a transition to an intermediate state (pending) for the duration of the action, and

then upon success a second transition to the final desired state. In case of failure, a transition to the original state can be made, essentially ignoring the input, or a

transition to an error state can be made. In this method, the action handler emits a

"succeeded" or "failed" notification upon completing the requested action. In

some implementations, the notification may be generated by general p pose parts placed in front of the action handler, essentially creating a compound action

handler.

23. A method for implementing timed transitions and timeouts in state machines can be defined. This method consists of the following steps:

creating an instance of a configurable state machine driver; parameterizing the state machine driver with a state machine descriptor; for the states

that require timed transitions or timeouts, the descriptor specifies state-enter and state-leave notifications; creating at least one timer, preferably configuring it with the desired timeout;

connecting the notification output of the state machine driver to the control input of

the timer, through which input the timer is armed and disarmed; connecting the fire output of the timer, which is signaled when the specified time interval expires, as input to the state machine driver; and using the state-enter and state-leave notifications to arm and disarm the timer; using the fire from the timer to perform the desired timed transition.

As described herein, the present invention has many advantages over the previous prior art systems. The following list of advantages is provided for puφoses of illustration, and is not meant to limit the scope of the present invention, or imply that each and every

possible embodiment of the present invention (as claimed) necessarily contains each

advantageous feature.

1. The present invention provides a fine-granularity, easily reusable object that contains the fundamental functionality needed to implement state machines in a wide variety of software applications and systems.

2. The present invention provides a reusable object that can be parameterized extensively

without modifying its implementation or requiring source code, thus achieving the ability

to modify and specialize its behavior to suit many different specific puφoses as required.

3. The present invention provides a reusable object that can be combined easily into different composition structures, in new and unanticipated ways, so that even entirely new

application requirements and functionality can be met by combining mostly, if not only,

pre-existing components.

4. The present invention provides a reusable object that implements fundamental software

mechanisms related to state machines in a way that makes these mechanisms readily available to system developers, without requiring substantial understanding of their

implementation.

5. The present invention provides a reusable object that implements a well-defined

mechanism or function in a way that allows this function to be combined with other

functions in unanticipated ways. 6. The present invention provides a reusable object defined so that it can be implemented in

a way that is independent from any specific application, so that it can be reused easily in new and widely different application areas and domains.

7. The present invention provides a reusable state machine driver that can be used with different action handlers to provide different actions associated with the state machine

inputs and transitions while preserving the same state machine definition and transition

rules.

8. The present invention provides a reusable state machine driver that can used to implement multiple different state machines using the same software code, thereby reducing the required memory footprint to implement a given system.

9. The present invention provides a configurable state machine driver that can be configured

to implement wide variety of state machines without having to modify software code or develop new software code.

10. The present invention provides a configurable state machine driver that can be configured to implement wide variety of state machines without requiring a translation of the state

transition table to sequential software code.

11. The present invention provides a configurable state machine driver that can be configured at runtime so that the state machine and its transition rules can be modified at runtime.

12. The present invention provides a state machine driver that is separated from the object or code that implements the actions taken on each state machine transition, so that the state

machine driver can be implemented in a manner independent of these particular actions.

13. The present invention provides a state machine driver that is separated from the object or code that implements the actions taken on each state machine transition, so that the actions can be implemented simpler, without having to account for the current state, received inputs and associated transitions. 14. The present invention provides a state machine driver that is separated from the object or

code that implements the actions taken on each state machine transition, so that the object

or code that implements these actions can be reused with different state machine drivers that implement different state transition requirements.

15. The present invention provides a state machine driver component that can be used to build fully functional state machines by composing them from the state machine driver and

other ready-made components.

16. The present invention provides a state machine driver that can be composed with other

ready-made components to build more complex state machine drivers without duplicating or modifying its source code. Such more complex state machine drivers include but are not limited to state machine drivers with stack, with input postponing, with input queue

and dedicated thread, with timed state transitions and many others.

17. The present invention provides a state machine driver that is reentrant so that new inputs can be processed while a previous input is still being processed.

18. The present invention provides a state machine driver that does not require a dedicated thread and/or input queue, so that the state machines implemented with it can work in

various threading models, environments and application domains.

19. The present invention provides a state machine driver that can operate in interrupt context without requiring access to thread synchronization functions. 20. The present invention provides a well-defined mechanism for operating software state machines, so that state machines that use this mechanism will reliably produce the same

results even when run under different implementations of the state machine driver and

under different operating environments, thus improving software determinism and interoperability. 21. The present invention provides a state machine driver that can send a notification upon

completing any state transition, so that other objects can take respective action, such as resubmitting inputs that were previously postponed as result of the state machine being in

a state in which these inputs could not be processed. 22. The present invention provides a state machine driver that can send notifications upon

entering and leaving specific states, so that other state machines can be synchronized to the current state of a state machine.

23. The present invention provides a state machine driver that can send notifications upon entering and leaving specific states, so that watchdog or periodic timers can be controlled

by those notifications, enabling the state machine to perform actions or transitions upon expiration of a time period in absence of other input.

24. The present invention provides a state machine driver that can send notifications upon

entering and leaving specific states, thereby enabling the implementation of hierarchical

state machines, where subordinate state machines are controlled by those notifications. 25. The present invention provides a state machine driver that can be interconnected with other instances of the same state machine driver or with other state machines to provide

arbitrarily complex state machines.

26. The present invention provides a state machine driver with built-in implementation for frequently used simple actions, such as forward, generate and serve [described in detail in

the CDS~pn$$], so that the handling of most events does not require additional software.

27. The present invention provides a state machine driver that can propagate the return code of an output as the return code for the input that led to that action, thus significantly

reducing the number of intermediate inputs and states that would be otherwise needed to provide feedback. 28. The present invention provides a state machine driver that can send exception

notifications when it detects errors that the state machine is not designed to handle,

thereby allowing other, higher-level software to provide the necessary handling, such as to terminate a communications session that is in error. 29. The present invention provides a state machine driver that can send exception notifications that, unlike traditional operating system or language exceptions, can be

processed asynchronously, without affecting the thread of control that provides input into the state machine.

30. The present invention provides a state machine driver that can treat input events that carry the same event identifier but have different event attributes as different inputs for the state

machine, so that no special translation is necessary to properly handle asynchronous requests and their completions as different inputs.

31. The present invention provides a state machine driver that accepts polymoφhic events as input and generates polymoφic events as output, so that the state machine driver

implementation does not have to change depending on the particular mechanism by which the inputs and outputs are provided in the system.

32. The present invention provides a state machine driver that can be encapsulated together with a specific state machine descriptor table to form a new object class, so that the new

object class can be delivered, instantiated and used without having to know or disclose the

specific state transition table.

Portions of the present invention may be conveniently implemented using a conventional general puφose or a specialized digital computer or microprocessor programmed according to the teachings of the present disclosure, as will be apparent to those

skilled in the computer art. Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art.

The invention may also be implemented by the preparation of application specific integrated

circuits or by interconnecting an appropriate network of conventional component circuits, as will be readily apparent to those skilled in the art.

The present invention includes a computer program product which is a storage

medium (media) having instructions stored thereon/in which can be used to control, or cause,

a computer to perform any of the processes of the present invention. The storage medium can

include, but is not limited to, any type of disk including floppy disks, mini disks (MD's),

optical discs, DVD, CD-ROMs, microdrive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices (including flash cards),

magnetic or optical cards, nanosystems (including molecular memory ECs), RAED devices,

remote data storage/archive/warehousing, or any type of media or device suitable for storing instructions and/or data.

Stored on any one of the computer readable medium (media), the present invention includes software for controlling both the hardware of the general puφose/specialized computer or microprocessor, and for enabling the computer or microprocessor to interact with

a human user or other mechanism utilizing the results of the present invention. Such software

may include, but is not limited to, device drivers, operating systems, and user applications.

Ultimately, such computer readable media further includes software for performing the present invention, as described above.

Included in the programming (software) of the general/specialized computer or

microprocessor are software modules for implementing the teachings of the present invention, including, but not limited to, requesting web pages, serving web pages, including html pages, Java applets, and files, establishine socket communications, formatting information requests, formatting queries for information from a probe device, formatting SMNP messages, and the

display, storage, or communication of results according to the processes of the present invention.

Those skilled in the art will appreciate that various adaptations and modifications of

the just-described preferred embodiments can be configured without departing from the scope and spirit of the invention. Therefore, it is to be understood that, within the scope of the appended claims, the invention may be practiced other than as specifically described herein.

Claims

What is claimed is: 1. A method for designing a state machine in a software system, said software

system containing a plurality of object classes, said method comprising:

designing a state machine driver object class that receives at least one first

state machine input, keeps at least one state variable, performs at least one state transition, and emits at least one first state machine output;

designing an action handler object class that receives at least one second

input and takes one or more actions in response to said at least one second input;

and designing a structure of connected objects in which an instance of said state machine object class is connected to an instance of said action handler object

class so that said first state machine output is received as said second input.

2. The method of Claim 1, wherein said state machine driver object class is

replaced with a plurality of state machine driver object classes.

3. The method of Claim 1 , wherein said action handler object class is replaced with a plurality of action handler object classes.

4. The method of Claim 3, wherein said object classes are parts.

5. The method of Claim 1, wherein said structure of connected objects is built

using object inheritance.

6. The method of Claim 1, wherein said structure of connected objects is built using an object composition system.

7. The method of Claim 1, wherein said state machine driver object class is a configurable state machine driver.

8. The method of Claim 7, wherein said state machine driver is further parameterized with a state transition table.

9. A method for implementing a hierarchical state machine in a software

system, said software system containing a plurality of state machine driver objects, said hierarchical state machine having a plurality of master states and a plurality of

subordinate states, said method comprising:

creating a first state machine driver object that controls said plurality of

master states; creating a second state machine driver object that controls said plurality of subordinate states.

10. The method of Claim 9, further comprising connecting said first state machine driver object and said state machine driver object.

11. The method of Claim 9, further comprising sending a first notification

from said first state machine driver to said second state machine driver.

12. A method for processing inputs of a state machine in a software system,

said method comprising: receiving a first input in a first state of the state machine;

locating an entry in a state transition table, said entry being associated with said first input and said first state, and said entry containing a second state of the state machine and a first state machine output;

changing the state of the state machine to said second state; and sending said first state machine output.

13. The method of Claim 12, wherein said method is implemented by general puφose program code that is independent of the state machine.

14. A part in a software system, said part comprising: a first terminal for receiving state machine inputs; a second terminal for sending state machine action events; a state variable for keeping the current state of a state machine;

a property for configuring said part with a state transition table;

means for changing the value of said state variable based on a first input received through said first terminal and based on the value of said state variable at the time said first input was received; and

means for choosing either one or no action event to be sent through said

second terminal based on said first input and based on the value of said state variable at the time said first input was received.

15. The part of Claim 14 further comprising a third terminal for sending a notification that indicate that the value of said state variable has changed.

16. The part of Claim 14 further comprising a third terminal for sending

exceptions that indicate that said part has detected an error.

17. An object class in a software system, said object class comprising a

section of program code that executes different state machines based on configuration

data that resides outside of said object class.

18. A structure of connected parts in a software system, said structure comprising: a first state machine driver part that maintains the current state of a state machine, determines and performs state transitions, and emits a first plurality of

outputs; and a first action handler part that receives said first plurality of outputs and performs associated actions.

19. The structure of Claim 18, wherein said first action handler part sends feedback events to said first state machine driver part.

20. The structure of Claim 18 further comprising a timer part for causing state transitions in absence of input events.

21. The structure of Claim 20, wherein said timer part is controlled by

notifications sent when said first state machine driver part enters and leaves a predetermined state.

22. The structure of Claim 18 further comprising a buffer part for keeping

inputs that cannot be processed in at least one state of said first state machine driver

part.

23. The structure of Claim 22, wherein said buffer part flushes any buffered inputs upon receiving a notification that indicates that said first state machine driver part has changed its state and is able to process at least one of said buffered inputs.

24. The structure of Claim 18, wherein said first state machine driver part is a composite part.

25. The structure of Claim 18, wherein said first state machine driver part is replaced with a structure of parts.

26. The structure of Claim 18, wherein said first action handler part is an

assembly.

27. The structure of Claim 18, wherein said first action handler part is replaced with a structure of parts.

28. The structure of Claim 18 further comprising a second state machine '

driver part that maintains a plurality of subordinate states.

29. The structure of Claim 28, wherein said second state machine driver part

receives as input a plurality of notifications, said notifications indicating that said first state machine driver part has entered or left a predetermined state.

30. The structure of Claim 18, wherein said first state machine driver part can be configured with different state transition tables without modifying program code of said first state machine driver.

31. A method for defining a state machine, said method comprising: defining an identifier for each state of the state machine; defining an identifier for each input of the state machine;

for each state, defining a state entry containing the identifier for the state,

and for each state defining at least one transition entry; and

for each input in a given state, defining a transition entry containing the identifier for this input, the identifier for the next state and an action code.

32. The method of Claim 31 , wherein for each state further defining a state entry containing the state enter and state leave notifications.

33. A state machine descriptor object, said object comprising:

at least one state entry, said state entry containing a state identifier field; at least one transition entry, said transition entry containing an input identifier field, a next-state field and action code field.

34. A state machine descriptor object, said object comprising at least one transition entry, said transition entry containing a state identifier field, an input

identifier field, a next-state field and an action code field.

35. A method for designing a state machine in a software system, said software system having at least one object class and having at least one configurable

state machine driver class, said method comprising: designing a state transition chart for said state machine;

identifying the state machine actions that need to be performed on the state transitions;

converting said state transition chart to a state machine descriptor in a format required by said configurable state machine driver class; designing an action handler class that implements the identified state machine actions; and

designing a structure of connected instances that includes at least an instance of said configurable state machine driver class and an instance of said action handler class.

36. A method for implementing a state machine in a composition-based

software system, said method comprising:

creating a first object which is a state machine driver;

creating at least one second object which is an action handler; connecting said first object and said second object.

37. The method of Claim 36 wherein said first object is a configurable state machine driver that is configured with a first data set, said first data set describing a

state transition table.

38. A method for building a composite state machine driver in a software

system, said software system containing a plurality of state machine drivers, said method comprising:

creating a first state machine driver;

creating a second state machine driver; establishing a connection between said first state machine driver and said second state machine driver, so that said first state machine driver can send a notification to said second state machine driver.

39. A method for building a composite state machine driver in a composition- based software system, said software system containing at least one state machine driver component and a plurality of reusable components, said method comprising: creating a state machine driver component instance;

creating an instance of a reusable component;

establishing a connection between said state machine driver component

instance and said instance of a reusable component.

40. The method of Claim 39, wherein said instance of a reusable component is an instance of an event buffer component.

41. The method of Claim 39, wherein said instance of a reusable component is

an instance of a desynchronizer component.

42. The method of Claim 39, wherein said instance of a reusable component is an instance of an multiplexor or switch component.

43. The method of Claim 39, wherein said instance of a reusable component is an instance of timer component.

44. A method for building a state machine with a postpone function, said

method comprising: creating an instance of a state machine driver;

creating an instance of an event buffer with postpone capability; establishing a connection between the output of said event buffer and the

input of said state machine driver; and establishing a connection between an output of said state machine driver and the control terminal of said event buffer.

45. A method for handling errors in a hierarchical state machine, said hierarchical state machine containing a master state machine driver, a subordinate

state machine driver, said method comprising:

sending a first notification from a said subordinate state machine driver, said notification indicating that a first error has occurred;

receiving said first notification by said master state machine driver; and

performing a state transition in said master state machine driver to handle said first error.

46. A method for building a state machine driver in a software system, said method comprising:

designing a configurable state machine driver that can be configured with a state transition table;

designing a state transition table; creating an instance of said configurable state machine driver; and configuring said configurable state machine driver with said state transition

table.

47. A method for building a state machine driver in a software system, said method comprising:

designing a configurable state machine driver that can be configured with a state transition table;

designing a state transition table; designing a composite object class that encapsulates said configurable state

machine driver and said state transition table so that creating an instance of said composite object class causes an instance of said configurable state machine driver

to be created and configured with said state transition table.

48. An object in a software system, said object comprising:

a first input for receiving state machine input events; a first property for receiving a first configuration data;

a first state variable; a first means for locating a first state value from said first configuration

data, said state value associated with a second state value and a first identifier of

an input event; a second means for assigning a new value to said first state variable in

response to a first input event received on said first input, said new value being determined using said first means, where said first state value is the said new value, the present value of said first state variable is said second state value and

the identifier of said first input event is said first identifier.

49. The object of Claim 48, wherein said first property is replaced with a

second property for receiving a reference to said first configuration data.

50. The object of Claim 48, further comprising a first output for sending state machine output events.

51. The object of Claim 50 further comprising a third means for locating an identifier for an event to be sent through said first output, said identifier being located in said first configuration data and associated with said second state value and said

first identifier.

52. The object of Claim 48, wherein said first property is replaced with a second input for receiving said first configuration data.

53. The object of Claim 48 further comprising a second output for sending state machine notifications.

54. An object in a software system, said object comprising:

an input for receiving state machine input events; an output for sending action requests; a state variable; and

a section of program code for selecting a new value of said state variable

based on a present value of said state variable at a time when a first input event is

received on said first input, and for selecting an action request to be sent through said output based on a present value of said state variable at a time when a first input event is received on said first input.

55. The object of Claim 54, wherein said section of program code uses an

externally provided table to determine said new value and said action request.

56. A composite state machine object, said composite object having a first

state and performing a first plurality of actions, said composite object consisting of a state machine driver object and an action handler object, said state machine driver object performing state transitions of said first state and said action handler object

performing said first plurality of actions.

57. A composite state machine object, said composite object comprising:

a state machine driver object that maintains state and performs state transitions; and a plurality of interconnected reusable objects, said reusable object not

designed specifically for the puφose of said composite object.

58. A composite object in a software system, said composite object

comprising: a configurable state machine driver object; and a state transition table.

59. An object class in a software system, said object class implemented so that

instances of said object class can be configured with different state transition tables in order to achieve behavior of different state machines.

60. A state machine object in a software system, said object having a state, said object being configured with a state transition table, and said object sending a

notification whenever said state changes.

61. A state machine object in a software system, said object comprising:

a state variable; means for sending a notification when said state variable is changed so that its value matches a predetermined value; and means for sending a notification when said state variable is changes so that

its value no longer matches a predetermined value.