DNP 3.0 Ethernet to BACnet IP
Quickserver Gateway (Serial-Ethernet)
QuickServer is a high performance, fully configurable, cost effective Building and Industrial Automation gateway for integrators to easily interface devices to networks in commercial buildings and industrial plants.
System integrators world-wide have benefitted from the value of the powerful line of interoperability gateways offered by FieldServer. Now, QuickServer adds to that value by running the same robust FieldServer protocol conversion software on a highly cost effective platform backed by the experience, engineering expertise and proven technical support that integrators have come to expect from FieldServer.
QuickServer is available in two series. The FS-QS-10XX Series is preloaded with two BAS drivers (serial, Ethernet and/or LonWorks) from a choice of Modbus RTU, Modbus TCP, BACnet/IP®, BACnet MS/TP, LonWorks®, JCI Metasys® N2 and SNMP. Each QuickServer can handle up to 250 points.
The FS-QS-12XX Series QuickServer is available to use any Serial, Ethernet or LonWorks driver in the extensive FieldServer driver library. The FS-QS-12XX Series can handle up to 500 points and is available with a choice of RS-485, RS-232 or RS- 422 serial ports, KNX or M-Bus, in addition to Ethernet and LonWorks (optional).
Each QuickServer includes browser-based tools to make it easy to set-up
QuickServer and perform diagnostics including determination of status, network
settings, node information, map descriptors and more. The USB flash drive also
includes the Discovery utility to determine what FieldServers are on a network.
DNP 3.0 Ethernet
The Ethernet DNP 3.0 driver allows the FieldServer to transfer data to and from devices over Ethernet using DNP 3.0 protocol. The FieldServer can emulate either a Server of Client. The DNP 3.0 Ethernet Driver adheres to and supports the framework specified by the IEEE 1815-2012 Standard for electrical power system communications.
The following information was copied form the DNP 3.0 User Group Internet site.
The development of DNP3 was a comprehensive effort to achieve open, standardsbased Interoperability between substation computers, RTUs, IEDs (Intelligent Electronic Devices) and master stations (except inter-master station communications) for the electric utility industry. Also important was the time frame; the need for a solution to meet today's requirements. As ambitious an undertaking as this was, we reached this objective. And since the inception of DNP, the protocol has also become widely utilized in adjacent industries such as water / waste water, transportation and the oil and gas industry.
DNP3 is based on the standards of the International Electrotechnical Commission (IEC) Technical Committee 57, Working Group 03 who have been working on an OSI 3 layer "Enhanced Performance Architecture" (EPA) protocol standard for telecontrol applications. DNP3 has been designed to be as close to compliant as possible to the standards as they existed at time of development with the addition of functionality not identified in Europe but needed for current and future North American applications (e.g. limited transport layer functions to support 2K block transfers for IEDs, RF and fiber support). DNP3 has been selected as a Recommended Practice by the IEEE C.2 Task Force; RTU to IED Communications Protocol.
DNP3 is an open and public protocol. In order to ensure interoperability, longevity and upgradeability of, protocol the DNP3 Users Group has taken ownership of the protocol and assumes responsibility for its evolution. The DNP3 Users Group Technical Committee evaluates suggested modifications or additions to the protocol and then amends the protocol description as directed by the Users Group members.
DNP3 Features: DNP3 offers flexibility and functionality that go far beyond conventional communications protocols. Among its robust and flexible features DNP3 includes:
- Output options
- Secure configuration/file transfers
- Addressing for over 65,000 devices on a single link
- Time synchronization and time-stamped events
- Broadcast messages
- Data link and application layer confirmation
DNP3 was originally designed based on three layers of the OSI seven-layer model: application layer, data link layer and physical layer. The application layer is objectbased with objects provided for most generic data formats. The data link layer provides for several methods of retrieving data such as polling for classes and object variations. The physical layer defines most commonly a simple RS-232 or RS-485 interface.
DNP3 is very efficient for a layered protocol while ensuring high data integrity
DNP3 Benefits: Because DNP3 is based on the IEC 870-5 requirements, DNP3 is suitable for application in the entire SCADA environment. This includes RTU to IED communications, master to remote communications, and even peer-to-peer instances and network applications.
Being an object-based application layer protocol, DNP3 has the flexibility to support multiple operating modes such as poll-response, polled report-by-exception, unsolicited responses and peer-to-peer. It permits multiple masters and encourages distributed intelligence.
Users can expect many benefits from using DNP3. In the short term:
- Interoperability between multi-vendor devices
- Fewer protocols to support in the field
- Reduced software costs
- No protocol translators needed
- Shorter delivery schedules
- Less testing, maintenance and training
- Improved documentation
- Independent conformance testing
- Support by independent users group and third-party sources (e.g. test sets, source code)
The BACnet/IP driver allows the FieldServer to transfer data to and from devices over Ethernet using BACnet/IP protocol. The FieldServer can emulate either a Server or Client.
All information in a BACnet system is represented in terms of objects. The Object_Identifier is a 32-bit code that identifies the type of Object (also identified by the Object_Type Property) and its "Instance" number, which together uniquely identify the Object within its BACnet device. Theoretically, a BACnet device could have over four million Objects of a particular type. The Object_Name is a text string, which has a unique capability.
BACnet devices may broadcast queries for devices that contain Objects with a specific Object_Name. This can greatly simplify project setup.
BACnet requires one Device Object to be present in every BACnet device. The Device Object makes information about the device and its capabilities available to other devices on the networks. Before one BACnet device starts control-related communications with another, it needs to obtain some of the information presented by the other device's Device Object. Unlike other Objects, the Device Object's Instance number must be unique across the entire BACnet internetwork because it is used to uniquely identify the BACnet devices. It may be used to conveniently identify the BACnet device from other devices during installation.
Standard object types are used to hold real time data and other information. Each Object Type is referenced by a number, for example 0 represents an Analog Input. See Appendix D.1 for abbreviation list.
Each Object consists of a number of prescribed properties, the main property being the Present_Value. Objects are monitored and controlled through their properties.
The information that follows describes how to expand upon the factory defaults provided in the configuration files included with the FieldServer.