Water Industry

Water and Waste Water

Hello I am seeking information on applications that the water and waste water system use. Is there a vendor for applications? I am not interested in the SCADA software, only the applications that pertain to industry. Any information is appreciated Thanks in advance

     -------------------------------------------------------------
 | Ron Harter            | Tongue Tied and Twisted           |
 | rharter@flash.net     | Just an Earth Bound Misfit ... I  |
 |                       |     David Gilmour  Pink Floyd    |
 -------------------------------------------------------------
    

Re: Water and Waste Water

This depends what you mean by applications, if you consider the PLC/DCS/RTU programming as the application we have implemented many such schemes for clean water sewage treatment plants. As a result of this have built up a library of applications. However, due to the nature of different hardware / customer requirements these libraries always require customisation for the final solution although usually saving much development time. Until this time comes when many PLC/DCS/RTUs use the same programming language (or at least programming interface) I doubt if it will be viable to buy an 'application off-the-shelf'.

       | Paul J. Newbery     | Email: pnewbery@cytek.co.uk |
 | Cytek Projects Ltd. | Tel:   +44 1252 715171      |
 | UK                  | Fax:   +44 1252 713271      |
      

RE: Water and Waste Water

To end processor and PLCs / RTUs std-bus standard. Their e-mail is std@nrp.com.br

 Regards
 Simões
      

Re: Water and Waste Water

In our experience the water / waste water industry have very little in the way of applications above that of equipment control. However it must be said that they are starting to look at leak detection and in a current application we know of leak detection is being performed using flow balance along a pipeline. This is very crude in comparison with the oil and gas industries but water has a much lower value (at least currently !). The other applications we have come across are delivery scheduling packages along pipelines where the flow setpoints to various branches along a pipeline are varied throughout the day to meet demand. As far as I am aware these packages are bespoke and engineered usually by the system integrator. I don't know of any energy management systems in use, most SCADA based applications count running hours of equipment which is used to schedule maintenance. I hope these comments are useful, most of our experience is in the UK and less so in Europe, so these comments may not reflect the state of play in other areas of the world. Regards,

      | Paul J. Newbery     | Email: pnewbery@cytek.co.uk |
 | Cytek Projects Ltd. | Tel:   +44 1252 715171      |
 | UK                  | Fax:   +44 1252 713271      |

      

Re: Water and Waste Water

I would be interested in applications (on 'PC' platforms running Windows 95) that provide production and management reporting that could support invoicing from water filtration plants whose capacity is rated at 150 mL/day. michael pascoe ----------

Re: Water and Waste Water

We have not used an 'applications' capable of doing this. However we have implemented reporting systems with this type of information using either Excel or Visual Basic with links to the historical data manager of MMI. This is easily achieved when using InTouch or Fix by setting up DDE links. We are currently engineering such a reporting system for a 490 Ml/day water treatment works.

 | Paul J. Newbery     | Email: pnewbery@cytek.co.uk |
 | Cytek Projects Ltd. | Tel:   +44 1252 715171      |
 | UK                  | Fax:   +44 1252 713271      |
      

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

AWWA

TO Matt Lukens, The AWWA is the American Water Works Assoc. and they have two conventions. Every year is their usual big show, with all sorts of papers and manufacturers present. Then, every other year they have a computer automation and software show. The exhibits and papers at this one are primarily on control equipment and software, centering on that segment of the industry. Steven King: I expect to be there on sun nite and Monday, leaving late Mon. Yes, it is a lot to take in, and you can only digest so many "features" everyone has to sell. Regards all, Bill Cross

Ref: c:\scada\041997\msg00002.xml

FW: For the scada folks in the water business

Hi All, The RTU's best suited to any SCADA application are intelligent, able to interface and interact with local control systems at their sites, and capable of report-by-exception as well as being polled. This last feature is critical. They need to be able to advise of abnormal (alarm) conditions or changes of state instantly, while having a background poll to ensure they are alive and well.

A system I helped design for a water authority (who are still trying to make a decision on it after 3 years) utilised both these systems in a way that produces efficient communication, with minimal traffic overhead. It went something like this.

1. The RTU would log non-critical events or changes of state in a time stamped fashion.

