An Information Model as a Basis for Hypermedia-Based Plant Documentation

Kari Kaarela

VTT Electronics, P.O.Box 1100, FIN-90571 Oulu, Finland

e-mail: Kari.Kaarela@vtt.fi

Jaakko Oksanen

VTT Electronics, P.O.Box 1100, FIN-90571 Oulu, Finland

e-mail: Jaakko.Oksanen@vtt.fi

Juha Takalo

VTT Electronics, P.O.Box 1100, FIN-90571 Oulu, Finland

e-mail: Juha.Takalo@vtt.fi

ABSTRACT

This paper addresses the production, use, and maintainability of hypermedia-based on-line documentation in industrial plants. The proposed method for addressing all these issues is the utilisation of an information model. This paper describes how an information model can be used for structuring the documentation, for automatic generation of hypertext links, and as a basis for the design of user interfaces that support information retrieval. The tools for modelling and automatic link generation are briefly described. Two case studies utilizing the WWW for the implementation of on-line documentation are discussed.

KEYWORDS: Information model, automatic generation of hypertext links, graphical user interfaces.

1 INTRODUCTION

1.1 Problems with Industrial Plant Documentation

Plant operators control the process they are assigned to with the assistance of a process automation system -- and, of course, with their professional skills and experience. The documentation for the plant is usually stored in the control room to provide information about the process and its automation. For a modern industrial plant, this typically consists of thousands of pages of more or less detailed technical information about the plant's subsystems.

There are many kinds of problems concerning such documentation:

Accessibility problems result from the linear nature and huge number of paper documents; it is difficult to find a specific piece of information in a documentation set consisting of tens of folders. This is intensified by the often poor organization of the documents. The information is not structured and tends to be scattered around the documentation.

Frequent changes at plants - the process and its automation evolve constantly - cause additional problems. Updating paper documents is laborious and, therefore often neglected. The documentation no longer reflects the current status of the plant and soon becomes outdated. Such inconsistencies easily lead to a situation where the documentation can not be relied on. Furthermore, there are several interest groups in a company running an industrial plant: the design organization (process design, automation design, electric design, etc.), maintenance staff (process maintenance, automation maintenance, instrumentation maintenance, etc.), operators, etc. , who have their own copies of the documentation. Communication between these parties is far from ideal, and the changes made by one group are not always reported to the other parties. The production and delivery of new versions of the documentation is very costly and therefore rarely done. This rapidly leads to situation where inconsistent copies of the documentation coexist.

An even more severe problem with the documentation is often its insufficient information content. Successful operation and maintenance of an industrial process require a profound understanding of the process and its goals concerning production requirements, economical use, and operational safety. However, the current process design practices are rather device-oriented and abstract process concepts are often neglected. In other words, more abstract information is not communicated but remains only in the minds of the plant designers. Moreover, information on intentions behind the plant design, the design criteria, the purpose of equipment, and various design constraints are often only roughly described.

1.2 On-line Documentation Systems

On-line documentation systems seem a promising alternative to solving many of the problems related to technical documentation for industrial plants. Such systems store the documentation in an electronic form and provide support for information retrieval. Hypermedia techniques have frequently been applied in the implementation of such systems. The claimed advantages of such systems include:

Despite their obvious advantages, hypermedia-based on-line documentation systems are not yet common at industrial plants. In our view, this is mainly due to the following factors:

Currently, on-line documentation systems are generally based on existing paper documentation of the plant. The documents have usually been produced as linear text using standard text editors. Importing these texts into a hypertext system is usually not a problem. The often poor structure and missing information content may, however, cause much work and cost.

Structuring the linear text documents into reasonable hypertext nodes is a demanding and time-consuming task. This is because the information concerning a specific object at a plant, e.g. a pump, may be scattered around the documentation. Moreover, without any changes in the information content, any information missing in the paper documents cannot be found in the hypertext version. Thus, merely converting the documents into hypertext does not improve their quality. This implies that some parts of the documentation may have to be supplemented.

In addition to the text nodes, links form another essential component of hypertext. Regrettably, the links often have to be created manually one by one. For technical documentation of an industrial plant, such a task would be overwhelming. Furthermore, maintenance of the manually created links becomes extremely difficult. Thus, creating the links manually does not seem feasible.

