- Email: [email protected]
A simple “embedded” reasoning inference engine with application example in the X-ray Photoelectron Spectroscopy
Computer Physics Communications 160 (2004) 8–22 www.elsevier.com/locate/cpc
A simple “embedded” reasoning inference engine with application example in the X-ray Photoelectron Spectroscopy ✩ János Végh Institute of Nuclear Research of the Hungarian Academy of Sciences, H-4001 Debrecen, POB 51, Hungary Received 12 November 2003; accepted 17 February 2004 Available online 16 April 2004
Abstract In the field of experimental data acquisition and evaluation need rises for using some kind of “expert system” in order to provide support for sophisticated instruments and data evaluation applications. Different external expert system shells served as the basis for previous attempts to develop an expert system for such goals in the X-ray Photoelectron Spectroscopy (XPS). The paper presents a simple reasoning expert system engine, which can be built directly into data acquisition and evaluation software. Some problems arising due to the lack of human intelligence in the inferencing process are also discussed. The feasibility of the realized system is demonstrated through implementing a real-life rule set, an example (the carbon contamination rules) taken from the field of XPS. Apart from the field-specific rules, the package can be used on any field. 2004 Elsevier B.V. All rights reserved. PACS: 07.05.Kf; 07.05.Mh; 07.05.Hd; 07.90.+c Keywords: Embedded expert system; Inference engine; X-ray Photoelectron Spectroscopy; Measurement control; Spectrum evaluation
1. Introduction The different methods and systems originating from the artificial intelligence (see for example [1]) are more and more extensively used in very different fields, including science, industry and everyday life. One of its specific fields, the expert systems, is also conquering step-by-step different fields of life. In the different applications very different definitions, functions and forms are used, but probably all of them fulfill the classical definition [2]: “. . . a computer program that behaves like a human expert in some useful ways”. Even more variety can be experienced in using “embedded” in connection with expert systems. Typically it means that the expert system functionality is hidden (in some software layer, firmware, etc.) and not directly accessible by the user. In the rest of this paper the embedded expert system means a software package that can provide human expert like decisions and reasoning using a built-in knowledge base and information accessing agents, but does not communicate directly with the user. ✩
This work was supported by the project OTKA T046783. E-mail address: [email protected] (J. Végh).
0010-4655/$ – see front matter 2004 Elsevier B.V. All rights reserved. doi:10.1016/j.cpc.2004.02.009
J. Végh / Computer Physics Communications 160 (2004) 8–22
9
With the tendency of developing more and more capable and sophisticated measurement devices and measurement data evaluation programs, more and more need raises towards the expertise needed to handle them adequately. The problem of helping the experimenter with expert’s advice has been attacked several times, with different ideas. The electron spectroscopy as an experimental field complicated both in acquiring and evaluating data, is no exception. Castle and Baker [3] have proposed some rules for an expert system suitable for application in X-ray Photoelectron Spectroscopy (XPS) and also discussed the feasibility of expert systems in the field of XPS. Recently, a renewed interest raised in applying expert system(-like) functionality in the different fields of XPS, as outlined in the expert workshop in Saint-Malo [4]. The goal of those efforts was to develop an expert system (both the rules and the inference mechanism) which can be built directly into data acquisition and evaluation software. In a recent paper [5] the implementation of the first known rule set [3] for XPS in such a system has been published. That rule set is implemented in a simple ‘embedded expert system’. The system comprises a simplified expert system engine that can be applied in other fields, too. Here the inference engine’s principles are detailed, giving its application in XPS as an example.
2. The ‘embedded expert system’ There are many expert systems, based on different ‘shells’, in use. For its users the expert system is a ‘black box’ that provides to his questions a more or less cryptic reply, which depends in a pre-defined way on some external conditions. In addition, an expert system is able to explain why a particular decision was made. 2.1. Need for a special expert system In most of the known “expert system shells” a special language is constructed to describe the rules. The input is formulated in a native language (usually English) and so is formulated the resulting reply, too. In the field of XPS, the user exposes his problem and responds to questions formulated by the expert system. During this process, he evaluates spectra, looks up data in a database, etc. and finally, interprets the result. Such kind of an expert system is not appropriate for using it as an automated “embedded expert system”. The one which the XPS users need built into their data handling software, shall be somewhat simplified but still be able to simulate a real domain expert. When using external information, the system shall be able to access the parameters of the spectrum to be collected, the spectrum components fitted to the experimental data, the samplerelated information, some commonly used data bases; shall be able to handle the acquisition hardware, etc. In addition to these requirements, the system shall be able to explain its decisions, because (especially in the data evaluation applications) the users might need it. The requirements can be fulfilled only by a very specialised expert system. Fortunately, the special conditions allow to reach a reasonable trade off, retaining only the most mystic part of the expert system: the inference engine. For the rules concerned just some simple logical functionality is requested, even no forward/backward chaining. Since the field of the intended application needs some well-defined, community verified rules, it is an acceptable compromise to not provide native language input and to use only the inferencing and reasoning abilities of the expert system. Also, we can give up the need for constructing and using rules created “on the fly”. We have to take into consideration that the users of such an expert system are usually neither experts in programming or in expert systems. These assumptions suggest an expert system with at least three different access levels, as shown in Fig. 1. The lowest level (‘Base’) provides access to the general purpose expert system functionality for programmers. This level comprises the logical operations, see Section 2.2 and the inference engine functionality, see Section 2.3. At this level a rather complete functionality is provided, see in the following sections. The level ‘Rules’ is where the system can be tailored to the needs of the specialists of the different specific fields, see Section 2.6. Here the very
10
J. Végh / Computer Physics Communications 160 (2004) 8–22
Fig. 1. Access levels to the “embedded expert system”.
basic and more complex, established, expert-proven rules are accessed. The developers constructing generally used rules for some specific field need access here, see Section 4. The highest level (‘Applications’) is reserved for the end-users of the expert system. They can use the field-specific rules through combining them into more complex rules or deriving more specific rules for their own use. All mechanisms and reasonings are inherited from the lower levels and most of the field-specific rules can be taken ‘off the shelf’, so specialised rules can be constructed quickly and effectively, see Section 3.3. 2.2. Need for extending the boolean logic An expert system shall arrive to the same result from the same input data as a human expert would do. The human expert shall work sometimes with incomplete or missing data, so in the real life the replies of an expert person to a question can be not only a definite “yes” or “no”, but also “maybe yes” or “probably no”, as well as “in lack of . . . I cannot decide” or “I am not sure” or even “I do not know”. These replies can also be used as input information when formulating another question to an expert person. Because of this, one of the most critical points of an expert system is the type of the output it can give and the type of the input it can receive. For operating the inference engine properly, one has to extend the generally used (two valued) boolean logic to multiple-valued logic. Introducing some kind of three-valued logic enables the expert system to simulate an expert person who is able to deal with incomplete/not fully reliable input data and is able to give a reply other than a definite “yes” or “no”. The new logic can be constructed as an extension to the boolean logic: operators (defined by their “truth table”, see Tables 1–4 in Appendix A) can be defined and implemented.
J. Végh / Computer Physics Communications 160 (2004) 8–22
11
2.3. The generic rule The key to the usability of the package is to provide an easy way to making properly behaving rules. A so called “generic rule” establishes the behaviour of the rules used in the system. It is implemented as an “object” (see Appendix A) operating with triple-valued logic variables and functions introduced above. Most of the functions are not directly used by the application or at user level; the typical application uses only two member functions. Of course it uses also the logical operators with the same meaning used in connection with 2-valued logical variables. The Fire() member function evaluates the rule and returns the corresponding extended boolean value. This function can use external data sources, other rules, stored extended boolean variables, etc. It is important to note that the comprised other rules can be structured in any special way, including if–then–else type internal rule structure, sum or proportion type rules, etc. During the evaluation the generic rule combines some strings attached to the comprised rules (and stored data, etc.) with strings corresponding to the operation between the rules. The resulting string represents some kind of reasoning (for examples see Section 4.3) which is the so called default reasoning. This reasoning string is returned by function GetReasoning(). Any kind of reasoning (custom reasoning) can be realized through overriding this function. Two different evaluation modes can be set for the rules. In the ‘complete’ mode all logical variables and functions comprising the rules are evaluated, independently from the actual values the rules deliver. In ‘shortcut’ mode only those which the result of the rule can be clearly and doubtlessly evaluated from. Since the variables and functions, not used actually for calculating the value of the rule, are redundant; omitting them makes the evaluation shorter and quicker as well as the reasoning cleaner. Because of this, the ‘shortcut’ mode is selected as default. 2.4. Handling external information The goal of the package is to operate on data from the data evaluation and data acquisition software, so the method of interaction with them shall also be elaborated. The program might need information from external databases, from the web, from the user; should act on something, etc. These requirements suggest to use “agents”, the same way as they are used in many fields of the artificial intelligence [1] (AI). As an example agent the xrSpectrumAgent is introduced. It uses methods provided by the wxEWA program [6,7] which defines a consequent, fully OOP based model for spectrum evaluation. The central object in wxEWA is the ‘computed spectrum’ (see Fig. 2), which comprises a list of components (background and peaks) and references to objects ‘measured spectrum’, ‘sample’, ‘spectrometer’, etc. The figure is an (incomplete) objects interworking diagram for the wxEWA program, and it also illustrates advantages of the object-oriented design. One has to teach only the ‘SpectrumComponent’ object to answer the question ‘Are your energy-related parameters given on binding energy scale?’, and all peaks and backgrounds will inherit this ability. It is enough to implement the ‘GetPeakEnergy()’ method in the ‘PeakComponent’ ancestor object and all derived peaks will do it in the same way. This feature can be used advantageously when it is asked if there is a peak with a given energy in the spectrum. The ‘ComputedSpectrum’ object can ask all ‘PeakObject’s using its ‘HasPeakInRegion(EnergyLow, EnergyHigh)’ method, and they can report the result using their ‘IsAt(Energy)’ method. Even, these methods can actually be invoked in rules, so part of the platform-specific rules can be built into spectrum evaluation objects. 2.5. Rules vs wizards One way to handle the parameters for the rules is to not provide any help on what conditions are needed and to force the user to figure out the bad parameters and missing conditions from the results the rules provide. The settings could be done at different places of the application, in various forms, usually without any available on-line help or explanation. Another possibility is to guide the user on his way of assembling the necessary conditions
12
J. Végh / Computer Physics Communications 160 (2004) 8–22
Fig. 2. Object interworking diagram in the expert system-controlled wxEWA data evolution software.
and parameters in such a form that before a rule ‘fires’, the user is asked about all conditions, he can select some parameters from lists, check checkboxes, select with radioboxes, etc. The complex selections can be split into several simple setting steps (and graphical units or pages) and explanations or even figures can be attached to the selections. The latter style is used in the today’s windowing-style operating systems, most noticeably in Windows. This ‘wizard style’ was also considered for making logical conclusions and reasoning with an expert system [8]. From the user’s point of view, wizards are a safe way to reach some goal, without the need of knowing many details. From the programmer’s point of view, the wizards are specialised and guided dialogs, which direct the user to establish the necessary conditions, ask for the requested information pieces, and even force some prescribed way of usage through disabling temporarily some operations, making some routes one-way only, etc. When using a wizard either all phases are passed (during which the needed replies/info pieces are delivered and the logical parameters of the rules established) resulting in some conclusion or the wizard is cancelled, delivering no reply at all. Without using any wizard, the user needs to know (or needs to conclude from the reasoning of the conclusion of an unsuccessful trial) which conditions are necessary for the rule to deliver the reply he wants. The main difference between these cases is that the wizard ‘knows’ the necessary conditions as well as the ways as they can be established and guides/forces the user to follow the necessary steps, while in the case of using the rules directly the user has to figure out from the reasoning he receives from the system what is still missing. That is, using wizards is a ‘hard-wired’ way of receiving a reply from the inference engine, because (at least part of) the rules shall be hard-wired in the sequence of the wizard pages, in the used controls, etc.
J. Végh / Computer Physics Communications 160 (2004) 8–22
13
There are, however, some important differences. When using wizards, the user is the medium (or the agent) that provides the replies needed by the expert system engine. Because of this, wizards have some important disadvantages: • • • • •
user’s intelligence has to be involved in the decision process, the process cannot be automated or integrated with the acquisition/evaluation software, the user will be the only information source, the result will contain some subjective elements (replies), allows ‘improvisation’.
On the other hand, they have also some advantages: • • • •
user’s intelligence and knowledge might be involved in the decision process, no direct integration with the acquisition/evaluation software is necessary, any kind of input information can be used, allows ‘improvisation’.
2.6. Domain specific rules As it could be deduced from the first published XPS rule set [3], the rules needed for the expert system are essentially simple logical expressions. In the present system they are implemented using 3-valued logic and also their operators are defined by their truth tables. The elementary rules can be formulated as questions like ‘IsXXX’ or ‘HasXXX’ or ‘DoesXXX’, i.e., questions which can be answered using the True, False, Unknown value set. Formally, the rules are able (through agents) to extract the necessary information from external objects, like spectrum, configuration file, user, database, etc. and provide the result in form of a 3-valued logical value with a joined reasoning. The resulting values (as well as the joined reasoning) can be combined to form more complex rules. These combined rules also result in a single 3-valued boolean and comprise a reasoning that includes the reasonings of the more elementary rules. The resulting rule can also be used when constructing even more complex rules. In all specific fields, it is a good idea to prepare a set of very basic rules. These rules are considered trivial, but unfortunately they shall be used in constructing the less trivial ones. The human experts consider them so much trivial that even do not mention them when outlining the rules suggestions. However, the expert systems are lacking any human intelligence (as well as expertise in the domain), so they shall use them heavily in order to avoid trivial mistakes. Some examples in XPS are given in Section 4.1. The specific fields might need some composite rules assembled in some special way. The XPS rule set [3] needs explicitly two special kinds of composite rules, see Section 4.2. Note that in the case of such composite rules usually some kind of ‘custom reasoning’ is also necessary.
3. Features and feasibility The present section discusses some practical aspects of developing expert systems using the present base package. 3.1. The implementation For a complex task such as implementing an expert system, using object oriented programming (see, e.g., [9]) seems to be a necessity. Fortunately, most modern languages support this programming facility. Much less
14
J. Végh / Computer Physics Communications 160 (2004) 8–22
are among them which also support operator overloading, which is the simplest way of implementing the binary operations between the extended booleans and the expert rules, including the reasoning joined to them. Because of this, the C++ language [10] has been chosen for implementing the base system. It facilitates for both using objects (for the rules) and operator overloading, which allows using an elegant syntax, quite similar to the natural English language. In the present system the language’s standard elements (‘for’ cycles, ‘if–then–else’ structures, etc.) are used to combine the rules, to calculate, etc. The implemented package is available through the net for free [11]. 3.2. Testing the rules When constructing widely usable rules (and especially in case of ‘embedded’ ones), one has to exercise maximum care in excluding all logical mistakes as well as in providing from the same input data the same result that a human expert would provide. In the case of using real spectrum-related data (even if derived from test or artificial spectra) it is hard to exclude the possibility that the provided result does not match the expectation because of error in the input data rather than in the logic. In addition, in a non-trivial case it is at least hard to provide spectra (even artificial ones) for all possible situations to be tested. Such kind of errors and problems do not occur if the rules get their input data from a data source with known and controllable content. Because of this, the present expert system can use input data provided by control elements on a graphic surface, controlled by its user. Using this kind of input data the rules can be tested under clean conditions: one can easily produce all possible conditions and can completely exclude misfunctioning due to incorrect data. At this point one can make good use of the excellent support provided by the multi-platform package wxWidgets [12], because • The package needs some objects, like strings, lists, etc. This package provides the possibility to install the software at very different hardware and software platforms. • The development (including rule verifying phase) can be carried out on very different platforms. • The demo applications can be run on different platforms, allowing all users to study and improve the rules. • The multi-language capability allows to receive reasonings in the user’s native language. 3.3. The demonstration application Using the multi-platform package wxWidgets [12] a demonstration application has been prepared, which shows the usage of the sample rule set (see Section 4) and also can serve as a basis for a similar application in a different field. The application provides menu items for verifying some more or less complex rules directly, as well as a sample “wizard” which comprises the ‘carbon contamination rules’ and delivers the reply if the carbon contamination is present in the XPS sample. In the present system the question whether or not using a wizard makes a difference only in the demonstration application, the logic engine and the rules behind the scenes remain the same in both cases. The more important point here is the rule and the logical interrelations between some parameters, the way as they are communicated to the inference engine is of secondary importance. Although it is probably correct that for the very beginner it is easier to use a wizard, with growing familiarity with the rules and conditions, the user will find it much slower and less effective to reach the goal with wizards than using the rules directly.
4. An example: Rules for the expert system for XPS In the first published XPS rule set [3], the rules needed for the expert system are simple logical expressions or some simple combinations of such expressions.
J. Végh / Computer Physics Communications 160 (2004) 8–22
15
4.1. Elementary XPS-specific rules One of the very basic equations in the electron spectroscopy is the one that describes the dependence of the kinetic energy of the ejected electron on the energy of the exciting X-ray source and the binding energy of the electron in the atomic shell: EKinetic = EeXcitation − EBinding.
(1)
Knowing the energy of the exciting source, the binding energy and the kinetic energy can be easily calculated from each other. In the practical evaluation both energy types have their advantages and some used energy values are given on one scale, some others on the other scale. Because of this the expert system shall be able to calculate one from the other. The requirement if some data are available on binding energy scale in everyday English is: Binding energy is available if energy data are on binding energy scale or energy data are on kinetic energy scale and excitation energy is known. Using the present base package it is quite straightforward to translate the everyday terminology to logical expression as well as to create the corresponding rule: class xrIsEnergyKnownBE : public xpRuleXPS { public: xrIsEnergyKnownBE( xpAgent *MyAgent=NULL) :xpRuleXPS(MyAgent) { Name = "Binding energy known"; } xpRuleGeneric Fire(void) { return xrIsEnergyBE(xpAgent) OR ( xrIsEnergyKE(xpAgent) AND xrIsXEnergyKnown(xpAgent) ); } };// of xrIsEnergyKnownBE The braces in this particular case are not really necessary (the precedence of the operators would result in the same calculation order without them, too), they just emphasise how exactly the expression is meant. Now (thanks to the ancestor object’s functionality) the CalculateValue() member function can calculate the resulting value (whether one can use the binding energy scale) and the method GetReasoning() can tell the reason to the user, see Section 4.3. It is important to know whether some energy region is measured completely: IsRegionMeasuredBE(Spectrum, BE1, BE2) = { IsEnergyKnownBE(Spectrum) AND
16
J. Végh / Computer Physics Communications 160 (2004) 8–22
IsInRangeBE(Spectrum.MeasuredLowBE, Spectrum.MeasuredHighBE, BE1) AND IsInRangeBE(Spectrum.MeasuredLowBE, Spectrum.MeasuredHighBE, BE2) } where the rule whether an energy value falls in some range is IsInRangeBE(BE1, BE2, EnergyBE) = { EnergyBE > BE1 AND EnergyBE < BE2 } Since the peaks are objects, and they can tell their energy, the rule if a peak has its energy in some range has the form: IsInRangeBE(Peak, BE1, BE2) = { Peak.EnergyBE > BE1 AND Peak.EnergyBE < BE2 } The elementary rules above can be combined into a more complex general rule (representing an example of the subrange type rule), which tells if some energy region contains a peak at all: HasPeakInRangeBE(Spectrum, BE1, BE2) = { IsInRangeBE(BE1,BE2,Spectrum.Peak1) OR IsInRangeBE(BE1,BE2,Spectrum.PeakN) }
// For all peaks
4.2. Composite XPS-specific rules Using these elementary rules, quite complex rules can be constructed. For example, the criterion if the C 1s peak is present in the spectrum at all, is given in form HasCarbon1sPeak (Spectrum) = { IsRegionMeasuredBE(Spectrum, 282-2, 462+2) //Region measured AND IsRegionMeasuredKE(Spectrum, 269-2, 275+2) //Region measured AND HasPeakInRangeBE(Spectrum, 282, 288) //C 1s present AND HasPeakInRangeKE(Spectrum, 269, 275) //KLL Auger present AND ! HasPeakInRangeBE(Spectrum, 458, 462) //Ruthenium absent }
J. Végh / Computer Physics Communications 160 (2004) 8–22
17
Note that here it seems unnecessary to verify if the region containing C 1s peak is measured at all and if the given energy values are accessible. And really, they could be verified in the lower-level rules, too. In the latter case, however, they will be executed more than once, which decreases performance and blows up reasoning unnecessarily. The carbon contamination rule represents again another type of rules. Neither of the sub-rules alone is decisive, but they all increase by some amount the chance that the sample is carbon contaminated. The sum then can be below a lower or above an upper threshold, or even between them. The rule then “fires” correspondingly: HasCarbonContamination(Spectrum) = { x = 0 if IsEnergySeparationInRange(ESLow, ESHigh) x = x + 15 if HasCarbon1sPeak(Spectrum) x = x + 20 if IsShirleyParameterAboveThreshold(Spectrum.PeakC1s) x = x + 25 if IsCarbonSlopeGreater(Spectrum) x = x + 25 .... False if x < LowThreshold True if x > HighThreshold else Unknown } 4.3. Example reasoning For the rule described in Section 4.1 the conditions can be set differently. Depending on the actual values, the Fire() function delivers the correct value for the rule and the GetReasoning() function will result in text something like: "Binding energy known" is TRUE because ("Energy-Data are BE" is TRUE OR ("Energy-Data are KE" is FALSE AND "Exciting energy known" is UNKNOWN)) This is the result the ‘default reasoning’ in ‘complete’ evaluation mode. (The ‘reasonings’ shown in this section are the results from the working code.) The same result in ‘shortcut’ mode is: "Binding energy known" is TRUE because "Energy-Data are BE" is TRUE As it is seen, the information content is identical but the output is more compact. In shortcut mode it is simpler to understand the reasoning of the rule. When setting the input values differently, different values and different reasonings are resulted: "Binding energy known" is TRUE because ("Energy-Data are KE" is TRUE AND "Exciting energy known" is TRUE)
18
J. Végh / Computer Physics Communications 160 (2004) 8–22
or "Binding energy known" is FALSE because ("Energy-Data are BE" is FALSE OR "Energy-Data are KE" is FALSE) or "Binding energy known" is UNKNOWN because ("Energy-Data are BE" is FALSE OR ("Energy-Data are KE" is TRUE AND "Exciting energy known" is UNKNOWN)) The real advantages of using expert system rules come to light in the case of more complex rules. As Castle pointed out [3], the decision whether the surface of the sample is carbon contaminated (the rule “HasCarbonContamination”, see above) cannot be based with certainty on one single rule, because the inelastic scattering of the photoelectrons these rules are based upon depends very much on the material type. Rather, several sub-rules shall be used and a consensus between them shall be reached. As mentioned by Castle, selecting that five sub-rules [3] is somewhat arbitrary and serves as an example of making such a composite rule. The sub-rules are of different complexity: some of them only read certain flags, others make searching, comparing, even they might do active operations, like setting flags or changing values. The internal operation of the sub-rules is irrelevant here: some weight (called ‘credit’ here) is assigned to their result and the final result is derived as a weighted average of the results of the sub-rules. These sub-rules derive their own decision independently and increase by the value of their credit the certainty of the result of the main rule. Using the language facilities of the host language (C++) any kind and number of operations can be performed within the rule and the feature “custom reasoning” allows to keep only the important information provided by the used sub-rules and the logic. An example reasoning begins like this: "Is Carbon contamination consensus" is TRUE because The 72.2% of the subrules voted FOR that the carbon is contamination (More than the requested minimum 70.0% for TRUE) This main rule coordinates the results received from the sub-rules in order to reach some kind of consensus. The main rule has a lower and an upper threshold level for the resulting certainty. Below the low threshold value, the result of the main rule is “False”, above the high threshold it is “True”, between them it is “Unknown”. The credits and the threshold values are arbitrary (but not unrealistic) and shall later be adjusted in order to reflect the experiences from the praxis, as well as some more rules shall be added. The reasoning of the main rule is complete now. The reasoning of the individual sub-rules is listed under “details” in the reasoning of the main rule, as follows. The energy separation of the major excursions in the first derivative of the carbon KLL spectrum varies with the chemical state [13]. It was suggested that the value of this separation in a certain energy range also increases the certainty that the carbon is present as contamination. The first sub-rule verifies the energy separation of these excursions:
J. Végh / Computer Physics Communications 160 (2004) 8–22
19
Details: Energy separation (credit 20) voted FOR that carbon is contamination (The energy separation parameter 17.0 is in range [15.0,20.0]) If it is known that the bulk of the sample does not contain carbon, and yet the carbon is present in the spectrum, the fact increases significantly the certainty that the carbon is present as contamination. The sub-rule checks if the sample contains carbon and if the carbon is present in the spectrum. !! Bulk carbon content rule (credit 40) not relevant if carbon is contamination (The sample contains carbon) It has been shown [14] that the interaction between the valence bands of adsorbate and substrate results in increased intrinsic energy losses and so leads to an increased tail height in the case of the Carbon tail. The sub-rule determines (or verifies) is the Carbon 1s line is present, marks it and evaluates its tail height. C1s Shirley tail height (credit 25) voted AGAINST that carbon is contamination (The Carbon 1s Shirley tail height parameter 0.050 is BELOW threshold value 0.100) It has been pointed out [15] that the background after peaks of elements in the outermost layer is horizontal (or even decreasing) whereas that of the other elements in a deeper layer is increasing. The fourth sub-rule decides based on comparing the background slopes of all elements: Carbon background slope (credit 25) voted FOR that carbon is contamination (All post peak slopes are smaller than 0.030, that of the Carbon 1s) The last rule formulates the experience that with changing the angle of detection relative to the surface normal, one changes the effective thickness from which the electrons can come out. So, if the carbon is at the top (i.e., it is contamination), the intensity of its photopeak recorded at different angles changes much less than that of the other elements: Carbon angle ratio (credit 20) voted FOR that carbon is contamination (All angle ratios are smaller than 0.600, that of the Carbon 1s) 4.4. The XPS demonstration application
The data evaluation application is simulated through so called ‘notebook pages’, see Fig. 3. Here all data and characteristics used in the ‘carbon rules’ can be set by the graphics control elements of the application. The features of the individual spectrum components are controlled through graphic screen elements and text input/output.
20
J. Végh / Computer Physics Communications 160 (2004) 8–22
Fig. 3. Screenshot of the XPS demonstration application on a Linux KDE desktop. The notebook page simulates XPS peak related information.
5. Summary A general purpose ‘embedded inference engine’ has been implemented. The feasibility of the ‘embedded expert system’ has been demonstrated through implementing the first known rule set in the X-ray Photoelectron Spectroscopy. The complete rule set has been tested on a demonstration application, built using a multi-platform package. The software is available for using in other domains, too.
Appendix A Truth tables for the extended logic Possible value ranges: (U(nknown), F(alse) == 0, T(rue) == 1)
Table 1 Truth table for the extended boolean NOT operation (NOT) !A
A U U
F T
T F
Table 2 Truth table for the extended boolean AND operation (AND) A && B U B F T
A U U F
F F F
T U F
U
F
T
J. Végh / Computer Physics Communications 160 (2004) 8–22
Table 3 Truth table for the extended boolean OR operation (OR)
A
21
Table 4 Truth table for the extended boolean EQUALS operation (EQUALS)
A
A—B U B F
U U U
F U F
T T T
A == B U B F
U U U
F U T
T U F
T
T
T
T
T
U
F
T
The generic rule The generic rule contains the following data: string HistoryString; string Name; pointer InfoSource; xbool value;
// Here is the execution history string stored // The name of the rule // Pointer to the info source // Rules saved value
and methods // constructors & destructor AddStringToHistory: //contribute to history string GetValue: //return the stored logical value CalculateValue: //calculate the logical value anew using "Fire" Fire: //return the resulting rule GetHistoryString: //return the history while calculating the value GetName: //return the name of the rule GetReasoning: //return the rule’s history in reasoning form GetValueString: //return the rule’s value in string form SetShortcutMode: //set ’shortcut’ or ’complete’ evaluation mode = //(assign) operator ! //(negation) operator && //(logical AND) operator || //(logical OR) operator
References [1] S.J. Russell, P. Norvig, Artificial Intelligence: Modern Approach, Prentice Hall, New York, 1995. [2] P.H. Winston, K.A. Prendergast (Eds.), The AI Business: Commercial Use of Artificial Intelligence, MIT Press, Cambridge, MA, 1984. [3] J.E. Castle, M.A. Baker, The feasibility of an XPS expert system demonstrated by a rule set for carbon contamination, J. Electron Spectroscopy and Related Phenomena 105 (1999) 245–256. [4] From spectra to results—towards an expert system, in: 34th IUVSTA Workshop XPS, http://www.vide.org/xps.htm/, April 2002, SaintMalo, France. [5] J. Végh, The ‘carbon contamination’ rule set implemented in an ‘embedded expert system’, J. Electron Spectroscopy and Related Phenomena 133 (2003) 87–101. [6] J. Végh, EWA: A spectrum evaluation program for XPS/UPS, ECASIA’95—6th European Conference on Applications of Surface and Interface Analysis, Surface and Interface Analysis 1 (1995) 679–682. [7] J. Végh, A spectrum evaluation program with options in X-ray photoelectron spectroscopy, http://wxewa.sourceforge.net/, 2001. [8] J.E. Castle, A wizard source of expertise in XPS, Surface and Interface Analysis 33 (2002) 196–202.
22
J. Végh / Computer Physics Communications 160 (2004) 8–22
[9] B. Eckel, Object oriented programming, http://www.mindview.net/Books, 1999. [10] B. Stroustrup, International standard for the C++ programming language approved!, http://www.research.att.com/~bs/iso_release.html/, 1997. [11] J. Végh, An ‘embedded’ expert system for X-ray photoelectron spectroscopy, http://xps4xps.sourceforge.net/, 2002. [12] J. Smart, et al., The open source, cross-platform GUI framework, http://wxwidgets.sourceforge.net/, 1992. [13] E. Desimoni, T.R.I. Cataldi, U. Biader Ceipidor, Annali di Chimica 82 (1992) 207–218. [14] A.M. Salvi, J.E. Castle, The intrinsic asymmetry component of the ‘total background’ in XP spectra, J. Electron Spectroscopy and Related Phenomena 94 (1998) 73–87. [15] J.E. Castle, A. Talib, S.A. Richardson, The use of energy loss structures in XPS characterization of surfaces, Mat. Res. Soc. Symp. Proc. 48 (1984) 471–479.
A simple “embedded” reasoning inference engine with application example in the X-ray Photoelectron Spectroscopy ✩ János Végh Institute of Nuclear Research of the Hungarian Academy of Sciences, H-4001 Debrecen, POB 51, Hungary Received 12 November 2003; accepted 17 February 2004 Available online 16 April 2004
Abstract In the field of experimental data acquisition and evaluation need rises for using some kind of “expert system” in order to provide support for sophisticated instruments and data evaluation applications. Different external expert system shells served as the basis for previous attempts to develop an expert system for such goals in the X-ray Photoelectron Spectroscopy (XPS). The paper presents a simple reasoning expert system engine, which can be built directly into data acquisition and evaluation software. Some problems arising due to the lack of human intelligence in the inferencing process are also discussed. The feasibility of the realized system is demonstrated through implementing a real-life rule set, an example (the carbon contamination rules) taken from the field of XPS. Apart from the field-specific rules, the package can be used on any field. 2004 Elsevier B.V. All rights reserved. PACS: 07.05.Kf; 07.05.Mh; 07.05.Hd; 07.90.+c Keywords: Embedded expert system; Inference engine; X-ray Photoelectron Spectroscopy; Measurement control; Spectrum evaluation
1. Introduction The different methods and systems originating from the artificial intelligence (see for example [1]) are more and more extensively used in very different fields, including science, industry and everyday life. One of its specific fields, the expert systems, is also conquering step-by-step different fields of life. In the different applications very different definitions, functions and forms are used, but probably all of them fulfill the classical definition [2]: “. . . a computer program that behaves like a human expert in some useful ways”. Even more variety can be experienced in using “embedded” in connection with expert systems. Typically it means that the expert system functionality is hidden (in some software layer, firmware, etc.) and not directly accessible by the user. In the rest of this paper the embedded expert system means a software package that can provide human expert like decisions and reasoning using a built-in knowledge base and information accessing agents, but does not communicate directly with the user. ✩
This work was supported by the project OTKA T046783. E-mail address: [email protected] (J. Végh).
0010-4655/$ – see front matter 2004 Elsevier B.V. All rights reserved. doi:10.1016/j.cpc.2004.02.009
J. Végh / Computer Physics Communications 160 (2004) 8–22
9
With the tendency of developing more and more capable and sophisticated measurement devices and measurement data evaluation programs, more and more need raises towards the expertise needed to handle them adequately. The problem of helping the experimenter with expert’s advice has been attacked several times, with different ideas. The electron spectroscopy as an experimental field complicated both in acquiring and evaluating data, is no exception. Castle and Baker [3] have proposed some rules for an expert system suitable for application in X-ray Photoelectron Spectroscopy (XPS) and also discussed the feasibility of expert systems in the field of XPS. Recently, a renewed interest raised in applying expert system(-like) functionality in the different fields of XPS, as outlined in the expert workshop in Saint-Malo [4]. The goal of those efforts was to develop an expert system (both the rules and the inference mechanism) which can be built directly into data acquisition and evaluation software. In a recent paper [5] the implementation of the first known rule set [3] for XPS in such a system has been published. That rule set is implemented in a simple ‘embedded expert system’. The system comprises a simplified expert system engine that can be applied in other fields, too. Here the inference engine’s principles are detailed, giving its application in XPS as an example.
2. The ‘embedded expert system’ There are many expert systems, based on different ‘shells’, in use. For its users the expert system is a ‘black box’ that provides to his questions a more or less cryptic reply, which depends in a pre-defined way on some external conditions. In addition, an expert system is able to explain why a particular decision was made. 2.1. Need for a special expert system In most of the known “expert system shells” a special language is constructed to describe the rules. The input is formulated in a native language (usually English) and so is formulated the resulting reply, too. In the field of XPS, the user exposes his problem and responds to questions formulated by the expert system. During this process, he evaluates spectra, looks up data in a database, etc. and finally, interprets the result. Such kind of an expert system is not appropriate for using it as an automated “embedded expert system”. The one which the XPS users need built into their data handling software, shall be somewhat simplified but still be able to simulate a real domain expert. When using external information, the system shall be able to access the parameters of the spectrum to be collected, the spectrum components fitted to the experimental data, the samplerelated information, some commonly used data bases; shall be able to handle the acquisition hardware, etc. In addition to these requirements, the system shall be able to explain its decisions, because (especially in the data evaluation applications) the users might need it. The requirements can be fulfilled only by a very specialised expert system. Fortunately, the special conditions allow to reach a reasonable trade off, retaining only the most mystic part of the expert system: the inference engine. For the rules concerned just some simple logical functionality is requested, even no forward/backward chaining. Since the field of the intended application needs some well-defined, community verified rules, it is an acceptable compromise to not provide native language input and to use only the inferencing and reasoning abilities of the expert system. Also, we can give up the need for constructing and using rules created “on the fly”. We have to take into consideration that the users of such an expert system are usually neither experts in programming or in expert systems. These assumptions suggest an expert system with at least three different access levels, as shown in Fig. 1. The lowest level (‘Base’) provides access to the general purpose expert system functionality for programmers. This level comprises the logical operations, see Section 2.2 and the inference engine functionality, see Section 2.3. At this level a rather complete functionality is provided, see in the following sections. The level ‘Rules’ is where the system can be tailored to the needs of the specialists of the different specific fields, see Section 2.6. Here the very
10
J. Végh / Computer Physics Communications 160 (2004) 8–22
Fig. 1. Access levels to the “embedded expert system”.
basic and more complex, established, expert-proven rules are accessed. The developers constructing generally used rules for some specific field need access here, see Section 4. The highest level (‘Applications’) is reserved for the end-users of the expert system. They can use the field-specific rules through combining them into more complex rules or deriving more specific rules for their own use. All mechanisms and reasonings are inherited from the lower levels and most of the field-specific rules can be taken ‘off the shelf’, so specialised rules can be constructed quickly and effectively, see Section 3.3. 2.2. Need for extending the boolean logic An expert system shall arrive to the same result from the same input data as a human expert would do. The human expert shall work sometimes with incomplete or missing data, so in the real life the replies of an expert person to a question can be not only a definite “yes” or “no”, but also “maybe yes” or “probably no”, as well as “in lack of . . . I cannot decide” or “I am not sure” or even “I do not know”. These replies can also be used as input information when formulating another question to an expert person. Because of this, one of the most critical points of an expert system is the type of the output it can give and the type of the input it can receive. For operating the inference engine properly, one has to extend the generally used (two valued) boolean logic to multiple-valued logic. Introducing some kind of three-valued logic enables the expert system to simulate an expert person who is able to deal with incomplete/not fully reliable input data and is able to give a reply other than a definite “yes” or “no”. The new logic can be constructed as an extension to the boolean logic: operators (defined by their “truth table”, see Tables 1–4 in Appendix A) can be defined and implemented.
J. Végh / Computer Physics Communications 160 (2004) 8–22
11
2.3. The generic rule The key to the usability of the package is to provide an easy way to making properly behaving rules. A so called “generic rule” establishes the behaviour of the rules used in the system. It is implemented as an “object” (see Appendix A) operating with triple-valued logic variables and functions introduced above. Most of the functions are not directly used by the application or at user level; the typical application uses only two member functions. Of course it uses also the logical operators with the same meaning used in connection with 2-valued logical variables. The Fire() member function evaluates the rule and returns the corresponding extended boolean value. This function can use external data sources, other rules, stored extended boolean variables, etc. It is important to note that the comprised other rules can be structured in any special way, including if–then–else type internal rule structure, sum or proportion type rules, etc. During the evaluation the generic rule combines some strings attached to the comprised rules (and stored data, etc.) with strings corresponding to the operation between the rules. The resulting string represents some kind of reasoning (for examples see Section 4.3) which is the so called default reasoning. This reasoning string is returned by function GetReasoning(). Any kind of reasoning (custom reasoning) can be realized through overriding this function. Two different evaluation modes can be set for the rules. In the ‘complete’ mode all logical variables and functions comprising the rules are evaluated, independently from the actual values the rules deliver. In ‘shortcut’ mode only those which the result of the rule can be clearly and doubtlessly evaluated from. Since the variables and functions, not used actually for calculating the value of the rule, are redundant; omitting them makes the evaluation shorter and quicker as well as the reasoning cleaner. Because of this, the ‘shortcut’ mode is selected as default. 2.4. Handling external information The goal of the package is to operate on data from the data evaluation and data acquisition software, so the method of interaction with them shall also be elaborated. The program might need information from external databases, from the web, from the user; should act on something, etc. These requirements suggest to use “agents”, the same way as they are used in many fields of the artificial intelligence [1] (AI). As an example agent the xrSpectrumAgent is introduced. It uses methods provided by the wxEWA program [6,7] which defines a consequent, fully OOP based model for spectrum evaluation. The central object in wxEWA is the ‘computed spectrum’ (see Fig. 2), which comprises a list of components (background and peaks) and references to objects ‘measured spectrum’, ‘sample’, ‘spectrometer’, etc. The figure is an (incomplete) objects interworking diagram for the wxEWA program, and it also illustrates advantages of the object-oriented design. One has to teach only the ‘SpectrumComponent’ object to answer the question ‘Are your energy-related parameters given on binding energy scale?’, and all peaks and backgrounds will inherit this ability. It is enough to implement the ‘GetPeakEnergy()’ method in the ‘PeakComponent’ ancestor object and all derived peaks will do it in the same way. This feature can be used advantageously when it is asked if there is a peak with a given energy in the spectrum. The ‘ComputedSpectrum’ object can ask all ‘PeakObject’s using its ‘HasPeakInRegion(EnergyLow, EnergyHigh)’ method, and they can report the result using their ‘IsAt(Energy)’ method. Even, these methods can actually be invoked in rules, so part of the platform-specific rules can be built into spectrum evaluation objects. 2.5. Rules vs wizards One way to handle the parameters for the rules is to not provide any help on what conditions are needed and to force the user to figure out the bad parameters and missing conditions from the results the rules provide. The settings could be done at different places of the application, in various forms, usually without any available on-line help or explanation. Another possibility is to guide the user on his way of assembling the necessary conditions
12
J. Végh / Computer Physics Communications 160 (2004) 8–22
Fig. 2. Object interworking diagram in the expert system-controlled wxEWA data evolution software.
and parameters in such a form that before a rule ‘fires’, the user is asked about all conditions, he can select some parameters from lists, check checkboxes, select with radioboxes, etc. The complex selections can be split into several simple setting steps (and graphical units or pages) and explanations or even figures can be attached to the selections. The latter style is used in the today’s windowing-style operating systems, most noticeably in Windows. This ‘wizard style’ was also considered for making logical conclusions and reasoning with an expert system [8]. From the user’s point of view, wizards are a safe way to reach some goal, without the need of knowing many details. From the programmer’s point of view, the wizards are specialised and guided dialogs, which direct the user to establish the necessary conditions, ask for the requested information pieces, and even force some prescribed way of usage through disabling temporarily some operations, making some routes one-way only, etc. When using a wizard either all phases are passed (during which the needed replies/info pieces are delivered and the logical parameters of the rules established) resulting in some conclusion or the wizard is cancelled, delivering no reply at all. Without using any wizard, the user needs to know (or needs to conclude from the reasoning of the conclusion of an unsuccessful trial) which conditions are necessary for the rule to deliver the reply he wants. The main difference between these cases is that the wizard ‘knows’ the necessary conditions as well as the ways as they can be established and guides/forces the user to follow the necessary steps, while in the case of using the rules directly the user has to figure out from the reasoning he receives from the system what is still missing. That is, using wizards is a ‘hard-wired’ way of receiving a reply from the inference engine, because (at least part of) the rules shall be hard-wired in the sequence of the wizard pages, in the used controls, etc.
J. Végh / Computer Physics Communications 160 (2004) 8–22
13
There are, however, some important differences. When using wizards, the user is the medium (or the agent) that provides the replies needed by the expert system engine. Because of this, wizards have some important disadvantages: • • • • •
user’s intelligence has to be involved in the decision process, the process cannot be automated or integrated with the acquisition/evaluation software, the user will be the only information source, the result will contain some subjective elements (replies), allows ‘improvisation’.
On the other hand, they have also some advantages: • • • •
user’s intelligence and knowledge might be involved in the decision process, no direct integration with the acquisition/evaluation software is necessary, any kind of input information can be used, allows ‘improvisation’.
2.6. Domain specific rules As it could be deduced from the first published XPS rule set [3], the rules needed for the expert system are essentially simple logical expressions. In the present system they are implemented using 3-valued logic and also their operators are defined by their truth tables. The elementary rules can be formulated as questions like ‘IsXXX’ or ‘HasXXX’ or ‘DoesXXX’, i.e., questions which can be answered using the True, False, Unknown value set. Formally, the rules are able (through agents) to extract the necessary information from external objects, like spectrum, configuration file, user, database, etc. and provide the result in form of a 3-valued logical value with a joined reasoning. The resulting values (as well as the joined reasoning) can be combined to form more complex rules. These combined rules also result in a single 3-valued boolean and comprise a reasoning that includes the reasonings of the more elementary rules. The resulting rule can also be used when constructing even more complex rules. In all specific fields, it is a good idea to prepare a set of very basic rules. These rules are considered trivial, but unfortunately they shall be used in constructing the less trivial ones. The human experts consider them so much trivial that even do not mention them when outlining the rules suggestions. However, the expert systems are lacking any human intelligence (as well as expertise in the domain), so they shall use them heavily in order to avoid trivial mistakes. Some examples in XPS are given in Section 4.1. The specific fields might need some composite rules assembled in some special way. The XPS rule set [3] needs explicitly two special kinds of composite rules, see Section 4.2. Note that in the case of such composite rules usually some kind of ‘custom reasoning’ is also necessary.
3. Features and feasibility The present section discusses some practical aspects of developing expert systems using the present base package. 3.1. The implementation For a complex task such as implementing an expert system, using object oriented programming (see, e.g., [9]) seems to be a necessity. Fortunately, most modern languages support this programming facility. Much less
14
J. Végh / Computer Physics Communications 160 (2004) 8–22
are among them which also support operator overloading, which is the simplest way of implementing the binary operations between the extended booleans and the expert rules, including the reasoning joined to them. Because of this, the C++ language [10] has been chosen for implementing the base system. It facilitates for both using objects (for the rules) and operator overloading, which allows using an elegant syntax, quite similar to the natural English language. In the present system the language’s standard elements (‘for’ cycles, ‘if–then–else’ structures, etc.) are used to combine the rules, to calculate, etc. The implemented package is available through the net for free [11]. 3.2. Testing the rules When constructing widely usable rules (and especially in case of ‘embedded’ ones), one has to exercise maximum care in excluding all logical mistakes as well as in providing from the same input data the same result that a human expert would provide. In the case of using real spectrum-related data (even if derived from test or artificial spectra) it is hard to exclude the possibility that the provided result does not match the expectation because of error in the input data rather than in the logic. In addition, in a non-trivial case it is at least hard to provide spectra (even artificial ones) for all possible situations to be tested. Such kind of errors and problems do not occur if the rules get their input data from a data source with known and controllable content. Because of this, the present expert system can use input data provided by control elements on a graphic surface, controlled by its user. Using this kind of input data the rules can be tested under clean conditions: one can easily produce all possible conditions and can completely exclude misfunctioning due to incorrect data. At this point one can make good use of the excellent support provided by the multi-platform package wxWidgets [12], because • The package needs some objects, like strings, lists, etc. This package provides the possibility to install the software at very different hardware and software platforms. • The development (including rule verifying phase) can be carried out on very different platforms. • The demo applications can be run on different platforms, allowing all users to study and improve the rules. • The multi-language capability allows to receive reasonings in the user’s native language. 3.3. The demonstration application Using the multi-platform package wxWidgets [12] a demonstration application has been prepared, which shows the usage of the sample rule set (see Section 4) and also can serve as a basis for a similar application in a different field. The application provides menu items for verifying some more or less complex rules directly, as well as a sample “wizard” which comprises the ‘carbon contamination rules’ and delivers the reply if the carbon contamination is present in the XPS sample. In the present system the question whether or not using a wizard makes a difference only in the demonstration application, the logic engine and the rules behind the scenes remain the same in both cases. The more important point here is the rule and the logical interrelations between some parameters, the way as they are communicated to the inference engine is of secondary importance. Although it is probably correct that for the very beginner it is easier to use a wizard, with growing familiarity with the rules and conditions, the user will find it much slower and less effective to reach the goal with wizards than using the rules directly.
4. An example: Rules for the expert system for XPS In the first published XPS rule set [3], the rules needed for the expert system are simple logical expressions or some simple combinations of such expressions.
J. Végh / Computer Physics Communications 160 (2004) 8–22
15
4.1. Elementary XPS-specific rules One of the very basic equations in the electron spectroscopy is the one that describes the dependence of the kinetic energy of the ejected electron on the energy of the exciting X-ray source and the binding energy of the electron in the atomic shell: EKinetic = EeXcitation − EBinding.
(1)
Knowing the energy of the exciting source, the binding energy and the kinetic energy can be easily calculated from each other. In the practical evaluation both energy types have their advantages and some used energy values are given on one scale, some others on the other scale. Because of this the expert system shall be able to calculate one from the other. The requirement if some data are available on binding energy scale in everyday English is: Binding energy is available if energy data are on binding energy scale or energy data are on kinetic energy scale and excitation energy is known. Using the present base package it is quite straightforward to translate the everyday terminology to logical expression as well as to create the corresponding rule: class xrIsEnergyKnownBE : public xpRuleXPS { public: xrIsEnergyKnownBE( xpAgent *MyAgent=NULL) :xpRuleXPS(MyAgent) { Name = "Binding energy known"; } xpRuleGeneric Fire(void) { return xrIsEnergyBE(xpAgent) OR ( xrIsEnergyKE(xpAgent) AND xrIsXEnergyKnown(xpAgent) ); } };// of xrIsEnergyKnownBE The braces in this particular case are not really necessary (the precedence of the operators would result in the same calculation order without them, too), they just emphasise how exactly the expression is meant. Now (thanks to the ancestor object’s functionality) the CalculateValue() member function can calculate the resulting value (whether one can use the binding energy scale) and the method GetReasoning() can tell the reason to the user, see Section 4.3. It is important to know whether some energy region is measured completely: IsRegionMeasuredBE(Spectrum, BE1, BE2) = { IsEnergyKnownBE(Spectrum) AND
16
J. Végh / Computer Physics Communications 160 (2004) 8–22
IsInRangeBE(Spectrum.MeasuredLowBE, Spectrum.MeasuredHighBE, BE1) AND IsInRangeBE(Spectrum.MeasuredLowBE, Spectrum.MeasuredHighBE, BE2) } where the rule whether an energy value falls in some range is IsInRangeBE(BE1, BE2, EnergyBE) = { EnergyBE > BE1 AND EnergyBE < BE2 } Since the peaks are objects, and they can tell their energy, the rule if a peak has its energy in some range has the form: IsInRangeBE(Peak, BE1, BE2) = { Peak.EnergyBE > BE1 AND Peak.EnergyBE < BE2 } The elementary rules above can be combined into a more complex general rule (representing an example of the subrange type rule), which tells if some energy region contains a peak at all: HasPeakInRangeBE(Spectrum, BE1, BE2) = { IsInRangeBE(BE1,BE2,Spectrum.Peak1) OR IsInRangeBE(BE1,BE2,Spectrum.PeakN) }
// For all peaks
4.2. Composite XPS-specific rules Using these elementary rules, quite complex rules can be constructed. For example, the criterion if the C 1s peak is present in the spectrum at all, is given in form HasCarbon1sPeak (Spectrum) = { IsRegionMeasuredBE(Spectrum, 282-2, 462+2) //Region measured AND IsRegionMeasuredKE(Spectrum, 269-2, 275+2) //Region measured AND HasPeakInRangeBE(Spectrum, 282, 288) //C 1s present AND HasPeakInRangeKE(Spectrum, 269, 275) //KLL Auger present AND ! HasPeakInRangeBE(Spectrum, 458, 462) //Ruthenium absent }
J. Végh / Computer Physics Communications 160 (2004) 8–22
17
Note that here it seems unnecessary to verify if the region containing C 1s peak is measured at all and if the given energy values are accessible. And really, they could be verified in the lower-level rules, too. In the latter case, however, they will be executed more than once, which decreases performance and blows up reasoning unnecessarily. The carbon contamination rule represents again another type of rules. Neither of the sub-rules alone is decisive, but they all increase by some amount the chance that the sample is carbon contaminated. The sum then can be below a lower or above an upper threshold, or even between them. The rule then “fires” correspondingly: HasCarbonContamination(Spectrum) = { x = 0 if IsEnergySeparationInRange(ESLow, ESHigh) x = x + 15 if HasCarbon1sPeak(Spectrum) x = x + 20 if IsShirleyParameterAboveThreshold(Spectrum.PeakC1s) x = x + 25 if IsCarbonSlopeGreater(Spectrum) x = x + 25 .... False if x < LowThreshold True if x > HighThreshold else Unknown } 4.3. Example reasoning For the rule described in Section 4.1 the conditions can be set differently. Depending on the actual values, the Fire() function delivers the correct value for the rule and the GetReasoning() function will result in text something like: "Binding energy known" is TRUE because ("Energy-Data are BE" is TRUE OR ("Energy-Data are KE" is FALSE AND "Exciting energy known" is UNKNOWN)) This is the result the ‘default reasoning’ in ‘complete’ evaluation mode. (The ‘reasonings’ shown in this section are the results from the working code.) The same result in ‘shortcut’ mode is: "Binding energy known" is TRUE because "Energy-Data are BE" is TRUE As it is seen, the information content is identical but the output is more compact. In shortcut mode it is simpler to understand the reasoning of the rule. When setting the input values differently, different values and different reasonings are resulted: "Binding energy known" is TRUE because ("Energy-Data are KE" is TRUE AND "Exciting energy known" is TRUE)
18
J. Végh / Computer Physics Communications 160 (2004) 8–22
or "Binding energy known" is FALSE because ("Energy-Data are BE" is FALSE OR "Energy-Data are KE" is FALSE) or "Binding energy known" is UNKNOWN because ("Energy-Data are BE" is FALSE OR ("Energy-Data are KE" is TRUE AND "Exciting energy known" is UNKNOWN)) The real advantages of using expert system rules come to light in the case of more complex rules. As Castle pointed out [3], the decision whether the surface of the sample is carbon contaminated (the rule “HasCarbonContamination”, see above) cannot be based with certainty on one single rule, because the inelastic scattering of the photoelectrons these rules are based upon depends very much on the material type. Rather, several sub-rules shall be used and a consensus between them shall be reached. As mentioned by Castle, selecting that five sub-rules [3] is somewhat arbitrary and serves as an example of making such a composite rule. The sub-rules are of different complexity: some of them only read certain flags, others make searching, comparing, even they might do active operations, like setting flags or changing values. The internal operation of the sub-rules is irrelevant here: some weight (called ‘credit’ here) is assigned to their result and the final result is derived as a weighted average of the results of the sub-rules. These sub-rules derive their own decision independently and increase by the value of their credit the certainty of the result of the main rule. Using the language facilities of the host language (C++) any kind and number of operations can be performed within the rule and the feature “custom reasoning” allows to keep only the important information provided by the used sub-rules and the logic. An example reasoning begins like this: "Is Carbon contamination consensus" is TRUE because The 72.2% of the subrules voted FOR that the carbon is contamination (More than the requested minimum 70.0% for TRUE) This main rule coordinates the results received from the sub-rules in order to reach some kind of consensus. The main rule has a lower and an upper threshold level for the resulting certainty. Below the low threshold value, the result of the main rule is “False”, above the high threshold it is “True”, between them it is “Unknown”. The credits and the threshold values are arbitrary (but not unrealistic) and shall later be adjusted in order to reflect the experiences from the praxis, as well as some more rules shall be added. The reasoning of the main rule is complete now. The reasoning of the individual sub-rules is listed under “details” in the reasoning of the main rule, as follows. The energy separation of the major excursions in the first derivative of the carbon KLL spectrum varies with the chemical state [13]. It was suggested that the value of this separation in a certain energy range also increases the certainty that the carbon is present as contamination. The first sub-rule verifies the energy separation of these excursions:
J. Végh / Computer Physics Communications 160 (2004) 8–22
19
Details: Energy separation (credit 20) voted FOR that carbon is contamination (The energy separation parameter 17.0 is in range [15.0,20.0]) If it is known that the bulk of the sample does not contain carbon, and yet the carbon is present in the spectrum, the fact increases significantly the certainty that the carbon is present as contamination. The sub-rule checks if the sample contains carbon and if the carbon is present in the spectrum. !! Bulk carbon content rule (credit 40) not relevant if carbon is contamination (The sample contains carbon) It has been shown [14] that the interaction between the valence bands of adsorbate and substrate results in increased intrinsic energy losses and so leads to an increased tail height in the case of the Carbon tail. The sub-rule determines (or verifies) is the Carbon 1s line is present, marks it and evaluates its tail height. C1s Shirley tail height (credit 25) voted AGAINST that carbon is contamination (The Carbon 1s Shirley tail height parameter 0.050 is BELOW threshold value 0.100) It has been pointed out [15] that the background after peaks of elements in the outermost layer is horizontal (or even decreasing) whereas that of the other elements in a deeper layer is increasing. The fourth sub-rule decides based on comparing the background slopes of all elements: Carbon background slope (credit 25) voted FOR that carbon is contamination (All post peak slopes are smaller than 0.030, that of the Carbon 1s) The last rule formulates the experience that with changing the angle of detection relative to the surface normal, one changes the effective thickness from which the electrons can come out. So, if the carbon is at the top (i.e., it is contamination), the intensity of its photopeak recorded at different angles changes much less than that of the other elements: Carbon angle ratio (credit 20) voted FOR that carbon is contamination (All angle ratios are smaller than 0.600, that of the Carbon 1s) 4.4. The XPS demonstration application
The data evaluation application is simulated through so called ‘notebook pages’, see Fig. 3. Here all data and characteristics used in the ‘carbon rules’ can be set by the graphics control elements of the application. The features of the individual spectrum components are controlled through graphic screen elements and text input/output.
20
J. Végh / Computer Physics Communications 160 (2004) 8–22
Fig. 3. Screenshot of the XPS demonstration application on a Linux KDE desktop. The notebook page simulates XPS peak related information.
5. Summary A general purpose ‘embedded inference engine’ has been implemented. The feasibility of the ‘embedded expert system’ has been demonstrated through implementing the first known rule set in the X-ray Photoelectron Spectroscopy. The complete rule set has been tested on a demonstration application, built using a multi-platform package. The software is available for using in other domains, too.
Appendix A Truth tables for the extended logic Possible value ranges: (U(nknown), F(alse) == 0, T(rue) == 1)
Table 1 Truth table for the extended boolean NOT operation (NOT) !A
A U U
F T
T F
Table 2 Truth table for the extended boolean AND operation (AND) A && B U B F T
A U U F
F F F
T U F
U
F
T
J. Végh / Computer Physics Communications 160 (2004) 8–22
Table 3 Truth table for the extended boolean OR operation (OR)
A
21
Table 4 Truth table for the extended boolean EQUALS operation (EQUALS)
A
A—B U B F
U U U
F U F
T T T
A == B U B F
U U U
F U T
T U F
T
T
T
T
T
U
F
T
The generic rule The generic rule contains the following data: string HistoryString; string Name; pointer InfoSource; xbool value;
// Here is the execution history string stored // The name of the rule // Pointer to the info source // Rules saved value
and methods // constructors & destructor AddStringToHistory: //contribute to history string GetValue: //return the stored logical value CalculateValue: //calculate the logical value anew using "Fire" Fire: //return the resulting rule GetHistoryString: //return the history while calculating the value GetName: //return the name of the rule GetReasoning: //return the rule’s history in reasoning form GetValueString: //return the rule’s value in string form SetShortcutMode: //set ’shortcut’ or ’complete’ evaluation mode = //(assign) operator ! //(negation) operator && //(logical AND) operator || //(logical OR) operator
References [1] S.J. Russell, P. Norvig, Artificial Intelligence: Modern Approach, Prentice Hall, New York, 1995. [2] P.H. Winston, K.A. Prendergast (Eds.), The AI Business: Commercial Use of Artificial Intelligence, MIT Press, Cambridge, MA, 1984. [3] J.E. Castle, M.A. Baker, The feasibility of an XPS expert system demonstrated by a rule set for carbon contamination, J. Electron Spectroscopy and Related Phenomena 105 (1999) 245–256. [4] From spectra to results—towards an expert system, in: 34th IUVSTA Workshop XPS, http://www.vide.org/xps.htm/, April 2002, SaintMalo, France. [5] J. Végh, The ‘carbon contamination’ rule set implemented in an ‘embedded expert system’, J. Electron Spectroscopy and Related Phenomena 133 (2003) 87–101. [6] J. Végh, EWA: A spectrum evaluation program for XPS/UPS, ECASIA’95—6th European Conference on Applications of Surface and Interface Analysis, Surface and Interface Analysis 1 (1995) 679–682. [7] J. Végh, A spectrum evaluation program with options in X-ray photoelectron spectroscopy, http://wxewa.sourceforge.net/, 2001. [8] J.E. Castle, A wizard source of expertise in XPS, Surface and Interface Analysis 33 (2002) 196–202.
22
J. Végh / Computer Physics Communications 160 (2004) 8–22
[9] B. Eckel, Object oriented programming, http://www.mindview.net/Books, 1999. [10] B. Stroustrup, International standard for the C++ programming language approved!, http://www.research.att.com/~bs/iso_release.html/, 1997. [11] J. Végh, An ‘embedded’ expert system for X-ray photoelectron spectroscopy, http://xps4xps.sourceforge.net/, 2002. [12] J. Smart, et al., The open source, cross-platform GUI framework, http://wxwidgets.sourceforge.net/, 1992. [13] E. Desimoni, T.R.I. Cataldi, U. Biader Ceipidor, Annali di Chimica 82 (1992) 207–218. [14] A.M. Salvi, J.E. Castle, The intrinsic asymmetry component of the ‘total background’ in XP spectra, J. Electron Spectroscopy and Related Phenomena 94 (1998) 73–87. [15] J.E. Castle, A. Talib, S.A. Richardson, The use of energy loss structures in XPS characterization of surfaces, Mat. Res. Soc. Symp. Proc. 48 (1984) 471–479.