Chapter 4. Software

Table of Contents
Java
HPUX to DEC Unix
RTAP
FIX DMACS
GEFICS SCADA
Wonderware
SCADA and the Web

Java

java_in_scada

Thu, 13 Mar 1997 09:06:04 -0500

Hello ! My name is SAARATHY, i believe that most of the people in this group might have heard about java. could someone tell me how to utilise the power of JAVA for SCADA software development. Thank You

     saradhi@cse.bridgeport.edu
    

Re: java_in_scada

Thu, 13 Mar 1997 19:36:15 +0000

Hello SAARATHY The Attraction of Java is it's portability between different operating systems and platforms. The big problem up till now has been the fact that VirtualJava implements java programs by interpreting bytecodes stored in class files. This causes a severe speed degradation when compared to compiled programs. Two factors will assist in solving this problem. Firstly, Just in Time compilers are being developed and released allowing compilation of Java code. Secondly and perharps more importantly is JavaOS an operating system being developed for Java by Sun along with a range of microprocessors optimised for JavaOS. I think there is scope for using Java, but only when speed improvements allow.

       -- 
 James Winters
 jwinters@innotts.co.uk
 http://innotts.co.uk/~jwinters/
 +44 (0)1623 459576
      

Re: java_in_scada

Fri, 14 Mar 1997 07:09:57 +0000

A lot of the information available on JavaOS is still very sketchy, but it does seem set to grab a large chunk of the embedded controller market, so anyone involved in real time and/or embedded controller development needs to keep abreast with the technology. Hope this has answered your questions. James Winters

Re: java_in_scada

Mon, 17 Mar 1997 08:39:57 +0800 (SGT)

I was considering using a browser to be the MMI and Java applets to gather and display realtime data from the http server. Then you will get a SCADA system which runs over the Internet. The advantage of this system is software change distribution. If the data points and the MMI changes, you only need to change the http server. All browsers will get the update automatically.

       Ming-Ching
      

Re: java_in_scada

Mon, 17 Mar 97 08:42:15 -0800

It comes with a set of applets, so there is no Java programming required. It is available and shipping today. For more information see http:\\www.coactive.com Go to "Other Resources" - "FTP Site" - "Other" - "WebIO" for data sheets or contact me. David.

      ---
 David Gaw   (dgaw@coactive.com)
 Coactive Aesthetics, Inc.
 "Advanced Solutions for Distributed Control"
 4000 Bridgeway, Suite 303 Sausalito, CA 94965
 voice:(415)289-1727  fax:(415)289-1320
 http://www.coactive.com
      

Re: java_in_scada

Mon, 17 Mar 1997 12:28:28 +0800

We have similar vision. A lot of our users want real-time SCADA/EMS data. Satisfying all these requests would result in heavily loading the SCADA/EMS system. We have already a database repository system (DRS) that replicates all the real-time data. It allows PC users to query the DRS data base using a normal web browser. Thus, everyone on the Corporate intranet is able to get his data. Currently, we only support simple query on the historical data of one database point. We intend to add graphic representation using Java. This way, we could provide a simple poor-man's trending package without buying everyone a full-featured trending software. Regards

       Stephen Kwok
 China Light  Power Co Ltd
 email: skwok@sclpinet.clp.com.hk
 phone: (852) 2678-2361
 fax: (852) 2654-9823
 
 ----------
      

Re: java_in_scada

Mon, 17 Mar 1997 10:01:25 +0000

