Everyday operation of Siwenoid: Difference between revisions

From Siwenoid Wiki
Jump to navigation Jump to search
(Created page with "{{Languages|Everyday operation of Siwenoid}} = Everyday operation of Siwenoid = After starting the software we can see the default screen of Siwenoid (→ The starting scr...")
 
Line 44: Line 44:




* ''' 3; Currently selected datapoint. '''   - Shown in its place of the hierarchy.
* ''' 3; Bulk acknowledge button '''
 
-By clicking on this button every new event in this category is "acknowledged" in the software.
<br style="clear: both" />


->The button doesn't send commands to the subsystems but only registers in the software that the events were noticed by the user.
<br style="clear: both" />


* ''' 4; Commands '''  - The commands what can be send to the datapoint are shown here. You can send commands directly to the system by clicking on the command's icon.
-Many detectors of one connected system can signal simultaneously, for example all detectors of a deactivated zone. In the software these can be acknowledged by one click.






* ''' 5; Commands '''  - All events from the last 24 hours for the selected datapoint are shown here. (This is a filtered extract of the event log and only contain events for the one selected datapoint.)


* ''' 4; Acknowledged / Not acknowledged events '''
-Indicating number that shows how many events we have in the category and how many of them are acknowledged.


-The "1/1" in the example are showing us that we have one event which already have been acknowledged in the software.






=== 2) Parts of the main screen ===
=== 2) Parts, details and usage of the Signal log ===


* '''Attention!''' In Siwenoid every displayed item and view is bound to permissions. A user with fewer permissions can see fewer option than we show here in the manual.
The signal log is the main indication unit of the software where the alerts and disorders are shown from the subsystems.
*Although the signal log and especially the alarms cannot be hidden from any user.
*We rarely can see an empty signal log (shown on he picture) since a bigger site always have some disabled detectors for example.


                                                  Parts of the main Screen!
<br style="clear: both" />
<br style="clear: both" />
[[Image:Installer_v2_telepitesvege11.jpeg|left|thumb|800px]]  
[[Image:Empty_log_1_1.jpeg|left|thumb|800px]]  
<br style="clear: both" />
<br style="clear: both" />


* ''' 1; Main menu '''                         - The settings of the system can be accessed here.
''' Parts of the signal log '''


* ''' 2; Event categories '''                  - The signals and alerts from the connected subsystems all fall into one of these categories. (More in the chapter "Setting up")
The signal log shows every signal coming from the integrated datapoints. All indications are color coded with the represented event's color as in the event categories. This is the primary indication interface for the users.
 
* ''' 3; Main windows '''                      - Under the main tabs we can find the signal log, the datapoint structure and the event log. We also can define our own tabs with maps (for example).
 
  Default tabs:
    ->Signal log - the alerts and other events are shown here.
    ->Datapoint hierarchy - here we can oversee the connected systems in a multi-level tree view
    ->Event log - the software logs every alert and action. We can check and search in the previous events here.
 
* ''' 4; Parts of the signal log '''          - The most important view of the software since all signals, events and alerts are shown here what the transmitters ("datapoints") of the connected subsystems are sending.
 
We can see every datapoint's status here where the status is different from "normal" (alarms, exclusions, line erros etc).
 
* ''' 5; Bulk acknowledge buttons '''          - With these we can acknowledge every alert in the corresponding category (This is ackknowledgement in the software only, no commands are sent to the security systems).


*Alarms (red background by default) are always shown on top of the screen so they never get lost among the list of disabled sensors.
*If the category of the event is hidden then the signals from that category aren't shown in the signal log (but they can be acknowledged from the event category buttons).


<br style="clear: both" />
[[Image:Signal_log_1_1.jpeg|left|thumb|800px]]
<br style="clear: both" />


 
'''1; Icon of the category: '''    The default icon of the category of the event.
=== 3) The workplaces of the main screen ===
<br style="clear: both" />
<br style="clear: both" />
[[Image:Ablakok_helyei_%27.jpeg|left|thumb|800px]]
'''2; Timestamp: '''              The time of receiving the event.
 
<br style="clear: both" />
<br style="clear: both" />
 
'''3; Physical container: '''       From which physical container is the signal coming from.
We can arrange 4 workspace on the main screen by dragging their side. On these workplaces we can arrange views of the application as we like.
 
''' Tabs what can be shown on the workplaces '''
 
Onto these 4 place we can open different application views with the "+" button on top.
 
 
These can be:
 
