Jump to content
Security Installer Community

Search the Community

Showing results for tags 'BS5979'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Main Public Area
    • Site News, Events, and Feedback
    • Name And Shame Area
    • Introduce Yourself
    • Product / Service News
    • Members Lounge (Public)
    • Guest Forum
    • FORUM TRADE MEMBERSHIP
    • Regulations & Standards
    • Misc Area
    • UK Security Installers by regional Police Force
    • Collectors And Vintage Security & Fire Parts
  • Global Section
    • Security Job Requests and Vacancies
    • Equipment Reviews
    • General Security & Fire Queries
    • !!..DIY Installers..!!
    • Electrics
    • Inspectorate Queries
    • UK Security Sub-Contractors
    • User Manuals
    • Security Horror Stories
    • Setting-up Business Queries
    • Trade ADT Only Engineer Forums
  • CCTV & Access Control Area
    • CCTV & Access Control
    • Trade Access Control
    • Trade CCTV Forums
  • Fire Area
    • General Fire Alarm Queries
    • Trade Fire Forum
    • Restricted Trade Fire Forum
  • Intruder Alarm Section
    • Control Panels (Public)
    • Detector Queries (Public)
    • Home / Building Automation (public)
    • Trade Only Area
  • Telecoms & I.T. Forum
    • General Telecom Queries
    • Networks
    • Computing etc
    • Mobile Devices
  • Trade Security Resources
    • Security Intruder Manufacturers
  • BSIA Commitees
    • SSS TC1
    • SSSTC
    • Regulation Drafts
  • Communal Trade`s Forums
    • Members Lounge
    • Trade Member Listings
    • Security News
    • Installers & Engineers Forum
    • Getting Approved..?
    • Rules and Regulations
    • Health & Safety
    • Basic Electronics
    • Trade Job Vacancies & Queries.
    • Equipment Wanted....
    • Engineer Manuals
    • The SWAP's Shop
  • Trade - Intruder Forums
  • Trade ACCESS & CCTV
  • Trade Fire Alarm Forums

Calendars

  • TSI Calendar

Categories

  • Applications
  • Documents
  • Documents (Trade Members Only)
  • Engineer / Installation Manuals, Training & Application
    • Access Control
    • CCTV
    • Fire
    • Intruder Alarms
    • Training
  • User Manuals
    • Access Control
    • Fire
    • Intruder Alarms
  • Sales Brochures
    • CSL Dualcom
    • Honeywell
    • Texecom
    • Web Way One

Blogs

  • Service Engineer's Blog
  • Service Engineer's Blog
  • arfur mo's Blog
  • therealmophead's Blog
  • jb-eye's Blog
  • jb-eye's Blog NICEIC making up charges for certs
  • jameswilson's Blog
  • Smoke Screen's Blog
  • Jim's Blog
  • The Messenger
  • Electronic Security & Technology
  • digitalwitness' Blog
  • Operational Security & Management
  • The Scantronic & Menvier Tat Blog

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests


Location

Found 1 result

  1.   Bigger = Better? Many barriers currently exist for businesses which are planning to run their own Alarm Receiving Centre (ARC). In the coming months we could potentially see some of those barriers crumble and a whole new way of doing business materialise.     Winners & Losers Traditionally setting up an ARC from scratch has been an expensive and time consuming process, which can rely upon expertise in the field to implement and is surrounded by very little shared information or open resources (ARCs for Dummies is not out yet). Existing ARCs face to lose out if more competition enters the fray and yet at the same time suppliers could benefit if more new business is generated.   Barriers So what exactly are the barriers to setting up a modern ARC? Building / Structure Buildings and structures must comply with specific requirements of the standards Equipment / Hardware In some cases specialist equipment may be required Communication Networks From voice communications to PSTN to IP via fibre links and all flavours in between AE Platforms Software packages used to monitor remote system Licensing / Accreditation Strict standards must be met in order to escalate calls to authorities Employees Skilled and capable staff are needed (You can automate some of this process but not all - yet Processes & Procedures You can have all of the above but without the correct procedures they will fall over Investment A large amount of money must be spent before you can earn a penny back If you think of any others please add them in a reply...     What's so 'Super' about that?... These and I am sure other points which I have likely overlooked, all make that first step of implementing an ARC a tough proposal. Given an ever improving core broadband network, with rapidly reducing prices and a growth in 4G wireless IP communication, can we now consider another approach though? ARCs usually build in a certain amount of spare capacity at any given time; this is good practice and is recommended at all times. Could some of this spare capacity be utilised to allow an ARC to operate as a 'Super ARC' by receiving and processing signals on behalf of a client ARC and relaying these processed alarms and signals back to them for handling? Why even go to another ARC? Could suppliers of alarm handling software packages not offer their own hosted 'Super ARC' platform? Maybe signalling providers could operate their own Super ARC to encourage more startups or extend reach? Why would a user choose to go to an ARC outsourcing to a Super ARC? Well, maybe they prefer the personal service offered by the smaller ARC but want the assurance of the capacity of the larger ARC. This could give rise to a stepping stone approach to bringing an ARC online, streamlining costs whilst allowing processes and procedures to be ironed out. The current standards would not lend to such a proposal, however the incoming standards allow a much less restricted approach and this type of centralised cloud based processing of signals is going to become a reality in many industries. Current latency and bandwidth restrictions will simply not exist in the same way in future.   Questions, questions... As usual we can end up with more questions than answers so I would like to ask you all to consider the following: 1. What problems would you foresee with such an approach? 2. Would you use an ARC which outsourced it's platform in this way? 3. Would you want to host services on behalf of a.n.other ARC? 4. What pros and cons do you see with this type of solution? 5. Is more ARCs a good thing or a bad thing? As always, please feel free to discuss, debate or disagree...
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.