Развіццё тэхналогій аказала значны ўплыў на архітэктуру сістэм кантролю доступу. Прасачыўшы шлях яе развіцця, можна прадказаць, што ж чакае нас у найбліжэйшай будучыні.
Мінулае
Даўным-даўно кампутарныя сеткі яшчэ былі вялікай рэдкасцю. І тагачасныя СКУД будаваліся наступным чынам: майстар - кантролер абслугоўваў абмежаваную колькасць кантролераў, а кампутар выступаў у ролі тэрмінала для яго праграмавання і адлюстравання інфармацыі. Логіку працы вызначаў майстар-кантролер, які кіруе другаснымі кантролерамі.
Другасныя кантролеры не маглі абменьвацца інфармацыяй наўпрост адзін з адным, абмен адбываўся праз майстар-кантролер. Такая мадэль накладвала значныя абмежаванні на развіццё сістэм кантролю доступу.
Развіццё кампутарнай тэхнікі і сеткавага абсталявання паўплывала на архітэктуру сістэм, у выніку чаго з'явіліся мультысерверныя СККД. Змены закранулі праграмнае забеспячэнне, але абышлі кантролеры, што накладвала абмежаванне на нарошчванне і развіццё сістэмы.
цяперашні
Развіццё мікраэлектронікі дало магчымасць вытворцам абсталявання ў корані памяняць архітэктуру СКУД. На змену мінулай мадэлі прыйшла архітэктура, у якой кантролеры змаглі абменьвацца дадзенымі напрамую адзін з адным.
У такой мадэлі праграмнае забеспячэнне магло быць усталявана ў любым месцы ў межах лакальнай сеткі, інтэграцыя з іншымі сістэмамі бяспекі спрашчалася за рахунак выкарыстання адзінага асяроддзя абмену інфармацыяй.
Гэтая мадэль паспяхова працуе і дагэтуль, але бягучы ўзровень тэхналагічнага развіцця дазваляе будаваць сістэмы з зусім іншай архітэктурай. Існуе шырокі спектр фізічных і лагічных варыянтаў забеспячэння сувязі паміж кампанентамі сістэмы і сродкаў узаемадзеяння паміж карыстальнікамі і сістэмай. Сярод іх кансольныя прыкладанні, спецыялізаваныя кантролеры з графічным інтэрфейсам, розныя пульты кіравання, планшэтныя кампутары і тэлефоны, выкарыстанне стандартных WEB браўзэраў. Магчымасці мікракантролераў ужо ў шмат разоў пераўзыходзяць рэсурсы кампутараў выкарыстоўваных у першых СКУД.
Далейшае развіццё архітэктуры СКУД
Кантролер як сервер
Сервер у СКУД патрэбен, каб карэктна выконваць бізнэс-логіку сістэмы, захоўваць дадзеныя аб карыстачах і падзеях. 20 гадоў таму з гэтым спраўляўся і майстар-кантролер. З тых часоў патрабаванні да сістэм кантролю доступу значна ўзраслі, але і магчымасці сучасных кантролераў пераўзыходзяць магчымасці кампутараў 20-гадовай даўніны.
Сервер сістэмы можа быць усталяваны і ў самім кантролеры, калі ён валодае адпаведнымі рэсурсамі. Сервер сістэмы, які разгортваецца ў памяці кантролераў, мае значныя перавагі. Першае з іх - прастата запуску сістэмы.
Адзін з кантролераў сістэмы прызначаецца серверам (ці майстрам, як калісьці), ён атрымлівае ўказанні, з якімі кантролерамі ён будзе працаваць. Усё, сістэма гатова. Для працы з выдаленымі аб'ектамі кантролеру, прызначанаму серверам, даецца "белы" IP, ён паказваецца іншым кантролерам, і яны самастойна падлучаюцца да яго. Для інтэграцыі з 1С трэба проста перадаць у праграму адрас кантролера. Для інтэграцыі з сістэмай распазнання нумароў - пазначыць у якасці нумара пропуску нумар аўтамабіля і IP-адрас камеры або сістэмы, здольнай распазнаваць аўтамабільныя нумары.
СКУД як сэрвіс
Другая важная перавага - зручнасць карыстальнікаў. Заказчыку больш не трэба думаць, на якім кампутары разгарнуць сістэму, дзе ён будзе стаяць, і хто будзе яго абслугоўваць. Зараз кліент проста атрымлівае IP адрас, лагін і пароль - і можа сачыць за дысцыплінай супрацоўнікаў, прызначаць правы доступу і выдаваць гасцявыя пропускі ў любым зручным яму браўзэры. Досыць набыць турнікет і кантролер (ці гатовае рашэнне - электронную прахадную) і ідэнтыфікатары. І сістэма гатова.
Такі падыход максімальна адпавядае сучаснаму трэнду ўспрымання СКУД як сэрвісу. Замовец не думае аб усталёўцы і абслугоўванні сістэмы, усё гэта выдалена ажыццяўляюць адмыслоўцы. Тут непазбежна ўзнікае пытанне аб хуткадзейнасці кантролера і яго здольнасці працаваць з 10 тысячамі карыстачоў і 200 турнікетамі? Пакуль гэта не ўяўляецца магчымым, але базу дадзеных можна размясціць у воблаку або на выдзеленым серверы. З часам магчымасці кантролераў будуць расці, і апісаную вышэй сістэму можна будзе разгарнуць нават на буйных прадпрыемствах з вялікай колькасцю супрацоўнікаў і выканаўчых прылад.
будучыню
Стандартызацыя як трэнд
Архітэктура СКУД будзе будавацца на аснове "разумных" кантролераў, якія будуць самастойна ўзаемадзейнічаць паміж сабой, маючы сярод сябе некалькі майстар-кантролераў, якія выконваюць ролю сервера. Яны таксама змогуць аб'ядноўвацца на базе адзінага сервера (ці некалькіх сервераў), які забяспечвае неабходную логіку ўзаемадзеяння.
Неабходна, каб стандартызацыя пратаколаў была падтрымана ўсімі гульцамі рынку - не толькі на ўзроўні ўзаемадзеяння з кантролерам, але і на ўзроўні ўзаемадзеяння сістэм.
Магчыма, распрацоўка адзінага стандарту будзе рэалізавана ў далёкай будучыні. Але нават калі гэтага не адбудзецца, стандартызацыя ўзаемадзеяння на аснове REST API і доступ да інфармацыі праз браўзэр павінны быць рэалізаваны як мага хутчэй.
Крыніца: habr.com