2. The background poll would request the logged data since the last poll, and update it to the HMI historical database. This poll occurs slowly, leaving a decent "window" for any report-by-exception comms to occur. This ensures that the site is still communicating and that any important trends are accumulated by the Supervisory system and available for viewing or dissemination to the EIS.

3. In the event of an alarm or other abnormal condition, the RTU would notify the Supervisory system of the condition, and the Supervisory system would immediately request all logged data since the last poll. This allows any trend leading up to the alarm or abnormal condition to be analysed by the system or operators.

This methodology has a couple of important advantages. Firstly, events or conditions you HAVE TO KNOW ABOUT are reported immediately, delayed only by the communications lag times and data collisions inherent in any point to multi-point system. Secondly, it means that you can still get all normal events (albeit at a less than "real time" rate) from the out-stations, while not waiting until a station has not reported in before realising that it may be off the air. This gives your engineers, operators, and anyone else interested in the "real time" trends good data, without clogging up your communications bearers.

So, now we have some basic criteria for the RTUs, intelligent, data-logging, and capable of polled and report-by-exception communications. Are there any around? Well, when I was looking at RTUs to handle this (18 months ago), I discovered only two that could do it off the shelf. Both required drivers to be developed for the Supervisory system in order to handle the time-stamped data and the complexity of the communications (background poll data request, and data request on exception report). These were MotorolaMOSCAD and Action Controls Kingfisher Series II. By now I imagine there are a lot more. But they use proprietary protocols, few (if any) standards exist that can handle it. Also, they are more like a hybrid Programmable Logic Controller, scanning their inputs and setting outputs at programmable, or interruptable rates. Extremely adaptable and capable of being extensively programmed using proprietary ladder logic and special ladder function blocks.

More difficult, was finding a SCADA/HMI software system that could handle time-stamped data coming in from the RTU, and integrating that data into it's historical database. At the time only one package could do this off the shelf in the driver toolkit, and, to my knowledge, no-one has implemented it yet. I hope there are more these days. But as most off -the-shelf SCADA/HMI software is designed for factory floor applications, time stamped data coming from PLCs is usually not a consideration.

Please remember that the above system is best suited to industries where you have out-stations spread out over a relatively large geographical are, and use relatively slow communications bearers, like radio. This system then closely approximates to Mark's ideal SCADA system. Regards John

RE: FW: For the scada folks in the water business

There are probably a few examples of HMI RTU combinations around which handle time-stamped data. One SCADA/HMI package which handles time-stamped data from RTUs isCitect. I have written the Citect Harris HR6000 Protocol driver which fully supports this "SOE" (Sequence Of Event) mode, and also modified the Citect Introl DPC Protocol driver which does likewise. This means that Harris D20 RTUs and Introl RTUs will accurately transfer timestamped state changes to Citect. There may well be others.

Citect has the concept of "time stamped alarms" where the timestamp is read from the RTU. The way Citect interfaces with its drivers, drivers can be set up to read state changes quickly from the RTUs (especially where their state change buffers are limited in size), and buffer them in the driver memory ready for Citect to process sequentially. You can guarantee that every state change reported by an RTU will be processed by Citect - fully timestamped to millisecond accuracy if needed.

As an example of an alternative to "pure" Report-by-exception, the HR6000 protocol's polling mode achieves the same result. A very small "status change check" poll message can be sent to each RTU logical unit frequently. A system I installed for a power authority has around 20 logical units across three serial channels, and these are all being polled for state changes every 200 milliseconds. In addition, as a single RTU can be divided into multiple logical units, all of the highest priority alarms for example can be placed on one logical unit which is polled at a higher rate than the others.

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

Re: FW: For the scada folks in the water business

CiTecT time stamps at the SCADA host layer when interfacing to Square D model 650 RTUs. In fact, it appears that if you have a dual redudant CiTecT Alarm configuration, both the primary and secondary alarm servers do their own time stamping. That is, CiTecT doesn't appear to send time stamped alarms between the primary and backup alarm servers. The implication is that alarm lists appearing on the primary and backup hosts can have different time stamped values.

michael pascoe
KINHILL Pty Ltd

RE: FW: For the scada folks in the water business

I guess you don't have full timestamped alarm mode running for the Square D driver (because it's not implemented I suppose). But for drivers like the HR6000 one forCitect, multiple alarm servers are supported - and the timestamps read from the RTUs will be displayed identically in each alarm list. You just need to set a parameter in the "citect.ini" file to tell the driver how many alarm servers there are, so timestamped state changes won't simply be discarded after having been read by one server.

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