Converting textual documents into hypertext seems a promising and more realistic short-term alternative. Such conversions have been reported in the literature [FRI88, FUR89, RAD92, ROU94]. Generally, they are based on converting the document markup to the one utilized in the hypertext system. Such conversions are straightforward: the tags in a document markup language are converted to those in the hypertext system. These conversions yield only first-order hypertext whose links are based the logical markup of the original text. These are the presentational markup and direct references between various parts of the text. A presentational markup shows how various parts should appear and describes the book-like structure of the text [COO87, CHE88, JOH88]. The resulting hypertext is most often just an electronic version of the documents. Its links are based on the book structure of the original paper document.

Rada has presented methods for generating second-order hypertext whose links cannot be directly found in the original text [RAD92]. Such methods can be based, for example, on word patterns in the text. Such links may be useful even in technical documentation but do not solve the search problem.

The above approaches mainly produce links that can be used for browsing the hypertext. When searching for relevant information in technical documentation, browsing the documents back and forth using the more or less arbitrary links is clearly not enough. In a hurried situation, the operator has to directly get to the essential information concerning a specific device, for example. A primary prerequisite for such a search is that the information in the documents be properly structured. Furthermore, the links should guide the operator in the search process: the links should contain a hint on the content of information expected to be found at the destination. Linear text documents do usually not record the semantic structure of the information presented in them. Thus, the semantic links missing in the textual documents can not be automatically generated and the result is often unsatisfactory. In practical industrial applications, structuring the hypertext (i.e. generating the semantic links between information chunks) after the documents have been written is a tremendous effort.

There is a close similarity between hypertext and semantic nets [SNA92, RAD92, JON93]. Hypertext nodes represent the concepts in a semantic net with the relationships being in effect hypertext links. This is a useful observation, but unfortunately very little support has been proposed for acquiring semantic nets and for automatically mapping the semantic structure into hypertext.

Technical documentation is one of the major sources of information for the operator. It is therefore of utmost importance that the documentation be available where most of the operator's work is done. On-line documentation systems provide an excellent way to fulfill this requirement. However, on-line documentation systems for industrial applications have in most cases been separate systems with dedicated user interfaces. This requires the operator to master several user interfaces, which is clearly an additional cognitive burden. Furthermore, the operators have been forced to turn to another system in order to look at the documentation. This is not desirable, especially in an emergency situation -- the operator can not leave the automation system console to search for documentation in another system that is possibly located elsewhere. According to the experience of our industrial partners, this has been an obstacle to the effective use of on-line documentation in the control rooms of the plants: separate systems with distinct monitors will not be used, no matter how useful they could be.

1.3. Current Trends

The emergence of new technology has improved the possibility of developing on-line documentation systems. The openness of computer systems is currently an important marketing factor. The advent of X-based user interfaces in automation systems has remarkably improved integration possibilities. Internet and World Wide Web (WWW) have brought a new dimension in the implementation of such systems: it is possible to replace the numerous copies of the documentation with a single one seen by all the involved parties [BER92]. This guarantees the consistency of the documentation.

We want to emphasize the fact that the existence of the technical facilities, e.g. WWW, is not enough to produce a successful on-line documentation system. WWW is good at what it was designed for -- providing a framework for distributed hypertext documents. It does not, however, provide much support for producing the most critical element in such a system -- the documentation, and its structure and information content more specifically. Without a systematic approach for producing the documentation, the expected advantages of such a system remain empty promises. In the following chapter, we present a methodology for building on-line documentation systems based on an information model.

We also want to point out the tight integration of the on-line documentation system with the automation system:

2 MODELLING THE INFORMATION -- A KEY TO EFFECTIVE ON-LINE DOCUMENTATION

Many of the problems discussed in the previous chapter are closely related to the poor structure of plant documentation. These problems could be lessened by properly modelling plant information. The importance of the structure of the information is unquestionable. It is essential both from the point of view of understanding and navigation [RET92]. Detailed information often obtains a meaning only when presented in its context. Thus, plant documentation should not be a collection of scattered information chunks. The organization of the documentation around the process or device hierarchy is not sufficient, because such a hierarchy has only a little to do with the operators' tasks. A holistic model of the plant is required. This model should be used as a backbone for the documentation in order to capture the relationships between the issues documented.

To be successful, information modelling should be:

