implementing a model-based generic user interface for computer

1

Implementing a model-based generic user interface for computer integrated manufacturing systems

R P Monfared, A Hodgson, B A Bowen and A A West MSI Research Institute, Manufacturing Engineering Department, Loughborough University, Loughborough, Leicestershire

Abstract: Computer integrated manufacturing (CIM) systems are complex in terms of performing a variety of activities, maintaining a range of information and involving various classes of users with differing levels of knowledge and skills, and different levels and time spans of decision making. Much investment and effort has been made to formalize and automate the performance of the CIM elements in a manufacturing system. However, each CIM subsystem will typically have its own terminology, procedures and presentation formats. This places a heavy and unnecessary burden on users, resulting in frustration and reduced effectiveness. Research has been carried out by the Manufacturing Systems Integration Research Institute at Loughborough University towards the generation of a user-oriented interface for CIM systems. This research has resulted in a conceptual approach, which incorporates a generic user – task model, which enables the generation of flexible and reusable software components to form a semi-generic user interface for CIM users. The CIM user interface provides presentation tools to monitor and control the performance of the CIM elements. Advanced modelling and integration technologies have been deployed to enable the system to cover a wide area of manufacturing domains. These technologies include modern manufacturing modelling architectures such as CIMOSA and GERAM, and advanced communication techniques such as those used by Web-based software applications in manufacturing environments. The implementation issues of the generic user interface concept, together with its application within an industrial case study are discussed in this paper. Keywords: CIM user interface, user model, generic task, common user interface, Web-based application 1 INTRODUCTION Many practical implementations of computer integrated manufacturing (CIM) systems involve human elements in a wide range of activities [1]. It is increasingly accepted that effective use of the human resource, and not only technology, is a key element in the success of manufacturing enterprises [2]. Although the effective performance of the human resource is now widely recognized as key to the efficient operation of CIM implementations [1], to date only limited support for human factors has been offered by CIM information and control systems. In consequence, CIM users are typically inadequately served by these systems, e.g. receiving insufficient, inadequate, excessive, unnecessary or irrelevant information, or information at the wrong level of detail, in the wrong units or over the wrong time period. In addition, terminology, procedures and presentation are typically inconsistent across the set of CIM subsystems. As CIM system complexity increases, the problem will worsen with regard to the complicated human relationships with various CIM elements in terms of functionality, data and user needs. Some manufacturing control systems and modelling methods [1, 3] do include techniques and methods to provide appropriate information for the users. However, there are still problems with regard to the presentation, interaction and access restrictions of data for different user classes. These problems include unsuitable levels of information depending on the position of the user within the organization, various interaction and data exchange formats, inconsistency of different legacy systems and lack of appropriate integration techniques [4]. A coherent model-based presentation system is required to provide appropriate user interfaces for CIM users with appropriate integration to the relevant information sources. The presentation system should be placed between the users and the CIM systems and facilitate the users’ understanding of the system by providing a properly formatted user interface for each class of user, considering the user needs, abilities and skills. The presentation system should also be able to realize the CIM user requirements in terms of the information needs, human user perceptions and individual interface requirements and preferences. The presentation system should also be able to recognize the functional and informational elements of the particular CIM systems and be capable of interacting with them. Research into a generic user interface for CIM environments, undertaken at the Manufacturing Systems Integration Research Institute at Loughborough University, proposes concepts and methods to design and construct flexible, reusable and semi-generic software components for the user interfaces of a particular enterprise domain, by

2

introducing and implementing a manufacturing user – task model. This user interface unifies the interaction methods with the CIM elements via the application of Internet-based communication and knowledge exchange methods. 2 INTEGRATED PRESENTATION SYSTEM: THE CONCEPT The purpose of the CIM integrated presentation system (IPS) is to provide the means by which a common CIM user interface can be constructed. The common user interface provides consistency of terminology and presentation to a particular class of CIM users across the range of software systems that he/she is authorized to use. It is proposed that existing user interfaces should be gradually replaced with the common interface, constructed via the IPS. The IPS proposes an additional view for CIM users, who have been previously regarded as both functional and authority elements in many CIM environments and manufacturing modelling architectures, e.g. National Institute of Standards and Technology [5] and GERAM [6]. The integrated presentation system includes three major parts: firstly, the user – task model, secondly, the interaction model and, thirdly, the final end-user interface (UI), as illustrated in Fig. 1. The user-task model provides descriptions for the common tasks carried out in a particular domain of manufacturing systems, the various classes of user in that domain, and the relationships between tasks and users. The interaction model maintains a consistent interaction among the system entities within the IPS. These include the user- task model, final end-user interfaces, existing manufacturing models, reusable software components, CIM elements and supportive information systems. The final end-user interfaces are common user interfaces generated by the interaction model to be used by CIM users, considering the task and user requirements defined in the user – task model. The following sections discuss the IPS terminology in detail.

Fig. 1 Integrated Presentation System concept

