Tips for Reading a WITS Device Profile


Having been given that choice, the users now need a method of determining which Field Device to select for any particular project. Each project may have its own requirements, for instance:

  • A specific communications medium to be used. Maybe the outstations deployed for the project are to be battery powered and should support TCP communications over GPRS.
  • A specific regime for recording data at the device. For example, in CSO monitoring it may be necessary to keep records of the 15 minute values of sewage level against the weir. In the case of WITS this is called “logging”.
  • A specific alarming regime. The device may need to monitor its inputs and when they exceed certain levels, either log those values or make them immediately available to the Master Station.

The user must now match the project requirements against the capabilities of the WITS Field Device to ensure that the device is capable of meeting all the requirements. The WITS Device Profile is a good starting point for users to do this. It also assists users in comparing devices, and, more fundamentally to the WITS-DNP3 Protocol, permits the Master Stations to understand the capabilities of a device in an automated manner. However, to support this function with the Master Station, the WITS Device Profile in its base form is presented as an XML document, which tends not to be easy for users to read. More user-friendly forms are available and these will be discussed later.

This article seeks to demystify the WITS Device Profile for users by: explaining what the Device Profile is, how it can be acquired, what forms it takes, how to read simple setting from the profile, and various issues to be aware of when reading the Device Profile. The article is suitable for users of the WITS-DNP3 Protocol and may also be of use to new vendors hoping to gain an understanding of the WITS Device Profile. Within this article we also use the term “Device Profile” to mean WITS Device Profile.

What is a Device Profile?

The WITS-DNP3 Protocol describes many different capabilities that a WITS Field Device or Master Station may have. Not all Field Devices or Master Stations implement all of these capabilities. For example, it is possible for Field Devices to support the downloading and running of applications on the device, such as IEC61131-3 applications. However, a battery device designed for monitoring a few signals may not need this level of complexity and may therefore not support it. The Device Profile lists all of the capabilities and describes, for a single device, which capabilities are implemented and which are not.

Every Master Station or Device should have a WITS Device Profile. Indeed, for any device which has self-certification or verification it is a pre-requisite that a Device Profile must be available for that device. Every Device Profile applies to only one device or family of devices.

To deploy a Field Device against a Master Station, the Master Station must have access to a copy of the device’s Device Profile. The Master Station uses this Device Profile to understand what the device is capable of and thereby restricts what the user of the Master Station can do in configuring the device and how the Master Station interacts with the device.

The Configuration Application (CA) for a specific Field Device is the software provided by the device vendor which enables the device to be configured, as discussed in the WITS Application Notes. The CA is capable of providing the correct Device Profile for a device. That Device Profile can then be used by the Master Station.

The Device Profile provides the capabilities of the device and not the specific configuration of the device. The specific configuration of the device is described in the Bulk Configuration File (BCF) and the Incremental Configuration (IC) as laid out in the WITS Application Notes. Note that the BCF and IC must not implement configurations which are not supported by the capabilities laid out in the Device Profile. So, for example, if a Device Profile indicates that the device does not support Rate of Change, then the BCF and IC for that device should not configure that.  

As a user, the most important thing the device profile provides is the list of what a device is capable of, allowing a comparison of the devices capabilities against those required to fulfil a specific application. So for example, if a device which is capable of supporting GPRS is required then the communications part of the device profile for the device in question should be checked to see that the device does indeed support GPRS.

Where can I get the device profile?

Device profiles are normally freely accessible from the WITS website or the device vendor. On the WITS website navigate to the Device Catalogue under the Certification tab. The device catalogue lists self-certified and verified devices with links to the vendor’s web sites, their product pages and to the device profiles submitted to WITS for certification. You can see an example of what this looks like below.

Figure 1 – An example of the WITS website Device Catalogue page for WITS verified devices in June 2016. This example shows the Link to Device column which contains version numbers which are hyperlinked to a page which is tailored for each device.