The first point emphasizes the importance of taking the readers of documents into account when modelling information. The second point suggests that current plant design representations are not expressive enough to capture design knowledge [KAA94]. Moreover, modelling techniques and representations vary from one domain to another. The third point stems from the fact that it is generally not economically feasible to build documentation systems from scratch. A great majority of the documentation of industrial plants is prepared in the design phase. Therefore, the requirements of the end users concerning the on-line documentation should be taken into account during the design process. The design process should thus produce the information model in addition to the documentation. Fourth, such an approach can only be taken in use if it is computer-supported to be economically feasible.

In this chapter, we present how an information model can be utilized for structuring the documentation, automatic generation of hypertext links, and representation of the documentation to the user.

2.1 Structuring the Documentation

Let us first define what we mean by structuring a document (or a set of documents). Two phases can be identified: recognition of essential information blocks and their markup. As a result of the structuring process, we assume we have documents in which closely related topics are gathered logically in one place, to form an entity that is explicitly tagged.

An information model that contains the concepts of the domain and their relationships can be effectively utilised in structuring the documentation. The model covers the first phase of structuring: identification of the concepts to be described and marked up in the documents. The information model is essential because it records the needs of the readers -- it should be based on a survey of their needs. The markup of documents means simply that the identified text elements be explicitly tagged with unique identifiers.

Structured Generalized Markup Language (SGML) provides a way to implement such an approach [ISO86]. The information model is in fact a company-wide Document Type Definition (DTD), its subparts (D in Fig. 1) are the individual DTDs used in the documentation. With SGML, it is not possible to represent the links between the documents. Bergström and Magnusson have proposed the use of HyTime [ISO92] to represent such links [BER94, MAG94]. For the moment, this approach has the drawback that there is a very limited number of tools supporting HyTime on the market.

We have adopted the use of Hypertext Markup Language (HTML), to mark up the elements describing an object in the model [HTM]. Its various versions (HTML, HTML+, and HTML2.0) allow the representation of links between documents.

2.1.1 Documentation of New Plants

To begin with a simpler case, let us consider a situation in which a new plant is being designed. To make the case even more idealistic, let us assume that there are no similar plants and no existing documentation to be reused.

In such a case, the structuring of the documentation is rather straightforward, as depicted in Figure 1. (B) denotes the design phase in which the information model (C) is built starting from the needs of the users and various information systems (A). The information model describes the concepts of the domain and their relationships. The information model is divided into parts to be produced by various design teams, device vendors etc. (D). The essential point here is that a piece of information should be produced only once, to achieve consistency. For each type of an object the required information is defined. The information sets produced in the design process are stored in a corporate text base (E). Paper documents (or hypertext documents) from different viewpoints can be produced using the same material (F, G).

A cornerstone of such an approach is that modelling (B) should be done as a natural part of the design of any man-made artifact -- not as a separate effort [KAA93A].

Figure 1. Producing structured documentation of new plants

2.1.2 Structuring Existing Documentation

Existing documentation of an industrial plant originates from several companies that all have their own symbols, tools, representations, design culture etc. Even generally accepted terms may have different meanings in different companies. Documents may vary a lot in terms of information content and quality. They are often rather poorly organized: the same topic is described in several locations and documents. This implies that a lot more work than mere tagging has to be done. The information blocks (hypertext nodes) have to recognised. For this purpose, some parts of the documents have to reorganized and others may have to rewritten.

Converting existing documentation into hypertext presupposes that the documentation be divided into hypertext nodes. The result of this process depends on how the author understands the structure and content of the documentation. An information model can considerably help in the structuring the documentation in that it readily recognises the information nodes.

2.2 Automatic Generation of Semantic Hypertext Links

As stated in the previous chapter, the approaches to automatically generate hypertext links have not been satisfactory for technical documentation. The links generated on the basis of the document layout do not sufficiently support the operator in finding relevant information.

We propose automatic generation of semantic hypertext links based on an information model. A primary prerequisite for such generation is that the documents involved be structured and marked up with unique identifiers obtained from the information model. In the case of existing documentation this implies manual work and the process can not be regarded as completely automated. For new plants the documentation can be readily produced in a structured manner with the amount of manual work remarkably lessened.

In our view, utilising an information model for generating hypertext links would yield good results. First, the process produces links that have a semantic meaning. Second, the process is systematic, leading to a consistent structure of the documentation. Third, this approach improves maintainability: changes to the information model can be reflected in the documentation by simply relinking the documents.

