1.

Описание Dashboard и Monitor

Не берем транзакции в которых указано в “DESCRIPTION” слова “AUDIT” или «TEST» лучше их выделить с помощью highlight .
Данные транзакции можно брать на проверку после того как об этом попросят.

Все транзакции, которые прилетают на мониторинг можно увидеть, нажав на вкладку ELD Transaction.
После чего мы переходим на Monitoring Dashboard, где видим список транзакций, которые были отправлены на мониторинг.
В данной вкладке мы можем видеть такие колонки :

1. Кто делал транзакцию ( красная буква F во второй колонке - означает, что ее открыл флит компании, если место
пустое - это значит что транзакцию открыл наш саппорт).
2. Organization - название компания, которая прислала транзакцию
3. Drivers list - имя водителей, на которых была открыта транзакция.
4. Owned by - кто из команды мониторинга сейчас смотрит эту транзакцию.
5. Opened by - имя того , кто делал эту транзакцию.
6. Opened date - дата и время открытия транзакция
7. Processed - имя того, кто прислал нам эту транзакцию.
8. Processed date - дата и время, когда транзакция появилась у нас на борде.
 9. Rejected by - имя человека из команды мониторинга, который сделал реджект по данной транзакции.
10. Comment /Description - короткое описание к данной транзакции (всегда обращать внимание)

В конце мы видим последнюю колонку с названием ACTION и кнопку с таким же названием.

1. View - для просмотра транзакции

2. Take - для того чтобы взять транзакцию под своим именем, то есть когда начинаем смотреть
3. Delete transaction - удалить транзакцию ( никогда не нажимаем эту кнопку!только в случаях если это вас попросит
ваш тимлид)

Для проверки транзакции нажимаем кнопку Take , после того как транзакция была взята под вашим именем, то есть ваше
имя теперь есть в колонке Owned by, нажимаем кнопку View и переходим непосредственно к проверке.

После этих действий , мы переходим на саму транзакцию. Здесь также дублируются

 1. Creation Date: Дата создания транзакции,
2. Owned By: кто взял транзакцию, то есть нажал кнопку Take ( сейчас поле пустое так как никто транзакцию не взял) ,
3. Organization: название компании ,
4. Validated Drivers: водитель
5. Validated Trucks: номер трака водителя.
Обращаем на это внимание, так как если у вас в транзакции есть несколько водителей, но Validated Drivers: только один,
мы и смотрим только этого водителя. Тоже самое и по траку, если у вас Validated Trucks: только один номер трака, то и
смотри по этому траку.
Если у вас в списке несколько драйверов, для того чтобы выбрать нужного водителя, открываем список всех водителей и
выбираем нужного. В данном случае это Mandi Rasikh.

Для того чтобы просмотреть комментарий к транзакции или предыдущий реджект по данной транзакции, необходимо
нажать эту кнопку:
Чекбокс unidentified events - показывает все неопределенные ивенты которые есть в данной транзакции

Event Status - Статус ивентов которые находятся в нашей транзакции

1. Active - Ивенты которые мы видим сейчас в нашей транзакции
2. All events - Все ивенты которые были в транзакции, включая удаленные. На удаленные ивенты обращаем особое
внимание, компаниям запрещено удалять ивенты в смене, особенно драйвинги.
 Фильтр по траку, если у вас больше одного трака, для удобного просмотра выбираем нужный трак, и тогда все ивенты будут
видны только по выбранному траку.

Кнопка REJECT и COMMIT .

1. В случае нахождения ошибок мы делаем реджект с описание и скрином, что нужно исправить .
2. В случае не нахождение ошибок мы делаем коммит с + или словом ок.
Пример реджекта.

Пример коммита
Show legend - описание значков, колонок и ошибок которые есть в нашей транзакции.
Add missing events - добавляет в транзакцию ивенты, которые появились после открытия транзакции. Обязательно
добавляем эти ивенты!!! В данном случае ивентов которое отсутствуют - нет.

