|
|
|
 |
RiverSoftAVG Newsletter #14
Winter 2003/2004
Hello and welcome to Newsletter #14! Belated Happy Holidays to you and your
family! Again, this newsletter is late, late, late! Happily, we think the
wait was worth it. In this issue, we have a ton of news, downloads, and an
article on building monitoring applications using the IECS. We hope you
enjoy the newsletter and find it useful.
A reminder, this newsletter and all previous ones are available for download
from the web site at
http://www.riversoftavg.com/articles_&_tips.htm
Contents Article: Building a Monitoring Application with the IECS, Part 1
News: Inference Engine Component Suite (IECS) updated to v2.1!
News: Upcoming Fuzzy Logic Component Library
News: Object Inspector Component Suite (OICS) updated to v1.12!
Download: IECS/OICS Presets Available for Download
Note: You received this newsletter because you are an owner of a
RiverSoftAVG product. If you received this newsletter by mistake
or if for any reason you wish to not receive any future mailings from
RiverSoftAVG, just reply to this message informing us so. We apologize for
any intrusion.
Article: Building a Monitoring application with the IECS, Part 1
Introduction
In this newsletter, we are going to build a common application (at least,
that we've seen) of expert systems, a Health and Safety Monitoring system.
The basic idea of a Health & Safety Monitoring application is to create a
real-time or near real-time system to monitor incoming data to spot problems
or potential problems. If the HSM application sees a problem, it then
informs a user or other automated system about the problem so that
corrective action can be made. HSM expert systems are a very common expert
system. Fortunately, they are also very straightforward (usually) to make.
The input data for an HSM application may be raw sensor values, derived
(converted and computed) values, or even inferred values deduced by an
expert system. The data could be coming in over a socket, from a database,
from a simulator, or anywhere else. For the purposes of our HSM
application, we are going to simulate sensor values directly within the
application. The point is that we have data and that data may be "good" or
"bad" or even somewhere in between. Note that this is in addition to the
quality of the data. The quality of the data relates to how much you can
believe the data is not junk or corrupt. An HSM application could be
written to assess the quality of the data as well. But for this article, we
are talking about what the data means. If SensorA is 100, what does this
mean? If SensorA was a man's temperature, 100 degrees Fahrenheit means
somewhat bad (not life-threatening but not good either). If SensorA was the
temperature of water, it would mean the water is warm, which could be good
or bad depending on the context of the system (if our system needed boiling
water this would be bad as it is way too low. If our system needed bath
water, this may be just right).
When we talk about good or bad data, we usually get into the idea of
limits. What are the maximum and minimum limits to the good data for a
certain data value or sensor within our system? Many systems break the
limits down into red and yellow limits. The yellow limits are the "somewhat
bad" limits of the data, such as the man's temperature above. If his
temperature was above 102, it becomes life-threatening and his temperature
is "bad". This is a red limit.
Note that for this article, we are going to write a "traditional" health and
safety monitoring expert system that uses yellow and red limits. Because
the IECS supports fuzzy logic, we can go beyond traditional expert systems
and use fuzzy limits. However, we have enough on our plate this time so we
will save the Fuzzy Health and Safety Monitoring expert system until part 2.
Designing our HSM
The code and executable for our example HSM application are at
www.RiverSoftAVG.com\Files\HealthAndSafetyMonitor.zip Before we build
our HSM expert system, we need to build the infrastructure to simulate the
values we are going to monitor. In the example application, we've defined a
TCollection called TMnemonics, which will hold 0 or more TMnemonic items.
(In the aerospace field, mnemonics are the short name label for the "real"
name of ONE piece of data (one sensor)). Each TMnemonic class will
represent one raw or derived sensor. It is the job of the TMnemonic classes
to generate our test data. We are going to use the TMnemonic class to hold
the raw and derived values, the formula we use to generate each time step,
and the traditional low and high red and yellow limits. This is the data we
get over our socket, or from our database, etc.
For this application, we are going to simulate monitoring a satellite. Our
simulated satellite is made up of four different systems, each of which has
a number of assigned mnemonics. The four systems are Communications,
Control, Power, and Scientific (Payload). Using the MNEMONICS_PER_SYSTEM
constant, we assign a number of mnemonics to each system. All extra
mnemonics are assigned to the Scientific System.
When the Health & Safety Monitor starts, we will create some number of
mnemonics (defined by the NUM_MNEMONICS constant). Since this is a demo and
we want to watch what is happening, we will also create a chart for each
mnemonic to show the last 50 data points and the discrete red and yellow
limits. Generating charts is controlled by the GENERATE_CHARTS constant.
To simulate the data changing, we have also added a TTimer component to our
application. Every time the timer fires (controlled with the SIM_SPEED constant),
we will update our mnemonics using the specified formula. This will, in
turn, update our charts and (eventually) our expert sytem.
The HSM application has a number of constants and control variables defined
at the beginning of the main unit. You are welcome to play with them. You
can turn charts on or off, change the number of systems and mnemonics, and
much more. Be aware that some options, such as generating charts with a LOT
of mnemonics, can significantly impact the performance of the HSM.
For this article, we are going to build four expert systems. To allow us to
write one HSM application for all four expert systems, we have set up the
HSM application to load its expert system from an external file. The file
loaded is controlled by the EXPERT_SYSTEM constant. The four expert systems
are in the same directory as the HSM application and all use the *.ie
extension. As it is set up now, the HSM application will query the user on
startup for the expert system file to use.
The GUI for our HSM (see accompanying screenshot) will display the values
and limits for our mnemonics on the top of the form. This will serve as a
reality check for our expert system on the bottom. On the top left, we
display all the mnemonics in a list box. All mnemonics exceeding red limits
are in red, all mnemonics exceeding yellow limits are in yellow, and the
rest are normal. The rest of the top of the form is taken up with a chart
for each mnemonic showing its current value and some previous values.
The bottom of the GUI is divided into 3 main areas. On the bottom left, we
list the systems of the satellite. These also change color based on the
status of the system: normal (clBtnFace), warning (clYellow), and alert (clRed).
In the lower middle, we display the "satellite." This, too, will eventually
display colors for the satellite's status. Finally, in the lower right, we
display the science mnemonics and controls for the simulation.
Building our Expert System - Structures
First, we need to define the data structures of our expert system. For our
example, our expert system will only deal with mnemonic values for one time
step (so no trending-type monitor will occur). Each mnemonic value will be
represented by one fact containing the mnemonic name and its value. The
definition of our fact template will be:
(deftemplate mnemonic (slot name ) (slot value) )
We also need to define the metadata for each mnemonic, e.g., what system it
belongs to, what are its yellow limits, and what are its red limits. Unlike
the mnemonic fact template, these facts will be defined once and should
never change. Here is our fact template:
(deftemplate mnem-metadata (slot name ) (slot yellowhigh ) (slot redlow ) (slot redhigh ) (slot system ) (slot yellowlow ) (slot subsystem ) )
Those are the two most important fact templates. We also need an alert and
a warning fact template (discussed later), but they only need to hold the
name of the system so we can just use the default structure, e.g.,
(deftemplate warning) (deftemplate alert)
That's it for our structures. The HSM application will be responsible for
fill the mnem-metadata structure on startup. It will do this once. Every
time step, the HSM application will remove all mnemonic facts that currently
exist and then assert new mnemonic facts. Note that this is inefficient if
not all mnemonics change their value every time step. However, for
simplicity's sake and because of how we defined the mnemonic's formula, we
decided to just retract and assert every mnemonic every time step.
At the end of every time step and after all mnemonics are asserted, the HSM
application will then run the inference engine. We are going to make two
assumptions about our expert systems for simplicity: 1.) the expert system
will always finish, and 2) it shouldn't take long either. If the expert
system did not finish, calling InferenceEngine1.Run would put the
application into an infinite loop. If the expert system never finished or
took a long time, we would have to run the expert system a few steps at a
time and then return control back to the application.
Building our Expert System - Round 1
We will start with a very basic expert system, called "hsm - all
systems.ie". The job of this expert system is just to detect if mnemonics
are in-bounds, exceed yellow limits, or exceed red limits. When a
mnemonic is found that exceeds yellow limits, we are going to issue a
warning for the system it belongs to. When a mnemonic is found that
exceeds red limits, we are going to issue an alert for the system
it belongs to. We wish to receive only one alert or warning per system no
matter how many mnemonics are out of bounds.
This simple expert system is composed of two rules, one to check for red
limit violations and one to check for yellow limit violations. The rules
just need to check if a mnemonic fact's value exceeds the limits in the
mnemonic's metadata fact. When a violation occurs, we will print the
mnemonic that went out of bounds and then assert an alert or warning.
Here is the red-limit rule:
(defrule red-limit-violation "check for red-limit-violation" ?mnemonic <- (mnemonic (name ?mnemonicname) (value ?mnemonicvalue) ) ?mnem-metadata <- (mnem-metadata (name ?mnemonicname) (redhigh ?mnem-metadataredhigh) (redlow ?mnem-metadataredlow&:(not (< ?mnem-metadataredlow ?mnemonicvalue ?mnem-metadataredhigh))) (system ?mnem-metadatasystem) ) => (printout t Red Limit Violation: " " ?mnemonicname) (assert (alert ?mnem-metadatasystem )) )
Note that we are setting set-fact-duplication to TRUE for the expert
system. This means that the inference engine will throw away duplicate
facts when they are asserted. So even if more than one mnemonic exceeds
its limits, we can only receive one alert and one warning (though we can
receive both).
That's it. Now run the HSM application using the expert system. Press
the Play button and watch it go! Because this is a basic expert system
and our simulator is very basic, you will be able to see the expert system
flag LOTS of limit violations. But everything looks correct so we are
happy with our first attempt.
Building our Expert System - Round 2
Well, our Health and Safety Monitoring expert system worked but it
flagged way too many violations. If we think a moment, we realize
that the scientific system really has nothing to do with the health
and safety of the satellite (or at least, we assume so for our
example). Ideally, we could just never assert mnemonic facts for the
science system. However, we may need those facts for something else,
so let's just modify the expert system rules.
Since we have the system slot as part of our metadata, we can modify
our rules to just ignore mnemonics that are in the Scientific
system. Here is our new red limit violation rule:
(defrule red-limit-violation "check for red-limit-violation" ?mnemonic <- (mnemonic (name ?mnemonicname) (value ?mnemonicvalue) ) ?mnem-metadata <- (mnem-metadata (name ?mnemonicname) (redhigh ?mnem-metadataredhigh) (redlow ?mnem-metadataredlow&:(not (< ?mnem-metadataredlow ?mnemonicvalue ?mnem-metadataredhigh))) (system ?mnem-metadatasystem&~Scientific) ) => (printout t Red Limit Violation: " " ?mnemonicname) (assert (alert ?mnem-metadatasystem )) )
The file, "hsm - system basic, no science.ie," contains our new expert
system. Run the HSM application again, select this file, and press
Play... MUCH Better. We have reduced a lot of spurious warnings and
alerts that really didn't contribute to our monitoring of the
satellite.
Building our Expert System - Round 3
Now that we have the system status working, we need to work on
deciding the overall health of the spacecraft. For our satellite, we
are going to create three new rules:
For our new rules, we need to create a new fact template that will
hold the status of the satellite:
(deftemplate satellite-health "(Implied)")
After that, the first rule is easy:
(defrule satellite-critical "if any system alerts, satellite is critical" (alert ?system) => (assert (satellite-health ?*CRITICAL*)) )
Both the second and third rules are slightly more difficult.
Basically, the two rules are mirror images of one another. Satellite
is failing if greater than 50% warnings and no alerts. Satellite is
good if less than 50% warnings and no alerts. To determine if 50% or
more systems have warnings, we need to determine some aggregate
information about our alerts and warnings before we can make an
assessment. We actually have add one more rule: one to count the
number of warnings. To count the warnings, we will need two new fact
types: one to count the warnings and one to tell us to not count the
same system twice. Our count-warnings rule will then just need to
find a warning fact, increment the warning-count fact and assert the
counted warning system fact:
(defrule count-warnings "count the number of systems that have warnings" ?w <- (warning ?sys) (not (counted-warning ?sys)) ?wc <- (warning-count ?c) => (assert (counted-warning ?sys)) (modify ?wc (__Data (+ ?c 1))) )
We needed to assert the counted-warning fact because we didn't want the rule to fire again when the warning-count fact changes. Now that we have tallied the warning count, we can write our good or failiing rules. For these rules, we want to fire when there are no alerts (which would fire the satellite-critical rule), the warning count is more (or less) than 50% of the number of systems (represented by a global variable we will have the HSM application set), AND all of the warnings have been counted. This last condition means that we need to set the salience (priority) for these rules to less than the count-warnings rule. Here is the satellite-failing rule:
(defrule satellite-failing "if no system alerts but more than 50% systems are yellow, satellite is failing" (declare (salience -10)) (not (alert ?system)) (warning-count ?wc&:(> ?wc (* ?*NUM_SYS* 0.50))) => (assert (satellite-health ?*FAILING*)) )
You can load this expert system from the file, "hsm - satellite basic, no science.ie"
Building our Expert System - Round 4
For our last expert system, we wanted to
fine-tune our warnings and alerts for each system. The first
three expert systems are very simplisitic in that just signal a
warning or alert if a violation is found for any mnemonic of a
system. This time, we are going to assume that there is some
redundancy in our satellite or wiggle room for displaying warnings
and alerts. To make it interesting, we will treat each system
differently.
Round 4 - Comm System
For the Communications system, we are going to assume that each mnemonic represents available bandwidth for the comm system. Each mnemomic provides 1 Mbps of bandwidth when nominal and 0.5 Mbps when yellow. Our total bandwidth provided by the Communications system with 5 mnemonics will be 5 Mbps maximum. Now, each Science mnemonic represents some science data from an instrument. To keep it simple, each science mnemonic requires 0.20 Mbps. All other telemetry (housekeeping) requires an additional 0.5 Mbps. Total load will therefore be (15*0.2)+0.5 = 3.5 Mbps. For our communications system, we will define two rules:
In order to create our rules, we need to make a few
intermediate facts and a couple new rules. The first intermediate fact,
system-violations, will track the good, yellow, and red mnemonics for
each system. Each iteration, the facts will be initialized so that
yellow and red are 0 and the good is the number of mnemonics in the
system. Here is its fact template:
(deftemplate system-violations (slot name ) (slot yellow ) (slot red ) (slot good ) )
Now, our original red-limit-violation and
yellow-limit-violation rules need to be rewritten to not just assert
alerts and warnings willy-nilly. Instead, they will assert another
class of intermediate facts: mnem-yellow-violation and
mnem-red-violation, which will contain the system and the mnemonic that
is out of bounds. Here is the new red-limit-violation rule:
(defrule red-limit-violation "check for red-limit-violation" ?mnemonic <- (mnemonic (name ?mnemonicname) (value ?mnemonicvalue) ) ?mnem-metadata <- (mnem-metadata (name ?mnemonicname) (redhigh ?mnem-metadataredhigh) (redlow ?mnem-metadataredlow&:(not (< ?mnem-metadataredlow ?mnemonicvalue ?mnem-metadataredhigh))) (system ?mnem-metadatasystem&~Scientific) ) => (printout t Red Limit Violation: " " ?mnemonicname) (assert (mnem-red-violation ?mnem-metadatasystem ?mnemonicname)) )
Now, we will define the two new rules which count the
red or yellow violations and add it to the system-violations fact we
defined above. Below is the count-red-violations rule:
(defrule count-red-violations "count red-limit violations for each system" ?violation-fact <- (mnem-red-violation ?mnem-metadatasystem ?mnemonicname) ?sys-violations <- (system-violations (name ?mnem-metadatasystem) (red ?c) (good ?g)) => (retract ?violation-fact) (modify ?sys-violations (red (+ 1 ?c)) (good (- ?g 1))) )
Finally, we can write the Comm-Alert and
Comm-Warning rules. Basically, these rules will add up the good
and yellow mnemonic bandwidth (GOOD*1+YELLOW*0.5) and compares it to the
load ((15*0.2)+0.5). If the load exceeds the bandwidth, Comm-Alert
fires. If load exceeds 80% of bandwidth, Comm-Warning fires.
Otherwise, neither fires. Here is the Comm-Alert rule:
(defrule Comm-Alert "Comm gives alert when can no longer provide bandwidth for all science instruments" (system-violations (name Communications) (red ?rc) (good ?gc) (yellow ?yc&:(and (= (+ ?rc ?yc ?gc) ?*NUM_MNEM_PER_SYSTEM*) (< (+ (* ?gc ?*COMM_BANDWIDTH_NORMAL*) (* ?yc ?*COMM_BANDWIDTH_YELLOW*)) (+ 0.5 (* ?*SCI_BANDWIDTH* ?*NUM_SCI_MNEMS*)))))) => (assert (alert Communications) ) )
Round 4 - Control System
The Control system has its own rules. In this case, we are going to
assume each mnemonic represents a gyro. To operate properly, our
satellites needs at least 2 good gyros or 1 good gyro and 2 yellow
gyros. Our Control system will define two new rules:
We can reuse our system-violations facts from above, so all we need to
do is write the 2 rules. Here is the Control-Alert rule:
(defrule Control-Alert "Control needs at least 2 good gyros or combo of 3 good/yellow" (not (alert Control)) (system-violations (name Control) (red ?rc) (good ?gc) (yellow ?yc&:(and (= (+ ?rc ?yc ?gc) ?*NUM_MNEM_PER_SYSTEM*) (not (or (>= ?gc 2) (>= (+ ?gc ?yc) 3)))))) => (assert (alert Control) ) )
Round 4 - Power System
Our Power system is the least complicated of the
redesigned systems. Our rules for the Power system will be:
These are simple rules, and this has been a *long*
article, so we will refer curious readers to the expert system file, "hsm
- satellite, no science.ie." You can now load and run this expert
system in the HSM application.
Conclusion
That's it. For this article, we are done. There is obviously a lot of extra
work that could be done on this application. Adding more inferred facts and
inferring facts from those inferred facts (mnemonics cause subsystem alerts
which cause system alerts which cause satellite alerts) ad nauseum would
increase the complexity and hopefully the intelligence of our expert system.
More significant rules would also be nice. But this was a lot for one small
tutorial and it is enough to get you started. The rest is left up to the
reader :-) Next time, we are going to extend the HSM expert system and create
a fuzzy HSM. See you then!
News: Inference Engine Component Suite (IECS) updated to v2.1!
The Inference Engine Component Suite has been updated to v2.1. Owners of
the IECS v2.0 can go to the web site and download their new update from the
http://www.riversoftavg.com/support.htm page (you will need the user
name and password). The IECS v2.1 is in many ways an important update
because it includes one seemingly minor feature and one major feature.
The minor feature is that we have changed our installation procedures to use
InnoSetup. InnoSetup is by Jordan Russell and is a free installer
for Windows programs. By replacing InstallShield with InnoSetup, all of our
installations will now automatically install the components into Delphi and
install the Help. No longer will you have to add components or help
manually! Also, InnoSetup allows us to automate creating new
releases. This will reduce the number of errors
(once we shake out the bugs) and hopefully allow us to
create smaller point releases more often.
The major feature is it includes a large update to our fuzzy logic library.
We have added new components and features to the fuzzy logic library. Soon,
we are going to offer it as a stand-alone component product. Don't worry,
the Fuzzy Logic Component Library will always come bundled with the IECS as
it is a vital part of the fuzzy logic support in the IECS. However, now you
will have access to the standalone product as well so you can use fuzzy
logic in situations you don't need to full IECS. Please read more about the
fuzzy logic library in the following news item.
So, in summary, IECS v2.1 is a point release to the IECS. The installer is
new and the fuzzy logic components outside the IECS are new. These
features will have a shakedown period. However, the IECS core has not been
changed and is still rock solid (once it installs :-)). To read more about
the changes, check out the IECS history page:
http://www.riversoftavg.com/IECS_version_history.htm
News: Upcoming Fuzzy Logic Component Library!
RiverSoftAVG is proud to announce the beta version of a new product: the Fuzzy
Logic Component Library. We've enhanced the great and tried-and-tested fuzzy
logic features of the Inference Engine Component Suite and are creating a
standalone product. The FLCL will always come bundled with the IECS
(so IECS users, you will never need to buy this product). However, for users
who don't need the complexity (and price) of the IECS but who need some fuzzy
logic, this product is for you. The project is currently is beta.
Here is the official blurb about it:
The RiverSoftAVG Fuzzy Logic Component Library for Delphi 5, 6 and 7 is an
advanced fuzzy logic library for adding fuzzy logic to your programs. The
FLCL is included free with the Inference Engine Component Suite, but is also
available stand-alone. The FLCL has the following features:
News: Object Inspector Component Suite (OICS) updated to v1.12!
The Object Inspector Component Suite was updated once again on December 7th. Registered users of the OICS will want to download the new update (those users who purchased the OICS after December 7th do not need to get the download). This is a maintenance release and fixes bugs. To read more about what was fixed, go to the version history page: http://www.riversoftavg.com/OICS_version_history.htm
You can download the update (you'll need a user name and
password if you haven't already requested one) from
http://www.riversoftavg.com/support.htm
Download: IECS/OICS Presets Available for Download
As promised last time (see "Tip: Using the IECS with the OICS" in newsletter
13), we have a free download available for registered users of both the IECS
and OICS. We've created some Object Inspector Property Presets for editing
special properties of the inference engine. In all, there are 8 presets for
defining property editors using the IECS with the OICS. This is a free
download, with source, available from the http://www.riversoftavg.com/downloads.htm
page.
One tip: with these presets installed, every time you drop an object
inspector on the form, the object inspector automatically adds these
presets. If you do NOT use a IECS component in your project, when you run
your project you will receive an "Error reading RSObjectInspector1.HPresets:
Class TRSTIExxxPropertyPreset not found" exception. The solution is easy,
just delete the IECS presets from the Presets property of the Object
Inspector.
Well, that's it for this time. Happy Holidays and see you in the New Year!
|
Send mail to
webmasterNO@SPAMRiverSoftAVG.com with questions or comments about this web
site.
|
