data classification, ui widget & data integration and interaction

[saman_artorious]

I need to monitor data on a widget(on which a system scheme or image is laid out). My main question is how to classify and organize data to that monitoring becomes easy and also the best way I can show monitor data in the program, considering the space limit on the Main Window.

The monitoring data include System signals, alarms and command sent relevant to the specific signal or alarm. signals only give data showing the current status of a sub-component, whereas alarms are triggered when something abnormal happens. let's say temperature increases over x. The commands user input according to the signals and alarms warnings shown in the scheme.

let's jump in the main problem:

as I mentioned above the scheme of a particular sub-system is shown on the main window. The main scheme of sub-system shows its components to the user, it is an image. Signals, alarms and commands are categories in which if the user selects one, it adds data to the main scheme. So, if I choose signals from the let's say combo box it shows and adds signals to the main scheme, same to Alarms and commands. as I don't have enough space and the number of signals and alarms are much I need to monitor it in a perfect and tricky way.

Does anyone had any experience with this before? if so, could you let me know about the best way to program this problem. besides what classes do you classify to handle signals and alarms?
uh, I almost forgot, another very important thing is the relation between signals and alarms. for example one signal shown in a the scheme of sub-system x may be relevant to another sub-system y. because of a lack in space what is the best way to make this monitoring easily-shown to the user?

an example:
In the main scheme if i choose system x, it shows its scheme. let's say some component of this subsystem's temperature increases so that if it increases more than a number, or if it turns off or if doesn't get closed, a relevant signal or alarm may rise, in this case this is an alarm, bcoz it is abnormal situtaiton, how to show it?
signals of this are regular receiving data that shows its current status. in any case user enters commands a pre-defined decision by inputing data like pressing a button or any kind.

I want to know how to classify this things in code with classes so that everything becomes encapsulated. and the best way to monitor the whole system with alarms, signals and rising commands according to lack of space I have.

[d_stranz]

First, as they say, "Do not confuse the map and the terrain". In other words, the map is just a picture of the problem, it isn't the problem itself. So, you have two different issues here:

1 - How to create an architecture that will allow you to monitor (and maybe control?) all the devices in your process, independently of how that information is displayed on screen and
2 - How to display the status of the system and react to problems independently of how the system status is recorded.

I assume you have some kind of low-level control library that lets you identify and monitor specific devices. I would start by creating a QObject subclasses (maybe "MonitoredObject", "MonitoredDevice", "MonitoredSubsystem") which you can use to wrap the low-level devices and systems and convert the low-level monitoring information into Qt signals. If you make this class general enough, it can encapsulate the behavior of most of the devices, even if the details are slightly different. You can then derive more subclasses from this to model specific devices.

I would also develop another class hierarchy, something like QEvent, where you can have a generic "MonitoredEvent", which maybe gets further refined into "TemperatureEvent", "PressureEvent", etc. with data members specific for that kind of measurement. Your MonitoredDevice classes can emit signals with the appropriate event types: "deviceAlarmEvent( MonitoredEvent * )", "deviceStatusEvent( MonitoredEvent * )" to communicate with the outside world.

MonitoredDevice instances can be combined in "MonitoredSubsystem" collections. Here, you can establish relationships between devices which occur in the same subsystem. If the temperature of process A goes too high, the deviceAlarmEvent() from temperature monitor A can be connected to a slot in the TemperatureController instance for A which will turn the heat down. Other subsystems do not need to know about this, since it is handled internally. However, if a problem in one subsystem can cause a problem in another subsystem (a pressure surge in subsystem A can cause problems in other subsystems in the same pipe network), then subsystems can emit signals that can be monitored by others: "subsystemAlarmEvent( MonitoredEvent * )" where the detailed event information includes the ID for the device that raised the alarm.

Notice that none of this discussion says anything (so far) about the display of the information. All of the activity around monitoring and controlling the system is completely encapsulated, totally independent of the display.

So, now you need to display the status on screen. Here, I would use the Qt Graphics/View architecture. I would create a QGraphicsObject subclass that mirrors each of the MonitoredObject subclasses in the monitoring hierarchy. These QGraphicsObject classes provide the visual display of the device status, and can have a different appearance depending on the device type (a temperature monitor looks like a thermometer, maybe) and can change their display depending on the device status.