The problem for me is not (real-time) database access with JAVA, JDBC does that. The problem is data acquisition with SCADA. Those functions that require low level programming will be much more dificult do implement since you don't have any standard (or class) for some things like interfacing a I/O port. If you have all your SCADA network on TCP/IP SCADA is really a major advantage, but if you don't!!!!!!!!! Nuno

 -------------------------------------------------------------------
 |   Da Madeira em Directo...             Live From Madeira...     |
 -------------------------------------------------------------------
 |               Nuno Jardim Nunes - Computer Science Unit         |
 |                   University of Madeira - Portugal              |
 -------------------------------------------------------------------
 | Address: Largo do Municipio, 9000 - Funchal - Portugal          |
 | Contact: Voice:351-(0)91-222417 ext. 213, Fax:351-(0)91-225111  |
 | e-mail : dnnunes@dragoeiro.uma.pt                               |
 | URL    : http://www.uma.pt/dnnunes/nuno.html                    |
 -------------------------------------------------------------------

Ref: c:\scada\031997\msg00013.xml

java_in_scada

Mon, 17 Mar 1997 09:27:58 -0500 (EST)

Hello, this is SAARATHY again during this week i talked with couple of professors and listening to all the intelligent talk in this group, after all this i would like to propose liek this 1. RTU : Will not only do all the functions which it could perform today but will behave like a HTTP server. All the grapchis and database related with this RTU will be stored on the RTU, so that any user who can access this RTU ( either in internet or intranet ) could check and see what is going on at that RTU location, using a web-browser. 2.RTU SOFTWARE : i think it is not necessary that we should develop the software in JAVA, then it becomes re-inventing the wheel, instead if we could make the existing software CORBA-IDL ( Common Obejct Request Broker Agent-Interface Definition Language ) complaint, then we can even use this software ( Objects ) over a network, using JAVA. -------- Saarathy

Re: java_in_scada

Tue, 18 Mar 1997 08:26:17 +0800 (SGT)

Why do you have to do Java serial I/O ? Serial I/O should not be done on your browser. It won't work and it is a bad design. That should be done on the web-server. You could still do you SCADA serial I/O in C or whatever usual stuff you have and feed the data to the database. Then the Java applet will talk TCP/IP to get the data from the database. Ming-Ching

Re: java_in_scada

Tue, 18 Mar 1997 19:35:41 +0000

That's not the point I was trying to focus. I was trying to focus on full java development for a SCADA system, not just deploying data on the Web. That can be done will almost all the RDBMS in the market, regardless of the application you are talking about. The point for me is can JAVA replace the "standard" languages and development system for SCADA systems. I was thinking of JAVA based RTUs, JAVA based MTUs, and communication protocols over standard TCP/IP. Imagine small (cheap :-)) PICOJava architectures running JAVA code for RTUs, and a JAVA OS with MTU code deploying data and control for clients over TCP/IP, the clients could then run some HTTP Browser anywhere in the world and access (or control) the SCADA system. Regards Nuno

RE: java_in_scada

Mon, 17 Mar 1997 10:33:13 -0300

No Message

Re: java_in_scada

Tue, 18 Mar 1997 19:04:00 -0700

I like what you are talking about, from a theoretical point of view. In the absence of any constraints, it sounds great. However, I have found that most SCADA systems have to deal with constraints. Some of these include:

- challenges in use of TCP/IP, due to:

- limited bandwidth comms

- multi-drop circuits, radio cells

- smallest possible RTUs (to keep costs down), meaning

- limited cpu size

- limited memory space

- low power budget

- limitations of existing installed RTU base

- limitations of existing host system

- challenges in doing time-critical processing in Java, such as

- ladder logic

- PID loop control

- timing constraints in overall system performance/responsiveness/reliability

- degree of determinism required in operations

- product availability and support

- development and support tools, and expertise Clearly the more constraints you have, and the tighter they limit you, the closer to the metal you'll have to work. Java makes the metal invisible, so it may not be a good fit...

                              ////////////////////////////////////////
                             ///  R. Murray Reid   (403) 541-4787 ///
                            ///       murray.reid@pipe.nova.ca   ///
                           ////////////////////////////////////////
      

Re: java_in_scada

Wed, 19 Mar 1997 07:31:30 +0000