2.1 User-task models The ‘user-task model’ part of the IPS concept provides descriptions for the stereotyped users and tasks involved in a semi-generic manufacturing system. The user-task model consist of a user model and task model in two levels of generality (for stereotype and profile levels, see below), and the user and task linkages model. The coverage of the user-task model could include generic, semi-generic and specific levels of manufacturing domains. To obtain the model generality required for meaningful research results and yet to maintain a sufficient level of detail for application realism, the research has focused mainly on the semi-generic and specific level of manufacturing systems, the so-called stereotype and profile levels. The user- task relationship model specifies the dynamic interactions between users and tasks within the stereotype and profile levels. A schematic diagram of the user – task model developed consisting of the user model, the task model, the user – task relationship model at stereotype and profile levels is illustrated in Fig. 2. A comprehensive discussion about the user- task model developed in this research has been given in reference [7].

3

Fig. 2 Sample user–task model for semigeneric manufacturing domain

2.1.1 Manufacturing user model The manufacturing user model is generated largely from a stereotype ‘job role’ hierarchy, defined for a generic manufacturing system (see Fig. 2). A manufacturing user model can be structured on the basis of task orientation or user orientation. A job-oriented (or task-oriented) user stereotype approach introduces the user in terms of the class of jobs that he/she may carry out such as ‘shop-floor manager’, whereas a user-oriented approach is more concerned with the personal aspects of the users, for instance age group and education level. The first approach has been implemented in this work to provide consistency with existing manufacturing organizations. The user stereotype consists of the following: 1. User description. This is a textual description of the class of manufacturing user in relation to his/her job. In this research the descriptions have been extracted from the Dictionary of Occupational Titles [8] with some modifications based on the result of interviews and questionnaires. 2. Stereotypical properties. These contain information about the stereotype and feed into an individual user profile. 3. Interface requirements and preferences. These properties specify the job-role stereotype needs and preferences on the format of the final individual user interface presentation. This facilitates the generation of the software components (and initial status of the components) according to the user perceptions. A comparison between the above manufacturing user model approach and existing approaches of general user modelling approaches [9] has been made by West et al. [7]. The user profiles contain specific values of the stereotype properties, which are inherited from the job-role stereotype hierarchy. 2.1.2 Manufacturing task model The task model consists of a hierarchically structured set of tasks which are required to be carried out in a specific domain of a manufacturing system (see Fig. 2). The task model contains the stereotype of the tasks and their instan-

4

tiations as task profile structures. The tasks have been defined on the basis of the commonality of activities in a particular domain. It has been intended to maintain the generality of the tasks (i.e. supporting a wide range of the manufacturing classes) together with an appropriately detailed knowledge of particular tasks, to improve the feasibility and practicability of such tasks. Three different sources of information have been considered in order to determine the stereotype tasks:

(a) Structured interviews, which study the users’ points of view;

(b) Knowledge and expertise including for manufacturing activities (e.g. manufacturing reference models [5]) and experiences of system developers which may be based on the system user requirements and some extensions to improve them;

(c) Manufacturing modelling architectures, which are the methods to formalize the tasks (or processes or activities) and utilize (a) and (b) to provide knowledge required to populate their formalized structure. One example of these modelling architectures is CIMOSA [1], which provides a high-level process model (i.e. partial and generic) to support a range of particular manufacturing tasks. The structure of the semigeneric (or partial) manufacturing task stereotype used in the task model has been adopted from semigeneric tasks introduced in [10]. The task stereotype consists of the following: 1. Task description. This is a textural definition for the task defined by the existing manufacturing function models and used by the IPS model. 2. Hierarchical position description. This specifies the position of a task in relation to the other tasks in the hierarchy, in order of performance. 3. Reference to the supportive information system. A set of information objects and data retrieval descriptions, according to the global schemata, which have been associated with the task stereotype to provide the required data during the operation of the task. The format and structure of the data depend on the existing information systems in the manufacturing domain [11]. 4. Reference to the templates and components. The templates and corresponding software components (discussed in Subsection 2.2.1) are addressed by the task stereotypes. The task stereotype hierarchy is instantiated by several particular level tasks, as task profiles. A task profile contains the real data about the task, which should be carried out in an industrial activity. 2.1.3 User-task linkages model In order to maximize benefits from the user model and task model in the generation of the common user interface, these models should be linked to each other. The linkages are required at both the stereotype and the profile levels of the models. The linkages at the stereotype level address a set of stereotype tasks, which can be performed by a particular user type. In the interaction model, these linkages are used to specify a number of software components, which need to be selected to provide the final user interface for a particular user class (see Fig. 1). The linkages have a different usage at the profile level. At this level the dynamic linkages provide a flexible human resource allocation (and physical resources allocation via manufacturing models) to the tasks and determine who is responsible (and capable) of doing a task or authorizing it. 2.2 Interaction model In the IPS concept, the interaction model has a major role in establishing a consistent interaction between the IPS elements and the CIM elements together with an information system, which provides the information requirements of the system elements (see Fig. 1). The interaction model generates and implements the software components to structure the final user interface, by recognizing the task model attachments to the software components, and required information objects. It also specifies the access restriction rules imposed by the user model during the generation of the final user interface. The interaction model manages the identification processes when the end users access the system and generate the final user interfaces. A wide range of integration infrastructure systems can be utilized to establish a consistent communication and data exchange method across the system. These methods include manufacturing data exchange methods such as STEP [12], MMS [13], CIMBIOSYS [14] advanced distributed object methods [15, 16], agent-based technology and unified communication methods such as KQML [17] and the Internet (or Intranet) with secure hypertext mark-up language (HTML) and TCP/IP protocol [14]. The research has been focused on the Internet-based communication systems. The

