Уважаемые специалисты, подскажите пожалуйста, в каком месте стоит искать корень проблемы - имеется некая самописка для сканирования беджиков (учет в заводской столовой, кто когда ел). Выглядит она примерно так - Компьютер с убунтой и подключенным сканером (метролоджик), на компе вертится некий фронтэнд на пхп и яве, данные выгружаются в mysql, после чего некие отчеты показывают полученные данные в удобном виде. Когда эта система ставилась, считалось, что отсканировать неверный Ш/К будет невозможно - контрольная цифра, ламинированный бедж и все такое. В реальности нечасто, но постоянно раз в месяц/два появляются непонятные сканирования: покушал человек, числившийся уже уволенным (такие вещи запрещены программно - в базе у сотрудника есть поле Active, либо человек из другого города и в эту столовую никак не могущий попасть, либо один и тот же Ш/К дважды в день. Я пытаюсь понять, отчего такое вообще может произойти - то ли люди меняются пропусками, то ли виноваты беджики без ламинирования (встречается), прочие варианты:
дефект сканера,
дефект драйвера в убунте
дефект программы (написана на коленке)
дефект мускула или его настройки

вопрос такой - скорей всего виновато железо или софт (и его настройка)? Если второе - то лучше поменять программную начинку, если первое - придется менять еще и сканер и вводить например магнитные карты.

(0) Контрольный разряд сразу отметает ошибку чтения, у тебя кто-то человеческим фактором троллит.

железо не может быть виновато, даже если железо криво прочитало код софт обязан это отловить и заставить бейджиком провести еще разок...

а вообще думаю все просто, кто-то сделал ксерокопии старых бейджиков :)

(1) не отметает. Если многократная ошибка, то может и совпасть с контрольным разрядом. Причем не факт, что другой сканер прочитает так же. Были такие случаи.

(2) мне тоже так кажется, ШК использовать для контроля доступа куда-либо дурная идея. Либо карты, либо сканер пальцев.

хотя карту тоже можно передать или даже сделать ее копию, но хотя бы копию технически сложнее сделать чем копию ШК

(3) Вероятность того, что при ошибке чтения неправильно считается один символ и при этом соответственно неправильно считается контрольный разряд так, что он под ошибку скорректируется... хм, даже не знаю, насколько редкими такие случаи могут быть. Не было бы лень - посчитал бы шанс на такое совпадение, но даже навскидку он мизерный.

Есть еще один вариант - кто-то в базу грязными ручонками лазит, его тоже отметать не стоит.

(1) самая вероятная ошибка кроется в софте, ибо он написан в режиме "черный ящик" на коленке, но я должен сначала убедиться, что другие варианты отпадают

(2) а смысл копировать старые беджи? Тем более что технически система должна была послать и сказать "уволенный человек не может здесь питаться".

(4) Когда-то эта система работала на винде и 1С 7.7. Ошибок не было (возможно их не находили).

(5) я понимаю принципиальные ограничения (что запретить передавать беджи невозможно)

(7) у базы сейчас один разработчик, документации нет и не будет (линуксоиды маны не пишут).

(8) "копировали" это фигурально. На практике человек, к примеру, мог слить базу кодов. Мог догадаться как они формируются (например из табельного номера). Мог тупо накопировать себе этих беджей много и пользоваться случайным образом какими-то из них. Важно что тут есть принципиальная и неизлечимая дырка.

(9) я понимаю, но при этом не понимаю -какая прибыль от копирования беджа? Обед за 45 рублей?

(10) "Одна старушка - рубль, десять - уже червонец" (с)

Добавь в систему логирование. Для начала пиши в лог, все что сканер отдает. При ошибке сверишь.

(10) ну мало ли, может человек или его родственники свинюшек держат. Или носит домой любимой собачке. Всему можно найти применение. А если это делать регулярно, можно нехило сэкономить.

(3) Вот такого чтобы контрольник считался неверно - не припомню. Припоминаю другое - неправильно считывается 2-3 разряда из значащих 12, значение уже здорово непохоже на то которое должно быть - а контрольник при расчете сходится. И сканер эту белиберду возвращает в приложение. Было не раз.

к (6)

(14) и какова вероятность что совпадет с уже существующим в базе Ш/К?

+(16) Точнее что можно сделать, чтобы сбой сканирования не возвращал заведомо неподходящий Ш/К? Заполнять все незначащие нулевые разряды случайными цифрами?

(17) можно ввести дополнительный контрольный символ и проверять его в приложении самостоятельно. Правда, обычно такими вещами балуются с более длинными последовательностями чем EAN13...

хотя у кого-то я и на EAN13 такое видел

а это где?)

(18) ввести доп.контрольный символ на этапе формирования Ш/К? Интересная идея.

ШК может считаться криво. Такое бывает.
Выход - считывать дважды или усложнять штрихкод.

(21) она древняя как какашка мамонта. Чем длиннее код, тем больше вероятность того что он считается неверно, если у вас CODE128 и символов 25-30, то дополнительные разряды контроля уже жизненная необходимость. Кстати, в (22) тоже верное предложение. Настройте свой сканер на 3-4 повторяющихся чтения, многие сканеры такое умеют.

(22) А смесь идей из (17)+(19) - "Заполнять все незначащие нулевые разряды случайными цифрами" + "ввести дополнительный контрольный символ" - может прокатить?

(23) повторное сканирование - идя хорошая для, к примеру, продавца в магазине. А заставлять 3 раза махать беджиком человека пришедший покушать - идея не совсем удобная.

камеру поставь и смотри по камере кто это был

(24) не надо махать ничем. Надо сканер настроить на несколько повторных чтений и если разночтение, то выбирает то что встретилось больше раз. Cipher, например, умеет такое делать.

отражается это только на скорости чтения - больше времени проходит между нажатием кнопки и моментом пока сканер пискнет

на фронт вывести еще и фотку сотрудника

(8) купи слона:
http://catalog.mista.ru/public/16464/
http://content.screencast.com/users/Che66/folders/Jing/media/985c160f-b16f-4d07-9508-257103008452/2015-07-15_1650.png