| Data Transfer Methods | The iFleetELD provides Data Transfer Capabilities as specified in section 4.9 of ELD Test Plan and Procedures. Data Transfer to an Authorized Safety Official is provided using the standards Option (1) Telematics transfer methods(4.10.1). This transfer can occur either via email(4.10.1.1) or Wireless Web services(4.10.1.4, 4.10.2, Appendix to subpart B of 395) With this feature, a safety inspector will easily be able to retrieve Driver data in the form of a text file. The text file will be attached to an email or as part of an web services request. The text file is formatted according to section 4.8.2 of ELD Test Plan and Procedures. It includes Driver data from the previous 7 days up to the the time of the inspection. At the beginning of a safety inspection, the inspector will enter an "Inspection Mode" in the iFleetELD. From there he will perform a visual inspection of the Driver's data for the current 24-hour period, with the ability to go back and view records from the previous 7 days. If the inspector feels the need to retrieve the Driver's data electronically he or she will press a button labeled "E-File". This will then generate the output file and automatically send it to the desired FMCSA endpoint(4.3.2.4 Driver’s Data Transfer Initiation Input). |
| Malfunction Notes | The iFleetELD is connected to the engine ECM via a Bluetooth or serial interface. This connection monitors a number of engine functions including power, engine hours, engine on/off, VIN, and speed. The status of the Bluetooth connection with the ECM is displayed to the driver in the main view of the ELD. In the case of a malfunction the corresponding codes are sent as part of the ELD Output File. The malfunction codes used are referenced from Table 4 of the federal Register: Power Compliance Engine Synchronization compliance Timing Compliance Positioning Compliance Data Recording Compliance Data Transfer The following is a description of the measures taken to comply with the above rules. Power Compliance (P) To use the iFleetELD, we require that driver power on the device and login using his or her credentials before turning the engine on. In the case that the driver mistakenly turns the engine on before logging in, the event is still logged under a pre-assigned unidentified driver id, where it can later be “re-attached” to the driver through a Unidentified ELD Event Confirmation view in the app. In addition to this, tablet shutdown and low battery events are logged to monitor a suspected premature shutdown by the driver. Engine Synchronization Compliance (E) Connectivity to the Engine ECM is constantly monitored at intervals of less than 5 seconds. As a visual aid to the driver, we have designated an button icon which is set to RED(ECM Connected) or GREEN(ECM Disconnected). This will alert the driver along with an auditory beep of a loss in engine connectivity. If a failure occurs for more the 30 minutes, we ask the driver report the issue to tech support and any faulty hardware is replaced. Timing Compliance (T) All Driver and CMV data is recorded in UTC time on the iFleetELD’s database. Drivers and Managers do not have the ability to alter or generate the timestamps that are sent with any data. In the case of a Driver making a mistake in producing his or her data, the Driver can create an annotation according to the rule in 4.3.2.6. In addition to the timestamp of the ELD Event, we are also saving the time each record made it to the server, providing an effective crosscheck of when the Event was created and when it was saved. Positioning Compliance(L) This procedure is in compliance with 4.3.1.6 CMV position of the federal Register appendix. Our monitoring procedure validates Latitude and longitude coordinates and distance traveled in miles and timestamp since the last position. If we detect a failure in accordance with 4.6.1.4 (a), (b), (c), (d) we will record an event whereby the ELD record the character ‘X’ in both Latitude and Longitude. In the case of hardware failures, faulty devices will be replaced within an 8 day timeframe. Data Recording Compliance (R) All ELD Data is stored locally on the tablet for the previous 7 days up to the current 24 hour period. The iFleetELD ensures data synchronization between the device and the server is consistent and up to date. Loss of network and a driver who has not logged in yet are the edge cases that we have accounted for. For a loss of network, the event is logged as a malfunction and upon reconnection, the data is synced. For unidentified records, the Driver is provided the option of identifying his or her data via an Unidentified ELD Event Confirmation view. Data Transfer compliance (S) The iFleetELD offers option 1 (Telematics) according to 4.10.1.1 and 4.10.1.2 rules (i-Web services, ii-email) as a means for a sending an ELD Output File to an authorized safety official during a roadside inspection. As a self monitoring procedure, the ELD connects to the FMCSA Web Services endpoint to identify itself as a certified device, and any status errors received are logged as malfunctions. This ELD identification process is run every time the Driver logs in as well as right before attempting to send an ELD Output File. |
| Certifying Statement | The iFleetELD was tested to fulfill the Functional Requirements located in section 4 of ELD Test Plan and Procedures. Testing was conducted by engineers at the software level as well as manual testing done by QA. In addition, a focused group of beta users were selected to take part in a lengthy pre-release phase of the iFleetELD(Versions 0.0.1 - 1.1.2). For software tests, mock data was utilized for the purpose of simulating the data generated by a Driver and his/her CMV. With this data our engineers will be able to easily conduct automated regression tests as features are added to subsequent releases of the iFleetELD, thus creating a stable release cycle. In addition to mock data, our engineers were provide the convenience of using an OBDII J1939 Simulator to test and develop the iFleetELD. The simulator allows emulated Engine Synchronization data to be attached to Driver status events and so on. Despite the convenience of simulated data, the actual tests to satisfy the Pass/Fail requirements of ELD Test Procedures were done using a combination of manual tests conducted by QA and Beta user feedback. The Beta users consisted of several small fleets consisting of 10 trucks or less with owner/ operators willfully testing our product. By testing using real engine data and drivers over time, we were able to hone in on issues or edge case bugs that would otherwise be obscured or untestable at the software level. This especially came in handy when testing the reliability of any ELD Function that requires a physical dimension outside of the office environment. These include: Geolocation Auto Driving/On Duty detection Vehicle Speed Spotty Network Connectivity Testing in the field with Beta users also allowed us to look at the behavior over a prolonged period of time(2 weeks or more), aiding our testing of the following features: Weekly On Duty/ Driving Limit Calculations Shift Reset Calculations With these tests described, we certify that we have complied with FMCSA requirements |