2.3 Presentation of the documentation to the user

User disorientation -- getting lost in a hypertext document -- is a commonly recognized problem. Another related problem is cognitive overhead resulting from the need to make decisions on which link to follow [CON87]. Both problems are important in the case of technical documentation for industrial plants, due to the huge amount and complexity of documentation. The disorientation problem is closely related to the problem that the readers do not possess a sufficient understanding of the domain -- the process they are assigned to. This implies that their mental model of the system does not cover the concepts of the domain, not to mention their relationships.

To lessen the cognitive overload of the operators, we propose that the same conceptual model be presented to the user in both the user interface of the automation system and in the structure of the on-line documentation system. According to Norman, repeating the same conceptual model in training, documentation, and user interfaces will support the users' formation of a mental model that is consistent with the conceptual model [NOR83].

Our approach has two elements:

The first point implies tight integration of the automation system and the on-line documentation system. Both the documentation and the user interfaces must be structured based on the same conceptual model to enable their compatibility.

Structuring the hypertext according to a conceptual model corresponds to providing high-level semantic structure. Representing the type of the semantic link to the user is essential because it can provide the user information about the content of the destination node. According to Halasz, such links support the reader in navigation [HAL88].

3 TECHNIQUES AND TOOLS

3.1 Modelling the Information

As suggested in Chapter 2, the modelling should be preceeded by a survey of the users' needs. We have conducted such a survey which revealed that many of the problems experienced by the readers of the plant documentation, are caused by device-oriented nature of documents [KAA93A]. Documents are typically structured following the device hierarchy and they best describe device-level details. Examples of points missing in such documents are:

Much of the missing knowledge can be classified as conceptual. In an industrial plant project, a great part of this knowledge is actually born during the design phase. However, this knowledge is rarely seen in design documents.

To be able to represent the concepts of an industrial plant, we have adopted the use of the Multilevel Flow Modelling technique (MFM) [LIN82, LIN90]. A Multilevel Flow Model combines the means-ends and whole-part hierarchies for structuring systems. A means-ends hierarchy describes the relations between the goals of the system and its (abstract and/or concrete) functions, and between the functions and process devices. Using the whole-part relations, each level is represented as a structural hierarchy.

The most obvious advantage of such modelling is that it combines the parts of the process and its automation into an understandable whole. Each process device gets a purpose through the relations that connect it to the functions it performs. Likewise, the purpose of each function is given by the goal it is designed to achieve.

MFM as a modelling technique does not require any specific tools. The models could be created using standard PC drafting tools. However, in this case, the semantic content of the diagrams is not directly usable in other systems. To improve the usability of our approach, we have built extensions supporting the modelling effort in the process design tool of an industrial plant design organization, Tampella Power, Inc. The object-oriented representation of the MFM-model in this tool makes it possible to easily transfer the information in the model to other tools, and finally to automation systems. To support the communication between the design environments, we have developed extensions for transferring the model's knowledge into a relational database that is used for storing design data. The conversion of the object model from the process design tool into C++ objects and Prolog facts allows the use of the model in embedded applications. For each object in the model, such a conversion yields the following information:

A more thorough discussion of the tools is presented in [KAA93A, KAA94].

3.2 Structuring the Documentation

An MFM model essentially depicts the structure of the domain knowledge. This model can be utilised as a framework in the documentation.

The design tool discussed in the previous chapter provides some support for structured documentation. First of all, the information model -- the MFM model -- is produced using the tool. Second, the tool contains an editor for authoring descriptive text blocks. Thus, for any type of an object created in the MFM model, a structured text entity consisting of several elements is created. This entity is to be filled by the designer as part of the design work. Such entities can be stored in a corporate text base to be used when producing either paper or on-line documents.

However, in case of existing documentation, the above approach is not feasible; separate tools supporting structured documentation must be used to mark up the documents. In the development of our prototypes we used public domain HTML tools supporting both editing and conversion of existing documents. The following tools have been used for structuring and converting the documentation:

These tools were used to initially convert the existing documentation into HTML format. The additional markup imposed by adding the semantic structure was generated automatically using the tool described in the following section.

3.3 Automatic Generation of Hypertext Links

For the automatic generation of hypertext links into design documents, a hypertext linker was implemented. The links are generated according to the information model depicting both the concepts of the domain and their interrelationships. Ideally, such a model should be produced as part of the design process.