В данном случае - есть 1 ивент, который не попал к нам при открытии транзакции. Это происходит потому, что транзакция
была открыта до того, как у водителя начали появлятся ивенты в реальном времени и они прилетают к нам в missing events.
1. Event name - Здесь находятся ивенты водителя, а также ключи ( On-duty, Off-duty , Sleeper, Driving, Login/logout ,
Power-up/Shut-down ).
2. Event timestamp - Время и дата создания ивента
3. Errors - Здесь находятся подсказки для мониторинга, в виде значков таких ошибок, за которое мы делаем реджект.

1. Показывает дубликаты ключей

2. Показывает запрещенные штаты
3. Показывает падения одометра
4. Показывает падения мото-часов
5. Показывает координаты на сертификации
6. Показывает перевод ивентов со статусом РО 2 в
РО 1.

4. Validation - Показывает валидацию D - валидация по драйверу, Т - валидация по траку, TD - валидация и по траку и

по драйверу. D - это нам нужно проверять на соответствия правил FMCSA, то есть последовательность ивентов,
дублирование, пропуски ивентов и т.д. и не нужно делать реджект, если там кривые метаданные.
T - это валидация только по метаданным грузовика, то есть нормальные ТВМ, АВМ, ТЕН, ЕЕН, координаты и т.д. -
соответственно, если есть проблемы по последовательности ивентов, то за это реджектить не нужно.
Ну а если стоит TD - то проверяем все.
5. Update - Показывает тип изменения ивента I - означает что ивент был вставлен , U - означает что ивент был изменен,
если ничего нет - значит ивент не трогали и никак не изменяли.
6. RO - Показывает статус ивента. RO 1 - означает, что ивент был создан автоматически ( Driving, Power-up/Shut-down и
On-duty, но On-duty может быть автоматическим только после драйвинга.)
RO 2 - это ручные ивенты, которые были созданы водителем через приложение (Sleeper, Off-duty, On-duty и Driving,
но Driving может быть ручным только если после него идет автоматический Driving )
RO 3 - это ивенты которые были ранее неопределенные, но флит их добавил в транзакцию через флит-тулс.
RO 4 - это ивенты которые ранее были неопределенные, но водитель их добавил в свой логбук через приложение.
7. TVM - Total Vehicle Miles суммарное значение миль пройденных автомобилем.
8. AVM - Accumulated Vehicle Miles значения пройденных миль автомобилем в рамках между Power up и Power down,
после каждого Power down AVM обнуляется.
9. Speed - Показывает скорость трака на данном участке
10. TEH - Total Engine Hours суммарное значение времени работы двигателя автомобиля, отображенное в часах.
11. EEH - Elapsed Engine Hours показывает время работы двигателя в рамках между Power up и Power down, после
каждого Power down ЕЕН обнуляется.
12. Lat/Lng - показывает координаты местоположения где был сделан ивент. (Широта/долгота)
13. Truck - номер трака на котором ездил водитель.
14. Location - показывает название города, штата и страны , где был сделан ивент.
15. Comment - коментарий которой оставляет водитель , например перед каждой сменой водитель делает проверку трака
на ивенте On-duty, при создании этого ивента он ставит комментарий PTI.
16. Driver - Здесь указывается водитель, чью транзакцию мы смотрим.
17. Co -driver - Здесь указывается имя и фамилия еще одного водителя, который работал вместе в смене с нашим
основным водителем.
18. LMB - Last Modified By: показывает как этот ивент был добавлен в транзакцию
L - Mobile App,
E - HOS Editor,
F - Fleet Manager;
1. Show All Gap Events - показывает все ивенты которые есть под гепом.
2. Scroll to Gap Period - дает возможность сразу опустится вниз к гепу.
Во вкладке History возможно посмотреть историю транзакции кто и за что реджектил

2. Описание Viewer
Во вкладке Viewer находится графическое отображение нашего логбука

