A long time ago
In the 90’s, I worked as sysadmin in a small automation supplies distribution company, how I got that job is an interesting story but I’ll reserve it for another time.
Back then, broadband Internet access was a corporate luxury, and both cable modem and ADSL services were scarce and really expensive. In fact, those services were not yet available in the area where this company was located.
So, believe it or not, I had to offer Internet access to the company’s networked PCs by a shared dial-up connection. From today’s perspective it surely sounds like a nightmare, but in those times the web was far from being as rich in media content as today. For stuff like e-mail service and web browsing, it was tolerable.
In order to share the Internet connection among the company’s PCs, I employed a nice piece of software called Wingate, which had a list price of some hundred USD and allowed me to share Internet access by working as a proxy server. Surprisingly, this software is still available in newer versions and, due to the wonders of Internet marketing, now is free for up to 10 users. Go figure…
An additional problem to 56 Kbps shared Internet access was the fact that our ISP also employed a proxy server. This arrangement was commonplace in those times because proxy servers can also work as cache servers, improving transfer data performance if the information remains unchanged. Web pages were significantly more static in that era, so a cache server was a real life benefit.
This network configuration, featuring two proxy servers working one behind the other, is called “cascading proxy servers” and back then it was very difficult to configure to allow access to some Internet services.
Life was not easy for sysadmins in those years, but for sure it was challenging.
Some background information
A brief explanatory pause for the non-geeks: a proxy server is a software or hardware that makes it possible for all the LAN network nodes (like a corporate network) behind it to access simultaneously to WAN resources (like the Internet) through a single LAN/WAN connection. Using a proxy, from the WAN side it seems that only one node is accessing the WAN resources. From the LAN side, it seems like each node has direct access to the WAN resources.
Eventually both cable modem and ADSL services became available in the area and then I ditched the proxy server and acquired a dual redundant connection broadband Cisco router with load balancing that really rocked. And the proxy story came to an end, or at least I thought so.
Revenge of the proxies
Back to present days, a couple of weeks ago I was analyzing the available information about the four existing alternatives for the integration of Profibus PA devices into Profinet networks.
I’ve always wondered why the main player in the Profinet market, Siemens, is happy with its current solution for this issue: they use a device called a IE/PB Link and a DP/PA Link in cascade, with the IE/PB Link acting like a Profinet IO device and the DP/PA Link as a segment coupler. This solution works OK, but in my point of view it still raises some questions, like the datagram size limit of the DP/PA link (244 bytes) and the problems of integrating such a solution in non-Siemens based control system architectures.
After reading the paper published in 2015 by Zhijia Yang, Zhongsheng Li, Feng Qiao and Minghui Min, all of them members of the Shenyang Institute of Automation, Chinese Academy of Sciences titled as “Research of PROFIBUS PA’s integration in PROFINET IO”, I became curious enough to get into the “Fieldbus integration in PROFINET IO Guideline”.
In the Chinese paper the researchers figured out that their best approach to solve the problem would be to use a device that would act as a virtual Profinet IO Device in its Profinet side and as a virtual Profibus Master in its Profibus side, which would poll the PA devices and enable them to exchange data with the Profinet IO controller.
This is the functional description of a proxy.
Getting deep into the problem
So this document left me craving for more details and with some degree of nostalgia. Then I started to look for more info.
Enter the “Fieldbus integration in PROFINET IO Guideline”. This really interesting document explains in detail the intricacies of how a Fieldbus to Profinet IO proxy device should work and describes how any Fieldbus protocol included in the IEC 61158 standard can be integrated into a Profinet network.
The first question that appears is why would you want to integrate other fieldbuses into Profinet?
Of course there are economic reasons for this, such as protection of existing investments, but the main reason is flexibility:
Even though there is an increasing number and variety of Profinet devices available in the market, certain application fields remain that cannot be solved with Profinet IO technology alone.
Profinet in Process Automation
The field that is my main interest (Process Automation) has been approached by two protocols featured in the IEC 61158 standard: Foundation Fieldbus H1 and Profibus PA.
I will focus on the integration of Profibus PA into Profinet in order to remain concise, but the concepts are valid for any other IEC 61158 fieldbus protocol.
Profinet’s physical layer is defined by the IEEE 802.3 standard. This standard describes the physical layer and the data link layer of what is usually known as wired Ethernet.
Since even the most energy efficient Ethernet drivers consume at least 250 mW and Profinet IO devices require at least two Ethernet ports, the minimum power requirement for a Profinet IO device is about 500 mW. That power consumption level is excessive for most field devices.
Typical Profibus PA device’s power consumption is something about 250/300 mW and even less (around 150 mW) in intrinsically safe applications. Also 802.3 Ethernet does not provide power, so additional cabling would be necessary.
Cable length is another issue: Ethernet supports 100 m, after that you’ll need a switch or hub which will require power, meanwhile Profibus PA MBP technology can reach up to a distance of 1900 m.
Finally, there are no standard intrinsically safe Profinet specifications available.
There are other considerations, but you get the idea: Process Plant field devices are not well suited for an Ethernet approach, at least for the medium term.
Profinet based control systems
A Profinet control system usually features the following components:
- A Profinet IO controller, which is the Profinet equivalent of a Class 1 Profibus Master.
- A Profinet IO supervisor, the equivalent of a Class 2 Profibus Master.
- Profinet I/O devices, equivalent to Profibus DP slaves.
Profinet IO devices are integrated into the IO controller by means of a GSDML file. This file acts as a device descriptor and provides to the controller the configuration and parametrization characteristics featured by the corresponding IO device.
A fieldbus enabled Profinet system would feature the same components with the addition of a fieldbus linking device. This device is responsible for the data mapping between the fieldbus protocol and Profinet. Linking devices may be compact (fixed amount of fieldbus lines or segments) or modular (variable number of fieldbus lines, to be defined by the user).
Profibus PA employs GSD files as device descriptors, Profinet employs GSDML files for the same purpose. So the features and properties described in the GSD PA file must be integrated into the GSDML file of the linking device, which in fact would behave like a Profinet IO device.
The GSDML creation process is done by a software tool supplied by the linking device supplier and there lies one of the strengths of Profinet: it offers the possibility of integrating any kind of DD into a GSDML. This tool is called the GSD composer.
Mapping into the Profinet world
The mapping process of the PA devices functions into a Profinet GSDML file requires that all PA devices and their available functions should be declared correspondingly as slots and subslots of the Profinet IO linking device.
In order to enable the use of modular linking devices a feature called the slot cluster is employed. This feature basically reserves Profinet address spaces for additional linking device modules. To identify this clusters, a special kind of subslot called FAP (Fieldbus Access Point) is defined. Each FAP could correspond to a different kind of linking device or to several linking devices supporting the same protocol.
The slot cluster concept can be also employed for compact linking devices with support of more than one fieldbus line.
So the most important aspect of fieldbus integration into Profinet is mapping.
Four ways to get there
There are four methods to accomplish this mapping:
- Compact mapping: In which a whole fieldbus system is mapped to a single Profinet IO device. This device stores the fieldbus configuration in a non-volatile memory available in the linking device.
- Transparent mapping: each fieldbus device is mapped to a logical Profinet IO device, with the linking device working as a Profinet IO device by itself.
- Modular mapping: each fieldbus device is mapped to a module/submodule in a Profinet IO device. This method requires the use of a GSDML composer.
- Device Slave Coupler: by this method, each fieldbus device is mapped to a single Profinet IO device. This means one coupler for each fieldbus node so it is device specific.
Real life Profinet proxies
If you are still reading this post at this time you deserve something:
Like a real life example.
A compact linking device with compact mapping would be something like the Softing proxy, which supports up to two Profibus PA segments and that configuration can’t be modified by the end user. Currently available info states that it supports up to 32 PA devices, 16 per segment. This arrangement offers the best performance since I most applications all the fieldbus subsystem data could be transferred to the controller in one Profinet IO frame.
A transparent linking device with transparent mapping would be the Siemens IE/PB Link. This method is not yet supported by the GSDML 2.0 specification. To access the PA devices, a DP/PA Link is required which will be seen as a Profinet IO device from the IO controller. The 244 bytes long datagram size limitation for DP nodes limits the number of PA devices that can be connected per DP/PA Link. This translates into not as good performance since the Profinet frame size would not be fully employed.
Modular linking devices with modular mapping examples are P+F’s Profinet Power Hub and Ifak System’s modular ISNet family of gateways.
This method requires a GSDML composer. Since in Profinet IO, after parameterized, each device can handle data exchange by itself and can provide data both cyclically (for Io controllers) and acyclically (for IO supervisors, the datagram size can reach up to 1500 bytes (Ethernet dataframe), so if the fieldbus subsystem data size is large, it has to be transmitted through more than one Profinet frame, so its peeformance would be
You can have support for 244 bytes per PA device and 46 devices per segment in the P+F proxy. But due to PA topology limitations 24 PA devices per segment (96 PA devices per 4 channel’s proxy) would be a real life limitation.
The Ifak proxy offers modules with 1, 2 or 4 channels. Each channel can handle up to 31 PA devices, but the Profibus address limit is 126. Up to 5 modules can be added to the proxy, so the number of devices could reach more than 500. That would be more than what typical controllers can handle. Again, the same PA topology restrictions apply, so 24 PA devices per segment (channel) or 96 devices per module would be the real life limit.
Device Slave couplers examples are something like the Anybus Communicator Profinet devices.
Conclusions?
These are preliminary conclusions that are based on the devices manuals and available standards. For sure there may be omissions or mistakes, but the idea of this post is to start a discussion rather than to be a reference document. Profinet proxies became available in late 2015, so there is a long road ahead until they become commonplace.
If you think this material is interesting, please post your comments. If you discover mistakes or omissions, please let me know in order to make the corrections. And if you have already used these devices in real life projects, I’d like to know about your experiences.
And I’d really like to know if somebody is still using that Wingate software.
Mirko Torrez Contreras is a freelance Process Automation consultant who had the luck to play with stuff like Mosaic and Netscape web browsers, had to use a nullsock.dll in order to use these browsersin offline mode in his DIY AMD 386 PC, had to deal with coaxial cable 10base2 and 10base5 networks and joyfully switched from hubs to switches in the 90’s. He is currently enjoying Gigabyte Ethernet networking in his home office network and has not used a proxy server in the last 10 years..