SUMMARY:
Serguei, Laza and Kurtis have met and discussed how to go about implementing the custom software (CSW) interfaces which will be necessary to connect the various special calibration and monitoring devices that are being designed, to the SCADA system in an efficient manner. Our conclusions are presented in detail below.The short form of our conclusions is that due to scarcity of software expertise and the desirability of encapsulating the specialised knowledge necessary to operate and maintain these devices, there are two recommendations we should follow.
- There is a particular software structure we should utilise when creating the CSW, explained below, and...
- We should invest significantly in software productivity tools.
We will be integrating a number of very specialised, one-of-a-kind instruments into the HCAL SCADA system. Each such object requires specialised knowledge to create the software interface to the external world. Once finished, we would like to be in the position of never having to change the CSW during the lifetime of the experiment, estimated to be a decade at least.
On such a timescale, one must reckon with the possibility that the people who developed the CSW will "move on" in one way or another. For example, at least two of the active participants in the construction of the laser monitor system have said they will be retiring or leaving the field in the next few years. When the expertise has disappeared, re-writing the CSW for this device will require someone to dig into the hardware details "from scratch".
Although we cannot prevent this from occurring, we can ameliorate the effects of natural attrition through well-considered software design. Another foreseeable eventuality is the certainty of "upgrades" in the SCADA software. Unless we take care to design the CSW properly, we could find ourselves in the difficult situation of having to actively maintain compliance with PVSS releases (constant re-writing of the, say, source scanner CSW to remain compliant with release N.xyz of PVSS will place a heavy and constant drain on our available software manpower).
From this we derive a major requirement:
==> the CSW must be shielded against external software changes. Therefore the Client/Server architecture must be used. Typically SCADA is the client and the CSW acts as a server; the C/S architecture decouples driver and SCADA software and allows to increase the level of software modularity.
A second requirement is quite obvious. Since we are severely manpower limited we must take the necessary decisions, e.g. adjust our funding priorities, to be as productive as possible:
==> we will have to spend money on software productivity tools.
There are two standard methods of communicating with PVSS: a device driver and an API manager.
Typically a device driver (being a part of the PVSS) could be obtained from the PVSS manufacturer. It is also possible to design your own driver using PVSS driver design toolkit. At the present moment one of most widely used driver standards is the OPC (OLE for Process Control) server based on the COM/DCOM protocol (Windows NT and 2000 only). Now it has become the industrial standard and typically 90% of the industrial equipment has appropriate OPC server. It should be noticed that the design and maintenance of OPC servers is quite difficult. We will just mention that OPC is an industrial strength interface standard running under Windows which is not relevant to this discussion now.
The Application Program Interface manager comprises a utility library and a set of standard methods which are a part of PVSS. Typically, one part of the API manager resides "close" to PVSS and the other runs on the application host machine. For example, the computer driving the source scanner would run part of the API (which would actually "call" the source driver software) and the rest of the API would run on the PVSS host. The source driver CSW is embedded in the API; "upgrades" to the API will inevitably require "upgrades" to the CSW in such a design.
Writing code for the API manager requires a non-trivial upfront investment in time and effort by a programmer, as the API manager class given by ETM recently made vivid. A standard method of finessing such a situation, is to introduce a second, simplified, user created interface which communicates with the API manager. The application - source scanner, laser monitor, etc. - communicates with the second interface only. Changes required by the API can now be complied with by altering only this second interface. The CSW can remain unaltered. It is clear that having to maintain only one object rather than every piece of software is a great advantage.
Creating such an interface which complies with the API requirements and is at the same time general enough to be used by all our CSW's is not easy. Fortunately then, it has already been done for us. It is called DIM. Even better, the job of keeping the DIM client in compliance with PVSS new releases will be taken by IT/CO, so we do not have to worry about that, either.
Using standard terminology, we suggest that a client/server architecture with a DIM client being a part of the API manager and a DIM server resident at the CSW is the appropriate structure for our applications.
We note that DIM runs under both WinNT and Linux.
We think that the selection of the set of the DIM items should be done in two steps:
Step one: the CSW designer presents to the DCS experts the list of items needed to control a subsystem or a device. These items include both the set of command items to be sent to a device/subsystem and the set of status items to be published by the device/subsystem.
Step two: if needed, the DCS expert adds extra items required by the DCS. For example for debugging purposes it would be very useful to have an item such as "Last_Sent_Command".
The commands to a device/subsystem very likely should contain the source (program name) of the command. The CSW designer from the very beginning should accept the possibility that a command could contain at least two parts (the command itself and the source) separated by some delimiter.
Debugging or/and diagnostics tools must be provided by the CSW developer. These tools could be attached to the CSW directly or via DIM. In the first case some extra monitoring tools connecting to the CSW DIM interface should be provided. These tools are needed to check the correct performance of a whole command or status chain in the CSW.
First, we state a few "self evident's".
In Serguei's experience, using Borland's DELPHI has been a factor of 3 to 5 more efficient than MS/C++ Developer's Studio. Very recently, Borland introduced a new product, KYLIX, an OO Pascal based RAD tool (Rapid Application Development) running under Linux, in fact, the only RAD tool for Linux to date. Such tools are optimised for productivity and utilise the object methodology intensively. As an example, under DELPHI/KYLIX, DIM could be implemented as a standard visual component, allowing a client or server to be built using drag and drop!
Another very important feature of KYLIX is that it supports the most popular data bases like ORACLE, DB2, MySQL etc. so the Linux programmer could get very simple access to these databases.
These productivity enhancement tools are not cheap, running about 1 to 2 K$ each, but are an excellent investment. Under the assumption that Serguei exaggerated wildly and is only 10% right, then a 10K$ investment in RAD software spread out over the three of us nets one additional programmer of productivity ( 3 people X 30% to 50% prod. increase ).
A programmer for 10K$? - that's cheap!