By clicking on the version number in the “Link to Device Profile” column, a page specific to that device and manufacturer is shown, which includes links to display the device profile and to download the device profile.  See the screenshot below.

Figure 2 – An example of a device specific page showing links to allow the device profile to be displayed or downloaded.

Note that in general the WITS website only carries the device profiles submitted by vendors when they apply for self-certification of verification. This version of the device profile may be older than the current version available from the vendor, so if you want the most recent version then contact the vendor directly and request it.

Vendors may publish their most recent device profile to the WITS web site as they wish, however these will not be marked as self-certified or verified unless the vendor has re-submitted all the relevant paperwork. An example of this can be seen on the Schneider Master Station device profile page.

Why might the most recent device profile differ from the device profile on the WITS website and used for self-certification or verification? Well, the act of re-running all tests and providing the paperwork to WITS is non-trivial and so vendors may choose to batch this up and only occasionally resubmit later version of software. Suffice to say that as a user you should be aware that:

  • The most recent version of device profile is always available from the vendor.
  • The main version shown on the WITS website is the version for which self-certification or verification was achieved.
  • Vendors may or may not have tested against later versions of the device profile. If they have, it is likely they would share this information with prospective users.
  • More recent versions of the device profile may show extra, newly implemented capabilities for devices.

Remember that the device profile contains the version number and name of the Field Device alongside the version of WITS supported in the first section of the profile. This allows you to be sure that these properties match what you are buying and that they are supported on your Master Station.

What forms does it take?

As already mentioned, the device profile is primarily available as an XML file which makes it easy for a computer system such as a Master Station to read and interpret the device profile. However, the XML format is not convenient for users attempting to quickly determine whether a device performs some function.

To support an easily readable format of the XML device profile, WITS has provided an XSLT file which, when used appropriately, displays the XML file in a more readable HTML format. In fact, when clicking on the display link on the WITS website this is precisely what happens; the difficult-to-read XML is converted to easier-to-read HTML. A simple example is shown below using Section 1.5 of the device profile. This section is a simple example but as you can see you are looking at lines 304 to 309 of a large XML file; finding that data and interpreting it can be very difficult, whilst the well-presented table in HTML is much easier to interpret.

Figure 3 – A comparison of the XML and HTML device profile representations, showing the counter point section of the device profile only.

Often vendors will also convert that HTML output from the XML and XSLT into a PDF document, which can then easily be transferred to users. As a human consumer, you do not need to know the exact mechanism of translation from XML to HTML via the XSLT file. Normally just opening up the XML file in a well behaved browser would automatically deal with this, but if you do have problems getting hold of a readable HTML or PDF file, please get in touch with the vendor, who will be able to get those files for you.

What the device profile contains

The device profile is divided into a number of sections which describe the various aspects of a device capabilities. This section provides an overview of the sections indicating what is described in each.

  • Device Identification – This section describes whether the unit is a Field Device or Master Station, the vendor name, device name, hardware version, software version, device profile document version number and supported version of WITS.
  • Communications – This section includes details of whether the device supports incoming or outgoing connections, the modes of connection supported and a full list of the communications ports available (that is ports in the WITS sense, which is to say specific channels out of or into the device). This section is important for determining if your communications architecture is supported by the device.
  • Health-Check – Details which bits are provided in the health check dataset and their meaning.
  • Analogue Points – Describes the limit model as applied to analogue points including number of limits, hysteresis, persistence etc., whether the point can be overridden, and the raw type of the points.
  • Counter Points – Describes the number of limits supported by counter points and whether these can be overridden.
  • Binary Points – Describes whether binary points can be overridden and what persistence can be applied to binary points.
  • Profiles – The field device can use profiles containing values spread over time to act as limits or for the purposes of control. This section describes the types of profiles that are supported, how many profiles are supported, the number of vectors (i.e. individual values) in a profile and how those vectors are interpolated.
  • Rate of Change – Describes the options for supporting rate of change and no change detection on analogue and counter points.
  • Extended Data Points – Describes how max, mean, min, integrals, state counters and state runtimes are supported through extended data points.
  • Action Inhibit Data Set – Describes how the action inhibit data set is supported, whether it can be applied against single points, all points, whether it supports timeouts on inhibits and whether local action inhibits are supported.
  • Data Logging – Describes the types of logs that are supported, whether associated values are supported, overflow and filling behaviour, periodic logging rates and logging offsets.
  • Application Programs – Describes whether the Field Device supports applications programs, how many, and whether they can be started, paused and stopped.
  • Configuration – Describes the configuration options that are supported by the Field Device such as whether configuration download or upload are supported and whether firmware download is supported.
  • Point Event Data Sets – Describes the details for generating point data set events on the Field Device.
  • High Speed Sampled Data – Describes the high speed sampled data facilities that are supported by the Field Device. These include whether it is enabled, the number of points supported, the sample rate and the cycle rate.

