How to deal with I&M data? (Updated 2016-12-20)

How to deal with I&M data?

Overview

Identification & Maintenance (I&M) is an integral part of each PROFINET Device implementation. It provides standarized information about a device and its parts. The I&M Information is accessible through PROFINET Record Objects and is always bound to a submodule belonging to the item to be described. An item means here the PROFINET Device itself or a part of this device e.g. a plugable module for modular devices. Submodules can provide own I&M objects or share the I&M objects of other submodules. The I&M objects can be grouped into three kinds of information as described as follows.

I&M0 is a read only information which describes the associated item. The following fields are defined:

The I&M1 to I&M4 objects provide a non-volatile storage for PROFINET engineering-related information. This information is typically generated by the engineering software and stored within the objects at engineering time. The information must be stored by the device in non-volatile memory. The objects must be stored physically within the associated item. This means in particular, if a plugable module is removed from one backplane and plugged into another backplane, it must deliver the same I&M1 to I&M4 information as stored before.

Finally, the I&M5 record provides information about the PROFINET protocol implementation itself. It is quite similar to I&M0 but describes the PROFINET protocol implementation instead. Thus it is handled by the PROFINET protocol implementation itself.

Addtionally to these submodule specific I&M objects each Profinet device must support the global I&M Filter Data object, the so called "I&M0FilterData". This is an read-only object which is used to determine which submodules are associated with dedicated I&M objects.

Structure and access paths of I&M objects

The following picture illustrates the structural organization of I&M Records within a device and the access paths:

According I&M a submodule can be characterized as follows.:

• Module Representative: The submodule has own I&M data and is a representative for the module. That means the I&M information of the submodule represents the module the submodule is part of.
• Device Representative: The submodule is a representative for the device. In that case the I&M information of the submodule provides the I&M information for the device. Exactly one submodule of the device must have this property. Typicall the DAP submodule is choosen for that purpose.
• Default: The submodule only represents itself and provides at least I&M0 dataset.
• No I&M: The submodule has no own I&M dataset.

When accessing the I&M of a submodule the following order is used to choose the I&M dataset provider:

1. If the submodule provides an own I&M0 object, the I&M access will use the submodule's I&M dataset.
2. If the submodule has no own I&M0 object and the superordinate module has a module representative, the module representative's I&M dataset will be used.
3. If the submodule has no own I&M0 object and the superordinate module has no representativ the device representatives's I&M dataset will be used.

The access is restricted and validated as follows:

1. When the choosen I&M dataset provider (the submodule) does not implement the desired I&M object, the error code "Invalid Index" must be returned.
2. When a write access is performed and the I&M dataset provider (the submodule) is not directly addressed, but addressed as module or device representative, the error code "Access denied" is to be used. Writing is only allowed if the submodule is addressed directly.
3. When a write access to I&M 0 or 5 occurs the error code "Access denied" must be returned as I&M 0 and 5 are read only.

If none of the conditions above matches, the access is to be handled and shall be responded with status "Ok".

Finally, the I&M0 Filter Data object contains the information which submodules are associated with their own I&M data, which submodules represent their superodinate module and which submodule represents the whole device. This object is global and a read-only object and it is not associated with any submodule.

As a consequence of the above specifications:

• Reading I&M 0 is never responded with an error and always succeeds.
• Writing I&M 0  is always responded with error "Access Denied".
• Writing I&M 5  on any submodule is responded either with error "Access Denied" or "Invalid Index".
• Writing I&M 1 to 4 on any submodule contained in I&M0 Filter Data is responded either with "Ok" or error "Invalid Index".
• Writing I&M 1 to 4 on any submodule not contained in I&M0 Filter Data is responded either with error "Access Denied" or "Invalid Index".

Usage of I&M with Hilscher PROFINET Protocol

The PROFINET Device protocol implementation of Hilscher supports two modes of operation with I&M. For simple applications the PROFINET protocol implementation provides I&M0 to I&M5 objects within the DAP submodule. In this case the I&M is fully handled by the PROFINET protocol implementation without any interaction with the Application. If a more complex I&M structure is required, the PROFINET protocol implementation can forward I&M accesses to the Application. In this case all I&M objects must be handled by the application. The desired mode of operation is configured using the Set Configuration Service.

If the PROFINET protocol implementation is configured to handle the I&M internally, the following parameters will be used within the I&M0 object:

If the application requested to handle the I&M objects, all I&M accesses will be forwarded to the Application using the I&M Read and I&M Write service. For details on the data structures of the I&M services refer to the protocol api. The application must store the data of I&M write services permanently, so that the I&M1 to I&M4 objects and the I&M0 revision counter can be recovered after a power cycle. The I&M0 Filter data structure must be filled by the application with a list of the submodules which are associated with dedicated I&M data. Exactly one of these submodules must be characterized as device representative. Characterization as a module representative is optional and only sensible if the module has more than one submodule. The protocol stack will then internally build up to three lists out of the information provided by the application.

Note

In order to fulfill PROFINET conformance needs, any PROFINET IO device should be able to handle the I&M0, I&M1, I&M2, I&M3 and I&M0FilterData.