5

major issues of the interaction model are the creation and the implementation of the ‘templates’ and the ‘software components’, which are described in Sub- section 2.2.1. 2.2.1 Components and templates

The final end-user interface been decomposed into modular components to improve its manageability and reusability [18]. The components are atomic blocks of software applications. In this research, a structure based on, firstly, generic tasks and, secondly, user properties, is used for constructing the components. Each component is related to a unique stereotype of the task in the task model. It is actually a structured piece of information, which is implemented as a software application and enables users to carry out the corresponding task. The components may use similar sources of data to represent a task or subtask in different ways (with various levels of detail), with respect to the user requirements. The components may also provide different optional formats of data representation, suitable for various classes of user (e.g. diagrams for managers, and tables for operators). The components should be able to support system functionality such as executing a scheduler application tool, and presenting and manipulating system information. Templates have been created to facilitate the generation of the above components. The templates are used as a guide- line in association with the other user interface building issues to help to design components. As depicted in Fig. 3, the templates are created on the basis of the task model for the specific domain of manufacturing systems, information required for the tasks, the user model to limit the presentation format and details for particular classes of users, and a general knowledge of building graphical user interfaces and software engineering [19]. Each template offers a capability to demonstrate adequately its associated task stereotype as a component of the final user interface.

Fig. 3 Generation of user interface components based on generic tasks

The basic format of components created via templates hasbeen designed in accordance with typical user interface requirements for particular tasks provided, firstly, by inter- viewing the users [20], secondly, by reviewing user interface standards and guidelines [19] and, thirdly, by the knowledge of experts. The information provided by the user model is encapsulated in the templates. This information restricts the accessibility and level of granular- ity of the data represented by the component, based on the user stereotypes. In addition, it provides information about the user preferences and options, as defined by the user profiles†. The components may be generated by using a number of graphical user interface builders (e.g. Visual Basic [21], Xwindows [22], Java [23] or Web application builders [25]), subject to the condition that they can maintain integration and interoperation capabilities among the components, and interactions with data storage systems.

6

3 EXPERIMENTAL APPLICATION OF THE IPS To examine and demonstrate the results of the research, a set of application toolkits has been developed to study the applicability of the concepts in manufacturing sectors. Application software currently used in a typical manufacturing system varies widely in terms of interaction with users, communication with each other, and hardware and software requirements. The basic criterion in selecting and developing application tools for implementing the IP concept was the ability to provide application requirements for these manufacturing systems [15, 25], such as: (a) the ability to perform in a multiplatform environment, (b) the reusability of application components, (c) the ease of communication among the components, (d) uniformity and consistency, (e) security and restricted accessibility and (f ) scalability. To meet the above application requirements, two different types of application toolkit were required: the tools to be used by manufacturing end users; the tools to be used by system developers to generate and modify the end-user tools. Figure 4 illustrates these toolkits with a description of the potential application software, which can be used to develop the toolkit.

Fig. 4 Demonstrational application toolkits

The system developer toolkit includes a graphical representation tool to demonstrate and manipulate the user – task model, a library of the pre-defined software components, and the interaction tools to recognize the end-user identity, to retrieve appropriate user and task properties from the user – task model, to select a set of software components from the library, to arrange the display layout, and to generate the final end-user interfaces. The system developer tool is supported by the IPS information system containing the information concerning the user – task model, integrated with the existing manufacturing information system. The end-user tools make up the final user interface, commonly formatted to be used by a class of CIM users. These tools communicate with the CIM elements via an interaction system provided by the interaction model. Further, the final user interfaces could be intended to be supported by a natural language query system [26].

7

