17-Nov-2015 Steps to consider in implementing a WITS Field Device

So you are considering implementing a WITS Field device? This article provides an insight into the factors you may need to consider and the steps you may have to take to do that. By pulling together some of the experiences of current WITS device manufacturers on the PSAC, it also provides a glimpse into the types of issues that others in your position have found important.

To explain a few terms before we dive in to the article, the protocol is called WITS-DNP3 as it is based on DNP3; for the remainder of this article we will just refer to it as the WITS protocol. The PSA is the Protocol Standards Association, set up to manage the protocol and any other protocols developed. The PSAC is the PSA Committee, a group of six users and six vendors of the PSA who are voted onto the PSAC by the members of the PSA every two years.

The majority of the article is presented in an informal and anecdotal style giving you an unordered list of things to consider, together with why they should be considered. The article ends by pulling together a roughly ordered list of the things you will need to do during planning and development. Remember though that each vendor organisation is likely to have a different experience depending upon their exact situation, so please treat this in the advisory sense in which it is written.

Business Case

As with any project you are going to undertake, having a sound business case will make all the difference in getting the project started and maintaining focus once it is underway. That solid business case, as always, an exercise in comparing your costs against your potential gain. If you can reasonably present gains which outweigh costs, then depending upon other business objectives, you are likely to garner strong support for the project from your stakeholders.

The actual formulation of the business case is an exercise for each organisation alone; however, we present here a few things to consider with respect to costs and potential gain. On the costs side you will need to consider the following items; more discussion of each of the items follows later in the article. All figures are accurate at the time of writing (autumn 2015):

Membership of the WITS Protocol Standards Association (a £1000 one-time registration fee, then £500 per annum, see the WITS website).
Membership of DNP3 ($1000 or £650 per annum, see the DNP3 website).
WITS Test Specification (£3000, available by contacting enquiries@witsprotocol.org).
Costs of read in and design.
Costs of development and testing.
Possible costs of a test Master Station if you are using this (approx. £10,000, see more detail on the use of test Master Stations on the website here)
Costs of WITS Certification, including Self Certification and Verification if you are going for this, see more details here.
Sales and marketing costs.
Support and remedial costs.

If DNP3 and WITS are new to your organisation, you may be able to mitigate some of the uncertainty in costs by contracting others with pre-existing knowledge in the area to help estimate, plan and/or develop.

Estimating the potential gain is a much trickier procedure as you will need to evaluate the market position and opportunity for deployment of your type of device. Although much of the “magic” associated with this estimation will come from your Sales and Marketing department we offer the following paragraphs for you to consider in doing that.

Have in mind a unit cost, which should be based on what you already see in the market place, borne against any unique selling points which are going to lift your device above the others in the market. Alternatively, maybe you are going to provide the same or fewer WITS functions but at a much more attractive cost?
Consider the volumes of your sales that are likely. Where will those sales likely come from? Who are you competing against? Are there industry initiatives or calendar activities (such as the AMP cycle in the UK) which will drive some of those sales?. Do you have something unique about your product which will drive those volumes of sale?
Carefully consider the the time period over which you might expect that volume of sales to be achieved. Remember that this time period can only start once you have completed development.
Be aware that a WITS device can also function as a pure DNP3 device. If you plan accordingly then that DNP3 device will be a device capable of much more than just DNP3 Level 2 functions and will open up more market opportunity than a WITS-only device would present.
Consider whether you can implement the WITS standard on more than one product; this may improve your business case in that you may be able to sell more units in order to recoup your project costs.

Combining all the information above you will be able to develop a model of how long it will take for you to recoup your development costs and reach break-even for the product development.

The Standards and Organisations

To add WITS to your product you will need access to the DNP3 and WITS standards. These are available by joining the relevant organisations. Becoming a member of WITS and DNP3 also gives you various other benefits such as:

