1.0 ABSTRACT
This paper describes experiences using Python during the development of a distributed object system. Python has been used in various areas, such as testing, tool building, and prototyping. ...2.0 INTRODUCTION
The ABB Object Management Facility (OMF) is a distributed object system specifically designed for the process control industry. The object model is similar to other distributed object systems, such as OMG's CORBA and Xerox's ILU. What makes OMF different from these is its interaction model. While the common interaction model is
OMF is implemented in C++, with APIs also for C, Smalltalk, Python and Java (real soon now :-). The primary reason for the Python API was originally for writing test programs, but has since been used to write various tools to aid in application development and run-time management.
More...
On top of this API we wrote a few utility classes such as the OMFagent, where we got a glimpse of the power of Python. The agent lets the user treat OMF objects as local Python objects with attributes and methods.
from OMFagent import Agent # Connect to an object in the network ai = Agent(`AI1.1') # Get the Analog Input's value # This will actually result in an RPC value = ai.VALUEThe Agent code is surprisingly small, but results in a drastically higher abstraction layer than the bare OMF API. The main reason why this is a rather simple class is Python's dynamic typing.
4.0 TOOLS
The tools we have written in Python can roughly be divided into
The vpApp framework contains a set of classes called Datum. Datum instances can be linked together so that updates at one end are propagated to the other(s). There are Datum classes that perform operations on inputs before propagating them as well.
-------
3->|Datum|----
------- | -------
|----| Add | -> 8
------- | -------
5->|Datum|----
-------
The figure illustrates the use of two datum instances connected with an Add datum. The Add value is automatically recomputed as soon as one of its input datums gets a new value.One of the tools we have is a type browser, with which you can browse all available object types (=interfaces) in OMF. The browser is composed by an object type list, a list of subtypes, and a list of attributes/operations/events. All these parts communicate via Datums, which means each of these can also be used in some other context. The tool basically just connects the parts' datums to each other in the appropriate way to make them interact. A powerful and simple solution for writing reusable pieces of code.
OMF is currently used in many installations, such as oil rigs and passenger ships (better word?) cruising the Caribbean. To make it convenient to run these tools from our office in the cold north of Sweden instead of having to spend two weeks in the warmth of the Caribbean Sea, we are thinking of making the Python tools runnable remotely via the Grail browser.
When the tools run on the target node, they use the OMF API to perform their tasks. When run remotely in Grail, the OMF API is not available, so instead we use the RemoteCall package (RPC in Python) to gain access to the OMF API. RemoteCall will, once set up, let the tools use the OMF API more or less in a transparent way.
Describe RemoteCall in more detail?
Python has proved to be a simple language to learn, with a useful set of builtin types (lists, dictionaries), and easy to extend with new types. The metainformation and hooks available makes it fairly easy to build debuggers, profilers, RPC packages, etc, comletely in Python (great!). And a lot of people produce useful extensions. Thanks!