Toward a Safe Design of CANopen Distributed ... - Semantic Scholar

IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT, VOL. 55, NO. 3, JUNE 2006

771

Toward a Safe Design of CANopen Distributed Instruments Eric Benoit, André Chovin, Laurent Foulloy, Alain Chatenay, and Gilles Mauris

Abstract—This paper proposes a modeling for a safe design of intelligent instruments distributed on a CANopen fieldbus. It gives a brief summary of the service-based User Operating Mode modeling and the specificity of the application layer of the CANopen fieldbus, followed by a presentation of the application to a safe design of CANopen distributed instruments. An example of the instrumentation of an open-channel irrigation canal is used to illustrate these concepts. Index Terms—CANopen, fieldbus, intelligent instrument, software design, software modeling.

I. I NTRODUCTION

T

HE DESIGN of intelligent distributed instruments, i.e., sensors and actuators, is a complex problem. Competence in physics, mechanics, and computing science are needed for this design, and important constraints from the instrument hardware or the chosen fieldbus have to be respected. Furthermore, the design of intelligent instruments is distributed between the company that builds it and the systems integrator who adapts the instruments to the application. Recent studies have proposed instrument modeling based on a set of functionalities organized with a general behavioral description, i.e., automation graphs [1], [2] or object models [3]–[5]. The internal modeling of intelligent instruments is not sufficient for the design of large applications. Obviously, intelligent instruments need to interoperate. Therefore, an external model of intelligent instruments is required. In [6] and [7], Staroswiecki et al. propose to model a sensor by a set of services which are organized into subsets called User Operating Modes (USOMs). The approach discussed in [6] was proposed to model existing instruments from an external point of view. In particular, the external model of the instrument can be used to build a global model for an application involving several instruments. In this paper, we present an improvement of the approach presented in [8] and [9] that defines the internal functional model of an instrument that is compatible with the USOM modeling [10], [11].

Manuscript received June 15, 2005; revised November 21, 2005. This work is part of the SYCADI French program supported by the “Région Rhone-Alpes” and includes the Institut National Polytechnique de Grenoble, the Laboratoire d’Informatique, Systèmes, Traitement de l’Information et de la Connaissance (LISTIC) of Université de Savoie, and Crouzet Automatisme of the Schneider Electric Group. The authors are with the Laboratoire d’Informatique, Systèmes, Traitement de l’Information et de la Connaissance (LISTIC)-Ecole Supérieure d’Ingénieurs d’Annecy (ESIA), Université de Savoie, Annecy Cedex F-74016, France (e-mail: [email protected]). Digital Object Identifier 10.1109/TIM.2006.873798

This approach divides the smart instrument design into three levels. 1) The instrument user level, based on the external instrument model: This level concerns the final user who performs service requests and changes the instrument modes. 2) The instrument designer level, based on the internal instrument model: This level concerns the systems integrator who creates services adapted to the application and the customer requirements. 3) The software designer level, where atomic parts of software are created: This level concerns the company that designs the instrument. Using both internal and external models increases the safety of the instrument design and use. The separation between the designer action and the work of the software designer makes it possible to quickly adapt a product to a user’s specific needs. Indeed, the software designer creates basic algorithms and pieces of software that use the instrument hardware. These software materials are then checked to validate and implement them into the commercial product. They are the atomic software parts for a complete family of instruments that will be designed. The instrument designer receives this kind of intelligent instrument and only has to create the instrument behavior to respond to the user’s requirements. It is important that the designer of the instruments does not create or introduce new pieces of software. Indeed, adding unchecked software could introduce errors into the instrument behavior leading the final customer to reject the product, i.e., the intelligent instrument. If a new function is needed, it must be created and validated by the software designer. The final user, i.e., human or another instrument, can modify the instrument’s parameters like a normal instrument. The behavior of the instrument can also be influenced by changing the modes and requesting services. It must be remembered that this approach for the design of the instrument has been introduced to reduce the time spent on design. Furthermore, this approach must also increase the functional safety of the instrument regarding the IEC61508 functional safety standard [12]. The idea is to apply important constraints on the last step of the instrument design. The modeling of a software architecture approach [14] has a layered architecture style (Fig. 1). The lower layer, i.e., the software designer level, has a pipe-and-filter architecture style, and the higher layer, i.e., the instrument designer level, has an event-based style. The object approach is not used in this modeling, but it can be introduced into the lower layer for the interchangeability of internal services.