You can read further details on all of these configuration parameters in the device profile itself or by reading through the relevant sections of the WITS application notes.

Specific issues to be aware of

In talking with users, the WITS PSAC became aware of a number of misunderstandings that can exist when reading a device profile. The most common of these are captured below.

Version Number and device capability

There are a number of versions of WITS; starting at version 1.1 and, at the time of writing, going to version 3.0. Each successive version of WITS tends to add new features to the protocol which require the protocol itself to change. This page on the WITS website gives an overview of the new functionality included in each version of the protocol.

The device profile for a Field Device may indicate that it supports protocol version X. However, this does not mean to say that it implements the extra functions in that version of the protocol; just that it implements the protocol compatible with those functions.

It is therefore important that one does not assume that a WITS 1.3 Field Device implements all the extra functions in WITS 1.3. To determine if a device does implement these extra functions it is necessary to check the device profile and ensure that these extra functions are indicated as implemented.

Field Device and Master Station compatibility

Field Devices which implement multiple versions of the protocol must have multiple device profiles, one for each version of the protocol implemented. Having a Device Profile which indicates that a device implements WITS 1.3, for example, does not guarantee that the device also implements WITS 1.2 and WITS 1.1. It is essential to check that device profiles are available for these previous versions. This is because it is not a requirement that Field Devices which support a specific version of WITS must also implement earlier versions of WITS.

However, in the case of a Master Station, if that Master Station implements a specific version of WITS then it must also implement earlier versions of WITS. In this case it is only necessary to check that the Master Station has a device profile at the latest version of WITS.

Also note that if a user’s current Master Station implements, for example, WITS 1.2 and earlier, then the highest version of WITS Field Device that can be used against the Master Station is WITS 1.2. A Field Device which only implements WITS 1.3 will not interoperate with a WITS 1.2 Master Station; such a device could only work when the Master Station is upgraded to also support WITS 1.3.

One thing the device profile does not indicate is whether the device can be configured for different protocol versions or whether different versions of software must be installed to implement different protocol versions. Users should check this if it is important for their method of deployment. Having, for example, a WITS 1.3 Field Device which also implements WITS 1.2 and WITS 1.1 and is configurable to select the version used would allow that device to be installed against a WITS 1.2 Master Station. Then, when the Master Station is later upgraded to support WITS 1.3, the field device can be changed by configuration to use the WITS 1.3 protocol. If the Field Device implements functions only available in WITS 1.3, these will become available for use only when the device is changed to use WITS 1.3.

Device communications

Another common problem is to assume that a Field Device supports all forms and types of communications. For instance, it is easy to assume that, because it has Ethernet, a device will be able to accept incoming connections at any time or make outgoing connections when necessary. The types of communications that a Field Device supports and how those communications can be used are described in the device profile and must be understood and checked prior to attempting to deploy the device.

