Menu
▾
▴
qscada-developers
|
From: Paolo S. <pao...@ya...> - 2006-11-13 12:31:51
|
Hi James,=0Aback in Italy, but still busy.=0AI=B4m here even if it seems I= =B4m diseppeared.=0AThanks for your help and effort=0Atake care=0Apaolo=0A= =0A=0A----- Messaggio originale -----=0ADa: wireless <wireless@tampabay.rr.= com>=0AA: qsc...@li...=0AInviato: Venerd=EC 10 n= ovembre 2006, 22:14:49=0AOggetto: [Qscada-developers] Exciting news=0A=0AHe= llo Everyone,=0A=0A=0A=0AJovan: have you guys what tools/languages we shou= ld all install, to=0Awork on Qscada? I need this info to begin recruiting= coders and=0Atesters. I have been invited to speak at a=0Alocal group that= refers to themselves as 'the 2600 club'. Mostly=0Akids and older (adult) k= ids that love linux. Hopefully there is=0Aand interest in controlling hardw= are and One of=0Amy ideas is to get embedded developers on board that are = familiar=0Aor willing to learn about embedded micro-controllers to we can i= mplement=0Aplc type functions on micros including but not limited to full= =0APID controls.=0A=0AIf you guys are ready, I'm going to propose to these = guys, who are=0Ainterested in accessing and controlling remote hardware, co= nsider=0AQScada, as a project of interest. Since Paolo is quite busy at the= =0Acurrent time, we need a software oriented person (Jovan?) to=0Akinda spe= ar head where we are going. I think iain is the admin=0Aand consumerate gen= too guru (grin) and I'll be the hardware guy=0Abuilding an online playgroun= d for folks to hang out and articulate=0AQScada with actual hardware=0A=0AI= hope to motivate the local (Tampabay) linux talent into this venture,=0Acu= lling through the masses and finding a few that capable. If we get=0AQScada= to a point and have a core team contributing, we can put=0Aup QScada for g= oogle funding it as a 'Summer of Code' opportunity.=0AOnce we have somethin= g to show, I'm going to start looking for=0Afunding, so some of the 'softwa= re guys' can focus on QScada on=0Aa serious basis.=0A=0A=0AI'm still bogged= down on the document I'm trying to develop, but it's=0Amore due to a lack = of time not lack of ideas. Hopefully, It'll be=0Adone next week as I have a= few days of slack time to finish the=0Afirst draft.=0A=0AOn another note, = I'll be getting a fiber drop from Verizon, in the next=0A30 days, so I have= to get (2) dns servers up and get ready to install.=0AIt'll be a multi meg= abit per second drop with about 5 usable(published/=0Aroutable IP address) = dedicated to QScada.=0AI'm leaning towards (3) hardened systems with SElin= ux(on Gentoo) and=0Aiptables/netfilter on the firewall and DJBDNS on the (= 2) dns servers.=0AHaving actual hardware for folks to remotely access to de= velop code on=0Aembedded linux controllers as well as PLCs, should be an at= traction.=0A=0AHere's a list of what I've accumulated so far:=0A=0A19"rack,= din rails large UPS=0A=0A(2) ethernet flat hubs, one unmanaged switch.=0A(= 2) Lantronix serial(232/485) to modbusTCP (ethernet) converters=0A(2) Newpo= rt serial(232/485) to modbusTCP (ethernet) converters=0A(2) Cyclades TS100 = serial(232/485) to modbusTCP (ethernet) converters=0A(1) Automation Direct = PLC 05 with 4 ch of analog I/O=0A(4) 24VDC power supplies=0A(2) bench power= supplies (current/voltage adjustable)=0A(6) video cameras (usb, ntsc, ethe= rnet)=0A(1) H.264 encoder (could use help getting the backend linux=0Abased= software to compile under gentoo (c/c++) sources=0A(1) TS-5500 (ethernet= ) running a 2.4 embedded linux kernel=0Ahas an AMD elan SC520 processor.=0A= http://www.embeddedarm.com/epc/ts5500-spec-h.html=0A(1) microchip MPlab ICD= 2 and a pikdev 18F456 chip w/ ethernet=0A(1) 8 port digi serial port expans= ion board.=0A(1) atmel AT91 dev board=0A(4) old 586 pcs we can used as embe= dded x86 based controllers.=0Awith serial and parallel ports , ethernet and= hard drives.=0A(suggestions on which kernel/rtos/linux to put on these=0Am= achines is welcome)=0A(1) usb-serial converter=0Ahttp://www.ftdichip.com/Pr= oducts/EvaluationKits/USB-Serial.htm=0A(1) CF writer, smart media writer an= d various support hardware.=0A=0AOn thing I'm looking for is a pci or pc-ca= rd based oscilloscope card=0Athat runs under gentoo, so we can capture wave= forms and display them=0Aover the net or convert them to an image so we can= send them to=0Ahardware oriented folks.=0A=0AI also have access to a prett= y nice logic analyzer, but cannot dedicated=0Ait to the project, only gain = sporadic access on off hours.=0A=0AI have a few discretionary dollars for a= dditional equipment purchases=0Aas warranted. Any soft of PLC's we can cobb= le together out of old PC's=0Aor purchase used PLCS would be keen. I need t= o start collecting sensors,=0Asuch as temperature, pressure, voltage, curre= nt, etc etc to have=0Ato interface to the water cannon.=0A=0AI'm also going= to rework my well equipment (pumps, water softener,=0Achlorine pump, UV li= ght) and 24VDC valve control so that it can be=0Amonitored over the interne= t with something that is qscada but looks like=0Athis demo:=0Ahttp://server= .scadabase.com/demo.html# (click the demo link) very cool!=0A=0A=0AI'm read= y to setup a development net for QScada, any and all=0Aideas are welcome.= =0A=0A=0A=0A=0A=0A---------------------------------------------------------= ----------------=0AUsing Tomcat but need to do more? Need to support web se= rvices, security?=0AGet stuff done quickly with pre-integrated technology t= o make your job easier=0ADownload IBM WebSphere Application Server v.1.0.1 = based on Apache Geronimo=0Ahttp://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D= 120709&bid=3D263057&dat=3D121642=0A________________________________________= _______=0AQscada-developers mailing list=0AQ...@li...urcefo= rge.net=0Ahttps://lists.sourceforge.net/lists/listinfo/qscada-developers=0A= =0A=0A=0A=0A__________________________________________________=0ADo You Yah= oo!?=0APoco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da= tanto spazio gratuito per i tuoi file e i messaggi =0Ahttp://mail.yahoo.it= |
|
From: wireless <wir...@ta...> - 2006-11-15 17:08:54
|
Paolo Sereno wrote: > Hi James, > back in Italy, but still busy. > I=B4m here even if it seems I=B4m diseppeared. > Thanks for your help and effort > take care > paolo Hello Paolo, It's always good to hear from you. Hang in there. Things will get better for you and all of us. You and yours are in my prayers and I hope you work everything out. On a brighter note, every time I talk to somebody about Qscada, they think it is a wonderful idea. We just need to get it to a point where we have some simple hardware on the net for folks to see and control. AT that point, I think it will explode with excitement as a project. In my opinion, I think it's good for you to 'hang back' and let the indians hash out quite a lot. That way, you can enter the debates at a later stage, as 'father wisdom' once the emotional spew is spent and folks are ready to get to work. On anther note, I rather like Jovan quite a lot. He's very up_tempo and crazy_maniacs like myself need a good rudder, now and then. Besides, we both agree on pushing the RT needs as close to the remote hardware as possible. That is the RT needs to be satisfied on the processor that is the closest to the field hardware. Whether it's a pc running qscada on a small control network, or a plc that has 3 processors between itself (the field plc) and final qscada server, RT requirements should be on the (micro)processor closest to the final (controlled) elements. But, we can support both scenarios and everybody will be happy. I've spent lots of time on RT issues with pc(servers) and it's not where I want to spend my time. Besides, on the Qscada server end, I'm leaning more to "openmosix" as a cluster, to provide High Availabilty for QScada. Supporting this "dual modality" of RT will allow vendors with products such as PLC with pid cards to be excited about Qscada. This is a very important point too. If we keep Qscada attractive to commercial companies, eventually all but the largest will get on board with Qscada. Those companies that do not get on board with Qscada will have their "proprietary portocols" reverse engineerd so they will be compatible without consent/control of their destiny..... If we support an architecture that allows one to mix and match both commercial offering and Qscada,(down to running pid loops) on a qscada machine in lieu of commercial plcs, then Qscada will allow for easy transition for utilities and companies, by allowing them to initially just replace their legacy scada server with Qscada. Last, I want you to know that I pray for people. It's part of my fundamental beliefs, so, If you are hurting or need a friend or want somebody to pray for you and yours, just let me know.... Our faith is the only thing that separates us from the animal kingdom....... Keep the faith, always your pal, James |
|
From: Jovan K. <cho...@gm...> - 2006-11-16 00:25:47
|
Hi, Great to hear from you Paolo. On 11/15/06, wireless <wir...@ta...> wrote: > On anther note, I rather like Jovan quite a lot. He's very up_tempo > and crazy_maniacs like myself need a good rudder, now and then. Thanks for the complinents :) > Besides, we both agree on pushing the RT needs as close to the > remote hardware as possible. Yes that's right. In some situations we can solve the RT problem by adding two timestamps to the data, one would be the time that the event has occured set by the RTU, and the other would be the time when it has arrived on QScada server, set by the QScada server. That way we'll have the exact time when the event has occured and when it was registered/logged by QScada. > Besides, on the Qscada server end, I'm leaning more to > "openmosix" as a cluster, to provide High Availabilty for QScada. good point > Those companies that do not get on board with Qscada will > have their "proprietary portocols" reverse engineerd so they will be > compatible without consent/control of their destiny..... We don't have to reverse engineer those protocols. If we do that we can not garantee that the protocol is working correctly. I think the best way is those proprietary protocols to be written by the companies themselves and to be given to us as compiled plugins that can be added to QScada. A concept similar to what NVidia is doing with the Linux drivers for their graphic cards. GREETZ, Jovan |
|
From: wireless <wir...@ta...> - 2006-11-16 17:43:38
|
Jovan Kostovski wrote: >>Those companies that do not get on board with Qscada will >>have their "proprietary portocols" reverse engineerd so they will be >>compatible without consent/control of their destiny..... > We don't have to reverse engineer those protocols. If we do that we > can not garantee that the protocol is working correctly. > I think the best way is those proprietary protocols to be written by > the companies themselves and to be given to us as compiled > plugins that can be added to QScada. > A concept similar to what NVidia is doing with the Linux drivers for > their graphic cards. Jovan, WE agree again! (this is quite scary for me).... But, my question is what do you do when the "big boys" Do not develop compatibility with Qscada? Reverse engineering their proprietary portocols, even with a limited measure of success, will motivate them. I'm sorry, but I do not see Rockwell, Siemens, etc etc jumping on the Qscada bandwagon, as most have purchased part or all of companies that have their own SCADA products. Reverse engineering protocols provides that nudge some may need. If not, potential users of Qscada, will have an alternative. What I do is used proprietary protocols(when the customers insists) between the PLC and a limited amount of equipment. I then used ModbusTCP to communicate with the SCADA server. If one designs a controls network like that, migration from one Scada server to another is very straightforward. If the (legacy) Scada server to PLC communiations involve many proprietary protocols, migration away from that (vendor's)Scada server platform can be a lot of work, and preclude many from the effort. That is why we'll need to suppport these legacy (proprietary) protocols in QScada. If not this approach, then tell me what is our plan to attract (migrate) folks from their legacy scada setup to QScada? If we do not have compatibility with the "big boys" on their proprietary (plc) protocols, migration from other commercial SCADA offerings to Qscada, may take a long time. Most protocols are "clear text" and therefore straightforward to reverse engineer.... We do it all the time, but, as you have elluded, maintaining such code, is time consuming.... thoughts? James |
|
From: Jovan K. <cho...@gm...> - 2006-11-17 00:55:22
|
Hi, On 11/16/06, wireless <wir...@ta...> wrote: > Jovan, > > WE agree again! (this is quite scary for me).... Ok, from now on what ever you say I'll take the opposite side :) > But, my question is what do you do when the "big boys" > Do not develop compatibility with Qscada? Reverse engineering > their proprietary portocols, even with a limited measure of success, > will motivate them. I'm sorry, but I do not see Rockwell, Siemens, > etc etc jumping on the Qscada bandwagon, as most have purchased > part or all of companies that have their own SCADA products. > Reverse engineering protocols provides that nudge some may need. > If not, potential users of Qscada, will have an alternative. Good point. I'll check (already found) some existing FLOSS projects of Scada systems for PLC drivers (tested and ready to use). I'll also dig http://forums.mrplc.com for docs and reverse engineered protocols (they had loads of that stuff). We should always have in mind that some companies want "out of the box" solutions and always buy everything from one vendor. Sad, but true :( > If the (legacy) Scada server to PLC communiations involve many > proprietary protocols, migration away from that (vendor's)Scada server > platform can be a lot of work, and preclude many from the effort. That > is why we'll need to suppport these legacy (proprietary) protocols > in QScada. If not this approach, then tell me what is our plan to > attract (migrate) folks from their legacy scada setup to QScada? No, you're wrong (read this yes you're right :) We have to support as much protocols as we can. There are some people somewhere in the world that have already done reverse engineering and rewritten the protocols so we just have to ask them for help. > If we do not have compatibility with the "big boys" on their proprietary > (plc) protocols, migration from other commercial SCADA offerings to > Qscada, may take a long time. Most protocols are "clear text" and > therefore straightforward to reverse engineer.... We do it all the time, > but, as you have elluded, maintaining such code, is time consuming.... As I said before. We can reverse engineer ourselfs or to wait somebody else to do it and all we should do would be writing the protocol by his/hers docmentation, or even easier, change the code that they have written to comform our needs. GREETZ, Jovan |
|
From: wireless <wir...@ta...> - 2006-11-16 19:48:21
|
Jovan Kostovski wrote: >>Besides, we both agree on pushing the RT needs as close to the >>remote hardware as possible. > > Yes that's right. In some situations we can solve the RT problem by adding > two timestamps to the data, one would be the time that the event has occured > set by the RTU, and the other would be the time when it has arrived on > QScada server, > set by the QScada server. That way we'll have the exact time when the event > has occured and when it was registered/logged by QScada. Well, that's very similar to what I had in mind: I would use (2) time fields: [parameter, timestamp, skew] Where the timestamp is the one closest to the first element (i.e. the RTU) and the skew is the delay(difference) in that first timestamp and the next device that can generate an (NTP) timestamp. So between two systems, it's virtually the same parameters, because you can add timestamp and skew to get the second timestamp value. However, if there are more that 2 devices running NTP between he final scada server and the first element (RTU in this example) then you use skew as a cummulative function of the maximum or total delay. That way you keep your RT data to just 2 fields of time (original timestamp and skew) . But if you are having problems and need to debug, then we should have a debug options where all of the timestamps between the final Qscada server and the RTU are kept. For example if somebody has 2 Qscada servers and 2 plc, in ordinary RT mode you'd see date like this [parameter, timestamp-0, skew] in debug mode, you'd see [parameter, timestamp-0, 0] [parameter, timestamp-1, skew-0.1] [parameter, timestamp-2, skew-1,2] [parameter, timestamp-3, skew-2,3] or [parameter, timestamp-0, skew-2,3] depending if you want to subtract or add the skew value.... skew is normally an accumulated value but can be expanded via a link list or other such construct, when needed (debug mode). ???? James |
|
From: Jovan K. <cho...@gm...> - 2006-11-17 01:23:35
|
Hi, On 11/16/06, wireless <wir...@ta...> wrote: > Well, that's very similar to what I had in mind: > > I would use (2) time fields: > > [parameter, timestamp, skew] > > Where the timestamp is the one closest to the first element (i.e. the > RTU) and the skew is the delay(difference) in that first timestamp > and the next device that can generate an (NTP) timestamp. So between two > systems, it's virtually the same parameters, because you can add > timestamp and skew to get the second timestamp value. Really good concept. That way we can measure the time delays of the parameter data when travelling through devices until it gets to the QScada server. There is a small problem: Not all field devices (RTUs etc.) keep track of time. The time of the measurement depends of the device that reads that information. All the other times are relative to that time. So if the first device, the one that reads the informaton doesn't have a clock, who will timestamp that information? The first device on the road that has a clock, or the QScada server? The method that I proposed (t_occured an d t_arrived) is based on the experiences that I have from working on development of SCADA systems. So if the device that read that parameter doesn't have a clock only the t_arrived parameter is filled. I personally like James' method more because time delays between devices can be measured, but the drawback is that every device in the system has to track the time (have a clock). GREETZ, Jovan |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X