An Open Implementation of Profibus DP

TRAN Duy Khanh, Pavel PISA, Petr SMOLIKCzech Technical University in Prague, Faculty of Electrical Engineering

Department of Control EngineeringKarlovo namesti 13, 121 35, Praha 2

info@pbmaster.orghttp://www.pbmaster.org

Abstract

This paper presents a project named PBMaster, which provides an open implementation of theProfibus DP (Process Field Bus Decentralized Peripherals). The project implements a software imple-

mentation of this very popular fieldbus used in factory automation. Most Profibus solutions, especiallythose implementing the master station, are based on ASICs, which require bespoke hardware to be builtsolely for the purpose of Profibus from the outset. Conversely, this software implementation can run ona wide range of hardware, where the UART and RS-485 standards are present.

1 Motivation

Profibus is a fieldbus that can be used both inproduction automation and process automation andwhich has become a global market leader. World-wide, over 28 million Profibus devices were in-stalled by the end of 2008.

Although the Profibus was initially standard-ized in the late 1980s it is not easy to find mate-rials to help design and system engineers developnew products. Despite many interesting featureslike deterministic media access or fast data exchange,Profibus still seems to be only in the domain of pro-fessional applications and commercial solutions. Themain reason is probably due to the high price of allProfibus products, whether hardware or software so-lutions.

Commercial solutions commonly need specialhardware, and the software is mostly proprietary- which also significantly increases the price ofProfibus applications. In addition, the primary sup-ported platform for these solutions is the operatingsystem MS Windows. Support for Unix-like systemsis very low.

2 PBMaster project

Into this marketplace, PBMaster [1] comes with itssolution within the field of this popular industrialbus. The project is still under extensive develop-ment, but aims to offer a cheap solution that willmake it possible to use Profibus not only in commer-cial applications, but also in universities, homes orsemi-professional applications. The key to achievingthese objectives is in using common inexpensivehardware and open source software.

Initially, the project aimed to offer a solutionfor connecting common personal computers runningLinux to this industrial bus. Now, it runs onseveral operating systems (Linux, FreeBSD andNetBSD) and sys-less embedded hardware based onthe ARM architecture. The objectives are to offermulti-platform drivers, libraries and applications ca-pable of carrying out the master, slave and analyzerfunctions of the Profibus. In the future the projectwill try to offer a complex and inexpensive softwarebased solution for applications using Profibus.

The following picture describes the softwarestructure of the PBMaster project. We will take acloser look at each component later in this paper.

FIGURE 1: Software structure

3 Open source vs. Profibus

patents

The project was established to offer an open imple-mentation with all the components to be releasedunder the GNU GPL v.2 or a later version. Earlierthis year distribution of the source code wasbeen suspended due to patent problems prevent-ing the distribution of the implementation under anopen-source license. The patents appeared this yeareven though they were applied in 1992. Two of thethree patents related to the Profibus implementa-tion affect the FDL master implementation withinthe PBMaster project.

Despite very positive feedback from the Profibusexperts after the presentation of the project atthe Profibus Conference in Krakow in July 2009,the PI (Profibus International organization) andpatent holders declared they did not want to supportthe community and repeated that Profibus is an“open” but not “open-source” standard. ThePI grants rights for using the patents to Profibusmembers. This means the PI members can usePBMaster’s implementation. The situation unfortu-nately does not allow distribution of the master im-plementation, which covers a significant part of theproject, in the community until the patents are valid.

4 Hardware System Structure

As mentioned before, implementing the standard bysoftware makes it possible to run on a wide rangeof hardware including that which was not designed

for the purpose of Profibus. It is also one of themeans by which the solution can be made inexpen-sive. The software implementation can run on hard-ware integrating UART (Universal AsynchronousReceiver/Transceiver) circuits with RS-485 output,the physical standard used by Profibus DP. The cur-rent version supports three types of hardware. Wewill discuss them in the following sections.

4.1 RS-232/RS-485 Converter

The converter offers an economic solution in order toconnect a PC to a Profibus network. The essentialrequirement is for the connected PC to have a serialport, which could be a problem as modern computerslack this communication port. The electric level ofRS-232, generated by the common PC, is convertedusing this dongle to RS-485, used by Profibus DP.The dongle is powered directly from the serial portof the PC. It is the reason why the converter is verysmall with very few components integrated. The lackof external power supply limits use of the dongle invery extensive networks with long cabling; further-more, it’s not possible to use cable termination andthe number of nodes on the network is limited toaround 10 nodes.

