Expert System Shell for Building Photofinishing Diagnostic Systems

The present invention relates generally to artificial intelligence and knowledge engineering, and more particularly to a knowledge engineering tool for diagnosing a photofinishing process such as in a film processor.

A portion of the disclosure of this patent document contains material to which a claim of copyright protection is made. The copyright owner has no objection to the facsimile reproduction of any one of the patent documents or the patent disclosure, as it appears in the U.S. Patent and Trademark Office patent file or records, but reserves all other rights whatsoever.

A photofinishing process is a procedure for converting a latent image on the photographic plate to an actual image. It has been known for a long time that some silver salts, such as silver bromide and silver iodide (collectively called silver halides), are sensitive to light. When silver halide is exposed to light, the structure of the silver halide will be changed. It was also noted that unexposed and exposed silver halides have different chemical characteristics. When a thin layer of silver halide emulsion is put on a plate which is later exposed to different light intensities, a latent image is formed on the plate. By placing the plate in a developer solution, the exposed silver halide is reduced to metallic silver, while the unexposed silver halide is not affected. The unexposed silver halide can then be dissolved and washed away in the subsequent steps, leaving the metallic silver behind. Because of the special molecular structure of the reduced metallic silver it actually appears in black rather than in "silver" color, resulting in a black-and-white picture.

Color processing is more complicated. Based on the tri-color theory (red, green and blue for the additive method or their corresponding complementary colors, cyan, magenta and yellow for the subtractive method), the whole color spectrum can be reproduced by using just three primary colors. In photography, the subtractive method is extensively used. Three layers of silver halide emulsion that contain (or are later caused to contain) dyes of cyan, magenta and yellow are made to become sensitive only to red, green and blue light, respectively. Thus, three overlapping images of cyan, magenta and yellow colors are formed, resulting in a color picture.

There are many different photofinishing processes in use today. For example, the pictures that we take using KODACOLOR.TM. films (or equivalent ones) are first processed using process C-41 to develop the color negatives. The color negatives are then used with a printer to produce latent images on Kodak EKTACOLOR.TM. paper (or equivalent paper) which are then developed using process EP-2 to produce the color prints.

Color slides such as Kodak EKTACHROME.TM. films are developed using process E-6. Process E-6 is a reversal process which first develops the exposed film using a black-and-white developer. The film is then re-exposed and developed using a color developer, resulting in a positive image. Process K-14 is used for developing color slides on KODACHROME.TM. film. It includes a black-and-white developer followed by re-exposures and three color developers (one for each subtractive primary color) to form a positive image. It is by far the most complex photofinishing process.

Photofinishing is a chemical process that can be characterized by a set of variables, or the chemical and physical parameters. A real-time direct control of the chemical process could be implemented, if thorough feedback, information as to all of the state variables could be obtained at any time. Physical parameters, such as temperature of solution, the amount of time the film is in a solution, the replenishment rate of the solution, etc. can be measured on a timely basis. However, chemical parameters, such as the composition and concentration of chemicals in a processing solution, are very difficult to measure instantaneously and precisely. It seems that real-time direct control of photofinishing processes is beyond the technology available today. Since photofinishing processes are dynamic in nature, the controlling parameters may drift with time with various degrees of severity. Control is further complicated by human factors such as mixing the chemicals, setting the temperatures, etc. A process that once produced excellent pictures may produce pictures that are no longer acceptable. Thus, some way to keep a photofinishing process in control is necessary and this is usually done by human experts through examining the pictures produced. To do this objectively, a filmstrip (commonly known as a control strip 10) that is pre-exposed to different intensities of light under controlled conditions is processed with a customer's work to determine the status of the process. FIG. 1 illustrates a typical control strip 10 for Process E-6. At the top of this control strip, there are three color patches (yellow 12, magenta 14, and cyan 16) which are pre-exposed only to blue, green and red light respectively. These patches provide an easy-eye examination of the quality of the individual color. In the middle of the strip is the "gray" scale; it is a series of patches exposed to increasing intensities of white light. Based on these patches, characteristic curves such as the one in FIG. 2 can be drawn. Usually, characteristic curves are characterized by four points corresponding to four levels (steps) of exposure on the control strip 10. They are the minimum density step (D-MIN), low density step (LD or speed step), high density (HD or color step) and maximum density step (D-MAX). The red, green and blue densities at these exposure levels are read using a densitometer (not shown) and are compared against reference values. The deviations from the reference values are then plotted to monitor the status of the process. FIG. 3 shows typical deviation plots on a color process record form. In this figure, there are a number of solid lines and dotted-line pairs running across the form. The solid lines 28 indicate the aims of the parameters. The closer the plots are to the aims, the better the pictures. For each pair of dotted lines 30, the one that is closer to the aim defnes the action limit. When a parameter moves beyond the action limit, this implies that the process is beginning to get out-of-control and action should be taken to bring the parameter back. The dotted line 30 that is further away from the aim defines the control limit. When a parameter goes outside the control limit, the process is totally out-of-control and processing should be stopped, or unsatisfactory pictures will result.

Using FIG. 3 as an example, when the green speed step 32, plotted on this chart, moved above the action limit at 12:20 on Sept. 5, it was discovered that the underlying cause of the problem was that the first developer temperature was too low. Corrective action was taken to adjust the first developer temperature and the process was brought back under control.

This process of determining the underlying cause or causes is known as photofinishing process diagnosis. To assist processing experts (or novices) in diagnosing process control problems, many control plots are documented showing how each chemical or physical parameter affects the color densities at various exposure levels. FIG. 4 is an example of such control plots and shows the effect of color developer over replenishment.

Since there are many physical and chemical parameters, and each control plot only shows the effect of a single parameter, the control plots are only helpful in a limited way to determine the possible cause (or causes) when, in real life, control problems usually have multiple causes. Over the years, a processing expert develops a set of hunches which are not documented in any way to solve processing control problems. However, these experts are hard to come by and many of them will sooner or later retire and/or leave and take with them their trouble-shooting expertise.

