На одном предприятии, основным видом деятельности которого является предоставление офисов и складских услуг, возникла необходимость установить СКУД. Клиентами предприятия являются организации и индивидуальные предприниматели, занимающиеся торгово-закупочной и производственной деятельностью. В свою очередь, они имеют большое количество собственных клиентов.
Требования к системе, помимо обычных требований по учету рабочего времени сотрудников арендодателя и арендаторов, включают требования по контролю за клиентами арендаторами, в плане запрета вывоза товаров без отметки об оплате или разрешении на вывоз. Также, необходимо учесть наличие совместителей как на основном предприятии, так и у арендаторов.
Особенности структурной модели
Построим структурную модель СКУД на территорию с одной точкой доступа. Любая точка доступа оборудуется замком, для открытия которого имеется набор ключей. Простейшая модель такой системы включает в себя четыре сущности, играющие определенные роли, например, для квартиры с одной входной дверью:
Однако, даже при самом подробном описании сущностей, они не являются моделью системы, потому что между ними нет связей. Например, описывая дверь, мы должны знать к какой она относится квартире. Устанавливая связи между сущностями (объектами), мы фиксируем результат взаимодействия между ними и задаем связь как набор атрибутов: дверь в квартиру установлена 01.01.2000 (атрибут Дата), замок на двери установлен 02.01.2000 (атрибут Дата) мастером Петровым П.П. (атрибут Мастер).
Так как у каждого из связанных объектов может быть свой «взгляд» на связь между ними, то нужно рассматривать две связи. Например, связь Замок#Двери это набор атрибутов,
{"Имя связи", "Дата установки замка", "Кем установлен замок"}а связь Двери#Замок — набор атрибутов
{"Имя связи", "Дата установки замка", "Кем установлен замок", ["Координаты установки замка"]}
Установка второго замка на дверь, означает появление не только нового экземпляра сущности (без изменения ее роли), но и изменения ее «размерности» — с одномерной Замок, на многомерную Замки. Точно также установка второй двери изменит «размерность» соответствующей сущности:
Сохранение ролей при изменении сущностей (например, их размерности) определяет сохранение и структуры связей между ними. Мы по-прежнему рассматриваем по две связи между многомерными сущностями (объектами), но сами связи становятся многомерными, причем количество компонентов у связи Замок#Двери равно количеству замков в системе, а у связи Двери#Замок — количеству дверей.
Наиболее интересными связями с точки зрения СКУД являются связи между объектом Ключи и объектом Замки (ролями Идентификатор и Преграждающее устройство). Именно в этих связях можно вести учет в какой момент какой замок открывался или закрывался и каким ключом. Связь Ключи#Замки, например,
может иметь вид:
[{"Имя связи", "Операция (открытие/закрытие)", "Время начала операции"}, {}, ..., {}]Связь Замки#Ключи, в свою очередь, может иметь атрибуты, связанные с моментами получения ключей, их утери и замены.
В любом, случае к объектам мы относим элементы системы, чьи атрибуты практически не изменяются за время наблюдения за ней, в отличие от связей, чьи атрибуты за это же время могут существенно изменится. Выбор набора атрибутов для элементов системы целиком определяется конструктором системы при ее моделировании.
Роли и объекты структурной модели
В реальной СКУД нужно учитывать ряд новых ролей и объектов их исполняющих. Добавим в структурную модель нужно роль Владелец идентификатора, объект, исполняющий эту роль, назовем Посетителем, а также изменим исполнителей некоторых ролей:
Связь Метки#Посетители:
[{ "Имя связи", "Имя посетителя", "Тип метки": (Постоянный, Временный, Разовый) ", "Дата начала владения", "Дата окончания владения", "Статус метки": (Активный, Неактивный)}, ...]Такая связь позволяет:
однозначно идентифицировать посетителя по метке (только одна запись в связи может иметь Статус метки=Активный);
выдавать сотруднику разовый или однодневный временный пропуск взамен забытого;
задавать срок действия временного пропуска.
Связь Посетители#Метки:
[{"Имя связи", "Имя метки", "Причина добавления новой метки"}, ...]Такая связь позволяет организовать, например, начисление штрафных баллов на сотрудника, потерявшего карту доступа или регулярно ее забывающего.
Связь Считыватели#Метки:
[{ "Имя связи", "Имя метки", "Статус метки": (Вход разрешен, Вход запрещен, Выход разрешен, Выход запрещен), "Время считывания"}, ...]Такая связь позволяет вести журнал учета событий со считывателем.
Связь Метки#Считыватели устанавливать не будем, так как для нее нет значимых атрибутов.
Получение статуса Вход разрешен, еще не означает, что вход состоялся. Для того, чтобы отобразить атрибуты связанные с переходом добавим связи между метками и турникетом.
Связь между меткой и считывателем должна показывать какая метка каким считывателем и когда определяется, а также фиксировать статус метки.
Связь Метки#Турникет:
[{ "Имя связи", "Имя Турникета", "Направление": (Вход, Выход), "Время перехода"}, ...]Такая связь позволяет вести учет переходов через турникет каждым посетителем в соответствии с его меткой.
Связь Турникет#Метки:
{ "Имя связи", ["Имя Метки", "Направление": (Вход, Выход, Не определено), "Время перехода"]}Такая связь позволяет вести журнал посетителей и переходов. Если невозможно определить направление перехода (турникет открыт кнопками в обоих направлениях), а переход осуществлен, в связи указывается время перехода с неопределенным направлением и пустым именем метки.
Связи между турникетом и считывателями, а также турникетом и зоной доступа могут использоваться для учета эксплуатации устройств, например, связь Турникет#Считыватели:
{"Имя связи", ["Имя cчитывателя", ["Событие": (Установка, Ремонт, Замена) ,"Время события"]]}Чтобы определить направление перехода в связях Метки#Турникет и Турникет#Метки нужно знать позицию посетителя (метки) по отношению к зоне доступа. Соответствующий атрибут удобно держать в связи между меткой и зоной доступа, поэтому создадим соответствующую связь:
Связь Зона_доступа#Метки:
{"Имя связи", ["Имя Метки", "Имя Посетителя", "Позиция"]}Такая связь позволяет определить позицию Посетителя в любой момент времени, а также обеспечить контроль за сменой позиций при наличии нескольких зон доступа. Например, Посетитель не может попасть во внутреннее помещение, если он не вошел через турникет.
Связь Метки#Зона_доступа:
[{"Имя связи", "Имя Зоны ", "Время входа", "Время выхода", "Время пребывания"}]Такая связь позволяет получать необходимые данные для учета рабочего времени с учетом фактического времени пребывания на территории. Однако этих данных не достаточно. Во — первых, нужна информация о фирме-работодателе (фирмах-работодателях), а во-вторых — информация о графике работы. Для учета такой информации добавим новый объект Фирма в роли Работодатель и установим связи между ней и сотрудниками (Посетители).
Связь Посетители#Фирма:
[{"Имя связи", "Имя фирмы", "Время прихода на работу факт", "Время прихода на работу учет", "Время ухода с работы факт", "Время ухода с работы учет", "Время пребывания на работе факт", "Время пребывания на работе учет"}]Такая связь содержит все данные необходимые для учета рабочего времени, а также разрешения возможных конфликтных ситуаций. Учетные данные строятся на основании сравнения фактических данных и графиков работы. Данные по графику работы содержаться в связи Фирма#Посетители:
{"Имя связи", ["Имя посетителя", "Посещение в нерабочие дни", "Режим работы", ["Дата", "Время прихода на работу план", "Время ухода с работы план", "Время пребывания на работе План"]]}Такая связь позволяет учитывать данные по графику работы для каждого сотрудника, а также запрещать или разрешать вход в Зону доступа в нерабочие дни. Данные для связи формируются вне СКУД и должны поступать от фирм.
Теперь рассмотрим контроль за клиентами фирм. Такие посетители являются покупателями или поставщиками (или их представителями) фирм. Фирмы для них выступают не в роли Работодателя, а в роли Поставщика или Покупателя. Таким образом, у объекта появляется несколько ролей:
Соответственно изменяется и количество связей между посетителем и фирмой. И хотя теперь каждый посетитель может играть роли Сотрудника, Покупателя или Поставщика, в рамках структурной модели мы оставляем ему только одну роль — Владельца идентификатора. Зато увеличение количества связей
позволяет собирать и хранить всю информацию, необходимую для контроля за клиентами арендаторов.
Связь Посетители#Покупатель#Фирма:
[{"Имя связи", "Имя фирмы", "Время получения товара", "Время оформления документов", "Время оплаты товара"}]Такая связь позволяет разрешать выход покупателя в зависимости от условий, наложенных поставщиком (все три времени не нулевые). Аналогично, в связи Посетители#Поставщик#Фирма:
[{"Имя связи", "Имя фирмы", "Время получения товара", "Время оформления документов"}]содержатся данные необходимые для разрешения поставщику покинуть территорию.
Таким образом, мы построили достаточно простую структурную модель СКУД, позволяющую решать все задачи, стоящие перед такими системами, а также ряд дополнительных задач.
В дальнейшем будет изложена система управления редактированием данных и их хранение, а также приведен пример реализации с описанием использованных устройств.
Автор: LRpro
