Layered object based software architecture for statechart-centric embedded device controllers

A computer software architecture for an embedded computer system. The architecture includes a hierarchy of software object classes. One classification contains object tables which capture device control law behavior expressed in statecharts. Another contains objects which collaborate to function as a logic engine for processing statechart information encoded into object tables. In order to promote reusability, the architecture is layered in increasing levels of system abstraction.

TECHNICAL FIELD

The present invention relates to systems and methods for capturing device controller control laws in embedded computer systems.

BACKGROUND OF THE INVENTION

Over the years, the responsibility for device control (e.g., pumps, valves, actuators and the like) has migrated to embedded processors. The traditional way of capturing the behavioral requirements for a device controller was with textural descriptions. While this approach worked for simple devices, it failed when confronted with more complex behaviors. Recognizing that device controller behavior is state oriented, coupled with the advent of powerful state machine modeling tools, capturing the behavior requirements in verifiable statecharts soon became the method of choice.

While there are many ways to design embedded software that will carry out device control laws, they tend to be designed around the specific device functions, resistant to requirement changes, and do not take advantage of the statechart modeling environment. What is lacking is a sophisticated software architecture that embeds the actual statechart behavior, is designed for rapid change processing, and can be used with a family of devices.

SUMMARY OF THE INVENTION

The present invention constitutes a radical departure from conventional embedded device controller design solutions pursued previously, such as those described above.

According to one aspect of the invention, a computer software architecture is provided for capturing the properties and behavior of device control laws expressed in the form of state charts within a machine-implemented embedded device control application. The architecture includes a condition class for capturing one or more sets of conditions present in statechart models; an action class for capturing actions to be performed while in a particular state; a transition class for capturing sets of transitions between states; a group of state classes for capturing parallel state and sub-state interrelationships within a statechart; and a class for capturing time delays between state transitions.

In accordance with another aspect of the invention, a computer software architecture is provided for processing control laws expressed in the form of state charts within a machine-implemented embedded device control application. The architecture includes an event recognition layer including at least one event recognizer object; a state determination layer including at least one state controller object; an event response layer including at least one event responder object; and a logic engine including a condition recognizer object, a logic parser object and a temporary storage object.

DETAILED DESCRIPTION OF THE INVENTION

The present invention will now be described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout.

Although the invention is described herein with reference to a specific embodiment such as an embedded device controller, this is for purposes of illustration and clarity only, and should not be construed in a limiting sense. Those skilled in the art will readily appreciate that the invention can be generally utilized with any application wherein state oriented behavior is a parameter of primary interest. Furthermore, the invention is not limited to a particular style of statechart modeling, and can accommodate both Mealy and Moore styles within the same model.

Referring initially toFIG. 1, a device control system10is shown in accordance with an exemplary embodiment of the present invention. The system10includes a device controller12which controls a device14. The device14may be any type of device without departing from the scope of the invention. For example, the device14may be a discrete device such a motor, pump, valve, actuator, etc. Alternatively, the device14may be a system or sub-system such as a brake control system, traction control system, monitoring system, etc.

The device controller12may be any type of automated controller without departing from the scope of the invention. For example, the device controller12may be based upon any of a variety of micro-type controllers such as commercially available microcontrollers, microprocessors, etc. In addition, or in the alternative, the device controller12may be based upon larger controllers in the form of a dedicated personal computer, server, mainframe, etc. Still further, the device controller12may be based on configured hardware such as a programmable logic array (PLA), programmable logic controller (PLC), or the like.

Furthermore, the device controller12is programmable in accordance with the layered object based software architecture of the present invention. As will be described in more detail below, the software architecture of the present invention is a layered architecture for processing control laws of the device14expressed in the form of state charts. The software architecture may be embodied in machine executable code which is executed by the device controller12. The machine executable code is stored in an information storage medium such as digital memory (volatile or non-volatile), magnetic disk, optical disk, floppy disk, etc., represented generally by16, which is accessed and executed by the device controller12. Alternatively, the software architecture may be embodied in the hardware design of the PLA, PLC, etc., again represented generally by16.

In the exemplary embodiment of the present invention, the device controller12is an embedded device controller. In the context of the present invention, “embedded device controller” refers to a controller12which controls the device14, wherein the device14may or may not be part of a larger system.

