Сайдбар в пространстве имет Артсек-Тула
Сайдбар в пространстве имет Артсек-Тула
Это старая версия документа.
Зайти по RDP на 194.87.237.67
Логин:Administrator
Пароль: запросить у Бухарова.
№ п/п | Дата, автор | Название | Описание |
---|---|---|---|
1 | — Бухаров А.В. 2019/06/17 09:10 | управление пиплами и ГРЗ | В эту систему надо будет передавать ГРЗ для гостевых ТС. Макет системы заказа пропусков делает Алексей Межоев. А тебя, СВ, я прошу предусмотреть возможность добавления/удаления гостевого ГРЗ внешней программой. |
2 | — Бухаров А.В. 2019/06/17 09:22 | Этап 2. Аналитика на выезде | В ходе эксплуатации нам надо будет давать ответы на вопросы: * почему не выпустило? * Что именно не хватало для выезда? И нам надо знать причину отказа в выезде. Как это сделать? Я предлагаю в журнал событий добавить поле «Аналитика». При выезде делать анализ: как машина выехала? Основные пункты: * оплачено/не оплачено, * ГРЗ распознанов/не распознано, * ГРЗ совпадает/не совпадает с выездом. * Порядок проезда правильный/нарушен. Затем, по результатам анализа, мы будем вешать всякие оповещения, свистелки, рассылки. Система примет вполне понятный вид. Важно, что аналитика выполняется в режиме он-лайн, т.е. по текущему набору данных. Если, к примеру, позже придет информация о разрешении выезда, то по коду аналитики мы сможем утверждать: в момент проезда разрешение не было! |
— Бухаров А.В. 2019/06/17 20:33
Стал я расписывать аналитику, и понял, что надо идти не по пути «событие (проезд разрешен - проезд запрещен) → соответствующая ему аналитика», а наоборот: «сначала аналитика, а уже затем событие (проезд разрешен - проезд запрещен)».
Количество условий, проверяемых при въезде и выезде, может быть много. Это сегодня мы знаем 4 условия. В скором времени могут появиться дополнительные условия (например, «Есть признак служебной карты», «Карта в списке разовых гостей» и т.п.)
При этом мы должны сохранить результат анализа для каждого проезда, чтобы в отчетах позже была ясна причина проезда или отказа.
Результат аналитики можно хранить разными методами. Например, побитово, в указанном порядке. Я сейчас отобразил 4 случая. Самый верхний - бит 0, самый нижний - бит 3.
Если выезд не оплачена, но ГРЗ распознан, совпадает с въездом и порядок проезда правильный - код 0001.
Если выезд оплачен, но ГРЗ не распознан, то код получится 0010
Ну и так далее.
Однако побитовая маска требует дополнительных пояснений и расшифровок.
Я предлагаю вместо побитовой маски можно сделать ту же побитовую таблицу, но каждой комбинации дать числовое значение. Например, так:
Бит 3 | Бит 2 | Бит 1 | Бит 0 | Код аналитики | Выезд разрешен? |
---|---|---|---|---|---|
Нарушение порядка проезда | Въезд и выезд разные | ГРЗ не распознан | Не оплачен | ||
0 | 0 | 0 | 0 | 500 | Нет |
0 | 0 | 0 | 1 | 501 | Да |
0 | 0 | 1 | 0 | 502 | Нет |
0 | 0 | 1 | 1 | 503 | Нет |
0 | 1 | 0 | 0 | 504 | Нет |
0 | 1 | 0 | 1 | 505 | Нет |
Такой подход хорош тем, что по мере добавления условий анализа разных разрешений количество кодов аналитики можно увеличивать практически без ограничений, не меняя базы данных.
Будет формироваться список код - выполненные условия. Код 503, например, это значит, что не было ни оплаты, ни распознанного ГРЗ.
И шлагбаум будет открываться только для указанного набор кодов. Т.о. мы сможем менять условия выезда просто редактируя список ситуаций, допустимых для выезда.
Наличие таких кодов упрощается последующую автоматизацию и позволяет расширять набор анализируемых параметров.
Сервер доступен с парковочного сервера по адресу 192.168.0.2 логин РТС1 (буквы русские), пароль 333.
— Бухаров А.В. 2019/06/17 09:10
Первый релиз. В целом работает. ГРЗ ловим, в базу пишем.
— Бухаров А.В. 2019/06/17 23:11
Сегодня в 14:25 что-то там случилось, и драйвер не получал ГРЗ от СР.
При этом драйвер говорит, что СР давала статус подключения ОК (или Актив? я не уточнял).
СВ разбирается.
Тестовая программа работает без сбоев.
— [Самсонов С.В.] 2019/06/18 По поводу аналитики.\\Как оказалось, при появлении фиксации ГРЗ никаких новых причин отказывать в проезде не добавляется.\\Конкретная причина пишется в комментарии и, по опыту, 90% или более всех случаев есть отсутствие оплаты.\\Думаю, что на данном этапе, с учетом того, что изменений в этой части ПО вносится не будет, не следует менять имеющуюся схему.\\Тем более, что именно эти пункты аналитики, если уж говорить честно, тут во многом притянуты за уши.\\Пример. Порядок правильный-нарушен. Для служебных карт проезд будет разрешен, а для гостевых запрещен. То есть однозначно привязать решение о допустимости проезда к комбинации приведенных признаков невозможно. А если добавлять служебная-гостевая, активна-неактивна и т.д., то появляется слишком много комбинаций, десятки если даже не сотни.
У нас появляются несколько моментов, которые не являются основанием для отказа в проезде, но их следует фиксировать.
1.Автокорректировка «Карта свободна». Выдача гостевой карты, которая числится на территории
2.Нарушение последовательности проезда. Въезд/выезд по служебной карте или ГРЗ, если карта или ГРЗ на территории/вне территории.
3.Повторный въезд. При въезде по гостевой карте распознанный ГРЗ числится на территории.
4.Передача карты. При выезде по карте, ГРЗ не совпадает с распознанным на въезде.
Если эти моменты отражать в виде отдельных событий, то их отбор может быть произведен имеющимся ПО, чего нельзя сделать если к разрешению проезда добавлять коды аналитики