Device Drivers Development

To add support of a new device type to Rapid SCADA you need to develop the device driver. In terms of Rapid SCADA driver is called a device library or device DLL. SCADA-Communicator application dynamically links up the developed library and performs querying devices and sending telecontrol commands.

To develop a device library Microsoft Visual Studio 2010 or higher is required. Also ScadaCommCommon.dll, ScadaData.dll and Log.dll libraries are needed. These libraries contain the base functionality. The actual versions of the libraries are located in the installation directory of Rapid SCADA.

The general sequence of developing a device library:

  1. Start Visual Studio and create a new project of Class Library type. Use .NET Framework 4 for the project.
  2. Add project references to ScadaCommCommon.dll, ScadaData.dll and Log.dll.
  3. Create a class inherited from Scada.Comm.Devices.KPView. This class implements a user interface of the library.
  4. Create a class inherited from Scada.Comm.Devices.KPLogic. This class implements logic of communication with devices.
  5. Build the project and copy the created DLL in the device library directory of SCADA-Communicator. Its default location is C:\SCADA\ScadaComm\KP
  6. Restart SCADA-Communicator graphical shell to make the DLL visible for the application.
  7. Debug the library by using SCADA-Communicator logs or with help of Visual Studio remote debugger.

A project and classes must follow the naming rules:

  1. A filename of a device DLL have to use Kp prefix. For instance, KpTest.dll.
  2. The required namespace of classes inherited from KPView and KPLogic is Scada.Comm.Devices.
  3. The required formats of class names inherited from KPView and KPLogic are KpTestView and KpTestLogic, respectively, where KpTest is the name of the device DLL.
  4. The class names are case sensitive.

The example of a device library development is KpTest project which is included in OpenKPs solution. This solution is accessible on GitHub here. Learn KpTest and other projects of OpenKPs and use them as templates to create your own device drivers.

Implementation of User Interface Class

The simplest example of the class inherited from KPView:

The required thing to do when you implement the class is overriding KPDescr property which returns a description of a device library displayed in SCADA-Communicator.

The additional features that can be used during the implementation of a device library user interface:

  • Override DefaultCnls property to define descriptions of the channels which are used by Creating channels feature of SCADA-Administrator.
  • Override DefaultReqParams property to set the default device request parameters which are used by SCADA-Communicator.
  • ShowProps method can be overridden to provide displaying the device library properties form in SCADA-Communicator.

The examples of implementing these features can be found in KpModbus and KpSms projects of OpenKPs solution in KpModbusView and KpSmsView classes respectively.

Implementation of Operation Logic Class

To implement the logic of communication between a server and devices you need to create a class inherited from KPLogic. KPLogic class contains a number of useful properties and methods needed to developers. The primary of these class members are described below. To better understand how device libraries are constructed and to use all the features of Rapid SCADA it is recommended to learn the source code of KPLogic class and the source code of the libraries included in OpenKPs solution.

Constructor of the created class must contain an integer argument named number which is used to pass the device number from the configuration database. In the most cases a constructor initializes device tags which are the instances of KPTag class. The tags can be divided into groups of TagGroup class.

The following example demonstrates the implementation of the constructor:

KPLogic class contains a number of virtual methods which can be overridden in the custom class to implement the new driver algorithm. These virtual methods are described in the table:

Virtual Method Name Description
Session Performs device request session
SendCmd Sends a telecontrol command
ProcIncomingReq Processes already read an incoming request
ProcUnreadIncomingReq Processes unread an incoming request
OnAddedToCommLine Performs actions after adding the device object instance to a communication line
OnCommLineStart Performs actions on a communication line start
OnCommLineTerminate Performs actions on a communication line termination
OnCommLineAbort Performs actions on a communication line abort
OnConnectionSet Performs actions on a connection set
BindTag Binds a device tag to an input channel of the configuration database
CheckBehaviorSupport Check the behavior support of a connection channel
InvalidateCurData Set the current device data as undefined
GetInfo Gets information about the device operation
ConvertTagDataToStr Converts tag data to a string

Most often it is sufficient to override only the methods Session and SendCmd those implement communication session and sending command, respectively. Overriding a method it is possible to invoke a method of the base class in order to reuse the existing logic as shown in the example:

KP.dll includes KPUtils class which contains auxiliary methods. Also pay attention to the useful class ScadaUtils from ScadaData.dll library. Using of these classes reduces development efforts and allows applying a unified approach for creating a variety of software modules.

Tags: ,