A highest attainable Profibus speed of19200 bit/s is another limit of this converter. Thelimitation is caused by differences in speeds sup-ported by RS-232 of the personal computer and thespeeds supported by Profibus DP. This convertercan be run in mode Master and Analyzers. It is avery low cost solution. All schematic and assemblymaterials are available in the project’s repository.

FIGURE 2: RS-232/RS-485 Converter

4.2 PCI based cards

In order to achieve higher speeds it is necessary touse some UART integrated extension cards. The cur-rent drivers support PCI based cards integrating theOX16C954 chip, probably the fastest UART inte-grated circuit with a PCI interface on the market.It is a high performance UART with 128 byte FI-FOs by Oxford Semiconductor. The IC integrates a16C550 compatible UART offering an ample FIFOsize and many other interesting features. One of themost important features is the maximal bus speedof 15 Mbit/s in normal mode and 60 Mbit/s in ex-ternal clock mode. Using this IC the drivers achievea communication speed of 12 Mbit/s, the max-imal speed of Profibus DP. The PCI card containsup to four ports. Each port can run in Master orAnalyzers mode up to 12 Mbit/s independently ofthe others. The PCI card does not allow usage inthe Bit analyzer mode at the moment as there is nobuilt-in hardware support (could be added easily).

FIGURE 3: UART Integrated PCI Card

4.3 ARM based boards

Having the option to use the Profibus drivers onan embedded system is especially interesting. Thisoption makes connecting to the Profibus networkeasy, cheap and removes the need for big hardwaresupport. Reading sensors and controlling actuatorswould be very easy and available for common appli-cations like home automation, robot controlling oreven control of a production line. The embeddedsystem offers a lot of options for creating a bridgebetween different standards, as the micro-controllersusually offer many types of interfaces.

The following figure shows a board integratingan LPC 2148 ARM with UART interfaces by NXPSemiconductors. The highest tested Profibus speed

was 500 kbit/s (limited by the transceiver). It isexpected to achieve a Profibus speed 1.5 Mbit/s orhigher with a faster transceiver. The software runson a target without operating system. It is a robustsolution and can be used in Master or experimentallyin Slave mode.

FIGURE 4: Embedded Board Integrating anARM LPC 2148

This very tiny module integrating ARM7 by At-mel offers many interesting interfaces like Ether-net, USB 2.0, SPI, I2C, CAN transceiver, UART+ RS-232/RS-485 transceivers etc. It runs FreeR-TOS, a highly portable real-time operating system.Profibus support for this module is under develop-ment and is expected to achieve very high speedsthanks to the DMA channel and very high speed RS-485 transceiver.

FIGURE 5: ARM7 board running FreeR-TOS

5 Device Drivers

Almost all hardware needs software to support thefunctionality it was designed for. In our case, this

takes the form of a device driver implementing low-level support called FDL (Fieldbus Data Link). Mostof the hardware supported solutions use ASICs toimplement this FDL layer. In contrast, the PB-Master solution is implemented solely by software.Along with the FDL layer the drivers cover also thelow-level part of the Profibus analyzer and UARTBit/Byte analyzers. The software structure was de-signed to be as modular as possible. The modularityallows porting to other platforms without extensivemodification of the base part. The created frame-work offers a simple way to write driver support fornew hardware.

The current driver design is divided into three groupsof modules:

The core module – (pbmcore) – is the main driverimplementing the basic device data structure,chip related defines, a bit/byte stack imple-mentation and the most important part, theProfibus FDL stack. The implementation ofProfibus covers Finite State Machines of anFDL Master station, FDL Slave station, low-level part of the Profibus Frame Analyzer andUART Bit/Byte Analyzer.

The module is platform and hardware indepen-dent and by itself does nothing but offer func-tions to other chip drivers. This allows use ofseveral chip drivers simultaneously without anycode redundancy. In addition it makes possiblesupporting new hardware without deep knowl-edge about the Profibus standard.

Chip drivers – (pbm 950pci, pbm 8250, ..) – im-plement basic I/O operations with realhardware like chip initialization, read, writeetc. The chip module, upon loading, registersto the core module these basic operations andprovides hardware and system dependent sup-port for things such as resource allocation orinterrupt registration. The remaining actionsare controlled by the core module through thestate machine.