R. Murray Reid wrote: TCP/IP has more than enough bandwidth to deal with Scada networks and copes with multi drops. Nothing much has been developed for radio cells as there hasn't been a percieved need. That may change. The new Java optimized CPU's from Sun are incredibly small, compact and seriously fast. They are extremely power efficient and can be clocked back to reduce power requirements even more. This is a stumbling block of sorts, but in this industry that has never stopped advances from being utilised.. There is a popular misconception that you need powerful complex systems to run Java. Java is designed as a true multi platform language and can be ported to most existing systems. This is where Java really shines. It is a multithreading environment where many concurrent tasks can run and where error handling is far better than most languages in use today. The performance in real time systems is blisteringly fast. The product is fairly new and expertise and support are not widely available at the moment, but they will become more widespread. I appreciate that many people do not see a role for Java in the Scada and RTU market, but I see Java as a programming environment made for Scada. It is multi platform. It is being ported to silicon. It is extremely good at concurrent tasks and multi threading. Exception handling is excellent. Security features are excellent. Many people still assume Java is some sort of language for programming nifty animations on the net. It is in fact a very robust and powerful development tool. Regards

       James Winters
 jwinters@innotts.co.uk
 http://innotts.co.uk/~jwinters/
 +44 (0)1623 459576
      

Re: java_in_scada

Wed, 19 Mar 1997 13:30:19 +0800 (SGT)

Me too. I love Java as a better C++, the portability, smallness etc. But there are quite lot of other considerations that me stop me from investing on using Java this way. And I am quite doubtful about it being cheaper. God knows after you have invested so much in Java, so successful with Java, Sun decided to raise the licensing fees a few hundred percent. Ming-Ching

RE: java_in_scada

Wed, 19 Mar 1997 15:25:25 +1000

Murray Reid's comments about Java hit the nail on the head. Many SCADA systems have to cope with legacy hardware and software, a mis-mash of proprietary protocols and communications mediums. My question is: What is the advantage of using Java? There is a lot of hype about Java and it was originally designed for Embedded systems but what advantages would it really provide when implementing a SCADA system. I would guess most code for RTUs is written in ANSI C, which is portable. The diverse range of hardware platforms and RTU vendors means that the main two interfaces to the RTU are all different - i.e. the interface to the RTU's I/O and the serial ports. And no RTU vendors are about to provide applications and/or source to other RTU vendors for either their protocol libraries or their automation routines. Sure you can write the protocol emulation in Java, but why not write them in C or C++. Being able to download applets for automation functions could be quite useful, but as Murry meantions performance issues are a problem. Also it requires that the engineer implementing the routines can program in Java. Best regards Paul Whitfield

RE: java_in_scada

Wed, 19 Mar 1997 10:30:42 +0000

Aend my conclusion is: What about SCADA! It's just another problem to solve. I found nothing that important in the SCADA field. At least nothing that wouldn't benefit from using standard technics on software engineering. What I found was that the SCADA field is somehow hermetic, people don't share experience they don't cooperate, there's a lot of money involved and it's not going as fast as one would expect. As an example I've asked a dozen of companies for proprietary SCADA protocol information and none answered. That leads us again to money, you will solve that problem when vendors find out that reusable software components (patterns) will lead you to much more stable faster and cheaper products. As for ANSI C portability, you can ask anyone that uses, or used C, for some time. Portability!!!!!!!!! Why not in JAVA, you have real portability, native support for multitasking, object oriented paradigm, garbage collection (wich is the no 1 reason for C and C++ bugs), etc, etc... Performance is allways a problem, but the silicon industry answers that problem faster than you can develop your programs. I go back to the beginning of my message: the problem is can you keep up with silicon, can you develop faster, can you use all the power silicon drives or do you keep spending lot's of time debugging your programs and reinventing the wheel. I think JAVA will be a major leap in the computer industry, at least if Microsoft let's them go ahead :-)... Regards Nuno

RE: java_in_scada

Wed, 19 Mar 1997 21:12:19 +0800 (SGT)

