Skip to end of banner
Go to start of banner

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

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Current »

Q

How to deal with I&M data?

A

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:

FieldDescriptionUsage Hints
Vendor IDThe PNO Vendor ID of the associated item. E.g. the vendor of the device or the vendor of a pluggable module/submodule.This is the Vendor ID of the manufacturer of the item and not the Vendor ID of the PROFINET Protocol Vendor. Do not use the Hilscher Vendor ID.
Order IDThe order id of the associated item.Order ID as defined by the manufacturer of the item. Must be equal to any order id markings on the item itself.
Serial NumberThe serial number of the associated item.Must be an unique serial number associated with the item. Must be equal to any serial number markings on the item itself.
Hardware RevisionThe revision of the hardware of the item.Must be equal to any hardware revision markings on the item itself.
Software RevisionThe software revision of the itemThis is the software version of the whole item including the PROFINET protocol implementation and the application. This version is managed by the manufacturer of the item. It must be changed whenever a part of the software within the item (including the PROFINET protocol implementation if it is part of the item) changes. This is not the version number of the PROFINET protocol implementation. Do not use the Hilscher Version of the PROFINET protocol implementation.
Revision CounterCounts the changes of I&M1 to I&M4 objects-
Profile IDThe Profile of the item if applicable.-
Profile Specific Type
Supported I&M objectsBitmask defining which I&M objects are supported by this item.-

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".

 

Returning "Acces Denied" or "Invalid Index" is possible since Stack Version 4.2.0.16 or 3.11.0.1 using decidated packet status codes TLR_E_PNS_IF_APPL_IM_ACCESS_DENIED and TLR_E_PNS_IF_APPL_IM_INVALID_INDEX when applicatio handles I&M Read/Write Service.

 

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:

FieldSource of value
Vendor IDVendor ID in Set Configuration Service or Configuration Database. Can be overwritten by tag list if a Configuration Database is used.
Order IDOrder ID in Set Configuration Service or Configuration Database.
Serial NumberDefaults to the serial number from Security Memory / Flash device label. This is the serial number of the Hilscher communication module if applicable. It shall be changed to the serial number of the manufacturers device using the Set OEM Parameters service.
Hardware RevisionHardware revision in Set Configuration Service. If a Configuration Database is used the hardware revision from Security Memory / Flash device label is used. This is the hardware revision of the Hilscher communication module if applicable.
Software RevisionSoftware revision in Set Configuration Service. If a Configuration Database is used the PROFINET protocol implementations software revision will be used.
Revision CounterInternally stored an incremented on each change of I&M1 to I&M4.
Profile IDDefaults is '0x00' (Manufacturer specific). Can be changed toa  desired value using Set OEM Parameters service.
Profile Specific TypeDefaults is '0x05' (Generic Device). Can be changed to a desired value using Set OEM Parameters service.
Supported I&M objectsDefaults is I&M0 to I&M5. Can be changed to a desired value using Set OEM Parameters service.

 

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

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.

  • No labels