EPSIAE » eneraptor

h1. The logic

{{toc}}

h2. Basic concept

System Eneratptor is designed to take predefined actions in response to events in the surrounding world. The logic system is designed to be easily calibrated and managed. In addition to its predefined logic it allows the human administrator (through HMI) to reverse any automated or scripted decision and to execute any of the predefined actions, thus allowing the operator to tweak the system according to her best judgement.

!Logika.jpg!

The logic of the system consists of the following concepts:

* Device maneger

* Mailbox

* Decision making software

* Predefined action list

* Action

* [[Human Machine Interface]]

The basic idea behind this design is modularity. Eneraptor supports any device and can execute any action as long as the driver follows our standard. In this scenario we [the eneraptor designers] expect the device manufacturer (ie air conditioning unit) at least two supply two _programs_ : the device manager and the action program. If there are several actions supported by the device, we expect each to be a standalone program or all actions to be in a single program targeted by different command line arguments.

h2. Concepts described in detail

h3. Device manager

Device manager is basically a program. The eneratptor system doesn't know anything about it, the only crucial part is the driver-mailbox communication through witch data is supplied. More about date in the _message specification_. The device manager has to know how to reach the mailbox and how to correctly format the message. The device manager does not receive any confirmation from the message recipient.

This driver is not necessarily the same software which is supplied by the manufacturer, it is only a program that communicates with the eneratpr Mailbox.

h3. Mailbox

Mailbox is a bridge between the device managers and the decision making software. It is a buffer of messages that the decision making software can read at its own pace.

The design of the mailbox and message structure is still open to debate; all input is welcome!

h3. Decision making software

Decision making software is the key mechanism of the eneraptor project. It brings all other components together to ensure all conditions set by (human) operators are met.

The decision making software continuously checks the mailbox for new messages. If any new info is read the software compares it with all the predefined conditions (see _predefined action list_). If a condition is met, the action is executed. If several conditions are met, all co-responding actions are executed.

This (very elegant) main loop is always executing, however it can be halted by the [[Human Machine Interface]]. When this happens the loop still executes, however all but the messages originating from HMI are ignored.

h3. Predefined action list

Predefined action list is a list of all the conditions and co-responding actions entered to the system. It is implemented as a non-ordered list of structures containing the information: 

# Input device ID

# Corner value

# Comparison operator

# Action to be executed

The list is saved in a csv/xml file. It is initialized with on the Decision Making Software program startup and then periodically refreshed, insuring no restart is required when additional rules are entered.

h3. Action

Action is a program path and program argument pair, thus allowing the _Decision making software_ to execute it.

There are several rules for the Action developers:

* The Action program must be executable through command line,

* The Action program must *not* expect human interaction,

* The Action program must terminate in a deterministic time,

Outside of this very general rules the Action developers have no limitations in writing the Action programs.

h2. Communication and message formats

The logic component uses three types of messages to connect to other parts of the Eneraptor system. They are the following:

* The message for communication with device manager -> XML

* The message for communication with HMI -> XML

* The message for logging (via syslog) -> formatted plain text

These messages are then transported over the network to their destination.

* The Logic <--> device manager communication uses *named pipes* to relay messages.

* The Logic <--> HMI communication uses *UDP* communication to relay messages.

* The Logic <--> Logging service uses syslog's built in mechanism for relaying the messages to their destination.

h3. The logic <--> device manager message

h3. The logic <--> HMI message

h3. The logic -> logging

h2. Configuration