How to manage Security Dashboard?

Modified on Fri, 19 Jul at 12:44 AM

Enabling the security alerts for the site

Site administrator => Config dashboard => security configuration => Rules configuration => Alerts which you have to enable for the site => Enable the master switch

Providing Access to security dashboard alerts and safe reach dashboard

User Created to monitor the Security alerts should be added in the Employee security rules.

Site administrator => Security configurations => Employee security rules => Add employee => Add required Alerts to monitor => save

(Please note : You will only see the alerts which is enabled in the config dashboard in the list to add)

Modify the list of alert access provided Search for employee =>Click on Modify => Select/deselect the required alerts => Save

Common Issues and Cause

User is not able to see the security dashboard/ Security dashboard is not enabled for the user.

Steps to debug : Goto => Site administrator => Security configurations => Employee security rules => Search for the user profile (Name/Email) who is not able to see the security dashboard => See if all the alerts which are asked for are added to that profile.

If the Name is available => Reply to the client that the security dashboard is added to the user
If the Name is not available => Share the steps to client how to add the profile and add alerts to the user(Steps shown above)

Security dashboard UI

Open security dashboard => Site administrator => Security dashboard => All the alerts which are added for the user in employee security rule will be visible in the security dashboard.

Alerts raised on the security dashboard will be visible in the alert specific dockets.
Clicking on the required docket will give a list of alerts triggered.
Clicking on the alerts will give you the details of the alerts on the right side window.
Once after checking the alert details we can investigate with the employee/driver/escort regarding the incident and based on the criticality of the incident we can mark the severity.
Once after selecting the severity, We can close the alert by selecting the resolved button if the investigation is completed, Or we can click on unresolved if the investigation is still going on and you need to check the other alert.

Common Issues and Cause

Alerts not showing in the docket/ Alerts count are showing but the alert is not showing in the list.

Steps to debug => Clear the browser cache/ Logout and Login again/ Use private network/ Check internet Connectivity

Overspeeding Alert

Description

If any vehicle is overspeeding more than the configured speed and for the configured time period then we will be triggering an alert on the security dashboard.

Overspeeding can be calculated through the driver device and fixed device.

Configuration dependency is both on device and ETS side.

Dependency

Devices should be connected to good internet connectivity.
Devices should continuously be contacting the server for real time alert triggering.

Configurations

Device side:

SPEEDING_ALERT_ON - master switch to enable speed alert on device side.

SPEEDING_AUDIO_ALERT_TEXT("Overspeeding alert. Please slow down.") - Audio alert on driver device if the configured speed is crossed.

TRIP_SPEED_LIMIT_IN_KM_HR - Device side configuration to set Speed threshold in KMPH during the trip after which the alert to be raised on the security dashboard.

DEAD_LEG_SPEED_LIMIT_IN_KM_HR - Device side configuration to set Speed threshold in KMPH in the dead leg after which the alert to be raised on the security dashboard.

ETS side :

Master switch to enable overspeeding alert on ETS

Overspeeding threshold [KMPH] - Speed threshold in KMPH during the trip after which the alert to be raised on the security dashboard.

Device Grace time before raising alert (sec) - Time threshold after which the audio alert to be raised on the driver device.

Dashboard Grace time before raising alert (sec) - Time threshold after which the alert to be raised on the security dashboard.

Switch to enable if the alert should be raised on dashboard during dead leg(Time between duty start and before the first employee sign in)

Speed threshold [KMPH] in dead leg : Speed threshold in KMPH in the dead leg after which the alert to be raised on the security dashboard.

Switch to enable the Alert Validation through Fixed GPS Data

Time Duration in which the latest fixed GPS information is fetched from alert time : This represents the time window in which the latest fixed GPS information should be retrieved from the alert time.

Speed Tolerance (in kmph)

Alert ignored if speed difference between in-cab & fixed GPS falls within configured threshold in specific time:This signifies the maximum allowed difference between the In-Cab Device speed and Max Speed fetch from fixed GPS data within the configured time window. If the speed difference exceeds this tolerance , the alert should be discarded.

