В системе 18 считывателей С2000-BIOAccess-MA300. На текущий момент в базе порядка 250 отпечатков пальцев и 50 карт доступа. Ядро опроса и сервер размещены на одном и том же ПК. В процессе пусконаладки и использования в течении 2 месяцев выявились следующие проблемы:

1. При длительной потере связи с каким либо из считывателей  (несколько часов),  невозможно зайти в АБД. Необходимо выгрузить оболочку и снова зайти. Потеря связи определялась стройготовностью объекта - некоторые считыватели при пусконаладке были занесены в базу, проверены и в них записаны тестовые ключи (через АБД). Но на объекте не все считыватели были установлены сразу, либо их приходилось отключать в процессе пусконаладки. Чтобы исключить проблему приходится устанавливать в АБД атрибут "не опрашивать" на неустановленный считыватель и тогда проблема исключается. Но в реальной эксплуатации также может происходить потеря связи со считывателями и тогда проблема снова проявится.

2. В мониторе и в отчетах невозможно определить по какому идентификатору прошел сотрудник: по отпечатку пальца или по карте?  Заказчику хотелось бы иметь такую информацию.

3. В АБД не работает "Поиск лишних ключей в приборах" и "Поиск дубликатов ключей в приборах". Понятно что с отпечатками пальцев это может быть сложно - но эти поиски не работают и для кодов проксимити карт. Выводится только IP адрес компьютера и далее мгновенно "....... ключей  не обнаружено". Процесс "считывания конфигурации из приборов и ключей" - также "не виден" - при переходе на эту вкладку сразу показывается конфигурация 100 % и количество ключей. Можно предположить, что они считываются мгновенно, но почему тогда синхронизация 300 ключей или перезапись этих же ключей в 18 приборах занимает у нас несколько часов???

4. Бывает, что удаление ключа (отпечатка или карты) в АБД не приводит к его реальному удалению в считывателе. В АБД все хорошо, даже если провести синхронизацию. Перезапись ключей в приборе не решает проблему удаления лишнего ключа, а штатными средствами поиска это сделать тоже не удается (см. пункт 3). Пока нашли только такой способ: выгружаем все модули Ориона, запускаем утилиту Baprog, удаляем с ее помощью все ключи из считывателя, удаляем файл кэша для данного прибора из Devconf (если не удалить кэш, АБД потом покажет, что все хорошо и все ключи на месте). Запускаем АБД и делаем перезапись всех ключей в данном приборе. После этого ключи работают нормально. При перезаписи ключей удивляет скорость перезаписи - ощущение что считыватель работает на скорости 9600 бит/сек. 250 отпечатков и 50 карт записываются в один считыватель примерно 15 минут.  А ведь это всего лишь отпечатки 125-ти сотрудников. Далее в базе будет 600-800 сотрудников.....

5. Операция синхронизации всех ключей иногда приводит к странным последствиям - при поднесении некоторых прокси-карт дверь не открывается, а считыватель произносит фразу "поднесите пожалуйста палец". Причем палец не принимает. Также на некоторое время (приблизительно секунд 30) данный считыватель не принимает любую другую карту, которая нормально открывала эту же дверь до поднесения "странной" карты. То есть некоторые карты ведут себя как карты с подтверждением пальцем, но это не работает, а дверь на время блокируется. В базе эти странные карты прописаны верно - также как и все другие работающие. Проблема решается как и в пункте 4 - удалением всех карт из считывателя через Baprog и перезаписью всех карт в считывателе через АБД. Причем после операции синхронизации всех ключей это надо сделать во всех считывателях!!! (несколько часов утомительной работы).  Удаляемые перед этим файлы конфигурации из Defconf снова  формируются.


6. В генераторе отчетов невозможно просмотреть "маршрут  движения по коду ключа". Код ключа проксимити карты выводится, добавляется в окно поиска, но отчет всегда пустой.  Такое ощущение, что некоторые модули системы работают только с внутренними идентификаторами ключей самих считывателей (ключ 302, ключ 303 и т.д и т.п) и не сопоставляют идентификаторы с реальными с кодами прокси-карт из базы при операциях поиска и в журналах (может в этом проблема и в пункте 2. данного списка проблем?).

