SDO - simple distributed objects

S9 ~ # python2 /usr/share/sdo/server.py --help
usage: server.py [-h] [-c CONFIG] [-v] [-l LOGGER] [-u USER] [-g GROUP] [-d]
                 [-q] [-s]

SDO (Simple Distributed Objects) service

optional arguments:
  -h, --help            show this help message and exit
  -c CONFIG, --config CONFIG
                        configuration file if not given it tries to find files
                        in this order: ~/.sdo.conf ./local.conf /etc/sdo.conf
                        ./default.conf
  -v, --version         show program's version number and exit
  -l LOGGER, --logger LOGGER
                        use a specific logger (has to be configured in config)
  -u USER, --user USER  setuid to user
  -g GROUP, --group GROUP
                        setgid to group
  -d, --dump-config     test and dump config
  -q, --quiet           change logging verbosity and only print errors
  -s, --dump-serial     print systems serial

In short, SDO provides you abstracted and cached access to different busses and objects.

The initial idea was to create some kind of a caching service which on one side polls a slow object provider (like let's say a slow device on a serial bus), stores the relevant data and provides fast and abstract access for a more complex system.

At the beginning such a service became necessary for a combination of ModBus-RTU and PHP.

There had to be a service which handles incoming ModBus-RTU-Master requests and provides an interface for a PHP based visualization. The ModBus-queries simply contained information about registers and their values. These requests came in periodically and had to be parsed and acknowledged all the time thus making it necessary to run a service permanently. With PHP this wouldn't be possible since every request on the web-server would create a new PHP process (at least for normal CGI setups). Another point is, that PHP's strengths are in the field of XML, JSON and other ASCII based data. Using it for binary data is possible also but wouldn't make much sense at this point. For this case the SDO had a ModBus-RTU/Slave- „driver“ and a JSON/TCP- „interface“ running. The PHP process is able to read/write from the SDO's cache at any time.

With the latest development efforts, SDO got a HTTP interface which can server webpages, binary files like images, JSON RPC and Websockets. These features provide the base for rich HTML5 web applications.

The current implementation, so called „pySDO“ is written mostly in python. It uses a lot of threading and was aimed to implement new „drivers“ and „interfaces“ as fast as possible.

One type of the SDO's structure are so called „drivers“. A „driver“ runs as a single thread and handles all access to lower protocols. Generally it provides access to a bus / field-bus. Such an access can be synchronous or asynchronous. A driver can access other drivers and can also generate events.

A driver can have multiple instances like for example on devices where you'd have two ModBus-interfaces there can be two instances of the driver „modbus“, one for each interface.

Similar to a driver who provides access to an lower bus, an interface gives access to the drivers objects. There can be any number of currently running interfaces and each interface can also have multiple instances. It's for example possible to run JSON/TCP at TCP/port 80 and also a second instance at port 81.

Every interface runns in it's own thread. Sometimes one interface instance can also create multiple other threads, which is the case for some TCP based interfaces where every connection would have it's own thread.

Controllers are relatively new. Imagine them as little programs or scripts which access the drivers on their own.

They can also provide objects for the interfaces, can run in multiple instances and have their own threads.

This class is somehow like a controller but it's main purpose is to create virtual objects out of real ones which do exist on a driver.

Typically a driver only provides access to the bus, thus resulting in a group of registers and values.

Sometimes two registers would result in a single object or sometimes there has to be some calculation to actually get a user-friendly representation of an object.

Imagine a temperature, given by a float type represented via 4 bytes which would be something like 0x41c8.0000 = 25.

The idea is to implement a common layer for storing values so that after a restart of SDO a driver/controller can continue it's process or maybe save some state information.

This is partly implemented but depends on the specific driver, interface or controller.

Starting with the new „cherrypy“- interface we have so called „views“. A view presents objects (from driver/interface/controller/abstract) to the user. It is language independent and also can have different output types. At the moment a view is just some HTML-code which is rendered via the Mako-Template-Engine. Since it's HTML it is only used by the cherrypy interface.

A typical use case for a view is the representation of an abstract. The abstract has different properties and the view shows these to the user like for example via an HTML-table.

• Configuration