L.D Development

6.1 DEVELOPMENT OF SYSTEM

As outlined in the knowledge elicitation in chapter 5 the first stage of the system development was to represent the knowledge for the three pieces of equipment, each achieving the same results from different means, together with the knowledge needed to optimise a layout. This chapter describes how this knowledge was implemented in Kappa-Pc. The first stage was to integrate the technical programs and then control them so that the current layout could be optimised.

6.1.1 Technical Programs

When the expert is analysing a plant he uses mathematical models which simulate how different aspects of a Hot Strip Mill work. The two main programs which are used both run in DOS;

EHSM

This models the requirements of the mill to roll a specific piece / batch of strip ( see appendix C for input forms ). The program gives figures for loads, powers and temperatures for key parts of the mill. These figures can be reported to the system in two formats. These are as a file created by the

Chapter b - r .L .U .r . U ev elo p m en t system, in a form specified by the expert, which can be imported into a spreadsheet; or as the screen output redirected to a file.

The system uses both formats to retrieve data from the results. The Lotus format is read into the database which stores scenario data, using array facilities within the database. The file with the screen output is read into Kappa-Pc using its ability to read lines of text from a file. The program looks for a line which locates the results within the file. It then looks for the desired result in a specific position a predetermined number of lines after the locating line.

ENCO

This models the temperature drop between the Roughing stand and the first Finishing stand ( see appendix C for input forms ). The program is able to calculate the strip's temperature drop when 'Free Air' and 'Enco Panels' are used. The results of the temperature drop can be fed into EHSM allowing the use of Enco Panels to be evaluated. This is done by retrieving the information from the screen output in similar fashion as for EHSM.

It was decided to use the ENCO program to calculate the temperature drop with no heat shields even when Enco Panels were not being used. This means that if only one scenario used Enco Panels, the comparison of different layouts will use the same calculation approach.

The inputs for the technical programs were written to an ASCII formatted file, with values positioned in a form similar to the original

v_napter e> - r .L .u .r . d e v e lo p m e n t program written for a Prime minicomputer based system. The technical programs were written to read these inputs from a file, containing the values which model the mill, before it ran. The name of the file was entered by the user during program execution. This meant that the DOS version of the programs could not be executed remotely in their present form. They were modified by the Davy International (Sheffield) IT department so that the programs ran without asking for a filename by using pre-specified input files.

One of the first stages of creating the automatic optimisation program was to be able to interface the technical programs with Kappa-Pc. This involved creating an object that would be responsible for this task for each technical program. Each object requires slots for the inputs of the technical programs. A method needed to be created to write this information to a file, using a template, to produce the input files to the program.

To run the programs in DOS it was necessary to write a batch file which started the programs in the correct fashion and also displayed a message to inform the user of progress. The batch files were linked to a windows PIF file which allows the programs to run in a windowed format. This provides a better user interface than if the programs had been run in full screen, where the whole screen would change from Windows to DOS and back again.

When the program has been run under the control of the E.S. then the results have to be read back into the system, before the E.S. can proceed any further. Two approaches were needed because some of the results were

^napter o - r .L .u .r . d e v e lo p m e n t printed to the screen and other selected results were written to file. The results which were written to file allow the expert to read results he used frequently into the spreadsheet he was using for the current feasibility study.

The results were written in vertical column format which meant that the information would have to be read one line at a time if retrieved by Kappa-Pc. This could be achieved more efficiently with the use of the array facilities which are present in the database program Foxpro. This was chosen because it was the company's standard for PC databases. However the indices which this database produces are not compatible with Kappa-Pc. This does not cause a particular problem because for this application the database will only be required to hold a limited number of records, which are referenced via a unique title ( consequently indexing is not needed ). Each record holds the results of the corresponding output from the technical programs together with other selected inputs. These are inputs which are not part of the description of the equipment makeup or physical layout of the plan, for example the slab temperature leaving the furnace.

The plant description and equipment makeup are handled by the class 'PlantLayout'. The original description of the layout of the plant is stored in the class 'ControlScenario'. All other scenarios exist as instances beneath this class. The instances can then be modified as the expert explores the advantages and disadvantages of different approaches to altering the plant layout. Each of these different approaches or scenarios, will be evaluated using the technical programs and their results stored in the Foxpro database,

^napter e> - i .jl.u .jl . u e v e io p m e n t

see figure 6.1. The 'PlantLayout' object uses the title of the scenario, in the database, to link the layout knowledge with the performance data generated.

The use of a database means that the data for more than one scenario can be stored and retrieved as needed ( This process is described in Appendix D ). This minimises the number of instances that have to be used for storing data produced from the technical programs. The E.S. renames the old record and marks it for deletion for each technical program iteration. After the current layout has been optimised all marked records are deleted, ensuring the database only has one record per scenario. A separate database records the details of how the water curtains are used for each scenario, and is updated in parallel to the main scenario database.

Create

input file Batch file

Technical program used

Database updated

Values added to database. Each record using a pre­ determined 'Title' < WINDOWS DOS E.S. Database EHSM Instance EHSM Instance ENCO Instance Technical program

Create file E.S. is watching for Input file for

technical programs Output files: • Spreadsheet file • Screen re-directed to a file ENCO Update EHSM values EHSM Figure 6.1

Chapter 6 - r .L .D .r . D ev elo p m en t