Bend, most reliable tool is Java SDK, which is a command line tool. (d) GUI objects in Java are not sophisticated enough yet. (e) Other limitations which I haven't compile them here. Ming-Ching.

RE: java_in_scada

Wed, 19 Mar 1997 15:54:27 +0000

Hello Ming-Ghing, I also not interested in that kind of discussion, but it's clearly a subject worth discussing even if JAVA will enter the SCADA world a couple of years from now. Wich again are not exclusive to the SCADA area, that was the point I was trying to explain. Of corse JAVA will not change this but it will change the way you can buy components from various vendors and put them together. Various authors, namely those working on Patterns, have discussed these issues and a platform independent language, using the Object Oriented paradigm with automatic memory managment features is a great push for code reuse in any area not just SCADA. I generally agree with those points, that leads us to the beginning of the discussion: Can SCADA benefit from large scale JAVA use? My answer will have to be YES. And then I'll have to agree with you: it's still some steps away from getting there. The problems for me are: are SCADA developers really interested in using JAVA (and other OO related technologies), will they want to keep up with never-ending standard processes or worst with their onwn proprietary components? if they don't who will push JAVA in that direction (actually JAVA's original direction)? Perhaps consumer electronics vendors... I'm really quite happy with this discussion, I'm trying to develop these concepts in my thesis and nothing better than discussing a subject to able to understand it on several view-points. Regards

      Nuno J. Nunes
 
 -------------------------------------------------------------------
 |   Da Madeira em Directo...             Live From Madeira...     |
 -------------------------------------------------------------------
 |               Nuno Jardim Nunes - Computer Science Unit         |
 |                   University of Madeira - Portugal              |
 -------------------------------------------------------------------
 | Address: Largo do Municipio, 9000 - Funchal - Portugal          |
 | Contact: Voice:351-(0)91-222417 ext. 213, Fax:351-(0)91-225111  |
 | e-mail : dnnunes@dragoeiro.uma.pt                               |
 | URL    : http://www.uma.pt/dnnunes/nuno.html                    |
 -------------------------------------------------------------------
      

RE: java_in_scada

Wed, 19 Mar 1997 12:55:23 -0500

We are in a dynamic and competitive industry. Java holds promise to radically reduce the effort (=man-hours = $$) to develop and maintain SCADA software. Any one who maintains a large C or C++ application knows about the cost of software development on multiple platforms and the bugs introduced through stuff like pointers. Java has the potential to support reusable components, multiple platforms and reasonably bug free code. If Java fulfills 50% of its promise, those vendors left behind will eventually be caught in the quick-sand of their own legacy code. The vendor or vendors that dive right in to Java at the beginning will reap the benefits (market share, promise) when Java comes to age.

      Andrew 
 ----------------------------------------------------------------------
 Andrew H. Kooiman P.Eng.  Hamilton, Ontario, Canada   akooiman@hookup.net
 A. H. Kooiman Engineering Inc.                        (905) 524-0218   
 Automation for the Energy Industry
 
 Warning - Contents may have spelling mistakes introduced during shipment.
      

RE: java_in_scada

Thu, 20 Mar 1997 10:53:42 +1000

Not only do vendors not make protocol information. When it is available the information is quite often incomplete. This is an industry that has only recently even begun to standardise the protocols it uses. Which benefits the users not the vendors. Proprietary protocols and software are part of each vendors product range and at this stage I think it is unlikely for any vendor to give away part of their advantage. I am a software engineer with 10 years experience writing C and C++. Written correctly C is highly portable. The underlying Real Time Operating system and Hardware interfaces are not standard and this is a problem whatever language you use. These are valid points, but Java has its dis-advantages as well. I am not about to get into a flame war about computer languages here. I certainly agree that a object oriented paradigm could be very useful in development for SCADA software. Having personally written several protocol emulations I would love to have been able to have developed a object framework that allowed me to re-use my code more efficiently. The central problem of SCADA software development is that vendors will not standardise unless the is a compelling reason for them to and that we all have to live with the huge base of installed systems based on old hardware and software. Best regards

       Paul Whitfield
 pwhitfield@skm.com.au
      

RE: java_in_scada

Thu, 20 Mar 1997 13:10:54 +0200

Take a look at WizNet - I believe it is a good example of SCADA in Java. The Kernel is written in C and all the user interface part is written in Java. When a user with a web browser access the WizNet SCADA site it receives an HTML page with embedded Java applets - those Java applets show alerts or drawing of the process. User can operate on alerts or on the drawing as in normal SCADA. Using Java enables to use the SCADA application from any computer in the organization with a Java enabled browser (unix,mac, win3.11...) One of the interesting advantages of such HTML based systems is the ease to integrate information from other systems into the same user interface - you can create an HTML page showing a graphic presentation of a process with other data coming from any other source. http://www.pcsoft.co.il/wiznet.htm

      Noam Sadot.
 WizNet Project Leader.
 PC Soft International Ltd.
      

RE: java_in_scada

Thu, 20 Mar 1997 09:03:55 -0500

I believe the component technology you are alluding to is already supported by the JavaBeans support in Java 1.1, with the distributed aspects being supported by either the Remote Method Invocation (RMI) capability built into Java 1.1 or by using something like IIOP (Internet inter-ORB Protocol). Documentation for Java 1.1 can be found at http://www.javasoft.com and IIOP at http://www.visigenic.com

       Stephen Shelley
 (Intec Controls Corp)
      

Re: java_in_scada

Sun, 23 Mar 1997 07:41:07 +0800

At 07:31 19-03-97 +0000, you wrote: Are they as "small" as a us$3 motorola 6811 or Zilog Z180 or Intel 8051? Don't forget the economics of manufacturing - yes, in "integrator" can take $1000 of material and sell it for $1500 because they also charge for "engineering" services, support, commissioning, etc, etc. But a real manufactur needs much higher margins to cover the considerable expenses involved. I don't know the "cost" of a Sun Java CPU, but assuming it is anything like a Pentium or Spark or Alpha, how will the price of RTU's change if you pull out the $3 CPU and put in a $300 CPU? I can promise you the price cannot just go up $297. Best Regards;

 Lynn August Linse, linsela@robustdc.com
 Robust DataComm Pte Ltd, 30A Hillview Terrace #02-00
 Singapore 669247, Ph(65)764-2791  Fx(65)764-2740
 http://www.robustdc.com
 http://www.singnet.com.sg/~linsela
      

Ref: c:\scada\031997\msg00014.xml

SCADA w/JAVA

Tue, 17 Jun 1997 13:52:53 -0400

I have read many replies concerning SCADA and the internet using JAVA as a tool to do so. Although this is probably the wrong place for this discussion, I'll start it anyway. *smile* I thought JAVA was designed to be cross platform. Therfore, to access hardare, especially using the serial port of a PC would defeat the sole intention of JAVA. Assuming the JAVA/SCADA applet must access hardware of course. Tim Higgins

RE: SCADA w/JAVA

Wed, 18 Jun 1997 09:37:31 +0800

Well, defeat a MAJOR intention perhaps. There are still other benefits such as integration with existing standard tools, and "automatic" distribution of new software versions. Both of these lead to reduced administration costs. I tend to assume the reverse! The place I'd particularly like to see Java used is in the "MMI" part of a SCADA package. So it would consist of Java applets that do all of the user interface stuff and communicate via sockets back to the Servers of the SCADA system - the Application or I/O servers for example. These applets would be cross-platform.

Steve Kinsman
 (steve@comsys.com.au)
 Control Innovation Pty Ltd
 PO Box 687 Nedlands WA 6009 Australia
 Tel: + 61 411 518 419, Fax: + 61 8 9386 8418
 

Ref: c:\scada\061997\msg00024.xml