СКУД. Знать, что хочет заказчик

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

и так не может...

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

Специально для водителя автобуса, чтобы со всеми не уехать))):

и билеты для пассажиров

Ну и как, по жизни, проходит сиё предрейсовое мед.освидетельствование ? :) Дают "клюкиной" 100 рупелей в лапу, и дует она (весело) в динго заместа водителя и весело-с-хитринкой ждёт следующего трудника ... Ибо какая ей разница, пришол-шофер опохмелившемся VS опохмелится апосля продувки ...а 100 рэ к ее зряплате ( 4 тыр/месяц) ощутимая = премия .

А вот и Клюкина, сообственной персоной)))

и сколько объектов/заводов на нашей необъятной Родине оборудованы данной системой?

и сколько объектов/заводов на нашей необъятной Родине оборудованы данной системой?

Потенциально-принципиально можно обуть всех владельцев рыдванов ...))) В каждый рыдван = ДИНГО . Дунул-плюнул, если бОльше 5-и промиле в завод можно не ходить . По каналу связи GSM кидаем данные сервиса GPS ближайшему вытрезвителю ...вуаля, не гибнет бОльше в заводе = НАРОД .

Все уже есть, даже в труднодоступных местах)))

Читать здесь http://secuteck.ru/articles2/security-director/raspredelennaya-skud-i-urv-na-gornodobyvayuschih-predpriyatiyah/

Забавно...

Хочу сказать, что все задачи по опросу алкотестера, чтения карт, управление устроствами преграждения можно просто и эффективно реализовать вообще безо всякого оборудования СКУД.

Или, скажем так, СКУД он-лайн (Юрий Михеевич это сразу понял, потому и видео там вывесил с правильным названием).

От он-лайн СКУДа тут только плюсы будут: можно работать с любым оборудованием, с любым количеством, реализовывать любые разумные алгоритмы и не зависеть от самого оборудования.

Если будет такая потребность - с удовольствием поучаствую. Все уже готово.

От он-лайн СКУДа тут только плюсы будут: можно работать с любым оборудованием, с любым количеством, реализовывать любые разумные алгоритмы и не зависеть от самого оборудования.

Можно назвать и так, я предпочитаю "интеграционные платформы". Интеграционные платформы начали появляться достаточно давно - в конце 90х, когда производство оборудования в нашей стране было практически уничтожено (оставались только единицы выживших) и все оборудование поступало в основном из-за рубежа. В то время было проще и быстрее написать код и начать зарабатывать на нем деньги, но сегодня везут одно, завтра другое - не переписывать же все время код? Сейчас у таких продуктов открылось второе дыхание (интересно, что многие производители даже не подозревали в таких возможностях, так как ориентировались в основном на классическую СКУД). Из-за снижения стоимости комплексов в данной сфере пришлось искать новые пути развития (так как такие платформы стоят достаточно дорого) и выход был найден достаточно быстро и я считаю успешно, наверное из-за этого я отношусь с некоторой настороженностью к классическим СКУД с формулировкой для промышленных предприятий. Кстати, в результате таких поисков были найдены модули, про которые уже давно забыли и не получили широкого распространения в свое время, но очень актуальные сейчас. Понятно, что такие "платформы" ориентировались в основном на СКУД и для того чтобы они могли управлять документооборотом или циклом производства необходимы некоторые модернизации, но основной фундамент уже есть. Отсюда возникает справедливый вопрос, а так ли дешево получиться внедрить простой СКУД на предприятии, где работает 50 000 - 100 000 тыс. человек и получит ли Заказчик, то что он хотел?

http://secuteck.ru/articles2/Preview/7-trendov-novogo-pokoleniya/

6. Открытые платформы. Программные миры заменяют монософт. На смену обособленным системам приходят программные платформы управления, объединяющие технологические среды. Пользователи получают единое пространство для анализа разнородных данных. Чем больше сервисов встраивается в платформу, тем больше бизнеса генерят разработчики и партнеры по сбыту.

но сегодня везут одно, завтра другое - не переписывать же все время код?

Это смотря какая архитектура исходного ПО.

При правильной архитектуре код можно не переписывать, а ДОписывать.

Самый наглядный пример тому - пакет ТС Офис.

Офис НЕ переписывают, и даже не дописывают при появлении нового принтера, сканера или другой какого девайса.

Это пример правильной архитектуры ПО.

И тут мы плавно подходим ктому, что есть

программные платформы управления, объединяющие технологические среды

Тут, правда, каждый волен понимать что угодно под этой формулировкой...

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

Давайте рассмотрим ваше решение интеграции.

Выбранный Вами вектор движения - "аппаратная" интеграция алкотестера с контроллером СКУД - путь в тупик. Это монорешение.

Возможное изменение хоть одной компоненты (отказ от RFID и желание перейти на биометрию) рушит всю систему. Чтобы опять обеспечить ее работу необходимо старое оборудование выбросить, новое купить, тренируется на кроликах и порождаем новое монорешение?

Тупичокс... Это анализ текущего решения.

Какие альтернативы? Например, использовать

программные платформы управления, объединяющие технологические среды

Это будет уже синтез.

Если Вы, pavlikspb, знаете про эти платформы, почему же Вы пошли по заведому тупиковому пути?