The linker was written in Prolog and it runs on a 486 PC. Its operating principle is shown in Figure 2. The information model is input as a file containing the Prolog facts produced by our design tool.

As its input, the linker accepts the information model consisting of the nodes and their relationships [D] and the set of the documents under scrutiny [A]. The documents must be structured with the elements of the information model explicitly tagged with the unique identifiers given in the model. The linker works in two passes. During the first pass [B], it creates a table that shows what tagged elements are located in each document [C]. During the second pass [E], the linker reads the information model [D] element by element and writes the required links into the destination documents [F]. Each link represents a Uniform Resource Locator (URL) consisting of:

Figure 2. The operating principle of the hypertext linker

All the information required for the linking procedure except the name of the document server can be obtained from the information model. The linker writes the links into the destination documents as bulleted lists according to the types of link (Figure 3). As stated earlier, the type of link provides essential information of the content of the destination node and guides the user in searching a specific piece of information. The link types presented in Figure 3 are IS-ACHIEVED-BY and HAS-SUBPARTS.

<P >
<A NAME="SF3_1">In order to put out a fire</A> <UL> <LI>IS-ACHIEVED-BY:
<UL>
<LI><A HREF="http://otesun4.tko.vtt.fi/gas_105.html#SG2_1"> AVOID_FIRE_&_EXPLOSIONS</A>
</UL>
<LI>HAS-SUBPARTS:
<UL>
<LI><A HREF="http://otesun4.tko.vtt.fi/gas_110.html#SF4_1"> MEASURE_EXIT_GAS_OXYGEN_CONTENT</A>
</UL>
</UL>

Figure 3. An example of a bulleted list generated by the linker

4 EVALUATION

To evaluate the approach, we have developed two prototypes. The first case was a realistic plant application where the target process was the feedwater system of a 155 MW peat power plant. The other case concerned the argon-ethane gas system of the L3 experiment at CERN [PEA92].

The development of both systems followed the approach described in this paper. In both cases, the systems and their documentation already existed. This meant that the information models had to be reverse engineered from the existing systems. In both cases the existing linear paper documentation had to be structured afterwards.

In both cases, the developed prototype systems fully demonstrate the ideas presented above:

The systems were built using an industrial automation system, Damatic XD, and a process information system, XIS, both from Valmet Automation, Inc. Both application utilise X-based user interfaces supported by the above products. The online documentation provided by the systems was built using the hypertext document server and browser that have been developed and submitted into the public domain by the National Center for Supercomputing Applications (NCSA, USA) [NCS].

4.1. Modelling

In both cases, an information model had to be reverse engineered from the design documents. Interviews of the designers of the plants were used as another primary source of information.

The model of the feedwater system consists of 25 goals and subgoals and 100 functions and subfunctions. At the device level, the number of components is about 1500. There are numerous many-to-many relations between the components. The complexity of the model is reduced through the part/subpart-relations. A single part defines the purpose of many subparts: the realized-by relation only connects the function and the part and not each of the subparts. In the other case, the size of the model was smaller due to less detailed modelling of the device level.

Building an information model of an existing system is not a trivial task. First, it was found that working out the intentions of the original designers based on the often insufficient documentation is difficult. Second, the modelling effort was clearly obstructed by the very limited time available to discuss the model with the original designers.

4.2 Structuring the Documentation

The amount of the documentation for the feedwater system was large. There had been several organizations contributing to documentation. The paper documentation was quite freely organized; for example, the diagrams and pictures came in several formats.

For practical reasons, we could only use a small fragment of the available documentation -- less than 200 pages in 10 documents. The documents were obtained in RTF-format (Microsoft Rich Text Format). The original documents were not well-structured in the sense that the information concerning a topic (e.g. a feedwater pump) was typically scattered around the documents. Much reorganising had to be performed. Furthermore, the documents lacked many of the higher-level concepts referred to in MFM models, such as the goals and abstract functions of the feedwater system. The missing descriptions were written during the modelling phase, based on the interviews of the original designers of the plant. The markup of the documents was performed manually using public domain HTML tools. Using the information model as a framework, the text units corresponding to the objects in the model were explicitly tagged with unique identifiers.