In this research, Web-based applications [27] were selected and implemented to support many of the above application requirements. Using Web-based applications facilitates the portability and integration aspects of the tools [28]. However, such applications are limited in terms of their graphical user interface capabilities and speed of performance. The end-user applications have been designed to be used by the common Web browser. Nevertheless, Web-based applications eliminate the necessity of installation and maintenance of an individual application toolkit for each host connected to the main control system. In addition, the system resources (and, consequently, workloads) can be distributed over a number of computer systems. This clearly increases the scalability of the system [29]. 3.1 Demonstration toolkit The specific objectives of the demonstration tools are: (a) to demonstrate the generation of the end-user interface based on the components, (b) to clarify the users’ roles in constructing the user interface, (c) to qualify the use of generic tasks in structuring the user interface and (d) to show the improvements that can be made in the management and control of manufacturing organization data by using the concepts developed in this research. 3.1.1 The process of interface generation Automated interface generation is the ultimate target of the IPS concept. The interaction tool (see Fig. 4) is responsible for creating the appropriate interface for a particular user, when he/she logs into the system for the first time. The logging information, interface configuration and the individual user preferences are recorded when a new user logs in. The interaction tool reloads the interface every time that the same user logs in, provided that the initial states of the system have not been changed. If change occurs in the user or task profiles, the interaction tool will re-generate the user’s interface. Regardless of task and user considerations, all user interfaces have been split into two parts, navigation and presentation. The navigation part provides quick access to the tasks that the user is currently interested in. The set of tasks that the particular user is linked to is displayed hierarchically, mimicking the structure of the task stereotype hierarchy in the task. Each task listed in the navigation part is associated with a component that is activated in the presentation part of the interface. The presentation part displays the interface component and information associated with the task instance currently of interest. The method of information retrieval depends on the user interface designer application. As the user interface generation flow chart illustrates (Fig. 5), when a new user logs in to the system, the identification information is received by interaction tool. The interaction tool locates the user name in the user profile model to determine the interface requirements (or rejects the user if the identification information is wrong). The user identification information is checked in the user and task profile model to approve access to the system and to specify the user preferences. The information is also verified by the user-task model at the stereotype level, to specify the necessary information objects required to process the tasks and also to specify the appropriate set of software components needed to carry out the tasks. The interaction model then generates the navigation part based on the selected tasks. The navigation part provides appropriate references to the relevant software components for each task, executing in the presentation part. The data displayed in the presentation part is restricted by the user stereotypes in terms of its format and level of detail (see Section 2.2). The layout of the information in the presentation part of a particular user’s interface can be configured to take account of a number of preferences that the user may have. Information about these preferences is stored in the relevant user profile. Preferences can modify basic display properties (e.g. colour or font size) as well as the interface layout. They can also determine the initial state of the interface. An additional responsibility of the user preferences is concerned with unnecessary tasks that need to be excluded from appearance in the navigation part (and, by implication, in the presentation part) of a particular user’s interface. For example, a huge grinding machine bed manufacturer may not need (or want) to do the ‘monitoring job’ task because the manufacture of such a bed might be an infrequent job or the job might take so long that there would be no point in monitoring it. Tasks such as this can be ‘clipped’ from the interface if necessary. The layout management unit, as part of the interaction model, is responsible for positioning the software components on the monitor screen within the presentation part. The component positions can be determined based on the user preferences. The system developer is able to rearrange the interface layout and to save it together with the other user or

8

interface preferences. This layout can be reused each time that the particular interface is used with no change. A more advanced method to locate the components is to apply a tiling algorithm to position the components on the screen [30]: Given a set of display components and some information about how they are related within the task, three separate algorithms are invoked [30]: 1. A tiling algorithm initially decides upon which display components should be neighbours. 2. This information is then converted into a series of coordinates for more precise layout of the display components. 3. A final algorithm converts coordinates into nested rows and columns that are suitable cells of an HTML frame; the display components are found on HTML pages that are referenced by the HTML frame.

Fig. 5 User interface generation flow chart (DB ¼ database) 3.2 A prototype set of common user interface tools A prototype system was built to validate the common user interface concept in practice. In this experimentation, the applicability and benefits of implementing such a generic interface were examined by developing a prototype toolkit based on the IPS concept. The toolkit was designed to demonstrate the capability of the interface in terms of meeting the end-user requirements, defined by the project collaborators. A number of application tools were developed to implement the IPS concept. A graphical application tool was designed to construct and manipulate the user-task model. This application is integrated with the existing data storage system and attaches necessary database structures to the database system and populates them. The interaction toolkit was built to represent graphically the interaction model and to generate the final user interfaces, utilizing an Internet-based application and communication approach. The Internet-based interaction toolkit contains an Internet service provider, Web server application, Web-load distributor, dynamic Web page generator, Web browser, database access

9