RE: FW: For the scada folks in the water business

Hi Guys, I appreciate the input about CITECT but I think you have missed the point. I am very familiar with CITECT. However, what we are talking about is not just time stamped alarms. We are talking about logged time stamped data, be it analog or digital in nature. So that all events (digital changes or analog changes) logged by the RTU between background polls can be stored historically in the historical data files. To my knowledge, CiTecT does not handle this at all. In fact, it has been a sticking point for a number of potential CiTecT customers. I have not yet seen a full implementation as I described. RTUs doing logging and report-by-exception, AND the SCADA/HMI software to handle this. Personally I find it amazing and abhorrent that it has not yet been done in the water industry. My former employer has totally dropped the ball in implementing it, and one of the SCADA software products I do contract technical support for, and has the capability to do it in the driver, has never actually been asked to do it.

For god's sake I hope I'm wrong. But event/alarm time stamps is not what Mark and I are talking about. We are taking about all trendable data, logged by the RTU, being brought back, stored, and displayed via the SCADA/HMI software. If all you are interested in is alarms, fine. But in most water authorities, they need accurate trended data to produce mathematical models and expert systems to fully and efficiently utilise the infrastructures they manage. Regards John

RE: FW: For the scada folks in the water business

You're right, I did miss the point. But, in factCitect can support any timestamped data. The HR6000 driver I spoke of supports timestamps on any digital changes (not analogs, as the RTU doesn't support this), and there are ways of getting all of these into Citect, even for non alarm points.

Exactly the same methods both in Citect and in the driver can be used for timestamped analog changes - it is not significantly more difficult, but of course requires support in an RTU. I haven't seen this in practice yet, but I'm not familiar with all Citect drivers.

This shouldn't be a sticking point for potential Citect customers, all it may require is some modifications to the driver for the protocol of choice. I'm familiar with what's needed, and am not talking about a huge amount of engineering to do this either. Maybe I could "unstick" those customers you're talking about! :^)

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

RE: FW: For the scada folks in the water business

This is becoming the norm in the water industry, however. Take, for example, two relatively new SCADA systems that I have worked on - Sydney Water with their IICATS project, and Brisbane Water with their IDTS project.

Both of the systems have complete capability for RTU data-logging and report by exception, and this capability is being used. Now look at the SCADA systems that are being used....

Sydney Water use Logica (UK) RTUs and HMI software. Brisbane Water use MITS (Aust) RTUs (for the first phase) and HMI software. Both are large, complex systems which cost millions of dollars.

For the RTU to be able to data-log and utilise call by exception, a relatively complex communication protocol that allows for logged data to be transfered across the network must be used. In both cases above, they are proprietry protocols, which runs between RTUs developed by these companies, and the complex databases in the Master stations. Both system will timestamp and log both analog and digital points at the RTU end, and in the case of the MITS system, at the master station as well (if desired).

Even now, with new "standard" protocols such as DNP3, etc, these functions are still proprietry extensions to these protocols and hence not really adapted to use with a third party HMI. It is usually these protocols that the HMI manufacturers integrate into there systems, because it will give their product the widest range of PLC and RTU support possible. However, it means that functions that are now becoming necessary to further enhance the effieciency of SCADA systems are not available. As these protocols mature, we may see these functions in low end SCADA HMI packages.

This is the crux of the matter. If you want to be able to utilise these facilities, the data collected by the system must be accurate, and in terms of any computer system, accuracy costs money. Unfortunately, in this day and age, everything must be done cheaper, and in many cases, this results in less than optimal solutions. The bottom line is you get what you pay for.

Regards,
--
David Chinner
MITS Real Time Ltd, North Ryde, Sydney, Aust.
Tel: 61 2 9805 0688
E-mail: davidc@mega.com.au

RE: FW: For the scada folks in the water business

Hi Steven, Actually, theCitect historical sub-system only handles periodic trended data. That is, data that is stamped at fixed intervals. This inherently limits the ability of the product to store and display, non-periodic trended data. This is basically because it, and most other packages, are designed to be integrated with PLCs and utilise a poll methodology in communicating with them. Believe me, I would be most happy to be wrong. But I have written conversion utilities and custom packages for the Citect historical sub-system. It may have changed somewhat in the last 18 months or so, but the information I have at hand is that it hasn't.

