Safe design of CANopen distributed Instruments

IEEE Instrumentation and Measurement Technology Conference Budapest, May 21-23, 2001.

Safe design of CANopen distributed Instruments Eric Benoit(1), André Chovin(2), Laurent Foulloy(1), Alain Chatenay(2), Gilles Mauris(1) (1)

Laboratoire d’Automatique et de MicroInformatique Industrielle, LAMII-CESALP, Université de Savoie 41 Avenue de la Plaine, BP 806, F-74016 Annecy cedex, France Phone: +33 450.09.65.44, Fax: +33 450.09.65.59, E-mail: [email protected], WWW: http://ava.univ-savoie.fr/ (2)

CROUZET Automatismes 2 rue du Docteur Abel, BP59, F-26902 VALENCE Cedex 09, FRANCE Phone: +33 475.44.86.09, Fax: +33 475.55.98.03, E-mail: [email protected]

Abstract - This paper presents a modeling for safe design of intelligent instruments distributed on a CANopen fieldbus. This paper shortly recalls the service-based USOM/INOM modelling technique, then shows how this technique can be apply to a safe design of CANopen distributed instruments. An example of design of an instrument which is compatible with the CiA DSP-401 standardized profile of I/O modules is used to ilustrate these concepts.

II. PRELIMINARIES The approach discussed in [3] was proposed to model existing instruments from the external point of view. In particular, the external model of the instrument can be used to build a global model for an application dealing with several instruments. In this paper, we present an approach that define the internal functional model of a sensor [7][8][9]. This approach divides smart instrument design into 3 levels:

I. INTRODUCTION Since the eighties the concept of intelligent instruments (i.e. smarts sensors or smarts actuators) communicating over a field bus network, in order to drive an industrial process, has been developed. At the beginning, intelligent instruments were only defined by their hardware. And then, it appears that it was necessary to define a functional description of intelligent instruments. Last works propose models based on a set of functionalities organized with a general behavioural description, i.e automation graph or object model [1][2][5][6]. The internal modelling of intelligent instruments is not sufficient for the conception of large applications. Obviously, intelligent instruments need to interoperate. Therefore an external model of intelligent instrument is needed. In [3] and [4], Staroswiecki proposes to model a sensor by a set of services. Services are organized into subsets called "USer Operating Modes". In this model, a sensor service can be requested, and so executed, only if the current active User Operating Mode (USOM) includes this service. This prevents the request of services when they can not be available. .

-

the instrument user specification level based on the external instrument model,

-

the instrument designer level based on the internal instrument model,

-

and the software designer level where atomic pieces of software are created.

Using an internal model and an external model increase the safety of the instrument design and the instrument use. The separation between the designer action and the software designer work allows to quickly adapt a product to a specific kind of user. Indeed, the software designer create basic algorithms and pieces of software dealing with the instrument hardware, and the instrument designer just have to create the instrument behaviour in order to respond to the user needs. We also show that different levels of CANopen protocol can be represented into these 3 levels of the instrument modelling. Finally, this kind of modelling is used to simplify and to secure the sensor design by the way of an automatic generation of the sensor software and the testing software.

III. RESULTS A. External and internal models The external instrument model is based on USer Operating Modes (USOM). In this model, instruments functionalities are considered as services, and instrument’s states called USOM are defined as subsets of instruments services. in [4] Bouras had defined USOMs with 4 principles: A USOM is a subset of the set ES of services provided by the intelligent sensor.

u ∈ U ⇒ u ∈ {x, x ⊆ ES}

(1)

A USOM includes at least one service.

∀( u ∈ U ) ,u ≠ ∅

We consider now an internal point of view of the instrument. Preceding services are then called external services. New services, called internal services, are defined. These internal services are invisible by the user, and they can only be requested by an other service of this sensor. They are including algorithms like filtering, signal processing or are dealing with the hardware of the instrument such as transducers or fieldbus. The instrument designer have to use these internal services in order to create external services. Internal services are created by a software designer with the C language. The definition of any external service is performed by the definition of a sequence of internal services. This modelling separates the instrument designer work and the software designer work. The instrument designer defines the instrument behaviour and the software designer defines basic instrument functionalities. The first one do not need to know a specific computing language.

(2)

Each service belongs to at least one user operating mode.

∀( s ∈ ES ) ,∃( u ∈ U ) ,s ∈ u

(3)