provider and relational database system. The technical issues of generating the tools, developed for this experimental case, are described below. 3.2.1 User– task model graphical presentation The user-task model graphical presentation (UTGP) tool is a Windows-based software application, running on typical Pentium personal computers (PCs), that allows system developers to create, modify and manipulate graphically the user-task model. A graphical user interface builder was required to generate this tool and to manipulate the data storage system. This stand-alone application tool was developed using the SQLWindows software package (marketed by Gupta Corporation Limited [31]). The UTGP tool provides the graphical representation for the stereotype and profile levels of the user model, task model and user – task relationships, in three different windows as shown in Fig. 6. This figure shows a semi- generic user and task hierarchies, adapted [10] and configured for this work. The hierarchical structure of the user or task provides an easy navigational method to choose a particular item and the corresponding properties and values. For instance, by selecting a task stereotype (see Fig. 6a), the stereotype class (e.g. ‘schedule cell’), superclass (i.e. ‘task allocation’), class properties and values and the inherited properties can be displayed. In the case of selecting a multi-inherited class, the superclass item in the interface will indicate all classes that the selected item will inherit properties from. In addition, the property frame in the interface will display a collection of the properties inherited from all superclasses. The UTGP tool also provides means to create and manipulate user – task profiles. The profiles are instantia- tions of the stereotypes. As illustrated by Figs 6a and b, selecting a user or task stereotype causes the list of corresponding profiles on the related frames in the interface to be displayed. Selecting a specific profile results in the retrieval of appropriate property and property value information for that particular profile. The properties and values can be modified through the same tool by authorized users (i.e. system developers). Figure 6c demonstrates the user-task relationships in two levels of stereotype and profile. The interface splits into two frames. The first frame lists the users defined at the stereotype or profile level and displays the tasks that should be (or can be, at the stereotype level) performed by the particular user. Clicking on a task causes the properties of the selected user – task relationship to be displayed. The properties include the relationship type (e.g. perform or authorize [32]), the expertise level of the user who should perform a particular task, and the frequency of operation of a task by a particular user. The UTGP tool implements the Open Database Connectivity (ODBC) and SQLBase formats [33] for the database systems and can interact with many more database formats including Oracle and Ingres. The database structures have been generated using SQL Windows software for SQLBase format and MS-Access software for ODBC compatible format. The database system has been shared with the other applications including the run-time end-user interface toolkit (see below).

3.2.2 Internet-based end-users application toolkit The main concerns behind the development of Internet- based application tools were to provide a scalable implementation system to handle and distribute reliably the interactions load into the system resources, a secure communication system with wide geographical coverage, and a consistent interaction and set of data exchange methods compatible with existing manufacturing applications. A wide range of commercial user interface designer tools could be used to generate the end-user application toolkit (EUAT) and achieve the above requirements. For instance, many graphical user interface (GUI) builders, such as Visual Basic or Visual Cþþ and suitably empowered Web browsers, could be used. The implementation outlined in this paper has used an Internet-based user interface (HTML with Java [23], JavaScript [23] and CGI enhancements [34]). This is because such an approach provides good control and accessibility for various types of user in a large number of locations, as well as being portable (platform independent). These are important features in a manufacturing environment, which enable a better match with the legacy systems. The EUAT is a combination of software packages, cooperating to provide the final end-user interface in an Internet-based environment. EUAT was developed in the Windows operating system environment; however, it can be operated on any other platforms. Figure 7 illustrates a snapshot of the real-time execution of the EUAT developed for the case study in an Internet- based environment, together with the associated application tools. The computer hardware used for the generation of this toolkit included one Pentium PC for implementing the UTGP tool and database interactions, and a further Pentium PC for the distributed Internet-based interaction system, connected via a local area network (LAN) and the Internet. The data storage system is distributed across both PCs to demonstrate the remote data access capability. The final end-user interface can be utilized via any graphical computer system with an Internet browser.

10

509

Fig. 6 User–task graphical presentation tool

11

Fig. 7 Real-time execution diagram for the end user application toolkit

The software of the EUAT consists of the following:

1. Internet service provider (ISP). The Internet connection is an essential part of the EUAT to provide a communication protocol between nodes. The connection could be permanent (integrated services digital network (ISDN) [35]) or temporary (dial-up). For a geographi- cally limited version of the toolkit, the Intranet [36] protocol can be used to provide a secure communication system.

2. Web-server application. A Web server is the computer program that serves requested HTML pages or files. Examples of commercial Web servers include Netscape Web server, Microsoft Web server and CGI-family servers. The Web server software package used in this prototype is WebSite Pro (from O’Reilly Corporation Limited [37]), which is a CGI Internet server.

3. W Web-load distributor. This application includes a number of tools to assist in distributing the Internet transac- tion load among different computer resources to ensure real-time access to the system. In high-volume Internet interactions, using alternative resources (e.g. several Web servers or database systems) is a critical issue. The Centura Web Developer Application Console [27] and ForeSite [29] software packages (Centura Corpora- tion Limited) have been implemented to provide services required by the EUAT. The ability of these software packages to implement several Web-server tools (together with the Web-load distributor applications) enables the system to handle high-volume interactions in a complex manufacturing system.

4. Dynamic Web page generator. To provide the most recent and reliable information for manufacturing end users, the interface needs to be readily updated. There- fore, the end-user applications require the use of a dynamic HTML page technique. There are many technologies for producing dynamic HTML, including CGI scripts [34], Server-Side Includes (SSI) [38], Cookie [39], Java and JavaScript [23] and ActiveX [40]. To generate dynamic HTML pages in this prototype, a CGI script-based application, called Centura Web Developer, has been used. In addition, Java applets (Microsoft J þþ [41]) and Netscape JavaScript have also been implemented.