Therefore, it appears helpful to have a computer-aided diagnostic system based on current expert system technology to preserve the process diagnostic expertise and to aid personnel who are involved in photofinishing process diagnosis. Ultimately, such a tool can be made available to people not having any direct involvement or engineering knowledge and no specific knowledge of the underlying expert system technology.

In most areas of artificial intelligence, that branch of computer science which attempts to have machines simulate intelligent behavior, programs fall far short of the competence of humans or even animals. Computer systems designed to see images, hear sounds, and recognize speech are still in fairly early stages of development. However, in one area, that of reasoning or knowledge in a limited domain, computer programs cannot only approach human performance but in some cases they can exceed it.

These programs use a collection of facts, rules of thumb, and other knowledge about a given field, coupled with methods of applying those rules, to make inferences. They solve problems in such specialized fields as medical diagnosis, mineral exploration, and oil well log interpretation. They differ substantially from conventional computer programs because their applications are heuristic rather than algorithmic in nature.

Knowledge systems are computer systems that emulate reasoning tasks by using an "inference engine" to interpret machine readable knowledge stored in a "knowledge base". Knowledge systems are becoming useful for problems that require diagnosis, recommendation, selection or classification. Such tasks have in the past been performed by human experts. It is becoming known that if the domain of the knowledge base, or scope of the problem, is sufficiently narrow and a sufficiently large body of knowledge is properly encoded in the knowledge base, then the knowledge system can achieve performance matching or even exceed the ability of the human expert. In such a case, the knowledge system becomes an "expert system".

There are many expert system-building tools in use today to build expert systems. These tools range from special purpose ones, which are designed mainly for some particular applications, to general purpose ones, which contain a multitude of knowledge representation structures. Many of these tools were developed in universities and research institutes as research tools and have remained as such while some became commercially available, or were developed solely for commercial purposes.

Of the systems in use, there are four general categories, which are rule-based tools, inductive tools, domain specific tools, and hybrid tools. Rule-based tools and domain specific tools are more applicable to the problems and systems developed herein. Domain specific tools are designed specifically to develop expert systems for a particular domain. Therefore, these tools are most effective for the intended domain, but may not be suitable for others. IN-ATE.TM. (trademark of Automated Reasoning, Corp.) is an example of such a tool that learns as it is used. Such an expert system environment is specifically designed for fault diagnosis type of problems; that is, that the program remembers what has failed and automatically readjusts the reliability database and the rules accordingly. It is precisely this learning feature that does not lend itself to such tasks as photofinishing diagnosing of such things as a film processor where many rolls of film may be lost or damaged during the learning cycle.

The present invention uses a rule-based tool as the basic knowledge representation technique, which uses IF-THEN rules. Two types of control strategies are available, namely, forward chaining and backward chaining. Forward chaining strategy starts from the data and works to the conclusion, whereas backward chaining strategy starts from the stated goal and finds the plausibility of the goal by examining the conditions of the goal.

OPS5 is an example of a forward chaining rule base that is a rule-based expert system tool. It was developed at Carnegie-Mellon University as part of the OPS family of languages for expert systems and cognitive psychology. It is characterized by having a global database and condition-action rules programmed in the form of productions which operate on the global database.

The basic (and only) data structure in the global database is called "class", which is equivalent to the idea of a record in procedural languages. Each class has a class name and consists of a number of fields called attributes. An attribute may be either scalar, which contains one atom, or a vector, which contains a list of atoms. There are three types of atoms: symbols, integers, and floating-type numbers. One restriction about class definition is that there may be at most one vector attribute per class. Instances of classes are called elements. Elements can be created, modified, or destroyed through actions which are the basic components of the right-hand side of production rules.

Production rules in OPS5 employ forward chaining strategy. The left-hand side of a production rule describes the conditions under which the rule may be activated. The conditions here refer to the current state of the database. The right-hand side of a production rule describes the actions to be taken when the rule is activated. In general, the actions will affect the current state of the database and thus which rule is to be activated next. The rules can be regarded as independent, parallel processes constantly monitoring the current state of the database and waiting for the conditions necessary for them to become activated. Only one rule may be activated at a given time. When the conditions are met for more than one rule, a conflict is said to occur. OPS5 resolves the conflicts by preferring the rule with more stringent conditions and/or conditions that match elements which are most recently created or modified. (Therefore, each element carries with it a time-stamp, indicating the time it was created or last modified.) After the preferred rule is fired, the state of the database may be changed and all rules have to re-check their conditions again for firing. This is known as the recognized-act cycles in OPS5.

In accordance with the invention, an expert system is provided for use by an expert system user in conjunction with the control of a given photofinishing process comprising a computer having a stored program and memory for storing a knowledge base relation to one or more photofinishing processes. A control strip is used in the photofinishing process to supply densitometric information. The knowledge base includes both factual and judgmental knowledge concerning the photofinishing processes with the judgmental knowledge including judgmental rules. The factual knowledge used includes definitions of densitometric parameters associated with a given photofinishing process. The judgmental rules in the knowledge base include rules having premises referring to causes for out of tolerance densitometric parameters and rules for concluding which parameters were out of tolerance. Built-in control procedures are then executed which can interpret the knowledge base for a specific photofinishing process to determine possible causes for the out of tolerance parameters. Chaining rules associated with a specific photofinishing process are invoked. Means are also provided for terminating the knowledge base search for an unknown value. The judgmental knowledge advice from experts is used to generate attenuation factors associated with all possible causes for the out of tolerance parameter. Where possible cause descriptions may be generated from more than one cause for a given out of tolerance parameter, they will then be merged. A modification factor is then formed, based on possible causes and deviations from a normal range is derived from additional data received from a request for more data. A list of possible causes is then generated along with certainty factors associated with each of the causes listed.

Other objects and advantages of the invention will become apparent upon reading the following detailed description and reference to the drawings in which:

FIG. 1 illustrates a typical control strip of the type used in a photofinishing process;