Configure Email Id's in the text box to receive email update for alert : Email Id’s should be separated by commas

Alert Closure Comments : Predefined comments to select while closing the alerts, Comment can be mentioned separately for the genuine alerts and the false alerts closure.

Comment will be visible here as shown below.

Common Issues and Cause

Overspeeding alert is not getting raised

Investigation Steps =>

Device side configuration(check the configurations above) - True
ETS alert master switch is enabled(check the configurations above) - True
Speed set in the ETS and device side configuration is Same (check the configurations above) - True
GoTo=> Dashboard => Vehicle Id/Reg number => Date of alert => Device Health Logs=> Vehicle has crossed the set limit in Configuration (Check in device health Log) - If the configurations are right and device has crossed the set limit you will get an entry saying “Overspeeding is confirmed” in device health log. If the mentioned entry is created in the health log the overspeeding alert should be raised on the security dashboard => Check in overspeed report.

If the alert is available in report => Reply client with SS that the alert is showing in report.
If the alert is not in report => Raise TS with all the investigation steps and SS.

Speed mismatch between the actual speed of the vehicle and that is recorded on server while alert is raised.

Investigation Steps =>

Check the Speed in the health logs when overspeed is confirmed, In the below SS it is 18.366837 m/s converting it into km/hr is 66.120, So alert is raised at 66.12 Km/hr.
Check whether the Speed said by the customer is similar around the speed captured in health logs, If the difference is more than 10 km/hr then move the ticket to Driver POD/ Raise TS with the findings
Also attach the speed recorded in the overspeeding report in the TS.

Overspeeding alert is not raised in real time on the security dashboard.

Investigation Steps =>

Check the time at which the overspeeding is confirmed in health logs => Check the real time and the last successful polling time
If both the time is matching and pending requests are 0 => Then alert should have raised in real time
If the real time is more than the last successful polling time (Minimum 1 min) => Then alert would not have been raised in real time => check the difference in the time and reply to client that the alert is raised in delay due to device internet issue.

Overspeeding audio alert is not triggering on the driver device.

Investigation Steps =>

Check the ETS config whether the limit is set for audio alert (check the configurations above).
Check the audio text is set in device side configuration (check the configurations above).
If the configurations are set then you will get an entry shown below in the health log for audio alerts triggered on the driver device.
Share the SS and reply to the client.

Vehicle Stoppage Alert

Description

Vehicle stoppage alert is triggered when a vehicle stays at the same location more than the configured time (usually 10-15 mins).

Dependency

This alert is completely dependent on driver device location and if the driver device moved without vehicle being moved then the alert won't be raised, Driver device should be in the same location for the configured time period.
Device should be contacting the server in real time.
Alert will only be raised if the employee has signed in.

Configurations

Device side:

ENABLE_VEHICLE_STOPPAGE_ALERT - Enable vehicle stoppage monitoring on device side.

ETS side :

Go to employee profile icon>>> site administrator>>>configure dashboard>>>Security configuration>>>Rules configuration>>>vehicle stoppage.

The ON/OFF button in front of vehicle stopped alert depicts that the site having this feature enabled

Vehicle stoppage alert can be configured for planned/adhoc trips or both at the same time.

If enabled for planned trips, it will raise alerts only to planned trips in the system.

If enabled for an Ad Hoc trip, It will raise an alert on violation even if the trip is unplanned.

Alert buffer time where if the vehicle is stopped for more than the configured time, Alert will be raised on the dashboard.

Eg: For a configured time of 5 min, if the vehicle stays at one point just more than 5 minutes , an alert will be raised on the dashboard.

This window allows you to configure a certain period of day to raise the alert, we have 2 sets of such configuration where we can set 2 different time periods with customized buffer time.

We can also monitor the vehicle stoppage alert using a fixed GPS device.

In the below configuration we can set the time range in minutes within which alerts from the Driver app and server will be combined. Alerts occurring within this window will be considered for clubbing

Also we can set the minimum displacement (in meters) to trigger a stoppage alert. If the vehicle remains stationary for the configured time (in minutes), an alert will be generated