User space interface module – (pbm fdl) – thethird group of modules implements an inter-face between user applications and the FDLlayer in the kernel space. Currently, the mod-ule is a character device but in the futurea socket module will be developed to allowcommunication using a socket-based technique.An application writes its request to, and readsresponses from, the device. This data is passedto the core module and then is addressed cor-rectly to an appropriate chip device. Regard-less of whether the user chooses to communi-

cate using a file or a socket, the API betweenan application and a kernel is unified, as wellas the API between an interface module andthe core module.

6 FDL API

Once the drivers are installed, communication withanother station on the bus is provided by sendingbytes in the raw form directly to the Profibus de-vice. Even thought it is simple to realize communi-cation in this way, the fact that a developer needs tounderstand frame structures, and even the Profibusspecification, make it unsuitable and inconvenient formost application developers. Hence an API was de-veloped to offer a unified and simple mechanism toaccess the Profibus network.

The API is provided in the form of a library.The library offers a unified system and architecture-independent programming interface handling thetransfer between FDL applications and Profibus sta-tions.

The project had a plan to fully support theFDL programming interface by Siemens. In theend, backwards support was not implemented due tothe proprietary license of that programming inter-face. Nonetheless, the project’s API partly supportsbackward compatibility with the Siemens’s FDL pro-gramming interface. Everything related to Siemens’sRequest Block should be removed as the library doesnot work with that structure. Replace the RequestBlock with a buffer. This backward support is imple-mented as macros calling the proper API functionsdescribed previously. Mapping between the project’sAPI and the API by Siemens is listed below:

pbm open SCP openpbm close SCP closepbm write SCP sendpbm read poll SCP receivepbm errno SCP get errno

7 Profibus DP

The Profibus DP (Decentralized Peripherals) layeris based on top of the FDL layer. There are threegroups of specification for the DP layer. The ba-sic version DPV0 should be supported by all DPdevices which involve support for Cyclic Data Ex-change and Diagnostics. The DPV1 extensions arean integral part of the Profibus PA specification pro-viding Acyclic Data Exchange, Process Alarm Han-

dling etc. Extension DPV2 introduces additional en-hancements that are used in high-speed servos anddrives and in functional safety systems. DPV0 willbe supported by the project and its implementationis under development. This will be an important stepfor certification of the implementation.

8 TCP/IP Server

Until now, the software supported only Unix-like op-erating systems or embedded ARM based systems.With the server, any station supporting TCP/IP canconnect to the Profibus network remotely.

FIGURE 6: Client-Server Architecture

The figure illustrates a client-server model. Theserver is installed on the machine along with the de-vice drivers. The device drivers implement installednodes on the bus in several modes. The server pro-vides access to devices created by the drivers overthe Internet network. On one side it uses the FDLprogramming interface for accessing those devices.On the other side socket communications are estab-lished to serve the client demanding remote access todevices.

9 Bus Analyzer and Monitor

Applications in industry often demand for trackingproblems on the fieldbus. The problems can be di-agnosed and localized by listening to and analyz-ing communication on the bus. By analyzing thecaptured data, it is possible to detect problems likeframes with errors (often caused by signal reflection),station inactivity, address collisions, too short SlotTimes of the Master stations, even bad timing ofstations.

This section introduces a graphical analyzer andmonitoring program. The program was written inQT and as with other components of the project, was

designed to be fast, reliable and modular. Thanks toits modularity, it will be more simple to integratenew features into the program so it could becomea versatile industrial bus control and monitoring pro-gram. The current version supports Profibus Frameanalyzer and UART Bit/Byte analyzer.

FIGURE 7: Profibus FDL/DP Analyzer

The main window contains menus, tool bars, sidebar, debug window and tabs with specific functions.The global buttons like Start Capture, Refresh View,Timestamp settings affect only the visible tab. Thedebug window is collective for all tabs. The sidebar shows information about the nodes. Several tabsof the same type can be present at the same time.The analyzer offers other interesting features like on-line view during capture, offline view of saved filesand timestamp display in five formats. Timestampcan be in absolute time, time difference between data,time from the start of capture, bit time difference be-tween data and bit time from the start of capture.Capture trigger, view filter and statistics of captureddata will be implemented in the next version.

FIGURE 8: Bit Analyzer

All addresses are specified using the URL mech-anism (Uniform Resource Locator). A URL iden-tifier could be pbm://server.pbmaster.org:11000/0,file:///dev/pbmaster0 or simply /dev/pbmaster0.The first URL refers to a device number 0 on a re-mote server using port number 11000, the latter tworefer to a local file.