I agree totally that it could, and should, be handled at the driver end. But that is only part of the story. The sub system needs to be able to store these records and display them in the appropriate time sequence. As well as update any trends being displayed at the time. Regards John

RE: FW: For the scada folks in the water business

Hi David and all, Even now, with new "standard" protocols such as DNP3, etc, these functions are still proprietry extensions to these protocols and hence not really adapted to use with a third party HMI. It is usually these protocols that the HMI manufacturers integrate into there systems, because it will give their product the widest range of PLC and RTU support possible. However, it means that functions that are now becoming necessary to further enhance the effieciency of SCADA systems are not available. As these protocols mature, we may see these functions in low end SCADA HMI packages.

I disagree that proprietary protocols preclude third party HMI packages. Any package can have a communications driver written to handle any protocol. It's just software for god's sake, and not set in stone. The major problem is that the packages themselves are not written to handle non-periodic trended data, and store and integrate it into any visible trend displays. Basically, the software is designed for the factory floor where millisecond events and sub second poll times are the norm. If we need to live with proprietary protocols until a good open standard exists, then fine.

I also disagree that it is difficult to manage logged and transferred data between the RTU and the HMI system. Firstly, the background poll can be used to maintain local RTU clock accuracy, with the driver or RTU adjusting transmitted time packets for communications latency. Just about any RTU has a local clock, and many of the latest generation RTUs have the ability to log down to the millisecond. Very necessary in the Electrical industry, where the sequence of breakers tripping is important in determining the source of a fault. In the water industry, we not so concerned with that sort of resolution, but to engineer and utilise mathematical modelling, we need accurate trending of data. Not all water authorities can afford the mega-budgets you are talking of, and all given the choice would rather not spend the money on a mega system. Mid end RTUs that can perform local control functions, logging, and act as a standard RTU ARE THE NORM now. They generally budget at $5000 AUD for a fully cased, mounted and configured RTU. Sure you might need a million budget to get it installed. But the fact that a comparable SCADA/HMI can't support the RTU functionality is mind boggling.

This is the crux of the matter. If you want to be able to utilise these facilities, the data collected by the system must be accurate, and in terms of any computer system, accuracy costs money. Unfortunately, in this day and age, everything must be done cheaper, and in many cases, this results in less than optimal solutions. The bottom line is you get what you pay for.

Yes, in all things technical, you get what you pay for. Particularly computing. But just as computers don't necessarily need to do things just because they can (witness the tamagotchi, let 'em die) neither should we neglect the things they can do well. Computers are meant to make things easier. Computer manufacturers, software developers and consultants should not dictate solutions based on their own restricted thinking, stock of products, or experiences. We all need to address the problems and needs of customers and clients in order to provide solutions. Different industries, processes if you like, require different solutions.

I was once a member of the MITS development team, way back when it was the IT department of Melbourne Metropolitan Board of Works (now defunct and broken up) The SCADA system was an in house fund sucking system designed by people more akin to developing the EIS. They had some truly talented engineers designing the RTUs, but never once did they truly consider how it could be done cheaper and easier. They didn't truly understand the nature of the information they needed to gather. Just throw more money at it and use what we know. Most of these people have left and many have had a hand in designing the RTUs that have the capabilities we are talking about. It's just a pity none of us has moved into developing a SCADA/HMI package to do the job. These are two mega systems you speak of. But how many smaller systems do you sell? How many contracts do you lose to competitors that can scale down to a small or mid sized local authority? How many of these authorities require time-stamped data to model and develop their supply, removal and treatment systems? And how many of them settle for a compromise that doesn't truly fit their requirements? Isn't that an opportunity that could be exploited?

High end or low end solutions, costly or cheap, doesn't really limit these capabilities. It is the lack of a desire to do it. It should be apparent by now to any software developer out there that there is a real need for these capabilities. My guess it the first to capitalise on this need will reap the rewards in all industries where wide dispersion, low communications speed, fine resolution trending, and flexible RTUs are criteria. This is not limited solely to the water industry.

