The logic » History » Version 8
David Božjak, 14.12.2010 20:53
1 | 1 | Aleksander Bešir | h1. The logic |
---|---|---|---|
2 | |||
3 | 2 | Aleksander Bešir | {{toc}} |
4 | |||
5 | 1 | Aleksander Bešir | h2. Basic concept |
6 | 3 | David Božjak | |
7 | 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. |
||
8 | |||
9 | !Logika.jpg! |
||
10 | |||
11 | The logic of the system consists of the following concepts: |
||
12 | 4 | David Božjak | * Device driver |
13 | * Mailbox |
||
14 | * Decision making software |
||
15 | * Predefined action list |
||
16 | * Action |
||
17 | 7 | Aleksander Bešir | * [[Human Machine Interface]] |
18 | 1 | Aleksander Bešir | |
19 | 8 | David Božjak | 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 driver 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. |
20 | 6 | David Božjak | |
21 | 3 | David Božjak | h2. Concepts described in detail |
22 | 1 | Aleksander Bešir | |
23 | 3 | David Božjak | h3. Device driver |
24 | 4 | David Božjak | |
25 | 6 | David Božjak | Device driver 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 driver has to know how to reach the mailbox and how to correctly format the message. The device driver does not receive any confirmation from the message recipient. |
26 | |||
27 | 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. |
||
28 | |||
29 | 3 | David Božjak | h3. Mailbox |
30 | 6 | David Božjak | |
31 | Mailbox is a bridge between the device drivers and the decision making software. It is a buffer of messages that the decision making software can read at its own pace. |
||
32 | 1 | Aleksander Bešir | |
33 | 8 | David Božjak | The design of the mailbox and message structure is still open to debate; all input is welcome! |
34 | |||
35 | 3 | David Božjak | h3. Decision making software |
36 | 1 | Aleksander Bešir | |
37 | 8 | David Božjak | 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. |
38 | |||
39 | 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. |
||
40 | |||
41 | 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. |
||
42 | |||
43 | 1 | Aleksander Bešir | h3. Predefined action list |
44 | 8 | David Božjak | |
45 | 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: |
||
46 | *Input device ID |
||
47 | *Corner value |
||
48 | *Comparison operator |
||
49 | *Action to be executed |
||
50 | 4 | David Božjak | |
51 | 3 | David Božjak | h3. Action |