In the L3 Gas System demonstration, the documentation consisted of 150 pages. The documents were first converted to HTML using the WebMaker software package developed at CERN [WEB94]. This conversion was performed to conserve the book-like structure of the document. Thereafter, the documents were reorganised to some extent, marked up with the unique identifiers in the information model, and finally linked to reflect the structure imposed by the model. The resulting hypertext document thus has two parallel structures: one resembling the book-like structure of the original documentation and the other based on the semantic structure of the information.

4.3 Hypertext Link Generation

The hypertext links based on the information model were generated automatically using the hypertext linker described above.

In the first case, the feedwater system of a power plant, the linker generated about 350 links between the nodes residing in the 10 documents involved. Despite the totally unoptimized Prolog implementation the linking process took less than 30 seconds on a 486 PC. The apparently short execution time can be partly explained through the relatively small number and volume of the documents to be linked. However, the size of the model was realistic: there were about 1600 nodes and 3000 typed links. The size of the Prolog fact file containing the model was 1.3 Mbytes. However, for most of the objects in the model there was no structured text block in the documents involved -- the links were therefore omitted.

In the second case, the number of the document files involved was essentially larger totalling over 200. However, the number of the generated links was very limited (20) because the model was significantly smaller due to the fact that the system was not modelled to such a detailed level as in the first case.

4.4 Graphical User Interfaces

As to the user interfaces, the developed prototypes express the possibilities permitted by the similarity of semantic structures of the hypertext documentation and the user interfaces. The purpose of displaying this semantic structure in the user interfaces is to provide assistance for the users when navigating in the information space, i.e. support them in finding the correct piece of information. At least, it is believed to lessen the cognitive overload of the operators: they do not have to memorize the relationships between the concepts in the documentation. The developed prototypes pursue at this goal by two means:

4.4.1 The use of the displays of the automation systems as graphical maps to the hypertext documentation

Traditionally, display hierarchies of automation system user interfaces have been built according to the device or process hierarchy. In a sense, such displays are still replicating the wall-wide panels in conventional control rooms.

We have implemented a display hierarchy that is based on the MFM model of the system (Figure 4). The highest level of abstraction representing the goals of the system makes it possible for the operator to monitor the process at the level of these explicit goals (A). The achievement of the goals is expressed with symbols and colour codes (e.g. traffic lights). When applicable, trend displays with explicit values can be used. At the next level there is a display for each goal category that shows a detailed goal hierarchy (B). Colour codes are used to indicate the achievement of the goals. In an alarm situation, the hierarchy supports the operator in the analysis of the cause of the problem in question, because the traversal of the alarm is indicated on the display. The next level of hierarchy represents the abstract functions required to achieve a goal (C). At the lowest level, conventional displays based on device or process hierarchy are utilised (D). They represent the actual devices (e.g. pumps, valves, pipelines) that implement the abstract functions. In Figure 4, (E) denotes the hypertext window.

Since the display hierarchy, displays, and the hypermedia-based documentation are organized according to the same information model, the displays naturally function as a graphical map to the documentation. Finding the correct information is easy: positioning the cursor on the desired object and selecting a hypertext-option in a pop-up-menu is all that is required. A new X-window displaying the documentation of the selected component will be opened.

Figure 4. An MFM - based display hierarchy

Figure 5 shows an example of some of the displays in the demonstration system. The goal level window (upper left corner) has three indicators denoting the three top level goals: safety, economy, and production. The device level window is shown at the lower level corner. The hypertext window (at right) shows a portion of the documentation of the power plant application (in Finnish).

Figure 5. A view on the automation system display

4.4.2 The representation of typed links (based on the information model) to the user

Representing the types of link in the hypertext provides another way of supporting the user in navigating the document. In Figure 6, a section of the L3 Gas System documentation can be seen. The bulleted lists in the figure have been automatically generated by the hypertext linker based on the information model. In the figure, the list items 'ACHIEVES' and 'HAS-SUBPARTS' denote the links starting from the function 'PREVENT OVERPRESSURE'. Thus, 'PREVENT OVERPRESSURE' has subparts 'ADD FRESH GAS' and achieves the goal 'PROTECT CHAMBERS'. This display also reflects another strength of the approach: the same documents are available to several groups of people using a variety of computers. This screen dump has been captured while browsing the documentation with the Netscape browser (Netscape Communications Corporation) [NET94].

Figure 6. A view of automatically generated hypertext links in the L3 Gas System Documentation

5 CONCLUSIONS