0018-9456/$20.00 © 2006 IEEE

772


Fig. 1. Service-based instrument model.

This paper shows that various requirements of the CANopen protocol can be introduced into the three levels of the instrument modeling. Section II presents USOM modeling. CANopen-based instruments are introduced in Section IV, and specific aspects are exposed. Section V is concerned with USOM modeling of CANopen instruments. Finally, automatic code generation of intelligent instruments is presented in Section VI. II. USOM M ODELING The external instrument model is based on USOMs. In this model, instrument functionalities are considered as services, and instrument states called USOM are defined as subsets of instrument services. In [7], Bouras and Staroswiecki have defined USOMs by four principles. 1) An USOM is a subset of the set of services provided by the intelligent sensor. 2) An USOM includes at least one service. 3) Each service belongs to at least one user operating mode. 4) A service can be requested if and only if the current USOM offers this service, i.e., the USOM includes this service. This approach avoids using the instrument services incorrectly and improves the safety of the instrument. We can consider that creating the USOM model of an instrument is defining the user specification of this instrument. Indeed, the user defines all the services he wants the instrument to be equipped with. He also defines all the possible states (USOM) of the instrument and associates any service to one or more USOMs. To improve safety, constraints about mode switching are applied through a state graph of USOMs. Let us now consider an internal point of view of the instrument where previous services are then called external services. New services, which are called internal services, are defined and created by the software designer [13]. They are masked to the user and can only be requested by another service of this sensor. They include algorithms like filtering and signal processing or deal with the hardware of the instrument such as transducers or the fieldbus. First, a sequencing of internal services is defined through a graph where each node is an internal service, a meeting point (Rdv node), or an event connector, and each arch is an event [8]. The sequencing of internal services defines the authorized event flow that activates internal services. Events used for sequencing

are produced when an internal service ends. If the programmer chooses to define the dataflow into the eventflow, then data occurrences are linked with events. He can also choose to define the dataflow as a separate flow like the IEC61499 Function Block modeling where he currently has to create the associated code according to the chosen modeling and must know the maximum duration of each internal service. At this step, it was proposed in [8] and [17] to define external services as subsets of the set of internal services respecting simple constraints. This approach was chosen to simply define services, but some limitations had been discovered. For example, it was not possible to define into the same instrument a service including a filtering process and the same service without the filtering process. Let {i1 , i2 , i3 }, {(i1 , i2 ), (i2 , i3 ), (i1 , i3 )} be the internal service graph and i2 be the internal service that performs the filtering process. Let s1 = {i1 , i2 , i3 } be the service that uses the filter i2 and s2 = {i1 , i3 } be the same service without the filter. The subgraph used to perform the service s2 is {i1 , i3 }, {(i1 , i3 )} and fits the expected behavior. The subgraph used to perform the service s1 is {i1 , i2 , i3 }, {(i1 , i2 ), (i2 , i3 ), (i1 , i3 )}. It does not fit the expected behavior that will be {i1 , i2 , i3 }, {(i1 , i2 ), (i2 , i3 )}. To prevent such a shift between the model and the effective behavior, external services are now defined as subgraphs of the internal service graph. Several constraints must be respected. — In the union of graphs of services that leads to the same USOM, the internal services and output event connectors must receive only one event. The only nodes that can receive more than one event are meeting nodes. This constraint prevents multiple simultaneous activations of the same internal service. — Tops of graphs of any service must be input event connectors. This constraint prevents the definition of unusable services. The Internal Operating Modes (INOMs) are internal states of the instrument. These internal states influence the availability of the internal services and are not visible to the user. For example, usual INOMs can be “nominal” state, “degraded” state, and “critical” state. The implementation of each internal service has to be defined for each INOM. III. A PPLICATION E XAMPLE To illustrate the approach, let us give an example of USOM modeling. In this example, an open-channel hydraulic system is controlled with a set of identical intelligent instruments. This application is an existing irrigation system, called the “canal de la Bourne,” which is situated in the agricultural area of Valence in France. It is the object of the SYCADI French program supported by the “Région Rhone-Alpes.” First presented in [17], the application was used to implement a control algorithm [9]. To test software solutions, a miniature had been created during the project. In Fig. 2, two instruments and their logical connections are presented. In this figure, the IEC 1131.3 Function Block model is chosen to present the example. A fieldbus, which is not represented in the figure, gives a support for the logical connections. Each instrument used on the

