- Email: [email protected]
Intelligent sensor: Object approach
Control Eng. Practice, Vol. 3, No. 6, pp. 805-812, 1995 Copyright © 1995 Elsevier Science Ltd Printed in Great Britain. All rights reserved 0967-0661/95 $9.50 + 0.00
Pergamon 0967-0661(95)00063-1
INTELLIGENT SENSOR: OBJECT APPROACH D. Luttenbacher, S. Roth, M. Robert and C. Humbert Centre de Recherche en Automatique de Nancy, CNRS URA D821, Universit~ Henri Poincar~ Nancy 1, ESSTIN, 2 Rue Jean Lamour, 54500 Vandoeuvre, France
(Received March 1994; in final form December 1994)
Abstract: By way of introduction, the first section of this paper is about the need for models to represent the intelligent sensor (IS) concept. In the second section, the benefits brought by the use of Object Approach are discussed. The third section gives a brief description of the chosen method, the OMT methodology. In section four, an application example is proposed to illustrate an approach for modelling intelligent sensor measurement activity. Finally, as a conclusion, the requirements are shown for reaching the final objective of this work, the design of a CAD tool to provide more assistance for IS design. Keywords: Intelligent sensor, computer-aided design, object approach, Object Modelling Techniques (OMT)
1. INTRODUCTION
of services to the user, but not necessarily those which are really required. The construction should be based on standards, but as these do not yet actually exist, the design of an IS could be undertaken according to Reference Models.
Smart or "intelligent" sensors are becoming a reality in process control and industrial production systems. In the eighties, the demands for reliable measurements, expressed by engineers, led them to seek solutions that would no longer allow one to systematically put the blame on the sensor whenever a problem arises (Ciame, 1987). It is obviously the progress made in the related fields of microelectronics and microcomputer engineering, in association with the d e v e l o p m e n t of microprocessors, micro controllers or digital signal processors, that underlie the recent developments in the field of intelligent sensors (IS).
In this paper the proposed Object Approach (OA) is shown to be suitable to formalise the IS concept, and to build evolutionary models.
2. OBJECT APPROACH: LIFE CYCLE The main reasons for choosing the object paradigm for modelling the IS concepts are presented in this section. Figure 1 describes the thought processes involved in modelling.
Once they have been integrated in automation systems, then it is not so easy to connect a classical sensor, because intelligent instruments must be able to collaborate and to co-operate in order to make up a real distributed database, which must contain consistent information. It is therefore necessary to build models for IS to define as precisely as possible the services offered, the kind of information they are able to produce or consume, and their behaviour, in order to achieve interoperability (Robert et al., 1992; 1993a; 1993b).
In software engineering, the traditional description of the software life cycle is based on a underlying model, commonly referred to as the "waterfall" model (Boehm, 1976). This model initially attempts to discretise the identifiable activities within the software development process as a linear series of actions, each of which must be completed before the next is begun. Any graphical representation of the object-oriented version of the overall software development life cycle must take into account the implicit high degree of overlap and iteration. Rather than using a revised waterfall model, the "Fountain Model" of Fig. 1 seems to be appropriate (Henderson-Sellers et al., 1990). The life cycle thus grows upward to a
From a constructor or vendor's point of view, an approach to the construction of a piece of equipment where only the designer is involved, expressing how to "technologically" realise the equipment, cannot be satisfactorily applied to the realisation of an IS. This will result in a device which offers a certain number
805
806
D. Luttenbacher et al.
pinnacle of software use, falling back only in terms of necessary maintenance. This effectively reverts the stage of the cycle to a lower level. Application of this model to specific environments may lead to software life cycles such as prototyping. The system can be viewed not only in terms of the system~ life cycle, but also in terms of an amalgamation of a number of autonomous classes. Modifications can more easily be made interactively between class development and systems specification, so there is no longer a need to freeze the overall systems requirements specification at an early stage of the system life cycle.
This paper deals only with OOA, used to obtain a partial object model of the intelligent instrument (II), the IS family (IS represents a class of II, because intelligent actuators, for instance, also belong to the II meta-family). This orientation emphasises that object-oriented (OO) methods are useful to extract the "invariants" as "object-classes". These "invariants" are essential for the constructor. Because an IS is an association of hardware and software, the constructor is able to conceive his application as a set of reusable and evolutionary modules, so the time to develop a new product could be minimised and the vendor will adapt more quickly to the users' needs.
3. WHAT IS AN OBJECT APPROACH ? 3.1. Object approach In this section, the fundamental basis of the object technology (Afcet, 1991; Booch, 1986; Masini et al, 1990; Pernot and Wolinski, 1992; Wasserman et al, 1989) is presented. The term "object-oriented" means that software is organised as a collection of discrete objects. An object is an entity containing a set of data attributes which define its characteristics and its relationships with other objects, and a set of methods (operations) which describe its behaviour. In an object-oriented approach, "behaviour" describes how an object acts and reacts, in terms of its state changes and message-passing. "Class" is a technical word to describe a possibly infinite set of individual objects which have similar properties.
Fig. 1. The fountain model for the object-oriented software life cycle. Merging and overlap of activities are represented by the degree of overlap of the circle symbols. The decreased need for maintenance in an objectoriented system is symbolised by the smaller activity circle. In addition, the OA involves a global process of development for building systems by the way of three phases : Object-oriented analysis (OOA), Object-oriented design (OOD), used to design the application, Object-oriented programming (OOP), used to implement the design choices, in order to emphasise software evolution and maintenance.
The basic idea of the object approach is to organise a system from entities in which data and their associated methods are encapsulated. Abstraction and encapsulation are the fundamental mechanisms of the object concept : abstraction involves focusing on the essential or main characteristics of an entity (what an object is and does) and disregarding particular properties, before deciding how it should be implemented, encapsulation (also information hiding) involves separating the external aspects of an object which are accessible to other objects from the internal implementation details of the object which are hidden from other objects of the system. Abstraction allows one to build an entire object and to reduce it from a set of values and operations, which are used and understood by the external, real world. Abstraction and encapsulation are complementary concepts. Abstraction focuses on the external view of an object, and encapsulation prevents users from changing or modifying its internal organisation. The OOA includes other aspects to structure a system: inheritance and polymorphism. Inheritance is the sharing of attributes and operations among classes based on a hierarchical relationship. It facilitates the generalisation/specialisation mechanism. Polymorphism is another mechanism which means that the same operation may behave differently on different classes.
807
Intelligent Sensor: Object Approach 3
.
2
~
Building models with traditional methods such as SADT, is not sufficient because they do not support the encapsulation mechanism, in particular. Objectoriented methods allow one to define a system as a collection of reusable objects. Nevertheless, several methods exist with different graphical and syntactical notations and associated meanings (Graham, 1991), like those of Booch (1991), Rumbaugh (Rumbaugh et al, 1991), Martin-Odell (Martin and Odell, 1992), Shlaer (Shlaer and Mellor, 1988), Hood (1990), Coad (Coad and Yourdon, 1991). One of the main difficulties in selecting an object-oriented method comes from the choice of the appropriate method for a particular application.
context, but also available in more-general industrial production systems. Each of them gathers "classes" as proposed in Fig. 3. The six domains: data acquisition, data merging, situation estimation, decision, data management and data restoration, regroup functions which have the same characteristics such as communication, measurement and validation functions in different hierarchical levels. In the validation case it would be necessary to proceed in a progressive strengthening of the information credibility.
The object modelling techniques (OMT), the wellknown method formalised by J. Rumbaugh (Rumbaugh et al, 1991), have been chosen here to describe the IS concept. The methodology supports the entire software life cycle through the steps of initial formulation of the problem, problem analysis, system design, object design and implementation. One of the benefits of the OMT method is assuredly its ability to consider three aspects of a system: the information aspect which introduces the data structure, the functional aspect which concerns the semantics of an object's activities, and the behavioural aspect which is interested in a temporal model of the system's evolution. The OMT methodology captures the system in three models: the object model, which allows one to describe the static structure of the system by defining potential objects of the systems, the relationships between objects, the data attributes and the associated operations which characterise each class, the dynamic model, which describes the control structure of a system. It is used to specify and to implement temporal behaviour in terms of events and states, and the functional model, which allows one to define transformational processes of data in terms of values and functions. Each model describes one aspect of the system but contains references to the other models. In this method, the same notation is used throughout the development life cycle so that each of the three models is elaborated from analysis through design. It also allows the developer to elaborate selected parts of the system with design detail without having to maintain two separate system descriptions.
Fig. 2. IS and Albus domains. The modelling procedure should offer designers the possibility of achieving greater reusability for the software and hardware modules. It should also allow the users to describe their needs better, to understand the functioning of an IS more thoroughly, and to envisage more clearly, the integration of IS in their system. The proposed model gives the designer a guide to the best specification of its intelligent instrument. Virtual Instrument
4. IS OBJECT APPROACH Previous works (Robert et al, 1993a) have proposed the virtual instrument concept, which is an instantiation of an OO model, including six "domains" initially proposed by Albus (1991) (Fig. 2) to define an intelligent system in a robotic
Fig. 3. From classes to the virtual instrument. If only the "data acquisition domain" is considered, the measurement activity could be represented by the informal model shown in Fig. 4.
808
D. Luttenbacher et al.
One of the purposes of this section is to show how to define classes more precisely into a domain, using as an example, an intelligent temperature transmitter (ITT) with compensation for the temperature of the electronic components. This ITT includes as transducers a thermocouple to measure the temperature of the environment and a platinum resistance thermometer (SPRT) to acquire the temperature of the reference junction (also called the cold junction). The physical quantities which are directly related to the transducers and the internal hardware are divided into three classes: the measurand, which is the temperature of the physical environment, acquired through the thermocouple, the "influence" quantities, which is the temperature of the reference junction of the thermocouple, and the "self-checking" quantities, which are the temperature of the electronic components, the voltage of the power supply and the measurement evaluating the integrity of the measurement chain. All this information can also be classified into two types: "internal", meaning that information is generated by the sensor itself, and "external", meaning that information is supplied to the sensor by other components or by operators. For example, the value of an influence quantity could be measured by an IS located in another place. All this information is combined to give an operational measurement (OpM) which is valid data that can be immediately exploited by the user. For
Tim I .e
instance, the OpM desired by the user could be the average temperature over several values, expressed in degrees Celsius. The OpM is the projection of the valid measurement onto the user's reference. This valid measurement is obtained from a functional measurement (the temperature, of the physical environment, corrected by the reference junction temperature, in this example), which is composed of a primary measurement (the emf given by the t h e r m o c o u p l e ) together with an auxiliary measurement (the emf on both sides of the SPRT, when the current across the SPRT is regulated). This functional measurement is translated in a valid measurement by taking into account the technological measurements that characterise the good running of the intelligent sensor during the measurement. As far as the thermocouple and the SPRT are concerned, because the relationships between temperature and emf are non-linear, models are used to convert emf into temperature. The coefficients of these models are subject to accurate adjustment during a calibration step. Please note that: these different kinds of measurements have to be associated with information relating to local time, in order to ensure consistent dating, all the information used by algorithms running into the IS must be stored in an internal database. The Static part if this IS database contains for instance constructor's and user's identifiers, coefficients of models, etc., while the Dynamic one includes a historical record of measurements, failures and so on.
Models
Quantities
q
~"l Functional I I -" I W l i d a t e d
"ql
ii Fig. 4. Measurement activity.
I
"1 I Ope=tion l Meas. E
Me "
I
Intelligent Sensor: Object Approach The next section describes some functionalities of the software package used to illustrate the sensor model.
809
The first step consists in describing classes. Thus, links between some identified classes are extracted. Finally, by the use of the inheritance property, "invariants" are proposed in this object model.
5. LOV/OMT LOV/OMT editors are VERILOG tools especially dedicated to object-oriented analysis and design. Based on the object modelling technique (OMT), the wellknown method formalised by J. Rumbaugh of the General Electric Advanced Concept Centre, LOV/OMT enables users to describe their systems with class diagrams and related instance diagrams (object editor), state charts and event traces (behaviour editor) and data-flow diagrams (function editor). LOV provides more than the simple addition of three editors: each view refers to the other views. Functions and actors in a data-flow diagram can be operations and classes of a class diagram, and state charts can read or set attributes and run operations from a class. The LOV/OMT editors make it easy to express the relationship between the structural, behavioural and functional viewpoints. The LOV/object editor generates code automatically for all OMT constructs. The user can choose the default translation for each construct, override it locally or enter the body of functions manually when needed. User code can be entered without leaving the editor, or directly in the generated code. Concerning the documentation, textual annotations can be attached at any level (from class to operation parameter). Lastly, LOV/OMT provides powerful facilities for managing large models because they can easily be managed and split into smaller units. It is possible to refer to information from other files in a model: several users can work simultaneously on several parts of the same system, and changes propagate automatically from the source file to the client files. Within a class diagram file, the user can define several layers according to different viewpoints. The same object can be present in several modules. Modules are extremely useful for organising the model into a consistent collection of manageable domains. All modules are automatically kept consistent. The VERILOG LOV/OMT editors provide a multiwindow compliant interface. Editing can be performed in graphical and textual views. In the graphical views, palettes give rapid access to the various objects to be created, and pull-down and popup menus, and a drag-and-drop mechanism, make the editors as simple to handle as a drawing tool. Textual views synthesise all the information. They can be used to add and print notes and comments, as well as to browse through the descriptions. All the different views are automatically kept consistent at all times.
6. IS OBJECT MODEL To illustrate the approach taken in the work described here, a particular application example is provided, involving some concepts of an IS in order to model the elaboration of a measurement.
Figures 6 and 7 are diagrams of the object model from the requirements analysis document. The diagrams use the object modelling technique notation, in which classes are represented by boxes, each of which has a class name and, optionally, a set of attributes and operations. For example, the box labelled historical record in the upper left corner of Fig. 6 represents a class named "Historical Record" which has attributes "Data" and an operation "Maintain". In the example, the data archived could be the last OpMs arranged in chronological order, extremes of the measurement, the last errors which occurred during the different elaboration functions, and so on. Relations between classes, called "associations" by OMT, are represented by lines joining their boxes in the diagram. For example, the historical record can be related to measurement by the association archives. A complete description of the components of Fig. 6 will not be given here, but they will be briefly mentioned, in order to familiarise the reader with this notation. The triangle near the top of Fig. 6 indicates that the relationship between the measurement, primary measurement, auxiliary measurement, functional measurement, technological measurement, valid measurement and operational measurement objects is a generalisation. For example, the technological measurement object is a kind of measurement, used to provide information about the performance o f the IS to elaborate the valid measurement. Furthermore all functions of the class measurement are shared among the relationship, with polymorphism for the elaborate and the validate operations. This means that all subtypes of the class measurement have different elaborate and validate operations, but the same store and date operations. "elaborate" is a general term that corresponds to treatment operations for each type of measurement. In the example, for the auxiliary measurement class, the elaborate function involves the calibration of the emf on both sides of the SPRT, according to the lowest and highest forecast values of the current crossing the SPRT. Please note that the validation functionality and the measurement are not easily dissociable. This validation functionality is at the source of the attribute "intelligent" in the IS expression, because increased measurement credibility requires an interrogation of the conditions under which this measurement was obtained. It is necessary to proceed by a progressive strengthening of the information credibility. For e x a m p l e , the f u n c t i o n a l measurements are themselves labelled by taking into account the technological measurements. The integration of this type of information validation on different levels allows one to detect dysfunctioning on-line, to warn the user and to enable the intelligent sensor to function in a degraded mode.
810
D. Luttenbacher et al.
For example the validate function in the primary measurement class corresponds to the consistency between the measurement and the range of variation of the measurand, respecting the thermal restrictions towards the surroundings, as well as the validate function in the class auxiliary measurement. The diamond on the association between the valid measurement and the technological measurement object classes represents aggregation, so a valid measurement, which is a kind of measurement is made up of zero or more technological measurements. The black ball on the relation between model and measurement object classes is a multiplicity ball meaning "zero or more". Thus, while each measurement is elaborated, it can use zero or more models. These models are selected according to the type of measurement: they obviously are related to the type of thermocouple used for the primary measurement and to the type of SPRT used for the auxiliary measurement. Fig. 7 introduces the class physical quantity, used firstly for modelling the external data, such as the measurand and the influence quantities. Those quantities introduce the physical data which come from the measurement hardware system. However, it is necessary to transform those data into usable information. Those quantities must be translated into information to be treated in order to produce the OpM. 7. THE DYNAMIC MODEL The dynamic model consists of state diagrams for all the objects in the object model that display significant dynamic behaviour. The OpM is used here as an example, although only a part of its behaviour, is shown.
Temperaturemode cTemperaturein Fahrenheit /
onvert temp. to F J
U~er'srequtst cTemperature in ~'~ Celsius | onvert temp. to C.,)
Transitions are able to be activated by users' requests, by the way of the communication and configuration functionalities. The black ball represents the default initial state. It was discovered that the dynamic model was not maintained as well as the object model, because LOV/OMT does not address the dynamic model. This is seen as a significant weakness in the current implementation of LOV/OMT 8. CONCLUSION The object techniques have been investigated in this paper for modelling the IS concept. The problems related to knowledge representation are illustrated by a particular example, to show how to model the whole IS concept. As shown in Section 3.2, this object model must be completed with a functional model and a dynamical model. Functional models have already been produced by Rivi~re e t al. (1993), Bayart and Staroswiecki (1993) and G6hin (1993). A dynamic model is going to be realised in order to verify the feasibility of the global model, in a realtime context. The next step in this research work will be towards producing a CAD tool. This IS CAD toolbox could obviously be helpful for the designer to gather modules in order to reply to users' needs.However, this .tool could also be used by the user to define more precisely the specifications of an IS, so as to minimise the distance between designer and user. By trying to maximise the advantages of the application of the object-oriented paradigm, the fountain model seems appropriate. By using bottomup design for classes at the same time as top-down object-oriented systems design, interactions can be encouraged so that the design is more robust and at the same time more flexible, and the classes themselves are generically useful. Object-oriented encapsulation and inheritance favour the development of flexible components which can be reused and adapted later. This is why object oriented approaches improve reliability, reduce costs and delays, and ultimately forge the key to make software development an industry. OMT strikes a good balance between an easy-to-learn design tool and a highly expressive tool. OMT was used throughout the requirements analysis, design and implementation phases of the project. OMT has an associated tool, LOV/OMT with which the design can be entered in machine readable form, stored and modified by the developers. This design then forms the basis of the implementation in C++.
Fig. 5. Part of the dynamic model for measurement object. 9. ACKNOWLEDGEMENT This class is introduced as part of the object model in Fig. 6 and its dynamic model is applied to an intelligent temperature transmitter in Fig. 5. In this Figure the ovals represent states of the system and the arrows are labelled with events that cause transitions between the states.
The authors gratefully acknowledge the CRAN AMI Working Group and the VERILOG company who puts the LOV/OMT tool at their disposal. They also thank the CIAME Working Group members for their enriching discussions of intelligent sensors models.
Intelligent Sensor: Object Approach
811
CLA~ MODULEObjectModelfor the Measurement
l ain ...,.~
1="
~ i
le'b'v~"~!,
.
t' ~ " isv-~----'"
i
i
1
I "-"
1 J
0
m w . ~ Typl
t~~-
!
l,
i
J !
..
. 1 ' I ~
t
I~---
i
C~n~
i T u ~ Iv.,dm
Lore iob,.,n
V
ObjectEditor(e) VERILOG
I
Model: PubiI_IFAC.©d
I~ j
I
1994/06/24
J Page:1
Fig. 6. Part of the object model for intelligent sensors.
CLASS MODULEObjectModelfor Physicalquantitie
i ~tluemoqmmuty i
V
ObjectEditor(c) VERILOG J ,
Model: PublI_IFAC.¢d
Fig. 7. Object model for physical quantity showing only Inheritance.
I
1994/06/24
I
J Page:2
812
D. Luttenbacher et al. 10. REFERENCES
Afcet (1991). Objectifs objets!. Afcet interfaces, May-June, Vol. 103-104. Albus, J.S (1991). Outline for a theory of intelligence. IEEE transactions on Systems, Man and Cybernetics, Voi. 3, pp. 473-509. Bayart, M., and M. Staroswiecki (1993). A generic functional model of smart instrument for distributed architecture. Imeko TC4 Symposium Intelligent instrumentation for remote and on site measurement, May 12-13, Brussels, Belgium, pp. 231-238. Boehm, B.W. (1976). Software engineering. 1EEE Trans. Computer, Vol. C-25, pp. 12261241. Booch, G. (1986). Object-Oriented development. IEEE Trans. on software engineering, Vol. SE-12, 2, pp. 28-38. Booch,G. (1991). Object-Oriented Design with applications. Benjamin Cummings. Ciame, (1987). Les capteurs intelligents - R6flexions des utilisateurs. Ciame Afcet, Livre Blanc. Coad, P. and Yourdon, E. (1991). Object-Oriented Analysis, (Second Edition), Prentice Hall, Englewood Cliffs, NJ. G6hin, A.L. (1993). Analyse fonctionnelle et module g6n6rique des cateurs intelligents - Application la surveillance de l'anesth6sie. Thesis dissertation, Universt6 des Sciences et Techniques de Lille. Graham, I. (1991). Object Oriented Methods. Addison-Wesley Publishing Company. Henderson-Sellers, B., M. Edwards (1990). The object-oriented systems life cycle. Communications of the ACM, September, Vol. 33, pp. 143-159. Hood, (1990). Technical Group. Hood Reference Manual, October.
Martin, J. and Odell, J. (1992). Object-Oriented Analysis and Design. Prentice Hall, Englewood Cliffs, NJ. Masini, G., Napoli, D. Colnet, D. L6onard and K. Tombres (1990). Les langages h objets. Inter6ditions. Pernot, J.F and F. Wolinski (1992). Mod61isation par objets en robotique. Technique et Science Informatique, Vol. 11, 1, pp. 97-115. Rivi6re, J.M., M. Robert, F. Hermann and C. Aubrun (1993). Modelling of smart sensors : application to a smart temperature transmittert, lmeko TC4 Symposium Intelligent instrumentation for remote and on site measurement, May 12-13, Brussels, Belgium, pp. 173-180. Robert, M., J.M. Rivibre, J.L. Noizette and F.Herman (1992). Smart sensors in Flexible Manufacturing Systems. Sensors & Actuators Physics, Voi. 38-39, pp. 239-246. Robert, M., J.M. Rivi6re, D. Theillol and P. Geoffroy (1993a). Smart or intelligent instruments in industry, past, present and future. IAR Kolloquim, November 16, Duisburg Germany, pp. 77-86. Robert, M., M. Marchandiaux and M. Porte (1993b). Capteurs Intelligents et Mfthodologie d'Evaluation. Edition Hermes, Paris. Rumbaugh, J., M. Blaha, W. Premerlani, F. Eddy, W. Lorenson (1991). Object oriented modeling and design. Prentice Hall International Editions. Shlaer, S. and Mellor, S.J. (1988). Object-Oriented Systems Analysis : Modeling the world in data. Prentice Hall. Wasserman, A. P. Pircher and R.J. Muller (1989). Concepts of Object -Oriented Design. Tooi'89, pp. 269-280.
Pergamon 0967-0661(95)00063-1
INTELLIGENT SENSOR: OBJECT APPROACH D. Luttenbacher, S. Roth, M. Robert and C. Humbert Centre de Recherche en Automatique de Nancy, CNRS URA D821, Universit~ Henri Poincar~ Nancy 1, ESSTIN, 2 Rue Jean Lamour, 54500 Vandoeuvre, France
(Received March 1994; in final form December 1994)
Abstract: By way of introduction, the first section of this paper is about the need for models to represent the intelligent sensor (IS) concept. In the second section, the benefits brought by the use of Object Approach are discussed. The third section gives a brief description of the chosen method, the OMT methodology. In section four, an application example is proposed to illustrate an approach for modelling intelligent sensor measurement activity. Finally, as a conclusion, the requirements are shown for reaching the final objective of this work, the design of a CAD tool to provide more assistance for IS design. Keywords: Intelligent sensor, computer-aided design, object approach, Object Modelling Techniques (OMT)
1. INTRODUCTION
of services to the user, but not necessarily those which are really required. The construction should be based on standards, but as these do not yet actually exist, the design of an IS could be undertaken according to Reference Models.
Smart or "intelligent" sensors are becoming a reality in process control and industrial production systems. In the eighties, the demands for reliable measurements, expressed by engineers, led them to seek solutions that would no longer allow one to systematically put the blame on the sensor whenever a problem arises (Ciame, 1987). It is obviously the progress made in the related fields of microelectronics and microcomputer engineering, in association with the d e v e l o p m e n t of microprocessors, micro controllers or digital signal processors, that underlie the recent developments in the field of intelligent sensors (IS).
In this paper the proposed Object Approach (OA) is shown to be suitable to formalise the IS concept, and to build evolutionary models.
2. OBJECT APPROACH: LIFE CYCLE The main reasons for choosing the object paradigm for modelling the IS concepts are presented in this section. Figure 1 describes the thought processes involved in modelling.
Once they have been integrated in automation systems, then it is not so easy to connect a classical sensor, because intelligent instruments must be able to collaborate and to co-operate in order to make up a real distributed database, which must contain consistent information. It is therefore necessary to build models for IS to define as precisely as possible the services offered, the kind of information they are able to produce or consume, and their behaviour, in order to achieve interoperability (Robert et al., 1992; 1993a; 1993b).
In software engineering, the traditional description of the software life cycle is based on a underlying model, commonly referred to as the "waterfall" model (Boehm, 1976). This model initially attempts to discretise the identifiable activities within the software development process as a linear series of actions, each of which must be completed before the next is begun. Any graphical representation of the object-oriented version of the overall software development life cycle must take into account the implicit high degree of overlap and iteration. Rather than using a revised waterfall model, the "Fountain Model" of Fig. 1 seems to be appropriate (Henderson-Sellers et al., 1990). The life cycle thus grows upward to a
From a constructor or vendor's point of view, an approach to the construction of a piece of equipment where only the designer is involved, expressing how to "technologically" realise the equipment, cannot be satisfactorily applied to the realisation of an IS. This will result in a device which offers a certain number
805
806
D. Luttenbacher et al.
pinnacle of software use, falling back only in terms of necessary maintenance. This effectively reverts the stage of the cycle to a lower level. Application of this model to specific environments may lead to software life cycles such as prototyping. The system can be viewed not only in terms of the system~ life cycle, but also in terms of an amalgamation of a number of autonomous classes. Modifications can more easily be made interactively between class development and systems specification, so there is no longer a need to freeze the overall systems requirements specification at an early stage of the system life cycle.
This paper deals only with OOA, used to obtain a partial object model of the intelligent instrument (II), the IS family (IS represents a class of II, because intelligent actuators, for instance, also belong to the II meta-family). This orientation emphasises that object-oriented (OO) methods are useful to extract the "invariants" as "object-classes". These "invariants" are essential for the constructor. Because an IS is an association of hardware and software, the constructor is able to conceive his application as a set of reusable and evolutionary modules, so the time to develop a new product could be minimised and the vendor will adapt more quickly to the users' needs.
3. WHAT IS AN OBJECT APPROACH ? 3.1. Object approach In this section, the fundamental basis of the object technology (Afcet, 1991; Booch, 1986; Masini et al, 1990; Pernot and Wolinski, 1992; Wasserman et al, 1989) is presented. The term "object-oriented" means that software is organised as a collection of discrete objects. An object is an entity containing a set of data attributes which define its characteristics and its relationships with other objects, and a set of methods (operations) which describe its behaviour. In an object-oriented approach, "behaviour" describes how an object acts and reacts, in terms of its state changes and message-passing. "Class" is a technical word to describe a possibly infinite set of individual objects which have similar properties.
Fig. 1. The fountain model for the object-oriented software life cycle. Merging and overlap of activities are represented by the degree of overlap of the circle symbols. The decreased need for maintenance in an objectoriented system is symbolised by the smaller activity circle. In addition, the OA involves a global process of development for building systems by the way of three phases : Object-oriented analysis (OOA), Object-oriented design (OOD), used to design the application, Object-oriented programming (OOP), used to implement the design choices, in order to emphasise software evolution and maintenance.
The basic idea of the object approach is to organise a system from entities in which data and their associated methods are encapsulated. Abstraction and encapsulation are the fundamental mechanisms of the object concept : abstraction involves focusing on the essential or main characteristics of an entity (what an object is and does) and disregarding particular properties, before deciding how it should be implemented, encapsulation (also information hiding) involves separating the external aspects of an object which are accessible to other objects from the internal implementation details of the object which are hidden from other objects of the system. Abstraction allows one to build an entire object and to reduce it from a set of values and operations, which are used and understood by the external, real world. Abstraction and encapsulation are complementary concepts. Abstraction focuses on the external view of an object, and encapsulation prevents users from changing or modifying its internal organisation. The OOA includes other aspects to structure a system: inheritance and polymorphism. Inheritance is the sharing of attributes and operations among classes based on a hierarchical relationship. It facilitates the generalisation/specialisation mechanism. Polymorphism is another mechanism which means that the same operation may behave differently on different classes.
807
Intelligent Sensor: Object Approach 3
.
2
~
Building models with traditional methods such as SADT, is not sufficient because they do not support the encapsulation mechanism, in particular. Objectoriented methods allow one to define a system as a collection of reusable objects. Nevertheless, several methods exist with different graphical and syntactical notations and associated meanings (Graham, 1991), like those of Booch (1991), Rumbaugh (Rumbaugh et al, 1991), Martin-Odell (Martin and Odell, 1992), Shlaer (Shlaer and Mellor, 1988), Hood (1990), Coad (Coad and Yourdon, 1991). One of the main difficulties in selecting an object-oriented method comes from the choice of the appropriate method for a particular application.
context, but also available in more-general industrial production systems. Each of them gathers "classes" as proposed in Fig. 3. The six domains: data acquisition, data merging, situation estimation, decision, data management and data restoration, regroup functions which have the same characteristics such as communication, measurement and validation functions in different hierarchical levels. In the validation case it would be necessary to proceed in a progressive strengthening of the information credibility.
The object modelling techniques (OMT), the wellknown method formalised by J. Rumbaugh (Rumbaugh et al, 1991), have been chosen here to describe the IS concept. The methodology supports the entire software life cycle through the steps of initial formulation of the problem, problem analysis, system design, object design and implementation. One of the benefits of the OMT method is assuredly its ability to consider three aspects of a system: the information aspect which introduces the data structure, the functional aspect which concerns the semantics of an object's activities, and the behavioural aspect which is interested in a temporal model of the system's evolution. The OMT methodology captures the system in three models: the object model, which allows one to describe the static structure of the system by defining potential objects of the systems, the relationships between objects, the data attributes and the associated operations which characterise each class, the dynamic model, which describes the control structure of a system. It is used to specify and to implement temporal behaviour in terms of events and states, and the functional model, which allows one to define transformational processes of data in terms of values and functions. Each model describes one aspect of the system but contains references to the other models. In this method, the same notation is used throughout the development life cycle so that each of the three models is elaborated from analysis through design. It also allows the developer to elaborate selected parts of the system with design detail without having to maintain two separate system descriptions.
Fig. 2. IS and Albus domains. The modelling procedure should offer designers the possibility of achieving greater reusability for the software and hardware modules. It should also allow the users to describe their needs better, to understand the functioning of an IS more thoroughly, and to envisage more clearly, the integration of IS in their system. The proposed model gives the designer a guide to the best specification of its intelligent instrument. Virtual Instrument
4. IS OBJECT APPROACH Previous works (Robert et al, 1993a) have proposed the virtual instrument concept, which is an instantiation of an OO model, including six "domains" initially proposed by Albus (1991) (Fig. 2) to define an intelligent system in a robotic
Fig. 3. From classes to the virtual instrument. If only the "data acquisition domain" is considered, the measurement activity could be represented by the informal model shown in Fig. 4.
808
D. Luttenbacher et al.
One of the purposes of this section is to show how to define classes more precisely into a domain, using as an example, an intelligent temperature transmitter (ITT) with compensation for the temperature of the electronic components. This ITT includes as transducers a thermocouple to measure the temperature of the environment and a platinum resistance thermometer (SPRT) to acquire the temperature of the reference junction (also called the cold junction). The physical quantities which are directly related to the transducers and the internal hardware are divided into three classes: the measurand, which is the temperature of the physical environment, acquired through the thermocouple, the "influence" quantities, which is the temperature of the reference junction of the thermocouple, and the "self-checking" quantities, which are the temperature of the electronic components, the voltage of the power supply and the measurement evaluating the integrity of the measurement chain. All this information can also be classified into two types: "internal", meaning that information is generated by the sensor itself, and "external", meaning that information is supplied to the sensor by other components or by operators. For example, the value of an influence quantity could be measured by an IS located in another place. All this information is combined to give an operational measurement (OpM) which is valid data that can be immediately exploited by the user. For
Tim I .e
instance, the OpM desired by the user could be the average temperature over several values, expressed in degrees Celsius. The OpM is the projection of the valid measurement onto the user's reference. This valid measurement is obtained from a functional measurement (the temperature, of the physical environment, corrected by the reference junction temperature, in this example), which is composed of a primary measurement (the emf given by the t h e r m o c o u p l e ) together with an auxiliary measurement (the emf on both sides of the SPRT, when the current across the SPRT is regulated). This functional measurement is translated in a valid measurement by taking into account the technological measurements that characterise the good running of the intelligent sensor during the measurement. As far as the thermocouple and the SPRT are concerned, because the relationships between temperature and emf are non-linear, models are used to convert emf into temperature. The coefficients of these models are subject to accurate adjustment during a calibration step. Please note that: these different kinds of measurements have to be associated with information relating to local time, in order to ensure consistent dating, all the information used by algorithms running into the IS must be stored in an internal database. The Static part if this IS database contains for instance constructor's and user's identifiers, coefficients of models, etc., while the Dynamic one includes a historical record of measurements, failures and so on.
Models
Quantities
q
~"l Functional I I -" I W l i d a t e d
"ql
ii Fig. 4. Measurement activity.
I
"1 I Ope=tion l Meas. E
Me "
I
Intelligent Sensor: Object Approach The next section describes some functionalities of the software package used to illustrate the sensor model.
809
The first step consists in describing classes. Thus, links between some identified classes are extracted. Finally, by the use of the inheritance property, "invariants" are proposed in this object model.
5. LOV/OMT LOV/OMT editors are VERILOG tools especially dedicated to object-oriented analysis and design. Based on the object modelling technique (OMT), the wellknown method formalised by J. Rumbaugh of the General Electric Advanced Concept Centre, LOV/OMT enables users to describe their systems with class diagrams and related instance diagrams (object editor), state charts and event traces (behaviour editor) and data-flow diagrams (function editor). LOV provides more than the simple addition of three editors: each view refers to the other views. Functions and actors in a data-flow diagram can be operations and classes of a class diagram, and state charts can read or set attributes and run operations from a class. The LOV/OMT editors make it easy to express the relationship between the structural, behavioural and functional viewpoints. The LOV/object editor generates code automatically for all OMT constructs. The user can choose the default translation for each construct, override it locally or enter the body of functions manually when needed. User code can be entered without leaving the editor, or directly in the generated code. Concerning the documentation, textual annotations can be attached at any level (from class to operation parameter). Lastly, LOV/OMT provides powerful facilities for managing large models because they can easily be managed and split into smaller units. It is possible to refer to information from other files in a model: several users can work simultaneously on several parts of the same system, and changes propagate automatically from the source file to the client files. Within a class diagram file, the user can define several layers according to different viewpoints. The same object can be present in several modules. Modules are extremely useful for organising the model into a consistent collection of manageable domains. All modules are automatically kept consistent. The VERILOG LOV/OMT editors provide a multiwindow compliant interface. Editing can be performed in graphical and textual views. In the graphical views, palettes give rapid access to the various objects to be created, and pull-down and popup menus, and a drag-and-drop mechanism, make the editors as simple to handle as a drawing tool. Textual views synthesise all the information. They can be used to add and print notes and comments, as well as to browse through the descriptions. All the different views are automatically kept consistent at all times.
6. IS OBJECT MODEL To illustrate the approach taken in the work described here, a particular application example is provided, involving some concepts of an IS in order to model the elaboration of a measurement.
Figures 6 and 7 are diagrams of the object model from the requirements analysis document. The diagrams use the object modelling technique notation, in which classes are represented by boxes, each of which has a class name and, optionally, a set of attributes and operations. For example, the box labelled historical record in the upper left corner of Fig. 6 represents a class named "Historical Record" which has attributes "Data" and an operation "Maintain". In the example, the data archived could be the last OpMs arranged in chronological order, extremes of the measurement, the last errors which occurred during the different elaboration functions, and so on. Relations between classes, called "associations" by OMT, are represented by lines joining their boxes in the diagram. For example, the historical record can be related to measurement by the association archives. A complete description of the components of Fig. 6 will not be given here, but they will be briefly mentioned, in order to familiarise the reader with this notation. The triangle near the top of Fig. 6 indicates that the relationship between the measurement, primary measurement, auxiliary measurement, functional measurement, technological measurement, valid measurement and operational measurement objects is a generalisation. For example, the technological measurement object is a kind of measurement, used to provide information about the performance o f the IS to elaborate the valid measurement. Furthermore all functions of the class measurement are shared among the relationship, with polymorphism for the elaborate and the validate operations. This means that all subtypes of the class measurement have different elaborate and validate operations, but the same store and date operations. "elaborate" is a general term that corresponds to treatment operations for each type of measurement. In the example, for the auxiliary measurement class, the elaborate function involves the calibration of the emf on both sides of the SPRT, according to the lowest and highest forecast values of the current crossing the SPRT. Please note that the validation functionality and the measurement are not easily dissociable. This validation functionality is at the source of the attribute "intelligent" in the IS expression, because increased measurement credibility requires an interrogation of the conditions under which this measurement was obtained. It is necessary to proceed by a progressive strengthening of the information credibility. For e x a m p l e , the f u n c t i o n a l measurements are themselves labelled by taking into account the technological measurements. The integration of this type of information validation on different levels allows one to detect dysfunctioning on-line, to warn the user and to enable the intelligent sensor to function in a degraded mode.
810
D. Luttenbacher et al.
For example the validate function in the primary measurement class corresponds to the consistency between the measurement and the range of variation of the measurand, respecting the thermal restrictions towards the surroundings, as well as the validate function in the class auxiliary measurement. The diamond on the association between the valid measurement and the technological measurement object classes represents aggregation, so a valid measurement, which is a kind of measurement is made up of zero or more technological measurements. The black ball on the relation between model and measurement object classes is a multiplicity ball meaning "zero or more". Thus, while each measurement is elaborated, it can use zero or more models. These models are selected according to the type of measurement: they obviously are related to the type of thermocouple used for the primary measurement and to the type of SPRT used for the auxiliary measurement. Fig. 7 introduces the class physical quantity, used firstly for modelling the external data, such as the measurand and the influence quantities. Those quantities introduce the physical data which come from the measurement hardware system. However, it is necessary to transform those data into usable information. Those quantities must be translated into information to be treated in order to produce the OpM. 7. THE DYNAMIC MODEL The dynamic model consists of state diagrams for all the objects in the object model that display significant dynamic behaviour. The OpM is used here as an example, although only a part of its behaviour, is shown.
Temperaturemode cTemperaturein Fahrenheit /
onvert temp. to F J
U~er'srequtst cTemperature in ~'~ Celsius | onvert temp. to C.,)
Transitions are able to be activated by users' requests, by the way of the communication and configuration functionalities. The black ball represents the default initial state. It was discovered that the dynamic model was not maintained as well as the object model, because LOV/OMT does not address the dynamic model. This is seen as a significant weakness in the current implementation of LOV/OMT 8. CONCLUSION The object techniques have been investigated in this paper for modelling the IS concept. The problems related to knowledge representation are illustrated by a particular example, to show how to model the whole IS concept. As shown in Section 3.2, this object model must be completed with a functional model and a dynamical model. Functional models have already been produced by Rivi~re e t al. (1993), Bayart and Staroswiecki (1993) and G6hin (1993). A dynamic model is going to be realised in order to verify the feasibility of the global model, in a realtime context. The next step in this research work will be towards producing a CAD tool. This IS CAD toolbox could obviously be helpful for the designer to gather modules in order to reply to users' needs.However, this .tool could also be used by the user to define more precisely the specifications of an IS, so as to minimise the distance between designer and user. By trying to maximise the advantages of the application of the object-oriented paradigm, the fountain model seems appropriate. By using bottomup design for classes at the same time as top-down object-oriented systems design, interactions can be encouraged so that the design is more robust and at the same time more flexible, and the classes themselves are generically useful. Object-oriented encapsulation and inheritance favour the development of flexible components which can be reused and adapted later. This is why object oriented approaches improve reliability, reduce costs and delays, and ultimately forge the key to make software development an industry. OMT strikes a good balance between an easy-to-learn design tool and a highly expressive tool. OMT was used throughout the requirements analysis, design and implementation phases of the project. OMT has an associated tool, LOV/OMT with which the design can be entered in machine readable form, stored and modified by the developers. This design then forms the basis of the implementation in C++.
Fig. 5. Part of the dynamic model for measurement object. 9. ACKNOWLEDGEMENT This class is introduced as part of the object model in Fig. 6 and its dynamic model is applied to an intelligent temperature transmitter in Fig. 5. In this Figure the ovals represent states of the system and the arrows are labelled with events that cause transitions between the states.
The authors gratefully acknowledge the CRAN AMI Working Group and the VERILOG company who puts the LOV/OMT tool at their disposal. They also thank the CIAME Working Group members for their enriching discussions of intelligent sensors models.
Intelligent Sensor: Object Approach
811
CLA~ MODULEObjectModelfor the Measurement
l ain ...,.~
1="
~ i
le'b'v~"~!,
.
t' ~ " isv-~----'"
i
i
1
I "-"
1 J
0
m w . ~ Typl
t~~-
!
l,
i
J !
..
. 1 ' I ~
t
I~---
i
C~n~
i T u ~ Iv.,dm
Lore iob,.,n
V
ObjectEditor(e) VERILOG
I
Model: PubiI_IFAC.©d
I~ j
I
1994/06/24
J Page:1
Fig. 6. Part of the object model for intelligent sensors.
CLASS MODULEObjectModelfor Physicalquantitie
i ~tluemoqmmuty i
V
ObjectEditor(c) VERILOG J ,
Model: PublI_IFAC.¢d
Fig. 7. Object model for physical quantity showing only Inheritance.
I
1994/06/24
I
J Page:2
812
D. Luttenbacher et al. 10. REFERENCES
Afcet (1991). Objectifs objets!. Afcet interfaces, May-June, Vol. 103-104. Albus, J.S (1991). Outline for a theory of intelligence. IEEE transactions on Systems, Man and Cybernetics, Voi. 3, pp. 473-509. Bayart, M., and M. Staroswiecki (1993). A generic functional model of smart instrument for distributed architecture. Imeko TC4 Symposium Intelligent instrumentation for remote and on site measurement, May 12-13, Brussels, Belgium, pp. 231-238. Boehm, B.W. (1976). Software engineering. 1EEE Trans. Computer, Vol. C-25, pp. 12261241. Booch, G. (1986). Object-Oriented development. IEEE Trans. on software engineering, Vol. SE-12, 2, pp. 28-38. Booch,G. (1991). Object-Oriented Design with applications. Benjamin Cummings. Ciame, (1987). Les capteurs intelligents - R6flexions des utilisateurs. Ciame Afcet, Livre Blanc. Coad, P. and Yourdon, E. (1991). Object-Oriented Analysis, (Second Edition), Prentice Hall, Englewood Cliffs, NJ. G6hin, A.L. (1993). Analyse fonctionnelle et module g6n6rique des cateurs intelligents - Application la surveillance de l'anesth6sie. Thesis dissertation, Universt6 des Sciences et Techniques de Lille. Graham, I. (1991). Object Oriented Methods. Addison-Wesley Publishing Company. Henderson-Sellers, B., M. Edwards (1990). The object-oriented systems life cycle. Communications of the ACM, September, Vol. 33, pp. 143-159. Hood, (1990). Technical Group. Hood Reference Manual, October.
Martin, J. and Odell, J. (1992). Object-Oriented Analysis and Design. Prentice Hall, Englewood Cliffs, NJ. Masini, G., Napoli, D. Colnet, D. L6onard and K. Tombres (1990). Les langages h objets. Inter6ditions. Pernot, J.F and F. Wolinski (1992). Mod61isation par objets en robotique. Technique et Science Informatique, Vol. 11, 1, pp. 97-115. Rivi6re, J.M., M. Robert, F. Hermann and C. Aubrun (1993). Modelling of smart sensors : application to a smart temperature transmittert, lmeko TC4 Symposium Intelligent instrumentation for remote and on site measurement, May 12-13, Brussels, Belgium, pp. 173-180. Robert, M., J.M. Rivibre, J.L. Noizette and F.Herman (1992). Smart sensors in Flexible Manufacturing Systems. Sensors & Actuators Physics, Voi. 38-39, pp. 239-246. Robert, M., J.M. Rivi6re, D. Theillol and P. Geoffroy (1993a). Smart or intelligent instruments in industry, past, present and future. IAR Kolloquim, November 16, Duisburg Germany, pp. 77-86. Robert, M., M. Marchandiaux and M. Porte (1993b). Capteurs Intelligents et Mfthodologie d'Evaluation. Edition Hermes, Paris. Rumbaugh, J., M. Blaha, W. Premerlani, F. Eddy, W. Lorenson (1991). Object oriented modeling and design. Prentice Hall International Editions. Shlaer, S. and Mellor, S.J. (1988). Object-Oriented Systems Analysis : Modeling the world in data. Prentice Hall. Wasserman, A. P. Pircher and R.J. Muller (1989). Concepts of Object -Oriented Design. Tooi'89, pp. 269-280.