FIG. 2 is a graph of characteristic curves for film using red, green and blue densities;

FIG. 3 shows a typical deviation plot which make any deviations from the reference values easy to identify;

FIG. 4 is a graph illustrating densitometric effects of color developer overreplenishment;

FIG. 5 shows the logic structure of the diagnostic system for a film process;

FIG. 6 is a partial list of possible symptoms and their conditions for a film process;

FIG. 7 is a partial list of attenuation factors relating to the symptoms and the possible causes for a film process;

FIG. 8 is an example using a diagrammatic representation to illustrate possible causes merging;

FIG. 9 is an example using a diagrammatic representation for certainty factor update;

FIG. 10 illustrates the structure of the expert system tool and how the components relate to each other;

FIG. 11 is a flowchart for the Knowledge Base Editor;

FIG. 12 is a flow chart for the Shell Main Module; and

FIG. 13 is a flow chart for the Expert System Skeleton Module.

Referring to FIG. 1, for the control of a photofinishing process, control filmstrips 10 which are pre-exposed under controlled conditions are processed with the customer's work. After a control strip 10 is processed, a densitometer (not shown) is used to read the red, green and blue densities of various exposure levels to determine the quality status of the process. The densitometric readings of the control strip 10 are then compared against the reference readings to measure the deviations of each color at each density step. When one or more of the deviations are beyond the action limits defined for the process, corrective actions will be taken to bring the process back under control.

To identify the underlying process control problem, process diagnosis experts generally analyze the control strip deviations available to describe the symptoms of the process. The customers' work is examined to verify the symptoms suggested by the control strip 10 that are indeed present in the photofinishing results. Process diagnosis experts also have accumulated knowledge about the possible causes for each symptom and the likelihood of each cause, and they use that knowledge to diagnose the process control problem. Process E-6, which is a reversal process (that is, positive rather than negative images are produced), will be used to exemplify the diagnostic system.

FIG. 5 illustrates the logic structure of the Process E-6 diagnostic system. It uses an evidential approach to diagnosis. It starts from the control strip deviation readings and ends in suggesting the possible causes and their certainty factors through the following six phases:

1. symptoms generation 36;

2. possible causes generation 38;

3. possible causes merging 40;

4. additional data gathering 42; and

5. certainty factors update 44.

The first three phases constitute the hypothesis generation and ordering. The last three phases correspond to the relevant evidential considerations determination in hypothesis evaluation and acceptance.

The control strip for Process E-6 contains 12 denitometric readings, which are the four exposure levels for each of the three colors red, green and blue. The four steps are generally known as the maximum density (D-MAX) step, the high density (color) step, the low density (speed) step and the minimum density (D-MIN) step. These densitometric readings are then compared against the reference readings to find the deviation of each reading. Each deviation is actually a two-digit decimal number less than one. However, the common practice for describing a deviation reading is to read it as a two-digit number without the decimal point. This practice is adopted in the disclosed system.

The diagnostic program also defines and calculates some derived parameters, which are functions of the control strip parameters. The purpose of having these derived parameters is to provide a better description of the status of the process and a convenient way to describe the symptoms.

FIG. 6 is a partial list of the possible symptoms and their conditions. For example, if the average D-max is less than zero, the blue D-max is less than the average D-max, and both the red D-max and the green D-max are greater than the average D-max, one may then conclude that one of the symptoms of this process is a low blue D-max.

In order to describe the severity of the symptom, a certainty factor is assigned to each symptom. The range of a certainty factor is between zero and one, inclusively. This factor is a function of how much the underlying parameters deviate from the aim--the greater the deviation, the higher the certainty. After all the possible symptoms and their corresponding certainty factors are generated, the Process E-6 diagnostic system generates all the possible causes of the symptoms. Each possible cause is associated with a certainty factor. The certainty factor of possible cause depends upon the certainty factor of the deriving symptom and attenuation factor. The values of the attenuation factors are supplied by Process E-6 trouble shooting experts.

FIG. 7 illustrates a partial list of the possible symptoms, the underlying possible causes and the corresponding attenuation factors. For example in the course of diagnosing a control problem, the system deduces from the densitometric deviations that there is a low green red D-max symptom in the process with a certainty factor of 60%. Looking up the attenuation factor for low green red D-max, there are three entries in this partial list. The possible causes that are generated are Color Developer contaminated with the first developer with a certainty factor of 3% (60%.times.5%), color developer pH too high with a certainty factor of 24%, and color developer too much part A with a certainty factor of 30%.

When all the possible causs based on the symptoms are generated, there might be possible causes with the same cause description generated from two or more different symptoms. This implies that the possible cause should be more likely. When such is the case, the possible causes merging phase 40 combines the possible causes with the same cause description together and calculates a new certainty factor for the possible cause using the following certainty propogation formula: CF=CF1+CF2-CF1*CF2.

The properties of this formula are:

1. The new CF ranges between 0 and 1, inclusively.

2. The new CF is a mono-increasing function of CF2 given a fixed CF1, and vice versa.

3. The new CF is greater than both CF1 and CF2.

4. When there are more than two possible causes, with the same cause description to be merged, the ordering of the merge is irrelevant.

FIG. 8 illustrates an example of possible causes merging. In this example, there is low green, red D-max symptom 50 with certainty factor of 60% and yellow color balance symptom 52 with certainty factor of 50%. One of the possible causes derived from low green, red D-max symptoms 50 is color developer pH too high with a certainty of 24%. The same possible cause 54 is derived from yellow color balance symptom with a certainty of 30%. In merging the two possible causes 56 together, we conclude as a possible cause 58 that the developer pH is too high and has a new certainty factor of 47.2% (0.24+0.30-0.24*0.30).

When the generated possible causes can be confirmed or disconfirmed with additional data, the system will prompt the user to provide them. Upon the request of the system to provide additional data, the user can respond with any of the following:

1. Measure and enter the additional data.

2. Question why the additional data are relevant to the diagnosis.

