Plant Layout Design Program System Design
6.1.3 Representation of the basic knowledge description for equipment This is done by defining the basic elements needed by each piece of
equipment in the 'PlantEquipment' object. It also contains the method which is used each time to clear slots used by the rule system. Any slot which is not to be cleared has its name stored in a list in each object, referred to during the clearing process. An example of this are the facts used to calculate the financial benefits for adding each piece of equipment.
^.napier o - r.L..u.r. i^ eveiop m em The m enu for getting the cost information, needed to calculate financial benefits, is automatically created each time the system is started. This ensures that the menu will contain any future equipment objects. The menu uses the same session window to get the cost information for any piece of equipment, the object associated with the image is changed to suit.
6.1.4 User interface
This can form a significant part of an Expert Systems development, e.g. in the Dipmeter Advisor it formed 42% of its lines of code (Dym et al, 1991). Expert systems need to more than a black box which outputs answers, they need to justify their choices. As a result the interface should be intuitive to the user, together with being forgiving any mistakes they make (Microsoft Corporation, 1992). This next section describes how the interface was created for the Plant Layout Design System.
When the user enters information to specify the initial conditions of the mill this is done through a series of input windows. These are accessed through named buttons, shown in figure 6.2 which shows the User Interface before the mill details have been entered. Each button shown on the screen represents a group of associated information needed to describe the mill, mainly needed for the technical programs.
The data entered in the User Interface, via Edit images, is stored in the relevant object and slot pair. For instance, the information for the technical programs is stored in the EHSM instance and saved as a database record.
^.naprer o - r .L .u .r . u e v e iu p m e iu This is satisfactory if all the values modified for each scenario were stored in a database, which could update the object whenever the user wished to view a different scenario. Some of the information about the scenarios is stored in different objects. This information describes the layout of the mill, equipment present, roll diameters and motor powers. The object called 'ControlSenario' records the initial details of the layout. These are inherited to instances which record the changes to the layout for each scenario. Each time the user changes a scenario the interface needs to update which of the layout objects they are using. To do this a class of image objects were created, e.g. PLEdit. These objects contain the interface tools for editing the scenario data. The object which holds the current scenario data was declared at class level rather than individually defined for each instance. These images then have to update their links to get the object and slot pairs current values. This is handled easily by resetting the links for the instances in this class.
This process is handled by the class 'Display' using the instance PLDisplay. As soon as the scenario is changed the value of slot in this instance, containing the name of the object which represents the new scenario, is updated. By changing the value of this slot, a m ethod fires automatically to update all the links for the edit images, which alter with the change of scenario. This looks at an internal list which contains the names of the 'Edit' classes. The name of the object scenario is altered at the class level for each 'Edit' class which in turn updates its instances.
^napter o - r .L .u .r . d e v e lo p m e n t Initially the buttons are white to signify that no information has been entered in this area. The buttons change colour when the input window has been accessed. This was set-up to try to create a visual way of highlighting the completeness of the information input, without looking at the input screen. If there was a way of identifying the minimum information needed for each section, then their colour would only change when it was present. This has not been done because the amount of information needed by the technical programs varies with the layout, making it a complex problem with limited benefits.
File Control Equipment Exit
Roll Tem perature 100
Number of R oughers [3
Number of Finishers fij D ista n ce s B etw een |
= Equipm ent j Work Roughers Roll Radii \f
> Roughing Mill I
‘ ‘ ' |
Roughing M8i Finishing Mill
P ow ers j
Finisher Product
Details R ougher Product D etails
Slab / Product
Details Additional Equipm ent j ]
Plant Details Initialise Mill Madt*
ED Rule Inputs EH Show R eport
Figure 6.2 Once all of the information needed has been entered the user then initialises the Mill Model. This will only be successful, when EHSM runs
cn a p ter b - r .L .u .r . d e v e lo p m e n t without crashing, when all of the information required by the technical programs has been correctly entered. When using external programs there are two ways to ensuring the data received is complete. This is to ensure the input is correct, which requires an intimate knowledge of the system, or by checking that the output received is okay. The system assumes the person using this system will ensure that all of the inputs needed are present before they initialise the mill or optimise a layout. The results are checked before retrieval by Kappa-Pc ( see section 6.1.1 ). If the technical programs have run correctly then the mill model is initialised. The User Interface is then altered to allow the user to experiment with the mill layout. Figure 6.3 shows the interface after the mill model has been initialised.
I
File Control Equipment Scenario Exit
Scenario Under Investigation
Approach used for optimisation Fjtpiipmftiit S elected : A M W R AGC D iagnose Workings olution Current P aybacks Throughput Equipm ent R eturn On Investm ent Optimisation Layout Roll T em perature [70. Number of R oughers pj Number of Finishers [7
.D istances B etw een
j Equipm ent
Roughing Mill Equipm ent Roughing Mill
Pow ers
W ork Roll Radii 1 R oughers
-_____________I
W ork Roll Radii Finishers Finishing Mill
Pow ers
, Finisher Product 1 R ougher Product
D etails j
' Slab 7 Product
j D etails AdditionalEquipm ent
Plant D etails
CD Rule Inputs Q Show R eport
cn a p ter b - r .L .u .r . u e v e io p m e n t A report is constructed as equipment is added to the current scenario, which can be displayed each time a piece of equipment is added, by checking the show report box. The report list all equipment added to the mill, together with the financial benefits which it offers.
After the mill model has been initialised there are other inputs which describe aspects which can change how the mill is altered. These are essentially inputs for parts of mill knowledge which are represented using rules.
▼ a
Return P ag e C lo se
EH
The strip is sold as Deep drawn steelEH
The strip is sold as tin platef~l
The strip is used on heavy gauge for structural useEH
Uniform metallurgy required for high strength steelsEH
Material sold as hot band / Pipe stockPageUp |; PageDown |
Figure 6.4
Some of the inputs into the rules are by the checking of points listed on pages of special input windows ( Figure 6.4 ). The pages created include "Mill Problems", "Customer Requirements" and "Mill Details / Aims".
cn a p ter b - r .L .u .r . u e v e io p m e n t The user is prompted for these questions each time the rules are fired. Figure 6.5 shows that when the user presses the diagnose button they are prompted with a menu asking either for additional information or to fire the rules. The use of the menu ensures that the user is prom pted in a gentle fashion each time the rules are fired so that they consider entries for the "additional information" window. Many of these questions will only need consideration when initially describing the mill layout.
F ile C o n tro l E q u ip m e n t S c e n a r io E x it
Scenario Under Investigation
Approach used for optimisation
Fi|iiipitn»nt S elected :
W orkings olution
Current P ay b ack s
Roll Tem perature |70.0j
Number of R oughers |jj |
Number of Finishers I7 I
Throughput
D istan ces B etw een Equipm ent R oughing Mill
Equipm ent
W ork Roll Radii R oughers W ork Roll Radii
Finishers
A M W R Equipm ent
R oughing Mill
Pow ers Finishing Mill P ow ers
AGC R eturn On
Investm ent
Finisher Product
D etails R ougher Product D etails
Slab / Product
D etails AdditionalEquipm ent
D iaqnose
F ire R u le s Plant D etails
|~1 Rule Inputs Q Show R eport
Figure 6.5 Initially routines were written to translate the TRUE / FALSE values generated by the CheckBox into the values used by the rules. The later rules were constructed to use the syntax of the CheckBox.
en a p ter b - r .L .u .r . u e v e io p m e n t 6.1.5 Integration of optimisation programs with technical programs
The 'Translation' class translates the aim of the optimisation into numeric value change. It changes the textual requirements to increase slab length to a value entered into the technical program. These changes are then relayed to the appropriate technical programs which are used to model the changes. At present this class is only used as an intermediate to the EHSM program. The class has been laid out so appropriate translation procedures can be incorporated for other programs if necessary. This is implemented at present by ensuring any change of the control variable is done via the top level object in the Translation class. This change would then be inherited to any sub-class which needed the information. The process of updating the technical programs is then done by informing the 'Translation' object which control variable should be altered, this name corresponds to a method name which effects the appropriate change.
The object which does the translation between the optimisation object and the technical programs is the instance 'Intermediate'. This instance representation and behaviour is defined in the class 'EHSMLink'. This approach separates the implementation, 'Intermediate', from the functional, 'EHSMLink', which helps during development / maintenance. This ensures that it is clear which slot values have a purpose for the implementation and which are generated during the programs run. The class also deals with the translation of the numeric results into semantic descriptions, e.g. that the
L.napter b - r .L .u .r . u e v e io p m e n t