BENOIT et al.: TOWARD A SAFE DESIGN OF CANopen DISTRIBUTED INSTRUMENTS

Fig. 2.

773

Instrumentation of an open-channel irrigation canal.

Fig. 4. Internal services and eventflow.

Fig. 3.

USOM state graph and services.

open-channel irrigation canal is localized near a water gate. Each one takes two pressure measurements from a Pitot tube and is able to modify the gate position with a brushless motor. The pressure measurements are enough to process the water level and the water speed, then the water flow, in the open channel. Fig. 2 shows a usage example where the first gate is manually controlled and gives local level and speed values to the next gate that performs a flow control. The second gate gives local level and speed values to the next gate. In this example, all gates are synchronized with a “sync” signal; thus, usual control algorithms can be applied. The USOM modeling includes one configuration mode and three running modes, namely 1) the “Flow” mode for services that can be used with a flow control, 2) the “Level” mode devoted to the control of water level, and 3) the “Manual” mode when no control is needed. The state graph chosen by the instrument designer restrains the instrument in such a way that it cannot be switched back from the Manual mode to the Flow mode or to the Level mode (Fig. 3). It must first be switched to the “Configuration” mode. This constraint guards the system against instabilities that can appear when a control is switched from one algorithm to another. Available services are the “Measurement” service that gives the speed and the level of the water flow, the “FlowControl” and the “LevControl” services that perform control of flow or level, the “ManualMove” service that allows changing the gate position, and the “Diagnosis” service that performs self-diagnosis on the instrument. In the example shown in Fig. 2, the instrument on the lefthand side is in Manual mode, and the ManualMove service and the Measurement service are activated. The instrument on the right is in Flow mode and has only its FlowControl service activated. Internal services are created for pressure acquisition, flow speed and flow level computation, flow control, level control, and gate movement. Then, the eventflow is created as presented in Fig. 4 The eventflow definition includes “Rdvz” nodes, input connectors, and output connectors.

Fig. 5. Definition of the Measurement external service.

Fig. 6. Definition of the FlowControl external service.

Fig. 7. Definition of the ManualMove external service.

In the example, five services are defined as shown in Fig. 3. The Measurement service, the FlowControl service, and the ManualMove service are presented in Figs. 5–7. With respect to the constraints, the FlowControl service and the ManualMove service cannot lead to the same USOM. The graphs included in Manual and Flow USOMs are shown in Figs. 8 and 9. IV. S PECIFICITY OF CANopen I NSTRUMENTS As the USOM modeling defines the behavior of the instrument, it also defines the OSI layer 7, i.e., the application layer of the instruments. This means that it can be used for the design of instruments that use networks without this application layer (CAN, AS-i, Bitbus, Arcnet). However, most fieldbuses already

774


Fig. 10.

Main modes of a CANopen device. TABLE I ITEMS OF THE DICTIONARY OF A CANopen I/O DEVICE

Fig. 8. Graph belonging to Manual USOM that includes Measurement and ManualMove services.

Fig. 9. Graph belonging to Flow USOM that includes the Measurement service and the FlowControl service.

define the application layer; thus, compatibility between the USOM modeling and the OSI layer 7 of these networks must be checked. The USOM modeling and the application layer of fieldbuses both define the general behavior of the instrument. Furthermore, some application layers like CANopen and DeviceNet and application layers of Profibus and Interbus include the concept of profile also named electronic datasheet (EDS). With these protocols, any node is characterized by a profile including the functional description and the parameters of the node. Depending on the protocol, the profile is totally or partially included into the node. The CANopen protocol defines an application layer for CAN fieldbuses: It defines low-level instrument network functionalities like the identification of network variables and defines the general behavior of the instrument as below. The state of any CANopen device can be switched to either the “Pre-operational,” “Operational,” or “Stopped” mode. After resetting, the instrument starts in the Pre-operational mode. The CANopen protocol specifies that the Operational mode support parameter changes and processes data exchange, but the PreOperational mode only supports parameter changes and is used as a configuration mode (Fig. 10). The CANopen protocol specifies that any entity used for the communication process has to be defined in a table called “dictionary.” Any entity is associated with an index, a subindex,