Во вьювере так же как и в мониторе есть легенда, в которой расписаны обозначение каждого значка
1. Ключи вкл и выкл зажигания
2. Ивенты аутентификации
3. Малфанкшин - просим удалить
4. Сертификация
5. отчет, который заполняет водитель перед началом
рабочей смены. Он содержит всю информацию о
состоянии автомобиля на текущий момент. На
графике отображается оранжевой пунктирной
линией. Является опциональным.
6. Пересечение границы
7. Автоматическое пересечение границы , которое
подтягивается координатами из за близкого
расположение к границы.
8. Нарушения - на них не смотрим
9. Заправки
10. Рестарт цикла
11. Смена трака
12. Превышение скорости
13. Езда в плохую погоду
14. Инспекция ДОТ
15. Движение трака
16. Ручные ивенты
 3. Запрещенные штаты
Запрещенные штаты - это штаты где есть весовые станции и где на дорогах установлены камеры. В данных штатах
редактирование запрещено. Мы разрешаем редактирование в запрещенных штатах, только в том случае если водитель туда
не возвращается на протяжении 8 дней. Изменения до 15 минут мы пропускаем.

Запрещенные штаты:
IDAHO
MONTANA
OREGON
WASHINGTON
NORTH DAKOTA
SOUTH DAKOTA
FLORIDA
UTA

Дополнительно для Quality Wheels Inc — CALIFORNIA, COLORADO

Так выглядят запрещенные штаты в мониторе:

Так мы смотрим и выделяем запрещенные штаты во вьювере. Обязательно сравниваем оригинальные ивенты с теми что
сейчас у нас в транзакции. Сравниваем Origin и After.
Origin - показывает оригинальные данные водителя, которые были у него без редактирования.
After - показывает нам то, как выглядит наша транзакция сейчас, после редактирования. Так она будет выглядеть у водителя
после коммита.
Before - показывает как выглядела транзакция перед последним редактированием, то есть перед тем как она прилетела к нам.
В данной ситуации мы видим, что были смещены все ивенты за 24 число. Соответственно просим перевести это все в
ручные ивенты, если водитель будет возвращаться назад или сейчас находится в этих штатах.
 4.BDX/BDXa
Отметка о пересечении границы есть автоматическая и ручная. Автоматическая BDXa на графике отображается как
тускловатая пунктирная линия — система проставляет самостоятельно этот ивент когда видит, что координаты близки к
границе. Ручной ивент пересечения границы BDX отображается более толстой пунктирной линией и может быть позже
предыдущего ивента.

BDX - правила нашей компании запрещают удаления или редактирования отметки о пересечении границы. Всегда
сравниваем Origin и After на изменения этой отметки. BDX должен быть между ивентами, на драйвинге его ставить нельзя.
BDXa - автоматическую отметку о пересечении границы , мы разрешаем редактировать.
 4.Выгрузка / геп
Оригинальный геп в транзакции у нас находится 9 дней назад . Проверку транзакции мы начинаем от оригинального гепа.
Он отражается так :

Если при просмотре логбука установлен кастомный Gap Date, это геп который установлен значительно выше оригинального
гепа, то есть его установили вручную, и там есть разные ошибки — необходимо посмотреть “ELD Viewer” на наличие
выгрузки данных ( DOT Insection) . Этот геп обозначается более темным серым и специальным значком, который
показывает нам выгрузку данных. Если выгрузки не было, мы просим опустить геп до оригинального и исправить ошибки
(если они там есть)
5. Проверка транзакции
 Типичные ошибки в транзакции + GAP DATE

Локации

1. Локейшн дискрипшн должны быть на дьюти ивентах (driving, on, off, sleeper). Если после нормализации
дискрипшн нет, то при выгрузке HOS репорта отсутствие дискрипшн будет ошибкой.
При этом, добавлять локейшн дискрипшн на ивенты аутентификации (login logout) и engine activity (power up -
power-down) не нужно.

2. Необходимо проверять корректность локации.

В данной ситуации - локейшн дискрипшн “40” отсутствует в системе. На ивентах РО2 водитель может указать
любой город, который не переподтянется с приложения. И это не будет считаться ошибкой. Но на автоматических
ивентах РО1 локейшн дискрипшн записывается с устройства, по-этому следует добавить правильную локацию,
всплывающую из списка в приложении.
На этом скрине название местоположения не пишется с заглавной буквы, что недопустимо на автоматическом
ивенте.

3. Отсутствие LAT LNG на Engine ивентах

Некорректный рост одометра

1. Без изменения координат TVM не может увеличиваться.

