MINDS—A software tool to establish a measuring system requirement

M I N D S - A software tool to establish a measuring system requirement P. H. Sydenham*, D. D. Harris t and N. H. Hancock §

*Academic in Charge, Measurement and Instrumentation Systems Centre. South Australian Institute of Technology tNational Research Fellow. Measurement and Instrumentation Systems Centre. South Australian Institute of Technology §Senior Lecturer, School of Engineering. University College of Southern Queensland, Australia MINDS (Measurement INterface Design System) is a software tool to assist the user in rigorously designing and specifying a measurement system commencing only with a statement of the knowledge needed. It employs the Measurement Process Algorithm (MPA) and provides facilities for the system user to specify the system such that factors required for design of an optimised measurement system are considered and included. A comprehensive report is then produced. This paper represents the state of development of the concept and the first generation software developed to implement it. Case histories of its use in the development of a sleep disturbance (apnoea) monitor for medical research and an aquaculture water quality monitor are presented and discussed. A major barrier to the use of MINDS is reluctance of users to think out their real need and to answer large numbers of questions. A suitable user interface is therefore of prime importance and suggestions for such an interface are discussed. Keywords: Instrumentation, computer aided engineering, CAE, sensing interface

1. Introduction The purpose of a measurement system is to extract knowledge from physical world events. A barrier exists in setting up this knowledge extraction interface efficiently, because there are two different kinds of expertise involved. The user of the system understands the measurement problem in terms of the knowledge needed. The instrumentation engineer, on the other hand, understands instrumentation systems capability and limitations. Communication between these different fields of expertise is fundamental to the specification of a satisfactory system. This information exchange is frequently carried out through the medium of manufacturers' technical brochures which, in addition to the aim of conveying relevent information, have other aims (such as selling) which introduce misinformation into the communication. In order to facilitate correct and efficient communication, a systematic understanding of the sensing interface is required. Work by Sydenham (1985a,b) investigating the structure of the measurement process led to the development of an ordered procedure for setting up systems of sensors. The concept of the Measurement Process Algorithm was developed by applying the scientific method to the information gathering task. Sydenham (1987) reported the development of a software system implementing the Measurement Process Algorithm. This system, called MINDS - Measurement INterface Design Measurement Vol 8 No 3, JuI-Sep 1990

System - has been developed further and has achieved successful user trials. The Measurement and Instrumentation Systems Centre (MISC) of the South Australian Institute of Technology is a multi-disciplinary academic centre set up to advance measurement science and instrument engineering. The systematic study of the structure of the measurement process falls within this brief. Research also includes the automated design of instruments and measurement systems. MINDS is an essential first step to this process, defining the information gathering requirement and the environment in which the sensing system is to operate. A productive exchange exists between senior students of the South Australian Institute of Technology and the University of Twente, in the Netherlands. The MINDS software system has been implemented by a succession of senior exchange students from the University of Twente under the direction of the authors. The first implementation of the MINDS algorithm into a Pascal program was made by Lensink (1986). Van Leunen (1987) prepared a user interface using the SYNICS language, which has the capability to parse free-text input (Lutchi, 1985). This was less than successful, partly because of problems with the SYNICS environment in Adelaide but equally because free form entry was found to give insufficient guidance to users on what kind of answer was required. The user interface was subsequently re-written in Pascal by Hammes (1988) who, using the 109

Sydenham, Harris and Hancock knowledge and strategies developed by colleagues, completed the task of coding the first functional MINDS system. Currently, MINDS exists as a Pascal program, of modular structure, running on the Institute's VAX computer system. It is a text-based program (to avoid the need for VAX graphic terminals) and produces a printed report of the required sensing system on completion of the consultancy session. This paper sets out the basic operations of MINDS, outlines experience from user trials, and discusses areas in which MINDS needs to provide further user support. Directions and recommendations for further development are discussed.

2. The measurement process algorithm and the program 'MINDS'

(.,a,.mon,o,,now=oo..=) Refer to existing knowledge j.__q

IEs,.o,i.hr--ots) T

I

I

of observed system

of the environment

t

½

of observed system )

environmentmeasurands must be controlled

~, I

,,ino I