-Signal log
<br style="clear: both" />
<br style="clear: both" />
-Datapoint hierarchy screen
'''4; Datapoint's name: '''        The name of the signaling datapoint
<br style="clear: both" />
<br style="clear: both" />
-Event log
'''5; Description of the error: ''' The caouse of signaling (In the example the licenced client application is not connected to the server, so the status is "CLIENT DISCONNECTED".)
<br style="clear: both" />
<br style="clear: both" />
-Any map
'''6; Status of the signal: '''    The fresh, not yet acknowledged signals backgound is blinking.
<br style="clear: both" />
<br style="clear: both" />
-Logical containers (Sub-trees of the datapoint hierarchy)


The status of hte signal can be:


*New event (blinking line)
*Acknowledged event (not blinking line)
*Deleted event (black background, inverted text color)


The intervention texts for events also opened on the workplace prevoiusly setupped for it.




 
'''Buttons: '''
=== 4) Overview of the datapoint hierarchy screen ===
 
'''7; Default command: ''' The command we most likely want to send to the system in case of this signal.
*If by the event's type it's not clear what command should be sent then the button is disabled. Even though by right-clicking on the disabled button we can see the list of possible commands what we can send to the datapoint.
*The default command is predefined in the software based on the integrated subsystem and the type of the datapoint.
'''8; Show on map: ''' If the signaling datapoint is placed on a map (green backgound on hte button shows that) we can open the corresponding map and see the datapoint by pressing the button. Tha datapoint's backgound blinks for a few times with the color of the signaling event's category.
<br style="clear: both" />
<br style="clear: both" />
The Datapoint hierarchy scree shows the physical and logical containers of datapoints in a hierarchical tree view. All important details (→1,2,4,5) of the currently selected datapoint (→3) are shown.
'''9; Intervention text: ''' Every datapoint can be assigned with an Intervention text what pops up every time the datapoint is signaling an event. This helps the end-users to help in the typical methods of solving events.(For example "The zone can't be re-set while the windows are open."
 
)
The datapoint hierarchy screen have 4 different sections. The left side shows the logical and physical tree of the datapoints.
<br style="clear: both" />
 
'''10; Write a comment: ''' We can write comments to the events if it is necessary to document the events.(For example "Cause of disabling: maintenance".)
The right side of the panel if split into 3 sections.
<br style="clear: both" />
<br style="clear: both" />
 
'''11; Show in tree: ''' If we click on this button the datapoint will be selected in the datapoint hierarchy tree.
[[Image:Hierarchy_v2.jpeg|left|thumb|800px]]
<br style="clear: both" />
<br style="clear: both" />


* ''' 1; Datapoint informations '''      - The tecnical name (what is inherited from its physical container), the type and the name of the physical container of the datapoint is shown here.(These informations are necessery since the datapoints can be renamed in the software and can be moved to logical containers.)


* ''' 2; Treatments (statuses) '''    - The possible statuses of the selected datapoints can be seen here. The current status of the datapoint is highlighted (except "Normal").
=== 3) Deleted events: events with black background ===


* ''' 3; Currently selected datapoint. '''  - Shown in its place of the hierarchy.
The signals with black background can be acknowledged / hide from the signal log by one click. These are statuses what are not present by the time of viewing it in the software. So the users won't miss any events even if they had been acknowledged on a secondary client, or on the connected unit.


* ''' 4; Commands '''  - The commands what can be send to the datapoint are shown here. You can send commands directly to the system by clicking on the command's icon.
[[Image:Jelzesnaplo_elemei_inverz.jpeg|left|thumb|800px]]
 
<br style="clear: both" />
* ''' 5; Commands '''   - All events from the last 24 hours for the selected datapoint are shown here. (This is a filtered extract of the event log and only contain events for the one selected datapoint.)
'''When can we see signals with inverted background?'''


*For example we don't have to send command to the fire alarm unit if the event were acknowledged on the unit itself.
*If someone on a different Siwenoid client is acknowledged the signal. (And acknowledgement by clients is setupped in Siwenoid)


=== 5) The event log ===
=== 4) Detecting and handling alarms from central units and datapoints ===
<br style="clear: both" />
Every incoming and outgoing events, signals and commands are logged in Siwenoid with one second accuracy. So every event can be traced back, can be filtered and can be exported.


[[Image:123.jpeg|left|thumb|800px]]
<br style="clear: both" />


* '''1;''' Every events are shown by the color of its event category. The time, status and the corresponding datapoint is shown.


* '''2;''' Filtering options. We can search and filter the event log by date and time interval, plus we can search for phrases and names with the input fields under the columns.


* '''3;''' Exporter buttons. The filtered event log of the Siwenoid software can be printed or exported in .XLSX, .CSV and interactive HTML format.


