XEVENT-HANDLER

NAME

xevent-handler - A Generic Event Handler for Small Linux Devices

SYNOPSIS

xevent is a light weight automation framework implemented in C++. It consists of a generic part that organizes the event handling and a domain specific part that does the work.

DESCRIPTION

Many technical tasks require an asynchronous handling of events. These events origin from timers, interrupts, or external input. They initiate a work flow. Some calls within this work-flow might be also synchronous, such as fetching a measurement value.

xevent is a light weight automation framework implemented in C++. Task specific code is simply added by additional shared libraries. A xevent process is started for each shared library as defined in the configuration file.

The configuration file defines the following items:

- The workflow with the participating object classes

- xevent processes with the corresponding shared libraries

- The distribution of the object classes to the shared libraries / event handler processes

- Timers and interrupts

The workflow has to be built from standard event types: GET,SET,CREATE,DELETE,TRIGGER,RESPONSE. The RESPONSE event is used for the responses of synchronous calls. Participating object classes have to implement the events that are used with this class.

The generic part provides the following object classes:
Data Provider

is used for data calibration. Measurement values can be mapped with a calibration curve. See header file DataProvider.h

SystemCall

performs calls to the operating system.

An application has to define a logic tree in its configuration file, that is built by fuzzy operations (e.g. NOT, AND, OR ) and comparator leaves. Fuzzy logic allows to implement expressions from natural speech like âin the nightâ: This may be defined by:

- âcompletely in the nightâ: 11 pm to 5 am, resulting in a 100% value

- ânot in the nightâ: 9 am to 5 pm, resultingin a 0% value

- The time in between results in percentages by linear interpolation.

Typical use of this software are all kinds of steering tasks like operating cooling and heating, where it is already in use, or steering tasks in a production environment.

A user library has to be linked into a file called HandledObject.so, that has to be in the shared library path of that event handler instance, that is intended to handle the therein implemented objects. Every user library has to provide a class HandlerFactory.cpp. Therein the factory methods for the implemented user classes have to be provided. See HandlerFactory.h. Indide a user library the configuration can be accessed via the ConfigFile class. The configuration file name is accessed via EDCommon. See ConfigFile.h EDCommon.h

For details see the EXAMPLE section.

FILES

The whole system is configured by the configuration file, typically /etc/xevent-handler.conf.

EXAMPLE

xevent provides some generic classes, that can be used as scetch for your application.

DataProvider

DataProvider instances are indentified by the instance numbers, starting with 1. In the configuration file there is a special DataProvider section, that assigns a calibration file name and the validity time to each DataProvider instance. This calibration file consists of lines of integer/float pairs, seperated by semicolon (100;23.4). The validity time defines how long (in seconds) the last value is returned in a GET. If the time is over, GET returns return value 1, which should result in a synchronous GET to the instance providing the raw measurement value.

RESPONSE inputs the new integer measurement value for calibration.

Return Values

0, if the GET is withing the validity time, 1 otherwise.

A typical event flow can be seen in the repository file Test/etc/nestedsync.conf.

Logger

Logger writes messages to log file.

Return Values

0

A typical event flow can be seen in the repository file Test/etc/attribute.conf.

SEE ALSO

xevent.conf(5)

configuration file format

mbuild(7)

build service

Installation hints
header files

ConfigFile.h DataProvider.h EDCommon.h HandlerFactory.h