qscada-developers

[Qscada-developers] Future plans

[Jovan K. <cho...@gm...>]

Hi people,

how are you? how are the things going?

I'm planing to start writing the "Architecture Document (ADD)"
Based on the past discussions I think the architecture shoud be:

Client:

1. Field Management data acquisition, diagnostics of the machines
involved in the process
   (parameters, state), state of the raw material used in the production process

2. Process Management and Visualization   (This would be the part for
process engineerers and techincians)
2.a. HMI for the process
2.b. Trends
2.c. Alarms
2.d. Reports
2.e. Commands

3. Bussines management - observation and control of financial aspects
of the production process (income, expences, maintenance cost etc.)


Server:

1. The server process/deamon
1.a. informing the clients about a change of value of any subscribed
process point
1.b. Process point management (client subscribtions, grouping of
process points etc.)
1.c. System configuration (Process Picture configuration, users and
user groups, available field devices, drivers for  etc.)
1.d. Preprocessing the acquired data from the field devices
(formatting, timestamping etc)
1.e. Database Logging (every event and value changes will be logged
into a database)
1.f. Web server interface for web based clients (PHP + AJAX)
1.g. Field device plugin interface (interface for upper layers of the
server with the real physical devices)
1.h Field Device drivers (plugin based) - drivers (rs232, rs485,
modbus canbus) reasponsible for reading and writing to the physical
devices and informing the server if some process point changed it's
value, communication line diagnostics etc.

2. Administration tool/aplication (toll which will be on top of the
server used for editing configuration of all properties of the system)
      2.a. Console based
      3.b  GUI based



Simulator:

Console and GUI based application that will be on top of a dummy field
device driver. It will be a sort of virtual device used for testing
the SCADA system, changing the values of the process points, states of
the devices/machines. The GUI version should be configurable so that
the values can be changed by pressing buttons, sliders, textboxes and
other simmilar gui widgets.

What do you think about it?
I hope I'll finish it in 2-3 weeks maybe sooner.

I need help on the OS part. Which distribution, what kind of
configuration, security issues...


As we agreed we need a demo application.
What kind of process do you think would be
the most appropriate?

There is one more thing, one of the forums
for qt programming QtCentre started a programming
contest for Qt apps. It started on 5th of Jan and it will
last till 31st of May. What do you think, should we take
our chaces? The prizes are good and it maight be a good
motivation ;)
The link is: http://contest.qtcentre.org/


BEST REGARDS, Jovan
-- 
Advice for software developers and horse racing enthusiasts: Avoid hacks

Re: [Qscada-developers] Future plans

[wireless <wir...@ta...>]

Jovan Kostovski wrote:
> Hi people,
> 
> how are you? how are the things going?

Well, if you recall my last email, I had 10-20 per week available.
RIGHT after that, I got slammed with work. As a consultant, I have
to work the hours when they become available. I will have time, in
a few weeks/months, but, not really any way to predict when. That
said, what you have proposed looks reasonable to me. If you
parse the previous emails, you can see my primary concerns and
suggests, I shall list them below, but, my belief is that at this
point we should all defer to those with time to make most decisions
and get the ball rolling. My chief client only gives me so many
billing hours per year and now is when they have decide to use
those hours....


Primary suggestions:

ARCHITECTURE:
Keep the arch so that a pc running linux, a PLC, or an embedded linux
target can all be used with Qscada.

PROTOCOLS:
I've been working on a ModbusTCP driver, modified for linux. Any
sources or code snippets are most welcome. At the present time,
I'm working to put implement this driver on a MicroChip PIC 18F
processor with a custom (minimalistic) stack. This has been
temporarily shelved for now, until, I drop below 60 hours per week
on my workload.
DNP3 ?

DATABASE:
Keep it open so that Mysql or Postgresql can be used. MySql may be
the easiest, default for now.

ACCOUNTING:
SQL Ledger is a wonderful application to use with QScada
http://www.sql-ledger.org/

APPLICATIONS (DEMO):

I have a well, where we draw drinking water. It has 2 pumps
(one submersible)  for filling the 200 gal water tank  another
pump for pressurizing the house potable water.
Also pressure (analog reading) tank level and 5 24 VDC valves for
the header for the sprinkler system.

This is something very commonly found in the world and might
be a good (simple) first application. Combined with a
analysis of the raw water stream, and the appropriate filters
it could be used as a baseline, for drinking water supplies
in many place (with many disclaimers).

Also, we had the water cannon device that has been talk about
several times before, as a way to catch the eye of netizens
and interject some fun into this project..



> I'm planing to start writing the "Architecture Document (ADD)"
> Based on the past discussions I think the architecture shoud be:
> 
> Client:
> 
> 1. Field Management data acquisition, diagnostics of the machines
> involved in the process
>    (parameters, state), state of the raw material used in the production process
> 
> 2. Process Management and Visualization   (This would be the part for
> process engineerers and techincians)
> 2.a. HMI for the process
> 2.b. Trends
> 2.c. Alarms

