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