Automatic Programming for Sequence Control Hiroyuki Mizutani Yasuko Nakayama Satoshi Ito - PDF document

Automatic Programming forSequence ControlHiroyuki Mizutani, Yasuko Nakayama, Satoshi Ito, Yasuo Namio-ka, and Takayuki Matsudaira, Toshiba Corporationhas been carried out manually, and an increase in applications of pro-Third, information that is necessary to complete one program step is From: IAAI-92 Proceedings. Copyright © 1992, AAAI (www.aaai.org). All rights reserved. scribed in this chapter is to reduce these difficulties to increase pro-ductivity and improve the quality of sequence control program design.Moreover, it aims to facilitate a systematic accumulation of designThere are two kinds of design knowledge used in generating se-quence control programs: One is knowledge about the environment inwhich the programs work. The other is the specific programmingWe found through an analysis of designersÕ behavior that knowledgeabout the environment (that is, plant) plays an essential role through-specification validation, implementation, testing, and maintenance.This knowledge constitutes a model of the plant that is to be con-trolled and leads us to propose a model-based automatic programmingparadigm. Under this paradigm, the plant model supports every task inThe second significant kind of knowledge is for refining specifica-tions to target program codes. It appears that two kinds of program-ming knowledge are involved: One is to find reusable program partssuitable to given specifications. The other is to select a program skele-ton and refine it in a stepwise fashion, according to the specifications,We chose the knowledge-based approach to develop First, it is one of the first knowledge-based systems in the plant con-trol program design domain in which knowledge about the environ-Second, it demonstrates a new technology for making a knowledgeand model transformation discussed later.A plant system includes operators, operation devices, programmableControl programs in conventional problem-oriented languages (forLADDERDIAGRAMimplement, they are still being manually designed; as a result, theprocess has begun to suffer from several of the problems that were316MIZUTANIETAL At the first stage of automatic programming system development, weestablished the software life cycle that we describe here. It was set upsimilar to conventional design processes so that designers would beable to easily transfer to the new system and maintain it. Because ofthis policy, it was necessary to simulate designersÕ conventional think-Previously, automatic programming research was based on the theo-rem-proving approach (Manna and Waldinger 1980), the program-transformation approach (Fickas 1985; Darington 1981; Green andWestfold 1982), and the knowledge-based approach (Barstow 1985;Lubars and Harandi 1987; Smith, Kotik, and Westfold 1985; Neighbors1984). We selected the knowledge-based approach, where an informalhigh-level specification would be attainable, and prototyping would beeasy; moreover, a conventional program-parts database could be used.UTOMATICROGRAMMINGFOR Figure 1. Conceptual Block Diagram for Plants. Figure 2. Example of Control Programs Written inLADDERDIAGRAM Requirement analysismeans deriving detailed specifications from briefrequirements given in terms of the structure and operation of thein terms of actuators, sensors, operation devices, interlocks, and so on.control specification(figure 4), which sets out the operationsthat the plant is required to perform.In figure 4, a box represents an action, and a horizontal bar repre-sents a transition. We set composite-actionÐlevel specifications as infor-is an abstract descriptionof possible machine actions or states that can be broken down intocations, such as speed and subsidiary actions, are not described at thislevel. For example, Òmove forwardÓ can later be broken down intoÒmove forward at low speed until some conditions become true, andthen move forward at high speed.Ó This high-level specification bringscontrol design closer to the designersÕ conceptual level, making designIn the new automatic programming system, a generic model con-structs a specific model by interpreting machine specifications. Thesemodels are discussed later. The generic model determines a structuralrepresentation using the general knowledge of the functional structureof such plants. At the same time, it derives the detailed machine behav-lates incomplete and ambiguous control specifications into detailedSpecification Validation PhaseThe conventional testing method is based on a comparison of the actualbehavior of the programs with the userÕs intent. It is carried out using aspecial-purpose plant simulator after implementation is complete. If mis-318MIZUTANIETAL Figure 3. Example of Machine Specification. In the new system, the plant model supports specification validation.A symbolic simulation is performed using the detailed machine behav-ior, as represented by transitional relations between machine actionsImplementation is carried out by selecting suitable program parts andmodifying them according to the specifications. Sequences that cannotbe covered by program parts are refined using the program pattern ina stepwise fashion to create detailed programs. The specific model pro-vides the knowledge necessary for these refining processes.Task independent: The model must support the entire design pro-cess previously mentioned. There are different kinds of tasks in the de-to support every task. The knowledge-compilation technique (Chan-drasekaran and Mittal 1983; Araya and Mittal 1987; Brown and Sloan1987; Keller et al. 1989) was suggested based on a similar idea. Knowl-UTOMATICROGRAMMINGFOR Figure 4. Example of Control Specification. ic programming for plant control. A common problem exists in con-large amount of ad hoc knowledge. To overcome this problem, model-ing techniques must be developed that support every application in aUnder this paradigm, we built the automatic programming system4000 workstation. We developed and useda knowledge description language in Lisp. It has facilities for frameProgram parts are stored in a relational database (RDB), and theinterface. Designers inputspecifications through a dedicated editor.We propose the modeling techniques that are outlined in the following320MIZUTANIETAL Figure 5. CAD-PC/AIFlow Diagram. The plant model is composed of two parts: One is a generic model thatcontains knowledge used by system designers in the requirement analy-sis phase of control systems for a particular class of plants. It includesthe functional structure of such installations, types of machine behav-ior, and expertise about plant control. The generic model is construct-ed by collecting the practical knowledge of experts and generalizing it.The same model is applicable to all plants of the same type; for exam-ple, the generic model of a steel plant is used for a hot-strip mill, a tan-The other part is a specific model that contains knowledge used inthe specification validation and implementation phases. This knowl-edge includes the structure, machine behavior, and constraints of a sin-gle target plant. This specific model is derived from the generic modelthat contains conditional relations in addition to the conventional se-conditions. When the conditions are valid with regard to the specifica-tions, the relation is reflected in the specific model. This representa-Furthermore, it has an object-oriented facility. The model-derivationprocedures, mentioned previously, are represented as methods. Condi-tional relations in the generic model are instances of classes and, assuch, are able to inherit the methods. As a result, appropriate specificmodels are built by interpreting the generic model with regard to theuser-defined specifications of the target plant.Model Transformation: The Design ProcessThe design process was considered as an iterative model transforma-tion from abstract level to detailed description. In Gero (1990), a sign prototypefrom alike design cases. In addition, routine design is viewed as a de-The sequence control program design described in this chapter is a. The refinement in the transformation is guided by input specifi-UTOMATICROGRAMMINGFOR functions, structures, behaviors, and relationships as well as expertiseabout plant control. The general knowledge is independent of the in-dividual target plant. Interpreting a machine specification, implemented in a target plant. In other words, the functions, struc-the specific model 1 in figure 6, so that expertise about plant control322MIZUTANIETAL Figure 6. Model Transformation and Refinement in In the next step, specific model 1 is transformed into specific model2 along a high-level control specification, that is, a composite-UTOMATICROGRAMMINGFOR Figure 7. The Plant Model. fied and stored in specific model 2. They are further refined to theprogram model (intermediate representation) using programmingDesigners validate specific model 1 with views of a simulation and adetailed specification format. If the transitional relations between ma-chine actions and states are not just as the designers intended, higher-Figure 7 illustrates a portion of the model of a steel plant. The genericSteelPlant is shown as the composition of two machines, Carrier andUncoiler. Forward is one of several possible actions of Carrier. The re-lation Qualify specifies the possible control speed for Forward, whichcan be executed at either LowSpeed or HighSpeed. BackwardLimit,MiddlePoint, and ForwardLimit are possible states of Carrier, withAfter specifying transitional relations conditioned by Forward. For ex-ample, a partial description of the class Forward is as follows:[ ForwardSUPER:MachineActionOPPOSITE:BackwardACTION-OF:CarrierCONDITION-OF: After1, After 2, After 3Qualified-by 1: LowSpeedQualified-by 2: HighSpeedHighSpeed] .Qualify, After, and Has-condition are conditional relations. They aredefined as a class in terms of domain primitives, and they have condi-tions and methods for constructing specific models. Qualify1 is one ofthe instances of the conditional relation Qualify. Qualify and Qualify1. Qualify and Qualify1SUPER:RelationORIGIN:MachineActionDESTINATION:MachineActionmethod:[É]324MIZUTANIETAL INSTANCE-OF:QualifyORIGIN:LowSpeedDESTINATION:ForwardHas-condition1:After1Has-condition2:After3Qualify1 is related to After1 and After3 by the conditional relations Has-condition1 and Has-condition2. Has-condition1 has the condition Load-ed, and if Loaded is true, Has-condition1 is actual. Has-condition2 has thecondition AccuracyRequired, and if AccuracyRequired is true, Has-condi-tion2 is actual. Thus, when a carrier is loaded at the beginning of an ac-tion, or accuracy is required at the end of an action, it must be driven atmethods to infer the actual states of the target plant. Thus, the genericThe specific model consists of two consecutive models. The first spe-cific model (Specific model 1 in figure 6) contains concrete descrip-tions of the target plant structure. After the environment of the targetplant is specified, the specific model is constructed and is referred toin all subsequent phases of the software life cycle. The basic struc-tureÑfor example, the physical construction, control relations, and in-dictionary that contains the basic vocabulary of plant control. The ma-chine Conveyor is an instance of Carrier, and UncoilerClamp is an in-stance of MaterialFastener. The machine Conveyor has the action Con-veyorForward driven by the actuator Sve01. The statesConveyorBackwardLimit, ConveyorPoint1, and so on, are detected bythe sensors Nle01, Nle02, and so on. A partial description of Conveyor-Forward is as follows:[ ConveyorForwardINSTANCE-OF:ForwardACTION-OF:ConveyorACTUATED-BY:Sve01HAS-SUB-ACTIONS: ConveyorForwardLow ConveyorForwardHighSTART-INTERLOCK: UncoilerStopRUN-INTERLOCK:(AND ConveyorLowerLimit(OR (NOT ConveyorCoil Touch) (AND ConveyorCoil TouchUTOMATICROGRAMMINGFOR The second specific model (specific model 2 in figure 6) contains atransitional relationship between actions and states of machines in theterpreting and refining a control specification using a dictionary andexpertise about plant control. ConveyorForwardLow and ConveyorFor-wardHigh are concrete actions of Conveyor. The relations cause andenable specify the transitional relationship between actions and statesof Conveyor. The cause links an action to a state. It specifies that theexecution of a specified action results in a specified state. The enablelinks a state to an action. It specifies that a specified state enables aSpecification ValidationThe symbolic simulation (Fox 1987; Reddy and Fox 1986) enables de-signers to validate specifications by testing for errors or omissions. Thedescription of the machine action, the machine state, and the transi-tional relations between them in the specific model represent the de-tailed machine behavior of the target plant. The system simulates anexpected machine behavior by tracing these transitional relations, thatto programming knowledge. The programming knowledge is imple-mented in an object-oriented style of programming, with objects repre-mented in an object-oriented style of programming, with objects repre-SUPER:ProgrammingKnowledgePATTERN: (BETWEENIt has a program pattern that means Òin a period between acceptinga start order and detecting a stop sensor, provided the interlock condi-326MIZUTANIETAL tions hold, output an on signal to the actuator that drives the targetmachine.Ó The object sends a message to lower-level objects that pos-StopSensor, RunInterlock, and MutualInterlock) until an intermediate[ ConveyorForwardwardLimit; StopSensor: (AND(AND ConveyorLowerLimit(OR (NOT ConveyorCoilTouch)(AND ConveyorCoilTouch&#x Con;&#xveyo;&#xrFor;&#x-25.;瀀- (ON ConveyorForward)Each element is replaced by controller I-O signals, and finally, thefragment is converted to a target LADDERDIAGRAMSEQUENTIALFUNCTIONCHARTPart-Retrieval MethodProgram parts are retrieved by keys that consist of the operation devicetrieval function is implemented by the production system, which usesrules in the programming knowledge base. Retrieved parts are cus-Program parts are designed to be as small as possible, basically soare provided in the program parts to enhance their flexibility.tion, and most of their variables are global. Variables in different re-trieved program parts are required to be appropriately identified. Thisautomatic programming system attaches attributes, such as machinetaining identity.UTOMATICROGRAMMINGFOR control program design divisions in the Toshiba Corporation. Pro-grammable controllers are being applied to a wider range of work, andtheir functions are being upgraded and diversified. Thus, a design sup-stage of development, we decided that the design processes using should be close to the conventional ones. The sequence controlprogram design process was considerably analyzed, and the life cyclediscussed previously was established. We then decided what activities inthe life cycle could be supported by AI technology. This policy was onereason that the system was deployed smoothly.We used Wire and rod mill plant2.5K program stepsContinuous pickling line6.5K program stepsContinuous galvanization line90K program steps Continuous galvanization line15K program stepsof generated programs was compared with those designed manually.Some problems were found with the knowledge bases, the lack of pro-gram parts, and the inconvenient human interface. After these prob-Number of frames 2900 framesNumber of program parts 190 partsNumber of part-retrieval rules 320 rulesNumber of records (machine specifications)17K records Number of steps (control specifications)5.5K stepsTarget programTarget plantContinuous galvanization line Programmable controllerPCS-5000 (4 sets)Program size 90K stepsIt would have taken about 100 person-months to complete the targetprogram using the conventional technique. The total cost for software328MIZUTANIETAL development, including specifications and testing, was reduced by halfusing this system. The generated program was checked by both designexperts and a plant simulator. The achieved quality was satisfactory.changed, which, in turn, affects the control program specifications.When machine specifications are altered, the specific model is con-structed again. When control specifications are altered, the resultingThus, maintenance is performed by altering the specifications and re-plants, and it can be used for several different applications. A singledoubled design productivity. It took about 20 person-yearsthe system engineers, and 7 person-years by researchers. At the firstsign division for a few months to learn the design skill by themselves. ItThe system made the quality of programs generated by the expertsand others relatively uniform. However, it cannot be said that a system-the original developers can maintain the knowledge bases consistently.Maintenance has been continued by the original developers (re-quirements. Enabling designers to easily extend knowledge bases is theTenth International Joint Conference on Artificial Intelligence,UTOMATICROGRAMMINGFOR 552Ð558. Menlo Park, Calif.: International Joint Conferences on Artifi-Barstow, D. R. 1985. Domain-Specific Automatic Programming. Transactions on Software EngineeringBrown, D. C., and Sloan, W. N. 1987. Compilation of Design Knowl-edge for Routine Design Expert Systems: An Initial View. In Proceed-ings of the ASME International Computers in Engineering Confer-ence, 131Ð136. Fairfield, N.J.: American Society of MechanicalChandrasekaran, B., and Mittal, S. 1983. Deep Versus Compiled Knowl-edge Approaches to Diagnostic Problem Solving. International JournalDarington, J. 1981. An Experimental Program Transformation and Syn-Artificial IntelligenceFickas, S. F. 1985. Automating the Transformational Development ofIEEE Transactions on Software Engineering Fox, M. S. 1987. Constraint-Directed Search: A Case Study of Job-ShopGero, J. S. 1990. Design Prototypes: A Knowledge RepresentationGreen, C., and Westfold, S. J. 1982. Knowledge-Based ProgrammingKeller, R. M.; Baudin, C.; Iwasaki, Y.; Nayak, P.; and Tanaka, K. 1989.Compiling Special-Purpose Rules from General-Purpose Device Mod-els, Technical Report, KSL-89-49, Knowledge Systems Laboratory, Dept.of Computer Science, Stanford Univ.Lubars, M. D., and Harandi, M. T. 1987. Knowledge-Based Software De-sign Using Design Schemas. In Proceedings of the International Con-ference on Software Engineering, 253Ñ262. Los Alamitos, Calif.: IEEEComputer Society.Manna, Z., and Waldinger, R. 1980. A Deductive Approach to ProgramACM Transactions on Programming Languages and Systems Mizutani, H.; Nakayama, Y.; Sadashige, K.; and Matsudaira, T. 1991. Aplications, 124Ð128. Los Alamitos, Calif.: IEEE Computer Society.Nakayama, Y.; Mizutani, H.; Sadashige, K.; and Matsudaira, T. 1990.330MIZUTANIETAL Model-Based Automatic Programming for Plant Control. In Proceed-ings of the IEEE Conference on Artificial Intelligence Applications,281Ð287. Los Alamitos, Calif.: IEEE Computer Society.Neighbors, J. M. 1984. The Draco Approach to Constructing SoftwareIEEE Transactions on Software EngineeringOno, Y.; Tanimoto, I.; Matsudaira, T.; and Takeuchi, Y. 1988. ArtificialIEEE AIÕ88 Proceedings of the International Workshop on AI for In-dustrial Applications, 85Ð90. Los Alamitos, Calif.: IEEE Computer Soci-ety.Ramana-Reddy, Y. V., and Fox, M. S. 1986. The Knowledge-Based Simu-IEEE Software Smith, D. R.; Kotik, G. B.; and Westfold, S. J. 1985. Research on Knowl-IEEE Transac-tions on Software Engineering UTOMATICROGRAMMINGFOR