Alarms need to have hi and low settings. Display with a default
(alarm) color if a reading is out of range. Later on we can add
email, sms, audio etc etc capabilities.

> 2.d. Reports
> 2.e. Commands
> 
> 3. Bussines management - observation and control of financial aspects
> of the production process (income, expences, maintenance cost etc.)
> 
> 
> Server:
> 
> 1. The server process/deamon
> 1.a. informing the clients about a change of value of any subscribed
> process point
> 1.b. Process point management (client subscribtions, grouping of
> process points etc.)
> 1.c. System configuration (Process Picture configuration, users and
> user groups, available field devices, drivers for  etc.)
> 1.d. Preprocessing the acquired data from the field devices
> (formatting, timestamping etc)
> 1.e. Database Logging (every event and value changes will be logged
> into a database)
> 1.f. Web server interface for web based clients (PHP + AJAX)
> 1.g. Field device plugin interface (interface for upper layers of the
> server with the real physical devices)
> 1.h Field Device drivers (plugin based) - drivers (rs232, rs485,
> modbus canbus) reasponsible for reading and writing to the physical
> devices and informing the server if some process point changed it's
> value, communication line diagnostics etc.

Don't forget we have Digital I/O and Analog (4-20 ma or 1-5vdc) I/O
from sensors to display. LEDs red/green looking graphics for DIO
is common. For Analog readings to have to 'scale the signal (for
example 4-20 ma) to a range for example the submersible pump discharge
of a well from say 0-80 psi.

Units used for display? Folk might want millibars instead of psi
for pressure, as an example. In fact we'll need a 'units conversion'
library so that folks can select the units for display with QScada.

Once we get up a minimal gui demo of Qscada, we can just keep
expanding it. As I wire up devices, I'll send schematics to someone
for inclusion in the docs.

This all looks good.

> 2. Administration tool/aplication (toll which will be on top of the
> server used for editing configuration of all properties of the system)
>       2.a. Console based
>       3.b  GUI based
> 
> 


> 
> Simulator:
> 
> Console and GUI based application that will be on top of a dummy field
> device driver. It will be a sort of virtual device used for testing
> the SCADA system, changing the values of the process points, states of
> the devices/machines. The GUI version should be configurable so that
> the values can be changed by pressing buttons, sliders, textboxes and
> other simmilar gui widgets.
> 
> What do you think about it?

Yes, and if we provide a structure where graphical icons can be added
easily, such as a pump, a valve, a guage, then many folks can
contribute artwork for the various devices.

> I hope I'll finish it in 2-3 weeks maybe sooner.
> 
> I need help on the OS part. Which distribution, what kind of
> configuration, security issues...

Gentoo provides a very rich set of turnkey solutions here.
Iain and I both are Gentoo users. Iain is quite saavy with
Gentoo. Other linux distros will be able to use Qscda, but
we both work on Gentoo. Once we have something up to show,
I intend to annouce on the Gentoo list, trolling for other
folks to join or help.

> 
> 
> As we agreed we need a demo application.
> What kind of process do you think would be
> the most appropriate?

See above.

> 
> There is one more thing, one of the forums
> for qt programming QtCentre started a programming
> contest for Qt apps. It started on 5th of Jan and it will
> last till 31st of May. What do you think, should we take
> our chaces? The prizes are good and it maight be a good
> motivation ;)
> The link is: http://contest.qtcentre.org/


This look fine to me. However, when I get some time, I have to finish
my network expansion so I have a place to put a QScada server that
is attached to actual hardware. This effort will most likely consume
most of my spare time between now and May (just a guess).


The good thing about entering this contest, is we can possibly roll
it over into  the 'summer of coding' program by google:

http://www.eclipsecon.org/2007/index.php?page=sub/&id=3829


Are we still using Eclipse as the development tool of choice
or is their something else?

I think it would be wise to make QScada a QT4 based project and not
use any QT3 resources that are not compatible. Gentoo allows both
to be installed and used with different applications.


Which linux distro do you prefer?


> BEST REGARDS, Jovan

Sorry for the disappearing act....

Your proposal looks fine. Our problem now is that you will be
alone for a while, unless Iain has some spare cpu_cycle he
can provide.


James

Re: [Qscada-developers] Future plans

[Jovan K. <cho...@gm...>]

Hi,

On 2/11/07, wireless <wir...@ta...> wrote:

 > PROTOCOLS:
> I've been working on a ModbusTCP driver, modified for linux. Any
> sources or code snippets are most welcome. At the present time,
> I'm working to put implement this driver on a MicroChip PIC 18F

here are some links that I found with a little google-ing

http://www.embeddedrelated.com/usenet/embedded/show/6969-1.php
http://www.embeddedrelated.com/usenet/embedded/show/6957-1.php

and the microchip's app note
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en011993

