Copyright © IFAC Automated Systems Based on Human Skill. Berlin, Germany, 1995
QUALITY MANAGEMENT IN CHEMICAL PROCESS CONTROL EXPERT SYSTEMS
Peter Szczurko*, Kai Finke**, Dorothee Hoberg**
* RWTH Aachen, **
Informatik V, Ahornstr, 55, D-52056 Aachen, Germany szczurko@ informatik. rwth-aachen. de Henkel KGaA, TIS-I Engineering Systems, 40191 Diisseldoif, Germany {kai.finke,
[email protected]
Abstract: The reliability of Process Control Expert Systems (PCX) can be guarantieed only by comprehensive test methods. The knowledge acquisition process as well as the carefully applied test methods are important factors in increasing the acceptance of automatical systems even in controling complex chemical processes. The quality of product and process knowledge and the quality of the software system from the technical point of view has to be considered with the same consciousness. In this paper we describe how formal test methods are used during a PCX development process and how the development process itself is guided intuitively by knowledge engineers in five steps. An investigation of a concrete PCX development process based on several interviews at a major German chemicals company is the basis for a quality process model which is described in detail. Keywords: process control, quality control, automation, ISO 9000, testability, PCX
1. HIGH QUALITY PROCESSES
An investigation of test methods for knowledge based systems has shown that conventional test methods used in software quality management have to be adapted for special expert system development requirements (Coulibaly, A., 1993). As we can see in specific literature on knowledge based process control, testing only plays a marginal role, mostly in connection with the question on how to embed PCX in a general CIM architecture (Wallmtiller, E., 1990 and Yeomans, R.W. et.al., 1991). A comprehensive computerized environment for PCX testing and metrication called FAITH (Fault Analysis and Integrative Testing in Heprox) (Finke, K., et al., 1994) has been developed for a PCX shell called HEPROX (Soltysiak, R., 1989) which is the standard development PCX tool for Henkel. The expert system shell is based on a host target architecutre (see Fig. 1) which enables full testing on the host system. The knowledge base is given in PROLOG which will be transformed in FORTRAN77 to run on the production control computer.
Increasing customer demands on products and processes cause appropriate quality management activities. According to ISO 9000 part 3 systematic, repeatable, and documented test procedures are required especially for highly automated chemical processes. Henkel KGaA, a major German chemicals company pursues the goal to raise the quality consciousness of every employee. Even in chemical processes the company invests a huge effort in receiving a quality certificate (Witzke, R., 1994) of the developed software for process control. The requirements for complexity, ease of maintenance, and the ability to manipulate large volumes of data are reasons why AI techniques, e,g. Process Control Expert Systems (PCX) have been successfully applied. The quality of the PCX software, the knowledge acquisition process, the development and applicability of an appropriate test environment as well as the development process of the PCX itself are special interests of the company.
181
Although PCX are too complex for a comprehensive specification, at least essential parts can and must be specified efficiently. In FAITH this is done by exploiting the deep engineering knowledge encoded in measurement, control and regulation standards like (ISO 3511 , 1977). Five special adapted testing techniques, exploiting external specifications gained from the process control environment have been developed and were implemented as integral parts of the PCX quality management process. A detailed description of the test methods can be found in Finke, K. (1993).
PCXRUNllME ENVIRONMENT
Consistency check: includes syntax check according to the specific knowledge representation form in HEPROX, formal verification of a set of rules to find out redundancies , subsumptions, contradictions and circularities.
Fig. 1. HEPROX PCX Environment Plant operators have to take decisions in any of essentially infinitely many possible process situations. To deal cognitively with this complexity, plant operators tend to categorize process situations into classes. This leads to discretization and is a prerequisite for the qualitative kind of process modeling used in expert systems (Kuipers, B., 1989). This is done in HEPROX using different kinds of language levels describing process situations (Soltysiak., R., 1989).
Knowledge inspection: means tracing the PCX strategies by a knowledge engineer and at least one expert guided by external specifications. With this , nearly complete automation of the inspection has been established. Whitebox test: covers inference paths considering the content of modules passed by the inference. All possible combinations of actions influencing the process will be simulated checking the inference following the strategy as intended.
2. SYSTEMATIC TESTING
Blackbox test: is used in traditional manner. Some important limiting values and equivalence classes can be derived from the external specifications .
The faith in PCX is increased by embedding various verification steps in the development process. This stepwise testing should be executed with appropriate methods easy to use and as automatic as possible to facilitate the knowledge engineers tasks. Each verification step should be documented to show the correctness or to indicate errors and inadequacies . The verification process should be transparent and stepwise executable so that appropriate modifications would lead to the next consolidated development step. The general strategy is to detect any error as early as possible in order to minimize its impact, and to maintain the quality status achieved in the presence of change with as little effort as possible (regression testing). On the organizational side, the technical quality support achieved by FAITH has to be accompanied by a Total Quality Management environment as it is demanded by Deming, W.E. (1986).
Regression test: each test case is archived in a file system so that they can be read selectively or as complete test package. The overall test effort for a PCX has been reduced to 50%, first because it runs completely automatically, and second because the regression test ensures that no side effects have been worked in during the improvement or refinement phase of the PCX development process.
FAITH test method Consistency check
In expert system for extemal specifications validation and verification are often missing (Bologna, S., Vaelisuo, H., 1991). In contrast to the traditional evolutionary prototyping approach to expert systems development we emphasize the use of predefined external specifications as documents to test against (see also Lane, N.E. , 1986). It should be avoided that the first prototype is only refined and expanded into a new prototype without specifying changes in a requirements document. This would be unacceptable from the viewpoint of dependability in a chemical production setting.
Knowledge base inspection Whitebox test Blackbox test RegreSSion test testability metrics O'!ll.
Fig. 2. Automatism of FAITH test methods
182
100'!ll.
3. TESTABILITY METRICS The test environment FAITH also comprises a set of easily computable metrics for analysing the knowledge from a structural viewpoint and enables estimating the test effort. The full paper will conclude a detailed description of test methods and metrics. knowledge base statistics: survey of size and growth
....
to give a general
-
11
~ maximum depth
largest substrategy: as a measure for the degree of modularity procedural share: gives hints whether exhaustive whitebox testing is possible
Table 1 Testability metrics for real PCX
231
13%
27 178 137 258 139 515 4 8 50 %
11
26
19
348
2
maximum breadth 3 procedural share
CC call substrategy ,~ , return nodes
, -.
50 %
The sewage control PCX has been developed by only one knowledge engineer. Within two years from the beginning to the application of the sewage control PCX we can distinguisch five development steps. In Fig. 4 an approach to a quality process model for PCX development is given. The knowledge acquisition process as well as several quality steps can be separated by certain characteristics of documents.
ester intersewage change reactor preparation
i7
, - - ,j
The continuous call of the companies management on the improvement of product and process quality led to an intuitively applied PCX develop'ment process model of the consciencious knowledge engineers. An explicitly given quality process model is not yet given though it is demanded for software engineering processes in (Stucky and Oberweis, 1992). The following steps are described as a result of several interviews with the involved staff during the development of a concrete PCX.
longest possible inference: is defined as the inference path taking the most runtime in execution. The estimation is important to ensure that real time requirements are fulfilled.
2 29 12 14 17 30 7 2
'
Fig. 3. Metrics of an example strategy in HEPROX
maximum breadth, maximum depth: as measures for the complexity of PCX decisions. This are very important values for knowledge base transparency.
expert system / kind of entry nodes substrategies variables modules conditions actions explanations maximum depth maximum breadth proc. share largest substrategy longest possible inference
\ _
We noticed that social impacts are also important facts in achieving high quality expert systems as the consideration of technical details and knowledge formalisation. The development of high quality knowledge and inference processes for PCX is both a result of carefully composed specification documents and the capability of motivating the development team considering technical, organisational and personal aspects simultaneously. Fig. 4 shows that the first phases of cooperation between experts (experienced engineers), operators, and knowledge engineers have the main effect of reducing both exaggerated expectations and fears on the user side while bringing the knowledge engineer up to the needed threshold of domain understanding. Together with increasing trust, the operators then acquire the understanding of PCX necessary to actually participate in the functionality, the expectations to the system grow again but the trust in the system oscillates as serious errors are detected, until the basically error-free operation of the system in parallel to human control finally establishes the ground for phasing in actual system usage.
4. MODELING QUALITY PROCESSES Several applications have been developed successfully using the facilities of the development environment HEPROX. With the establishment of automatic test methods using FAITH the effort of PCX maintenance has been reduced to merely 50 % than before. The most important help is given by the regression test which relieves the developers of boring repetitions after knowledge base changes to avoid error propagations. This led to a reduction of the personnel which is involved in the PCX development process, while carefully ensuring the highest possible quality.
183
which is used in HEPROX to hold the process knowledge. The formalized knowledge which has been derived from the decision tables and the informal interviews is the basis for discussion.
deei8iont.b... knowt.d9t
devel· opment steps
prKtic. teet hanclling
knowt.dge coMt~
atNCturin§ and
training. knowtItdge
Icnowt.dge
tannllliution
fMdbeek
Kqunment
.1TOf'
refiMfMnt t_ca. c:ompi6iltion
dM:iaion
com.-riaon
=
I -.... ~~~ interview
teaching
im:7
The replay of the operators knowledge is an important step in PCX software quality because of the following aspects: First the knowledge engineer and the operators form a team during the PCX development process. Building up the team spirit in periodical meetings where the current state of the PCX development can be discussed is beneficial for new ideas and knowledge improvement from both sides especially if the discussion takes place not at the usual place of work. The motivation increases visibly giving the operator the certainty when the companies philosophy of total quality management is realized through have the operator participate in the PCX development process actively, involving him in training processes and make his work more interesting by varying the scope of work.
• review/test
I
I
degree of ' knowtedge i
I knowledge engiMer
I
' I
exper1l0petat0r
.
:::.::~~i~.f·::::~:~· ..:.~~·::::·~::::·:·: ~.,. -.-.-.
•.
I
Fig. 4. Steps in the PCX development process
5. PCXDEVELOPMENT STEPS: A CASE STUDY
Second the given informal documents are processed by the knowledge engineer for the use of computers. A comparison and verification of this knowledge can only be performed by the experts themselves. The goal is to achieve a complete view on the necessary process knowledge and its correctness and completeness. The discussion of process situations and decision rules is already an improvement of the process quality without the PCX because of the complete gathering of experience of all involved experts and operators.
In the following we give a detailed description of the development steps derived from an example of a sewage control system. Interview phase At the beginning the knowledge engineer did not have any knowledge about the PCX to be modeled. Process documents for training are not used because of their less detailed and illstructured form. On the basis of informal interviews between the operators and the knowledge engineer, documents like decision tables and rules in certain problem situations were drawn up. These tables consist of combinations of measured values and necessary actions to improve the process accdording to resources optimization, quality control and avoidance of pollution.
Third the operators will be aware of the PCX's area of authority explaining which kind of work the PCX will take over. It is not rarely the fact that operators are afraid of the expert system because they don ' t know exactly how their scope of work will be changed when the PCX is used instead of the human process control. It is a must to explain the operators how a PCX works and in which situation, namely the routine work, decisions and actions will be taken over. On the one hand side the operators should lose their doubts and fears and on the other hand side they should be aware of their interesting future work and their responsibility for a high quality PCX.
A listing of all possible combinations of measured values was drawn up as a first description of correct process states and rules to detect alarm situations. Within this phase the social competence of the knowledge engineer and the talent to motivate the operators to give expressive process knowledge is the key of increasing the mutual understanding of the operators process knowledge and the formal and abstract way of thinking of the knowledge engineer required to build up an expert system.
The need of abstraction mechanisms and formal representations as a basis for automatism confronts the operators with a new way of thinking. The consideration with knowledge representation and inferencing mechanisms reduces existing cognitively and intuitively used actions. Although the experience knowledge will be structured and formalized the often praised instinct for the optimal regulation of processes will be replaced by rational ways of thinking and behaviour.
Training phase With respect to the formal representation of the PCX the operators knowledge will be transformed in modules and strategies as basic elements of the PCX knowledge base. In special training sessions the knowledge engineer explains the representation
184
Improvement phase
and integration tests within the process environment are performed (see Fig. 1).
On the basis of the explicit abstract representations the experts give constructive remarks to improve the knowledge base. The correctness will be proved in further team sessions and meetings together with the operators. Detailed questions like, which values are measured by an instrument or which states can be calculated from combined measurements, lead to a considerable improvement of the existing knowledge. Furthermore the consideration of so called external specifications which consist of explicitely given documents of PCX requirements as well as the behaviour of the PCX in certain alarm situations is a prerequisite for the knowledge base inspection as well as the blackbox test in the test environment FAITH.
6 . EXPERIENCE In interviews with the knowledge engineers and users we established the fact that during the PCX development using the test environment FAITH the prototyping process was supported appropriately . It was easy for the developer to get a feeling for the knowledge base and its quality looking at the metric information generated during the various test phases. Feedback information like error messages and improvement hints rises step by step the trust in the system even because the boring and lengthy regression test was automated. In the development of a sewage control PCX, FAITH reduces the regression test effort to 30 %.
Refinement phase The PCX development team generates a lot of test cases which should cover all decision paths as far as possible. The number of test cases depends directly on the number of decision nodes within a PCX decision tree. As an example for the sewage control PCX exist about 200 test cases documented and executed (see also table 1). The results of the PCX in every given test case are discussed together with the operators with the goal to refine the knowledge base using the abstraction mechanisms offered by HEPROX namely using strategies and substrategies. In case of obviously wrong PCX decisions the traceability of decisions plays a main role in the refinement phase. Only a comprehensive understanding of the whole decision process can reduce the operators breach of trust which arises because of the detected errors. During the development of the sewage control PCX about 50 errors have been detected and eliminated.
As a side effect, the implemented metrics give adequate help in estimating the knowledge base quality from a structural point of view . We found out that the procedural share is the most important metric. A value higher than 10 % disables exhausive tests in most cases. The very success of PCX is not only a consequence of the establishment and carefully application of software quality methods but also a service of the knowledge engineer. The goal of the PCX development team should not only be reduced to reach the companies goal but also to consider the interests of every involved team member. The consideration of organizational and personnel aspects was remarked as very important for a successful PCX development (see Fig. 5). The appropriate technical environment which is given by HEPROX, FAITH and several techniques for knowledge acquisition, visualization and refinement is only one layer for the quality concept which is followed in developing successful PCX at Henkel.
Review / test phase During this phase the already existing PCX is integrated in the process. Although this is done without any competence changing the process, all the measured process values are given to the PCX. The process situation as well as the decisions are documented and discussed later with the operators. For an evaluation of the PCX in problematic situations the behaviour of the PCX is observed by simulating known critical situations. Especially for this reason test cases are generated and executed in the process environment. Blackbox test cases derived from the external specifications as well as whitebox test cases which are generated from the internal structure of the PCX knowledge will be executed equally. We know from experience that in this phase only few errors are detected because even the problematic situations are covered by a test case which is already investigated in the previous phase. Additionally to the validation of the PCX decisions the usual interface
Fig. 5. Quality facets in HEPROX PCX development
185
The application of an expert system in process control causes changes of work spaces which requires additional qualifications of the involved operators. It has been shown that fears and doubts have to be eliminated to ensure that the operators understanding of a PCX means positive work changes with more responsibility and less routine work. This is a prerequisite for an efficient cooperation between knowledge engineers and plant operators.
cooperation with this team and the willingness to give expressive information during the held interviews.
REFERENCES Bologna, S., Vaelisuo, H. (1991), Deep knowledge and rigorous engineering practice, In Dependability of Artificial Intelligence Systems (DAlSY91), (Schildt, Retti, Ed.), North-Holland,73-90. Coulibaly, A. (1993), Development of test methods for knoweledge based systems, (in German), Diploma Thesis, RWTH Aachen, Informatik V. Deming, W.E. (1986), Out of the Crisis, MIT, Cambridge. Finke K. (1993), Systematic Testing of Process Control Expert Systems, (in German), Diploma Thesis, RWTH Aachen, Informatik V. Finke K. , larke M., Szczurko P., Soltysiak R. (1994), FAITH in Process Control Expert Systems, Proc. 11 rh European Conference on Artificial Intelligence (ECAl94) , Amsterdam (NL), 8th-12th August 1994 ISO 3511 (1977), Process measurement control functions and instrumentation - symbolic representation, Part I-II. Kuipers, B., Qualitative reasoning - mode ling and simulation with incomplete knowledge, Automatica 25, 4. Lane, N.E. (1986), Global issues in evalutation of expert systems, Proc. IEEE Int!. Con! on Systems, Man and Cybernetics, Atlanta 1986, 121-125. Schinzel, B. (1991), Frauen in Informatik, Mathematik und Technik, Informatik Spektrum, 2-1991. Soltysiak, R. (1989), HEPROX, eine Expertensystemshell fiir ProzeBftihrungsaufgaben" , Automatisierungstechnische Praxis, Nr. 31,211989. Stucky, W., Oberweis, A. (1992), Zur Beherrschbarkeit des Entwicklungsprozesses Forschungskomplexer Software-Systeme, bericht 242, Univ. Karlsruhe. Wallmiiller, E. (1990), Software-Qualitiitssicherung in der Praxis, Hanser-Verlag. Witzke, R. (1994), Zertifizierung von Qualitatsmanagement-Systemen bei Softwareherstellem, Theorie und Praxis der Winschaftsinformatik , Heft 175, Jan. 1994. Yeomans, R.W., Choudry, A., Ten Hagen, PJ.W. (1991) , Design Rules for a CIM System, North Holland.
The acceptance of PCX has been increased because both developer and user have the opportunity to participate in all steps of PCX development. In fact, we noticed that with the help of FAITH, the work itself was made more interesting. Generally, the use of FAITH substantially reduces the human test effort while improving the quality of PCX significantly. Is has been shown that the development process has been guided in an excellent manner by the knowledge engineer. This includes the carefuly preparation and execution of necessary development tasks as well as the ability to motivate the involved plant operators creating a high quality PCX. In fact the knowledge engineer at Henkel is female , which may be a reason for the successful collaboration in the development team. It can be shown by several empirical studies that women are thinking more realistically, that they are more pragmatic and that they lead a conversation with more feelings for important issues than their male colleagues (Schinzel, B., 1991). In this given case it can be confirmed that the social competence of the knowledge engineer was a main factor for efficient and successful work. Until now several PCX have been designed and implemented with the use of the above mentioned development environment facilitating the knowledge acquisition process and prototyping. The given quality process model has not been described until now in detail, but has been applied intuitively by the involved knowledge engineers with great success. Although we hasten to acknowledge that this case study is in no way statistically significant, it may help to explain the stringent quality requirements placed on PCX in the company, even at the cost of system intelligence.
ACKNOWLEDGEMENTS This work has been realized within a cooperation between the department of computer science V at the RWTH Aachen and the department of engineering systems at Henkel KGaA. We appreciate the excellent
186