We have demonstrated the use of an information model as a basis for designing user interfaces and structured hypertext. According to our initial evaluation, such an approach seems feasible for producing and using on-line documentation in industrial plants.

An information model -- an MFM model in the example case -- depicts the structure of the information of the plant. This information is invaluable in structuring the documentation of the plant. First, the model can be used for automatically generating hypertext links between the nodes describing the objects in the model. Second, the displays of the automation system can be used as a graphical map of the hypertext, because they have the same information structure.

The first prototype system has gone through initial tests by our industrial partners with promising results. Operator support systems and user interfaces based on the MFM models enable the operators to monitor and control their process at the level of explicitly defined and represented goals, instead of individual process variables. Moreover, these systems help the operators in understanding the meaning of the process devices as parts of a whole and in relation to overall goals of the plant.

According to Duncan and Praetorius [DUN92] and Sassen [SAS93], user interfaces based on MFM models significantly improve the ability of the operators to reason about the possible causes and effects of faults, especially in case of multiple faults. We have augmented this approach with easily accessible on-line documentation via the user interface of the automation system. In the initial evaluation this feature has been found to be especially useful.

In the prototype systems, all the documentation has been stored on one server, typically located at the plant. This approach was taken for practical reasons. First, it is of utmost importance that the documents are available at all times even during network or server failures. Therefore, a local document server was preferred. Second, using current techniques documentation distributed at several servers may be hard to maintain.

In spite of the success in the demonstration of our approach, a number of problems remain. First, the amount of manual work is still considerable, especially in the case of an existing system. This could be partially solved with some changes in the design process: the designers should be able to construct the information model and structured documentation should be introduced. Such changes are not easy to perform, due to resistance of both organizations and individuals. The initial cost of the introduction of a new methodology may seem high, but the future savings will be considerable Second, the layout-based links and the semantic links produced according to the information model may not be enough. The management of other types of link (e.g. associative) has not been sufficiently investigated.

We foresee developing a methodology to automatically generate the displays of the automation system, and the links from the objects of the displays to the respective hypertext nodes. This will considerably lessen the effort to construct systems as outlined in this paper. Moreover, it will guarantee consistency between the displays (pointers to the text nodes) and the documentation.

ACKNOWLEDGEMENTS

This work has been done in two research projects. The basic work and the first application were done in the project "Integration and Embedding of Knowledge for Process Management" which was carried out at the University of Oulu and VTT Electronics. The project was part of the national Process Technology Programme funded mainly by the Technology Development Centre of Finland. The other application was implemented in a multinational research project CICERO, initiated by CERN.

The authors would like to acknowledge the contributions of several colleagues at the University of Oulu, Juha Jaako and Kauko Leiviskä, and at VTT Electronics, Pekka Ala-Siuru and Jarmo Kalaoja. The authors would also like to acknowledge the effort of the numerous people working in the CICERO project, and especially Pertti Huuskonen for his constructive comments.

Finally, this research would not have been possible without the fruitful cooperation and financial support of our industrial partners, IVO International, Inc., Tampella Power, Inc., and Valmet Automation, Inc.

REFERENCES

[BER92] Berners-Lee, T.J., Cailliau, R.: The World-Wide Web", Proceedings of the conference "Computing in High Energy Physics", Annecy, France, 1992.

[BER94] Bergström, P.: FMV Grund-DTD Overview, Conference Proceedings of SGML Europe '94, May 16-19, 1994, Montreux, pp. 273-276.

[CHE88] Chen, P., Harrison, M. A.: Multiple Representation Document Development, IEEE Computer, Vol. 21 No. 1, January 1988, pp. 15-31.

[CON87] Conklin, J. "Hypertext: An Introduction and Survey", IEEE Computer Vol. 20 No. 9, September 1987, pp. 17-41.

[COO87] Coombs J. H. et al: Markup Systems and the Future of Scholarly Text Processing, Communications of the ACM, Vol. 30 No. 11, November 1987, pp. 933-947.

[DUN92] Duncan, K. D. and Praetorius, N.: Flow Displays Representing Complex Plant for Diagnosis and Process Control. Reliability Engineering and System Safety, Vol. 36, 1992, pp. 239-244.

[FRI88] Frisse, M.: From Text to Hypertext, Byte, Vol. 13 No. 10, October 1988, pp. 247-253.