As is shown inFIG. 1, the device controller12issues control commands to the device14as represented by line20. In addition, the device controller12receives control signals from the device14as represented by line18. In a case where the device14is a motor, for example, the control commands may turn the motor on, off and vary the speed of the motor. The control signals, on the other hand, may indicate operation properties such as motor position, measured speed, current, etc. The software architecture of the present invention, as embodied in the device controller12, provides for control of the device14based on the state charts defining the operation of the device14.

Referring now toFIG. 2, the embedded computer software architecture of the present invention is illustrated in its respective layers. Specifically, the software architecture of the present invention provides for performing the three main functions required within the domain of device controllers: event recognition, state determination, event response. The architecture includes an event recognition layer22of software objects having responsibility for detecting the occurrence of events that may trigger a change in the current state of the controller12.

The event recognition layer22makes use of a logic engine24included within the software architecture. The logic engine24is composed of objects that can process logical expressions of parameters encoded in Reverse Polish Notation (RPN) or other tabular parsable format, for example. However, it will be appreciated that other forms of logical expressions are possible without departing from the scope of the invention. The software architecture further includes a state determination layer26having objects for condition evaluation, state determination and object coordination. The state determination layer26also makes use of the logic engine24objects. The software architecture additionally includes an event response layer28. The event response layer28contains objects responsible for issuing the device control commands associated with the control laws of the current state of the device controller12.

As is discussed herein, a class framework is provided for encoding the conditions, structural components and interconnections found on statecharts, into a series of classes that are embedded within the device controller12and are operated on by the various software architecture layers22,26and28. It will be appreciated that a “class” as referred to herein typically defines data, data types, and operations on the data. The realization of a specific case of a class or classes is an instance of the class or classes which is referred to herein as an “object”.

The software architecture of the present invention provides a direct correlation between the device control requirements modeled in statechart format and the embedded device control software. One having ordinary skill in the art of object based programming will appreciate that the requirements may be modeled in a tool that uses standard statechart notation, and a utility can be written to extract the statechart elements from the tool and automatically populate the statechart class framework objects. The use of the architecture set forth herein in accordance with the present intention improves behavioral verification and end user understandability since the parameters within the embedded controller12directly correlate to elements within the requirements model. This software architecture also makes changes to the requirements easier to achieve by encoding the statechart elements into software structures rather than in-line code.

The implementation of the logic engine24along with the event recognition layer22and state determination layer26provide strong support for reuse by being device independent thereby allowing the same architecture to support families of device controllers.

With reference toFIG. 3, a simplified class diagram is provided to define the overall structure30and relationship of the embedded objects used to capture the various elements of a typical statechart. A generic statechart is provided for reference purposes inFIG. 4. Referring toFIG. 3, the structure30includes a condition class32provided to capture one or more sets of conditions. These conditions (including action expressions) are encoded in RPN and are used to determine whether or not a transition can be taken as well as for evaluating the assignment statement(s) for any “entry”, “during” or “exit” actions associated with a state. (See, e.g., State1inFIG. 4). The structure30also includes an action class34provided to capture the actions to be performed while in a particular state. The expressions are encoded in RPN or other tabular parsable format and handled the same as conditions in the condition class32. For each state, the structure30identifies a link, such as an index, into the set of conditions for the entry, during and exit expressions associated with the state. A transition class36is included to capture the sets of transitions between states. Each transition (e.g., T1inFIG. 4), is identified via a “From State” and a “To State” as well as with an index of a condition (e.g., C1:exp inFIG. 4) used to evaluate if the transition should be taken.

The set of transitions for a parallel state are grouped together. Since Harel's extensions to finite statemachine theory are embodied within most modern statechart modeling tools, the structure30of the present invention provides a group of state classes, e.g., a parallel and sub-states class38, for capturing both parallel state and sub-state interrelationships within a statechart. (See, e.g., State2inFIG. 4). Because of the nature of real-time embedded controllers12, delays between transitions may need to be modeled. Accordingly, the structure30includes a class40to capture these requirements. (See, e.g., delay inFIG. 4). The state chart model may also contain tables of logical expressions (conditions) captured within the condition class32, for example, whose resulting parameters appear within the body of the state chart.