10 Live Linux CD

The PBMaster project is an effort to develop andmaintain an open-source implementation of ProfibusDP. Running in open-source software has also disad-vantages. Probably the biggest disadvantage is thatalmost everyone using computers is familiar withcommercial operating systems like MS Windows orMac OS, but not everyone has experience nor theability to get on with Linux, BSDs, etc. Despiterapid improvements and the spreading use of open-source software, applications based on commercialsoftware and MS Windows are still dominant andthis situation applies especially for Profibus indus-try.

That is why the project has developed a LiveLinux CD offering an easy way to use the Profibussolution without need for software installation. Itis not necessary to install any operating system norother program - just plug in the hardware, insert theLive CD and start working with Profibus.

The CD is based on the Debian Lenny [6] dis-tribution. It contains utilities and useful tools likeXfce desktop environment and its programs, Firefoxinternet browser, Kate text editor, Openoffice.org of-fice suite, OpenSSH client and server, GCC compilercollection and Make utilities, Midnight Commander,Vim editor, GIT, CVS, SVN, media player and manymore programs including all necessary libraries tocompile the project’s components. The number ofpackages in total is more than 750.

FIGURE 9: Xfce Desktop with Profibus Util-ities

Imagine having an environment supportingProfibus and other UART utilities in just a few min-utes. There is no need for installation, no manualconfiguration required - just put the Live CD intoyour drive and reboot the computer.

11 An Overview of Applica-

tions

The figure shows a model production line runningProfibus using PBMaster. The drivers implement amaster station with an integrated PCI card, based onan OX16PCI954 chip, running at 1.5 Mbit/s. It ispossible to run up to 12 Mbit/s without any problem.The speed limitation is caused by one slave station.Actuators and sensors are connected to slave stationsby WAGO.

FIGURE 10: A Model Production Line

The figure shows several Profibus networks. Onenetwork consists of an ARM based board runningin master mode, a slave station with digital in-puts/outputs and an analyzer running in bit mode.The network communication speed is 500 kbit/s.The second network consists of two Profibus nodescommunicating at 12 Mbit/s. One node simulates amaster station, the second node runs in frame ana-lyzer mode. The rest 4 unconnected ports are mas-ters running at 187.5 kbit/s, 500 kbit/s, 1.5 Mbit/sand 6 Mbit/s. All nodes run simultaneously.

FIGURE 11: Master-Slave Communicationand Bus Monitoring

The figure shows two Profibus networks. There isone master, one slave and one bit analyzer on the firstnetwork running at 19200 bit/s. The second networkconsists of one master and one frame analyzer sta-tion running at 12 Mbit/s. Data from the analyzeris sent over the Internet network to the analyzer andmonitoring program running on a notebook. Moreexamples can be found on the project’s website [2].

FIGURE 12: Remote Bus Monitoring

12 Friendly projects

I would like to mention two projects, uLan andProfiM, which have similar objectives as PBMas-ter. Some solutions and ideas used in PBMaster havebeen taken from these projects.

The project uLan [4] provides a 9-bit multi-master message oriented communication protocol,which is transferred over the RS-485 link. Charac-ters are transferred in the same way as for the RS-232 asynchronous transfer except for the parity bit,

which is used to distinguish between data charac-ters and protocol control information. The physi-cal layer consists of one twisted pair of leads andRS-485 transceivers. The project is developed andmaintained by Pavel Pisa and Petr Smolik. For moreinformation please refer to the project homepage.

ProfiM [5] is a project implementing simulationof master stations using only UART integrated PCIcards or a simple converter of RS-232/RS-485. Itleads to an inexpensive solution as there is no needof any expensive proprietary hardware nor software.In addition it offers an FDL programming interfacecompatible with the API by Siemens. The projectsupports only Windows OS. One of the disadvan-tages is that the project has been inactive since 2004.The driver was not designed to be modular and frommy point of view it is inefficient and even the stabil-ity of the driver is not favorable. The project wasdeveloped by Pavel Trnka and maintained by PetrSmolik. For more information please refer to theproject homepage.

13 Compiling with OMK

At present, the device drivers are built inside thesource code directory using system’s default makescheme. On the other hand, the project’s applica-tions are built out of the source tree using Make sys-tem called OMK (Ocera Make System [7]).