7. Для ввода карт мы используем отдельный считыватель С2000-BIOAccess-MA300, установленный в отделе персонала точно также как и все другие считыватели, чтобы пользователь максимально правильно ввёл отпечаток. Через этот  же считыватель вводим в систему прокси-карты. Кадровик-оператор работает на удаленном рабочем месте. Если при вводе отпечатка произвести отмену процесса ввода, либо процесс ввода прервётся по тайм-ауту, то на сервере будет висеть незакрытый процесс ввода отпечатка, который оператор не может закрыть со своего рабочего места и продолжать вводить отпечатки считыватель не будет.  Надо либо закрывать вручную на сервере, либо делать операцию "обновить БД в ОЗ" с УРМа (что сейчас оператор и делает в этом случае). Но это не совсем удобно и тоже вызывает ряд проблем (см. пункт 8).

8. При операции "обновить БД в ОЗ" Badriver получает приборы и передает их в систему - что наглядно видно в графическом интерфейсе Badriver на сервере - при удачной передаче прибора в систему, напротив прибора появляется плюсик "+". Иногда, довольно часто, именно при операции "обновить БД в ОЗ", реже при полном запуске после перезагрузки сервера, передача некоторых приборов в систему НЕ ПРОИСХОДИТ. Плюсик напротив прибора не появляется. Оператор на удаленном УРМе этого не видит и при вводе отпечатка или кода карты он не прописывается в данный прибор без "плюсика". Приходится заходить на сервер, открывать интерфейс Badriver и прибору без "плюсика" делать операцию "пересчитать приборный кэш". После этого прибор передается в систему и можно сделать синхронизацию недописанных ключей, по одному ключу за раз. (синхронизацию всех ключей уже боимся делать см. пункт 5). 

9. Состояние дверей (взломана, заблокирована) не передаются в ОЗ в обычном режиме. Они появляются лишь после операции "обновить БД в ОЗ". Причем это как на сервере так и на УРМ. После "обновить БД в ОЗ"  валится целая куча сообщений (несколько десятков) о разблокированных или взломанных дверях за весь период пока не было этой операции или перезагрузки сервера.

10. У нашего сервера Орион Про две сетевых карты. К одной подключены считыватели и УРМ. Вторую хотелось бы тоже использовать для другой подсети. Но как только мы включаем вторую сетевую карту, то перестаем видеть информацию о ключах - "должен храниться в приборах" - "храниться в приборах" при переходе на вкладку "считать конфигурацию из приборов" или при клике на вкладку "подробно", чтобы получить информацию о ключе. Вместо информации о ключе появляется сообщение "Не найден компьютер с адресом....."  Проблема известная и в Windows 7 решалась изменением приоритета сетевого подключения в интерфейсе настройки сетевого адаптера - адаптер передвигался стрелочками в верхнюю позицию.  В Windows 10 такой настройки нет, назначение метрики основного адаптера (меньше чем неосновного) не дает никакого эффекта.

Конфигурация системы
Badriver Версия 1.31 (выпуск 0, постройка 38) дата сборки 25.11.2016
АРМ Орион Про: Модуль: Р.АЦДР. 00381  мультидрайвер версия 1.3

Администратор базы данных Орион Про  версия 1.20 (выпуск 1, постройка 3895)
АРМ Орион Про версия 1.20 (выпуск 1)
АРМ Орион Про: Р.АЦДР.00027  Модуль Р.АЦДР. 00027

Ядро опроса версия 1.20 (выпуск 1, постройка 5605) 
ID ключа 33981817, лицензия на 127 приборов. 
АРМ Орион Про: Р.АЦДР.00011 Модуль: Р.АЦДР. 00011

Монитор Орион Про версия 1.20 (выпуск 1, постройка 3462)
АРМ Орион Про: Р.АЦДР.00026  Модуль Р.АЦДР. 00026

Центральный сервер Орион  версия 1.20.1.167  
номер ключа: 33982069

Аппаратная конфигурация сервера:
Windows 10 Pro x64
Intel(R) Core(TM) I5-7500 CPU 3.4 GHz  3.41  
8Gb RAM

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