A service can be requested only if the current USOM owns this service. This approach protects the instrument against a wrong use of its services. It improves the safety of the use of the instrument. We can consider that the creation of the USOM model of an instrument is the user specification of this instrument. Indeed, the user defines all services he wants the instrument owns. He defines also all possible states (USOM) of the instrument, and associates any service to one or more USOM. In order to improve safety, constraints about modes switching are applied throw a state graph of USOMs. For example, with a sensor with 2 analog inputs, the state graph can imposes that the instrument cannot be switched form a Absolute mode to a differential mode if not first switched to a configuration mode.

The sequencement of internal services is represented by the definition of admited activation event of each internal service. Events used for the sequencement are events like end of service computeDifInput (see Fig. 2.). External services are then defined by the set of internal services they use, and by the definition of new activation events like start of the external service (see Fig. 3.).

acquireInput1

exportInput1

acquireInput2

computeDifInput

event end of internal service

exportInput2

exportDifInput

Fig. 2. Internal services and their activation events

getEntry1

getEntry2

acquireInput1

acquireInput2

acquireInput1

exportInput1

exportInput1

acquireInput2

getEntry

configuration diagnostic

computeDifInput event start of external service absolute

differential

getEntry1

getEntry

getEntry2

Fig. 1. USOMS state graph and services

exportDifInput

Fig. 3. External services definition

Let us consider an adaptation of USOM approach to an internal point of view, and let us define INternal Operating Modes (INOMs) as subsets of internal services respecting the 4 following principles:

-

A INOM is a subset of the set IS of the instrument internal services.

i ∈ I ⇒ i ∈ {x, x ⊆ IS} -

Pre-Operational

Stopped

(5) Operational

Each internal service belongs to at least one INOM.

∀( s ∈ IS ) ,∃( i ∈ I ) ,s ∈ i -

(4)

A INOM includes at least one internal service.

∀( i ∈ I ) ,i ≠ ∅ -

Operational mode support both parameter changes and data process exchange, but Pre-Operational mode only support parameter changes and is used as a configuration mode.

(6)

An internal service can be requested only if the current INOM owns this service

Considering theses constraints, an INOM is in fact an internal state of the instrument. Theses internal states influence the availability of internal services. They are not visible by the user. For example, usual INOMs can be “nominal” state, “degraded” state, and “critical” state. In order to simplify the job of the instrument designer, we have developed a tool which generates the software which will run on the intelligent instrument, and which generates also a graphic interface for the test of this sensor. The tool also performs verifications on USOM and INOM state graphs, and on internal service time execution. The designer only has to create the INOM’s model of the instrument, to define all services and to translate this model into a source code written with the CAP language developed in our laboratory. After the download of the software into the intelligent instrument, the designer can test it with the graphic interface. It can send external events or variables and receive variables exported by the sensor. B. CANopen instruments The CANopen protocol defines the application layer of a CAN fieldbus. It defines low level instrument network functionalities like the identification of networked variables for example. It defines also the general behaviour of the instrument. The adaptation to the general USOM/INOM modelling can be made by defining generic internal services that deals with the exchange of values and parameters throw the CANopen protocol. The CANopen specific general behaviour can be modeled into the INOM formalism. The state of any CANopen device can be switched to one of Pre-operational, Operational or Stopped mode. After reset, the instrument starts in the “Preoperational” mode. The CANopen protocol specifies that

Fig. 4. basic USOMs of a CANopen device

The CANopen protocol specifies that any entity used for the communication process has to be defined into a table called dictionnary. Any entity is associated to an index and a list of properties like the range or the accessibility. Entities registered into the dictionnary are arranged into 3 classes. -

Common entities, such type definition or communication parameter, are defined for any device.

-

Profile entities are defined for a kind of device, for example the CiA DSP-401 standardized profile includes all definitions of I/O modules. These entities has indexes from 6000h to 9FFFh.

-

Specific entities such a manufacturer parameter, are specific to a device and are specified by the manufacturer or the user of the instrument. These entities has indexes from 2000h to 5FFFh.

The instrument designer only has to define new entries into the dictionnary. In the folowing table 4 differents entries are presented. The first one is a common entity and do not has to be defined by the instrument designer. Others are used for the communication of one parameter i.e. the offset, and 2 data process. The instrument designer has to chose a name for theses internal services TABLE I PIECE OF DICTIONNARY OF A CANOPEN I/O DEVICE Name

Index/ Access subindex

Communication cycle period 1006/0 Read Dif. An. Input 8 bits

read/write

Range

data process

Unsigned32 no

2200/0

read/only

Unsigned8

yes

Read Analogue Input 8 bits 1 6400/1

read only

Unsigned8

yes

Read Analogue Input 8 bits 2 6410/2

read only