5. Web browser. A Web browser is a software application used to locate and display Web pages. Any Web browser which supports HTML 3, should be able to browse the final end-user interfaces, generated by the toolkit. Netscape and Microsoft Internet Explorer have been used to test the implementation.

12

6. Database access provider. Data required by users is accessed through the database server. The database server responds to queries from client machines (i.e. final end-user interfaces). These queries are formatted in formal SQL language [33]. Theoretically, the data repository systems can be almost any format and can be located at any place on the Internet or the LAN. SQLBase Server for Windows, ODBC and Java Database Connectivity (JDBC) have been utilized in the prototype. 7. Data storage system. The Centura Web Developer software package and Microsoft Access (based on the collaborator requirements) have been utilized to create the majority of databases used in the prototype. 8. Software component builders. A variety of commercial applications are available to be used for the generation of the components. Because of the use of the Internet- based applications, the final format of the components needs to be supported by Web browsers. In the case study, the Centura Web Developer package has been used for the HTML formatted components, and Micro- soft J þþ for the Java-based components.

4 A CASE STUDY APPLICATION OF THE PROTOTYPE TOOLS Common user interfaces to a quality inspection process (monitoring and control systems) have been developed for a local manufacturer using the IPS methodology. A description of the application is briefly given below. The company is a small to medium enterprise (approxi- mately 150 employees) and supplies punches and dies for the tabletting industry. The pharmaceutical and confection- ary industries are the major customers. The company is a market leader holding a substantial share of the home (70 per cent) and world (8 per cent) markets. Exports to 70 countries worldwide are supported. Cellular manufacturing strategies are applied throughout the shop-floor. There are 15 cells in all ranging from drawing, sales and scheduling (cells 1, 2 and 3) through manufacturing (cells 4 to 13) to dispatch and accounts (cells 14 and 15). Punches are manufactured from cylindrical blanks of raw material via a number of processes (cell 4, hob preparation; cell 5, coning, polishing, hobbing; cell 6, turning and trueing; cell 7, heat treating; cells 8 to 10, centreless grinding, undercutting, tipping, length grinding and finishing the punch head; cell 12, final barrelling and chrome finishing; cell 13, final inspection). Dies are manufactured separately in cell 11 (turning, drilling, spark erosion, honing, depth grinding and polishing) although the dies are also heat treated (cell 7) and undergo final inspection (cell 13). Every punch and die that is manufactured is currently inspected in the final inspection cell (cell 13), which is the focused area of this case study. This cell includes four inspectors and a cell supervisor who schedules and dis- patches jobs within the cell. The scheduling process is carried out manually or by using supporting scheduler tools. The cell operators report the inspection results to the cell supervisor in detail, and the supervisor provides a summary report for the quality-and-supply manager. If a part does not conform to the specifications, the quality- and-supply manager decides whether the part should be rejected, accepted or reworked (which may involve resche- duling the jobs and resources). Historically each of the individual manufacturing cells has ‘in-process checks’ on the critical dimensions (i.e. punch length, tip diameter, barrel diameter and die depth, bore and external diameter) but no formal application of statistical process control (SPC) had been applied. SPC is currently being applied throughout the manufacturing cells in an attempt to gain a deeper understanding of manufacturing processes and the problems that occur. 4.1 Problems The inspection operators, inspection supervisor, and quality-and-supply manager are all interested in the information derived from the SPC data. While performing different tasks and having different requirements for the presentation of the information, all the personnel require access to the same SPC system. An in-house-supported measuring and SPC system has been implemented by the company. While functionally capable of measurement, analysis and storage of the data, the software package does not provide a user interface that is appropriate for all the ‘stakeholders’ in the information, in respect to the format and depth of the information presentation. 4.2 Implementing the IPS approach In this case study the semigeneric manufacturing task and user hierarchies were instantiated to support the task of the final inspection cell, and the three user stereotypes involved in this case study (i.e. inspection operator, cell supervisor and quality-and-supply manager). The user and task stereotype models were populated by the real data, collected from the company inspection processes, to generate the user and task profiles. A set of prototype tools consisting of Internet-based reusable software components were developed for the final inspection cell. The prototype

13