2. TVM растет без изменения TEH

3. Локация изменилась без роста TVM

4. Увеличение одометра после статусов Off-duty, On-duty

Некорректные показатели AVM и EEH на автоматических ивентах

1. Отсутствие показателей AVM и EEH на intermediate logs

В данном случае, показатели AVM и EEH не считаются, потому что отсутствует power-up ивент.

2. Несоответствие AVM росту TVM

Одометр вырос на 43,69 миль, а рост AVM составил 51,67.

3. Некорректный рост EEH

 4.Показатели EEH считаются, а AVM - отсутствуют

5. Показатели TVM не изменились, а значения AVM после power-up начинаются не с “0”.

 Дубликаты

Два события не могут происходить в одно и тоже время (исключением является сертификации, так как водитель
может одновременно подписать их).

Порядок ивентов

1. Отсутствуют включение, выключение, логин или логаут (нужно логически понимать нужны ли они там).
2. Автоматические ивенты не могут записываться после логаута

3. После ручного ивента не может идти автоматический ивент (должно быть наоборот).
4. Присутствуют события diagnostic, malfunction
 Personal Use/Yard Move
Драйвер в статусе YM может работать до того момента, пока трак не достигнет скорости 5 миль/час(8 км/час) и для Канады
и для США. После достижения данной скорости - автоматически включается драйвинг.
На РС есть ограничение по пройденному расстоянию в 75 км и ТОЛЬКО ДЛЯ КАНАДЫ, в США ограничения нет.
По времени ограничений нет. Драйвер в этом статусе может находиться хоть день, хоть неделю. Обязательное
условие при активизации РС, у водителя не должно быть груза и он не должен ехать на pickup / delivery.
На ивенты РС/YM ИЛИ Clear можно переключиться, ТОЛЬКО, если драйвер подключен к траку. В противном
случае у него будет даже кнопка залочена.
Время между ивентами не соответствует пройденному времени TEH
Между ивентами ELD Logout 02:24:56 и ELD Login 13:05:15 прошло 10 часов и 41 минута, что составляет 10,68 по
TEH. Но в данном случае, рост TEH между этими ивентами равняется 15,68, что на 5 часов превышает время по
Timestamp.
 Увеличение показателей TVM и TEH после выключения двигателя и до его включения.

Между power-down и power-up ивентами не может расти одометр и часы работы двигателя
 Сертификации

Водитель не может сертифицировать логбук в движении. Наличие сертификаций на ивентах Driving, PU/YM является
ошибкой.

На сертификатах показатели TVM, АVM, TEH, ЕEH, координаты и локации не должны присутствовать (нули на
показателях не считается ошибкой).

Unidentified events

При наличии неопределенных ивентов, сперва необходимо их приассайнить. В дальнейшем, если нарушен порядок
ивентов или не корректные данные, нужно их удалить. Unidentified events, которые попали в логбук с другого трака,
мы пропускаем.

