The present invention relates generally to a programming tool for software development. More specifically, the present invention relates to a tool for developing and executing real-time control systems.
Real-time system software is notoriously complex. Large projects must balance the special needs of real-time softwarexe2x80x94such as event processing, data sampling, and feedback controlxe2x80x94with the needs of interacting teams of programmers, engineers, managers, and maintenance personnel. Successful projects require solid software architecture, an intuitive, graphical programming paradigm, and a well-developed reuse capability.
Building software for real-time control systems is a huge challenge. The software must coordinate actuators, sensors, and interactions with the real world. It must deal with complex and intelligent subsystems. Many systems are large applications developed by teams of programmers, engineers, architects, and managers. All team members must be able to both understand and contribute to the design. The demands for a modular, clean design are compounded by the special needs of control systems such as control and sequencing. Systems are built, simulated and tested incrementally for best results. Significant legacy code embodying years of experience is often required to be used. In the past, these control systems defied reorganization. Prior art development tools for such complex systems have simply not been able to keep pace with the demands of these complex systems.
Development tools built for other real-time applications-such as telecommunications or databases-are not well suited to the challenges of complex control systems. In particular, they are not well-suited for complex electromechanical systems. Generic programming languages and methodologies are useful for modeling. They carefully define the nuances of syntax and meta language. But often they do not truly accelerate development. In particular, prior art object-oriented modeling tools are useful for some systems as will be described below, but are not well suited for the needs of complex, real-time control systems.
Prior art mathematical simulation tools can also be useful. They allow you to build and test dynamic models of the physical processes in your system. However, in most systems they only apply to a small percentage of the total problem. They are not good programming systems, and thus cannot handle truly complex systems that require significant custom coding. In particular, mathematical simulation tools are useful for certain applications as will be described below, but are also not especially well-suited for the needs of complex, real-time control systems.
In general, two approaches have been used in the prior art to develop complex software systems: top-down design and bottom-up design. Top-down design means breaking the problem into smaller and smaller parts until the pieces can be implemented easily. Top-down design is very general and powerful; it can eventually solve most problems. It is also intuitive, it allows division of labor, and it encourages rapid prototyping through consideration of intermediate incomplete models of a complex system. It provides a high level view important to communication and understanding between team members and management.
Most people naturally think of complex systems in a top-down, object-oriented fashion. For instance, when you describe a car, you think of the engine, the frame, the transmission, and other systems as functional, complete objects that cooperate to make the whole complex system. However, the top-down design process has a serious flaw: it leads to unique solutions to every problem. Each top-down design subdivides the problem in a unique way. None of the resulting subsystems can be reused easily. A top-down design has been called xe2x80x9cthe process of making all your worst mistakes first.xe2x80x9d A top-down designer building a car would start with a concept drawing, and break it into subsystems as best fit the problem. However, like a concept car, the result will contain many strange parts that all have to be painstakingly handcrafted.
Often, prior art object-oriented modeling tools are thought of as providing a top-down design approach because they provide an object model view of the world. In particular, various prior art object modeling tools work well for general problem areas, but are not optimal for complex, real-time control systems. For example, one object modeling tool available from Rational Corporation of Sunnyvale, Calif. is called xe2x80x9cRose.xe2x80x9d Rose is based on the well-known Unified Language Modeling (UML) graphical development tool (a general tool). Rose provides event-driven processing for general problem areas. Another UML-based tool is xe2x80x9cRhapsody,xe2x80x9d available from iLogix Corporation of Andover, Massachusetts that also addresses general problem areas. Another representative object modeling tool is xe2x80x9cObjecTime,xe2x80x9d available from ObjectTime of Ottawa, Canada. ObjecTime is based on the real-time object-oriented modeling (ROOM) language and is especially suited for modeling telecommunications systems.
In general, these prior art object modeling tools are based primarily on event-driven processing because of the problems to which they are addressed. They are not well-suited for, and are unable to handle, sampled-data processing mainly because the problems they address do not require it. In general, these prior art object modeling tools do not provide sampled-data processing that is often critical in complex real-time systems. Specifically, these tools have no concept of matrices and are unable to implement detailed mathematical calculations nor evolve over time. These deficiencies mean that these tools may not be well-suited for certain real-time systems that require such complex mathematical simulations.
At the other end of the spectrum are bottom-up design tools. Bottom-up design is the process of synthesizing from preexisting components. A bottom-up design process for building a car would be to walk into an auto parts store and begin piecing together the vehicle from parts on the rack. Bottom-up design is great for reusing such parts. However, without the overall picture and goal in mind, it often does not result in a clean division of functionality. The bottom-up design process provides no overall view to communicate the goals and progress of a project between team members. Bottom-up design is important for reuse, however, and to achieve true leverage, software must be reused unmodified. By contrast, copying and modifying code creates many source versions that must be independently tested and maintained. Only true reuse generates the leverage that results in large dividends.
To be truly powerful, bottom-up design should support multiple levels of granularity. Small, functional components are easy to reuse, but do not provide large benefits. On the other hand, large-scale components provide large-scale benefits. The reuse of an entire subsystem as a component would accelerate greatly the next system""s implementation. But complex components have complex interfaces and specific functions. The more complex the component, the harder it is to reuse. Clearly, to maximize the benefits of component-based design, components should be reusable at different levels.
Many of the prior art mathematical simulation tools often are thought of as providing a bottom-up design. As such, they provide advantages for certain narrow problem areas, but are not well-suited for modeling complex real-time systems. One simulation tool is xe2x80x9cSimulink,xe2x80x9d available from Math Works of Natick, Mass. Another simulation tool is xe2x80x9cSystem Build,xe2x80x9d available from Integrated Systems, Inc. of Sunnyvale, Calif. These prior art simulation tools (and others) are based upon a mathematical model of the world and use complex matrix libraries to simulate a model using matrices. These tools are useful for simulating complex processes over time where complex calculations are involved. These tools typically provide sampled-data processing that can simulate a system and evolve over time.
These simulation tools, however, are not object-oriented programming tools and are not well-suited for modeling systems or for building complex real-time systems. Specifically, these tools are useful for building a data flow model of the world where intense number crunching is necessary, but they do not provide objects, methods upon objects, or the other beneficial features of object-oriented programming tools.
Unfortunately, often complex problems require both a top-down and a bottom-up approach. The two approaches are very different and require fundamentally different thought processes. Complex, real-time systems (and electromechanical systems in particular) may have a need for both data-flow processing as well as specific reactions to discrete events.
Therefore, a method and apparatus are desired that would provide the advantages of both top-down and bottom-up design for real-time control systems. Further, a method and apparatus are desired that would provide the object-oriented and event-driven capabilities of object-oriented modeling tools with the matrix manipulation and sampled-data processing features of mathematical simulation tools.
Another area of intelligent control that could benefit from improvement is the management of modes. Most complex systems require different operating modes. To illustrate, consider the simple example of a hybrid automobile powered by both gasoline and electricity. The car has both batteries and gasoline for use as fuel, and both an electric motor and a gasoline engine for propulsion. The car can be operated in two modes. In the zero-emission mode, the car uses the electric motor and the batteries. In the low-emission mode, the car uses the gasoline engine and the gasoline. Of course, real-life control systems are incredibly more complex.
Some prior art systems attempt to implement modes informally using ad-hoc implementation of xe2x80x9cif-then-elsexe2x80x9d statements. This technique is confusing and hard to understand and maintain. Other systems use special xe2x80x9cswitch blocksxe2x80x9d that run control lines to every other block within the system. These lines can become very complex and difficult to manage, let alone simply trying to figure out which mode the system is in. Furthermore, many complex systems often radically change modes of operation during execution. The designs of these systems may fail to consider the wide-ranging effects of these mode changes and xe2x80x9crun out of steamxe2x80x9d due to the complexity of the branches and switch blocks required. A fundamentally new approach to the management of modes would be desirable.
Another area of intelligent control that could benefit from improvement is the creation of executable programs for different purposes. Often a user will create a complex control system and its corresponding executable image to run on a specific real-time computer. The user, however, may wish to simulate the system on his or her own desktop computer. It can be time-consuming and complex to redo the system to make a simulation. Certain components only applicable to the real-time computer might have to be removed and substituted with simulation components.
Another area of intelligent control that could benefit from improvement is the optimal utilization of processing resources. Often different elements within a control system might need to run at different rates. The fast rate required for a particular sensor may be incompatible with the slower sampling rate of a different element. Simply slowing the whole system down to accommodate one slow rate element is not efficient. Conversely, speeding up the whole system to run at a fast rate is not feasible if one particular sensor or data sampling element cannot cycle that quickly. Further, it can be unwieldy to break the system into different pieces for different processors, only to try to cobble the system back together to make it function correctly. It would be desirable to take advantage of numerous processors and/or multiple threads of execution that may be provided by a real-time computer.
To achieve the foregoing, and in accordance with the purpose of the present invention, a development tool is disclosed that combines the advantages of a simulation tool with an object-oriented modeling tool. An embodiment of the present invention is based on a real-time mathematical matrix library, but also has an object model. Advantageously, most all real-time systems can be modeled using the present invention. The present invention supports the entire process for building complex real-time systems: design; development; execution; test; and maintenance. The present invention is well-suited for systems that have complex interactions, require strategic decisions, use control, have intelligent subsystems, and/or exhibit modal behavior.
In general, the present invention is applicable to any intelligent control system. In particular, the present invention is advantageous for developing software for real-time electromechanical systems. For example, the present invention is applicable to aerospace systems, robotics, autonomous vehicles, hardware-in-the-loop (HIL) test, semiconductor manufacturing equipment, and many other types of complex electromechanical systems. Nevertheless, the present invention is not to be limited to electromechanical systems, but can also be used for signal processing, process control, medical imaging, radar control, etc.
Advantageously, the present invention realizes that many real-time systems (and electromechanical systems in particular) have two very different aspects: continuous data flow and event-driven reaction. These two aspects are common to most complex systems, and in particular are fundamental in electromechanical systems. It is observed that in complex electromechanical applications, sampled-data processing and event-driven processing are tightly integrated. In fact, most real-time applications can be divided into recognizable subsystems that include both sampled-data and event-driven processing. For instance, a robotic system has subsystems for the arm, gripper, and vision. Each processes data continuously (i.e., cyclically samples data) but also executes sequences when events are detected.
One embodiment of the invention codifies this observed structure. The present invention introduces the concept of a composite object group, or xe2x80x9cCOGxe2x80x9d. A COG is an object that may contain both sampled-data and event-driven capabilities. COGs are extremely powerful in that they are intuitive, they merge procedural and object-oriented programming, and are they well-suited for implementing intelligent control systems. A COG provides explicit, graphical integration of both types of processing and are fully hierarchical. That is, you can design complex systems by building COGs made up of other COGs. A COG may also contain a third aspect, an interface. An interface specifies both the data flow through the COG and the set of methods the COG provides (implements) and uses.
In addition to combining event-driven and sampled-data processing, COGs are also able to bridge procedural and object-oriented design. Both event-driven and continuous data applications are most naturally thought of as occurring procedurally. Control engineers are used to thinking in this manner; control systems are built from blocks that process inputs and produce outputs. On the other hand, larger subsystems are most often best modeled as objects. Objects are usually thought of as executing independently of and concurrently with other objects. They communicate by exchanging asynchronous messages. Object-oriented design is fundamentally different than procedural thinking. As a COG is an object that is built from procedural components, it neatly bridges the gap between procedural thinking (more efficient at low engineering levels) and powerful object-oriented thinking (more efficient at higher system design levels).
Prior art modeling languages, such as C++ and UML, provide a means of describing arbitrary relationships between various objects for attacking general problem domains. Each object can contain arbitrary functionality. UML, for example, is an object-oriented graphical notation that is a very general modeling language. It is used for everything from airline reservation transaction systems to cellular telephone firmware. UML""s first primary function is analysisxe2x80x94the process of examining a problem and designing a structure that can solve the problem. This is a top-down approach. Each problem leads to a unique structure.
By contrast, the present invention uses COGs to model complex real-time systems, and in particular is well-suited for modeling electromechanical systems. This utilization of a specific object model bestows many benefits. For instance, it shortcuts much of the tedious analysis and object hierarchy design phase. The present invention provides specific data structures and reusable objects that fit specific problem domains. It allows problems to be modeled faster and complex code to be working more quickly. In addition, the present invention is not limited to providing only a top-down design approach as in UML.
Recognizing the tradeoff between top-down and bottom-up design, the present invention takes a unique merged approach. Top-down object decomposition is combined with bottom-up component-based synthesis from reusable software. This combined approach couples object-oriented design with the power of building systems from tested, preexisting software components. It uses an intuitive approach to developing systems that match how most engineers naturally design. Initially, a global, undefined concept is decomposed into more specialized subsystems (or modules). Along the way, reusable objects are defined and incorporated that ensure clean divisions between subsystems. Finally, subsystems are built from the bottom-up by graphically combining components from a repository of reusable software. This merged approach combines the power of object modeling with the leverage of component-based synthesis.
This top-down/bottom-up combined approach is very intuitive. It allows designers to work simultaneously at different levels of abstractionxe2x80x94today on the overall design, tomorrow on a specific subsystem. This makes it easy to iterate between partially-specified designs and fully-specified subsystems. In one aspect of the invention, interfaces are defined between subsystems during top-down decomposition. As long as the interfaces are unique, top-down decomposition continues. When the design is refined to the point that existing components can be used, these components are then used to fill in the functionality needed. Thus, design may begin from the top-down, but eventually commonly defined components are reached during the process. Prior art tools have provided no mechanism for this combined design to occur.
The present invention also provides a technique by which a commonly used object interface may be defined as a reusable object. Thus, a mechanism for both defining and reusing interfaces is provided, making standardized interfaces are possible. Over time within a project, an organization, or even a market, these interfaces allow component-based design. Because these interfaces can be attached to many different software objects, they provide a layer of abstraction between the external behavior of an object and its implementation.
The present invention also provides a technique for xe2x80x9cmappingxe2x80x9d the computing resources of a computing device throughout the hierarchy of a control system. Mapping is provided for modes, executable programs and threads of a processor.
Under mode mapping, the user is allowed to choose in a simple and intuitive manner which components of the control system will run in which mode. Each component may have a number of modes, each identified by a name. For a group of components (e.g. a control system for a robot arm), a mode may be defined for this whole group by picking and choosing desirable modes for the components contained within. Thus, for a given mode for the whole system, only selected components are xe2x80x9cactivexe2x80x9d and will run. This allows a user to choose at high level which code will be allowed to run for a given situation.
Using executable mapping, the user chooses on which processor components will run. Users may build multiple executable programs from a single system diagram. Multiple executables are desirable should the user wish to create one executable for the actual hardware real-time computer, and another executable for simulation on the user""s own computer. With executable mapping, the user can create an executable for each situation by choosing which components are to be run in which situation. In other words, an individual processor can be chosen on which to run each component simply by naming an executable for each component.
Within a given processor, each component of a control system may be assigned to individual execution threads within that processor simply by naming a thread. Each thread may be configured to execute at a different rate, thus providing different rates of executions for different components within one control system. Also a composite component such as a composite object group or a finite state machine may be assigned to multiple threads to accommodate the different needs of its constituent components. Each component in the hierarchy of a system diagram is assigned a logical rate that is eventually mapped to an actual rate of a thread. In this way, a component with its hierarchy of logical rates is reusable and may be inserted into a different real-time system that might have different threads and rates available. When used in this way, the logical rates of a component are simply mapped to whatever actual rates that are available (which may number greater or fewer than the logical rates); each lower-level component is thus assigned to an actual rate.
Thus, mechanisms for specifying and changing the modes of operation of a control system are provided, for assigning portions of the system to be embodied into different executable images, and for assigning portions of an executable image to be executed by different operating system threads of a processor. These mechanisms provide a named layer of abstraction between hierarchical levels, and thus allow each hierarchical level to be more self-contained. Prior art systems instead utilize xe2x80x9cifxe2x80x9d statements or control lines and switch blocks, and are thus more poorly structured. These three types of mapping, modes, executables and threads, may exist independently of one another, or may be combined with one another in a single control system.
USPTO Backgrounds
USPTO Backgrounds