and a list of properties like the range or the accessibility. Entities listed in the dictionary are divided into three classes. 1) Common entities such as type definitions or communication parameters are defined for any device. 2) Profile entities are defined for a kind of device, for example, the CiA DSP-401 standardized profile includes all the definitions of input/output (I/O) modules. These entities are indexed from 6000h to 9FFFh (h denotes the hexadecimal). 3) Specific entities such as manufacturer parameters are specific to the device and are specified by the manufacturer or the user of the instrument. These entities are indexed from 2000h to 5FFFh. With normal CANopen instruments, the instrument designer only defines new entries in the dictionary. In the following table, four different entries are presented. The first is a common entity and does not have to be defined by the instrument designer. The second is a specific entity. Others are defined by the CiA DSP-401 standard. The “process data” column denotes the possibility of exchanging data during a process cycle (Table I). To use a CANopen device, it is associated with an EDS that includes all information about the communication configuration and entities that can be exchanged. Any software package that needs to interact with a CANopen device can find all the information it needs in this EDS device. The software package gets the EDS from an external database or downloads it from the device dictionary. V. USOM M ODELING OF CAN OPEN I NSTRUMENTS The USOM modeling creates an application OSI layer and is quite simple to use for the design of instruments that communicate with a fieldbus that only defines the physical and the data link layers. The CANopen protocol already defines the application layer and interacts directly with the USOM modeling. The CANopen general behavior can be modeled into the USOM formalism, respecting several simple constraints. First,


Fig. 11. Example of USOM and external services of a CANopen device. Dot arrows represent implicit transitions that do not have to be defined by the designer.

the Pre-Operational mode, the Stopped mode, and the Operational mode are considered USOMs. Then, each new USOM inherits from the Operational mode in the state graph of USOMs. An exception can be made for a Configuration mode that is the Pre-Operational mode. External services can then be included into USOMs. For example, the design of a CANopen instrument in accordance with the design shown in Fig. 3 includes new USOMs that are the Flow mode, the Manual mode, and the Level mode. As shown before, these are substitutes for the Operational mode, and the Configuration mode replaces the Pre-Operational mode (Fig. 11). At this stage, the user specification level is completed. The instrument designer level includes the definition of external services. The adaptation to the general USOM modeling can be made by defining generic internal services that deal with the exchange of values and parameters through the CANopen protocol. The EDS is used to specify the link of the instrument modeling and the network. Network variables that represent event connectors and USOM switching are defined. Process variables are created at the programmer level. Finally, the application is built like a common CANopen application. The main difference is that modes and activated services have to be specified. In the example (Fig. 2), the first instrument is in the Manual mode and has its ManualMove service and Measurement service activated. The other instrument is in the Flow mode and has only its FlowControl service activated. Events “sync” and “move” come from other instruments or from a supervisor. VI. A UTOMATIC G ENERATION OF THE I NSTRUMENT S OFTWARE To simplify the instrument designer’s job, a tool that generates the intelligent instrument software was developed. The tool also performs verifications on USOM state graphs and external service constraints. The designer only has to create the model of the instrument. He defines all the services and translates this model into a source code written with the CAP language developed in our laboratory. The CAPtool, including a CAP compiler, first performs a model checking to verify the consistency of the design. It checks the structure of the graphs that

775