OMK [3] is a Make system developed and main-tained by Pavel Pisa and Michal Sojka from the De-partment of Control Engineering at Czech Techni-cal University in Prague under the OCERA project.The main objective of the OMK system is to simplifycompilation of components on the host machine aswell as cross compilation for the target. In additionthe system provides for a better directory and filestructure. The make system allows building out ofsource trees and storing results of the compilation ina separate directory structure to simplify testing andprogram installation.

A key solution is to have a central Makefile withcompilation rules for most sub-components and com-ponents. This solution allows faster and smootherchanges to the system, such as kernel updates. Hav-ing most rules in a central file, Makefiles in sourcedirectories can be very simple.

OMK was not designed to support the BSD sys-tems. A number of changes have been made in orderto use this make system on FreeBSD and NetBSD.Although not all OMK features are available yet un-der FreeBSD/NetBSD, it is possible to compile all

project’s applications using this system. The OMKsystem is particularly useful for cross-compiling tothe final architecture (e.g. embedded ARM).

14 Advantages and disadvan-tages

One of the advantages and a strong point of theproject is based on the modular design of the soft-ware. It makes the implementation portable andmulti-platform. The software achieves 12 Mbit/swith very good performance. Thanks to the softwareimplementation, applications based on RS-485 couldbe switched to use the Profibus, therefore it is notnecessary to invent a new protocol in the applicationbased on this physical standard.

There are of course many disadvantages of thesoftware implementation. Even though it works re-liably in most cases, it is not possible to guaranteefully deterministic responses on common operatingsystems due to their design (e.g. when the CPU isoccupied by handling a lot of interrupts from anotherdevices). This could be solved by using Real-Timeoperating systems (tested on Linux with Real-TimePreempt patches). Another option to achieve fullydeterministic responses is to use embedded boardswithout operating system.

This is a software implementation without hard-ware support. It means there is no oscilloscope modenor speed detection by analyzing the signal. Anothervery important disadvantage is that this implemen-tation is not yet certified (under development).

15 Conclusion and Future

Work

An open implementation of Profibus has been pre-sented throughout this paper. One of the statedgoals for the project was the creation of multi-platform software capable of running on systems withoperating systems as well as embedded boards with-out OS. The components were designed to facilitateporting to new platforms. The software is imple-mented to be fast, reliable and requiring minimalsystem resources.

Currently, the project offers an implementationof Profibus FDL master stations, FDL slave stations,Profibus FDL/DP frame analyzer, bit and byte ana-lyzer for UART based bus, an FDL programming in-terface, Live Linux CD, a TCP/IP server for remoteaccess, a set of examples and free Profibus documen-

tation. The software runs on Linux, FreeBSD andNetBSD operating systems as well as ARM basedembedded systems. A few open hardware solutionsare also available.

There are many applications, where Profibuscan help to make our life more comfortable. TheProfibus can be use for example in automatic doorsystems, power saving systems, temperature regula-tion in buildings, etc. Application of this open so-lution may be appreciated by universities and com-panies, as it is currently necessary to have very ex-pensive commercial hardware and software for anyexperimentation with Profibus.

Despite these achievements, there are still manyproblems to be solved to facilitate use in professionalapplications. The future objective is to implementthe Profibus DPV0 layer and to create an unofficialcertification of the implementation. Even though theslave abstraction layer is working, there is still a lotof work to be done to improve it. The project willextend support for new hardware and operating sys-tems like FreeRTOS and MS Windows. Libraries,graphical analyzer and other applications will be im-proved.

The problems related to Profibus are very com-plex and much effort is required to overcome them.My hope is that this project will make more peoplefamiliar with this popular fieldbus solution, so the ex-tent of use of the Profibus standard would not be lim-ited only to commercial applications. The softwareimplementation can spread the use of the stan-dard to applications, where hardware supported so-lutions are inconvenient or not possible.

References

[1] PBMaster Project, Tran Duy Khanh,http://www.pbmaster.org

[2] PBMaster - Wiki Pages, Tran Duy Khanh,http://wiki.pbmaster.org

[3] OMK Project, Pavel Pisa, Michal Sojka,http://rtime.felk.cvut.cz/omk/, CTU in Prague

[4] uLan Project, Pavel Pisa, Petr Smolik,http://cmp.felk.cvut.cz/∼pisa/ulan/ul drv.html,CTU in Prague

[5] ProfiM - Profibus Master, Pavel Trnka, PetrSmolik, http://profim.sourceforge.net, CTU inPrague

[6] Debian Project, http://wiki.debian.org/DebianLive

[7] OCERA Project, http://www.ocera.org