Unsigned8

yes

C. Design of CANopen instruments

In order to simplify the instrument design, all common functionnalities i.e. communication, startup are included into a kernel, and do not have to be design again. New USOMs are supposed to have the same beaviour than the Operational one. New external services can then be included into existing USOMs or new ones. For example, the design of a CANopen instrument which respect the design shown in Fig. 1. includes new USOMs Absolute and Differential in replacement of Operationa. The Pre-Operational mode is considered as a configuration mode.

Pre-Operational

Stopped

internal services and INOMs definitions

CAP source code

CAP compiler Electronic datasheet C files Intelligent Instrument Generator

EDS

kernel

The aim of CANopen instrument design process is to create the instrument software and the electronic datasheet. The software can bu cut into a fixed part and a dedicated part. The fixed part

Intelligent Instrument

PC supervisor

diagnostic

data process

CANopen

service request, data process Absolute

Differential

getEntry1

getEntry

getEntry2

Fig. 5. Example of USOM and external services of a CANopen device

At this step, the user specification level is completed. The instrument designer level includes the INOMs definition, and the external services definition. External services are defined with internal services. Internal services are small piece of software like parameter writing or filtering or data process communication. Theses services can be writen with the C language by a software designer. All services relative to the communication are writen by a tool (CAPtool) dedicated to the generation of source code from a USOM/INOM model [9] (see Fig. 6.).

Fig. 6. Automatic generation of EDS and instrument sofware

IV. NOVELTIES The first advantage of the proposed technique is to make a clear separation between the user specifications, the instrument designer definitions, and the creation of basic software functions, inside the modelling considered in order to simplify the design of intelligent sensor networks. Constraints applied by the nature of this model during the design improve the safety of the design and of the use of the instrument in a network. The other advantage is the automatic generation of the source code of the instrument software from the USOM/INOM modelling of the instrument. This approach allows to quickly change the behaviour of an instrument, and then to easily adapt a product to a specific use. Furthermore, the automatic generation also verifies the coherence of the behaviour defined by the instrument designer. The CANopen is not the only protocol than can be used to apply this modelling technique, but the USOM/INOM modelling is sufficiently general for an application to many protocols.

REFERENCES [1]

Bloch G., Eugene C., Robert M., Humbert C., Measurement Evolution: from Sensors to Information Producer, Proc. of IMEKO TC1 TC7, (September 8-10, 1993) London, UK, pp 335-341.

[2]

J.M. Riviere, M. Bayart, J.M. Thiriet, A. Bouras, M. Robert, Intelligent instruments: some modelling approaches, Measurement and Control, (July-August 1996) Vol.29, pp.179-186.

[3]

M. Staroswiecki, M. Bayart, Models and Languages for the Interoperability of Smart Instruments, Automatica (1996), Vol. 32, n° 6, pp. 859873, .

[4]

A. Bouras, M. Staroswiecki, How can Intelligent Instruments Interoperate in an Application Framework ? A Mechanism for Taking into Account Operating Constraints, Proc. of Int. Conf. SICICA’97 (9-11 juin 1997) Annecy, France.

[5]

Q. Yang, C. Butler, “An Object-Oriented Model of Measurement Systems”, IEEE/IMTC Instrumentation and Measurement Technology Conference, Ottawa, Canada, May 19-21, 1997, vol.1, p.690-693.

[6]

H.J.W. Spoelder, A.H. Ullings, F.C.A. Groen, “Virtual Instrumentation: A survey of Standards and their Interrelation”, IEEE/IMTC Instrumentation and Measurement Technology Conference, Ottawa, Canada, May 19-21, 1997, vol. 1, pp. 676-681.

[7]

Tailland J., Foulloy L., Benoit E., “Automatic Generation of Intelligent Instruments from Internal Model”, Proc. of 4th IFAC Int.Symp. SICICA’2000, Buenos Aires, Argentina, Sept. 2000, pp 337-342.

[8]

Benoit E., Tailland J., Foulloy L., Mauris G., “A software tool for designing intelligent sensors”, Proc of the IEEE Instrumentation & Measurement technology IMTC/2000 Conference, Baltimore, Marynland, USA, may 1-4 2000, pp. 322-326.

[9]

Benoit E. , Foulloy L., Tailland J. “Automatic Smart Sensors Generation Based on InOMs”, Proc. of the 16th IMEKO World Congress. Vienna, Austria, Sept. 25-28 2000. Vol IX, pp. 335-340.

ACKNOWLEDGEMENT This study is part of the SYCADI french program supported by “Région Rhone-Alpes” .