A monitoring software idea

[pourkascheff]

Hi all, o7.
I'm working on a monitoring software in VB.NET but I'm looking for its idea, the way it works, even if it's not in VB or C#, instead being a flowchart. Since there is other old school congeners living out there perfectly, without an error. Before creating a huge mess, I wanted to taste a few thing first, seeking advice from you experts, then dive into it and share results for people with similar difficulties.

1) This thing asks a lot of external RS485 devices through 8 COM ports (Do you people transmit individually? I mean since it is sequential first it finishes COM1 then goes to 2 or you write it in a parallel way with BackgroundWorker thing?).
2) Then arrange all 300 parameters (Which each has a control on form either boolean (0, 1) or single or integer) based on their specified limits (minimum and maximum) if their offscan is false, for a not normal value, after spending an on-delay if condition still remains, trigger the alarm.
3) Missing a device will also considered as alarm.
4) Alarms should behave like a flip-flop way. Meaning that triggering it then getting normal immediately, is still alarm. In alarm history it turns to NORMAL but symbol is flickering and sounder is buzzing. After clicking on "Acknowledge" button Alarms (which are still alarm) turn from flickering to steady on and for normal ones will be rectified and steady off.

There is no documentations neither open-source examples nor algorithm-name is available.

What do you suggest to start?
Those 300 parameters/symbols (we call it tags) and their related names, offscan, on-delay, serialframe address, current value, compression value and status should be a CSV DGV table or dictionary? Cause it seems functions being repeated for them all. i.e.
001, House power main braker fail, False, 100, A2.2, True, False, Normal

Should I cycle a timer for getting new data (interpolation) and another for raising alarm?

[pourkascheff]

Well, As an update, I only find out that this is called SCADA (Supervisory control and data acquisition) which lots of industrial first class companies (Like Siemens and Omron) introduced their own pre-build designing environments based on this. I still have no idea the core's logic beneath the surface to mimic for my WinForm application. I was looking for a sort of name like 'Troy Horse' or something assigned/dedicated only for these kind of software. "Praxis Automation" and "Kongsberg NOR Control" marine companies are also providing such platforms for their machineries, hoping one of them had an open stem/sketch one like how Code.NASA.gov provided for inspiring/influencing people.

[Shaggy Hiker]

Just from the sound of it, I'd say that pretty much all the communication should happen on threads, not in the foreground. That might be just a BackgroundWorker object, or it might be one thread dedicated to each of the COM ports. The latter solution would likely mean that they'll step all over one another, which may or may not be an issue. It all comes down to the timing. Waiting on a port is an ideal use of a thread, since the thread will spend a fair amount of time doing nothing but waiting. Lots of simultaneous threads can operate in that kind of environment. However, if they all get activated quickly, the order of activation will be totally unpredictable. If that's an issue, then a single background thread that deals with one COM port, then the next, then the next, and so on, would be better.

[2kaud]

How much data is to be received from a com port when data is present to be received? How frequently must each com port be serviced? How fast is the data transmitted from the device? RS485 can support up to 10Mbits/s but how fast can the com ports receive?

Since RS485 supports a linear bus topology, why are multiple com ports being used when you could just use 1?

[pourkascheff]

why are multiple com ports being used when you could just use 1?

Indeed. Since the master node (PC) is using MOXA PCI 8 COM ports and also different baud rates with various handshake/parity configuration. So I rather remain faithful to previous hardware architecture.

Can we concentrate on the alarm raising logic I asked earlier people?