* '''4;''' Frequent searches (like a specific door's signals or often alerting smoke detector) can be saved for quick access. These can be loaded instantly from the dropdown menu (fast search).
<br style="clear: both" />
<br style="clear: both" />
<br style="clear: both" />
<br style="clear: both" />
<br style="clear: both" />
<br style="clear: both" />

Revision as of 14:37, 13 June 2018

Language: English


Everyday operation of Siwenoid

After starting the software we can see the default screen of Siwenoid (→ The starting screen of Siwenoid)

On everyday operation this screen is what we use most frequently.

1) The event categories bar

On the top of the screen we can see all categories in which every signal from the subsystems are arranged into. The colors of the categories are matched to the colors of the Signal log.

  • The bar of the event categories are not part of the Signal log but it makes the use of it easier.
  • The event categories are always visible and cannot be hidden no mater what window arangement we use.
  • Straight forward colors: On the maps, in the event and signal log we see the colors of the event categories. So we can know that every text with red background is about alarms.




  • 1; Event categories

- All signals, events, alerts from the subsystems are arranged into these categories.
-> "NORMAL" status is not shown in the bar of event categories since it is never shown in the signal log.
- Normal status is everything when the datapoint is operational and capable of communicating, like an activated smoke detector, an armed intrusion zone etc.


  • 2; Hidden event category

-We can hide signals from a specific category by clicking on its name. On this case every signal from the selected category are hidden from the signal log.

-> The background of the hidden categories are transparent.
-> We cannot hide the "ALARM" category.

-When servicing a fire alarm unit many detectors can be "Excluded". This can interfere the visibility of the signal log.



  • 3; Bulk acknowledge button

-By clicking on this button every new event in this category is "acknowledged" in the software.

->The button doesn't send commands to the subsystems but only registers in the software that the events were noticed by the user.

-Many detectors of one connected system can signal simultaneously, for example all detectors of a deactivated zone. In the software these can be acknowledged by one click.



  • 4; Acknowledged / Not acknowledged events

-Indicating number that shows how many events we have in the category and how many of them are acknowledged.

-The "1/1" in the example are showing us that we have one event which already have been acknowledged in the software.


2) Parts, details and usage of the Signal log

The signal log is the main indication unit of the software where the alerts and disorders are shown from the subsystems.

  • We rarely can see an empty signal log (shown on he picture) since a bigger site always have some disabled detectors for example.



Parts of the signal log

The signal log shows every signal coming from the integrated datapoints. All indications are color coded with the represented event's color as in the event categories. This is the primary indication interface for the users.

  • Alarms (red background by default) are always shown on top of the screen so they never get lost among the list of disabled sensors.
  • If the category of the event is hidden then the signals from that category aren't shown in the signal log (but they can be acknowledged from the event category buttons).



1; Icon of the category: The default icon of the category of the event.
2; Timestamp: The time of receiving the event.
3; Physical container: From which physical container is the signal coming from.
4; Datapoint's name: The name of the signaling datapoint
5; Description of the error: The caouse of signaling (In the example the licenced client application is not connected to the server, so the status is "CLIENT DISCONNECTED".)
6; Status of the signal: The fresh, not yet acknowledged signals backgound is blinking.

The status of hte signal can be:

  • New event (blinking line)
  • Acknowledged event (not blinking line)
  • Deleted event (black background, inverted text color)


Buttons:

7; Default command: The command we most likely want to send to the system in case of this signal.

  • If by the event's type it's not clear what command should be sent then the button is disabled. Even though by right-clicking on the disabled button we can see the list of possible commands what we can send to the datapoint.
  • The default command is predefined in the software based on the integrated subsystem and the type of the datapoint.

8; Show on map: If the signaling datapoint is placed on a map (green backgound on hte button shows that) we can open the corresponding map and see the datapoint by pressing the button. Tha datapoint's backgound blinks for a few times with the color of the signaling event's category.
9; Intervention text: Every datapoint can be assigned with an Intervention text what pops up every time the datapoint is signaling an event. This helps the end-users to help in the typical methods of solving events.(For example "The zone can't be re-set while the windows are open." )
10; Write a comment: We can write comments to the events if it is necessary to document the events.(For example "Cause of disabling: maintenance".)
11; Show in tree: If we click on this button the datapoint will be selected in the datapoint hierarchy tree.


3) Deleted events: events with black background

The signals with black background can be acknowledged / hide from the signal log by one click. These are statuses what are not present by the time of viewing it in the software. So the users won't miss any events even if they had been acknowledged on a secondary client, or on the connected unit.


When can we see signals with inverted background?

  • For example we don't have to send command to the fire alarm unit if the event were acknowledged on the unit itself.
  • If someone on a different Siwenoid client is acknowledged the signal. (And acknowledgement by clients is setupped in Siwenoid)

4) Detecting and handling alarms from central units and datapoints