Performance
OPS/R2 offers unmatched performance because it uses the
proprietary Rete II algorithm, and because it compiles rules into
machine code. (Most rule-based systems translate the rules to an
intermediate representation and then interpret that representation
at run-time.) Independently-developed benchmarks have shown that
OPS/R2 is much faster than conventional systems that use standard
Rete. Even on very simple programs, OPS/R2 runs a few times faster
than typical Rete-based systems. On more complex programs the
difference in speed is greater; OPS/R2 has been benchmarked to run
more than 100 times the speed of a popular Rete-based system on
standard benchmark programs.
Support for Both Forward and Backward Chaining
OPS/R2 supports both OPS5-like forward chaining and MYCIN-like
backward chaining. Both kinds of rule chaining are supported because
they are appropriate for different kinds of problems. Forward
chaining is commonly used for design and configuration, intelligent
process monitoring, scheduling, and other tasks that have complex
control requirements. Backward chaining is most often used for
diagnostic tasks.
OPS/R2 does not compromise in its handling of either kind of
rules. As a descendant of OPS5 and OPS83, it of course has complete
support for forward chaining, with powerful pattern-matching
capabilities, support for multiple rule firing strategies, and
comprehensive rule debugging facilities. But the language also has
full support for backward chaining. The backward chaining rules in
OPS/R2 use Certainty Factors; the condition parts of the rules can
contain nested AND and OR clauses; priorities can be associated with
the rules; and the rule interpreter supports How and Why
explanations. This is true MYCIN-style backward chaining; it is not
the clumsy pseudo-backward chaining supported by other
forward-chaining languages.
Recursive Forward Chaining
Conventional forward and backward chaining were developed in the
1970's. Recursive forward chaining (RFC) is a recently-developed
technique that is upward compatible with conventional forward
chaining, but that is much more powerful. One RFC rule can replace
several conventional rules. It is not uncommon to see instances
where five to ten conventional rules are replaced by one GFC rule.
The three varieties of rule chaining are seamlessly integrated in
OPS/R2. A rule set can switch from one form of rule chaining to
another at any time. It is no more complicated for a forward
chaining rule to invoke a set of backward chaining rules than it is
for that same rule to invoke other forward chaining rules.
Expressive Power
The OPS/R2 rule language has exceptional expressive power. OPS/R2
lets you concentrate on solving the problem, not on working around
artificial limits in the language. In addition to OPS/R2's
integrated support for backward chaining, conventional forward
chaining, and recursive forward chaining, the language offers:
 | Object-oriented rules. The elements in an
OPS/R2 working memory can be objects that inherit from other
objects. When a new working memory type is derived from an old
type, the new type inherits all the rules for the old type. (This
is the analogue to inheritance of methods in conventional
object-oriented languages.) |
| Multiple working memories. An OPS/R2 program
can have multiple independent working memories. This permits sets
of data that are conceptually independent to be kept physically
separate. In this way, unwanted interactions are prevented, and
the resulting system is more modular and easier to understand.
|
| User-defined control. Different problems call
for different problem-solving techniques; therefore, OPS/R2 does
not force your application into a standard mold. You can use a
standard inference strategy supplied with OPS/R2, you can make a
few modifications to a supplied strategy, or you can create a new
strategy specifically suited to your application. |
| Logical support for working memory objects.
In OPS/R2 you can specify that certain working memory objects
require other objects to provide them logical support. That is,
you can specify that a given working memory object is to be
considered true only as long as certain other objects exist in
working memory. When the system changes in such a way that the
supported objects should no longer be considered true, it is
automatically deleted from working memory. This feature permits
you to eliminate many housekeeping rules from your system. |
A Robust Implementation
OPS/R2 was designed to handle mission-critical applications. It
can run 24 hours a day, seven days a week. (Its predecessor OPS/83
was often used this way.) Several features have been designed into
OPS/R2 specifically to support this kind of service. Temporary
symbols permit symbol space to be reclaimed when the symbols are no
longer needed. Explicit control of dynamic memory permits the
programmer to specify precisely when certain kinds of dynamic memory
are to be returned to the system pool.
Embedability in C and C++
OPS/R2 can be used either to build stand-alone expert systems or
to create rule modules that link into existing C or C++ programs.
When you link OPS/R2 rules into a C or C++ program, the result is an
ordinary executable program that is run exactly the same way a
regular C or C++ program is run. Unlike other rule-based systems,
there will be no time-consuming delay as the program loads special
rule files at program startup time.
OPS/R2 was designed to eliminate the need for the "glue" code
that other rule-based systems require. OPS/R2 uses standard C
subroutine-linkage conventions and standard C data types. Because of
this, making a call from a C or C++ module to an OPS/R2 module (or
from an OPS/R2 module to a C or C++ module) is no more difficult
than making a call from one C module to another.
OPS/R2 makes it easy for C or C++ code to access the working
memories of the rules. The C interface to working memory provides a
straightforward API (Applications Program Interface) that permits C
functions to inspect, create, modify, or delete working memory
objects. The C++ interface provides a set of C++ objects that
encapsulate OPS/R2 working memory objects. C++ functions can operate
on the OPS/R2 working memory objects as if they were ordinary C++
objects.
Development Environment
The primary development environment for OPS/R2 is the Workbench,
a windowed, point-and-click system. Using the Workbench the
programmer can review rules, trace execution, set breakpoints,
search working memory, modify the program data, save and restore the
execution state, and perform other functions. One powerful feature
of the Workbench is its ability to display historical information.
With the history feature, when you find your system doing something
unexpected, you do not have to rerun the program to find out how it
got to that point; instead you can simply browse through the history
information maintained by the Workbench.
Because OPS/R2 is sometimes used on machines that cannot support
graphical user interfaces and pointing devices, OPS/R2 is also
supplied with a command-oriented development environment. The
command-driven environment provides all the information of the
Workbench, but it requires only an ordinary terminal to run.
No Run-Time Fees
Like all PST tools, OPS/R2 does not have run-time royalty fees.
You can buy one development license, create your program, and then
put the compiled program onto as many computers as you want.