You also make a QGraphicsObject subclass that represents MonitoredSubsystem instances. These contain child graphics objects that represent the monitored devices and the connections between them. This is where you can make use of the "level of detail" feature of the Graphics/View architecture. At a very high level, you can display a rectangle for each subsystem with lines that connect the subsystems that are wired or plumbed together. The rectangle has a color or other display that indicates its status - green for normal, yellow for warning, flashing red for emergency. Zooming in can display the subsystems inside a bigger one, zooming in more can display individual devices with their status and connections. (See the 40,000 chips demo (http://qt-project.org/doc/qt-4.8/demos-chip.html) in Qt to see what I mean).

Since each QGraphicsObject is responsible for a single actual MonitoredObject, you can connect slots in the graphics object with the same signals used by the monitoring hierarchy; these slots will cause changes in the display of the object's status, but nothing else. The monitoring hierarchy controls the devices themselves. If the user can control and change process settings through an interaction with the GUI (say, clicking on a temperature controller icon allows changes in the setpoint), then the graphics object should emit signals (with a "ControlEvent" pointer that the MonitoredDevice can be connected to.

I'll let you think about it. The basic idea is that Qt provide you with some great programming tools that can allow you to completely encapsulate different parts of your architecture in a way that allows you to implement and test the parts independently. The connections between the parts are realized using the signals and slots mechanism. If you keep the separation between the monitoring subsystem and the display subsystem clear in your head as you design and implement the system, you will end up with something that is very flexible and easy to change as the physical system changes - a Model 123 temperature sensor breaks and is replaced by an improved Model 124 temperature sensor, but except for replacing some small bit of code for that specific device code (or better yet, a configuration database that is read in at runtime to define the in-silico model of the system - similar to the XML used in .ui files to define the GUI), nothing else changes anywhere.

[saman_artorious]

what I have at hand is a serial lib for serial transportation to receive sensors data and send to it. And... a bunch of classes, one class per subsystem. All objects serialReceive slot() is connected to the sendToObject(QByteArray) signal of the serial class. This way, subsystem objects can update their own members. For the interactions of the subsystems, I connect the subsystem signals and slots. Their communication and interaction is of no concern this way. Let's forget about the display part for now, I just want to know if this method is o'rite. it would be nice if you tell if there is anything wrong with this method! so that I can correct it step by step. besides, honestly...i didn't understand your method.. so, I will be very happy if you can show me your visualization with some sample code. tnx

[saman_artorious]

First, as they say, "Do not confuse the map and the terrain". In other words, the map is just a picture of the problem, it isn't the problem itself. So, you have two different issues here:

1 - How to create an architecture that will allow you to monitor (and maybe control?) all the devices in your process, independently of how that information is displayed on screen and
2 - How to display the status of the system and react to problems independently of how the system status is recorded.

I assume you have some kind of low-level control library that lets you identify and monitor specific devices. I would start by creating a QObject subclasses (maybe "MonitoredObject", "MonitoredDevice", "MonitoredSubsystem") which you can use to wrap the low-level devices and systems and convert the low-level monitoring information into Qt signals. If you make this class general enough, it can encapsulate the behavior of most of the devices, even if the details are slightly different. You can then derive more subclasses from this to model specific devices.

I would also develop another class hierarchy, something like QEvent, where you can have a generic "MonitoredEvent", which maybe gets further refined into "TemperatureEvent", "PressureEvent", etc. with data members specific for that kind of measurement. Your MonitoredDevice classes can emit signals with the appropriate event types: "deviceAlarmEvent( MonitoredEvent * )", "deviceStatusEvent( MonitoredEvent * )" to communicate with the outside world.

MonitoredDevice instances can be combined in "MonitoredSubsystem" collections. Here, you can establish relationships between devices which occur in the same subsystem. If the temperature of process A goes too high, the deviceAlarmEvent() from temperature monitor A can be connected to a slot in the TemperatureController instance for A which will turn the heat down. Other subsystems do not need to know about this, since it is handled internally. However, if a problem in one subsystem can cause a problem in another subsystem (a pressure surge in subsystem A can cause problems in other subsystems in the same pipe network), then subsystems can emit signals that can be monitored by others: "subsystemAlarmEvent( MonitoredEvent * )" where the detailed event information includes the ID for the device that raised the alarm.


I need more explanation for this please, need to understand how this method works. I would thank if anyone could represent this with a sample code skeleton please.

[d_stranz]

I need more explanation for this please, need to understand how this method works. I would thank if anyone could represent this with a sample code skeleton please.

I don't have any sample code - this was just a concept idea. It would take a lot of work to come up with a working example. Maybe I can draw a picture instead. Be patient - I also have a job.