The vehicle stoppage alert will only trigger if the vehicle is out of the configured radius in mtrs from the office geocode.

Below explains three condition for which vehicle stoppage can be enable

(i) vehicle stoppage can be enabled for any employee( any gender)

(ii) trip which has one or more women employee signed in

(iii) trip containing only women employee

This configuration automatically closes the alerts as per as configured time if no action taken on the alert.

This configuration sends email to the subscribed person (people enlisted in employee security rules) for alert notification.
Any updates related to alert acknowledgement and closure will be shared on the same email id.

Common Issues and Cause

Vehicle stoppage alert is not raised even when the vehicle is stopped for configured time

Investigation Steps =>

Check whether the ETS Master switch is enabled or not?
Check if the device side configuration is enabled or not?
Check the alert is considered for the trip type of the reported Trip Id.
Check the alert window set and the trip start time of the trip Id shared by client, Trip start time should be between the set window.
Check if the vehicle was inside the radius set in configuration at the client reported time.
Check whether the employee type set in configuration is on the trip.
Check if the geocode of the vehicle was the same for the reported time frame (If client is saying that from 12:00 to 12:05 the vehicle was not moving, Geocode should be the same from 12:00 to 12:05).
If all the above points are met then alert will be raised from the driver device with below mentioned message in health log.

You can see the geocodes from the time 8:24 to 8:34 hence the alert raised.

Vehicle stoppage alert is raised even if the vehicle is continuously moving.

Investigation Steps =>

Check in the device health logs for the alert raised time the geocodes are the same for configured time.

If the geocodes are the same then an alert will be raised.

If the geocodes have changed more than 10 mtrs alert will not be raised

SOS From Device /Mobile app /Fixed device

Description

SOS from driver device : SOS button is available in MoveInSync app on driver device from which any person traveling in the cab can press to raise an emergency alert to the transport team.

SOS From fixed device: SOS is available as a physical switch fitted inside a cab from which any person traveling in the cab can press to raise an emergency alert to the transport team.

SOS from mobile app: Moveinsync employee app has a SOS button from Employee can press to raise an emergency alert to the transport team.

Dependency

Devices should continuously be contacting the server for real time alert triggering.
Fixed device should be registered in the Manage fixed device page and tagged with the correct vehicle ID.
SOS from device can be raised only after starting the duty
SOS from Mobile App can be raised between 30 Min before trip start time and 30 after trip end time (This 30 min is configurable.)
SOS fixed device can be raised anytime.

Configurations

SOS from mobile app: ETS configurations are same as SOS from device.

Mobile app side configuration:

sos: true

minutesBeforePickup: 30

minutesAfterDrop: 30

SOS Alert From Fixed Device : ETS configurations are the same as SOS from device.

SOS Alert From Device : Master switch to enable the alert
SOS IVR Call : Calls will be triggered to the escalation matrix if the alert is not closed within the configured time in the escalation matrix.

(Please note : Other fields are explained in the other alert configuration, The functionality is similar for all alerts.)

For the alerts which are closed under SEV1 that are high severity, Notification will be triggered through SMS for the numbers configured in the escalation matrix.

Audio alert will be triggered for every new alert raised on security dashboard (This feature only works for SOS/ Panic alerts)

Common Issues and Cause

Alert is not raised even after pressing the SOS button.

Investigation Steps =>

Check if the alert is raised at the time between 30 min(Configurable) before the planned trip start time to the 30 after(Configurable) the planned trip end time.
If the alert SS is shared from the client and the alert is not in the report at that time, It might be due to Mobile internet not working.
Ask the client to test the same again and share the instances, If this is frequently happening and for multiple users then raise TS with instances.

Getting a failed error even if we are raising the SOS alert from the mobile app within 30 min of planned trip start/trip end time.

Investigation Steps =>

Check the time buffer set on mobile app side configuration.
Check if the alert is raised at the time between 30 min(as per configuration) before the planned trip start time to the 30 after(as per configuration) the planned trip end time.
If the alert is raised outside the window then share the configured window to the client and close the issue.
If the alert is raised inside the window then raise TS.