> DNP3 ?

Yes and some others like:
Modbus, Modbus Plus, CANBus, ProfiBus, FieldBus
Ole for Process Control XML Data Access(OPC XML-DA)
IEC 60870.5 (this is protocol similar to DNP3 which is widely used in Europe)

Basically, what we need is a good structure that will interface with the other
(upper) layers of the QScada server and in the same time will enable easy
I/O programming. That way the people will have to write only the
communication part
of the protocol, and connect some signals to some routines (that are
part of the driver)
that will give information about some parameter changes.

I was thinking maybe this field device drivers can be released under
LGPL. Any thoughts?


> APPLICATIONS (DEMO):
>
> I have a well, where we draw drinking water. It has 2 pumps
> (one submersible)  for filling the 200 gal water tank  another
> pump for pressurizing the house potable water.
> Also pressure (analog reading) tank level and 5 24 VDC valves for
> the header for the sprinkler system.
>
> This is something very commonly found in the world and might
> be a good (simple) first application. Combined with a
> analysis of the raw water stream, and the appropriate filters
> it could be used as a baseline, for drinking water supplies
> in many place (with many disclaimers).
>
> Also, we had the water cannon device that has been talk about
> several times before, as a way to catch the eye of netizens
> and interject some fun into this project..

This looks good. Controlling the water flow, pressure and the level of the
water in the tank. We can can also add  a heater for heating the water too.
That way we'll have temperature control as well.


> Alarms need to have hi and low settings. Display with a default
> (alarm) color if a reading is out of range.

Right. Thought on that but I didn't write it.
Basically alarms will have 4 values High and Low
alarm values plus two warning levels first when it is
close to High and the second when it's close
to the Low value


>Later on we can add
> email, sms, audio etc etc capabilities.

As long as we keep modular plugin design
we can add everything that we want.

Audio is must for alarms.
Email is easy to implement (at least reporting)
GSM will be something like communication with the RTUs.
Later on we can add some command features and status
request by processing the received messages.
Special formatting of the sms and the email will be
required.


> > 1.h Field Device drivers (plugin based) - drivers (rs232, rs485,
> > modbus canbus) reasponsible for reading and writing to the physical
> > devices and informing the server if some process point changed it's
> > value, communication line diagnostics etc.
>
> Don't forget we have Digital I/O and Analog (4-20 ma or 1-5vdc) I/O
> from sensors to display. LEDs red/green looking graphics for DIO
> is common. For Analog readings to have to 'scale the signal (for
> example 4-20 ma) to a range for example the submersible pump discharge
> of a well from say 0-80 psi.

Everything that can be taken from the devices will be displayed


 > Units used for display? Folk might want millibars instead of psi
> for pressure, as an example. In fact we'll need a 'units conversion'
> library so that folks can select the units for display with QScada.

Yes indeed.

> > Simulator:
> >
> > Console and GUI based application that will be on top of a dummy field
> > device driver. It will be a sort of virtual device used for testing
> > the SCADA system, changing the values of the process points, states of
> > the devices/machines. The GUI version should be configurable so that
> > the values can be changed by pressing buttons, sliders, textboxes and
> > other simmilar gui widgets.
> >
> > What do you think about it?
>
> Yes, and if we provide a structure where graphical icons can be added
> easily, such as a pump, a valve, a guage, then many folks can
> contribute artwork for the various devices.

Right. That's the basic Idea for the client. We will provide some templates
and examples, so that the users can code their own visualisation
components. On the other hand we'll have some scripting engine
(most probably QSA - Qt Script for Applications) and some prime
shapes (lines, rectangles, circles, triangles etc.) whose behaviour
will be controlled by some scripts. This is the basic visualisation
technique that is implemented by most of the SCADA/HMI software

For the simulator we need some basic gui components (buttons,
sliders, text boxes) something simple just to change the values
of the parameters. Testing purposes only.


> Are we still using Eclipse as the development tool of choice
> or is their something else?

Yes, for now. I think some general purpose IDE like Eclipse
will be more appropriate than to use some IDE specially designed
for QT since we might need to edit some other files( different prog.
 languages) in it and still have compact project.

> I think it would be wise to make QScada a QT4 based project and not
> use any QT3 resources that are not compatible. Gentoo allows both
> to be installed and used with different applications.

Right again :) We'll use QT4 and Gentoo.

> Which linux distro do you prefer?

It doesn't really meter which distro we'll be using, as long
as we keep good configuration of the system. Gentoo
offers many "under the hood" things and total control over
what's installed and how it's working. We can use Gentoo
as a development environment.



> Sorry for the disappearing act....

Never mind. From time to time we get too busy.
Did it my self few times :)


>Our problem now is that you will be
> alone for a while, unless Iain has some spare cpu_cycle he
> can provide.

It doesn't meter if we keep on walking.
Small continuous steps, are much better than
running fast and get tired very quickly ;)

BR, Jovan