tool operates in a Windows operating system environment and communicates with the users and external supporting tools (e.g. scheduler and SPC) through the Internet. Each end-user interface supports particular user preferences while executing a software component. Furthermore, the task profiles were defined to demonstrate the information required for a particular user class in an appropriate format and level of detail, as shown by Figs 8 and 9. Figure 8 depicts the process of generating end-user interface ‘remote scheduling’, starting from the user-task model, to the final end-user interface. The figure shows a part of the task model implemented in the case study and an example template for the task stereotype ‘schedule cell’, used by the user class ‘cell supervisor’. The associated templates for the task stereotypes define the required information objects for performing the task class (e.g. order object and tooling object). The templates also define the display formats and user restrictions for the particular task stereotype. Furthermore, the conditions of the performance (pre- and post-conditions) are specified in the templates by defining the other templates (and associated components) which need to be considered before, after or with the current template. In the example, the component associated with the ‘schedule cell’ template (T121) should be performed after the components associated with templates ‘cell capa- city check’ (T1211), ‘collecting static data’ (T12111) and ‘collecting dynamic data’ (T12112) and before performing the ‘remote scheduling’ component (T131). The templates are used by the system developers to generate corresponding software components and to construct the final user interfaces. Figure 9 compares the final interfaces for the quality-and- supply manager and the cell supervisor. The figure illustrates a common set of information retrieved from the SPC software regarding the job ‘heat treatment’ for two different user classes. Both interfaces access the same information and display data according to the related user stereotype properties. The quality-and-supply manager requires concise and statistically formed data, as well as the ability to access the detailed data in the form of diagrams and tables, whereas the cell supervisor requires to control the inspection data in greater detailed format. 5 CONCLUSIONS AND FUTURE WORK The lack of a consistent user-attuned interface is a major hurdle to the effective use of manufacturing information systems. A model-based IPS has been proposed, developed conceptually and implemented, utilizing a range of state-of- the-art software technologies. This system employs a job- role stereotype hierarchy to provide the basic details of user capabilities and task responsibilities. These combine with individually stated user preferences to form individual user models, which govern the access to, the processing of and the presentation of information to users. The IPS concept provides a methodology to generate a consistent user interaction system over a particular domain of CIM systems. The implementation of the IPS concept may impose extra effort to elicit the generic user and task requirements and to structure the stereotype models, although it provides significant benefits on: (a) rapidly generating user interfaces for new users, which are specialized for individual users, and yet simple to use, (b) improving the customizability of the end-user interface via the user preferences, to provide better match with the user requirements, (c) reducing the required user training and skills by cutting down the interface syntax which users need to learn, (d) increasing the agility of the system by significantly decreasing the time required for re-configuring the system resources, when users or tasks are changed, and (e) expanding the system in terms of widening the CIM domain coverage and users of the system. A prototype set of tools has been developed to enable system designers to construct and implement the user and task models and to generate the end-user interfaces. An Internet-based solution was used to improve interaction and information consistency across the system domain, in a heterogeneous platform environment, which proliferates throughout manufacturing enterprises. The industrially based case study has provided an integrated user interface for a number of employees within the company inspection area. This paper has discussed the generic user interfaces provided for the user classes of quality and supply manager, inspection cell supervisor and inspection operator, implemented in the ‘heat treatment’ cell within the company scheduling cell. Because of the company’s plan to apply a monitoring system for the inspection area, the implementation of the IPS methodology resulted in a significant reduction in the time and hence cost of providing operator-specific interfaces. The evaluation of the implementation at the collaborator site is currently ongoing, although initial feedback indicates that the staff prefer the IPS interfaces to the original interface of the proprietary system currently operated. Research issues which still need to be addressed include improving end-user interactions via use of a natural language query system and data security via the use of encrypted formats or dedicated domains, increasing the ability of the system to perform functions, when required, such as the remote control of manufacturing applications, consideration of human ergonomics and physiology in generating user interfaces to provide more appropriate interface style, and providing metrics to assess the improvement in the CIM systems by implementing the IPS concept.

14

Fig. 8 Process of generating the user interface from the user –task model to the final interface

15

Fig. 9 Comparison of the final interface, which manipulates the same data for different classes of end users

16

REFERENCES 1 ESPRIT Consortium AMICE. CIMOSA: Open Systems Architecture for CIM, 2nd extended and revised version, 1993 (Springer-Verlag, Berlin).

2 Ferguson, A. Britain’s best factories, management today, human centred CIM. Professional Engineer, 1989, 34–36.

3 US Air Force Integrated Computer Aided Manufacturing (ICAM) Architecture, Part II, Vol. IV, Functional Modelling Manual (IDEF), 1981 (Air Force Materials Laboratory, Wright –Patterson Air Force Base, Dayton, Ohio).

4 Harrington, D. T., Bound, J. P., McCann, J. J. and Thomas, M. Internet protocol version 6. Digital Tech. J., 1996, 8(3), 5–22.

5 Barkmayer, E. J., Hopp, T. H. and Rinaudot, G. R. Background Study - Requisite Elements, Rationale, and Technology Overview for the Systems Integrated for Manufacturing Applications (SIMA), September 1995 (National Institute of Standards and Technology, Maryland).

6 Bernus, P. and Nemes, L. Framework to define a generic enterprise reference architecture and methodology. Int. J. Computer Integrated Mfg Syst., 1996, 9(3) 179–191.

7 West, A. A., Bowen, B. A., Monfared, R. P. and Hodgson, A. User-responsive interface generation for semi-generic manufacturing system: a theoretical basis. IEEE Trans. Syst., Man, Cybernetics —Part A: System and Humans, 1998 (submitted).