SOS fixed device alert is not raised

Investigation Steps =>

Fixed devices to be registered to manage fixed device.
Vehicle should be active when the alert is raised.
Logs should contain the Panic=True command while sending to moveinsync.
Fixed device should be contacting in real time at the time of the alert raised.
IMEI in the logs should match the registered IMEI in manage fixed device page against the vehicle.
If all these conditions are met and the still alert is not found in the dashboard and report, we can further investigate.

Device Not Reachable

Description

If the driver device/fixed device is not contacting the server for configured time, Then we will receive an alert on the security dashboard.

Dependency

This alert will be raised only when the trip is in progress.

Configurations

Master switch to enable the Alert

We can enable from the below option as to which type of trip should be considered for the alert.

If the device fails to connect to the server within a specified time period, an alert will be triggered.

Below option is given to specify at which part of the day alert should be triggered

Below explains three condition for which vehicle stoppage can be enable

(i) Vehicle stoppage can be enabled for any employee( any gender)

(ii) Trip which has one or more women employee signed in

(iii) Trip containing only women employee

Alert will be raised only if the vehicle is outside the set radius of office location

Common Issues and Cause

Device is polling still alert raised.
Alert is raised after the employee signs off/ trip completed.

Employee Sign Off Time Violation

Description

Alert will be raised on the security dashboard if the employee sign off is not received within the set buffer time.

Dependency

Driver devices should contact in real time to get genuine alerts. If the device is not contacting the server there will be delay in capturing the sign off on the server in real time.

Configurations

Master switch to enable the alert

For which direction of trip alert should be raised(Login / Logout)

Type of trip and respective buffer time can be set using below configuration.

Buffer Time After Planned Employee Sign Off Time To Raise Alert (Min): Buffer time will be calculated from the planned sign off time.

Buffer Time After Trip Start Time To Raise Alert (Min): Buffer time will be calculated from the planned trip start time.

Common Issues and Cause

Alert is raised even after the sign off is done before the buffer time.

Employee Geo Fence Violation

Description

Alert will be raised if the employee is dropped/signed off outside the set radius.

Dependency

Configurations

Time of the day during which alert is to be raised.

Trip type which has to be considered for triggering alert

Gender selection to trigger the alert.

An alert will be triggered if a sign-off occurs beyond a set radius.

Option to select which vehicle type to ignore while raising alert.

If the below option is enabled then alert will not be raised if the driver ends the trip without entering signoff OTP.

Common Issues and Cause

Geofence alert is raised even if the employee signs off in the office location.

Investigation Steps =>

Check for the office radius set and check the actual distance between the actual signed off geocode and office geocode.

Office geocode will be found in MIDadmin=> Data Upload => Manage Office => Copy the geocode of trip Office.

Employee sign off geocode can be fetched by health log => search employee Name => check for the sign off location after the employee signs off.

Check the distance between employee sign off location and office geofence, If it is more than the set radius reply to client that the alert raised is genuine.

Distance calculated should be aerial distance.

Additionally check whether the accuracy of the geocode is less than 20

Geofence alert is not raised even if the employee signs off in another location.

Investigation Steps =>

Check whether the shift is falling under the window set in config.
Check whether the trip type of reported trip is considered for raising alert.
Check if the user is falling under the employee type is considered for raising alert.
Make sure that the vehicle type assigned to the trip is not disabled for this alert.
Check if the employee's sign off location is outside the set radius or not If yes then alert be raised and if the alert is not found in the report even if all the above conditions are met , Raise TS with SS.

Woman Traveling Alone

Description

Alert will be raised if the women employee is traveling alone without a male employee/Escort

Dependency

Configurations

Master switch to enable the women traveling alone alert

Time of the day when the alert is to be raised.

Trip start time should fall into this window then alert will be raised.

The buffer time after which the alert will be raised if the women employee is alone in the trip after the buffer time system also checks whether the current location of the employee is outside the set radius or not if yes the alert will be raised.