3. Enter "N/A" to indicate that the data is not available.

4. Stop the additional data gathering session.

During an additional data gathering session, the system may prompt the user to enter for example, color developer specific gravity. When the user would question "why" this data is needed, the system would respond with the underlying symptom and the possible cause for the symptom. The user may then enter the measurement for the color developer's specific gravity as 0.040. Subsequently, the user may enter 0.034 for the first developer's specific gravity, "N/A" for color developer replenishment rate, and stop the additional data gathering when the first developer replenishment rate was requested. The user can also re-examine the values of the additional data entered and modify the data if necessary. The additional data that are relevant to the diagnosis are flagged so that the user can take note and enter them later on.

When relevant additional data are available, the system will derive modification factors to adjust the certainty factors of the possible causes generated. The range of the modification factors is between -1 for strongly disconfirming evidence, and 1 for strongly confirming evidence, inclusively.

Given a possible cause with a certain relevant additional data, the modification factor MF is a function of the value of the additional data V, the standard value of the additional value asked, the tolerance of the additional data T, and the direction of the confirming evidence D. The modification factor is derived using the following algorithm:

1. If D is high and V.gtoreq.S+2*T, then MF=1.

2. If D is high and S<V<S+2*T, then MF=(V-S-T)/T.

3. If D is high and V.ltoreq.S, then MF=-1.

4. If D is low and V.ltoreq.S-2*T, then MF=1.

5. If D is low and S>V>S-2*T, then MF=(S-T-V)/T.

6. If D iw low and V.gtoreq.S, the MF=-1.

The properties of the above algorithm are:

1. MF is between -1 and 1, inclusively.

2. MF is a continuous monotonic function of V.

3. If V is opposite to the confirming evidence direction, MF=-1.

4. If V is within the tolerance, MF is negative (disconfirming).

5. If V is beyond the tolerance in the confirming evidence direction, MF is positive (confirming).

Once the modification factors are derived, the new certainty factors can be calculated using the following algorithm:

1. If 0.ltoreq.MF.ltoreq.1, then CF=CF+MF-CF*MF.

2. If -1<MF<0, then CF=(CF+MF)/(1+MF).

3. IF MF=-1, then CF=-1.

The properties of the above algorithm are:

1. CF is between -1 and 1, inclusively.

2. The new CF is a continuous monotonic function of MF and the old CF.

3. CF remains unchanged when MF is zero.

FIG. 9 illustrates an example of a certainty factor update. In this example, the certainty factor of the possible cause of the color developer replenishment being too high is 60%. The standard replenishment rate 62 is 200 ml per square foot. The tolerance 64 is 20 ml per square foot. The direction of confirming evidence 66 is high. Given that the actual value 68 of the color developer replenishment rate is 230 ml per square foot, the modification factor is 50% ((230-200-20)/20). The new possible cause (certainty factor) 70 is thus 80% (0.60+0.50-0.60*0.50). Possible causes for which there is no relevant additional data or whose relevant additional data are not available will have their certainty factors unmodified.

After all the certainty factors of the possible causes have been updated, the system prompts the user to enter the cutoff percentage of certainty factor. Possible causes with certainty factors greater than the user's input cutoff, are displayed to the user in descending order of certainty factors.

FIG. 10 illustrates the structure of the expert system tool and how the components relate to each other. This tool consists of four main components, namely, the Knowledge Base Editor 72, the Data Definition Module 74, the Shell Main Module 76 and the Expert Systems Skeleton Module 78.

In general, Knowledge Base Editor 72 interacts with the Expert System Builder 80 to produce the Intermediate Knowledge File 82. Intermediate Knowledge File 82 contains expert knowledge provided by Expert System Builder 80 (through Knowledge Base Editor 72). This knowledge is in an intermediate formate which can be interpreted by a Shell Program 84 to produce Target Knowledge Base 86.

Shell Program 84 consists of two modules: Shell Main Module 76 and Data Definition Module 74, which primarily is used to interpret Intermediate Knowledge File 82. Shell Main Module 76 contains procedural knowledge (production rules) for interpreting Intermediate Knowledge File 82.

Data Definition Module 74 contains structural knowledge (frame definitions) for generating frame instances in Target Knowledge Base 86 (not yet discussed). A list of frame definitions for Data Definition Module 74 can be found below in the detailed discussion of this module.

Target Knowledge Base 86 contains frame instances required by Expert System Builder 80 as well as desired parameter generation rules, symptom generation rules and possible cause generation rules.

Target Expert System 88 interacts with the Expert System User 90 to require the required data for the diagnosis and the final diagnosis with explanations. It consists of three modules: Data Definition Module 74, Expert System Skeleton Module 78 (not yet discussed), and Target Knowledge Base 86. These three modules are merged together to form Target Expert System 88.

Expert System Skeleton Module 78 contains structural knowledge which utilizes Target Knowledge Base 86 to request data from as well as provide diagnosis and explanations to Expert System User 90.

The Knowledge Base Editor 72, Intermediate Knowledge File 82, Shell Main Module 76, Data Definition Module 74 and Expert System Skeleton Module 78 will all be discussed in greater detail below to provide a better understanding of the system. However, all of these elements could be combined into what is commonly known as a "Knowledge Base".

Intermediate Knowledge File 82 is the first to be created. Intermediate Knowledge File 82 is in some particular syntactic format reflecting the underlying implementation language used. Because of this, assistance to the Expert System Builder 80 is provided through the use of Knowledge Base Editor 72. This Knowledge Base Editor 72 interfaces with the user 90 in a "friendly" way producing the desired Intermediate Knowledge File 82.

Intermediate Knowledge File 82 serves as an input to Shell Program 84 to create Target Knowledge Base 86. Shell Program 84 can be divided into two modules, namely Data Definition Module 74 and Shell Main Module 76. Data Definition Module 74 contains data structures that are common to the expert system building stage as well as the target system consultation stage. Shell Main Module 76 contains routines that use the data structures defined in Data Definition Module 74 to convert Intermediate Knowledge File 82 to a Target Knowledge Base 86. Target Knowledge Base 86 and Data Definition Module 74 are then combined with Expert System Skeleton Module 78 to form Target Expert System 88.

