[prev in list] [next in list] [prev in thread] [next in thread] 

List:       spread-users
Subject:    Re: [Spread-users] Will Spread work for me - large numbers of remote
From:       Trever Miller <trever () cyberdex ! ca>
Date:       2004-03-04 18:10:18
Message-ID: 4047710A.1070406 () cyberdex ! ca
[Download RAW message or body]

Herbert Rubens wrote:

>Trever,
>
>	I was wondering if you could provide me with more information
>regarding your exact requirements. 
>

Well, I can tell you what we have now, and in the future it is planned 
to be more of the same...

>There is another type of networking
>technique called ad hoc wireless networking which allows the devices to
>relay packets over great distances. This could be a replacement for your
>existing satellite technique which could be both more cost effective and
>provide lower latencies. 
>

We don't need realtime, we're not directly involved with the C (control) 
part of SCADA.

>From my understanding, I am imagining a large
>number of nodes spaced some distance apart along a pipeline. The nodes
>are monitoring something, and reporting back information once an hour.
>One question I have for you is regarding the distance between each of
>the nodes. Are they 100 ft a part? A mile apart? 20 miles apart etc...?
>  
>

That would be more akin to traditional SCADA, gathering data from an 
oil/gas field of wells within 15-30 kilometer radius via radio modems.  
Plant and field operators typically use that data to monitor and control 
wells, compressor stations, etc and for alarm call outs when something 
goes outside of expected operating ranges.

That kind of data typically stays out in the field, and if it ever comes 
into head office, it is greatly delayed, and summarized to production 
volumes only.  Faxing and manual re-entry into production accounting 
systems is the norm.  

We grab reports from the SCADA systems via serial "printer" capture, or 
snag them off of a file share on the SCADA host, or actually talk 
directly to devices on an RS485 serial bus and collect data directly 
from the measuring points (sales/fuel meters, compressor station 
inlet/outlet and so forth).

>Also, where is the information being aggregated to? Are there control
>stations every 10 miles? Or does it all need to be collected back to a
>central control point? 
>

Central data collection point, in our data center.   Satellite downlink 
is in Toronto, our data center provider is in Calgary.  We also have 
CDPD and 1X cellular modems for the backhaul link in some locations. 

Remote locations are on the order of 50 or 100 KM or more apart.  They 
are isolated field locations with facilities operators that drive around 
and tend to perhaps an area 50K radius.  Some data is collected manually 
and entered into the app back at the field office, other data comes from 
SCADA (supervisory control and data acqusiton) or EFM (electronic flow 
measurement) devices which our system then interfaces to and pumps the 
results back to the mothership.  Other locations are unmanned most of 
the time, helicopter access only.

Data ultimately feeds into a J2EE based behemoth (ok, I'm not a java 
propeller head, but I work with a bunch..) that spindles, mutilates, 
transforms it all into our singing and tap dancing standard data model 
that then feeds via http/https to desktop application for analysis etc, 
and exports which enable operations optimization applications to be 
energized.    Let engineers who are internet connected get to relatively 
fresh, constantly updated, data and perform analysis with it.  Catch 
declines in production or imbalances etc before they become big problems 
requiring big $ to rectify.

At the moment we have file-based data transmission over scp.  SSH 
handshake initiation timeouts are happening more often than I like, and 
it takes several tries for the remote units to get the files back to 
home base.   They are well within expected time frame for delivery, but 
it just bugs me that it has to retry so much.

A message bus implemented on negative-acking udp protocol such as hop 
sounded quite nice ... and would enable a more sophisticated interaction 
with the remote units for configuration updates,  software updates, 
logging, and data transport obviously.

>All of these factors will play a role in
>determining the applicability of this wireless ad hoc technology to your
>specific application. Please feel free to contact me directly if you
>would like to discuss this further. I've also included a link to our
>webpage which overviews some of this information and has some papers as
>references.
>
>http://www.cnds.jhu.edu/archipelago/
>
>
>Regards,
>
>-Herb
>
>  
>
Thanks for the link.  I'll look into it later today. 

If it's strictly short range radio specific then it won't be a match but 
could be interesting readng nontheless. 

Timeframe for a replacement to the working but hacky (and I wrote it...) 
scp based implementation is on the order of 8-12 months out.

-- 
trever@cyberdex.ca
Cyberdex Systems Consulting Corp.


_______________________________________________
Spread-users mailing list
Spread-users@lists.spread.org
http://lists.spread.org/mailman/listinfo/spread-users
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic