Центарот за прием на аларми (ARC), исто така наречен Централна мониторинг станица на некои пазари, е професионална организација која прима одбрани извештаи за аларми од заштитено место и ги обработува според услугата договорена за таа сметка.
За инсталатерот, важното прашање не е само дали Hub поддржува ARC известување. Туку дали проектот може да го испрати вистинскиот настан на вистинската ARC сметка, да докаже дека ARC го примил и да се осигури дека сите знаат што треба да се случи следно.
Тоа е она што ја претвора поддршката на ARC од производна способност во функционална услуга за аларми.
Зошто еден проект за аларм би користел ARC?
Размислете за мала продавница откако ќе ја затворите.
Контактот на задната врата создава настан за аларм. Центарот го прима и, кога известувањето на ARC е конфигурирано за тој проект, го испраќа избраниот извештај преку мрежата до ARC приемникот. ARC ја идентификува сметката на клиентот и настанот, а потоа ја следи акцијата договорена за таа сметка.
Работната патека е:
Уред → Центар → патека за известување → ARC приемник → што треба да направи ARC следно
Секоја фаза има различна задача. Уредот и Hub-от го креираат настанот на локацијата. Конфигурацијата за известување го поврзува тој настан со наменетиот примач и сметка. ARC го додава професионалното ниво за примање и услуга.
Ова е важно кога избраните настани треба да стигнат до надворешен тим, наместо да се потпираме само на луѓе одговорни за локацијата за да ги забележат и да се справат со нив. Точниот одговор - како што е контактирање на именувано лице или следење на друг чекор на ескалација - го дефинираат клиентот и ARC за сметката на услугата.
Каде најчесто грешат проектите на ARC?
Повеќето проблеми со пуштањето во работа на ARC се појавуваат кога еден дел од патеката се предава на следниот. Центарот може да го креира точниот локален настан, додека ARC не гледа ништо. Може да пристигне извештај, но операторот на ARC може да следи друга сметка или да очекува различен тест настан. Двете страни може да бидат подготвени, но не е договорен споделен тест прозорец.
Ова се различни проблеми. Третирањето на сите нив како дефект на детекторот троши време и може да ја остави вистинската празнина нерешена.
Врати се во малата работилница. Инсталатерот го активира контактот на задната врата откако работилницата ќе се постави во договорената тест состојба. RB Link го прикажува локалниот алармен настан и однесувањето на локалниот систем е правилно. Сепак, операторот на ARC не може да го види очекуваниот извештај.
Корисен одговор е да се провери патеката во три слоја.
1. Дали системот на локацијата го генерираше очекуваниот настан?
Започнете од заштитената точка. Потврдете дека наменетиот контакт на вратата ја променил состојбата и дека центарот го формирал точниот локален настан за наменетиот уред или зона.
Ова утврдува што всушност се случило на лице место пред тимот да истражи пријавување или примање.
2. Дали Центарот ја користи наменетата конфигурација за известување?
Roombanker Центрите можат да известуваат до ARC или приемник преку мрежа. Тековно поддржаните опции за известување вклучуваат SIA DC-09 и ADM-CID/Идентификациски број на контактЦелниот ARC сè уште треба да потврди која поддржана опција за известување и патека за примање ќе се користи за проектот.
За моменталното поставување на RB Link ARC, инсталерот ги внесува главната адреса, бројот на портата и бројот на сметката обезбедени од ARC . Во примерот на продавницата, овие детали треба да го идентификуваат истиот приемник и сметка што операторот на ARC ги следи за време на тестот.
За повеќе информации за протоколот, видете Како SIA DC-09 ги поврзува алармните системи со ARC.
3. Дали ARC ја потврди точната сметка и настан?
Ова е чекорот што ја затвора јамката.
RB Link се користи главно за конфигурација. Неговиот интерфејс може да го прикаже локалниот уред или настанот за аларм, но не го прикажува статусот на известување Hub-to-ARC. Затоа, ARC треба да потврди што пристигнало на страната на прием и како било идентификувано.
Целосен тест следи една видлива секвенца:
Активирање на договорениот настан → потврдете го настанот од страната на Hub → дозволете ARC да ја идентификува сметката и настанот → побарајте од ARC да потврди што примило
Доколку ARC не види ништо, двата тима сега можат да одвојат три прашања: што се случило на локацијата, како е конфигуриран Hub-от и што гледа ARC. Додека ARC не го потврди последниот чекор, проектот знае само дека дел од патеката функционирал.
Дали на секој проект му е потребен ARC?
ARC е релевантен кога надворешна професионална организација треба да прими одбрани настани и да ги обработи според договорен процес на услуга.
Доколку проектот бара само одбрани корисници да гледаат локални настани или настани видливи во апликацијата и сами да одлучат што да прават, видливоста управувана од корисникот може да биде доволна. Правилниот избор зависи од тоа кој мора да го прими настанот, кои поддржани настани бараат надворешно ракување и каква услуга очекува клиентот по приемот.
Пред да препорачате мониторинг на ARC, утврдете:
• кој мора да ги прими избраните настани откако системот на страницата ќе ги креира;
• кои поддржани типови настани припаѓаат на услугата ARC;
• кого може да биде контактиран и кога се применува ескалација; и
• дали тие дејствија се менуваат помеѓу оперативните периоди, како што се работното време и по затворањето.
Овие одлуки ја обликуваат интеграцијата пред да започне конфигурацијата.
Што мора да биде подготвено пред конфигурација и тестирање?
Одлуките имаат природен редослед бидејќи секоја дава влезен сигнал за следната.
Настани за пријавување → Точна ARC сметка → Поставки за пријавување → Прозорец за тестирање → Потврда за ARC
Ако претходниот влезен податок е нејасен, подоцнежниот тест може да покаже активност без да докаже дека предвидената патека на проектот функционира.
Прво, дефинирајте ги поддржаните настани што се очекува да ги добие ARC. Ова им дава на двата тима опсег на тестирање. Без него, инсталатерот не може да избере репрезентативни тест настани.
Потоа, проверете дали обете страни ја гледаат истата сметка и тест настан. ARC го дава бројот на сметката и деталите за примачот, а потоа потврдува што очекува да види. Без таа споделена референца, обете страни може да видат активност, но сепак да зборуваат за различни резултати.
Потоа конфигурирајте ја патеката за известување користејќи ги тие влезни податоци специфични за проектот. Деталите од друга страница или сметка не треба да се користат повторно како претпоставки.
Конечно, закажете тест прозорец со именувано лице од двете страни. Инсталатерот ги креира договорените настани; ARC ја потврдува сметката и примениот настан. Откако ќе се докаже приемот, клиентот и ARC можат да потврдат што треба да се случи кога ќе пристигне вистински настан.
Оваа нарачка спречува вообичаен проблем со пуштањето во работа: тестирање на врската пред двете страни да знаат кои настани, сметка и луѓе се вклучени.
Зошто конзистентноста е важна на повеќе страници
Инсталатерот или дистрибутерот може да поврзе неколку продавници со истиот давател на услуги за следење. Конзистентните имиња на локации и сметки, именувањето на уреди или зони, пријавените настани и записите за тестирање ја олеснуваат подоцнежната поддршка.
Замислете дека една од десетте продавници пријавува проблем неколку месеци по предавањето. Сервисен инженер треба да може да идентификува која локација и сметка се вклучени, кои настани биле првично тестирани и кој контакт на ARC го потврдил резултатот. Без тие споделени референци, инженерот може да знае дека „е испратен аларм“, но сепак треба да ја реконструира оригиналната поставеност пред да може да започне корисна дијагноза.
Затоа, доследноста е дел од одржливоста, а не документација сама по себе.
Што докажува дека ARC патеката е пуштена во употреба?
Записот за прифаќање треба да ја направи тестираната патека репродуцирана без да открива ингеренции или оперативни тајни. Треба да идентификува:
• целниот ARC и референцата на сметката;
• користената опција за поддржано известување;
• податоците за примачот и сметката што се користат за тестот;
• поддржаните типови на настани вклучени во тестот;
• кога се одржа тестот и кој го потврди приемот во ARC; и
• кој е сопственик на следната акција или процес на ескалација.
Способност за ARC значи дека алармниот систем поддржува конфигурација за пријавување на избрани настани до компатибилна приемна поставка преку поддржана опција за известување.
ARC нарачан за проектот значи дека локацијата го генерирала предвидениот настан, Центарот ја користел договорената конфигурација за известување, а ARC потврдил прием за точната сметка и настан.
Потврдата на ARC е разликата помеѓу сознанието дека постои можност и сознанието дека патеката на проектот е тестирана од почеток до крај.
Преминете од одлуката за ARC кон планирање на интеграција
Откако ќе бидат познати целниот ARC, настаните за пријавување, деталите за сметката и примачот, контактите за тестирање и очекуваната акција, проектот може да премине во конфигурација и двострано тестирање.
Користете го упатството за планирање на интеграцијата на ARC за поцелосен работен процес на конфигурација, тестирање и предавање.
За Roombanker проценка на интеграција, донесете ја целната група, целната ARC, настаните што сакате да ги пријавите, деталите за сметката на ARC, луѓето што ќе учествуваат во тестот и што треба да направи ARC по приемот. Тоа му дава на проектот доволно информации за да премине од способност за ARC кон план за интеграција што може да се тестира.