[FUR89] Furuta, R., Plaisant, C., Shneiderman, B.: A Spectrum of Automatic Hypertext Constructions, Research Report CAR-TR-443 (CS-TR-2253), University of Maryland, May 1989, 10 p.

[HAL88] Halasz, F.: Reflections on NoteCards : Seven Issues for the Next Generation of Hypermedia Systems, Communications of the ACM, Vol. 31 No. 7, July 1988, pp. 836-852.

[HTM] The HTML Specification. URL = http://info.cern.ch/hypertext/WWW/MarkUp/HTML.html

[ISO86] ISO8879. Standard Generalized Markup Language, International Organization for Standardization, 1986.

[ISO92] ISO/IEC 10744. HyTime. International Organization for Standardization, 1992.

[JOH88] Johnson, J., Beach, R. J.: Styles in Document Editing Systems, IEEE Computer, Vol. 21 No. 1, January 1988, pp. 32-43.

[JON93] Jonassen, D. H.: Effects Of Semantically Structured Hyeprtext Knowledge Bases On User's Knowledge Structures. In: McKnight, C., Dillon, A., Richardson, J. (eds.): Hypertext, a psychological perspective, Ellis Horwood Limited, 1993.

[KAA93A]Kaarela, K., Huuskonen P., Leiviskä, K.: The Role of Design Knowledge in Industrial Plant Projects, Proceedings of the International Conference on Cognitive and Computer Sciences for Organizations, May 4-7, 1993, Montreal, Canada, pp. 173-183.

[KAA93B]Kaarela, K., Huuskonen, P., Jaako, J.: Providing Plant Design Knowledge to the Operators, Proceedings of the Human Computer Interaction Conference (HCI '93), August 8-13 1993, Orlando, Florida, Vol. 19A, pp. 546-551.

[KAA94] Kaarela, K., Oksanen, J.: Structuring and Recording Plant Design Knowledge, Proceedings of the International Conference on Feature Modelling and Recognition in Advanced CAD/CAM Systems (IFIP), May 24-26, 1994, Valenciennes, France, pp. 853-866.

[LIN82] Lind, M.: Multilevel Flow Modelling of Process Plant for Diagnosis and Control, Risø-M-2357, Risø National Laboratory. Denmark, 1982.

[LIN90] Lind, M.: Representing Goals and Functions of Complex Systems - An Introduction to Multilevel Flow Modeling, 1990, Institute of Automatic Control Systems, Technical University of Denmark, Report No. 90-D-381.

[MAG94] Magnusson, J.: Defining Information Objects against a Product Data Model, Conference Proceedings of SGML Europe '94, May 16-19, 1994, Montreux, pp. 253-272.

[NCS] NCSA Mosaic Documentation, URL = http://www.ncsa.uiuc.edu:80/SDG/Software/Mosaic/Docs/mosaic-docs

[NOR83] Norman, D. A.: Some Observations on Mental Models, in Gentner and Stevens (Eds.), Mental Models, Lawrence Erlbaum Associates, Inc., Hillsdale, NJ, 1983.

[NET94] Netscape On-LineManual, Netscape Communications Corporation, 1994. URL = http://home.mcom.com/home/ online-manual.html

[PEA92] Peach, D.: The L3 Gas Systems Operators Manual, CERN, Switzerland, August 1992.

[RAD92] Rada, R.: Converting a Textbook to Hypertext, ACM Transactions on Information Systems, Vol. 10, No. 3, July 1992, pp. 294-315.

[RET92] Rettig, M: Hat Racks for Understanding, Communications of the ACM, Vol. 35 No. 10, October 1992, pp. 21-24.

[RTF93] Rtftohtml Converter Overview. URL= ftp://ftp.cray.com/src/wwwstuff/RTF/rtftohtml_ overview.html

[SAS93] Sassen, J. M. A. (1993). Design Issues of Human Operator Support Systems. Delft University of Technology, Delft, the Netherlands.

[SNA92] Snaprud, M., Kaindl, H.: Knowledge Acquisition Using Hypertext, Expert Systems With Applications, Vol.5 No. 3/4, 1992, pp. 369-375.

[ROU94] Rousseau, B., Ruggier, M.: Writing Documents For Paper And WWW. A strategy based on FrameMaker and WebMaker. First International WWW Conference, May 1994, Geneva. URL = http://www.cern.ch/WebMaker/ whywebmaker/WMwww94_1.html