The purpose of Knowledge Base Editor 72 is to provide a user interface and to create and modify Target Knowledge Base 86 of Target Expert System 88. It shields Expert System Builder 80 from the internal design of the knowledge structure and the language(s) used to implement Target Knowledge Base 86. The minimal functionalities of Knowledge Base Editor 72 are as follows:

1. Add new instances to the pre-defined frames.

2. Delete instances of the pre-defined frames.

3. Modify instances of the pre-defined frames.

4. List instances of the pre-defined frame.

5. Provide help facilities to guide expert system builders when necessary.

6. Update the knowledge base at the end of the editing session.

7. Terminate an editing session without updating.

In summary, the output of Knowledge Base Editor 72 is Intermediate Knowledge File 82 which is used as an input to Shell Program 86 to produce Target Knowledge Base 86 of Target Expert System 88. The listing below shows the commands that are available and how the editor may be invoked.

FIG. 11 illustrates the flow chart for Knowledge Base Editor 72, wherein instruction 92 identifies the name of the intended system. This is necessary because Knowledge Base Editor 72 allows Expert System Builder 80 to incorporate more than photofinishing process diagnostics systems. After the process name is identified, instruction 94 retrieves and reads in all the data files that are relevant to the process. There are six data files corresponding to the six types of frames: control strip parameter frames, derived parameter frames, additional data frames, cause & solution frames, conflicting cause pair frames, and symptom description frames. In the event any of the data files do not exist, this step will create the missing data files.

The "get command" instruction 96 prompts Expert System Builder 80 to enter an appropriate command. Instruction 98 interprets the command entered and passes control to the respective command handlers. Valid commands are "a" for adding frames, "d" for deleting frames, "1" for listing frames, "m" for modifying frames, "h" for displacing the help message, "q38 for quitting the editor without updating the changes made and "x" for exiting the editor and updating the changes made. Instruction 100 checks the frame type in the command entered and allows the expert system builder to add new frame instance definitions of the specified frame type. Frame type and the frame number are checked in instruction 96 for the command entered and the specified frame instances definition are delected by instruction 102.

Instruction 104 "list frames" checks the frame type and the frame numbers in the command entered and lists the specified frame instance definitions. Similarly, instruction 106 "modify frame" checks the frame type and the frame number in the command entered and allows the user to modify the specified frame instance definition.

Instruction 108 the "help message", displays the valid commands and syntax for Expert System Builder 80 to interact with Knowledge Base Editor 72. Instruction 110 updates all the six data files according to the changes made by Expert System Builder 80. This instruction also generates a new Intermediate Knowledge File 82 to be used by Shell Program 84. The actual software used in Knowledge Base Editor 72 is listed in Appendex A at the end of the Specification.

The Data Definition Module 74 contains all the common data structure definitions for building Shell Program 84 as well as Target Expert System 88. It includes a number of data definitions to represent the following frames:

Because the photofinishing process monitoring and diagnosis start from the data on the control strip 10, control strip parameter frames are required to represent this data. A control strip parameter frame consists of the following slots:

1. The control strip parameter name slot.

2. The deviation value slot.

The control strip parameter name slot identifies the name of that control strip parameter. This value is to be entered during the target experiment building stage. The deviation value slot contains the densitometric deviation of that parameter from the aim or reference value. It is also to be entered by an end user of the target system during the consultation stage.

The following list contains the twelve control strip parameter frame instances used in Knowledge Base Editor 72. (Note that only the name slots are listed since the values of the deviation value slots are not yet known)

The derived parameter name slot identifies the name of that derived parameter. Its value is to be entered during the target expert system building stage. The following slots are contained in each frame of the derived parameter frames.

1. The derived parameter name slot.

2. The derived formula slot.

3. The parameter value slot.

The derived formula slot describes how the value is to be calculated. The format of this formula is like a typical arithmetic expression relating to the control strip parameter or other derived parameter. Information will be entered in this slot during the target expert system building Stage. The parameter value slot contains the actual value of that derived parameter. It is also to be provided by Target Expert System 88 during the building stage.

The following is a list of four derived parameter frame instances using the Knowledge Base Editor.

Taking the first frame instance as an example, the nameslot has a value of average D-max and the formulat slot indicates that the value of average D-max can be derived by summing up the red-D-max, the green-D-max, and the blue-D-max and then dividing by 3.

As used herein, the additional data refers to the chemical data (such as specific gravity and the concentration of certain chemicals in processing solution) and the physical data (such as temperature and replenishment rate of a processing solution). From the viewpoint of the operation of a photofinishing process, these are the basic parameters in controlling the process. However, from a process diagnostic point of view, this data may or may not be available, and often troubleshooting recommendatins have to be made even in the absence of this data. An additional data frame includes the following slots:

1. The name of additional data.

2. The standard value of the additional data.

3. The tolerance limit around the standard value.

4. The actual value of the additional data.

The additional data name slot identifies the name of the additional value. Its value is to be entered during the target experimental station building stage. The standard value slot identifies the reference operating point of that additional data. Photofinishing process designers usually have recommendations about these reference operating points. However, different processing laboratories may wan to deviate from such recommendations for their own reasons. Thus, Expert System Builder 80 can tailor-make reference operating points by entering the appropriate value during the target expert system building stage. The tolerance slot identifies the operating region of that additional data. Again, photofinishing process designers make recommendations about these operating regions while different laboratories may bent to deviate from such recommendations. The additional data value slot contains the actual value of the parameter. It is to be entered by an end user of the Target Expert System 88 during the consultation stage at the prompt of the system. The following table lists eight additional parameter frame instances using Knowledge Base Editor 72.

Taking the first frame instance as an example, the name slot has a value of first developer time. The standard value slot states that 6 minutes is the standard for the first developer time. The tolerance slot indicates that the actual first developer time should stay within 1 minute around the standard time.