Referring now toFIG. 5, in the exemplary embodiment of the invention, the statechart objects described above in relation toFIG. 3are coupled with the objects of the event recognition layer22(consisting, for example, of a single event recognizer object), the state determination layer26(consisting, for example, of a single state controller object), and the event response layer28(consisting, for example, of a single event responder object), as well as to the logic engine objects24, to make a complete framework for processing the statechart control logic. A class diagram of the exemplary embodiment of the framework is shown inFIG. 5, with interface entity classes44and a command request queue class46, included as an example of how the framework would interface to the rest of an application architecture. The objects in each of these layers, as well as the coordination of their operations by the state controller object in the state determination layer26are discussed in greater detail below. Although the exemplary embodiment includes only a single object in the respective layers for sake of brevity, it will be appreciated that each layer may include any number of objects without departing from the scope of the invention.

The individual functions of the state controller object within the state determination layer26include retrieving data from the entity classes44that is required to evaluate all of the conditions contained within the state chart structure30, determining the current state of operation based on the state charts, and using this information to generate a device(s) command(s) appropriate for the current state. The state controller class within the state determination layer26also coordinates the activities of a condition recognizer object48, the event recognizer object of the event recognition layer22, and the event responder object of the event response layer28.

The condition recognizer object48is part of the logic engine24, and is responsible for evaluating sets of tabularized logical expressions used to set parameters which appear within the body of the state chart30.

The event recognizer object within the event recognition layer22is responsible for evaluating the state transition criteria contained within the state chart30, and determining when a transition can be made to a new state based on the evaluated conditions. Once the current state is determined, the event recognizer in the event recognition layer22performs any associated entry, exit or during actions, which are stored in the action object34within the state chart structure30.

The event responder object within the event response layer28assembles device commands from the state controller object in the state determination layer26, resolves any conflicts (conflicts can arise in complex applications in which a device may receive commands from multiple sources, in which case a priority scheme can be used) and queues the resulting command(s) for output to the device14via the command request queue46.

Both the event recognizer object in the event recognition layer22and the condition recognizer object48use a logic parser such as an rpn calculator object50included in the logic engine24to evaluate their logical expressions. The rpn calculator object50is responsible for evaluating a tabular expression stored in Reverse Polish Notation, for example. It returns the result of the evaluation to the calling object. For added flexibility the rpn calculator object50in the exemplary embodiment of the invention supports boolean, integer and floating point parameters, which are common data types within embedded controller systems.

A temporary storage object such as a stack object52also included in the logic engine24is utilized by the rpn calculator object50when performing its evaluations. The stack object52provides a last in first out (LIFO) storage mechanism for Boolean or numeric data. In the exemplary embodiment of the invention, the stack object52provides the classic stack operations of read, write and empty (e.g., push, pop and is empty).

The layered object based state chart architecture described above not only meets the needs of the device controller domain, but is also capable of application as a generalized logic engine. Through the software architecture, a number of domain characteristics and advantages have been identified. For example, the system is tolerant to changes made to the statechart because they result in table object changes which therefore eliminates the need to re-verify the code within the various object layers. Since the objects within the various layers provide functions related to logic processing rather than operations functions, the system is highly reusable, thus providing improved long-term affordability and efficiency.

Turning now toFIG. 6, an exemplary statechart diagram for controlling a pump device14between an on state and an off state is shown. In accordance with the software architecture of the present invention, the condition class32(FIG. 3) may be populated as follows:

Similarly, the transition class36(FIG. 3) may be populated as follows:

The action class34(FIG. 3) may be defined as follows:

The parallel and sub-states class38(FIG. 3) may be populated as follows:

PARALLEL & SUB STATES (Structure)

For sake of efficiency, and thus avoid the need to copy data elements, a pointer table may be provided and each element of the state chart assigned a pointer ID. Although not necessary to the present invention, it will be appreciated that the pointer table may be included as part of the state chart structure30. In the exemplary application, the pointer table may be defined as follows:

POINTER Table

The RPN calculator50in the logic engine24may be configured as follows:

RPN CALCULATOR

The device controller12as shown inFIG. 1may be programmed as set forth above in order to control a the pump14, as will be appreciated by those having ordinary skill in the art of programmable controls. Accordingly, additional detail is omitted herein for sake of brevity.

As previously noted, the software architecture of the present invention provides a direct correlation between the device control requirements modeled in statechart format and the embedded device control software. One having ordinary skill in the art of object based programming will appreciate that the requirements may be modeled in a tool that uses standard statechart notation, and a utility can be written to extract the statechart elements from the tool and automatically populate the statechart class framework objects. The use of the architecture set forth herein improves behavioral verification and end user understandability since the parameters within the embedded controller12directly correlate to elements within the requirements model. This software architecture also makes changes to the requirements easier to achieve by encoding the statechart elements into software structures rather than in-line code.