关于报警的全部理解
许多产品经理对报警系统的认识还停留在表面,对于其工作原理、分类以及应用场景了解不深。本文将详细探讨报警系统的各个方面,帮助你全面理解报警的意义和作用。
偶尔得空,将这些年基于物联网设备和AI摄像头设计报警管理功能的思路进行了整理,形成一套业务模型,发出来供大家批判。
世界上有形形色色的事件,一些事件会对人们关注的事物产生危害,为了管理这种危害需要对事物监测报警。
报警通常包含了报警事件相关的一系列信息,以便人们处置报警,
报警逻辑就是:当监测数据满足触发条件=产生报警
2.2.1 按所需监测指标的数量,分为
2.2.2 按所需监测数据时长,分为
2.2.3 更复杂的情况是匹配行为序列触发,如垃圾乱丢报警:
为了减少因误报的发生,有几种方法:
报警后为了证明报警的真实性,指导报警处置,需要提供报警相关信息,这就是报警取证。
按报警证据的来源,分为两类:
报警触发后到报警解除前,应持续跟踪取证,按证据类型有不同的处理方式:
引发报警的危害,有些可以恢复,有些无法恢复,因此处置方式不同。
报警后,问责和消除危害,是最常见的两个处置方向,以污水排放报警为例:
处置责任单位是一个[[组织架构|组织机构]],确认报警处置责任单位的原则:
由于报警有多个处置方向,报警也可以有多个处置责任单位。
由于报警的危害程度不同,发生频次不同,所以需要对报警分级处置:
4.2.1 配置报警类型对应到专业领域、报警等级
报警类型:BBB
所属专业领域:ZZZ
报警等级:一级
触发条件:条件框架 + 监测指标 + 报警阈值(基于报警类型关联查询可用条件框架和监测指标,再基于可用设备过滤可用监测指标)
报警等级:二级
触发条件:TTT
4.2.2 配置组织机构管辖专业领域、报警等级
组织机构:KKK
管辖范围:FFF
管辖专业领域:ZZZ,管辖报警等级:一级+二级
管辖专业领域:YYY,管辖报警等级:一级
报警的处置方式多种多样,如果想要统一处置流程,只能忽略处置方式,关注责任主体:
根据报警危害的可恢复性,和人为规定的处置流程,报警的解除有自动解除和手动解除两种方式。
报警解除通常对应着消除危害这一处置方向的处置完成,而无关问责这一处置方向的处置进展。
报警自动解除同样基于监测数据,根据解除条件有两种逻辑
报警手动解除需要经过一系列人工处置流程后,手动在报警管理系统中确认报警解除。
本文由 @智慧小范 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自Unsplash,基于CC0协议。
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。