Access to further technical information, including recent technical bulletins.
The ability to vote for your chosen representatives on the standards committees.
The ability to get information about your product (once compliant) published on the organisations’ websites.
The ability to ask technical questions regarding the protocols and have them answered by the organisation or through their forums.
In the case of WITS, the chance to get news stories about your WITS product published on their `website.
In both cases the permission to use their logos in some of your marketing.

There is a lot to take in with the DNP3 and WITS standards. This knowledge is required to help you estimate, plan and design your solution. You need to allow a realistic time for read in and then the design and documentation of how you will incorporate the protocols into your product.

Use Device Profiles to Guide Your Thoughts

The WITS device profile is an XML document which defines what a Field Device is capable of within the scope of WITS. Many of the functions provided by WITS are optional. The device profile is the document which defines which of those optional functions a device will perform. As such the device profile is an important document for users, who can gauge how well the functions on the device match their requirements.

Apart from informing the users of the functions provided by your device, filling in the device profile is a good method of working out exactly what will and will not do. It is a good idea to fill in the device profile as early as you can. The device profile contains, for example:

The version of the WITS protocol you will be compliant with.
The interfaces implemented by your Field Device.
The types of points that are supported.
The types of events that are supported.
The types of logging that are supported.

Once completed, the WITS device profile will frame your estimations, planning, development and testing. It also acts as a good initial agreement of the capabilities that the device will have on release between the management team and the development team.

To assist you in seeing what other devices are capable of, self-certified and verified devices listed on the WITS website have links to their device profiles. This is a good starting point to let you see what is out there and what those devices can currently do.

The original purpose of the device profile was to provide an automated means by which the WITS Master Stations could determine what a device is capable of and how they should behave with that device. That is why the device profile is written in XML. However, reading XML is never any fun for a human, so, WITS have made available an XSLT file which transforms your XML into a much easier to read HTML version with full English descriptions of what each item is. This is much easier to work with in the project context, although the XML is always the master document.

An example XML document and the XSLT to transform the document into an HTML is available with the application notes once you have become a member of WITS. Also available in the same pack is the XSD file which specifies the exact structure of the XML document and against which any XML document you edit must validate.

What’s Already Available

No one likes building something from scratch if there is already a reliable implementation of it available. This is never more true than in the software industry where huge amounts of money can be saved by building on already available and trusted software. Unfortunately, there is not as yet, a software product available which would implement WITS for you, however, there are options when it comes to DNP3 which is half the battle in building a WITS system. A simple Google search on something like “DNP3 Software Stacks” will show some of what is available.

Within the portfolio of WITS Field Devices and Master Stations already available there are examples of both “roll-your-own” code (starting from scratch, developing everything in house) and also development based on standard commercial stacks. So both methods work, it is really a question of how each method will fit into your development plans.

For an organisation with little experience in DNP3, using a pre-developed software stack can offer many positive points, however it does force your implementation to fit in with the design of that stack. You also have to consider the costs of purchase and support, although these could be balanced against those thorny times when you have to debug a very low level DNP3 problem in your own implementation.

One thing it is worth pointing out is that at the time of writing the open source implementations of DNP3 that we are aware of do not necessarily support all of the DNP3 functions above DNP3 level 2 which are required for a full implementation of WITS. So although the low cost of open source may appeal, be careful to evaluate the functionality of the open source offering to ensure that it is capable of doing all you require.

Testing, Self-Certification and Verification

When you develop a WITS product as a member of WITS, the WITS PSAC have developed two methods by which you can have your product accepted by the broader WITS community. That means new users should consider that your product is ready for their use and Master Station vendors should consider your product as less of an integration risk. The two methods provide a different level of assurance as to how compliant your product is; they are:

Self Certification – You perform tests and provide the results to the WITS PSAC who check that they contain the right elements and, if they do, the PSAC will allow your device to be listed as Self-Certified on the WITS website.
Verification – You perform the tests with each of two Master Stations, and the Master Station vendors assist and witness the tests. Although this costs more as you will have to pay for the Master Station vendor’s services, you end up with Master Station vendor signatures confirming that your device works against their Master Stations. This can provide an additional level of confidence to users considering the use of your Field Device.

The WITS PSAC have produced a document describing the issues relating to obtaining compliance, the document is called the “Compliance Manual” and is available to members only from the “Members Library” on the WITS website. The document provides guidance for producing and maintaining WITS compliant devices and is an essential read. It contains the rules surrounding compliance, the meaning of compliance and also supporting information such as the conditions under which re-certification is necessary.

The tests performed within each of the above are generally those described in the WITS Test Specification. This is a long and comprehensive test document covering exactly what needs to be tested to show correct WITS operation. You will be hard pressed to write such a test specification at a lower cost than the document available to you from the WITS PSAC. The document is the only method used to date to demonstrate compliance of new WITS Field Devices.

The WITS PSAC perform general checking on your submission for self certification or verification. So although we may occasionally dive in and look at some of the test results, the prime aim is to check that everything in the submission hangs together. So for instance, if your device profile says you support various communications media, then we would expect to see tests for those communications media documented, or, if you say you support WITS 1.1 and WITS 1.2 then we would expect to see appropriate tests for each of these versions. Only once that checking has taken place will your submission be listed on the WITS website.

If you are attempting to go for verification then you can minimise the risk of failure by at least ensuring you can pass Self-Certification and also by buying and using the Master Stations test offerings which give you in advance, the ability to test your product against a Master Station controlled by you. Repeated failures of verification are a sure fire way to increase testing costs on your implementation. It would be better to spend your money on ensuring that you are as ready for verification testing as possible, both on your pocket and also the experience you have with the Master Station vendor.

Where no Master Station is available you will definitely need some form of DNP3 test harness, a piece of software that can act as a master and allow you to see wire-level traffic and analyse problems with your implementation. Such tools are available commercially or you could choose to write your own. Note though that there is a risk in writing your own in that your test harness works with your Field Device but you have not ensured interoperability with other DNP3 master stations due to some small oversight or misunderstanding of the specification. As such errors are normally only discovered late in the development process they can be more expensive to fix, so we suggest considering your test regime early on.

If an efficient method of automated testing is available during development this will also help in ensuring that a higher quality product is produced for a lower cost. Repeated manual testing is less rewarding and is likely to end up being more costly. Note that it is harder to add automated testing in at a later point in the development process and early consideration and integration will likely pay dividends.

User Support

If you, as a vendor, have current good relationships with a WITS user organisation, there could be positive benefits to early engagement with that user. Apart from the obvious benefit of keeping them abreast of your development process and possibly taking feedback from them of what they would particularly like to see the Field Device do, they could also help in getting access to a WITS Master Station – their WITS Master Station – for some informal testing? Off course there are no guarantees here and each relationship would have to be considered on its own merits.

MVP Approach

The Minimum Viable Product approach to development could be worth considering for your your WITS implementation if you are not setting out in direct competition with an existing unit. In this approach you would select the minimum set of WITS functions required to get your product to market in a functional state. Further development of your product could be predicated on success in the market, engagement with a user, or internal R&D plans. If nothing else, this approach reduces your development time, and hence costs, whilst also getting a product to market as early as possible.

Platform Considerations

Without a doubt, DNP3 is not the most lightweight protocol available, however it does provide the security and functionality to suit the Water Telemetry community. WITS adds elements of functionality that DNP3 does not possess, increasing the complexity and cost of implementation. In particular, WITS adds formalised logging, device configuration and alarming on top of DNP3 as laid out by the users during the requirements capture phase of the WITS protocol development.

It is important, given the nature of WITS, to consider and plan memory (program and data) usage, disk and storage requirements, and processing load. WITS can certainly be implemented successfully on small devices, as is obvious by some of the smaller devices listed in the device catalogue on line, however the implementation on smaller devices is likely to require careful selection of functions against device capabilities.

Another aspect of the design related to the hardware platform’s capabilities which should not be overlooked is the exact list of available communications channels you expect to support e.g. PSTN, GPRS/3G, ADSL/Ethernet. For each of those channels you need to also consider whether they will be dual endpoint, single endpoint incoming or single endpoint outgoing. Also consider whether those channels will be available to back each other up if one fails and how that will be implemented. All of these factors will make a difference to what you have to implement and how the device can be used.

Summary of Steps

To summarise elements of what we have discussed, the following list provides an ordered set of things to do to drive your estimation, planning, development, test and eventual sale of your WITS Field Device. The list references step numbers from the “Process for Claiming Certification” page on the WITS website for your convenience.

Join the WITS Protocol Standard Association.
[STEP 1]
Appraise yourself of the current standards information on WITS and DNP3. This may likely involve joining the organisations to get hold of the standards, although some summary information is available in the public domain.
Prepare a WITS Device Profile. This will help focus your thoughts on exactly what you are seeking to do and how it will fit into the market.
Consider the scope of what you will build and test. In particular, those aspects outside the control of the WITS Device Profile. Will you be going for the most recent version of the standard? Will you be self-certifying or verifying? These will affect your costs and implementation timescales.
Consider reuse/purchase of already available code. Using an existing DNP3 stack could save money in the long run and will reduce the risk of you implementing DNP3 incorrectly; however, there will be an upfront and ongoing cost.
Draft estimates for the costs of the overall project.
Prepare a business case. Know what you’re building, how much it will cost, and the possible returns on your investment.
Apply for a Device Manufacturer Name String. The name string populates a device attribute in Object Group 0 and is included in the protocol specification; it is further described on the WITS website at this link.
Develop. Assuming your business case is approved then you move on to development. Ensure that you have a solid design based against your device profile, an agreed approach to the use of pre-existing software and a strategy for testing prepared from the outset. Use standard project management techniques for keeping your project on track.
Internal Testing. Ensure ongoing, internal testing during the development phase so that you have confidence that the eventual product will be suitable for submission to WITS PSAC for self certification or verification.
Verification or Self-Certification. Perform the necessary testing for the method you have chosen to prove to others that your product is WITS compliant. Don’t forget to use the Compliance Manual (available to members from the WITS website) to assist you during this and the following compliance tasks. [STEP 2]
Download the relevant application form. Download either the “Self-Certified” or “Verified” application form from the WITS PSA website. [STEP3]
Fill in the application form. Complete all relevant fields in the form ready for submission to the WITS PSAC. [STEP 4]
Submission to WITS PSA. Submit the results of verification testing or self-certification to the WITS PSA to get your product listed on the WITS website. [STEP 5]
WITS PSA technical group check. The WITS PSAC technical group check the application for consistency. [STEP 6]
Application Accepted or Rejected. The WITS PSAC accepts or rejects the submission. If the submission is rejected, then you can work with the WITS PSA on the reasons for rejection and hopefully attempt to re-submit. [STEP 7]

If you do decide to implement WITS on your Field Device, don’t forget to keep the WITS PSAC informed, we are a good source of help and given that we have users on the committee and amongst our members, it can only be beneficial to get the news of your impending project delivery out to the market.

Good Luck

Authored by Mark Davison (Terzo Digital Ltd) on behalf of the WITS committee.

October 2015.