Different photofinishing processes may have different symptoms associated with each one of them. The symptom description frame is used to name the symptom, describe the conditions ascribed to the symptom, and give possible underlying causes of the symptom. A symptom description frame contains the following slots:

1. The name of the symptom;

2. The variable number of slots for the conditions of the symptom;

3. A variable number of slots for the possible underlying causes.

The symptom name slot identifies the name of that symptom. Its value is to be entered during the target expert system building stage. The condition slots are relational expressions relating the control strip parameters and/or the derived parameters of the symptom. These conditions are expressed as relational expressions with an implicit logic term "AND" joining them together. They are to be entered during the target expert system building stage.

The possible underlying cause slots identify the possible causes of the symptom and their corresponding attenuation factors. Thus, each slot actually consists of two sub-slots. The first sub-slot contains the description of the possible cause and the second sub-slot contains the attenuation factor of that cause. Both sub-slots are to be entered during the target expert building stage. The following table lists two symptom description frame instances using the Knowledge Base Editor.

Taking the first frame instance as an example, the symptom name slot has a value of color developer too dilute. There is only one condition slot which states that the condition for the symptom is the average D-max greater than zero. There are six possible cause slots. They are: color developer too dilute, first developer underreplenished, color developer underreplenished, first developer too dilute, first developer and color developer reversed, and first developer omitted with the correspondingly listed attenuation factors.

The cause-solution description frame contains information relating a possible cause to the relevant additional data, the evidence, and the solution in the control problem for that particular cause. A cause/solution description frame includes the following slots:

1. The name of the possible cause

2. The relevant additional data concerning the possible cause

3. The confirming evidence of the additional data

4. The solution prescribed to fix the problem.

The possible cause name slots identifies the name of that possible cause. This definition is to be entered during the target expert system building stage. The relevant additional data slot provides a linkage between the cause-solution description frame and the additional data frame. When a possible cause is generated during a target expert system consultation session as a hypothesis, and if the relevant additional data slot is not empty, the system prompts the end-user to enter the value of that additional data and checks the standard and tolerance slots of the additional data frame to update the certainty of that possible cause. This slot is to be entered during the target expert system building stage.

The evidence slot is an indicator in which direction (high or low) of the additional data deviation from the standard constitutes the confirming evidence. This slot is also to be entered during the target expert system building stage.

The solution slot contains a description of how to fix the problem concerning that possible cause. This slot is to be entered also during the target expert building stage. Referring to the earlier table which contains the listing of seven cause-solution description frame instances and taking as an example the sixth frame instance, the possible cause name slot has a value stating that the color developer is overconcentrated. The relevant data slot indicates that the specific gravity of the color developer is relevant data to this possible cause. The confirming evidence slot shows that a high value of the specific gravity is the confirming evidence. The solution slot suggests that adding water to the color developing may solve the problem.

It is possible that two different symptoms in a photofinishing process control problem point to two conflicting possible causes. Instead of allowing both conflicting causes to be presented to an end-user during consultation, the system identifies the conflicting possible causes and resolves the conflict by weighing the certainty factors associated with these causes. The possible cause with a lower certainty factor for instance, CF1 will be eliminated while the one with the higher certainty factor for instance, CF2 will remain but with its certainty reduced to (CF2-CF1)/1-CF1).

This formula is compatible with the one described in the section on possible causes merging. For example, if CF=CF1+CF2-CF1*CF2, then CF1=(CF-CF2)/(1-CF2) and CF2=(CF-CF1)(1-CF1).

A conflicting cause-pair description frame consists of the following slots:

1. The name of the first possible cause.

2. The name of the second possible cause.

Both slots together identify a conflicting possible cause-pair and they are to be entered during the target expert system building stage.

The following is a list of eleven conflicting cause-pair frame instances using the Knowledge Base Editor.

Taking the first frame instance as an example, color developer overconcentrated and color developer too dilute are two conflicting possible causes. If during the consultation stage, both possible causes are suggested with certainty factors 80 percent and 60 percent, respectively, then color developer too dilute is eliminated while color developer overconcentrated will have a new certainty factor which is equal to 50 percent ((0.80-0.60)/(1-0.60)).

The purpose of Shell Program 84 is to take Intermediate Knowledge File 82 produced by Knowledge Base Editor 72 as an input and produce Target Knowledge Base 86 of Target Expert System 88. Shell Program 84 consists of two modules--1. Data Definition Module 74 contains the definitions of various frames as described earlier; and 2. Shell Main Module 76 contains routines that take Intermediate Knowledge File 82 as an input and generates the Target Knowledge Base 86 of Target Expert System 88.

Target Expert System 88 is the desired output of Expert System Builder 80 using this expert system building tool. It is the program that will be used by end-users for photofinishing process control problem consultation. The following are the requirements for Target Expert System 88:

1. Prompt the end-users to provide control strip parameters. For those control strip parameter instances defined during the expert system building stage, Target Expert System 88 tries to fill up the unknown parameter value slots during the consultation stage.

2. Calculate the derived parameters. Based on the derived parameter frame instances during the expert system building stage, once the underlying deriving parameters are available, Target Expert System 88 will calculate the value of the derived parameters.

3. Generate the symptoms and the possible causes. With the control strip parameter values and the derived parameter values known, Target Expert System 88 will deduce all the symptoms and the possible causes.

4. Prompt the end-users to provide the relevant additional data. When there are possible causes that can be further confirmed or disconfirmed with additional data, Target Expert System 88 will request that data.

5. Generate and propogate certainty factors. As symptoms are generated, possible causes deduced and merged and additional data gathered, Target Expert System 88 maintains the certainty factors and propogates them to the final presentation stage.

6. Provide explanation facilities. During consultation, Target Expert System 88 allows the user to question why certain additional data may be needed or now the system arrived at its conclusions.

