Rapid Prototyping of Transition Management Code for Reconfigurable Control Systems M. Guler, S. Clements, N. Kejriwal, L. Wills, B. Heck, G. Vachtsevanos School of Electrical and Computer Engineering Georgia Institute of Technology, Atlanta, GA, USA
[email protected]
Abstract This paper presents a rapid prototyping technique that focuses on transition management in hybrid systems. In particular, it integrates hybrid modeling and simulation (for specifying and validating transition strategies) with a generic transition management pattern built on a RealTime CORBA-based platform for reconfigurable control systems. Code generation is performed from the hybrid models to transition management code. This allows hybrid systems and their reconfiguration strategies to be prototyped and validated at an early stage in development and for the strategies to be directly transferred into the control system software without a separate, manual reimplementation step. The application of this work is found in most complex control systems, including the control of unmanned aerial vehicle (UAVs) performing extreme maneuvers, which is our driving application area.
1
Introduction
A common strategy for control systems is to design a set of controllers for a given plant (i.e., the system to be controlled). The controller that is chosen to have authority at any given time depends on the current operating condition of the plant. For example, in a UAV application [19, 27], different controllers are used depending on whether the UAV is flying forward, hovering, or responding to a fault, such as a stuck actuator. The predefined controllers are usually modeled using differential or difference equations. The states corresponding to these controllers are continuous in nature. The higher level logic that determines which controller to use can be modeled using discrete states that evolve according to a finite state automaton. Such control systems that have both continuous and discrete states are commonly termed hybrid control systems. Transitions between the discrete states correspond to switching between the continuous controllers. Of particular
interest to the controls engineer is how to design these transitions. An abrupt transition (that is, a discrete switch) can excite high frequency dynamics in a system, which causes undesired responses and can stress the actuators. A number of transition management strategies are performed in practice but they are usually incorporated into the system on an ad hoc basis after the overall system has been designed rather than including transitioning management considerations in the early stages of design. In these dynamically reconfigurable systems, explicit evolvability and adaptibility of the reconfiguration logic and strategies themselves is needed, rather than building in one transitioning solution whose decision logic is buried in the implementation and cannot be changed easily. This paper presents a rapid prototyping technique for transition management that integrates hybrid modeling and simulation (using Ptolemy II [10, 11]) with code generation that targets generic architectural patterns for transition management [6]. These patterns are implemented on a middleware-based platform for reconfigurable control systems, called the Open Control Platform (OCP), which we are developing in collaboration with Boeing, Honeywell, and University of California at Berkeley [18, 26]. The paper first presents background on transition strategies typically used in hybrid control systems, the Open Control Platform, and generic support we have built on the OCP for transition management. It then describes our rapid prototyping approach, which uses Ptolemy II to express reconfiguration strategies, validates them through simulation, and ultimately generates OCP transition management code from Ptolemy hybrid models. We compare Ptolemy simulations of the models to the results of the actual OCP code and confirm that they produce the same behavior. We also discuss how this technique contrasts with popular commercial controls software tools and previous work in dynamic software reconfiguration and change management.
Proc. of the 13th IEEE Int. Workshop on Rapid Systems Prototyping (RSP), pp. 76-83, Darmstadt, Germany, July 2002.
2
Background
Our rapid prototyping approach builds on our previous research in identifying transition management strategies for hybrid systems and providing generic support for them in the OCP. This section gives background on this work.
2.1
Transition Strategies in Hybrid Systems
Control engineers have developed a number of strategies to try to alleviate perturbations to the system caused by switching controllers on the fly. One approach pursued by Oishi and Tomlin [14] creates a new discrete state for the transition, which incorporates the transition dynamics into it. This approach can create numerous extra “transition states” if the original hybrid system has many discrete states originally (consider all the combinations of discrete states and the corresponding transitions between them). Other approaches to handling transition dynamics are to find a means to smooth the transition between discrete states without deviating from the original set of discrete states. A common method of achieving this goal is to smooth the control action by blending the parameters of the controllers during the transition between them. A sophisticated example of a mode transition controller that is designed based on blending controllers is given in [20]. Another strategy for control smoothing is to initialize the new controller before it is switched on. For example, [23] identifies a state-preserving strategy that initializes the new controller states with the same values as those of the old controller before the switch. Further details and examples of transition management can be found in [4].
2.2
Open Control Platform
We are developing generic reconfiguration support for the common transition management strategies that have been identified in hybrid control systems. This is part of a larger effort to create an open control platform (OCP) [18, 26] based on object-oriented middleware and distributed object computing. The OCP aids the development of complex control systems by coordinating distributed interaction among control system components and supporting dynamic reconfiguration and customization of these components in real time. It is being applied to UAV control [19, 27]. The OCP consists of multiple layers of application programmer interfaces (APIs) as shown in Figure 1. At its lowest layer, the OCP utilizes Real-Time CORBA, [21, 22], to allow distributed components to communicate asynchronously in real time. The middle “reconfigurable controls” layer of the OCP provides basic abstractions for integrating and reconfiguring control system components. The abstract interface is based on familiar controls engineering concepts, such as block diagram components, input and output ports, and measurement and command signals. It
allows real-time properties to be specified that translate to quality-of-service constraints in the core real-time distribution substrate. Runtime changes can be made to these signal properties, which are handled by lower level dynamic scheduling and adaptive resource management mechanisms [1, 2]. The third “hybrid controls” layer of the OCP supports reconfiguration management by making reconfiguration strategies and rationale for reconfiguration decisions explicit, as is described next. Hybrid Controls API Reuse of generic patterns for hybrid control, configuration transition management
Reconfigurable Controls API Components, signals, QoS, runtime changes
Core OCP
Real-time distributed computing substrate with dynamic scheduling and adaptive resource management
Figure 1: Layers of Open Control Platform
2.3
Hybrid Controls API: Managing Transitions
The hybrid controls layer of the OCP captures common generic patterns of integration and reconfiguration that are typically found in hybrid control systems. A key pattern is the Transition Management (TM) pattern, which encapsulates the following as separate modular entities that can be specified and changed by the control system designer: 1. signal transition functions, which specify how to collate and/or blend signals during a gradual transition between controller configurations, 2. transition coordinator, which includes the reconfiguration decision logic and determines when signal transition functions should be applied (e.g., when to start and end blending of signals), and 3. rewiring strategies, which encapsulate correct ways of structurally rerouting component connections and which are derived from a predefined library, thus hiding structural reconfiguration details. (The user may also write a customized rewiring mechanism if desired.) To understand how the TM pattern works, consider a simple example in which two sensor components are being interchanged and their outputs need to be blended during the transition from one to the other. An aerial vehicle might use GPS to measure altitude at high altitudes, but it might use sonar at low altitudes where sonar is more effective. As the vehicle descends from a high to low altitude, it is not appropriate to abruptly stop using data from the GPS before starting to rely on the sonar altimeter. Rather, it is better to use a mixed GPS/sonar measurement during the transition. The blending of the GPS and sonar data is more accurate at the in-between altitude range. At these altitudes,
the onboard computer should be able to perform sensor fusion by blending these data together to come up with a logical measurement. The TM pattern can be used to coordinate how the sonar and GPS components are connected and disconnected to/from consumers of the altitude data and to control the application of blending functions to maintain a smooth output profile during the transition. We have developed support for discrete component switches, for collated-blending reconfigurations, and for transitions requiring component state initialization [4, 5]. Support for transient compensation transitions and transitions requiring warm-up periods are also being developed. The TM pattern is implemented as a set of abstract classes that are reused across different applications by userdefined specializations and methods for coordinating transitions and blending data. The Hybrid Controls API provides a high-level interface to the TM pattern that allows a controls engineer to define the signal transition/blending functions and the transition coordination logic as a finite state machine (FSM). The Hybrid Controls API is the target of our rapid prototyping technique.
3
Rapid Prototyping Approach
Our rapid prototyping approach, shown in Figure 2, uses Ptolemy II [10, 11] to express reconfiguration strategies and validate them through simulation. This allows reconfiguration management of hybrid control systems to be prototyped and validated early in the development process rather than patching transition management code into the system in an ad hoc fashion in later stages of development. We ultimately generate OCP transition management code from Ptolemy hybrid models using an XML-based code generation tool that maps Ptolemy models to the Hybrid Controls API. This allows reconfiguration strategies to be directly transferred into the control system software without a separate, manual reimplementation step. Thus, it establishes model continuity [7] from hybrid transitioning models to code that preserves the decision logic and reconfiguration strategies. This increases the likelihood that the hybrid system implementation will behave as expected and will avoid unwanted transients and instabilities.
3.1
Modeling Transition Strategies
Ptolemy II is a heterogeneous modeling and simulation environment developed by U.C. Berkeley for modeling systems that embody multiple models of computation (MoC), organized hierarchically. A hybrid system can be described using a Continuous-Time (CT) MoC that represents the low-level controllers, and a Finite-State-Machine MoC that represents the high-level discrete coordination logic governing the activation of the controllers.
Ptolemy Model
XML Format (Figure 4)
(Figure 3)
XML Parser XML-IR (Figures 5 and 6)
OCP Transition Management Code (Figure 7)
Code Generation
C++
Figure 2. Overview of Rapid Prototyping Process. An example of a hybrid controls system designed using Ptolemy II is shown in Figure 3. The upper left window in the Figure shows two controller components that will be switched in different configurations of the hybrid system and whose outputs will be blended during the reconfiguration transitions. The reconfiguration behavior is specified in the FSM diagram in the upper right. It models a composition of two transition strategies: • Signal blending - the outputs of two controllers are blended together by gradually ramping up the output of the first controller to that of the second one, and • State preserving - the integrators of the second controller are initialized to the final values of the first controller’s integrators. The fact that both controllers were structurally similar improved the system’s stability when the corresponding integrators transferred their values to one another during the transition phase. When this method is composed with signal blending, the system's stability improves even further. Each controller is specified in the CT domain as shown in the example in the lower left window. The lower right window shows a plot of simulation results generated by Ptolemy for this example. It shows the overall output as one controller is replaced by another and the control output is smoothed during the transition. Each of the finite states in the FSM diagram (upper right window in Figure 3) corresponds to a controller in the CT domain, a relationship which is called a “refinement,” and is explicitly shown in the configuration of each finite state. The transition arcs between the finite states specify when and how controller transitions will take place. The guard expression on each transition specifies the conditions which prompt the reconfiguration. The set actions specify actions to be taken during the transition, (e.g., the initialization of a controller). Usually the output of the FSM (and the output of the overall hybrid control system) is simply the output from one of the active low-level controllers. However, some transitions require the
Figure 3. Modeling the Signal Blending and State Preserving Transition Strategies in Ptolemy II.
Figure 4. Excerpt of Model Exported from Ptolemy II (in XML Format). outputs of several controllers to be blended together. This kind of signal blending can be specified in the output actions of certain finite states, which we call blending states. Such blending states must be designed to have multiple active controllers designated as refinements. (Extensions were made by the Ptolemy group to allow
multiple overlapping refinements of states, which made this possible.) The example shown in Figure 3 is a state preserving strategy composed with signal blending. Additional common strategies that we have modeled using Ptolemy II are the following:
•
Gain scheduling - the gains of controllers are scheduled to allow the controllers to be switched smoothly. • State zeroing - a controller is switched to another controller with completely different characteristics (instead of changing only a single parameter). During this transition, the integrators of the second controller, that are used in the continuous-time differential calculations, are initialized to zero.
3.2
Code Generation
Modeling transition strategies in Ptolemy II as part of the overall development of a hybrid system allows early validation of the system's behavior, including its ability to manage transitions gracefully. It is also possible to use the Ptolemy models as prototypes that are exported (in XML form as shown in Figure 4) and translated into transition management OCP code. This is done in our prototyping approach. In particular, the FSM models and output expressions on transitions map directly to the Transition Management pattern (transition coordinator and blending functions) in the Hybrid Controls API. These relationships have been encoded in an XML-based intermediate representation that allows Ptolemy II models to be translated directly into TM OCP source code. Figure 5. XML Data Type Definition for Transition Management Intermediate Representation.
For example, the FSM model of the State Preserving/Signal Blending transition strategy shown in Figure 3 is exported from Ptolemy as XML (see Figure 4). Our prototyping system then processes the XML-encoded model into an intermediate representation (IR) for the transition management pattern of the Hybrid Controls
API. It derives details about the blender functions (e.g., their signatures, data type information, and mathematical functions they apply) and the transition coordinator (e.g., states, guard conditions, and blender functions associated with transitions). The IR is also expressed in XML and its Data Type Definition is shown in Figure 5. An excerpt of the IR for the State Preserving/Signal Blending example is shown in Figure 6. C1_X1 double … true C1.y_ref=0.2;C1.Controller1.phi1=0.0;… FSM_ACTOR_BF_2 C1_X2>0.27 C2.y_ref=0.4; C2.x1=C1_X1; C2.x2=C1_X2; C2.Controller2.phi1=C1_PHI1; C2.Controller2.eta=C1_ETA; C1.y_ref=0.4; C1.x1=C1_X1; C1.x2=C1_X2; … … … Figure 6. Excerpt of IR for State Preserving/ Signal Blending Strategy.
This intermediate XML representation is translated directly, using Perl scripting, to OCP transition management code, as shown in Figure 7. This code preserves the coordination logic and blending strategies as modular entities in the code, making it easier to upgrade and adapt the code even though it is integrated with other aspects of a complex control system within the OCP.
3.3
Validation
The results of running our example with the transition management OCP code are shown in Figure 8 (solid curve). These closely match the simulation results predicted by Ptolemy II (see lower right screen in Figure 3). In contrast, to the smooth transitioning behavior shown in the solid curve, the dotted curve in Figure 8 shows the behavior of the hybrid system when transition management strategies are not inserted into the OCP code. That is, a discrete switch occurs between two controllers, which causes the output to overshoot and fluctuate and can lead to system instability.
Figure 7. Excerpt of Coordination Logic in OCP Transition Management Code.
Figure 8. OCP results using State Preserving/Signal Blending Transition (solid curve); and without Transition Management (dotted curve).
4
Related Work
Recently, a variety of commercial tools have appeared on the market for implementing real-time control systems,
including ControlShell/NDDS from Real-Time Innovations, Inc. [17], MATLAB/Simulink/StateflowTM from The MathWorks, Inc. [13], and ARCSware from Advanced Realtime Control Systems, Inc. [12]. Most support the development of control systems, making available repositories of prebuilt and preverified reusable components (such as common controllers and filters) for efficient construction of systems. The OCP complements this component-level reuse with reuse of generic reconfiguration strategies found in dynamically reconfigurable systems to support their evolution and online customization. We experimented with Simulink/Stateflow [13] to prototype and generate hybrid control systems software. These popular tools use block diagrams and FSMs to model hybrid systems. They share similarities with related MoCs in Ptolemy II. Both use FSMs to model discrete transitions, where the active state of the FSM enables (or refines) a specified block (or actor) in the model. However, the ability of the FSM chart to change parameters of other blocks is not inherently available using Simulink/Stateflow (as it is with Ptolemy II). This ability is vital in some transition management strategies, where the state of the newly active controller must be initialized based on the state of the previously active controller. Real Time Workshop, an add-on product to Simulink, generates code for deployment on processors or embedded systems. However, the code is monolithic and not meant for modification at the code level. In the context of our UAV application, it is critical that the generated code explicitly preserve the transition management strategies and decision logic in a modular, readable form, so that they can be modified or replaced after the code is deployed. These complex systems are composed of many components (newly created and legacy), some of which has been generated using other simulation and modeling platforms. It is important to integrate and reconfigure these in a way that makes transition management logic explicit. Transition management code by nature cannot be hidden in a monolithic, black box in systems into which it is integrated. Software architecture-oriented approaches have been proposed to manage runtime software evolution [3, 15, 16]. Oriezy et al. [15] refer to standard reconfiguration strategies as “change application policies,” which dictate how to make changes without violating reliability, safety, and consistency constraints. These policies are defined, but no automated support is developed to enforce them. Kramer and Magee [8, 9] performed seminal work on managing change in distributed software architectures. This work has been augmented by Taentzer, Goedicke, and Meyer [24, 25] who formalize change management using distributed graph transformations. These approaches typically assume either discrete switches, in which the switching time between one configuration and
another is not significant to the application, or they assume the components involved in the architectural change are in a quiescent state during the reconfiguration. Since the transition between configurations is often critical in hybrid systems, we avoid these assumptions and focus on the transition period explicitly.
5
Conclusions and Future Work
This paper presented a prototyping approach that generates transition management code for reconfigurable, distributed control systems from hybrid models of transition strategies. Using hybrid modeling to model transition management can iron out interactions between the behaviors of transition strategies in early stages of development, rather than discovering them and trying to resolve them in the implementation, testing, or later stages when it is more difficult and costly. Generating transition management code directly from the hybrid models provides model continuity, increasing the likelihood that the hybrid system implementation will behave as expected, thus avoiding unwanted transients and instabilities. There are a number of possible future directions. We plan to broaden the modeling of transition management beyond FSMs. We are making the OCP TM software more robust to broken transmissions and input time-outs and to be able to safely backout of transitions when interrupted. Finally, we will explore the use of additional front-ends to the TM software to increase the applicability and portability of the OCP's hybrid controls support. Acknowledgements We are grateful to Edward Lee, Jie Liu, and the members of the Ptolemy II group for their adaptations to Ptolemy which made it possible to model blending transitions. We would also like to acknowledge the contributions of Cameron Craddock, Suresh Kannan, Freeman Rufus, J.V.R. Prasad, and Daniel Schrage of Georgia Tech and Brian Mendel at Boeing. This work is supported under the DARPA Software Enabled Control (SEC) Program under contracts #33615-98-C-1341 and #33615-99C-1500. We have benefited greatly from the guidance of John Bay, Helen Gill (DARPA) and Bill Koenig (AFRL).
References [1] Cardei, M., Cardei, I., Jha, R., and Pavan, A., "Hierarchical feedback adaptation for real time sensor-based distributed applications," Proc. 3rd IEEE International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC 2000), pp.181 –188, 2000. [2] Doerr, B., Venturella, T., Jha, R., Gill, C., and Schmidt, D., "Adaptive scheduling for real-time, embedded information systems," Proc. 18th Digital Avionics Systems Conference, p.2.D.5/9, St. Louis, MO. Oct. 1999.
[3] Feiler, P. and Li, J., "Consistency in Dynamic Reconfiguration," in Proc. of 4th International Conference on Configurable Distributed Systems (ICCDS), Annapolis, MD, 1998. [4] Guler, M., Clements, S., Wills, L., Heck, B., and Vachtsevanos, G., “Generic Transition Management for Reconfigurable Hybrid Control Systems,” in Proc. of the 20th American Control Conference (ACC-2001), June 2001. [5] Guler, M., Wills, L., Clements, S., Heck, B., and Vachtsevanos, G., “Support for Dynamic Reconfiguration of Hybrid Systems for UAV Control,” in OOPSLA 2001 Workshop on Engineering Complex Object-Oriented Systems for Evolution, Oct. 2001. [6] Guler, M., Wills, L., Clements, S., Heck, B., and Vachtsevanos, G., “A Pattern for Gradual Transitioning during Dynamic Component Replacement in Extreme Performance UAV Hybrid Control Systems,” in OOPSLA 2001 Workshop on Patterns and Pattern Languages for ObjectOriented Distributed Real-time and Embedded Systems, Oct. 2001. [7] R. Janka, Specification and Design Methodology for RealTime Embedded Systems, Kluwer Academic Publishers, 2001. [8] Kramer, J. and Magee, J., "Analysing Dynamic Change in Software Architectures: A Case Study," Proc. 4th ICCDS, Annapolis, MD, IEEE Press, 1998. [9] Kramer, J. and Magee, J., "The Evolving Philosophers Problem: Dynamic Change Management," IEEE Trans. on Software Engineering, SE-16:11, pp. 1293-1306, 1990. [10] Liu, J., Liu, X., and Lee, E., "Modeling Distributed Hybrid Systems in Ptolemy II" in Proc. of 2001 American Control Conference, Arlington, VA, pp. 4984-4985, June 2001. [11] Liu, X., Liu, J., Eker, J., and Lee, E., "Heterogeneous Modeling and Design of Control Systems," to appear in Software-Enabled Control: Information Technology for Dynamical Systems, T. Samad and G. Balas (eds.), New York City: IEEE Press, 2002. [12] Advanced Realtime Control Systems, Inc. [Online], http://www.arcsinc.com. [13] The MathWorks: Real-Time Workshop [Online], Available: http://www.mathworks.com/products/rtw/. [14] Oishi, M. and Tomlin, C., “Switched Nonlinear Control of a VSTOL Aircraft,” Proc. 38th Conf. Decision and Control, Phoenix, Arizona, pp. 2685-2690, December 1999. [15] Oreizy, P., Medvidovic, N., and Taylor, R., “Architecturebased runtime software evolution,” Proceedings of the International Conference on Software Engineering (ICSE’98), pp. 117-186, 1998. [16] Oreizy, P., Gorlick, M., Taylor, R., Heimbigner, D., Johnson, G., Medvidovic, N., Quilici, A., Rosenblum, D. and Wolf, A., “An architecture-based approach to self-adaptive software,” IEEE Intelligent Systems, vol. 14, no. 3, pp. 5462, May/June 1999. [17] Pardo-Castellote, G. and Schneider, S., “The network data delivery service: Real-time data connectivity for distributed control applications,” Proc. 1994 IEEE International Conference on Robotics and Automation, Vol. 4, pp. 28702876, 1994. [18] Paunicka, J., Corman, D., and Mendel, B., "A CORBABased Middleware Solution for UAVs," ISORC, 2001.
[19] Rufus, F., Clements, S., Sander, S., Heck, B., Wills, L, and Vachtsevanos, G., “Software-Enabled Control Technologies for Autonomous Aerial Vehicles,” Proc. 18th Digital Avionics Systems Conference, pp. 6.A.5:1-8, St. Louis, Oct. 1999. [20] Rufus, F. and Vachtsevanos, G., "Design of mode-to-mode fuzzy controllers," International Journal of Intelligent Systems, Vol. 15, No. 7, pp. 657-685, 2000. [21] Schmidt D., Levine D., and Harrison T., “The Design and Performance of a Real-time CORBA Object Event Service,” Proc. of OOPSLA '97, Atlanta, GA, Oct., 1997. [22] D. Schmidt and F. Kuhns, “An overview of the Real-Time CORBA specification,” IEEE Computer, vol.33, no.6, pp.56-63, June 2000. [23] Simon, G., Kovacshazy, T., and Peceli, G., "Transient Management in Reconfigurable Systems," Proc. IWSAS 2000, P. Robertson, H. Shrobe, and R. Laddaga (eds.), Springer-Verlag, LNCS 1936, pp. 90-98, 2000. [24] Taentzer, G., Goedicke, M., Meyer, T., "Dynamic Change Management by Distributed Graph Transformation: Towards Configurable Distributed Systems, Proc. of TAGT, Paderborn, Germany, pp. 179-193, 1998. [25] Taentzer, G., Goedicke, M., Meyer, T., "Dynamic Accommodation of Change: Automated Architecture Configuration of Distributed Systems," Proc. of Automated Software Engineering (ASE99), Cocoa Beach, FL, pp. 287-290, Oct.1999. [26] Wills, L., Kannan, S., Sander, S., Guler, M., Heck, B., Prasad, J., Schrage, D., and Vachtsevanos, G., “An Open Software Infrastructure for Reconfigurable Control Systems,” IEEE Control Systems Magazine, pp. 49-64, June 2001. [27] Wills, L., Sander, S., Kannan, S., Kahn, A., Prasad, J.V.R., and Schrage, D., “An Open Control Platform for Reconfigurable, Distributed, Hierarchical Control Systems,” Proceedings of the 19th Digital Avionics Systems Conference, pp. 4.D.2-1 - 4.D.2-8, Philadelphia, PA, October, 2000.