Максимум +15 миль в зависимости от штата, но не больше 95 m/h
1 | 70 m/h | USA | Alabama | AL
2 | 65 m/h| USA | Alaska | AK
3 | 75 m/h| USA | Arizona | AZ
4 | 70 m/h| USA | Arkansas | AR
5 | 55 m/h| USA | California | CA
6 | 75 m/h| USA | Colorado | CO
7 | 65 m/h| USA | Connecticut | CT
8 | 65 m/h| USA | Delaware | DE
9 | 70 m/h| USA | Florida | FL
10 | 70 m/h | USA | Georgia | GA
11 | 60 m/h | USA | Hawaii | HI
12 | 70 m/h | USA | Idaho | ID
13 | 70 m/h| USA | Illinois | IL
14 | 65 m/h| USA | Indiana | IN
15 | 70 m/h| USA | Iowa | IA
16 | 75 m/h| USA | Kansas | KS
17 | 70 m/h| USA | Kentucky | KY
18 | 75 m/h| USA | Louisiana | LA
Превышение скорости (Speed limits)
43 | 85 m/h| USA | Texas | TX
22 | 65 m/h| USA | Michigan | MI
44 | 80 m/h| USA | Utah | UT
23 | 70 m/h| USA | Minnesota | MN
45 | 65 m/h| USA | Vermont | VT
24 | 70 m/h| USA | Mississippi | MS
46 | 70 m/h| USA | Virginia | VA
25 | 70 m/h| USA | Missouri | MO
47 | 60 m/h | USA | Washington | WA
26 | 65 m/h | USA | Montana | MT
48 | 70 m/h| USA | West Virginia | WV
27 | 75 m/h| USA | Nebraska | NE
49 | 70 m/h| USA | Wisconsin | WI
28 | 80 m/h| USA | Nevada | NV
50 | 80 m/h| USA | Wyoming | WY
29 | 70 m/h| USA | New Hampshire | NH
51 | 68 m/h | Canada | Alberta | AB
30 | 65 m/h| USA | New Jersey | NJ
52 | 75 m/h | Canada | British Columbia | BC
31 | 75 m/h| USA | New Mexico | NM
53 | 68 m/h | Canada | Manitoba | MB
32 | 65 m/h| USA | New York | NY
54 | 68 m/h | Canada | New Brunswick | NB
33 | 70 m/h| USA | North Carolina | NC
55 | 62 m/h | Canada | N&L | NL
34 | 75 m/h| USA | North Dakota | ND
56 | 62 m/h | Canada | Northwest Territories | NT
35 | 70 m/h| USA | Ohio | OH
57 | 68 m/h | Canada | Nova Scotia | NS
36 | 70 m/h| USA | Oklahoma | OK
58 | 56 m/h | Canada | Nunavut | NU
37 | 65 m/h | USA | Oregon | OR
59 | 62 m/h | Canada | Ontario | ON
38 | 70 m/h| USA | Pennsylvania | PA
60 | 56 m/h | Canada | Prince Edward Island | PE
39 | 65 m/h| USA | Rhode Island | RI
19 | 75 m/h| USA | Maine | ME 40 | 70 m/h| USA | South Carolina | SC 61 | 68 m/h | Canada | Saskatchewan | SK
20 | 70 m/h| USA | Maryland | MD 41 | 80 m/h| USA | South Dakota | SD 62 | 62 m/h | Canada | Quebec | QC
21 | 65 m/h| USA | Massachusetts | MA 42 | 70 m/h| USA | Tennessee | TN 63 | 62 m/h | Canada | Yukon | YT
 GAP DATE

Делаем реджект на искусственном гепе только, если ошибка после 12 часов от оригинального GAP DATE(9,5
дней):

1. Показатели TVM и TEH упали на границе с гепом.

2. Некорректные показатели на автоматических ивентах сразу после гепа
3. Ивент который был создан далеко в гепе, будет виден при выгрузке до момента пока не появится новый ивент.(12 часов на гепе и 8.5

дней).
В таком случае учитываются данные с оффа 24 марта и сравниваются с ним, так как логин в 8-дневной зоне выгрузки.
 Удаленная рабочая смена

Удаленная рабочая смена является грубой ошибкой. Это ЗАПРЕЩЕНО делать как флит-менеджерам, так и саппортам.
 Правила проверки текущих данных в транзакциях
* Синхронизация просчета AVM и ЕЕН идет от последнего Power Up, по формуле TVM/TEH данных с бортового компьютера минус
TVM/TЕН данных с последнего Power Up.

1. Проверка текущих данных проводиться в конце проверки транзакции

2. Проверка данных, соответствует общим правилам.
o Данные не должны снижаться, либо быть больше последних оригинальных данных с коробки.
o Соответственно. если водитель не делал логаут или Power down, то их там быть и не должно, а если они там нужны. то
нужно просить добавить Power up в то же время и данными, с которыми был последний оригинальный event.
(Пример: последний ивент в транзакции Off duty создан в 13.00 без Power down, после редактирования, этот Off duty в
10.00, с теми же данными, и сразу после него идет Power down. Мы просим создать Power up в 13.00 с данными
оригинального Off duty, для избежание несоответствия ТЕН с временем между ивентами, а также дальнейшего просчета
АВМ и ЕЕН в лог буке водителя,
Так как Power up водитель самостоятельно, не будет делать, ведь он же не глушил двигатель.)
o Последний events, при отсутствии Power down, в оригинальных данных, не должен быть создан позже последнего
оригинального events. (Пример: последний Off duty в оригинальных создан в 13.00, а в транзакции Off duty с теми же
данными стоит в 15.00) Так как при создании нового events водителем, будет несоответствие ТЕН и времени между
events.
3. Перед проверкой данных необходимо: 
3.1 Обновить страницу (F5)
3.2 Выполнить “Add missing events”, при их наличии
После выполнения, этих действий, приступаем непосредственно к проверке текущих данных. 

