Profibus Data Mapping

Hello everyone,

I have a project where I am configuring a Siemens protection relay (IED, Profibus DP Slave) in a SCADA system (Zenon, Profibus DP Master), and I am having a problem to understand how the data will be addressed exactly. I came to know that GSD files must be imported to the SCADA software in order to configure the data, is this all I have to do? or some kind of configuration must be done in the IED (the slave)?

I was trying to figure this out comparing it to the Modbus protocol, where previously all I had to do was referring the IED manuals to find the Registers mapping tables and address the data in the Master device accordingly, is it the same here?

Thanks in advanced.
 
PROFIBUS and Modbus use very different data models and data exchange methods.

Modbus is an object-based, request/response protocol. For example, the master makes a request for Holding Registers 123 - 132 and the slave responds with the values for those specific registers.

PROFIBUS, on the other hand, exchanges high-speed cyclic data. Essentially, this cyclic data is one stream of bytes that is constantly sent from the master to the slave (output data) and another stream of bytes that is constantly sent from the slave to the master (input data). The data contained in these streams is predetermined by the slave (or the current configuration of the slave). The master requires the GSD file to know the size (number of bytes) in each stream. However, what data is contained in the stream (the byte or word offsets in the stream, the data type and size of each value, etc.) is entirely up to the slave and should be documented in the slave's user's manual or similar.

As an example, a PROFIBUS slave's GSD file may have a 4-byte In and 2-byte Out module. When the master uses this module and establishes communications with the slave, it will sent 2 bytes to the slave, while simultaneously, the slave will sent 4 bytes to the master. The 2 output bytes could be a 16-bit control word, while the 4 input bytes could be a 16-bit status word and two 8-bit state values, for example.

To use the PROFIBUS data in a SCADA system, you will need to tell your SCADA system how to encode and extract the data values within the PROFIBUS data streams. These data values will likely be stored in tags, or similar, in the SCADA system. Therefore, you will have to setup a mapping in your SCADA system between those tags and the specific offsets and data types in the PROFIBUS data streams.
 
Hello Jschulze, thank you for your fast reply and great answer, things got quite clearer now, I just have some other questions regarding your answer.
From my previous searches I learned that even through Profibus DP sends its data cyclically, it is still restricted to the Request/Response mechanism of the Serial interface (Master-Slave), however I do agree the data addressing is quite different from Modbus.

Secondly, after I read a couple of manuals (mostly Speed Drives), I learned that the data configuration in Profibus is about Inputs and Outputs, and the master must be configured in order to determine how many bytes/words it will need from the slave, how can I link this to the PPOs concept? I figured also that there is a bunch of Profiles could be used (like PROFIdrive and I/O profiles), is the data configuration of these profiles the same? Because honestly I noticed each vendor has its own addressing schemes and it made look like Modbus where's its vendor-specific open protocol (Profibus shouldn't be though).

Sorry if my questions seems chaotic, I'm just a little confused of some concepts of the protocol.
 
From my previous searches I learned that even through Profibus DP sends its data cyclically, it is still restricted to the Request/Response mechanism of the Serial interface (Master-Slave), however I do agree the data addressing is quite different from Modbus.
Not exactly. PROFIBUS is actually a bit more complicated than what I explained in my last post. I only explained the most commonly used data transfer method, which is the cyclic I/O data. However, in addition to cyclic I/O data transfer, PROFIBUS also supports acyclic data transfer in a request/response model. This acyclic data transfer is very similar to Modbus. But keep in mind, acyclic data transfers are infrequently used in PROFIBUS. Most applications use the cyclic I/O data streams.

There are PROFIBUS applications that use both cyclic and acyclic communications. The cyclic communications is used for always-changing process data (for example, status/command data, position, speed, etc.) and is exchanged every cycle (at high speed) between the master and slave device(s), while the acyclic communications is used for on-demand, infrequently accessed data (such as configuration parameters).

Secondly, after I read a couple of manuals (mostly Speed Drives), I learned that the data configuration in Profibus is about Inputs and Outputs, and the master must be configured in order to determine how many bytes/words it will need from the slave, how can I link this to the PPOs concept? I figured also that there is a bunch of Profiles could be used (like PROFIdrive and I/O profiles), is the data configuration of these profiles the same? Because honestly I noticed each vendor has its own addressing schemes and it made look like Modbus where's its vendor-specific open protocol (Profibus shouldn't be though).
A PROFIBUS slave device defines how its I/O data is structured and is vendor/device-specific. However, as you mentioned, there are standardized profiles, such as PROFIdrive, that dictate the structure of the I/O data that all vendors must follow exactly the same. Now, under the PROFIdrive profile itself, there are different possible structures. This is where PPO (Parameter Process data Object) types come in. The specific PPO type dictates the exact structure of the I/O data. Not all slaves that support the PROFIdrive profile support all PPO types.

Here is an excerpt from the Siemens Micromaster PROFIBUS option board manual (https://support.industry.siemens.co...master-profibus-optional-board?dti=0&lc=en-WW):

Five types of PPO are defined according to PROFIdrive Profile, version 2.0
  • User data without parameter area (PKW), with two or six words of process data (PZD) or
  • User data with parameter area (PKW), with two, six or ten words of process data (PZD).
1705588729360.png

The selection of whether vendor-specific I/O data or standardized profile data is exchanges is done from the PROFIBUS master. When configuring your PROFIBUS master, you need to load the slave's GSD file. That file contains I/O modules for all supported I/O structures. When you configure the data exchange for a particular slave from your master, you need to select the I/O module(s) that you want to use. If you select a vendor-specific I/O module, the slave will use the vendor-specific I/O data structure. If you select a PROFIdrive module, the slave will use the standardized PROFIdrive I/O structure.
 
Thank you for taking effort and answering my questions this deep, I really appreciate it.

I took some time to dive into it more specially in the Protection Relay (Slave) I'm working with. I even found another file I didn't come across earlier which was a Mapping file (similar to the Modbus Register tables). Here is a an example of it:

1706555784083.png

Where 14/6 are the 14th Byte, 7th and 8th (last bit) respectively. using such tables made it clear how the slave data allocated (it was already allocated). So all I have to is to repeat such mapping in the Master using the GSD file and there tables I presume.

I also made this table from what I understood till now and I wanted to make sure if it is almost correct:

1706556006364.png

I worked earlier with the first 2 protocols, and these are the definite parameters in the same manner that was always needed to address a specific data (SP, DP or Measurement). The PROFIBUS DP I believe only asks for the Byte and Bit offset (if the Whole Byte is used then the Bit offset is not needed). In case of the PROFIdrive however you address a specific Bit BUT in a certain Word (not Byte), but it is similar I think.

Thank you very much Mr. Jschulze for the valuable information.
 
Top