Data processing: software development – installation – and managem – Software program development tool – Programming language
Reexamination Certificate
2000-01-11
2004-07-20
Nguyen-Ba, Antony (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Programming language
C717S104000, C709S241000, C709S241000
Reexamination Certificate
active
06766508
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to object-oriented programming techniques, and more particularly, to a method and apparatus for scheduling control input in an embedded real-time system using anonymous events.
BACKGROUND OF THE INVENTION
Object-oriented design is a design discipline that promotes good software design by providing tools that make it easy to create modules that are independent of one another. Dependencies between modules are minimized through the creation of interfaces that do not depend on specific implementations. Each object within an object-oriented system is defined by an interface and an implementation. Software clients external to the object depend completely on the object interface, and not the details of the object implementation. The implementation of an object contains the mechanisms and detail necessary to carry out the behavior of the object.
Object-oriented programs are collections of objects that relate to one another through these abstract interfaces. For a more detailed discussion of object-oriented designs, see, for example, Booch, Grady, Object-Oriented Analysis and Design with Applications (Benjamin Cummings, 1994); Martin, Robert C., Designing Object-Oriented C++ Applications Using the Booch Method, (Prentice Hall, 1995); Jacobson, Ivar, Object-Oriented Software Engineering, (Addison Wesley, 1992) or Rumbaugh, et. al., Object-Oriented Modeling and Design, (Prentice Hall, 1991), each incorporated by reference herein.
The collections of objects are themselves the subject of organization into modules that have a defined interface and embody some aspect of overall system behavior. Useful organizational patterns of these object collections have emerged as reusable solutions to specific problems in object-oriented design. Recognizing these common collaborations among objects can lead to the development of a system architecture that is smaller, simpler, and more understandable. These design patterns capture the structure of solutions that occur repeatedly in a particular design context.
Object-oriented patterns related to this invention include (i) the Command pattern described in Gamma, et. al., Design Patterns Elements of Reusable Object-Oriented Software, (Addison Wesley, 1994); (ii) the Pedestal and Reactor patterns described in Coplien & Schmidt, Editors. Pattern Languages of Program Design 1, (Addison Wesley, 1995); (iii) the Command Processor and Half Sync/Half Sync patterns described in Vlissides & Coplien & Kerth, Editors, Pattern Languages of Program Design 2, (Addison Wesley, 1996), and (iv) the Recursive Control pattern described in Martin & Riehle & Bushman, Editors, Pattern Languages of Program Design 3, (Addison Wesley, 1998). The discussions of each of these object-oriented patterns are incorporated by reference herein.
Object-oriented designs and design patterns are also applicable to real-time embedded systems. An embedded system is a computing solution developed for a specific real-world application, usually as a control mechanism for electronic equipment or devices. The term “real-time” implies that these systems have temporal requirements. Such systems are developed to satisfy the following three primary criteria: guaranteed timing deadlines, predictable response times, and stability in overload. A real-time system is said to be deterministic if it can guarantee the response time to control events. For a more detailed discussion of real-time design issues, see, for example, Klein et. al., A Practitioner's Handbook for Real-Time Analysis: Guide to Rate Monotonic Analysis for Real-time Systems, (Kluwer Academic Publishing, 1993), incorporated by reference herein.
Even within the possibilities granted by the above-described object-oriented designs and design patterns, it is still a common practice in embedded real-time systems to custom design an object model for each new set of requirements. Despite the apparent advantages, the reuse of object components in practice is minimal. This is due, in part, to the temptation of designers to treat each design uniquely. On the most basic level, most embedded real-time designs share a remarkably common set of requirements. Specifically, the system accepts a control input, processes the control input according to some established criteria (or control policy), and issues a set of commands to its associated hardware (through the hardware access layer, or drivers). While the control policy of a system and its hardware access layer may be arguably unique, the control input does not have to be.
There are three distinct quality of service (QoS) levels required in most multi-purpose embedded real-time systems. A quality of service is a means to classify response times for events. Automation of a system usually involves a control interface to an external computer. By necessity, this interface must guarantee a consistent and predictable level of performance and provide fast response times to meet the expectations given a machine-to-machine interface. Closely related to immediate automation commands is the desire to schedule events for execution at a specific time in the future. Such ability would be desirable, for example, if the event were either bound to an exact time, or multiple system components needed to execute events synchronously in order to conduct a facility-wide event.
These deferred events (i.e., events scheduled for execution at a specific future time) are usually issued through an automation interface, but stamped with a specific execution time. Although the use of automation to control embedded systems continues to increase, direct manual control will always be required. The quality of service demands of a human interface, however, differ significantly from the expectations of an automation interface. Where it is reasonable to expect the fastest response times from a machine, humans do not have such instant needs. Instead, response times must only be sufficient to give the human operator a perception of connection with the system by meeting human sensory perception deadlines.
Current systems rarely make distinctions for events based on these different levels of quality of service, opting instead for the simplicity of handling all events in the same way. This leads to several problems. When higher priority automation events are held off, waiting for system resources behind lower-priority manual events, a priority inversion occurs. Deferred events, when supported at all, are usually held in a container (or queue) until their execution time arrives, and then must contend for resources with other events at that time. Since there are no guarantees that system resources will be sufficient at the execution time for a given event, a delayed validation may occur. A delayed validation occurs when the system accepts an event for processing at a later time, but the event fails due to conditions present at the scheduled run-time.
Moreover, deterministic (guaranteed and predictable) response times, critical to the requirements of an automation interface, are usually handled by processing events as “fast as possible.” The resulting worst-case performance is measured and automation events are specified with a hold-off time. Each new revision of the software must then be measured and hold-off times renegotiated with end users.
Currently, there is no design pattern that adequately addresses control input processing in current embedded systems design. Control input processing issues are usually tightly bound with the unique design of the control policy, making reuse impractical and performance tweaking a must. Thus, the control policy of the application is burdened with the responsibility of maintaining real-time design goals.
A need therefore exists for an object-oriented design pattern that addresses the above-described deficiencies in the current design of embedded real-time systems. A further need exists for an object-oriented class pattern that abstracts the control input scheduling in an embedded real-time system using anonymous events.
SUMMARY OF THE INVENTION
Koninklijke Philips Electronics , N.V.
Nguyen-Ba Antony
LandOfFree
Object-oriented system having anonymous scheduler design... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Object-oriented system having anonymous scheduler design..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Object-oriented system having anonymous scheduler design... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3214962