There’s an informal definition for Legacy Software that comes up time to time that cuts to the core of the matter: Legacy software is software that actually works. Its been installed, deployed and run against real world situations. As such its a major decision to rewrite any substantial item of legacy software and should typically be resisted. Regardless, there are many situations where doing a rewrite is the best long term decision to make.

Sentient Computing and Torq had to make a rewrite or maintain decision with respect to the mqe driver back in 2004. The mqe driver is an abbreviation for the Modbus Quantum Ethernet driver. It is a MacroView communications driver that implements the Modbus Ethernet TCP protocol. We ended up taking the rewrite route and developed the modbusdrv communications driver. This same technology was then used to develop a Modbus Server implementation for MacroView and some internal Modbus protocol based utilities.

Many of the MacroView installed sites have moved to using the newer modbusdrv communications driver since it was first developed in 2004. Regardless many sites still run the mqe driver which was originally developed in 1996. Recently there was a need to identify the advantages of upgrading to the modbusdrv driver when the mqe had been operating at a site for many years. The question came up because ostensibly there is little functionality difference between the two. From a maintenance perspective, we much prefer the modbusdrv implementation as the source code and internal structure is much cleaner and better organized. So bottom line, the functionality difference is that modbusdrv a better quality communications driver. This translates directly to customer cost savings when any support is needed.

Its interesting that Wikipedia actually has a dedicated page for the word Rewrite with respect to programming. In that article various web pages are referenced with strong opinions on the subject. Its an emotional issue for developers because the cost of a rewrite is significant. There is a preconception that developers will lean towards rewriting software instead of extending it. It is often attributed to a variation of the Not Invented Here syndrome. The Wikipedia article lists the following possible reasons for a software rewrite:

  1. When the source code to be able to extend an existing program is not available.
  2. When the source code is available under an incompatible license.
  3. When the code cannot be adapted to a new target platform.
  4. When the existing code has become too difficult to handle and extend.
  5. When the task of debugging the existing code seems too complicated.
  6. When the programmer finds it difficult to understand the source code.

The last three were the reasons behind effectively rewriting the mqe driver and developing a new from scratch Modbus TCP driver which we called modbusdrv. The approach taken was to implement portions of the mqe functionality as needed on a project by project basis. It was impractical to attempt a total replacement in one go. We added functionality to the modbusdrv implementation over the years such that now they are now on par in terms of functionality. The rewrite was definitely the right decision as the result is that we have a Modbus driver implementation and technology base that is much easier to maintain and extend. Aspects of the modbusdrv implementation and its advantages over the mqe implementation are summarized in the remainder of this blog post.

Leveraging Common Libraries

The modbusdrv implementation leverages a series of common MacroView libraries that Sentient and Torq have developed since taking over the ongoing MacroView maintenance and development. The mqe driver has its own driver specific Modbus protocol and socket communications code. The advantage of using common libraries include:

  • Issues are resolved for multiple applications when they’re resolved in the common libraries
  • Services based on these core libraries can be applied to multiple applications without the need for additional application specific code.
  • Developers don’t have to learn how a particular driver implements a particular aspect of its functionality as there is a common mechanism.
Serialization Library

Newer MacroView drivers and communication utilities leverage the same core Serialization framework. It’s the same serialization library used in drivers such as the Allen Bradley PCCC driver, Simatic 505 driver, Symax ethernet driver, the Modbus server implementation and the MacroView metaserver infrastructure. In all of these implementations, communication messages are modelled as objects. This approach separates out the data structures from the protocol implementations. It makes it easier to add support for additional packet types and Modbus communication layer variations as needed. Note that the diagram below has only the fields of the classes displayed and excludes the class functions to highlight the data structure.

Modbus Protocol Library

A standalone Modbus protocol library was developed and that is used by multiple applications (the driver itself, the Modbus Server application and a general Modbus utility). The protocol library is session type agnostic in its design and currently supports either serial communications or Ethernet TCP scenarios using the same code base.

Debug Logging Library

The debugging and logging options for the modbusdrv driver use a standard MacroView library and leverage the Serialization debugging functionality to provide clear debug logs that show the packet structures in an organized manner. The detailed debug log shows a Modbus request-reply interaction and the associated serialization and deserialization activities. Each structural layer of an object serialization is indented so that the structure of a packet can easily be seen.

Modbus Driver Debug Log

Automated Testing

The modbusdrv development included automated unit tests and integration tests. The integration tests can be run against either a physical PLC or a Modbus simulator.

Unit Testing

Within MacroView application programs that we’ve developed, the unit tests are compiled into the Debug versions of executables and can be run with a –test command line option. It is based a unit testing framework built to work with the MacroView C++ classes but inspired by the xUnit family of unit testing frameworks. The following screen cast shows a run of the modbusdrv unit tests. These are all in-memory tests designed to executable quickly and provide developers with rapid feedback of whether any functionality modifications have adversely affected existing functionality.

Integration Testing

The modbusdrv integration tests are script based and exercises the drivers interaction with a Modbus device through a series of get/set actions with confirmation tests run during the test cycle. Both the unit tests and the integration tests are also run within a Purify session to identify and resolve any memory issues.