BNSF D8 device and alert management

BNSF D8 Device and Alerts Management

Base Station

Control Center is required to enter vehicles and contacts for a location so that the D8 device can be associated with it. LTI/Global Center needs this information to exist so the alerts can be set up and it cannot be created in Global Center at this time.

Many of the BNSF locations with D8 alert monitoring do not have a physical base station associated with them and he existing BNSF locations with base stations have connections with global center shut down. There are some BNSF locations that are collocated with other companies that have base stations but they are other companies.

We need to have a virtual base station(s) so the data entry can be done.

Virtual Base Station

This is a real base station located at Idrive Santa Barbara in the RMA area. Use this to create vehicles and assign devices for BNSF.

User idrbnsf@idriveglobal.com PW Idr805sb

For RMS log into one of their base stations to do the assignments

Adding New Vehicles

• Access Idrive Control Center on designated "BNSF Idrive Support" machine.

• Go to "Fleet Manager" at the top and go to "Vehicles" on the left side.

• Choose "Add a New Vehicle" (or Clone Vehicle)

• Input known vehicle name (retreived from BNSF documentation) and set to the correct BNSF location.

• Input all other required information while giving any unknowns arbitrary information.

Alerts Management

About Alerts

The D8 DVRs are configured to check in at a certain interval (currently 12 hours)and report status.

If at the time of check-in a video channel is not working or the DVR is not recording an alert will be generated.

A distribution group has been created to distribute this email to the concerned parties in Idrive. bnsfalerts@idriveglobal.com Idr805sb

Another distribution group has been created for installation alerts so that while the installation is being completed the false alerts do not go to the customer. installationalerts@idriveglobal.com

A separate email will go to the designated BNSF location manager if configured.

Setting Alerts

Alerts are set up in two places:

• AdminCenter (in Customer> BNSF> Location> D4/D8 devices tab.

• LTI (Login is as client through A/C and select LTI on the customer page)

Admin Center D8 Alerts Setup

Here we set the channels that should be monitored for each D8. We will only monitor alerts for cameras supplied by Idrive (typically channels 1-4) and not channels from monitors connected through an Idrive splitter.

We have also added device status / channels / recording info on the devices list.

Here is how the D8 device status looks now:

• Black = Inactive (Nothing have been communicated to the server)

• Green = Active (Have been communicated to the server, no issues found)

• Yellow = Installation not completed (Have been communicated to the server at least once but the “device Installed” checkbox is unchecked – no alerts will be triggered)

• Red = Overdue / Issues (Have been communicated to the server – communication overdue since 24 h ago or cameras / recording issues)

Here is how channels status looks now:

• Black = inactive

• Red = disconnected (channel is missing but is present on device settings)

• Green = active

• Yellow = wrong channel installation (in case a channel is active but contrary to device settings)

• Yellow with "S" = Sleep mode for the Alert. Known problem so do not sent alerts for 30 days.

Please set all the devices that have been installed so far and let us know, after that we will activate the new server side code that do the checking and triggers alarms. We did not activate it yet because will block all the alarms since there is no AC data saved (no installed channels info, etc.)

LTI D8 Alerts Setup

Here we set up which D8 sends out an alert email and who it goes to

When a D8 assigned to a vehicle checks in via cellular it will appear in LTI (and not until then)

An alert for a vehicle cannot be set until after the vehicle checks in with LTI

D8 Cell connection observations/notes

Green bars on the monitor does not mean that there is a connection to our server, only the cellular network contact. If the server address is incorrect or not enabled the Cell network will not know where to route the packets.

The DVR must be assigned and a rule set before the Cell LED illuminates.?

If you replace the cellular module in the DVR and use the same SIM you may need to PURGE the SIM in PodSystems. I suspect that the IMEI/MSISDN need to be flushed.

Observed A/C check in steps (buy Mark):

Initial check in - no cameras of info shown (DVR does not have its settings yet?

Second check in - should report per the settings

LTI Notes

Update from Florin 10-17-18

We have released a new version of AC containing few fixes on DVR. Here is the change log: - General DVR status in not changed while the device sends not recording state (bug) - Extend DVR channels status, active/no video must be set only for monitored and not snoozed channels / add new status for snoozed channels - Set the DVR last connection overdue to 8 days

We need to put more work on the channels status, we added only a new status – snoozed ones (channel have been set as snoozed and is disconnected). This status does not take dates in consideration - coming soon…

Filter Rules from Dragos 7-2-18

As promised I am coming back with the rules…

(they are listed as I find them in code…)

- If the device is not marked as installed, skip it

- If the device has not connected in more than 7 days, add alert (‘Not connected since: ‘. date ("m/d/Y”, $localTimestamp))

- *If the recording flag is off add alert (DVR not recording)

- *Ignore all errors for channels > 4 – this was added because our cameras are usually on the first 4 channels, rest of them are from the original crane/loader/whatever. Sean said we should only monitor our cameras.

- *Ignore disconnected snoozed cameras

- *If a camera is connected and active on a snoozed channel add alert (Camera is connected on a channel which was not configured (Channel {$channel}))

- *If a camera is not connected add alert (Camera disconnected (Channel {$channel}))

- *If all cameras are missing add alert (No cameras are connected)

For the * items:

If a change in status is observed (dvr is recording again, camera reconnected) they are added to the Resolved issues list, otherwise they go on the devices with active issues. The resolved issues list is filtered, and only the errors which were resolved more than 1 day later are kept, the rest are discarded (Date.parse(resolvedErrorList[i].resolved - resolvedErrorList[i].local_time > 1*24*3600)) . This was added to filter brownouts and erroneous messages from the devices.

Sample of string sent

From Florin 8/30/17:

Hi Mark, Looks that the device has connected for few times reporting no cameras installed and not recording - here is the last connection server log:

CONNECTION

New client connection from ::ffff:81.88.163.217:34681 @ 2017-08-28T00:01:30.103Z

Data received @ 2017-08-28T00:01:30.173Z

"################### HANDSHAKE ################# ON => { sn: '1708110012',

videoChannelsAvailable: 8,

lid: '65cfb0bc',

version: '201708221720',

networkType: 0,

recordingStatus: 0,

cameraLossStatus: 255 }

HANDSHAKE ( 1708110012 )

LTI_Set_GPS_Status_Last OK

Data received @ 2017-08-28T00:01:32.372Z

"################### ALARM ################# ON => { sn: '1708110012', alarmType: 20, alarmTime: '20170827164423' }

Data received @ 2017-08-28T00:01:38.054Z

"################### ALARM ################# ON => { sn: '1708110012', alarmType: 21, alarmTime: '20170827164423' }

Data received @ 2017-08-28T00:01:43.004Z

"################### ALARM ################# ON => { sn: '1708110012', alarmType: 22, alarmTime: '20170827164423' }

Data received @ 2017-08-28T00:01:48.062Z

"################### ALARM ################# ON => { sn: '1708110012', alarmType: 23, alarmTime: '20170827164423' }

Data received @ 2017-08-28T00:01:53.062Z

"################### ALARM ################# ON => { sn: '1708110012', alarmType: 28, alarmTime: '20170827164423' }

Connection from ::ffff:81.88.163.217 closed s/n 1708110012

Florin comments

alarmType 20 – 27, represents camera disconnect, channel 1 – 8.

Only 4 alarms are triggered because dvr have been set to use only these channels probably. Type 28 represents not recording.

Also, I have asked their engineers about cellular status values, under DVR>Settings>Network>Status>Cellular>Status, here is the answer (and my comments): “if the device report 27 once， it means the device has connected the net successed;”

“DEVICE_INIT = 200,

DEVICE_HARDWARE_ERR,//201

DEVICE_HARDWARE_OK,//202

DEVICE_OPEN_ERR,//203

DEVICE_OPEN_OK,//204 (modem present)

DEVICE_GPS_RESET,//205

DEVICE_ATI_ERR,

DEVICE_ATI_OK, (get modem FW version)

DEVICE_CPIN_ERR,

DEVICE_CPIN_OK, (pass the PIN – probably checks if the SIM card has PIN)

DEVICE_CSQ_ERR,

DEVICE_CSQ_OK, //211 (get signal strength)

DEVICE_NET_TYPE_ERR,

DEVICE_NET_TYPE_OK, (get network – modem registered)

DEVICE_GET_APN_ERR,

DEVICE_GET_APN_OK,

DEVICE_SET_APN_ERR, //216

DEVICE_SET_APN_OK, (set APN)

DEVICE_GSSTATUS_ERR,

DEVICE_GSSTATUS_OK,

DEVICE_PDP_ERR,//220

DEVICE_PDP_OK,

DEVICE_SET_PDP_ERR,

DEVICE_SET_PDP_OK, (set PDP context)

DEVICE_DUAL_ERR,//224

DEVICE_DUAL_OK,

DEVICE_IP_ERR,

DEVICE_IP_OK (have received IP address)

increase by degrees”

Another Sample of string sent

CONNECTION

0|ltiNode | ### CLOSING =>

0|ltiNode | CONNECTION

0|ltiNode | New client connection from ::ffff:81.88.163.217:49923 @ 2017-08-31T16:16:05.618Z

0|ltiNode | Data received @ 2017-08-31T16:16:05.678Z

0|ltiNode | ################### HANDSHAKE ################# ON => { sn: '1708110012',

0|ltiNode | videoChannelsAvailable: 8,

0|ltiNode | lid: '65cfb0bc',

0|ltiNode | version: '201708221720',

0|ltiNode | networkType: 0,

0|ltiNode | recordingStatus: 1,

0|ltiNode | cameraLossStatus: 248 }

0|ltiNode | HANDSHAKE ( 1708110012 )

0|ltiNode | LTI_Set_GPS_Status_Last OK

0|ltiNode | Connection from ::ffff:81.88.163.217 closed s/n 1708110012