This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
hekate:heart_overview [2009/08/14 15:09] gjn created, esimon ver imported |
hekate:heart_overview [2019/06/27 15:49] (current) |
||
|---|---|---|---|
| Line 2: | Line 2: | ||
| ===== About HeaRT ===== | ===== About HeaRT ===== | ||
| - | {{:student:msc2009_xtteng:hekate.jpg|}} | + | {{hekate-design-simplified.jpg?600|HeKatE design simplified}} |
| HeaRT (HeKatE RunTime) is an inference engine created for HeKatE Project. It provides inference mechanism, model verification, model administration and integration. To start inference process, HMR file must be created. It can be write by user in any text editor or can be generate as an output from HQEd visual editor. Result of inference process, verification or model administration can be shown to user by Prolog console message, callback mechanism or TCP/IP protocol. For more information about HMR files, inference and communication with HeaRT read | HeaRT (HeKatE RunTime) is an inference engine created for HeKatE Project. It provides inference mechanism, model verification, model administration and integration. To start inference process, HMR file must be created. It can be write by user in any text editor or can be generate as an output from HQEd visual editor. Result of inference process, verification or model administration can be shown to user by Prolog console message, callback mechanism or TCP/IP protocol. For more information about HMR files, inference and communication with HeaRT read | ||
| - | [[student:msc2009_xtteng:heart-howto | HeaRT HowTo documentation]]. | + | [[HeaRT HowTo]]. |
| ===== HeaRT Features ===== | ===== HeaRT Features ===== | ||
| Line 43: | Line 43: | ||
| ===== HeaRT Architecture ===== | ===== HeaRT Architecture ===== | ||
| - | {{:student:msc2009_xtteng:arch-en.jpg|}} | + | {{heart-arch-en.jpg?400|HeaRT Architecture}} |
| Line 84: | Line 83: | ||
| * //out// - this type of callback is used to present attribute value to user. | * //out// - this type of callback is used to present attribute value to user. | ||
| - | Callback can be use to create GUI with JPL and SWING library in Java. To make that process easier you can download JHNormal interface with example. This can be done in [[student:msc2009_xtteng:heart-howto | HeaRT HowTo documentation]]. | + | Callback can be use to create GUI with JPL and SWING library in Java. To make that process easier you can download JHNormal interface with example. This can be done in [[HeaRT HowTo]] documentation. |
| <code> | <code> | ||
| Line 110: | Line 109: | ||
| - **[model, verify, +{vcomplete | vcontradict | vsubsume | vreduce}, +modelname, +username, +schema].** - runs verification process in one of four modes, complete, contradict, subsume and reduce | - **[model, verify, +{vcomplete | vcontradict | vsubsume | vreduce}, +modelname, +username, +schema].** - runs verification process in one of four modes, complete, contradict, subsume and reduce | ||
| - | Character **+** means, that this parameter is obligatory. Format like this **+{ddi | gdi | tdi | foi}** means, that you must specify one of these parameters. For more information about protocol commands, examples and return values format please read [[student:msc2009_xtteng:heart-howto | HeaRT HowTo documentation]]. | + | Character **+** means, that this parameter is obligatory. Format like this **+{ddi | gdi | tdi | foi}** means, that you must specify one of these parameters. For more information about protocol commands, examples and return values format please read [[HeaRT HowTo]] documentation. |
| To make HeaRT integration easier, you can download one of three integration libraries, JHeroic, PHeroic or YHeroic. | To make HeaRT integration easier, you can download one of three integration libraries, JHeroic, PHeroic or YHeroic. | ||
| Line 171: | Line 170: | ||
| </code> | </code> | ||
| - | To download or check examples of using these libraries check [[student:msc2009_xtteng:heart-howto | HeaRT HowTo documentation]]. | + | To download or check examples of using these libraries check [[HeaRT HowTo]]. |
| + | ===== Automatic Tests ===== | ||
| + | A simple mechanism for testing HeaRT was implemented. It is a bash script called //test.sh// located in //tests// directory. (It can be downloaded also from here: {{:hekate:test.txt|test.sh}}) The script takes as a parameter a name of the file with testing data, and produces information about errors on the screen. More detailed information are stored in //log.txt// file automatically created by the script. | ||
| + | |||
| + | Example use of the script looks as follow:<code>./test.sh thermostat_test.pl</code> | ||
| + | Example output with no errors:<code>Testing thermostat_test.pl | ||
| + | 0 | ||
| + | OK | ||
| + | </code> | ||
| + | |||
| + | Example output with errors:<code>Testting thermostat_test.pl | ||
| + | 1 | ||
| + | There was errors! | ||
| + | ERROR: Produced state is different that expected, for states init4 and eval4 | ||
| + | ERROR: Produced: [[day, wed], [hour, 3], [month, 7], [today, workday], [season, summer], [operation, nbizhrs], [thermostat_settings, 27]] | ||
| + | ERROR: Expected: [[day, mon], [hour, 3], [month, 7], [season, summer], [operation, nbizhrs], [today, workday], [thermostat_settings, 27]] | ||
| + | </code> | ||
| + | |||
| + | |||
| + | The log file contains the full trajectory of the system (see {{:hekate:log.txt|example logfile}}). | ||
| + | |||
| + | ==== How to create a test file === | ||
| + | - A test file is a HMR file prepared for testing script. | ||
| + | - A HMR file that should be a test file has to have two following lines at the begining of the file:<code>:- ensure_loaded('../heart.pl'). | ||
| + | :- ensure_loaded('test-predicates.pl').</code> The test-predicates file can be downloaded from here: {{:hekate:test-predicates.pl|}} | ||
| + | - Special sets of states have to be added to the file. The state that is an input file have to be called **initX**, where X is some number. The state that describes the expected output should be called **evalX**, where X is a number that binds **init** state with **eval** state. Example of the testing states are shown below: | ||
| + | <code> | ||
| + | xstat init2: [day, 1]. | ||
| + | xstat init2: [hour, 12]. | ||
| + | xstat init2: [month, 4]. | ||
| + | |||
| + | xstat eval2: [day, 1]. | ||
| + | xstat eval2: [hour, 12]. | ||
| + | xstat eval2: [month, 4]. | ||
| + | xstat eval2: [season, spring]. | ||
| + | xstat eval2: [operation, bizhrs]. | ||
| + | xstat eval2: [today,workday]. | ||
| + | xstat eval2: [thermostat_settings, 20]. | ||
| + | </code> It means that for the input state init2, we expect output state eval2. | ||
