MONTHLY PROGRESS REPORT CONTRACTOR: University of California at Berkeley TITLE: Open Control Platform REPORT PERIOD: 10/15/00 - 11/15/00 SPONSOR: Boeing Subcontract, Air Force Research Laboratory (AFRL) REPORT PREPARED BY: Sonia R. Sachs 1. Research Status Sonia Sachs, Alvin AuYong and Mark Feng, implemented and demonstrated a combination of TAO and Orbacus Event Service examples: - Event Channel in TAO - Suppliers and Consumers in TAO - Suppliers and Consumers in ORBacus The goal of this work was to test the compatibility of the C++-based ORB (TAO) and the Java-based ORB (Orbacus). In particular, we investigated hybrid Pull/Push and Push/Pull, as illustrated below: Hybrid Pull/Push Model ---------------------- ------------ ***************** ------------ : Consumer : <-- push --- * Event Channel * --- pull --> : Supplier : ------------ ***************** ------------ - Event channels pull events from suppliers and push them onto consumers; plays the role of "intelligent agent". - The Suppliers and Consumers are passive in this model. Hybrid Push/Pull Model ---------------------- ------------ ***************** ------------ : Consumer : --- pull --> * Event Channel * <-- push --- : Supplier : ------------ ***************** ------------ - Suppliers push events to the event channel. - Consumers pull events from the event channel. - Event channel plays the role of queue. (passive). Unfortunately, we observed incompatibilities between the two ORBs. For example, we found out that termination of events from a TAO supplier to an ORBacus (Pull) consumer is delayed by a few seconds. The team also looked into the Java-based ORB Zen, from U.C. Irvine. Although Zen is being designed with the same features as TAO, particularly real-time, the code is not available at this time. We looked into OCP and Ptolemy II interoperation alternatives. One approach is to write a Java-based Event Service Utilities that wrap Java-based Event Channel operations, offering the same API as the OCP C++-based wrapper. We considered writing an IDL description of the C++ code, then using an ORB IDL compiler to generate the Java code. This approach would gives us reusable code for when we migrate to Zen (whenever it becomes available). Using the same IDL, we can use their IDL-Java compiler to generate the Java wrapper's stubs and skeletons, reusing some of the code from this step to implement them. This approach allows Ptolemy actors to send/receive tokens to/from receivers that in turn use the Event Service Utilities to transform tokens into OCP Event Channel events and transfer them via the ORBACUS Event Channel. Before pursuing this approach, however, we decided to first convince ourselves that a Java-based Event Service Utilities was needed. We starting our investigation by looking one layer above, namely the OCP controls API. The conclusions of this study, led by Prof. Lee, is that the current approach for the controls API is to use Simulink as a block diagram editor. Neither the Simulink components nor the Simulink semantics for component interaction are involved. Instead, the MDL files are used to generate C++ template files, which must then be filled in with functional code. The data types that are carried on the interconnections, the component types, and execution information, such as rates, execution times, and execution modes are added by the users by using a Simulink to OCP tool. Prof. Lee suggested to Boeing that the OCP component interaction semantics needs to be clarified, particularly since it is not Simulink semantics. The concern is that it can be very confusing to controls people to think that they are working with Simulink semantics, and then discover that the model of time is different, the synchronization is different, and they their legacy models don't work under OCP. Prof. Lee discussed with Boeing the use of Ptolemy as one of the "controls API" for the OCP. That is, models are constructed and simulated in Ptolemy, using a domain that approximates the OCP semantics. A code generation phase then produces the C++ code for the OCP platform, so that existing and future Ptolemy components can be used within OCP. He also discussed with Boeing the use a MoML syntax rather than MDL for exchanging data between tools. MoML is a XML language developed in the context of PtolemyII. XML has the advantage of being non-proprietary, public-domain parsers are readily available, and the Vergil schematic editor can be used to create visual representations. Another productive result of discussions was the proposal of a domain in Ptolemy II with OCP publish/subscribe semantics. Christoph Kirsch has started work on a formally defined virtual machine model for embedded code generation. The so-called embedded machine is a virtual machine in the spirit of the Java virtual machine with specific extensions for embedded real-time computing on distributed platforms. The embedded machine provides an abstract platform for generating distributed code from high-level embedded programming languages. Meetings ======== Visit by OGI (Richard Kieburtz, and Magnus Carlsson), on Nov 15. We presented hybrid and mixed signal modeling within Ptolemy II, and discussed code generation. OGI presented their simulation work on OCP.