8 US Department of Labor Dictionary of Occupational Titles, 4th Edition, 1977 (Government Printing Office, Washington, DC).

9 Rich, E. User modelling via stereotypes. Cognitive Sci., 1979, 3, 329–354.

10 Monfared, R. P. and Weston, R. H. The re-engineering and reconfiguration of manufacturing cell control systems and reuse of their components. Proc. Instn Mech Engrs, Part B, Journal of Engineering Manufacture, 1997, 211(B7), 495–508.

11 Jorysz, H. R. and Vernadet, F. B. CIMOSA, Part 2: information view. Int. J. Computer Integrated Mfg, 1990, 3, 157–167.

12 Owen, J. STEP, An Introduction, 1994 (Production Data Engineering, Information Geometers Limited, Winchester).

13 ISO TC 184 Manufacturing Message Specification, ISO 9506, 1988 (International Standards Organization).

14 Coutts, I. A. MSI Application Generation Libraries—Version0.5, January 1995 (Manufacturing Systems Integration Research Institute, Loughborough University, Loughborough, Leicestershire). 15 Millikin, M. Distributed objects: a new model for the enterprise. J. Data Commun. Tech. Tutorials, 1997, 26(2).

16 Emmerich, W. Introduction to OMG/CORBA. In Proceedings of the International Conference on Software Engineering, 1997, pp. 641–642 (IEEE, Boston, Massachusetts).

17 Finin, T. and Frizson, R. KQML as an agent communication language. In Proceedings of the Third International Conference on Information and Knowledge Management, November 1994 (ACM Press, New York).

18 Oblad, R. P. Applying new software technologies to solve key system integration issues. In Proceedings of JN AUTO- TESTCON, 1997, pp. 181–189.

19 Myers, B. A. User interface software tools. ACM Trans. Computer Human Interaction, 1995, 2(1), 64–103.

20 Burton, A. M. and Shadbolt, N. R. Knowledge elicitation. In Evaluation of Human Work (Eds J. R. Wilson and E. N. Corlett), 1990, pp. 321–345 (Taylor and Francis, London).

21 Franklin, C. Visual Basic 4.0, Internet Programming, 1996 (John Wiley, New York).

22 Heller, D. Motif Programming Manual, 2nd edition, 1994 (O’Reilly and Associates, California).

23 Wayner, P. Java and JavaScript Programming, 1997 (AP Professional, Boston, Massachusetts).

24 Kentie, P. Web Graphics Tools and Techniques, 1997 (Peach-pit, Berkeley, California).

25 Kobylinski, K., McLeod, R. D. and Shome, T. Design reuse in object oriented software architecture. In Proceedings of the IEEE Pacific RIM Conference on Communications, Computers, and Signal Processing, 1997, Vol. 2, pp. 993–997 (IEEE, New York).

26 Bowen, B. A. Natural language. Internal Report, ROPA Project, Manufacturing Systems Integration Research Institute, Loughborough University, 1997.

27 Ring, B. Developing with Centura Builders, February 1996 (Centura Software Corporation, California).

28 Stephen, E. WWW access to legacy client/server applications. Comput. Networks ISDN Syst., 1996, 28, 931–940.

29 Goodman, K. Integrating and Deploying Web Applications with ForeSite, February 1997 (InfoSpinner Inc., Texas).

30 Bowen, B. A. Layout management. Internal Report, ROPA Project, Manufacturing Systems Integration Research Institute, Loughborough University, 1997.

31 Russell, P. W. SQL Team Programming, April 1994 (Gupta Corporation, California).

32 Fox, M. S., Barbuceanu, M. and Gruninger, M. An organization ontology for enterprise modeling - preliminary concepts for linking structure and behaviour. Computers in Industry, 1996, 29(1 –2), 123 –134.

33 Connecting Centura Objects to Databases, October 1996 (Centura Software Corporation, California).

17

34 Gundavaram, S. CGI Programming on the World Wide Web, 1996 (O’Reilly and Associates, California).

35 Kessler, G. C. ISDN: Concepts, Facilities, and Services, 3rd edition, 1997 (McGraw-Hill, London).

36 Vaughan, N. Intranets, 1997 (AP Professional, Boston Massachussetts).

37 Peck, B. S. Website Professional Basics, June 1996 (O’Reilly and Associates, California).

38 Gundavaram, S. CGI Programming on the World Wide Web, 1996 (O’Reilly and Associates, California).

39 Highland, H. J. Threats on the web. Int. J. Computers Security, 1997, 16(5), 365–368.

40 Sanjay Rebello, N. and Sushenko, K. Designing interactive Web pages using ActiveX: Int. J. Computers Phys. 1998, 11(4), 125–129.

41 Davis, R. S. Learn Java Now —Teach Yourself Microsoft Visual J þþ, 1996 (Microsoft Press).

implementing a model-based generic user interface for computer

Documents