I do apologise for my tone in this. But I am so sick and tired of IT related consultants providing what they think is an adequate solution to a problem, especially to customers and clients who have little or no idea of the technologies and take for granted what we say. So often they accept a short term solution because nothing better is offered. I so often hear how these marvellous systems used as show cases by SCADA suppliers and consultants, actually don't do what their client's really want. The usual comment goes something like "We thought it could do this, but found out it would cost X amount extra to actually make it do it". And the SCADA industry isn't alone in this failing.

Too often is the answer "you only get what you pay for". Rarely the answer "let's think about this and see if there is a better way".

RE: FW: For the scada folks in the water business

Right! We've been coming at this from different angles. I've been thinking about whatCitect can do to gather data, whereas you're thinking more about what's practical to do with it!

What I meant was that you can, without too much difficulty, end up reliably processing inside Citect "state changes" consisting of "value,timestamp" pairs - for any digital or analog changes. But how much (or little) use the package can make of this data is a very relevant point - and you're right about there being no in-built ability to handle timestamped non-periodic trend data. It's easy to gather the data and log it for later display in Citect, or for use by other applications, but that's not exactly a complete solution I guess!

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

RE: FW: For the scada folks in the water business

I disagree, These protocols are not complex at all. Yes they are proprietary, but the are many RTU's out there capable of supplying time stamped data, and an even greater number of developers like myself just waiting to write drivers for these beasties. The problem is, that the SCADAs are incapable of processing the data once received.

Michael Whitwam
whitwam@global.co.za
http://www.wisetech.co.za

RE: FW: For the scada folks in the water business (longish)

John, But requiring a separate driver for each different type of PLC or RTU on your network defeats the purpose of having a "standard" protocol and the advantages of having a single protocol on your network. True, it is only software, but for an open system to exist, a standard must exist that encompasses all aspects of that system, and all parts of that system must conform to that standard.....

This is all very true, but you skirt around the problem of actually moving the logged data from the RTU into the HMI, and the conversion from the RTU data format to the correct format for the history database on the HMI, while maintaining data integrity. It is this aspect of the system that causes problems due to the complexity and the processing overhead of the software required to do this. It may not be economically feasible to write this software into a HMI such as CITECT.

..stuff snipped.. The way I see it, computers are a tool. They do not make things "easier". The way the tool is utilised determines whether the job they do is made easier. When the computer system is properly designed and utilised, the job that is to be done will be done better - but not necessarily "easier" to do. As computer systems become more complex, the skill levels required to maintain and utilise these tools will go up.

| Computer manufacturers, software developers and consultants should | not dictate solutions based on their own restricted thinking, stock of | products, or experiences.

How else do you suggest solutions be found then? If you can't base your solution to a particular problem on the tools, resources and experience that you have at your hands, how is it possible to find an optimal solution???

This sounds like a car that has a spare tyre, but no jack or wheel-brace, and a flat tyre. No tools, no resources - how do you change the tyre?

Is it really a lack of desire? Or is there some other factor that you haven't taken into account? Time, investment, risk? Yes, there is an apparent need for this capability. Yes, there are products already on the market that have this capability. Is any software developer going to be willing to develop a HMI that has these capabilities when they know that the product they develop will have competitors that have been in the market for a long time?

| these capabilities. My guess it the first to capitalise on this need will | reap the rewards in all industries where wide dispersion, low | communications speed, fine resolution trending, and flexible RTUs are | criteria. This is not limited solely to the water industry.

I may have missed the point here, but you appear to want something that already exists - but you are not prepared to accept the price tag that is currently placed on these capabilities. This seems a little naive. If a HMI with the capabilities we are talking about costs $X, then that is what you have to pay to get those capabilities. If you can do it cheaper, by all means, you are welcome to do that. It would be good for industry and force the prices down. But no one seems to be willing to take the step to do this, despite the apparent need.

This goes for the software industry in general. Just look at the world's biggest software company, Micrsoft. Its not what I want, or what i would call an optimal solution, but I'm forced to use it because everybody else does.

| Too often is the answer "you only get what you pay for". Rarely the answer | "let's think about this and see if there is a better way".

But once again, the solution found by stopping and thinking would then be subject to the "you only get what you pay for" adage when implementation comes around. Quality tends to cost money.....

Regards,

