., LA-uR--89-3534 DE90 002399 ‘i(/V~ [, i~~g TITLE The Development of an Expert System to Tune a Beam Line AUTHOR(S) D. E. Schultz DIS(’I..I4IMKR ‘,,,.,,,!! ,!, , ,,, ,. MASTER- “ About This Report This official electronic version was created by scanning the best available paper or microfiche copy of the original report at a 300 dpi resolution. Original color illustrations appear as black and white images. For additional information or comments, contact: Library Without Walls Project Los Alamos National Laboratory Research Library Los Alamos, NM 87544 Phone: (505)667-4448 E-mail: lwwp@lanl.gov ‘l’heDeve@ment of an Expert System to Tune a Beam Lin@—- —— ——. -—.———— -.—. —— —— David E. Schultz I,os Alamcs National Laboratory Los Alamos, New Mexico 87545 Pamela A. Brown TRIUMF Vancouver, BC V6T 2A3 Abstract The experience of developing an Expert System to””aid in the tuning of the Ion Source Injection beam line at TRIUMF is described. The challenging and complex task of introducing Expert System technology into an established accelerator operation is outlined. Success in this environment. depends strongly on the choice of project, the choice of experts, the choice of tools, and the methods used to represent tile expertise. All these choices are discussed. 1 THE ACCELERATOR ENVIRONMENT TRIUM? is a cyclotron which accelerates negatively–charged hydrogen ions to variable energies between 6Cl MeV and 520 MeV. 1.1 Ion Source Injection Beam Line The Ion Source Injection System (ISIS) beam line accepts 300KV tl- beam from the source and transports it a total of approximately 40 meters around two bendri to the centre of the main accelerator. The beam is transported by electrostatic focusing and steering devices. There are four groups of diagnostic devices in the ISIS beam line: collimators, skimmers, non-intercepting monitors, and wire scanners. The skimmers precede and protert each quad~-upole and help to centre the beam. In this project, thn collimators were the principal devices used; the skirnmerc were uGed lesb because they do not tolerate veL”y m~lch current and because they are leGs sensitive. ‘rhe non-intercepting monitors were used to calculate transmission. The Wi[C scanners w~rc not useu because there is little ope[akional expedience with usin(j * work fiupportec] hy the US [Jcp,~ltment of El~rrgy. w(~lk I)clf(lllnflll al l’RIUMF. 1 The Development of an Expert System to Tune a Beam Line them. 1.2 Manual ISIS Tune Procedure After the desired source is selected mechanically and logically, the electrostatic elements of the 1S1S beam line are restored to the values currespond~ng to the best known solution. The operator uses the currents Oc the beam stops and the spills on the skimmers and collimators to find the earliest significant spill. Next the operator determines whether the loss is caused by horizontal or vertical displacements, or if the beam is too large and hitting sumething. As a tuning contingency, the collimators are water-cooled and able to take the full ISIS beam. Close to a wire scanner, the operator uses the wire scanner to make the diagnosis. Elsewhere, he diddles (makes minor adjustments to) the setpoints of appropriate beam line or source devices. He uses the collimator and skimmer histogram patterns and the 1S1S transmission, to minimize beam spill in the ISIS beam line. .“ 2 THE OVERVIEW OF THE TASK A six month pilot project was setup to determine the feasibility, problems, and benefits of using Expert System technology to solve a problem in the beam line tuning domain. Several questions arise when approaching a new technology. Some of the more obvious are: 1. Can it solve the problem? 2. Is it appropriate for the task? 3. How much does it cost in time, money, and stress on the existing system? 4. What are the limitations? 5. IS it a good choice for this problem in view of the ahovc? The project was staffed by onc visiting sci~ntist working 1!111 time with a review pane 1 consi~tinq of four (two t~rhnicnl and two managerial ) TRIUMF employees. In ad(!ition, Othe r TRIUMF technical people werr called on to pcovidp detailed information about. spccif if” parts of the beam line and the curtcnt tune procedures. For a det.ailv:l technical dcscriptir)n rf thifi ~)~ojr(:t, Gce ~cfc[encv 1. .1 ,1 The Development of an Expert System to Tune a BPam Line 2.1 Characteristics Of Beam Line Control Problems There are characteristics common to beam line control problems. In most cases, there are a large number of repeating interacting devices. Each device has several related devices. The effects of these devices are not always well understood. While there may be a mathematical model of the theoretical beam line used to design the beam line initially, often that model is not precise enough to accurately predict what a given change will do to the real beam. That is the case for the 1. 2. 3. 4. 5. ISIS. The biggest factors preventing the use of a model to predict performance of ISIS are: A portion of the line goes through a wall. That portion is unshielded from the effects of the main magnet ( 90 gauss or mole). Permanent magnets are placed on the beam line to compensate for the effects of the main magnet. Due the the heavy weight of the accelerator, the floor below the ISIS beam line is sagging. Moving large pieces of metal, such as the crane, have an unpredictable effect on the magnet fields around the ISIS line. Each time the source is replaced, a s!ightly different set of initial beam conditions occur. 2.2 Implications Of Beam Line Characteristics On Expert System Tools The type of problem to be solved places constraints on the selection of tools to be used[2]. For beam line control prok~lems, the tool selected should provide for representing devices, interactions representing between devices,reasoning in the face of uncertainty, following an expert’s recipe for approaching a tune, and reasoning based on observing effects. 3 CI1OICI?,S ‘1’0have a successful expert system p[”ojr!ct care must be taken to choose the right project, the right expeLt, the riyht tor)]fi,and thu right, approach to representing the expottisc. l’hc 1S1S project will bn descrihcd in terms of the choices Fotcc[l on it Ily extclnal fartols 01 thr)ficmade fl~~ly. ‘1’hoficrhoicns will thrl~ hn cumpalp{l t(”) c1 llf~lff*(”( pl”ojf?ct t,() tly t(1 idcnt ify thof;o [cI(:toI:; th(l( m~lr;tI)(?t:tlll!~i(l(~l(’{1If) The Dt2Ve10pIW11L (JL all GAp CLL d~d.~... .- ..-. .-— —— . . increase the likelihood of successful ap~)licat ion u f ~X~)(’L ~ Sy!; ({.111 techniques to beam line control nrobl ems. 3.1 Choice Of Problem The 1S1S tune problem was chosen because it is big enough to test the use o f expert system techniques without being too big to handle. It is a real. problem that has a real need for an automated solution. ISIS is a good choice because there is a limited amount of expertise available. There is a dramatic difference between the performance of the best tune r and tl.e rest of the operators. The ISIS tune problem has a long life for the current TRIUMF accelerator wilml be the injector to the KAON factory. . 3.2 Choice Of Development Team Members of the project team should be trained in the technology to be used, knowledgeable about the application, have adequate time to spend on the tasks assigned, and dedicated to the success of the project. The domain expert is particularly important. Fred Bach was available, and the acknowledged expert OR the topic. He was interested, and cooperative. He has a long term familiarity with ISIS going back some 16 years. Fred was a cooperative expert who was willing to give up the secrets of his success. Sometimes this is difficult to achieve. Often a cjood candidate is one who wants or needs or is encouraged to move on to other tasks either for professional development or retirement. In those cases, the expert is not threatened by the apparent loss of scme of his or her uniqueness. Fred felt that this project would make his job easier and hence he did not consider the expert system a threat. 3.3 Choice Cf Development Machine TRIUMF had at the start of this project about 25 VAX wr)rkstatinns available to use. All of the workstations were connected to a Local A~ea VAX Cluster (LAVC). In thi~ environment, the workstati(ln~ c1I(’ normally disk-l~?ss ai~d all the operating system, paging, windowing, NI)CI nppliccltinn data is obtained OVCK the ETHERNET ftom/to thr (lick 5P1VPI 0II the 1>001 Iludr?. At. first,, a VAX station 2000 anfl tllvn latol , a wrt’~ l]Grd for lTA. 1200 Each initially hd(l flMB of mcmc]l~. 4 ‘lne Uevf51U~IIl~llL UL all IZAp CL u UY-LQ III -U AU . . ---- ------ —— -- — Beth workstations started disk-less, but, it quickly became Clc’ur thilt the demands on the boot node fo[- windowing and paqing wore a serious bottleneck. A single low performance local disk was [“)ut on both the 2000 and the 3200. This improved performance. For example, #indow swapping no longer took several minutes; but, the improved performance was still subjectively slower than the author’s previous experience using a 16MB micro-VAX II using two of the same 1aw performance disks in a stand-alone system. The LAVC environment was also considerably less reliable than similar hardware running outside a LAVC. The LAVC stations experienced repeated hang-ups when mouse or keyboard requests would be Another ignored. problem was the relatively frequent system crashes where the workstation’s processor would halt or spontaneously re-boot. The unpredictability and unreliability of the LAVC was- a serious problem for the development of ITA. 3.4 Choice Of Development Software Two different Expert System shells were used and the features and limitations of each were compared informally. We started NEXPERT, using to evaluate the premise that an apparetitly simpler tool might be easier to learn, use, and integrate. KEE was later used as the full featured, high powered approach. 3.S Choice Of Approach The ISIS tune advisor (ITA) project took a slightly different approach than traditional Expert System applications 13]. In most expert systems, either one expert is used, or a group of experts combine their knowledge to form a composite expert. ITA uses three slightly different approaches. The first attack on a problem is to use the heuristics of the operational expert. If that succeeds, all is well. If the operational approach fails to solve the problem, a second attempt is made using a technique developed by a beam line physicist from a theoretical analysis of the problem. If that approach also fails, a technique is tried which mimics the actions of an operator when faced with a problem for which he has no previous experience. In this fallback, last-chance, approach the expert system searches for a solution using only very general heuristics based on relative location and physical performance feedback to limit the search for the right correctors. It is hoped that the combined powel to solve tuning problems will he yreater than concentrating on any onc app[oach. !) 3.6 Choice Of Delivery Vehicle While the project did not advance to the delivery phase, it j.s clear that features and performance that are adequate or suitable fur development could be inappropriate for a production environment. This is true for both hardware and software. It is very likely that the best approach is to develop the expert system in a powerful high performance environment and when the concepts have been proven, port the knowledge gained in the development process to the best delivery vehicle available. 4 THE PERFECT PROJECT .“ This might be considered as an utopian description of the perfect project. However, it can be practically used to evaluate a proposed expert system project to determine the chances for success. While projects will succeed even if they differ from the ideals expressed here, the more deviation the more likely the project will not meet expectations, The knowledge gained from the work on ISIS and other accelerator control artificial intelligence projects worked on by the author is used here to describe the best of all pos6ible projects. .’ 4.1 The Perfect Problem The perfect problem has a high payoff, available expertise, cooperative expert, and a relatively confined problem area (well circumscribed). Complexity caused by repetition is a problem that can be handled more easily by a program than by a person. 4.2 The Perfect Development Team To create a knowledge based expert system successfully requires several things; the most important are the people that make up the project team. Ideally, the project team is made up of trained Knowledge Engineers (KE), programmers, an e~pert, and a managerial team that is knowledgeable in the technology. The team must have adequate time and support to build the system. The development team must be open to technology, focused, concis~, and insightful. The expert should have a stake in the out come. 110 should be able to share the praise or blame for the success or failure of the project. Not only must t.hc expert be willing to sp~nd tbc tim~ on the project but the expert’s managets must be committed to Suppolt (i he project. It has been said that you know that you have the [ight ‘xpert when the manager is reluctant to give up that person’s time. .3 The Perfect Development Machine It Ileeds to have high performance, powerful environment, and be ntegrated with existing beam line control system machines (for access .0 real data). High performance implies large effective memory :apacity, fast swapping device(s), high resolution display, and a fact Iccurate pointing device. Large amounts of memory are particularly lseful whev using a LISP based tool on a traditional work station. ,ISP in that configuration takes a large amount of phy~ical and virtual Iemory space . Though the single sample of a C based tool did not terform noticeably better in the LAVC environment. Whatever machine is :hosen, it must also be robust. For these reasons the development Iachine m!-.stbe dedicated to the task. It should be a stand-alone ~ystem in the sense that it is insensitive to outside forces. nterruptions affect development of expert systems even more seriously .han similar interruptions to traditional .programming for the following ‘easons. ,. Large codes imply longer times to save ,. Quick response encourages experimentation /. Neither shell used has journaling 1. Expert Systems require broader more complex thought processes Because the codes are much larger (the initial prototype of ITA :ontains almost 500K bytes ) it takes a relatively long time to save. ‘his coupled with the speed with which you can try another featu[e, encourages the knowledge engineer to “try just one more thing before Laving” . The cost is often recreating what was lost due to a hang or a :rash. In traditional development with a text editor, a crash or hang rould not be as costly becal~se usually the incremental adrlitions to a ~rogram are smaller and most of a lost editor session can normally t)e “ecovered from the journal file autamat.ically g~ncrated, Nf?ith~r :xpetl Sy$+tem stlell used pl-ovides a journaling facility. The breadth ~jf knowledge contained in an expert system usually i!i substantially k]roader and more complex than in a traditional Ipp],ication program. Even there, an int~lru~~t inn can }1p costly in .erms of time Lcquiled to regain a train 0[ thouyllt. Intvl~upLiorlfi alu ~ven more costly in expert system development because of the increased complexity. 4.4 The Perfect Development Software Development software must be powerful, fast, flexible, easy to :hange, simple to document applications, easy to learn (good tutorial naterial with plenty of examples) and use. It must have good debugging tools , well documented features, multiple representations, and full support of external subroutines and interfaces to existing independent ?rograms. Object-oriented programming tools provide many of the required features. .. The thought processes required to develop an expert system are ~ifferent than for a traditional program[4]. Expert system shells that look like or are patterned after traditional approaches, i.e., text sditors or spread sheets, on the surface are very attractive for they look familiar to the typical traditional programmer. But, that Familiarity can be costly for it makes.it doubly difficult to change :he traditional (procedural) thought patterns. 1.5 The Perfect Approach This, of course, depends on the specific application. The development team must have a broad repertoire of tools and techniques :0 apply. Each application will be somewhat different thereby requiring a variety of approaches to solve. 1.6 The Perfect Delivery Environment Both hardware and software should be inexpensive (so that many :opies can be economically fielded) , fast, robust, and requires minimal :hanges from development. It should match the existing environment so lo new policies, procedures, or maintenance is needed. i CONCLUSIONS AI technology can be profitably used in the solutio~ to Accelerator related problems, but, care must he taken in the choice of )Lohlem, expert, development and rl~livery vehicles[ 5]. AI tecllni~lu~s Ire appropriate because algorithms fail and the captured knowledge of the expert does lead to a solution. AI technology is costly in time to develop and in money for softwar~, hardware, and people. It has not stressed the system yet but in operation it will put significant. demands on the control system for data. The major limitatio;~s of AI technology are the limited number of people trained to do t!le wol-k the ,31)(1 poor performance of the shells used in the VAX workstation LAVC environment. AI technology is none the less the best choice available. There are several actions that can be taken to improve the chances for success of a production version of the prototype. Some suggestions for improvement include upgrade the workstation to a more powerful system, refine the approach used to include more, different or more powerful techniques, and port the application to a more powerful delivery environment. .. 6 ACKNOWLEDGEMENTS I would like to thank the fcllowing people for giving me this opportunity and assisting me on this project. Martha Hoehn and Earl Hoffman for arranging and approving the ‘leave from LANL to come to TRIUMF. Ken Dawson and Don Dohan for arranging for my stay at TRIUMF and selecting this project. Peter Grant and Mi’ke Mouat for technical assistance and support on the workstation. Fred Bach for his tuning knowledge of 1S1S. 7 REFERENCES [1] Schultz, D. and Brown, P., “Using Expert System Techniques to Tune the ISIS Beam Line”, LAMS-89–XXXX [2] Harmon, P. and King, D., =rz 5LsIg !:I-izi.!!.s: Intelligence in Business, John Wiley, New York, 1985.— .- -——— [3] Winston, P., Artificial Intelligence, Addison Wesley, Reading-——— .—— --— .-.—..... . MA, 1984 [4] Charniak, E. and McDermott, D., Introduction to Arti!l.g.l.?.}—..— — — Intelligence, Addison Wesley, Reading, MA, 1985 [5] Schultz, D. and Silbar, R., “Toward Automatic Control of Particle Accelerator Beams” in Artificial Intelligence in—- — Engineering: Diagnosis and Learning, J.S.Gero editor, Elsevier,—- — Amsterdam, 1988 .. 10