Зайти по RDP на 194.87.237.67

Логин:Administrator

Пароль: запросить у Бухарова.

— Бухаров А.В. 2019/06/17 20:33

Стал я расписывать аналитику, и понял, что надо идти не по пути «событие (проезд разрешен - проезд запрещен) → соответствующая ему аналитика», а наоборот: «сначала аналитика, а уже затем событие (проезд разрешен - проезд запрещен)».

Количество условий, проверяемых при въезде и выезде, может быть много. Это сегодня мы знаем 4 условия. В скором времени могут появиться дополнительные условия (например, «Есть признак служебной карты», «Карта в списке разовых гостей» и т.п.)

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

Результат аналитики можно хранить разными методами. Например, побитово, в указанном порядке. Я сейчас отобразил 4 случая. Самый верхний - бит 0, самый нижний - бит 3.

Если выезд не оплачена, но ГРЗ распознан, совпадает с въездом и порядок проезда правильный - код 0001.

Если выезд оплачен, но ГРЗ не распознан, то код получится 0010

Ну и так далее.

Однако побитовая маска требует дополнительных пояснений и расшифровок.

Я предлагаю вместо побитовой маски можно сделать ту же побитовую таблицу, но каждой комбинации дать числовое значение. Например, так:

Такой подход хорош тем, что по мере добавления условий анализа разных разрешений количество кодов аналитики можно увеличивать практически без ограничений, не меняя базы данных.

Будет формироваться список код - выполненные условия. Код 503, например, это значит, что не было ни оплаты, ни распознанного ГРЗ.

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

Наличие таких кодов упрощается последующую автоматизацию и позволяет расширять набор анализируемых параметров.

Сервер доступен с парковочного сервера по адресу 192.168.0.2 логин РТС1 (буквы русские), пароль 333.

— [Самсонов С.В.] 2019/06/18

По поводу аналитики.
Как оказалось, при появлении фиксации ГРЗ никаких новых причин отказывать в проезде не добавляется.
Конкретная причина пишется в комментарии и, по опыту, 90% или более всех случаев есть отсутствие оплаты.
Думаю, что на данном этапе, с учетом того, что изменений в этой части ПО вносится не будет, не следует менять имеющуюся схему.
Тем более, что именно эти пункты аналитики, если уж говорить честно, тут во многом притянуты за уши.
Пример. ГРЗ распознан или нет вообще никакого значения для принятия решения не имеет, и кроме того, это легко определить, просто посмотрев на поле в базе. Порядок правильный-нарушен. Для служебных карт проезд будет разрешен, а для гостевых запрещен. То есть однозначно привязать решение о допустимости проезда к комбинации приведенных признаков невозможно. А если добавлять служебная-гостевая, активна-неактивна и т.д., то появляется слишком много комбинаций, десятки если даже не сотни.

У нас появляются несколько моментов, которые не являются основанием для отказа в проезде, но их следует фиксировать.
1.Автокорректировка «Карта свободна». Выдача гостевой карты, которая числится на территории
2.Нарушение последовательности проезда. Въезд/выезд по служебной карте или ГРЗ, если карта или ГРЗ на территории/вне территории.
3.Повторный въезд гостя. При въезде по гостевой карте распознанный ГРЗ числится на территории.
4.Передача карты. При выезде по карте (любой, в т.ч. служебной), ГРЗ не совпадает с распознанным на въезде.
Если эти моменты отражать в виде отдельных событий, то их отбор может быть произведен имеющимся ПО, чего нельзя сделать если к разрешению проезда добавлять коды аналитики