--
David Chinner
MITS, North Ryde, Sydney, Aust.
Tel: 61 2 9805 0688
E-mail: davidc@mega.com.au

RE: FW: For the scada folks in the water business (longish)

Hi David, But requiring a separate driver for each different type of PLC or RTU on your network defeats the purpose of having a "standard" protocol and the advantages of having a single protocol on your network. True, it is only software, but for an open system to exist, a standard must exist that encompasses all aspects of that system, and all parts of that system must conform to that standard.....

Yes, I agree that for multiple brands of RTU/PLC you need to have a standard. But are these systems you're talking about using multiple vendor RTU/PLC or single vendor? Most systems generally standardise on single vendor, purely as this is the only feasible way to get what they want. Yes there needs to be standardisation, I totally agree. But that doesn't preclude utilising time-stamped data derived from the RTU. It is still a driver problem. Also, there are a number of standard protocols for transport layers. You can have multiple vendor RTU/PLCs on a single network talking the same transport protocol. The transmission of time-stamped data is, like the transmission of programming data or real time data, an application layer function. There are many SCADA/HMI packages, even in the "low-end" that can have multiple drivers talking across a common transport layer. And if there is no standard that fulfils all your system requirements, you have no choice but to roll-your-own. My argument against vendor reluctance to offer true solutions to clients applications still stands. The means is there, there just is no will to do so.

This is all very true, but you skirt around the problem of actually moving the logged data from the RTU into the HMI, and the conversion from the RTU data format to the correct format for the history database on the HMI, while maintaining data integrity. It is this aspect of the system that causes problems due to the complexity and the processing overhead of the software required to do this. It may not be economically feasible to write this software into a HMI such as CITECT.

That is my point entirely. Most software products being utilised in the water ( a particularly slow comms, wide geographical area) industry are not suited to the application. It would be almost impossible to write it into CITECT. What I am arguing for is a product that essentially suits these applications. And to my knowledge there is only one that can handle the kind of functionality, out of the box, that we have been talking about.

| But the fact that a comparable SCADA/HMI can't support the RTU | functionality is mind boggling.

But I can't agree with you here. See above.

I should have said, isn't generally available or common. See above.

The way I see it, computers are a tool. They do not make things "easier". The way the tool is utilised determines whether the job they do is made easier. When the computer system is properly designed and utilised, the job that is to be done will be done better - but not necessarily "easier" to do. As computer systems become more complex, the skill levels required to maintain and utilise these tools will go up.

Again I disagree. A tool is generally purpose built for a particular job. You can use a pair of multi-grips to undo a screw, but it isn't necessarily easier or designed for the job. A computer is a building block in a system. It is the system that is the tool. The best part about out computer building block is it's adaptability to a task. You need to utilise that adaptability to apply it as part of the solution.

| Computer manufacturers, software developers and consultants should | not dictate solutions based on their own restricted thinking, stock of | products, or experiences.

How else do you suggest solutions be found then? If you can't base your solution to a particular problem on the tools, resources and experience that you have at your hands, how is it possible to find an optimal solution???

You need to come from an understanding of what you are trying to achieve. Generally, your client knows best what this is. Then you can use your experience to inform them of the limitations, and your ingenuity to build the system that gives the best possible solution. I am not suggesting throwing out your tools, experience and products. But keeping an open mind. It's easy to change a tyre with your standard set of tools if you know that is what you are supposed to be doing. But if you are really supposed to be checking the tyre pressure, it's not much use taking the wheel off and carting it to a services station when a tyre gauge is really all that you need.

This sounds like a car that has a spare tyre, but no jack or wheel-brace, and a flat tyre. No tools, no resources - how do you change the tyre?

Is it really a lack of desire? Or is there some other factor that you haven't taken into account? Time, investment, risk? Yes, there is an apparent need for this capability. Yes, there are products already on the market that have this capability. Is any software developer going to be willing to develop a HMI that has these capabilities when they know that the product they develop will have competitors that have been in the market for a long time?

