PDF hosted at the Radboud Repository of the Radboud University Nijmegen The following full text is a publisher's version. For additional information about this publication click this link. http://hdl.handle.net/2066/112345 Please be advised that this information was generated on 2021-04-06 and may be subject to change. http://hdl.handle.net/2066/112345 Analytrca Chwnrca Acta, 235 (1990) 21-40 Elsevler Science Pubhshers B V , Amsterdam - Pnnted m The Netherlands 21 Expert system for precision testing in validation of liquid chromatographic methods J A VAN LEEUWEN *, L M C BUYDENS, B G.M. VANDEGINSTE a and G. KATEMAN Department ofAnalytrca1 Chemrstry, Cathok Unrversrty of Nqmegen, Toernooweld, 6525 ED NrJmegen (The Netherlands) M MULHOLLAND Fhlhpps S’crent$c, CambrIdge, CBI ZPiY (Great Bbtarn) (Received 3rd July 1989) ABSTRACT After a hquld chromatographlc method has been developed, It must be vahdated to estabhsh its imutations in daiiy use Method vahdatlon LS becommg increasingly Important as stncter rules are applied by regulatory authontles. Precision testmg 1s a vltai step m thus vahdatlon; both mtraIaboratory testmg and- mteriaboratory testing are needed. iii an mtralaboratory test, repeatability and ruggedness tests are usually done Expert systems are available for both tests Here they are integrated to form an mtralaboratory precision-testing expert system, special mtegratlon archtecture 1s described Important features of the integrated system are a supervlsor contammg planning knowledge about the tests and a common data structure contaming all the objects necessary for an expert system in this area Many applications of artificial intelligence in analytical chemistry have been described recently [l-5]. Although the types of knowledge vary, most applications are found in expert systems for spec- tral interpretation (infrared, ultraviolet, mass or NMR) or elucidation of chemical structures [2-51. The expert system described here was developed as part of a project (Esprit project 1570) that evaluates the use of expert systems in the develop- ment of liquid chromatographic (LC) methods [6]. In this project, method development 1s divided into four domains: first guess of conditions, selec- tion of criteria for optimization [7], optimization of instrumental parameters and operating condi- tions [B] and validation of the method [9-111. In this paper, the structure and implementation of the validation part is described. When a full validation program is run, the five features of performance tested are the accuracy, a Present address Umlever Research, Vlaardmgen, The Netherlands 0003-2670/90/$03 50 0 1990 - Elsevler Science Publishers B.V preclslon, sensitivity, selectivity and limitations of the method. Because a full program for method validation involves testing in different laborato- ries, it would be of little use to try to tackle the entire validation in one expert system, as it would be very difficult to control expert systems located at different sites. The size of such a system would also become very large. Therefore the method validation 1s tackled m parts. The expert system described here is concentrated on precision tests that can be done in the laboratory where the LC method 1s developed. It 1s intended to gve the analyst validating the method as much certainty as possible that this method will not fall m a col- laborative mterlaboratory test. For most analysts in a routine laboratory, the performance of a precision test is not stra&tfor- ward. Decisions must be made about which tests to apply, the extent of each test and the accepta- bility of the results. If a method falls the test, it is also necessary to specify the method again, with consideration of the problem that led to its failure. 28 J A VAN LEEUWEN ET AL Expert systems that advise on parts of the prob- lem of precision testing are available [9,10]. For an analyst to use these systems most beneficially, the basis of the test procedures and their relations to each other must be known. An integrated system based on extstmg systems would eliminate this requirement. An integrated system mvolves several modules of a heuristic as well as an algorithmic nature. Integration of modules with different problem- solvmg techniques, like calculations and produc- tion rules, requires a flexible arcluteture, m whtch the different modules are connected so that they can exchange as much information as possible. It must, for instance, be possible to have modules implemented in the usual techniques for expert systems as well as modules implemented in spreadsheet packages and normal programming languages like C. In prmciple, the architecture should not enforce too many constraints on the structure and implementatton of the modules be- cause this would damage their performance. Espe- cially in this study, where new modules are in- tegrated with existing expert systems, tt is tm- portant not to change the existing systems too much and not to place too many restricttons on the new modules. A feature of the design for mtegratton described here 1s the development of a kmd of backbone for LC expert systems, a data structure that can serve as a basis for many dtffer- ent expert systems on vahdation of LC methods. A framework of concepts describing the basics of LC can be accessed by every module m the in- tegrated system. The ObJects in the common data structure are represented formally on paper so that they can be implemented in any suttable technique for expert systems or in any program- mmg language. By using the common data struc- ture and the modules as budding blocks, an expert system is built on mtralaboratory precision test- mg. Because of tts modular structure, the separate parts of the system can be activated indepen- dently. The system also contains planning knowl- edge on when to activate which module. The repeatability test and the ruggedness test are the mam parts of the integrated system. These tests were developed independently in trials in- volvmg several experts. ‘The integrated system contains the integrated knowledge of these ex- perts. Thts is a typical feature of so-called second-generation expert systems, which contam the knowledge of more than one expert, apply different inference techniques in different parts of the system, and can also select the next part of the system to be consulted. The so-called blackboard architecture is suitable for the implementatton of such systems [12]. PRECISION TESTS The purpose of a precision test is to establish the random devtation from the mean in a certain analysis. Precision testing normally consists of re- peatability and (interlaboratory) reproducibility tests [13]. In a repeatability test on a method, the same sample 1s analyzed (usually 10 or 25 times) under the same conditions by the same analyst. Because the test site does not change, a repeatabil- ity test normally does not require much manpower and time. In contrast, reproductbthty tests are relatively costly; identical samples are tested in different laboratories to examine the precision of the method under slightly changing condittons. To avoid excessive problems during a reproducibility test, a ruggedness test can be added to the preci- sion test [14]. In a ruggedness test, the effects of changing parameters such as temperature, accu- racy of the analyst, etc., are simulated, so that the likely performance of a method m a reproducibil- ity study can be assessed. Possible problems can be identtfted and resolved before the actual repro- ductbthty test. Especially in LC, a large number of factors may mfluence method performance. A ruggedness test on the right factors can greatly reduce costs during a reproducibility study and can be apphed in the laboratory where the method was developed, like the repeatability test. A repeatability test combined with a rugged- ness test can be seen as an m-house precision study. This type of testing 1s advisable for every method that 1s destined for general use. However, ruggedness tests are rarely done; even repeatabil- ity testmg IS not yet part of many standard operat- mg procedure, probably because of lack of experi- ence m many routme laboratories. EXPERT SYSTEM FOR PRECISION TESTING IN VALIDATION OF LC METHODS 29 Stand-alone expert systems Previous work was aimed at the development of expert systems that could advise on parts of the problem of preciston testing. For instance, expert systems on repeatability testing [9] and on choice of factors in ruggedness testing [lo] have been developed. The latter system has been developed further to provide a complete system for rugged- ness testing. Both systems are described briefly below. The repeatablkty system. The repeatability sys- tem advtses the user on the performance of repeat- ability tests on the injection and sample prepara- tion of the LC procedure. The results of the re- peated experiments are processed to see if the method is repeatable within the specified limits, i.e., the (relative) standard deviations are calcu- lated and interpreted. If a problem with the method is indicated, the system diagnoses the problem and proposes remedies. The repeatability system contains three mod- ules, which cover the set-up of the test, mterpreta- tion of results and diagnosis cure. On the basis of a description of the method, the system selects a repeatability test for the inlection and sample pre- paration procedures and provides a description of the experiments to be done. The spreadsheet structure of the second module allows input of the experimental results; the relative standard devia- tions are calculated and assessed for acceptability. If they are acceptable, consultation stops. If they are not, possible causes of the error are diagnosed and if the problem can be identified, the system advises on possible soluttons, e.g., check for ade- quate degassing or for a loose grating in the detec- tor. The first and third modules are implemented m a commercial expert-system shell; they contain mainly heuristic rules and frames to represent the objects in the system. The second module is tmple- mented m a spreadsheet package because it is more algorithmic m nature and mostly concerns calculations. The ruggedness system. The ruggedness system advises the user on a complete test, from selection of factors to interpretation of results. A rugged- ness test consists of various experiments that simulate the changes to be expected when a method is transferred from one laboratory to another. / Common Datastructure Fig 1. The ruggedness system Because the number of possible influencmg fac- tors IS large (about 40), the test must be efficient. If most of the interactions between factors can be neglected (which is normally a realistic assump- tion), the most efficient experimental design is a fractional factorial design. But even when factorial designs are used, the number of possible factors is too large, so that the important factors must be selected. The use and interpretation of experimen- tal design require experience winch is not com- monly available in routine laboratories. The ruggedness system is designed to eliminate the problems that prevent ruggedness testing from being part of a normal procedure for method validation. Various modules advise on the differ- ent steps in the ruggedness test (Fig. 1). First, the user enters a descnption of the LC method, which should include only the facts necessary for rugged- ness testing. The system then advises on which factors to test; this is done on the basis of the input description and the requirements specified by the user (e.g., the expected usage of the method). If the user wants to change, add or delete any factors in the output advice, this is stored by the system and the user is warned that modifications have been made. When the set of factors selected by the system has been accepted by the user, the system selects an experimental design for the test; the number of experiments is usually 8-32. After the experiments have been done and the results have been put m, the interpretation module pro- duces either suitability criteria or main effects. Mam effects indicate that there are problems with the method; the system indicates if the problems are serious enough for rejection of the method. Normally, the user is only warned that certain 30 J A VAN LEEUWEN ET AL factors should not vary too much or that certain parameters are not reliable. As in the repeatability system, heuristic and algorithmic processes are used in the ruggedness system. The heuristic processes are implemented in an expert-system shell; the selection of factors and the selection of designs are rule-based. Inter- pretation of the experimental results is imple- mented m C language. The diagnostic module 1s implemented in an expert-system shell wtth frame-based reasoning. INTEGRATION OF THE SYSTEMS Integration of the repeatabihty and ruggedness systems mvolves the development of several new items and the adaptation of some parts of the separate systems. It is vital for all modules of the integrated system to use the same concepts as the basis for reasoning, so that flexible communica- tion is possible between the various modules. Communication between modules in a system can often be done by simple transfer of files, but such communication would be insufficient here. For an integrated expert system, most of the facts pro- duced by one module must be available to all other modules m the system. It is also important that the modules are not consulted in a standard sequence. If a file-transfer system were developed for tlns integration, all possible consultation se- quences would have to be implemented, winch would become unrealistically complex. If all modules in the system must use the same concepts for reasoning, it is better to merge all existing concepts in one common data structure that forms the basts for all systems. In tins study, the common data structure 1s built as a black- board structure; all the modules of the integrated system can read information from and wnte infor- mation to tins structure. The blackboard architec- ture was chosen because it allows integration of modules which use different mferencing or prob- lem-solving techniques. This approach has some consequences for the user interface of the separate systems. If the user mterfaces were not changed, the integrated system would somettmes ask for the same information twice, if the information were important for more than one module. When the information is available in the common data struc- ture, a new module for method description must replace the separate modules of the stand-alone systems. In the architecture proposed here, this is the only essential adaptation of the existing sys- tems. The integrated system needs a supervisor to decide when to consult which module. The super- visor contains knowledge on each module, its in- put variables, its output variables and its status. On tins basis, the supervisor decides which route should be taken to find an efficient precision test. With the supervisor, a level of meta knowledge (knowledge about the expertise in the system) is introduced into the system. Only the supervisor can trigger the modules; the modules cannot tng- ger themselves or each other. Because of the lnerarchical control structure, it is relatively easy to implement additional levels of control, e.g., to integrate other tests like accuracy and sensitivity. The method description module, the common data structure and the supervisor are the new items in the integrated system (Fig. 2). Adaptation of the extsting systems to the common data struc- ture and the method description module requires only minor changes. In future, new modules can easily be added if they use the concepts of the common data structure. Method descnptlon In this module, a full description of the LC method to be tested can be entered. The module contams knowledge on winch LC methods can be assessed by the system. The method description module is normally the first to be consulted, thus the user is confronted with the limitattons of the system at the start. If the system accepts the descnptron of a method, the user can be confident that a valid consultation has been started and a valid conclusion will be reached. The only excep- tion is when a very incomplete method description 1s provided. Normally, the system can work with an mcomplete method description but tf much information is missing, the system may not reach valid conclusions. The point at whtch the system loses its full validity is believed to be when 30% of the method description is missing. EXPERT SYSTEM FOR PRECISION TESTING IN VALIDATION OF LC METHODS 31 The system contains knowledge about the nor- tion that he is not asked to enter. This is done by ma1 concepts of an LC method. The user is not filling areas in the method description that are not asked for any feature of the method that is not in filled by the system. Volunteering mformation is lme with previously given answers. For example, if not always advisable. If the system does not need a diode-array detector is involved, the user will be certain mformation it may have good reasons. asked for wavelength, time constant and attenua- Information volunteered at the wrong place may tion. When a refractive index (RI) detector is confuse the system and mvalidate its conclusions. specified, the user will be asked the RI range and Another feature of the method description the temperature of the detector. If a column ex- module is the guidance given to the user to ensure traction is specified for sample preparation, the that the description contains all the information wash volume and the extraction volume will be relevant for the particular consultation. The sys- needed. When a filtration is specified, the pore tern will not ask for more mformation than it size of the filter will be required. However, the needs. If, durmg a consultation, it becomes clear user can overrule the knowledge in the system by that only a repeatability test is necessary, the user volunteering information. At any time during the will only have to spectfy a few parameters of his method descriptton, the user can enter mforma- method, mainly related to the expected usage of I ” V V V V v v v 1 Common Datastructure I L I Fig 2 The preas~~~ expert system 32 J A VAN LEEUWEN ET AL the method. If a ruggedness test is necessary, many more features are required. Of course, when a ruggedness test follows a repeatability test, the information produced during the first test remains available for the second. Fmishing the method description defines the basis for the following consultation. The system will ask for further information if necessary but the user cannot change hts method description after leaving the method description module. If changes are essential, a new consultation must be started. Common data structure The basis of every expert system is a descrip- tion of the objects about which it can reason. All necessary objects must be described in such a way that misinterpretation is impossible. In this case, all objects are represented in a network of frames. An object is described by giving a frame the name of the object and defining a list of all the relevant properties of the object. Every property has a number of possible values which are also defined m the frame. For every object, a so-called O(bject) A(ttribute) V(alue) tnplet is created. A typical LC object is a column, which is easily described in a frame (see Table 1). The column is defined by properties (attributes) like length, particle size, functionality, internal diameter, etc., each of which has several possible values. For functionality, for example the list including ODS, nitrile, C8, C18, etc. For column length, the range may be between 2 and 100 cm. The different objects in a knowledge domain are related. For instance, the object “LC method” has parts like sample preparation, column and detector. Relations between objects can be of a general nature common to different knowledge domams. The definitions of general relations are normally provided by the expert/system shell. A particularly useful example of a general relation between ObJects is “inheritance”. Inheritance al- lows division of frames into more specific sub- frames; its use implies that all attributes present in a general frame will always be attributed in the subframes, i.e., subframes inherit certain attributes from the more general frame. An example of the use of inheritance m representing relations be- TABLE 1 Example showmg the mformation m a frame for a column Object Attnbute 1 value 1.1 value 1 2 Attnbute 2 value 2 2 value 2 2 value 2 3 Column Tradename: Sphensorb, Hypersil, Nucleostl, Part&, pBondapak, Ltchrosorb Functionahty. C8, Cl& SI60, ODS, Nttnle, Phenyl, PAC Particle size (pm), REAL Column length (cm): REAL Batch number: INTEGER Internal diameter (mm) REAL Column I Tradename. Lichrosorb Functtonahty. ODS Particle size 4 Column length: 20 Batch. 23475435 Column 2 Tradename. pBondapak Functtonahty. Cl8 Particle stze 5 Column length 30 Batch 3498745678 Internal diameter 4 6 Internal dtameter: 4 tween LC objects can be seen in the description of a detector (Table 2). Here, a detector has only two properties: it is always of a certain type (UV, RI or diode array) and it always has a time constant. Real detectors have other properties that place them m a subclass of detectors, e.g., a UV detector will have a wavelength property that distinguishes tt from a RI detector. The UV and RI detectors are thus subframes of the detector frame. Another useful general relation is instantiation, whtch means specifying the exact feature of an TABLE 2 Example of mhentance detector Detector Type. vanable UV, fixed UV, diode array, refracttve mdex Ttme constant (s) REAL (IV detector Wavelength (nm) REAL Attenuation REAL RI detector RI const . REAL Temp (O C): REAL Range htgh, low UV detector 1 Type vanable UV Ttme constant: 0 5 Wavelength. 276 Attenuation 0.1 EXPERT SYSTEM FOR PRECISION TESTING IN VALIDATION OF LC METHODS 33 example. Defining a frame means the introduction of a certain concept mto the common data struc- ture. During a consultation, a specific example of the concept will be defined. An instantiation of a frame has only a subset (normally one) of the possible values for each attribute. Examples of instantiation can be seen in Tables 1 and 2; in- stantiations define so-called u-a relations, e.g., in Table 1, column 1 u-a column. Because mstantia- tions are created during a consultation, they are not part of the common data structure, because they are deleted after each consultation. Figure 3 summarizes all the objects and their general rela- tions in the common data structure. Inheritance enables a network of relationships between objects to be defined. There are, however, other types of relations in the knowledge domain that cannot be described with the inheritance con- cept, e.g., relations between attributes. Such rela- tions can be defined explicitly by a functional SAMPLE TOP FRAME METHOD ~~;AMT;'AF$iTION COLUMN DETECTOR CHROMATOGRAPHIC RESULTS USER REQUIREMENTS I Top. )ESCRIPTION FRAME- I I I FACTOR OPERATOR FACTOR EXP-DESIGN-INFO NUMERICAL FACTOR DISCRETE FACTOR TOP FRAME DIAGNOSE FRAME TOLERANCES STANDARD ERRORS CONCLUSIONS CONCLUSIONS MAIN EFFECTS FACTOR IDENTIFICATION FACTOR GROUPS DIAGNOSE INFORMATION SYSTEM SUITABILITY CRITERIA TOP FRAME REPEAT FRAME PARAMETERS PRECISION TEST VARIABLES SPREADSHEET REPEATABILITY DIAGNOSIS I METHOD VARIABLE REPEATABILITY TEST Ftg 3. Objects tn the common data structure 34 J A VAN LEEUWEN ET AL relationship, in which the names of the attributes are mcluded with the nature of the relationship between them. An example of a functional rela- tionship is the definition that the description of a sample preparation cannot include the attributes shake (mm) and sonicate (mm) simultaneously, because it is unnecessary to use both sonication and shaking in one procedure. The functional relationships are usually of a more complicated and specific nature than the general relations, and are defined in the language of the expert system, e.g., Lips. This makes them less comprehensible and flexible than the general relations but a func- tional relationship is used only once or twice so that generalization is unnecessary. The objects and relations together form the common data structure, which contains much knowledge about LC and method validation. Be- cause it is impossible to change the objects and the relationships during a consultation, the com- mon data structure is the static backbone of the system. The common data structure developed for this expert system provides a basis for a complete description of a procedure for method validation m LC, and could easily be extended for another LC application. Supervisor The supervisor contains the knowledge on when to activate which module. This meta knowledge represents the knowledge of a manager who de- cides which tests are necessary and when they should be done. The decisions of the supervisor are not much related to the activities of the mod- ules. The supervisor only needs information on the mput and output parameters of every module and some mformation from the method description module. At the moment, the supervisor knowledge is represented m rules (Table 3). The rules act on a simple separate frame, the scheduler (see Fig. 2). The modules cannot operate on this scheduler frame. In the scheduler, information is stored about the state of the modules. This structure is capable of handhng the knowledge for the preci- sion-testing system with its eight modules. Because the amount of information stored in the scheduler will become very large when more modules are TABLE 3 Rules m the supervtsor (DEFINE-RULE PRECISION TEST 3 ( doe-string “general rule 100 10-12-87” sponsor select-test-sponsor) (INSTANCE ?user ts user-requuements WITH lab-number 1 OR 2) THEN (INSTANCE PREC-TEST IS TEST WITH GLOBAL PERFORMANCE CHARACTER- ISTIC PRECISION WITH CONTRIBUTORY CHARACTERISTIC REPEATABILITY WITH CONTRIBUTORY CHARACTERISTIC RUGGEDNESS)) (DEFINE-RULE PRECISION TEST 2 ( do-c-stnng “general rule 110 10-12-87” .sponsor select-test-sponsor) (INSTANCE “APP IS APPLICATION WITH lab-number 1 or 2) THEN (INSTANCE PREC-TEST IS TEST WITH GLOBAL PERFORMANCE CHARACTER- ISTIC PRECISION WITH CONTRIBUTORY CHARACTERISTIC REPEATABILITY)) (DEFINE-RULE PRECISION TEST 1 ( dot-stnng “general rule 120 10-12-87” :sponsor select-test-sponsor) (INSTANCE ‘kser ts user-requuements WITH analyst-number 1 WITH mstrument-number 1) THEN (INSTANCE PREC-TEST IS TEST WITH GLOBAL PERFORMANCE CHARACTER- ISTIC PRECISION WITH CONTRIBUTORY CHARACTERISTIC REPEATABILITY)) added, the supervisor is being extended to include more frames and an additional so-called task level between the modules and the planning knowledge. Archrtecture of the system A complete precision testing expert system can be constructed with the building blocks described above. The system is based on the common data structure of frames that represent all the physical and mental objects necessary for a precision test, i.e., descriptions of the sample, method, tests, re- sults and diagnosis. Working on the framework are the modules that each contain knowledge on a EXPERT SYSTEM FOR PRECISION TESTING IN VALIDATION OF LC METHODS 35 certain part of the test procedure. The modules commumcate through the common data structure by placing variable values in it and reading from it. Direct cont.act between modules (e.g., for com- munication of vanables shared by them) is not possible, thus the supervisor can keep track of all activities in the system. The supervisor can see wluch modules can be tnggered at a certain mo- ment because it contains a list of the input and output parameters of all modules. A module can be activated only if all its input parameters are known; it will be deactivated only when all its output parameters have been established. The supervisor acts as a kind of switchboard operator connecting modules to each other accord- mg to the state of the system at a certain moment. The supervisor also contains knowledge on the priority of the modules if a situation occurs where more than one module can be activated at the same moment. Thus the supervisor decides on the best scheme to follow, usmg its meta knowledge. Comparrson with a blackboard At first sight, the architecture described above resembles blackboard architecture [12]. Black- boards are well known artificial-intelligence tech- mques for the integratton of expert systems. Blackboard architecture also uses modules (knowl- edge sources) that can communicate with each other only via a framework of objects, the black- board (see Fig. 4). However, in blackboard archi- tecture, the knowledge sources trigger themselves when the state of the blackboard is such that they can contribute to the solution of the problem. The scheduler then decides which of the knowledge sources can be activated. In an ideal situation, several knowledge sources can be activated at the same time. The blackboard architecture offers possibilities for parallel processing. The scheduler therefore does not contain any planning knowl- edge. In the architecture used here, the supervisor calls up the modules that can add to the solution of the problem. The scheduler frame contains all the conditions for activating the modules, and this allows the implementation of planning knowledge about the activation of the modules. Recently, the literature on blackboards has shown a shift to- r-l blackboard global database Fig 4 Blackboard archtecture wards the implementation of planning knowledge similar to that used here. An example of such a blackboard was described recently [ 151. In principle, the architecture used here does not allow processes to run in parallel unless they are specified as possible simultaneous processes. For the application of precision testing m LC method vahdation, however, this is not (yet) a disad- vantage. PROGRAM FLOW Consultation of the system normally starts with specifying the needs of the user (Table 4A). The appropriate modules are then loaded by the sys- tem. In a complete consultatton, all modules are loaded from initial method description to diagno- sis of the ruggedness test. In the method descrip- tion module, the user can enter all the information that he has on the method (Table 4B). The super- visor then decides, on the basis of the expected usage, which tests are needed (repeatability, ruggedness or both). This information ts transferred to the scheduler frame, which decides on the next step. In general, it will be a repeatability test and the system will activate the relevant module, which uses mforma- tion about the expected usage to select a suitable test. It also activates a spreadsheet in which the 36 J A VAN LEEUWEN ET AL test is implemented. After the user has done the and advise on their acceptability, etc. (see above). test and entered the results, the expert system The same procedure applies when the rugged- activates the next module to diagnose the results ness part is activated. Normally, ruggedness test- TABLE 4 Screen dumps of the mtegrated precision-testing system (A) Intellrgent scheduler Supervisor control NO Descnbe method. YES Perform repeatabdlty test’ NO Select factors to be tested YES Select expenmental design YES Perform diagnosis: YES Run a total consultation NO Start consultation Loaclmg part file (B) Chromatograph Screens > chromatograph questions > options Main questions and answers Flow rate (ml nun-‘) Number of solvents PH Buffer cone (M) Additives Injection volume (~1) Temperature mode 10 CONTROLLED (C) Selected factors > sample > chrom > detector > column > data > options < Sample prep. Chromatograph Detector Column factors. factors factors factors weight shake time sonicate time heat temp pore size 1 pore size 2 wash vol extract vol extraction centnfuge ddutlon PH * temperature :- buffer . - solvent . * additive _ flow rate . - RI-range _ filter ._ wavelength + UV-time-con - RI-time-con - Manufacturer. * Batch - Data handlmg factors _ _ _ 1 factor * Related answers Mmlmum solvent (W) Solvent 1 (W) Solvent 2 (%) Solvent 3 (W) Solvent 4 (%) 25 15 25 Mmlmum additive (W) . Addltlve 1 :08( ) Adchtlve 2 OS( ) Additive 3 O%( ) Additive 4 O%( ) Addltlve 5 O%( ) Temperature ( o C) 40 No modlflcatlons made EXPERT SYSTEM FOR PRECISION TESTING IN VALIDATION OF LC METHODS 37 TABLE 4 (continued) (0) Selected experimental design Expenmental design SATURATED-FRACTIONAL-FACTORIAL-DESIGN Number of factors 7 Number of levels 3 Number of dummy factors 0 Number of expenments. 15 Show factors Wavelength warmng (E) System surtabrlrfy crrtena The results of any analysis should always fall wrthm the ranges of the values gven below Minimum found at exp.: 6 Comp 1 2 RT 217 333 277.0 Area 58 449 572.325 He&t 646 832 7772 02 C area 297 621 296.896 C hgt. 296 535 296.271 P count 2 5399 5.7842 Result 2425 15 2614.22 Maximum found at exp.: 14 1 2 267 333 439 0 255.746 102 058 2841.85 2096.0 6.979 7.0895 6 982 6 8935 3.1108 6.0617 3637.18 287117 (F) Marn effects tis screen shows the input gven by the user It also gves a short descnptlon of the results. When a change 1s made to the mput values, the results may change A better descnptlon of the results can be obtamed by selectmg the appropnate screen from the ‘screens’ menu Usage. ONCE ONLY Length of run’ > 10 Q 25 Number of users > 3 Number of Instruments. 23 Number of laboratones 1 OR 2 Preparation repeatablhty test: REPEAT 1 InJection repeatablhty test REPEAT 5 Wnte ss ing is only done after a successful repeatability activated. If the results are satisfactory, the mod- test, but the user may elect to forego the repeata- ule will report this and provide system suitability bility test and proceed with the ruggedness test. criteria (Table 4E). If the results are not satisfac- The ruggedness part consists of four modules (see tory, the user is informed of the main effects that Fig. l), which are usually consulted in sequence. are outside the tolerance limits and of the factors The factor choice module advises on which factors causing the problem (Table 4F). A solution to the are likely to mfluence method performance (Table problems that does not affect the method itself, is 4C). The select design module then advises on a to respecify the levels for testing the factors. When suitable experimental design to test these factors these levels are specified at narrower intervals, the with a mimmum of experiments (Table 4D) and a method is more likely to pass the ruggedness test C program is activated in which the user enters his but, of course, operation of the method in the experimental results. The diagnosis module is then laboratory will have to be kept under more rigid 38 J A VAN LEEUWEN ET AL TABLE 5 Results of the test case Method description Sample name formulation of components Sample preparation take sample No of tablets add solvent (ml) add mtemal standard dissolve sample somcate mmutes (mm) ddutlon 1 ddutlon 2 extraction filter pore size (am) Chromatograph solvent no solvent 1 (X) solvent 2 (%) PH buffer cone (M) Injection volume (al) temperature ( o C) flow rate (ml nun-‘) Column tradename functionality particle sze (am) column length (cm) batch number internal diameter (mm) Ruggedness test Factors chosen by the system aspum, sahcyhc actd tablet 2 Detector type attenuation ttme constant (s) wavelength (nm) vanable UV 0.1 01 295 take no of doses Results 1 250 no internal standard somcate 15 no dtlut:on no filtratlon 10 2 15 25 25 100 40 15 Sphensorb Cl8 70 25 1 40 nummum resolution 4.0 mm retentton time (s) 240 overall run time (s) 600 worst peak symmetry 14 Reqmrements usage No. of hnes purpose regulatory standard method mterlaboratory number of analysts average run length number of instruments > 10 d 25 4 stability mdlcatlon USA USP >3 23 > 10 < 25 >3 Factor Nommal level Lower level Upper level Somcation time 15 Pore size 10 Data handling _ PH 2.5 Solvent 25 Manufacturer Sphensorb Wavelength 295 12 18 5 20 15 35 20 30 other other 290 300 EXPERT SYSTEM FOR PRECISION TESTING IN VALIDATION OF LC METHODS 39 TABLE 5 (contmued) Experrmental desrgn Reflected saturated fractional factonal desrgn 11 factors 4 dummy factors 3 levels Inierpretatlon of expertmental results Mam effect Factor 24.0% somcate ttme 23.7% pore stze 24.0% solvent 27.2% manufacturer 22 5% wavelength Repeatability test Test advrsed by the system 10 ttmes repeated mJectton of sample 5 ttmes repeated sample preparation Interpretatron Relatrve standard devtatrons InJection of sample < 1% Sample preparation < 1% Dtagnosrs No problems control. In this case, the factor choice module is activated again, the factor levels are adapted to fit the test, and the whole procedure is repeated. Control of this operation is again placed in the scheduler frame that keeps track of the number of times a module is activated and also checks if the new activation has yielded a result. The architecture around the scheduler frame also makes it possible to load only one module that can be consulted as a stand-alone expert system. For some modules, tins can be practical. The prototype was developed in the Goldworks expert-system shell, Version 1.1 [16]. An IBM PC/AT with 8 Mbyte extended memory was used. The spreadsheet packages Lotus 123 and MS-C were used for implementation of the tests. RESULTS OF A TEST CASE To illustrate the capacities of the system, the test case used was a full in-house precision test of an LC method for the determination of aspirin and salicylic acid. Both repeatability and rugged- ness tests were done and the results were interpre- ted by the system. Real experimental data were used so that a comparison of the system perfor- mance in a real-life situation was possible. Table 5 shows a complete description of the results. The conclusion of the system for the repeatabil- ity test was that the method was satisfactory within the specified limits. As the method had previously undergone similar tests [9], this was to be ex- pected. The set-up of the ruggedness test corresponded with the expert’s ideas and suggestions. The only difficulties appeared in the interpretation of these results. The system reported several problems that were not encountered in the real ruggedness test. For instance, the system suggested that the method was not rugged in the measurement of the con- centrations of the analyte. As this is the crucial parameter, such a conclusion would be serious, but in reality these problems were not encoun- tered. The difficulty may be due to too rigid interpretation by the system or to problems over- looked in real life. To test tins, a full reproducibil- ity study is needed. Concluslon The expert system described here is a prototype that must still undergo a full evaluation study, which will be reported elsewhere. The philosophy of using a common data structure as a blackboard for various modules will be investigated further. The possibility of adding new modules for testing accuracy and selectivity will be crucial for success. The addition of modules on extensions to the ruggedness test and other modules on method development will also be investigated. Part of this research was supported by the European Community in Esprit project P1570 Ex- pert Systems in Chemical Analysis. REFERENCES 1 M A Trschler and EA. Fox, Comput Chem , 4 (1987) 235 2 C G Et&e, A P Wade, P T Palmer and K J Hart, Anal Chem , 59 (1987) 1363A. 3 S Moldoveanu and CA Rapson, Anal Chem., 59 (1987) 1207 J A VAN LEEUWEN ET AL 4 K. Janssens, W Donnne and P. van Espen, Chemom. Intell. Lab. Syst., 4 (1988) 147. 5 G.J Kleywegt, H J Lumge and H.A van ‘t Klooster, Chemom. Intell. Lab. Syst., 2 (1987) 291. 6 D. Goulder, T. Blaffert, A Blokland, L Buydens, A Chhabra, A. Cleland, N Dunand, H. Hmdnks, G. Kate- man, H. van Leeuwen, D. Massart, M. Mulholland, G Musch, P. Naish, A. Peeters, G. Postma, P. Schcenmakers, M. Desmet, B. Vandegmste and J. Vmk, Chromatographta, 26 (1988) 237. 7 A Peeters, L. Buydens, D.L. Massart and P.J Schoen- makers, Chromatograplua, 26 (1988) 101 8 P.J. Schoenmakers, N Dunand, A. Cleland, G. Musch and T Blaffert, Chromatographta, 26 (1988) 37 9 M Mulholland, J A van Leeuwen and B.G.M Vande- gmste, Anal. Chum. Acta, 223 (1989) 183. 10 J A. van Leeuwen, B.G.M Vandegmste, G. Kateman, M. Mulholland and A Cleland, Anal Chtm. Acta, 228 (1990) 145. 11 M Mulholland, N Durand, A. Cleland, J.A. van Leeuwen and B G.M. Vandeginste, J. Chromatogr., 485 (1989) 283 12 N.P Nu, the Arttf. Intel. Magazme, (1986) 38 13 W.J. Youden and E H Sterner, Statisttcal Manual of the Assoctation of Offtctal Analyttcal Chemists, AOAC, Washmgton, DC, 1975 14 M. Mulholland, P.J. Niush and D.R Stout, Chemom In- tell. Lab. Syst., 5 (1989) 263. 15 B.R Miutre, T. Laasn, F Mondot, F Charptllet and J P Haton, paper presented at the 9th International Workshop on Expert Systems and Thetr Apphcattons, Avtgnon, May, 1989. 16 J.A. van Leeuwen, B G M Vandegmste, G J Postma and G. Kateman, Chemom Intell. Lab Syst., 6 (1989) 239.