The driver also has a control that increases or decreases the set point by a set amount. This, too, can be invoked at any time define arithmetic on undefined values to yield undefined values. Figure 9 summarizes the events involved in determining the set point. Note that this process requires access to the clock in order to estimate the current speed based on the pulses from the wheel. Although there is no need for the control unit and set point determination to use the same clock, we do so to minimize changes to the original problem statement.
Then, since current speed is used in two components, it would be reasonable for the next elaboration of the design to encapsulate that model in a reusable object; this would encapsulate the clock. All of the objects in Booch's design Figure 6 have clear roles in the resulting system. It is entirely reasonable to look forward to a design strategy in which the control loop architecture is used for the system as a whole and a number of other architectures, including objects and state machines, are used in the elaborations of the elements of the control loop architecture.
The shift from an object-oriented view to a control view of the cruise control architecture raised a number of design questions that had previously been slighted: The separation of process from control concerns led to explicit choice of the control discipline.
The limitations of the control model also became clear, including possible inaccuracies in the current speed model and incomplete control at high speed. The dataflow character of the model showed irregularities in the way the input was specified, for example mixture of state and event inputs and the inappropriateness of absolute position of the accelerator. Analysis and Discussion 3. Correspondence between architecture and problem The selection of an architecture commits the designer to a particular view of a problem.
Like any abstraction, this emphasizes some aspects of the problem and suppresses others. Booch [Booch 86] characterizes the views inherent in object-oriented and functional architectures: Simply stated, object-oriented development is an approach to software design in which the decomposition of a system is based upon the concept of an object. An object is an entity whose behavior is characterized by the actions that it suffers and that it requires of other objects. Object-oriented development i s fundamentally different from traditional functional methods, for which the primary criteria for decomposition is that each module in the system represents a major step in the overall process.
The issue, of course, is deciding which abstractions are most useful for any particular problem. We have argued that the control view is particularly appropriate for a certain class of problems. The idea of using software for control is not new; scheduling algorithms and real-time operating systems are an established area.
However, the control character of the task is rarely obvious from the system architecture. The Chimera framework for sensor-based control systems [Stewart et al 92, Setwart et al 93] provides reusable, reconfigurable building blocks for control that interact via data flow, but that framework does not make the explicit separation between the controller and the process that we make here.
The ARPA domain-specific software community is exploring canonical architectures for particular problem domains [Tracz 93]. Early results from this work include software architectures that quite appropriately include contain control loops. A future task is consideration of those designs in light of this formulation of the control loop idiom. Contrast these cases with Booch's second example, the sea buoy. This requires continuing operations and state changes in response to external commands.
However, it does not have to compensate for external perturbations and so is not a candidate for a control loop organization. Language support At some level the architecture of a system is independent of the programming language. However, architectures assume certain kinds of interactions among components, and these interactions often induce assumptions about the way the components are packaged -- that is, about some aspects of their interfaces.
Unfortunately, programming language do not provide comparable levels of direct support to all architectural idioms. Some architectures, most notably procedures, objects, and processes, have motivated features in programming languages intended to support the structural needs of the architectures. Others, however are orphans Booch remarks on the effect languages have on architectural design, simply because of the kinds of building blocks they present.
Thus, these languages are best suited to functional decomposition techniques, which concentrate upon the algorithmic abstractions. Subroutines, while well suited to the description of abstract events operations , are not particularly well suited to the description of abstract objects.
In order to achieve data flow, you have to want to achieve data flow. For example, unix pipe and filter architectures assume communication via pipes. The individual modules achieve this with conventions about how read and write procedures are used.
Methodological implications Object-oriented architectures are supported by associated methodologies. What can we say about methodologies for control-loop organizations and when they are useful? First, a methodology should help the designer decide when the architecture is appropriate. This is discussed in Sections 1. Second, a methodology should help the designer identify the elements of the design and their interactions. Such a list is established in Section 1.
Third, a methodology should help the designer identify critical design decisions. In the case of control, these include potential safety problems as discussed in sections 2. Each identifies a typical control situation and gives advice for suitable strategies. In addition, Section 2. This corresponds directly to the design. Performance: system response to control Process control provides powerful tools for selecting and analyzing the response characteristics of systems.
This is more appropriate for thermostats than throttles, but it could be considered. The gain of a cruise controller is the amount by which the speed deviation is multiplied to determine the change in throttle setting. This is a parameter of control. Depending on the properties of the engine, this can lead to a steady-state value not quite equal to the set point or to oscillation of the speed about the set point.
This has the effect of forcing the error to zero. Adding a further correction based on the derivative of the error speeds up the response but is probably overkill for the cruise control application. For each of these alternatives, mathematical models of the system responses are well understood.
Correctness When software controls a physical system, correctness and safety become particularly acute concerns. Sections 2. For cruise control, the possibility of runaway feedback is a significant safety concern, as the author's cruise control once vividly demonstrated. Summary Design methodologies get much of their power from focusing attention on significant decisions at appropriate times. They generally do this by decomposing the problem in such a way that development of the software structure proceeds hand-in-hand with the analysis for significant decisions.
This localizes decisions and limits the ripples caused by changes. In this example we have explored an example in which the significant high-level decisions are better elicited by a methodology based on process control than on the more common object-oriented methodology. Software architecture studies the ways software components are organized into systems, the reasons for selecting one architecture over another, and the analysis of the systems that result. Section 1. The control paradigm separates the operation of the main process from compensation for external disturbances.
This separation of concerns yields appropriate abstractions and leads to design questions that might otherwise be neglected. Cruise control exemplifies a class of software system design problems in which a real-time process is controlled by embedded software.
Conceptually such processes update the control status continuously. This leads to early consideration of performance and correctness questions that might not otherwise arise. Acknowledgments More than is usual, a clear sequence of events led to this paper. Along the way I had the opportunity to learn about control software from colleagues at Fisher Controls. Will Tracz presented an architecture for avionics whose essential core was essentially a feedback loop.
Department of Defense and by a grant from Siemens Corporate Research. The views and conclusions contained in this document are those of the author and should not be interpreted as representing the official policies of the U. Computer-Controlled Systems. Prentice- Hall Object-Oriented Development. IEEE Trans. Although several architectural idioms have strong advocates, no single paradigm dominates.
The choice of an architecture should instead depend on the computational character of the application. Documents: Advanced Search Include Citations. Authors: Advanced Search Include Citations.
Abstract A standard demonstration problem in object-oriented programming is the design of an automobile cruise control. The control view leads us to an architecture that is dominated by analysis of a classical feedback loop rather than by the identification of discrete stateful components to treat as objects.
The change in architectural model calls attention to important questions about the cruise control task that aren't addressed in an object-oriented design. Software Engineering Institute.
0コメント