This is the problem. There are no suitable products available. Not in the area of the market we are talking about. Real high end systems exist. The cost a lot more to buy and implement than a little tweeking on the driver side of a product that can handle the non-periodic trend data being pushed into the historical database system. If it can be done on a high end system, it can be done on a low end system. This is the whole crux of the argument. Most SCADA/HMI software packages being utilised in the water industry are NOT designed for the water industry. A little more thought on the architecture side to handle any type of historical data, and you have a product capable of doing what we want. It isn't that difficult, just a tad out of the line of thought most SCADA/HMI producers have. A little outside their experience. My god, we are not talking a complete re-write, just a change to a sub-system. There are at least a dozen water authorities in .au alone that would purchase such a product, and I imagine a lot in the rest of the world. There is little risk in trying, and a lot to gain. Besides, no company has gotten anywhere without risk. It comes down to complacency. We have a stable product that suits our needs, and we have enough customers that can pay for it. Why change? It also comes down to a lack of understanding by the major SCADA/HMI software producers of applications outside the factory floor, an the capabilities of the RTUs that are used in these applications.

I may have missed the point here, but you appear to want something that already exists - but you are not prepared to accept the price tag that is currently placed on these capabilities. This seems a little naive. If a HMI with the capabilities we are talking about costs $X, then that is what you have to pay to get those capabilities. If you can do it cheaper, by all means, you are welcome to do that. It would be good for industry and force the prices down. But no one seems to be willing to take the step to do this, despite the apparent need.

Idealistic, but not naive. The fact is that there are a lot of systems that could probably have the historical sub-system modified to do this, and they don't cost mega-bucks. And the non-willingness to take the step is exactly what we are talking about. We want to know why. I understand entirely the development costs versus return argument. I am in that boat myself. I produce software products tailored to my client's needs. Sometimes they can afford them, and sometimes not. Sometimes, for my close clients, I will wear the costs to give them a solution, and recoup development costs when other clients require the same or similar product. I have to take risks in order to maintain my business. It's an awful lot harder for me to take such risks as a self employed person, than as a software developer with a decent R D budget. Are you telling me that you, or your software suppliers, don't continually develop and improve the products? Aren't you taking a risk in recouping these costs? Don't you justify this expenditure with maintaining a competitive edge?

This goes for the software industry in general. Just look at the world's biggest software company, Microsoft. Its not what I want, or what i would call an optimal solution, but I'm forced to use it because everybody else does.

I am just as pissed with them. They are the worst offenders in this.

| Too often is the answer "you only get what you pay for". Rarely the answer | "let's think about this and see if there is a better way".

But once again, the solution found by stopping and thinking would then be subject to the "you only get what you pay for" adage when implementation comes around. Quality tends to cost money.....

No, actually quality is not at all necessarily linked to price. If it was, UNIX would be dead and buried a long time ago. It still exists because there are people out there that still believe that a quality must be maintained in the face of mediocrity. It may not be making "Windows" bucks, but it is still a better alternative in a lot of cases where mission critical means just that. And many flavours are better supported and far cheaper than it's commercially oriented competitor. But, hey. I still use Windows, because I can't run my business apps on UNIX. Everything has it's place, and there is always a need for something different. Which is why so may software companies and utility writers survive in the face of the MS juggernaught. They fulfil a need that the Big Boy can't, or more often won't.

A lot of mistakes and costs can be avoided by stopping and thinking about what is really required to give a client what they need, and how it can be best achieved. Rather than rushing head long into implementation. We need a better understanding of what is required. For those who can throw money at a problem and get an adequate solution, that's fine. It doesn't mean they get quality, just a system that fits their specifications. It doesn't mean it is the best solution, but the got what they wanted for a price. There are others who can't throw money at a problem, and must work within certain constraints. They may achieve a better, higher quality solution because of these constraints, even if they may suffer some of the functionality they require.

But there is still a need to be filled, and the first company who can do it within the allotted budget will get the business. The question is, who is brave enough to take the risk. MITS has been a case in point. While at Barwon Water, a mid-sized, low budget water authority, I requested on numerous occasions for MITS to come and tell us what they could do. Not once was an invitation accepted. When an EOI and system Specification was circulated, 4 companies replied, only 2 could fit the bill, MITS was never heard of. Just because we don't have the budgets to purchase the mega systems you provide, doesn't mean we are naive. It just means we believe that the technology exists to provide the systems we want at a price we can justify. All we are lacking, is one building block, the historical sub-system to handle time stamped data coming from the RTU. It shouldn't be that hard to fill. Regards John.

Ref: c:\scada\081997\msg00021.xml