Knowledge Base

l

Devel°p measurand )

specifications

~DD

evelop statement [ combining the L measurands

DEVELOP MOD~

Make block diagram of the system in the environment

1

2.1 Overview of MINDS

The philosophy behind the Measurement Process Algorithm and its derivation have been described by Sydenham (1985a,b). This algorithm forms the basis for MINDS. Fig 1, reproduced from Sydenham (1985b), shows the steps to be taken in establishing the information needs of the measurement task. Fig 2 shows the implementation of this algorithm in MINDS. The efficient coding of MINDS requires that common functions be grouped as six program modules which encompass the nine steps of Fig 2. Fig 3 illustrates their inter-relationship and the following description of MINDS is in terms of these six modules. The software

1 Fig 2 Application of the MPA to produce a measurement system design - the logical structure of MINDS

TASK OU'= 31

Statement o, know,edQo.o o,

Storl i

t

L

~ Rotor to existing knowledge ~

Existing KnowledgeBase

1 I Define knowledge needed

I

Existing knowledge bose

I

2 I Refer to existing knowledge

I

3I 6

List referentsl

L~I

Estoblish Define ' 'boundary' of system in which observotion resides

Estoblish suitoble

meOSuronds

Define meosuring [ instrument I operotionol specificotions

Jl

Model for combining

meosuronds

I Observer now reody to creote measuring system

t//////~/////////////f///A OUTPUT~//~

I/'///////////,2"/////////////]

Fig 1 Measurement Process Algorithm reproduced from Sydenham (1985b) 110

Fig 3 Software modules of MINDS Measurement Vol 8 No 3, JuI-Sep 1990

Sydenham, Harris and Hancock incorporates an (optional) tutorial, available when entering a work session, and extensive 'help' facilities are available at call. The user also has available at call a report facility which may be invoked at any time, and there is a facility to backtrack or abort the session. These facilities provide the beginnings of the 'user friendly' environment essential for the successful use of MINDS. No manual or pre-reading is necessary to use this C A E tool.

2.2 The ESTABLISH TASK module To establish the measuring task adequately the system requires answers to three questions: 1. What is the particular system/phenomenon/object to be observed? (Measurement needs will usually be specific and individual.). 2. What needs to be known about the system? (Not what is initially thought should be measured.0 In the authors' experience, most potential users tend to approach every measurement requirement by guessing the measurands required (force, displacement, temperature, pressure, etc). It is essential that this tendency be avoided as it is often wrong, pre-judges the task in hand and often seriously handicaps the subsequent analysis and design. 3. What is the physical environment in which the system is to operate? (This is, of course, vital to setting up a properly engineered system.) MINDS starts by prompting the user to enter a statement of the task of the form 'The task is to determ i n e . . . ' . The 'help' file gives the example 'The task is to determine the quality of an orange'. This response is not processed but is simply accepted as text. As indicated above, it is important that this statement is quite general and is not tempered by pre-conceived thoughts about how the task is to be implemented as a measurement or a set of measurements. This turns out to be quite difficult in many cases, as discussed below. Most users find it hard to start with an open mind on the issue - in essence, they have not adequately investigated what they really want to know. MINDS then moves into the definition of the knowledge required, supplying a procedure which will assist a systematic generation of answers to the questions. In our 'quality of an orange' example: • What are the attributes which determine whether or not the orange is of the required quality? • What are the measurable values of these features? The italicised items are the critical parameters. Decision making by the user is inherent in these steps. Firstly, the quality must be measured; then, on the basis of these measurements, a decision is made on its acceptability. Equally important is the operating environment of the instrumentation system. The user can, at this point, select one of a number of pre-programmed environments within MINDS (domestic, underwater, industrial, etc) or provide details of a new environment. Environmental parameters include temperature, pressure, vibration, dust, humidity, etc, as appropriate. Consideration of the operating environment at this initial stage is introduced Measurement Vol 8 No 3, JuI-Sep 1990

to set up a mental model of the full system in the user's mind. Fuller consideration occurs later in MINDS, as discussed in Section 2.5 of this paper. At this stage the task is defined, and a statement can be printed out if required.

2.3 The ESTABLISH REFERENTS module

Now that the task has been adequately defined, the process moves on to help the user to refine the understanding of the knowledge needed. Various attributes of the system to be measured will be of obvious relevance to the measurement system required. Two terms are required to handle these attributes:

• referent which is used for any attribute of the object or event which is relevant to the measurement task in hand. A referent is not necessarily directly measurable ('size' or 'quality' for example) but is what would be referred to by people as an attribute; and • measurand which is reserved for any directly measurable quantity (displacement, mass, pressure, etc) which, in principle at least, may be measured with physical apparatus. It is a major objective of the Measurement Process Algorithm, and therefore of MINDS, to assist the user to transform all referents into measurands. This is not always a straight-forward task. Often, apparent measurands are really referents. Take the example of size where there is a semantic ambiguity does it mean physical dimensions? In some contexts it could mean 'weight' or even 'shape'. In the case of the orange it has elements of both dimension and shape and may need to be obtained from three length measurements in the x, y and z directions. MINDS contains a support structure to help the user unravel such situations to arrive at a measurable and feasible system of instrumentation. Some referents, such as 'blemishes', may be measurable, but practical considerations may suggest alternative methods which are as much qualitative as quantitative. Manual inspection with reference to an acceptance standard is a common method of assessment of whether a blemish exists or not and clearly involves a process of correlation with a standard. Automation of such 'measurement' procedures may be difficult but MINDS is designed to assist the user in breaking down such referents so that they may eventually be transferred into measurands. MINDS accepts user input for referents and compares these inputs automatically with synonyms held in a thesaurus of attributes. Where a stored synonym is found it is presented to the user for acceptance, along with its ready-made development into measurands. This is necessary as people often use descriptive terms with little metrological validity, or with different meaning in different applications. 'Volume' for example, has different measurement implications if the object to be measured is a fluid or a solid. With the addition of application knowledge and some innovative thought by the user, MINDS progressively builds a tree structure of the referents supplied by the user. At this point of our 'orange' example it only needs two l e v e l s - the top level for the task and the next for the referents. The tree is expandable to multiple levels as 111

Sydenham, Harris and Hancock needed and forms the basis for further definition of the task within the subsequent modules. This tree is also part of the final report as it defines the connection of the many measurands (in general) to each required attribute. 'Quality', for example, is defined in terms of a set of measurands as set out in Fig 4 for our 'orange' example. To determine if the orange is of export quality: -

Sweetness

(1)

--

Compliance when 500gm load applied

--

Colour

--

Blemishes

--

Shape

--

(4)

(2)

2.5 The program SPECRITER

(3)

~ i dimension (4) dimension

(4)

dimension

(4)

Mass (5)

(1) Measurand (pH) provided as suggested equivalent for user acceptance. (2) Still not yet measurable. (3) Still not yet measurable.

To be expanded. To be expanded.

(4) Measurand (length) automatically provided by synonym recogniser. (5) Measurand (mass) recognised immediately without need for development.

Fig 4 Partially completed sensor tree to measure 'quality of an orange'

2.4 The MEASURAND

At this point it is appropriate to discuss S P E C R I T E R (Cook, 1988). This is a CAE tool for generation of specifications (to Mil Std format) for single-sensor measuring instruments. S P E C R I T E R is intended to run alongside MINDS, providing a formal specification for each measurand instrument for which the requirement emerges from MINDS. However, it is at a more advanced stage of development than MINDS and provides the user with independent advice on instrument parameters. In particular, factors such as discrimination, repeatability and hysteresis are often vague to the end user, or at least their significance is not well understood. S P E C R I T E R offers sensible defaults for these values, as will future developments of MINDS. At present, MINDS data has to be entered into successive SPECRITER sessions. SPECRITER is currently being re-written in Prolog to provide more flexible access to thesaurus information and greatly enhanced user input facilities. This may indicate a future development path for MINDS research.

SPECIFICATIONmodule

This module works closely with the E S T A B L I S H R E F E R E N T S module discussed above. The user breaks down each referent into one or more measurands, building the tree structure. This can be reviewed on screen or as a printed report at any stage. If the referent is recognised by the system and its expansion into measurands accepted by the user, this is appended to the developing tree structure. Alternatively, the user is prompted to provide lower level information about the referent. This user input is also compared with thesaurus data, as mentioned above and, when recognised, this branch of the tree is complete. One tree branch can have several branches down to lower levels, or one branch can have several 'leaves'. The partially developed tree for our 'orange' example is shown in Fig 4. This tree represents the 'many to one' mapping of sensed variables and shows referents in various stages of development as an illustration of the methodology. Once the measurands have been fully specified - i e, there are no referents remaining in the tree - MINDS then prompts the user for metrological parameters for each measurand. These parameters include basic matters such as measurement range (ie, maximum and minimum values), discrimination and dynamic response as well as parameters specific to the measurand. (At present, MINDS contains only a pre-set range of parameter questions but a more intelligent version will eventually provide only those questions appropriate to the measurand.) Hence, in order to provide usable data to MINDS, the user must have a clear understanding of the 112

application requirements. For example, the significance of measurement range and its relationship to discrimination (and the methods of specifying each) must be appreciated. Experience shows that the user is often anything but clear on these metrological points, and requires considerable help, as discussed below. The user must complete development of the referent/ measurand tree before being allowed to continue to the next operation. Without this, a fully realisable system could not be engineered.

2.6 The SYSTEMS ENVIRONMENTmodule The performance of all sensor systems depends upon the influencing environment in which they operate. The environment will introduce noise (unwanted signals) and may cause erroneous readings or even damage the instrument. If the MINDS user has accepted one of the pre-programmed environments, the influencing parameters and their values will be reported; if not, the user will be prompted to input appropriate values. A typical statement is as follows: 'Is vibration a feature of the environment?' If yes: 'Enter vibration f r e q u e n c y ' . . . 'Enter vibration a m p l i t u d e ' . . . MINDS then takes the user through each of the environmental parameters and asks whether the instrumentation system must take the parameter into account. This information is used to create the system block diagram showing the relationship of the instrumentation system to the environment in which it is to work. It is assumed at this stage of development that all sensors of the system are in the same environment. An example of such a diagram is shown in Fig 5 and has been derived for our 'quality of an orange' example. The entities are not pre-set as a whole, but vary according to the answers. Features of this diagram are as follows: • In the middle, the name of the required sensing instrument system is shown. At the left side an object occurrence enters the measurement environment. At Measurement Vol 8 No 3, Jul-Sep 1990

Sydenham, Harris and Hancock Object occurence carrying information relating to the quality of an orange

1 B O U N D A R Y

Enclosure

Electronic signal equivalent to the quality of each orange

J, Instrumentto measure the J v[ quality of each orange

Temperature variations

Pressure Humidity Vibrations variations variations

the right hand side is an output signal, usually electrical, carrying the information derived from the measurements and hence, in our example, represents the quality of the orange being inspected. • At the user's discretion there may be an enclosure around the instrument to protect it from environmental influences. However, if this is not called for, it does not appear in the diagram. • Outside the box are the environmental influence parameters. The user has specified those which must be controlled to preserve correct instrument operation and these are shown with arrows terminating at the instrument enclosure. In this example, only vibration control has been specified - i e, the instrument must be set up so as not to detect vibrations, or be compensated adequately for them. Those not so controlled have arrows flowing through the enclosure to the instrument - here temperature, pressure and humidity. • The outer box is the system boundary, implying that activity falling within the boundary affects the instrumentation system while that outside does not. This diagram forms part of the report and can be called up on demand. 2.7 The D E V E L O P SYSTEM module

Very commonly, an object will be passed as acceptable by the measurement system if all measured parameters fall simultaneously within the nominated range. However, this is not always the case and some trade-off may be permissible between parameters just out of range. In addition, practicality may suggest an order for measurements. For example, weighing is easily carried out and an o r a n g e which is under (or over) weight will not be acceptable whatever its measurements. It is therefore more efficient to use weighing as an initial step, passing only those satisfactory on this measurement to subsequent steps. Some steps are needed to yield higher level referents: volume, for example, needs three measurements unless it may be relied upon that the object is of regular shape and orientation. The Develop System module allows the user to specify the way in which the many measurands are to be combined to provide acceptance decisions for the task. This specification is input to MINDS as a logic statement (this A N D T H E N t h a t . . . ) , the program reporting on these decisions, on request, with a tree diagram. It is intended that this modelling module will eventually be able to propose and accommodate more sophisticated M e a s u r e m e n t Vol 8 No 3, Jul-Sep 1990

Fig 5 System diagram produced by MINDS as part of thefinal report

system models for carrying out the essential 'many to one' mapping. 2.8 Output module

This module provides a written report of the MINDS session, complete with diagrams. The report is most important, as it forms the working document from which the instrumentation designer will build or purchase a suitable measurement system. It is intended eventually that MINDS will also provide data directly into computer specification writing software (such as S P E C R I T E R ) or C A D packages to facilitate purchase or manufacture (Sydenham, 1987) of the instruments required. A MINDS report runs to several pages and includes: • • • • • • • •

The statement of the task. The referent/measurand tree structure. Details of environmental parameters. Details of which environmental parameters are to be controlled. Whether the instrumentation system is to have an enclosure. The systems environment diagram. Full metrological parameter details for each measurand. The statement from the D E V E L O P SYSTEM module, explaining how the signals from the many sensors are to be combined.

3. Some trials of MINDS 3.1 Assessment of user response

MINDS is still very much a research tool, but already has been shown to have value in defining a measurement task. It has also proved useful in researching the basis of measurement as part of cognitive science. Evaluating user trials of MINDS has yielded some interesting psychological insights. A response frequently heard at the end of a session is ' . . . but I already knew all that.' However, the fact is that: • they did not know it originally, as is evidenced by all the soul searching which goes on while the session is in progress; and • the written report is a document which users would rarely go to the trouble of preparing, or if done, to the depth of detail because they would regard it as 'obvious'. 113

Sydenham, Harris and Hancock Perhaps the point is that users do not believe that all the information collected by MINDS is necessary, but without it the instrumentation designer must fill in the gaps with more questions or, more likely, guesses. The report provides considerable time savings and confidence to the designer; rarely is such a document provided in normal practice. It is interesting to note that a S P E C R I T E R report is regarded much more favourably by users although its content is very similar and is only for simpler (single measurand) cases. Perhaps this is because users have usually been through the process of creating such a.specification and appreciate the ease and speed with which the system creates it. S P E C R I T E R , however, only covers the specification of an alreadyknown single sensor, whereas MINDS sets up a measurement strategy for hard-to-measure situations. Its philosophical, cognitive and analytical level is above that of S P E C R I T E R .

3.2 User trial methodology To date it has been found difficult to persuade a user with a real and challenging instrumentation problem to use MINDS alone at a computer terminal. A MISC researcher usually acts as a tutor, explaining the required information, assisting with default values and pointing out features of the system. This is largely due to the shortcomings in the interface design and development is obviously still needed to make it more user-friendly. It is important to recognise that MINDS does not provide innovation or application knowledge to achieve solutions. It can only prompt and provide a methodology. The user must be familiar with the application because only the user knows that part of the problem. A typical session will last around 1-2 hours. The time taken is not a factor of the software but is needed for the discussion and innovation prompted by the questions and responses to MINDS. If this were the only result of a MINDS consultation, the resulting clarification of the information collection problem alone would be valuable. However, the printed report also becomes a document for future reference and provides a repository of knowledge which would normally reside, in fragmentary and highly changeable form, only in the heads of those involved.

3.3 Specific trials With the permission of the users we now relate two recent applications.

Sleep apnoea monitor This trial was carried out in relation to a MISC project to develop a monitoring device for use in sleep research in a major public hospital. Apnoea is a temporary cessation of effective breathing which can, in severe cases, happen hundreds of times throughout the night. The statement of the measurement task was accepted as: 'To determine breathing disturbances in a snoring patient.' It was initially resolved that the required referents were: • • • •

Tidal volume (air volume per breath). Chest expansion. Abdominal expansion. Phase between the above expansions.

114

These were rapidly transferred into measurands, the first three being accepted directly as volumes and the phase as angle (as in an Argand diagram, using an electrical analogy). The measurement parameters set for the volumes were as given in Table 1. TABLE 1 : Measurement parameters for volumes Minimum volume Maximum volume

0 2 litres 50 ml 50 ml 50 ml critical 50 ms 50 ml 20 ms 200 ml over 8 hours

Discrimination Repeatability Hysteresis Damping

Response time Error Settling time Drift

Discussion during the session soon elicited some other facts: • It is necessary not just to detect apnoea but to distinguish two different types. In one of these the throat blocks but the diaphragm keeps moving, trying to draw in air. In the other type of apnoea the diaphragm movement itself stops. • The most fundamental referents were not those first thought but instead were: Airflow through the throat. Diaphragm activity. • The referents initially chosen had presumed a particular solution for the task, using two expansion measuring devices, one around the chest and the other around the abdomen. It became apparent that this solution was inappropriate unless direct relationships were known between these expansion measurements and the (new) fundamental referents. No such relationship is known at present. The hospital staff are very sensitive to the feelings of their patients, who are asked to sleep while fitted with a range of sensors connected to a computer. The thought of fitting a device over their mouth and nose to measure airflow was mentally discarded virtually immediately. Direct measurement of diaphragm movement is also difficult. As diaphragm movement simultaneously expands the chest and the abdomen, measuring these expansions gives an indirect indication of the volumes required. However, it became obvious that the measurement parameters specified were unlikely to be achievable and only testing would provide any relationship between these measurements and breathing volumes. It is believed that the phase between these extensions gives an indication of throat blockage. Movement 180° out of phase indicates that chest expansion is being cancelled by abdominal contraction and airflow is likely to be zero. Again, only extensive testing would verify the truth of this assumption. The hospital staff, on reflection, felt that useful information could be gathered without meeting the originally stated parameters. As they believed that the twin expansion measurements still provided the system most acceptable to them, a S P E C R I T E R session was run to Measurement Vol 8 No 3, JuI-Sep 1990

Sydenham, Harris and Hancock measurants, yielding:

generate a specification for these expansion measurement devices. This forms the basis of the current MISC project in this area. The result of this MINDS consultation was therefore not an entirely satisfactory measuring system specification but rather:

•

Good water quality - Dissolved oxygen content. - Un-ionised ammonia content. - pH.

- Temperature. Salinity. - Turbidity. • Minimum stress No rapid changes in water quality factors.

• a fundamental re-consideration of just what information a measurement system is to provide; • a report outlining the testing required to establish relationships between the measurements and the new referents (without which the measurements will have very limited value); and • a specification for a chest expansion sensing device and how to use this device to determine apnoea.

-

-

There is a close inter-relationship between the water quality factors. For example, the desirable levels of dissolved oxygen are dependent on the water temperature. All of these parameters are also dependent upon the species of fish as well as the purpose of their being in the tank. Different conditions are required for prompting growth than for holding an animal at minimal growth. Following through to Measurand Specification, the data in Table 2 were obtained. The result of this session was a MINDS report which now serves as the basis of the development project for the water monitoring system. In addition, the data from MINDS has been used to generate S P E C R I T E R specifications for the dissolved oxygen sensor and the temperature sensor, both of which are currently under development within MISC. Several of the parameters were not provided by the user. Those marked * were considered unimportant. In other cases, as the user put it, 'the expert's advice will be accepted.' This is satisfactory in some cases but others (such as drift of the Dissolved Oxygen sensor) are very important, and this point was made to the user (and accepted) during the MINDS session. Generally, the user was unwilling to do the research necessary to resolve these points and it was left to the instrumentation designer to make proposals for acceptance. This application of MINDS was judged more directly successful than the apnoea case as regards the design and specification of the required instrumentation system. This is very largely because the sensing situation was better understood for the determination of water quality.

This trial might be classed as a 'difficult-to-measure' application of MINDS, similar to the 'quality of an orange' example, and the possibility of heading off on the wrong track due to unrecognised assumptions has been illustrated. It remains a challenge for the future development of MINDS to force the user to examine critically hidden assumptions.

Aquaculture water quality monitor MISC is developing an instrumentation system for monitoring the water quality of aquaculture tanks for marine fish species. This work is being carried out in conjunction with the South Australian Department of Fisheries and was selected as a project which could use all of the Centre's software developments. A MINDS session was held to determine the measurement parameters for this system. The statement of the task was accepted as: 'The task is to ascertain whether the fish are healthy.' It was resolved that the required referents were: • G o o d water quality. • G o o d food. • Minimum stress. (The researchers agreed that they would feel healthy under these conditions too!) G o o d food was considered outside the scope of this MINDS session but the other two fall within it. These referents were taken to the next level, all of which are

4.

Discussion

- areas

for future

development

The use of MINDS has been found to be effective in

TABLE 2: Water quality factors

Minimum Maximum Discrimination Repeatability Hysteresis Drift quantity Drift period Settling time Damping

D.O.

NH3

pH

Temp

Salinity

Turbidity

0 40 ppm 4ppm 2 ppm * 1 ppm 1 week 60 sec . .

0 3 ppb 0.5ppb * .

7 8 0.35 0.35 ~

5C 35 C 0.5C 0.25 C *

0. 40 ppt 400ppm * .

0 40 cm z * .

* .

. .

. .

* .

.

. .

Notes: eCurrently, turbidity is measured manually with a Secchi Disc, a marked disc which is lowered into the water until it can no longer be seen. It is difficult to provide a figure for discrimination with this kind of device. Electronic sensors exist for turbidity measurement and such a device will be needed eventually for an automated system. * These values were considered unimportant by the users. Measurement Vol 8 No 3, JuI-Sep 1990

115

Sydenham, Harris and Hancock establishing and specifying a required instrumentation system for a situation where measurement leads to knowledge about a process. However, users, especially those unskilled in instrumentation, have found problems in using it. As it is specifically targeted at these people, this must be an area for future development. Three points stand out in particular as needing development: 4.1 Establishing the goal In order for MINDS to function correctly the user must first state 'the overall goal. It has been our experience that users find this quite difficult. Most users approach MINDS with a solution in mind involving known measurements. After all, if it is a real problem, they will have given it some thought before sitting down in front of the terminal. They therefore often start too far down the measurement tree. This suggests that usual practice tends to be to start measuring in order to refine the knowledge requirement. MINDS is set u p to challenge this experimental methodology. Typically the user will start with a goal like 'measure the size of the orange'. When the MINDS session has been under way for some time the user will realise that a sub-goal has been selected as the major goal, and there is a need to establish a new tree level higher than the top level. MINDS at present does not allow this, other than by a re-start.

4.2 Establishing the referents Again, the user will usually have some mental solutions before commencing the MINDS session and these will influence the selection of referents. The apnoea monitor previously discussed is a case in point. Here, the user jumped directly to the chest/abdomen expansion as the referents when the true referents were actually quite different. Arriving at the correct referents is quite difficult - this is, of course, the essence of much scientific investigation! It requires the user to jump out of any previous mind-set and involves a lot of clear thinking as well as some imagination and creativity. It is difficult to see how this can be provided by machine-held knowledge and it has been our experience that the most effective method for arriving at the correct referents is discussion between the tutor and the user during the MINDS session. ' The authors feel that it would be helpful to both of the above problems to provide a graphic user interface with completely free-form generation of the tree structure and the contents of the boxes at the branches and leaves. This will allow the user's imagination free reign to edit and modify the system while providing a form for its capture and systematisation when a satisfactory result has been achieved. 4.3 The user interface There is little doubt that the most serious criticism of the MINDS program itself at present is its relatively primative user interface. While considerable effort has gone into making it as good as possible under the circumstances, these necessarily included the use of textonly terminals and limited student level development 116

time. Some problems identified are the: • Inability to create new tree levels higher than the start point. • Limited capability to show tree structures. • Inability to work directly in the tree structure. • Difficulty of changing data entered (possible but not obvious). MINDS has two important requirements, which computer programs are not normally required to achieve: • Provision of a support and encouragement facility for free-ranging thought by the user. • Capture of the results of this thinking process into a complete and formalised structure. A number of current developments in the field of Artificial Intelligence (AI) software offer promise in this regard and will be considered in future developments of MINDS. These include: • Tree structure generation, as is currently becoming available with some expert systems. • A hypertext approach to instrumentation data storage to allow the user easily to explore trains of thought.

5. C o n c l u s i o n s

The limited number of real trials carried out have clearly indicated that MINDS can be a valuable tool. The clarification of the instrumentation requirement and the production of a substantial report is of considerable benefit to the instrumentaion system designer in ensuring that the user's needs are met. The work has certainly exposed many factors pertinent to better understanding of how to set up a complex sensing interface. There are two areas in which human creativity and knowledge are essential: • Homing in onto the real referents. • Moving from measurands to satisfactory methods of measurement. No computer program can do these tasks for the user. Nevertheless, m o d e m developments in computer interface design provide the means for developing a friendly and supportive environment for the user to explore alternatives and make decisions. The fact that MINDS is only available on the V A X of the South Australian Institute of Technology is seen as a limitation in its possible use by others. Transfer to a PC is therefore currently being undertaken.

6. A c k n o w l e d g e m e n t s

The authors greatly appreciate the keen and enthusiastic assistance of the several Netherlands students who grappled with vague ideas put to them in order to write the software defining the several functions of MINDS. These were Andre Lensink, Wilbert van Leunen and Petra Hammes. One of us, David Harris, holds a National Research Fellowship of the Australian Research Committee and their support is gratefully acknowledged. Measurement Vol 8 No 3, JuI-Sep 1990

Sydenham, Harris and Hancock 7. References

Cook, S. 1988. Automatic generation of measuring instrument specifications. Measurement, 6(4), 155-160. Hammes, P. 1988. MINDS, the first completed version. MISC internal project report, South Australian Institute of Technology. Lensink, A. 1986. MINDS. The second research version. MISC internal project report, South Australian Institute of Technology. LUTCHI 1985. Private communication, SYNICS language supplied by LUTCHI Centre, Loughborough University of Technology, U.K. Sydenham, P. H. 1985a. Structured understanding of the measurement process: Part 1. Measurement and Control, 3(3), 115-120. Sydenham, P. H. 1985b. Structured understanding of the measurement process: Part 2. Measurement and Control, 3(3), 161-168. Sydenham, P. H. 1987. Computer aided engineering of measuring instrument systems. Computer Aided Engineering Jnl. IEE, 4(3), 117-123. Van Leunen, W. 1987. MINDS, an expert system with a natural language interface. MISC internal project report, South Australian Institute of Technology.

Addendum after review The review process suggested that a wider list of references to the work of others would be helpful. Although MISC researchers enjoy extensive global communica-

tions through such mechanisms as being reviewers, editors, conference paper authors and by having overseas placements and incoming visitors, the authors are sensitive to the appearance that work is carried out in isolation of the wider research community. Prior to publication opportunity was extended that allowed (in March 1990) an on-line INSPEC database search to be carried out. The hour-long search made use of logical combinations of the following key words reflecting an engineering approach - 'transducer: sensor: multisensor: instrument: measurement: system: specification: requirement: performance: selection: CAD: CAE: software'. This did not lead to any additional publications appropriate for inclusion, the closest being to a proprietary sensor selection software tool (Ong et al, Wichita State University, USA, 1989). A second cognitive-science approach used 'knowledge' combined with 'sensor'. This was fruitless, it not being possible to isolate papers about knowledge as an entity from those in the area of 'knowledge based' - for which numerous papers are published. Citation of work of authors of this paper was also explored without revealing any related work. We therefore feel comfortable that our research method is sound but remain uneasy that this work will be regarded as ineffective because of lack of other similar activity. What continues to surprise us is that despite millions (billions?) of sensors being in use, and hundreds of thousands being offered for sale at any time, there exists no systemic practice for their effective selection! This example well demonstrates the need for more foundational research into measurement science.

Contributions Contributions are invited on all aspects of the research, development and application of the science and technology of measurement. They may include results of research or experimental work, or may deal with practical developments related to plant or process. Full guide notes for contributors are to be found on the inside back cover.

Manuscripts should be sent

to:

T. R. Warren, Managing Editor Measurement, 60 Thames Street, Sunbury on Thames Middx. TW16 6AF

MeasurementVol 8 No 3, JuI-Sep1990

117