7. Present final diagnosis to the end-users. When the diagnosis is done, Target Expert System 88 presents the final diagnosis of the control problem to the end user.

Target Expert System 88 consists of the following three components:

1. The Data Definition Module 74

2. The Target Knowledge Base 86 and

3. The Expert System Skeleton Module 78.

Data Definition Module 74 contains the definitions of various frames, as described earlier. Target Knowledge Base 86 is the output of Shell Program 84 based on the input to Expert System Builder 80. Expert System Skeleton Module 78 contains control structures that use Data Definition Module 74 and Target Knowledge Base 86 to diagnose the presented photofinishing process control problem and to provide explanations to users' questions.

After the design of the logical structure of the photofinishing process diagnostic expert system tool is in place, the next step is to implement the tool. The following description will attempt to incorporate a description of each of the main modules and its function during the implementation phase.

The purpose of Knowledge Base Editor 72 is to provide a convenient interface for Expert System Builder 80 to create and modify Target Knowledge Base 86. The output of Knowledge Base Editor 72 is Intermediate Knowledge File 82. This program is written in C with six input files corresponding to the six pre-defined frames and one output file known as the Intermediate Knowledge File 82.

In Data Definition Module 74, all the pre-defined frames are represented as classes of working memory elements in OPS5. An example of a working memory element definition in OPS5 is as follows (LITERALIZE, CONFLICTING.sub.-- CAUSE.sub.-- PAIR CAUSE 1, CAUSE 2). Using this language, "literalize" is a key word for defining working memory elements; the second member of the list conflict cause pair is the class name; and the remaining members of the list such as "Cause 1" and "Cause 2" are attributes of the working memory element.

FIG. 12 illustrates the flow chart for Shell Main Module 76, which allows Expert System Builder 80 to build up and move one photofinishing process diagnostic system. Accordingly, instruction 112 identifies the name of the intended system.

Because each photofinishing process uses different control strip parameters, instruction 114 is used to diagnose that process. Given the control strip parameters that are required, instruction 116 generates the data structures (frames) for Target Expert System 88 to store the actual values of the control strip parameters. This instruction is also used to guide Target Expert System 88 in acquiring control strip data from Target Expert System User 90.

Often times, it is helpful to examine the overall bearing of a group of control strip parameters rather than individual ones. Derived parameters refer to the tendency or trend of these groups of control strip parameters. Instruction 118 has the expert system builder provide the names of such derived parameters, as well as how these derived parameters can be calculated from the control strip parameters and other derived parameters.

Given the drived parameters that are required, the instruction 120 generates the data structure (frames) for Target Expert System 88 to store the actual value of the derived parameters. With the names of the derived parameters already entered and how they can be calculated, instruction 122 generates production rules for Target Expert System 88 to compute the values of these derived parameters.

Because additional data associated with the mechanical and chemical parameters are useful in diagnosing a photofinishing process, the quality of the diagnosis depends on this data, which data may or may not be readily available. Instruction 124 identifies the names of this additional data, their standard values and their tolerance limits. Instruction 126 generates the data structures (frames) for Target Expert System 88 to store the actual values of the additional data. These frames will also be consulted during diagnosis by comparing the actual values against the standards and the tolerance limits.

With symptoms being the characterization of the problems of the photofinishing process, instruction 128 identifies the names of various symptoms, how they relate to the control strip parameters and the derived parameters, as well as the possible underlying causes and their respective likelihoods. Instruction 130 generates the data structures (frames) describing the symptoms for the target expert system to consult during diagnosis. Instruction 132 generates production rules for Target Expert System 80 to deduce the symptoms in the process based on the actual values of the control strip parameters and the derived parameters.

Instruction 134 generates production rules for the Target Expert System 88 to deduce the possible causes and their respective likelihoods based on the actual symptoms deduced.

Instruction 136 identifies the names of all possible causes, the additional data and confirming evidence relevant to the determinates of these possible causes, as well as the prescriptions to solve the problems. The data structures (frames) are generated by instruction 138 describing the possible causes for Target Expert System 88 to consult during diagnosis. Instruction 140 can then identify the possible causes that conflict with one another.

Finally, instruction 142 generates the data structures (frames) describing such conflicting cause-pairs for Target Expert System 88 to consult during diagnosis.

The actual software used in Shell Main Module 76 are listed in Appendix B at the end of the Specification.

Shell Main Module 76 is also written in OPS5. Its function is to read Intermediate Knowledge File 82 and create Target Knowledge Base 86. This is done in the following six phases:

1. Generate the control strip parameter frame instances.

2. Generate the derived parameter frame instances and the corresponding value deriving production rules.

3. Generate the additional data frame instances.

4. Generate the symptom description frame instances, production rules for determining the symptoms from the conditions, and production rules for deducing the possible causes.

5. Generate the cause-solution description frame instances.

6. Generate the conflicting cause-pair description frame instances.

The first, third, fifth and sixth phases are very similar and straightforward. A typical frame instance that is generated is as follows: (CONFLICTING.sub.-- CAUSE.sub.-- PAIR CAUSE1 6 CAUSE2 18).

In the OPS5 language, this is an instance of a working memory element with conflicting.sub.-- cause pair being the class name, cause 1 and cause 2 attibute types, and 6 and 18 the contents of the attributes of indices pointing to the cause descriptions.

In the second phase, besides generating the derived parameter frame instances, production rules for deriving the values of parameters are also generated. The following is a typical example of such a production rule:

In OPS5, the "P" is a key word to denote a production rule, the identifier "G:1" is the rule name. Each rule name has to be distinct, and the "G:1" is formed by using the built-in function genatom, which generates a distinct atom every time it is called. The next five lines are the conditions for the rule trigger. The last line is the action to be taken when all five conditions are met.