Есть несколько вариантов, событий, в зависимости от них меняется способ проверки. Рассмотрим каждый по отдельности.
● Когда транзакция заканчивается Driving, Intermediate log CLP. 
В таких случаях проверка проводиться путем, открытия U-update events и сравнивание показателей TVM, TEH, LAT/LONG, и
LOCATION (для LAT/LONG действует правило, 2 знаков после точки. Локация может отличаться при одинаковых координатах до и
после редактирования, это тоже норма)
На показатели AVM and EEH не обращаем внимание, поскольку, при Commit до появления нового Intermediate log CLP, либо создании
любого duty events, эти показатели просчитаются согласно новым данным. (Синхронизация просчета AVM и ЕЕН идет от Power Up, по
формуле TVM/TEH данных с бортового компьютера минус TVM/TЕН данных с последнего Power Up) Так как при нормализации
проставляется новый ключ, соответственно синхронизация при создании нового events после Commit, будет от него.
В случае, если текущий Driving, Intermediate log CLP созданы как новые (вместо U-update прописано I-insert), мы переходим к 2
способу проверки.
● Транзакция, заканчивается Insert events, duty events, Power down, ELD Logout.
Для проверки таких данных нам необходимо использовать ELD Monitor

Для проверки мы, копируем имя водителя, и компанию. Переходим в ELD Monitor выбираем компанию, водителя и выставляем нужный
нам период, и обязательно проставляем галочки
Далее сверяем данные, с данным в конце транзакции. Необходимо учитывать, что в мониторе не оригинальные данные, а данные
которые были до текущего редактирования. Если до вас кто-то коммитил транзакцию, то они уже могут быть некорректны.
Пример сравнения и ошибок ниже.
Пример 1

,
Пример 2
Пример 3
● Третий вариант, самый простой. Он возможен при наличии «missing events», либо отсутствии редактировании последних events
В такие случаи, мы просто сравниваем данные с последними оригинальными events, которые не редактировались.
Как их определить? – на таких ивентах отсутствуют значки U - update или I - insert
И так же проводим проверку по общим правилам проверки транзакции.
Пример нормальных данных
Пример ошибки
Правила проверки транзакции с ко-драйверами и несколькими водителями

*Ко-драйвера – это водителя которые ездят на одном траке, и работают с одного устройства.
Также существуют транзакции драйверов, которые просто ездят на одном траке по очереди, по несколько трипов, но не
являются ко-драйверами и могут работать с разных устройств.

В зависимости от того водителя, ко-драйвера или нет, данные в их транзакции могут отличаться.
Как понять, что транзакция с несколькими водителями и кто из них ко-драйвера рассмотрим ниже.

Таким образом, на борде выглядят транзакции с несколькими водителями. Их может быть 2 и более.

При проверке таких транзакций мы отталкиваемся от валидации. Соответственно проверяем только валидируемых водителей и траки.

Проверяем по следующим правилам:

D - это валидация по драйверу.

Т - это валидация данных только по грузовику. То есть система проверяет правильность сбора технических данных грузовика, таких
как одометр, моточасы, координаты и т.д. и в данном случае не учитывает ивенты драйвера. То есть она не будет учитывать
повторяющиеся ивенты, пропущенные или в неправильном порядке.
TD - будет учитывать и то и то