The device profile includes a table at the end of Section 1.2 which lists the WITS ports a Field Device has available to communicate with. An example of this table is shown below.

Figure 4 – An example of the ports table for a Field Device taken from the end of Section 1.2 in a device profile.

So, for the device which has the above device profile, one can determine that the device supports Ethernet, PSTN, GSM, GPRS, Private Wire/RS232 and OPT/PPP. Note that the name column of the table is determined by the vendor; if you are unsure of what type of communications are supported on a port, please consult the vendor of the Field Device.

For network type communications such as Ethernet and GPRS the table also indicates that the ports are capable of being configured in listening mode, initiating mode or both (dual). Direct connections are always available. Non-direct or network connections which are on demand do not indicate whether they can be contacted or can initiate contact; to determine this one must look at other fields in the device profile.

Figure 5 – An example of the start of the Communications section of the device profile (1.2) showing the setting to indicate if a device can be connected to or can make connections.

In the excerpt from a device profile above, one can see whether a device supports outgoing connections and how many it can support, also whether a device supports incoming connections. Note that the number of supported outgoing connections does not refer to how many connections are made at once; WITS units normally only ever make one connection at a time. Rather, the number of outgoing connections refers to the number of separate outgoing connections that can be configured to allow the Field Device to connect to the Master Station. So, for instance, one may have multiple connections, the first being an outgoing connection over Ethernet to a specific IP which routes to the Master Station, then a PSTN connection on a specific phone number to the Master Station, then another PSTN connection on another phone number to the Master Station. Every time the Field Device attempts to connect to the Master Station it will use this connection list in the order specified to attempt to connect. If the most important connection fails then it moves to the next in the list.  This list of connections is not specified in the device profile, only the maximum number of such connections that may be configured. The list of connections is configured through bulk and/or incremental configuration.

If a Field Device supports outgoing connections, then it could support scheduled connections; however this is specified in sections 1.2.10 and 1.2.11 of the device profile.

So, to be sure the device you are going to deploy will work against your Master Station using the communications channels you have available, it is important to check that the settings in Section 1.2 match your system.

Multiple Field Devices running over a single communications channel

The WITS device profile for a particular Field Device describes how one device can be set up and configured on a user’s Master Station and communications network. However, it is important that users consider the effects of running many such devices over that communications channel. Carefully staged deployment of multiple devices to user’s system should ensure that any latent problems are uncovered early and can be addressed. The WITS PSAC would appreciate users sharing information on any problems encountered so that general guidance can be developed for other users and, where necessary, protocol changes could be suggested to alleviate the problems.

As an example of one such problem, if a user chooses to have a large number of devices permanently connected to a Master Station system, say for example over GPRS, then the active Master Station instance is swapped for any reason, all such connections must be re-made from the new active Master Station instance. This was reported to take some considerable time on some systems but was alleviated to some degree in optimisations made to the protocol in WITS 3.0.

Extended or associated points

Certain statistical values can be supported by some Field Devices, such as maximum, minimum, mean, state runtime or state counters. These can be implemented in two separate ways: as extended (i.e. virtual) points, or as associated values.

Extended (i.e. virtual) points are points available on the Field Device which are explicitly available for storing these statistical values if so configured through bulk or incremental configuration. Section 1.9 of the device profile indicate if extended data points are supported. If they are, then these points can be separately logged and have their own limits etc.

With associated values the statistical values are logged as associated points to the points against which they apply. If this method is supported, then Section 1.11 “Data Logging” of the device profile will indicate this in 1.11.3 “Supports associated values”.


This document has introduced WITS device profiles, what they are, how you can get them and problems and issues that should be considered in interpreting them. Hopefully you have found the document useful. If you feel there is something missing or extra information that could be added to help other users, please send that information to WITS using the email on the contacts page of the WITS website (, so that the PSA can upgrade the document.


Mark Davison, Terzo Digital, June 2016.