In other words, the first condition states that the state of the target system has to be in the derived parameter calculation mode. The second condition states that there exists a derived parameter frame instance (AVE.sub.-- D-MAX) whose value slot is known. The third to fifth conditions state that the components for calculating for the AVE D-MAX are availabilites of the RED.sub.-- D-MAX, the GREEN D-MAX, and the BLUE.sub.-- D-MAX. The action is to calculate the average value of the RED.sub.-- D-MAX, the GREEN.sub.-- D-MAX, and the BLUE.sub.-- D-MAX to form the AVERAGE D-MAX.

In the fourth phase, besides generating the symptom description frame instances, production rules for generating systems are also constructed. The following is a typical example of such a production rule.

In this example, the condition of the symptom is that the AVERAGE D-MAX is less than zero while the RED.sub.-- D MAX and the BLUE.sub.-- D-MAX are both less than the AVERAGE D-MAX. The action is to generate a symptom of low GREEN.sub.-- D-MAX.

Also in the fourth phase, production rules for generating possible causes are also constructed. The following is a typical example of such a production rule.

The meaning of this example is that when there is a symptom of LOW GREEN D-MAX, then the possible causes are those that the indices 45, 6 and 24 are pointing to with the certainty factors of 0.50. 0.40, and 0.10, respectively.

FIG. 13 illustrates the flow chart for Expert System Skeleton Module 78. The program begins with the "acquire control strip data" instruction 144 which causes the computer to examine the control strip parameter frame instances in Target Knowledge Base 86 and prompts Target Expert System User 90 to provide the control strip data required. Instruction 146 examines the derived parameter frame instances in Target Knowledge Base 86 and calculates the values of the derived parameters using the actual control strip data and the derived parameter value calculation rules in Target Knowledge Base 86.

The symptom determination rules in Target Knowledge Base 86 are examined per instruction 148 which also generates the symptoms of the process base on the actual control strip data and the derived parameter values. Instruction 150 results in the generation of the possible causes determination rules in Target Knowledge Base 86 which results in the generation of the possible causes and their respective likelihoods of the process problem base on the symptoms derived. Instruction 152 merges common possible causes generated from different symptoms and increases the likelihood of such possible causes.

The "resolve conflicting causes" instruction 154 examines the list of possible causes generated and checks them against the conflicting cause-pairs in Target Knowledge Base 86. If there are such conflicting pairs, it eliminates the less likely possible causes and reduces the likelihood of the more likely possible causes. The next step, instruction 154 examines the list of possible causes generated and checks the cause-solution frames instances in Target Knowledge Base 86. If there are relevant data associated with the possible causes, it prompts Target Expert System User 90 via instruction 156 to provide such information.

The "update certainty factors" instruction 158 reviews the values of the additional data provided by Target Expert System User 90 to adjust the likelihoods (certainty factors) or eliminate possible causes. Instruction 160 presents the final diagnosis of the process to Target Expert System User 90.

The actual software used in Expert System Skeleton Module 78 are listed in Appendix C at the end of the Specification.

Expert System Skeleton Module 78 uses the frame instances and the production rules generated in Target Knowledge Base 86 to help end-users solve photofinishing process control problems. This is done in the following four phases:

1. Acquire control strip data and calculate derived parameters.

2. Generate and merge possible causes followed by conflicting causes resolution.

3. Acquire additional data and update certainty factors.

4. Present the final diagnosis.

The first phase prompts an end-user for the control strip parameter values, and, after all the control strip parameter values are available, it uses the derived data production rules to calculate the derived data parameter values.

The second phase uses the symptom condition production rules to find out all the symptoms in the process. Once all the symptoms in the process are found, the system uses the possible cause production rules to find the possible causes. Then it combines possible causes that have the same cause description to form new (higher) certainty factors and/or uses the conflicting cause-pair description frames to form new (lower) certainty factors.

The third phase uses the relevant additional data slot in the cause-solution description frame instances to prompt the end-user to enter the relevant additional data value. In the event that the user questions why the additional data is needed, it uses the linkage between symptom and possible causes frames to provide the answer. It then uses the standard value and tolerance slots of the additional data frame to update the certainty factors of the possible causes.

The last phase displays all the possible causes generated one by one in descending order. In the event that the end user questions how the system arrives at its conclusion, it uses the linkage between symptoms and possible causes frames to give the answer. If the end-user asks for the prescription of the problem solution, the system uses the presription slot of the cause-solution description frames to give the advice. The following Tables A and B show a typical consultation session of a target expert system.

In this example, when Target Expert System 88 was evoked by entering "run e6" the system responded by requesting the 12 control strip parameters for Process E-6. After the 12 readings were gathered, the system started diagnosing. A diagnosing process includes derived parameters, calculation, symptoms generation, possible causes generated, possible cause merging and conflicting cause resolution. These steps were not listed so as not to overburden the end-user with unnecessary details. After all possible causes are generated and merged, and the conflicts resolved, the system will prompt the user to enter any relevant additional data. The system first requests a color developer specific gravity. As a result of a "help response", the system will explain what the possible choices of action are. When the end-user asks why the color developer specific gravity was needed, the system will respond with the explanations. Subsequently, the user enters 1.04 for the color developer specific gravity, and 1.034 for first developer specific gravity, not available for first developer replenishment rate, and stops the additional gathering session when the color developer replenishment rate is requested.

The system then presents the diagnosis with color developer pH low as the most likely cause (80 percent certainty). When the end-user asks how the conclusion was arrived at, the system provides the explanations. The system may then present a few more possible causes and finally, the consultation will be terminated when the end-user enters "end".

The actual software used in Knowledge Base Editor 72 and Data Definition Module 74 are listed in Appendices D and E respectively.

The programs shown in the Appendices all run under the VAX/VMS.TM. Operating System of Digital Equipment Corporation. The Shell Main Module 76, Data Definition Module 74 and the Expert System Skeleton Module 78 are written in OPS5; the Knowledge Base Editor 72 is written in C; and the input/output utility module is written in FORTRAN.

While the invention has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications, and variations will be apparent to those skilled in the art in light of the foregoing description. Accordingly, it is intended to embrace all such alternatives, modifications, and variations as fall within the spirit and scope of the appended claims. ##SPC1##