[[!img DBPC-logo-nb.png]

Links

Overview

Since popularity of Linux operating system in industrial environment increase, needs for interoperability between Linux applications and industrial equipment come true. Actually most every Linux scada/HMI project reinvents the wheel for field communication, without interoperability.

Mainly, DPBC (DBus for process control) is a standard abstraction layer between SCADA and field equipment.

DBPC is based on D-Bus which is a message bus and activation system that is set to achieve deep penetration in Linux.

DBPC define a standard set of objects, interfaces and methods for use in process control. It will provide a common standard for industrial communication, especially between HMI, SCADA and field electronic equipement.

Participate

If you have ideas you want to suggest but don't want to edit this main document, please go to the brainstorming Page.

Synoptic

[[!img DBPC-Synoptic.png]

Trivial diagrammatic description of DBPC architecture.

Audience

• Process control and automation engineer
• Linux user and open source programmer
• HMI and SCADA open source project
• Industrial embedded systems programmer
• Industrial equipment manufacturer
• Industrial computer manufacturer

Definitions

DBus

D-Bus is an inter-process communication (IPC) mechanism implemented as a software data bus which permits communication between applications. Unless it is not a process field bus as used in factory floor, its core functionality can easily be apprehended in the same way by control engineer. For more detail about DBus and IPC see related IPC specification.

DBPC

DBPC is a layer above DBUS. It define a standard set of objects, interfaces and methods for use in process control, automation and domotic applications, to facilitate interoperability. Primary goal is defining a common communication language for real time communication of plant data between control devices from different manufacturers and SCADA, HMI, process control and open source applications.

DBPC-server

DBPC servers are services which provide common tags access trough DBus. Generally a DBPC server grants real time data access to one or more remote programmable logic controller. Most of time is done by pooling. Typically DBus servers represent a field bus protocol. (For example : ModbusTCP DBPC server, Profibus DBPC server).

DBPC-client

DBPC client are compliant application which access to tags in one or more DBPC-server.

Tags

Each datum made available by a DBPC server is called a tag. Tags correspond (roughly) to physical values, factory state, command signals, etc. A tag's value may be read or written by a DBPC client.

Device

From a DBPC point of view, devices are equipment or objects which may be controlled or monitored through a DBPC server. While the primary target of DBPC are industrial applications, DBPC servers may also be implemented for other types of "industiral" devices : HVAC, heating control, domotic, real time data producers, metéo stations, telescopes, multimedia equipment, IR remote controls, DCF clocks, robotics, USB gadgets, RFID readers, etc.

PLC Programmable logical controller

Programmable logic controllers are digital computers used for automation of electromechanical processes. Unlike general-purpose computers, PLCs are designed for multiple input/output arrangements, extended temperature ranges, immunity to electrical noise, and resistance to vibration and impact. Although the IEC 61131-3 define PLC programming languages, manufacturers typically implement their own programming tools and interfaces. Interoperability is not yet a priority for PLC manufacturers.

Field bus

Fieldbus is an industrial automation network system for real-time distributed control. It offers a protocol for interconnecting instruments actuators and sensors with a controller. The domain of field bus application is typically an industrial plant. Many competing fieldbus technologies exist, merging them with D-Bus is a brave goal followed by DBPC.

Specification

Part 1, DBPC Basis

Part 1 This part introduce basis usage of D-Bus for process control.

Part 2, DBPC Tags : interfaces and methods description

Part 2 This part specify common D-Bus objects, interface and method for DBPC tags.

Part 3, DBPC Devices : specification, interfaces and methods description

Part 3 This part specify common D-Bus objects, interface and method for DBPC devices.

Part 4, DBPC Servers : specification, interfaces and methods description

Part 4 This part specify common D-Bus objects, interface and method for DBPC server.

Part 5, DBPC Configuration file

Part 5 This part define a common configuration file format which are used by DBPC servers.

FAQ

What is the difference between DBPC for Linux and OPC-DA for Windows ?

OPC-DA was designed to bridge Windows and process control hardware and software applications. Standard defines consistent method of accessing field data from plant floor devices. Actually, OPC-DA is probably the most common interoperability tool used in automation and process control world.

The need for interoperability are often equally applicable in Linux world. However, because OPC-DA is based on the OLE, COM, and DCOM technologies developed by Microsoft for the Microsoft Windows operating system family there are encumbrances preventing wholesale adaptation of these technologies to Linux systems. With this in mind, DBPC was created to present end users with a common cross-platform experience allowing DBPC and OPC-DA "feel" functionally similar.

Nevertheless, DBPC distinguish of OPC-DA in one sens that it target to exploit full advantage and benefit provided by Linux operating system and Open source software development. So we personally expect better performance and reliability.

Although DBPC is open source oriented, DBPC also still to encourage, manufacturer providing there own DBPC compliant software, not necessary open source, in the same way than OPC.

New specification OPC-UA work with Linux ? Do we really need DBPC ?

OPC-UA is an evolution of OPC-DA. It has been created to extend some features lacking with OPC-DA.

OPC-UA is more like a communication protocol. DBPC is still an Inter-Process Communication.

• In one hand, OPC-UA will be suitable for automation network and inter-systems interoperability, because it is XML based and include authentication support.
• In the other hand DBPC is rooted in Linux thanks to D-bus which allow deep system integration and eases application development. D-Bus offers low-latency and low-overhead and designed to be small and efficient to minimize round-trips. So very suitable for embedded systems as well as fanless touchscreen HMI. In addition, because the protocol is binary (as opposed to textual), it may remove some serialization overhead. OPC-UA may benefit of DBPC and reciprocally. As a reslut of OPC-UA can be implemented as a upper layer (wrapper) above DBPC, similar to upcoming XMP-RPC, SOAP, CGI and so on.

There are many interprocess communication and networking protocols. Why D-BUS ?

A first approach may be reading D-Bus FAQ, 9 to 18 which compare D-Bus with several IPC.

When choosing an IPC for process control in Linux, some criteria were decisive :

• Availability : D-Bus has strong integration with the Gnome and KDE desktop environments.
• Portability : D-Bus is portable to many Linux or UNIX flavors -- a port to Windows is in progress.
• Liability : The D-Bus low-level API reference implementation and protocol have been heavily tested in "real world" systems.
• Multi-language support : D-Bus is supported by many programming languages including : C, C++, Java, Python, Perl, etc.
• Scripting : D-Bus may be used from terminal (dbus-send) allowing command line/shell scripting.
• Efficiency : D-Bus may be effectively implemented in low performance hardware and embedded systems.
• Openness : A a side effect, instead of DBPC, HMI applications might benefit by supporting D-Bus connectivity.