Если проще, то D - это нам нужно проверять на соответствия правил FMSCA, то есть последовательность ивентов, дублирование,
пропуски ивентов и т.д. и не нужно делать реджект, если там кривые метаданные.
T - это валидация только по мета данным грузовика, то есть нормальные ТВМ, АВМ, ТЕН, ЕЕН, координаты и т.д. - соответственно,
если есть проблемы по последовательности ивентов, то за это реджектить не нужно.
Ну а если стоит TD - то проверяем все.
Также, если водитель нормализировался, не имеет значения, какая валидация у него проставлена, мы проверяем его по всем
правилам.
При отсутствии нормализации и наличии валидации. не реджектим за оригинальные данные. Так как, если транзакция запроцесилась
то данные валидные
 Ко-драйвера (co-driver, team driver)
Ко-драйвера в транзакции должны быть проставлены в строке “CO-DRIVER”

● Ко-драйвера ездят посменно, по одной смене (трип- 14 рабочих часов).

● В начале каждой смены у каждого водителя должен быть он дюти с PTI.
● При переходе смен, не должно быть телепортации (нереальной смены локации) , падения или нецелесообразного роста TVM и
TEH.

● В оригинальных данных все ключи дублируются у обоих водителей (проставляются в одну и ту же секунду). После
нормализации такое не встречается.

● При подключении 2 водителя впервые к траку, и создание пары ко-драйверов, у 2 водителя обязательно должен быть ELD
Login. Наличие ELD Logout у 1 драйвера не обязательно.
 ● Ко-драйвера могут отключаться и подключаться в рознь. То есть, наличие у 1-Д Logout не означает наличие Login у
2-Д.Главное, чтобы в начале смены 1-Д был Login, так как в конце прошлой своей смены он сделал Logout. Все это время 2-Д
может быть подключен. Соответственно Logout and Login пропишется только в лог буке 1-Д.(Схематический пример ниже)
Logout Login

Д-1 Logbook 1 driver

Logout Login

Д-2 Logbook 2 driver

● Если водителя ко-драйвера, мануальные ивенты(смена RO2) должны быть у обоих драйверов. То есть, не может быть у
одного драйвера все ивенты мануальные, а у второго автоматические(RO1), посменно. (Пример: у Д-1 трип за 11,13,15 число
мануальные, а у Д-2 за 12,14,16 автоматический (наличие RO1 events). Такое запрещено. Данная ситуация разрешается в случаи,
когда водителя не ко драйвера, а ездят на одном траке, так как они могут работать с разных устройств. Ну такие водителя ездят,
обычно минимум по 2 дня.
Для ко-драйверов нормальный мануал если у Д-1 и Д-2 все ивенты с 11 по 16 мануальные, а потом у кого-то из них есть Login и
дальше смены автоматические.
● При проверке водителей, которые не являются ко-драйверами, а просто ездят на одном траке, при каждом подключении
наличие логина обязательно.
● Наличие любых ивентов, сертификаций у ко-драйвера, во время Driving events водителя, до создания ним OFF, ON DUTY, SLEEPER,
запрещено.
● Подобное расположение ивентов не является ошибкой
 Проверка транзакция в Monitor и Viewer
● При просмотре в Monitor, ко-драйвер, или водитель, который так же ездил на траке, который проверяется, отображается
тусклым цветом (немного серее)
● При скриншоте ошибки обязательно, чтобы было видно строку DRIVER. Это нужно для понимания флита или суппорта, у кого из
водителей, в лог буке ошибка.

● При проверке транзакции с несколькими траками рекомендовано пользоваться селектом трака, и смотреть данные
именно по траку, а не по водителю отдельно. Для этого выбираем валидируемый трак и выбираем одного из водителей,
кто ездил на этом траке. Все остальные которые тоже ездили на данном траке будут показываться в транзакции серым
(на 2 пункт выше). И проверяем данные по отдельности по каждому траку (при наличии нескольких траков).
● В Viewer мы можем увидеть перемещения трака, там где есть ко драйвер, или водитель с этого же трака.
Если это ко-драйвер, то мы еще и можем видеть ивенты и время начала ивентов у ко драйвера.

Проверка данных, внутри смен, каждого из драйверов, производиться на основании общих

правил проверки транзакции. Только с учетом вышеуказанных правил.
Примеры нормальной переменки ко-драйверов: