Rules Engine: Best fit for an embedded system

Question

I have been doing some research on the rules engines that would be more appropriate run on a embedded system. The system will collect information from sensors and according to that information, make specific C/C++ calls. An example would be:

IF RainSensor.value > RainSensor.threshold 
THEN call( GarageWindow::close())

Being GarageWindow a C++ class, living in the binary that links to the Rules Engine library.

I cannot make assumptions on the capabilities of said embedded system. The requirements for it are:

• Minimum footprint.
• Portable
• Able to make function calls (make C/C++ calls from its RHS).
• Should accept new rules at runtime.

I would need to give alternatives according to its capabilities (to be defined in the future), the assumptions are:

1) The embedded system supports nothing(no JVM, no python, etc):

CLIPS as C library or clipsmm as C++ library. Both usable in commercial applications (GPL for clipsmm).

Advantages: Open Source. Very well tested/documented. Portable and can run on low memory footprint. It’s possible to call C or C++ functions from its RHS section. Most likely the Rules Engine will need to interact with a C or C++ software.

Disadvantages: It is not thread safe. It supports only forward chaining.

2) The system supports python:

PyClips:

Python interface to CLIPS. Functionality remains the same as in the previous case. Using this would only benefit if python calls need to be made in the RHS section. Any advantage/disadvantage I miss?

3) System supports JVM:

Jess:

Advantages: Nice integration with Java objects. CLIPS-like scripting language. Forward and backward chaining. Automatic listening to Java objects to modify slots.

Disadvantages: Licensed. Can only define new classes at compile time.

Drools:

Advantages: Open source. Documented. Java integration. Forward and backward chaining.

Disadvantages: It is more designed to work on the web (that's my impression).

What would be the advantage of Drools vs Jess in an embedded environment?

Both can only add new classes at compile time. CLIPS can at runtime. On the other hand,if the C++ code that updates clips instances is old, any new class created directly in CLIPS will not be matched to any other class in the calling C++ code. Therefore, the disadvantage of recompiling of the Java options is not such.

Is there any other appropriate engine for embedded systems that I am totally missing?

Gift

One thing you haven't considered is memory footprint. The Rete algorithm used by Jess, CLIPS, (parts of) Drools, and other products trades space for speed and thus uses an unbounded amount of memory at runtime. This may be wholly inappropriate for an embedded system. – Schoenberg

The requirements "minimum footprint" (due to the "embedded") and "accept new rules at runtime" are in sharp contrast. Unless you can narrow down the required capabilities of the rule language you may have a problem - compiling at runtime increases the memory footprint considerably. – Kathykathye

To clarify CLIPS threading support, you can create multiple instances of the engine each with its own execution thread. A single instance of the engine, however, is not thread safe for multiple threads. – Zumstein