model the application. Then, it generates a description of the instrument into a well-known language. The language chosen is Extensible Markup Language (XML) [15]. Indeed, the XML approach is based on the separation between the information and its representation and is now being applied to the intelligent instrument field [16]. In the instrument design context, the XML file of an instrument includes the instrument behavior defined with the internal model and the external model. The software of the instrument, its profile, and its documentation can then be considered as representations of the instrument. Then, several stylesheets, i.e., Extensible Stylesheet Language (XSL) files, are applied on the XML information file of the instrument to generate a source code, an EDS, and an Hypertext Markup Language (HTML) documentation. Each stylesheet defines a representation style that is applied to the XML file to produce the desired documents. The XSL files created to generate the source code depend on the target processor, the target fieldbus, and the source-code language. The C language is preferred as source-code language because instruments have limited memory (typically less than 32 KB), and development tools associated with the instrument microprocessor commonly use only C language. Some recent microcontrollers include a Java Virtual Machine (JVM) and use the bytecode as the assembling language. They are then able to process applications written in java language. To produce java source codes, a set of XSL files dedicated to the generation of java source codes from the XML representation is defined. The goal of the CANopen instrument design process is to create the instrument software and the EDS. The software can be divided into a fixed part and a dedicated part. In the fixed part, common functionalities like reacting to a switch mode request, or exchanging common entity values can be found. These functionalities are implemented into a generic kernel, which is itself included in any CANopen device software. The generic kernel used in our studies was created by Crouzet Automatismes and cannot be disclosed in detail. It includes the definition of the internal service sequencing technique derived from the IEC 1131.3 sequencing, the meeting node behavior, and the CANopen communications. The dedicated part comes from the source code generated by CAPtool. Internal services are small items of software like parameter writing, or filtering, or process data communication. These services are currently written with the C language by a software designer. All services relative to the device communication are written by CAPtool dedicated to the source code generation from an USOM model [11] (see Fig. 12). The designer defines the link between the name of the service and the name of the entity into the dictionary. Internal services “acquirePressure1,” “acquirePressure2,” “computeSpeedandLevel,” “speedControl,” “levelControl,” and “MoveGate” are written by the software designer. External service definitions are not specific to the CANopen instrument design and are performed in the same way as for other kinds of instruments [13]. VII. C ONCLUSION This paper proposes an original modeling technique that makes a clear separation between the user specifications, the

776


Fig. 12. Automatic generation of EDS and instrument software.

instrument designer definitions, and the software designer activities. The originality of the technique comes from the type of constraints imposed to the sensor designer. With this technique, the designer creates instrument services by defining a subgraph of an existing graph. This makes the design of intelligent sensor networks simpler. Constraints arising from the nature of this model improve the quality of the design and are a first step to the design that guarantees the functional safety of the instruments. The other advantage is the automatic generation of the source code of the instrument software from the USOM modeling of the instrument. This approach allows a quick change of the instrument behavior. It is then easy to adapt a product to a specific use. Furthermore, the automatic generation also checks the consistency of the behavior defined by the instrument designer. Studies associated with this paper are now based on the software architecture definition of intelligent instruments. This paper illustrates that CANopen protocol constraints can be introduced into an USOM instrument modeling. CANopen is not the only protocol than can be used to apply this modeling, and the USOM modeling is versatile enough to be applied to many protocols. R EFERENCES [1] G. Bloch, C. Eugene, M. Robert, and C. Humbert, “Measurement evolution: From sensors to information producer,” in Proc. IMEKO TC1 TC7, London, U.K., Sep. 8–10, 1993, pp. 335–341. [2] J. M. Riviere, M. Bayart, J. M. Thiriet, A. Bouras, and M. Robert, “Intelligent instruments: Some modelling approaches,” Meas. Control, vol. 29, pp. 179–186, Jul./Aug. 1996. [3] Q. Yang and C. Butler, “An object-oriented model of measurement systems,” in Proc. IEEE/IMTC, Ottawa, ON, Canada, May 19–21, 1997, vol. 1, pp. 690–693.