If the below option is enabled then the alert will be raised even if the male employee/escort is signed in to the trip.

Common Issues and Cause

Women traveling alone alert is not raised even if the woman is alone in the trip.

Women traveling alone alert is raised even if the women signed in beyond the set time window.

Investigation Steps =>

Check the alert trigger time in the report/email shared by the customer.
Check the configured set window, If the trip start time is inside the window alert will be raised then reply to the client that trip start time is inside the set window.

(Note: Alert time window switch should be enabled)

In below example the configured window is 19:22 to 6:55 But the trip start time is 7:26 But still alert raised, This is a TS case

If the trip start time is outside the window still alert raised, then raise TS.

Women traveling alone alert is raised even if the escort is signed in.

Safe Reach Confirmation

Description

Employees traveling within a designated time window will receive a safe reach notification upon reaching home.

We have a dedicated dashboard that allows monitoring of the status of employees who have received safe reach notifications.

The system enables tracking of safe reach confirmations, facilitating manual follow-up for employees who fail to confirm or whose confirmation fails.

Dependency

Employees in the ETS should be registered with the mobile number.

Shift of the employees should fall under the set time window.

Configurations

Console property:

We have to enable the Email from the console through SE team, To get Safe reach emails.

ETS side configuration : MISadmin => Manage properties => Engineering => IVR_DROP_VERIFICATION_FAILED_EMAIL_ENABLED - This property will allow the email to trigger in case if any employee failed to respond the IVR call and the safe reach status is failed.
Email will be triggered the next day at 8:00 AM.

IVR failed entries are triggered the next day at 8:00 AM. Manual success and manual failed entries will trigger email immediately after the status is changed.

Master switch to enable safe reach confirmation.

Below options allow us to enable mobile app notification and IVR calls for safe reach confirmation.

Below configuration will allow us to select Gender, Trip type and Time at which the Notification has to be triggered.

Shift time has to fall under the window.

Safe reach entry of the verification will be marked duplicate if there are any sign in in the last 60 min and in next 60 min.

If the below option is enabled then the safe reach notification will be triggered only after the actual sign off is received.

If the above option is disabled, System will consider the buffer time from the below config.
Mobile app notification will be triggered after planned pick up time + Buffer time set below for planned and Adhoc trip if actual pick up time is not received.
If actual pick up time is received before the planned pick up time then the Mobile app notification will be triggered after Actual pick up time + Buffer time.

Example : Planned pick up time is 18:00 and the buffer time is 10 Min, Then the Mobile app notification will be triggered to employee at 18:10 if actual pickup is not received on the server till 18:00, If actual pick up is received on the serve before 18:00 that is at 17:55 then the notification will be triggered at 18:05 that is 10 min after the actual pickup time.

If “Start IVR At Sign Off” property is disabled System will consider the buffer time from the below config to trigger safe reach IVR call.

Safe reach IVR call will be triggered after planned drop time + Buffer time set below for planned and Adhoc trip if actual drop time is not received.
If actual drop time is received before the planned drop time + Buffer time then the safe reach IVR call will be triggered after Actual drop time + time set in this “Time Difference Between Mobile App Notification And First IVR Call Time” configuration.

Denotes at what time difference between each notification.

If the actual drop off time is not received for ad hoc trip, the safe reach verification would not take place if the sign off is not received on the server until buffer time mentioned.

If the actual sign in/sign off is not received on the server until the above configured time, there will be no drop verification

If the employee press IN CAB when IVR call is triggered, the next IVR is delayed by above configured time.

Email Will be sent for IVR failed cases (Employee and reporting manager,team manager will get email along with mentioned email ID)

Email Will be sent for manual Success cases

Manual success is being done by monitoring specialist who manually calls the employee to confirms female employee safe reach when mobile app notification and IVR are not answered.

Common Issues and Cause

Call not triggered to Employee

Goto => SRC dashboard

Search for the employee with employee Id => select BUID => date of issue reported

No answer - Employee not responded

Failed - Network issue or operator issue

Busy - Employe on another call or blocked the span calls