[4] H. J. W. Spoelder, A. H. Ullings, and F. C. A. Groen, “Virtual instrumentation: A survey of standards and their interrelation,” in Proc. IEEE/IMTC, Ottawa, ON, Canada, May 19–21, 1997, vol. 1, pp. 676–681. [5] S. X. Liang, L. Zhang, and Luqi, “Automatic prototype generating via optimized object model,” ACM Ada Lett., vol. XXIII, no. 2, pp. 22–31, Jun. 2003. [6] M. Staroswiecki and M. Bayart, “Models and languages for the interoperability of smart instruments,” Automatica, vol. 32, no. 6, pp. 859–873, 1996. [7] A. Bouras and M. Staroswiecki, “How can intelligent instruments interoperate in an application framework? A mechanism for taking into account operating constraints,” in Proc. Int. Conf. SICICA, Annecy, France, Jun. 9–11, 1997, pp. 425–432. [8] E. Benoit, L. Foulloy, and J. Tailland, “InOMs model: A service based approach to intelligent instruments design,” in Proc. 5th World Conf. SCI, Orlando, FL, Jul. 2001, vol. XVI, pp. 160–164. [9] D. Georges, E. Benoit, A. Chovin, D. Koenig, B. Marx, and G. Mauris, “Distributed instruments for control and diagnosis applied to a water distribution system,” in Proc. IEEE IMTC, Anchorage, AK, May 2002, pp. 565–570. [10] J. Tailland, L. Foulloy, and E. Benoit, “Automatic generation of intelligent instruments from internal model,” in Proc. 4th IFAC Int. Symp. SICICA, Buenos Aires, Argentina, Sep. 2000, pp. 337–342. [11] E. Benoit, L. Foulloy, and J. Tailland, “Automatic smart sensors generation based on InOMs,” in Proc. 16th IMEKO World Congr., Vienna, Austria, Sep. 25–28, 2000, vol. IX, pp. 335–340. [12] Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems—Part 3: Software Requirement, Int. Stand. IEC 61508-3, 1998. [13] E. Benoit, J. Tailland, L. Foulloy, and G. Mauris, “A software tool for designing intelligent sensors,” in Proc. IEEE IMTC Conf., Baltimore, MD, May 1–4, 2000, pp. 322–326. [14] D. Garlan and M. Shaw, “An introduction to software architecture,” in Advances in Software Engineering and Knowledge Engineering, vol. I, V. Ambriola and G. Tortora, Eds. River Edge, NJ: World Scientific, 1993. [15] S. Perrin, E. Benoit, and L. Foulloy, “Automatic code generation based on generic description of intelligent instrument,” presented at the IEEE Int. Conf. Systems Man Cybernetics, Hammamet, Tunisia, 2002, Paper WA2Q5. CD-Rom edition, 6p. [16] M. Wollschlaeger, C. Diedrich, and M. Thron, “Generation of rolespecific information for an enterprise integration framework using XML description,” in Proc. ETFA, Antibes, France, Oct. 2001, pp. 237–244. [17] E. Benoit, A. Chovin, L. Foulloy, A. Chatenay, and G. Mauris, “Safe design of CANopen distributed instruments,” in Proc. 18th IEEE IMTC, Budapest, Hungary, May 2001, vol. 3, pp. 1768–1772.

Eric Benoit received the M.S. degree from Ecole de Physique Magistère, Grenoble, France, in 1988 and the Ph.D. degree from the Université Joseph Fourier, Grenoble, in 1993, both in physics. In 1994, he joined the Université de Savoie, Annecy, France, and is currently an Associate Professor in the Laboratoire d’Informatique, Systèmes, Traitement de l’Information et de la Connaissance (LISTIC), involved with data fusion systems and their implementation. His main topics of interest are the scales in measurement science and the software design for distributed intelligent instruments.

André Chovin received the M.S. degree in electronics from the Societe Ingenieur Professionel Francais (IPF), Grenoble, France. He has been with Crouzet Automatismes, Valence, France, since 1979. He was involved in several important projects about smart sensors, smart actuators, and industrial fieldbuses. From 1993 to 2000, he was the Manager of Anticipation Study Team and is currently the R&D Assistant Manager of the Sensors and Actuators Business Unit.


Laurent Foulloy received the M.S. degree from Ecole Normale Supérieure de Cachan, Paris, France, in 1980 and the Ph.D. and D.Sc. degrees from the University of Paris XI, Paris, in 1982 and 1990, respectively, all in automatic control and computer science. He is a Professor of electrical engineering and the Director of Ecole Supérieure d’Ingénieurs d’Annecy, University of Savoie, Annecy, France. His research interests include intelligent components and fuzzy techniques for process control and measurements.

Alain Chatenay received the M.S. degree in computer science from École d’Ingénieurs des Technologies de l’Information et du Management (EFREI), Paris, France, in 1974, and the M.S. degree in aerospace science from the Sup’Aero Master, Toulouse, France, in 1975. He has been with Thomson and has integrated the Alsys Corporation funded by Jean David Ichbiah. Since 1997, he has been with Crouzet, which is a member of the Schneider-electric group, where he is currently a Manager. His main work interests are the fields of compiler design and safety critical embedded software.

777

Gilles Mauris received the M.S. degree in electrical engineering and applied physics from the Ecole Normale Supérieure de Cachan, Paris, France, in 1985 and the Ph.D. degree from the University of Savoie, Annecy, France, in 1992. He is currently an Associate Professor of electrical engineering at the University of Savoie. At the Laboratoire d’Informatique, Systèmes, Traitement de l’Information et de la Connaissance (LISTIC), his research interests include fuzzy logic, possibility theory for information processing in the instrumentation, and measurement area.