监控系统 - 21ic中国电子网

当前位置：首页 > 监控系统

万字谈监控：解答Zabbix与Prometheus选型疑难

Zabbix与Prometheus 读完本文，你将收获两者适用于多大规模的监控场景？超过5000以上监控节点时怎么办？高可用怎么解决？两者怎么解决存储问题？对于监控信息是否有历史存储和分析，能从历史信息中挖掘到哪些有价值的信息？两者怎么应对告警风暴和误报？在智能监控和自动治愈方面是否有可借鉴的实践？基于什么算法或策略？怎么进行故障预判和预处理？监控大屏是怎么设计的？自动化运维管理是两者同时使用还是二选一更合适？两者在配合使用时，应该怎么分工？怎么落地？如果已经部署了Zabbix，怎么平稳过渡到Prometheus？分布式链路的可观测性和端到端诊断怎么做？大规模场景下，两者的性能和成本哪个比较低？监控，为什么总让我们头痛监控一直都是运维工作中不可或缺的部分，一个高效、契合的监控系统是服务赖以健康稳定的基石。随着业务规模的增长、技术的发展、行业的变革，企业对用户体验越来越重视，监控的需求发生着日新月异的变化，相应的监控工具和解决方案也层出不穷。其中，Zabbix和Prometheus就是两款非常典型的监控工具，应用颇为广泛。说起来，监控在不同的团队和公司之间，可能会存在各种差异化的需求。如何基于开源产品打造一个符合自己业务场景的监控体系，并且持续迭代？这成为了大家无法绕开的课题。比如说，如何选择监控方案和开源工具？如何为自己的业务场景做定制化适配？如何实现端到端的全链路监控？如何让业务方以更低成本接入到这个系统中？如何做监控的自动化？如何做异常告警的路由、分发、收敛和抑制？如何做统一化的监控大屏、Dashboard等等……这些都是我们在构建监控系统中可能会面临的问题。围绕这些问题，dbaplus社群特别邀请到美图SRE负责人-石鹏(东方德胜)作为主持人、招商银行技术经理-蔡翔华作为Zabbix使用方、甜橙金融基础技术架构师-刘宇作为Prometheus使用方，针对Zabbix和Prometheus展开实用选型探讨。十问十答，监控工具怎么选 Q1：Zabbix和Prometheus分别适用于多大规模的监控场景？超过5000以上监控节点时怎么办？高可用怎么解决？蔡翔华：我们和Zabbix官方其实有沟通过，业内他们有一些监控到了40万以上的节点数，当然这个节点数也要根据你每个节点上监控多少东西。Zabbix其实有一个指标叫做NVPS（New Value Per Second），也就是每秒新增的值的指标，来判断你的监控规模是不是合适的。那么对于5000个节点以上的场景来说，其实Zabbix还是OK的，你可以通过多布署一些Proxy，去对后台数据库做一些性能调优等等，以这些方式去提高整个监控平台的可承受、负载的性能。另外关于高可用，我们的数据库端是会有Mycat或者HAProxy高可用，但服务器端本身它其实没有高可用，那么我们可以依赖于虚拟化平台，或者是比如像我们有Vmotion等热迁移这些技术。另外，在未来的5.x版本或者6版本以上的话，官方已经将原生的高可用纳入到Zabbix的Roadmap里面了，大家可以期待一下。石鹏：好的，蔡老师的核心观点其实就是我们需要关注核心的指标，也就是NVPS，这个值是比较关键的。然后蔡老师之前您在实际的应用中，见过这个系统的峰值可以达到多少吗？是否可以给大家做个参考？蔡翔华：在我们自己的环境里面，NVPS峰值达到过6000以上，但我们后面其实也做了一些优化，把它调整到3000左右。主要目的是，因为一开始我们做的时候是希望做到大而全，什么都监控，但最后发现其实大而全不一定有用，因为很多监控即使它是问题，你也不会care它。刘宇：是的，蔡老师已经讲得比较详细了，其实以多大的规模是取决于你的监控目标，还有就是采集的间隔，比如说5秒采集一次和1分钟采集一次，这个规模都是支持着不一样的目标，所以还是要根据你的需求。一般来说，我们会配置成30秒或者是一分钟；如果是对于高频的，会15秒。因为单个Prometheus性能已经比较强了，一般来说，它每秒百万个指标都是没什么问题的。Prometheus会根据你的指标来计算，就是看你一个监控点上有多少个指标，这样来换算。如果你单个Prometheus的性能达不到它的要求时，也可以去做一些拆分，比如说我们把Prometheus根据它的功能来做区分，这个去监控node exporter，那个去监控Redis，这样来做区分。当然，如果你单个的性能还是不够的话，可以用分区，即用hash mod去多分几个Prometheus来做监控。然后关于高可用这块，其实社区Prometheus这部分做得也不是特别好，会用两个Prometheus来同时监控同样的一个目标，这样来做到一个高可用。当然，在容器环境，你也可以去通过K8S的deployment这种方式，来把高可用维护起来。 Q2：Zabbix和Prometheus怎么解决存储问题？对于监控信息是否有历史存储和分析，能从历史信息中挖掘到哪些有价值的信息？蔡翔华：的确，存储这个问题因为监控写的东西最多就是写到存储里面去，Zabbix以前被吐槽最多的就是它不支持时序数据库TSDB。其实在4.2以后，它就已经开始支持TSDB了，当然可能还没有Prometheus那么成熟，它主要的数据库还是MySQL为主。如果就存储问题的话，一方面你可以去尝试TSDB的这种方式；另外一方面的话，你可以去通过增加SSD，或者说数据库层面的一些性能提升，去解决它的问题。包括数据库本身可以去分库分表，去拆分一下，然后对历史数据做一个归档……就是通过数据库层面的优化，来解决这个问题。那么对于历史存储和分析这些信息，Zabbix提供了两个维度，一个叫history，一个叫trend，也就是一个历史数据和趋势数据。它具体数值是可以自己设定的，它的逻辑是说，如果超过history的保留期限，比如说30天，它自动会把数据归档成trend的数据，trend的数据就会只会保留最大值、最小值和平均值这三个指标，而并不能像history数据可以看到每一秒钟，甚至说每一个轮巡周期的指标。我们实际场景应用的话，主要是用于我们的性能分析，因为我们有很多互联网应用，会看一下这个业务增长对我平台的要求，会不会CPU比较紧张、内存比较紧张等等。另外，我们会根据这些数据做一个分析，为我们后期的扩容、决策提供一些参考性的依据。比方说我现在看到今年整体的使用率在多少，我们每年的增长量是在20%还是30%，这样我们后续做一些决策的时候，是需要多少的资源、多少的预算，就比较能有参考价值。刘宇：Prometheus本身存储如果存在本地的话，大概只能存15天，最多你也只能放到30天这样子。官方其实也不建议你把所有的监控数据都存在Prometheus的一个本地的数据库里。所以我在案例分享中也提到了一个远端存储的技术（案例分享内容请关注dbaplus社群后续文章发布）。我们是存在InfluxDB的，也有一些是可以存在比如说ES，通过remote_write的功能去存到ES或者是其它时序数据库中，或者是比如说HBase这种大数据的也可以存。石鹏：好的了解，其实关于存储这个问题，我们还是更多应该从需求出发。整体来看有一些比较通用的思路，最典型的就是这两种：第一种是数据的转储。比如像Prometheus，我们在本地只存2周或者4周的数据，然后更多的话，就把它写到远端。第二种思路是做数据采样。其实在很多监控系统里面，是一个比较常规的思路，就像在Zabbix里的history、trend，开始可能是每30秒一个点，然后数据采样之后，可能是每5分钟一个点。就用这样的方式，把这个数据量级减小，然后以此来做存储问题的优化。 Q3：Zabbix和Prometheus怎么应对告警风暴和误报？蔡翔华：首先误报这个事情，其实在我理解里是不存在的。也就是说，之所以我们会觉得很多有误报的东西存在，是因为我们对于规则，比方说我监控东西或者是我配置触发器，本身是有问题的。我碰到很多人说，打算监控它的CPU使用率，很多人会直接记录usage，它的使用率，也有很多人会监控它的free的这个space。但有时候会由于配置错误，导致原本监控cpu usage的使用了cpu free的指标。所以说，其实很多时候报警之所以会产生误报，是因为配置本身不是很正确。 Zabbix的工作机制很简单：我去收集数据，去根据这个处罚规则去做比较，然后去发报警。当中所有的逻辑其实本身是不会出任何问题，除非说收集数据配错了、触发规则配错了、报警机制配错了……这些其实更多是人为的因素在里面。所以说，更多的是要通过这种检查来判断一下你是否有配错。另外一个减少误报的方式是通过模板化。因为我们只要配置一次模板，那我把所有的Linux机型的监控模板都统一起来，对于所有监控Linux都套用同一个模板，那么就可以在一定程度上降低误报。关键还是在于人的问题。关于告警风暴，其实Zabbix里有一个特性叫做依赖项目。就比方说我现在有一台机器宕机，那么它可能里面的端口都会不通，然后ping也ping不通，CPU可能也拿不到，可能会有一堆的报警。那么我们可以把所有的这种依赖项关联到ping上，一旦ping的机器都死了，上面肯定东西都是宕掉了，这样子的话，它只会报ping的这一个问题，而不会把这堆机器上所有的东西都给报出来。就好比一个人如果死了，你跟他说这里有问题那里有问题，其实没有任何意义。它就只会把你最终的Root Cause（根因）给报出来，去防范这种告警风暴。刘宇：是的，误报我其实跟蔡老师的观点是很像的，就是告警中其实是存在一个误报率的，如果你的误报率很高的话，运维人员就很疲劳了，可能大家都会觉得狼来了，没有办法信任你的那种告警，反而你真正发生故障的告警就会被忽略掉。所以制定告警的规则就非常重要，需要想办法把误报率给它降低。那这种规则的制定其实就比较不是那么具体，会比较抽象，可能比如说把必须要人工介入处理的这种，才把它定为告警；然后如果系统可以自己处理掉，就不要把它告出来，或者只是在后面做一个每天发一次的报告也就行了。这是我对误报的一个看法。关于告警风暴，在Prometheus中，对告警风暴的处理方式是这样：可以通过静默告警解决，或者是可以加入维护组，或者是也可以做一个聚合，也就是把告警给聚集，然后同类的告警合并，这样来减少告警的条数，主要是这样来做的。当然如果你有些机器需要维护，它也是可以支持的，就是可以把一些告警直接静默掉。当然还有就是测试环境，比如说这种告警，你就可以完全忽略掉，我觉得可以这样来解决。石鹏：好的，我总结一下，关于误报这个问题，两位老师的意见是比较一致的，我也是比较赞同的。误报其实最根本的原因就是可能你的使用不合理，不管是你的配置还是说你的各种姿势可能不合理，才会导致误报。然后针对告警风暴，其实Zabbix和Prometheus也就是alert manager，它们都有提供一些相应的功能、特性。在Zabbix这边的话，可以像蔡老师说的用依赖项，然后也是可以加维护，也可以规避一些告警；然后Prometheus这边是alert manager它里面有silent这个静默规则，也是可以去做一些规避告警这种东西。可能在很多公司，他们除了监控平台本身去做告警风暴的抑制，还会有另外一层。比如说我们公司这边是这样：我们有一个告警平台，所有的告警都会汇集到这个告警平台里，然后这个告警平台会去做一层合并、收敛和抑制。这样的话，就可以不用特别依赖监控平台本身来提供这些特性，而是由一个统一的平台，在做最后发送动作的时候，再来做一层cover。可能在量级大的场景下，这种是比较推荐的一种思路。蔡翔华：是的，因为真正的监控当中，其实还会纳入很多比方说ES等其它监控平台，甚至是一些业务告警。当平台很多的时候，其实你需要有一层聚合的方式，去把告警做一个聚合收敛，然后通过在聚合平台里配置一定规则之后，再去做后续的一些报警。石鹏：没错，并且你有这个平台之后，就可以把一些告警的规则和策略做得更统一，这样的话，给用户的界面和体验也会更好。蔡翔华：对，所以说其实看公司规模，因为这一块会涉及到一些二次开发，如果公司没有这个能力，那就可以把Zabbix全套或Prometheus全套都用上；如果后续有能力去做这种聚合的话，其实Zabbix也好，Prometheus也好，更多的角色定位会变成一个收集器的角色。然后后面的逻辑其实都交给事件管理平台或聚合平台去做。刘宇：没错，这里Zabbix其实也可以把它的报警发送到alert manager里，也可以做一些静默处理，因为Zabbix本身它的静默功能确实不是特别多，还是alert manager会做的更好一点。所以两个工具其实可以结合起来使用。 Q4：在智能监控和自动治愈方面是否有可借鉴的实践？基于什么算法或策略？怎么进行故障预判和预处理？蔡翔华：首先我们是有尝试过智能监控，但是包括我看到的很多书籍里面，包括Prometheus的一些书籍里面，也说设这种固定的预知是一个很蠢的方法。根据我这边实际的应用，其实你要做到智能监控，肯定要有一些大数据的东西，比方说我有这种规律：例如，按照我们的实际操作里有很多互联网的应用，有些东西它就是会有高并发高抢购，可能每个月固定的时候，比如每个月10号放一个活动，活动时它的量是平时的10倍甚至100倍；但也可能有时候，业务会不停地在不同的时间放，你很难去判断这个点到底是不是一个故障点。也就是说，你用户数从10变成了1万，这1万到底是因为故障了，还是说是因为业务的一些逻辑导致的，很难判断。所以目前来说，我们尝试以后，还是用了一些比较固定的报警预知去做。那么回到这个话题，Zabbix本身它提供了一些预测的功能，它会预测现在我的磁盘消耗大约什么时候会消耗到20%以下，或某个阈值以下，它本身是提供了这个功能的。还有一些内置函数可以去做这个计算。但是目前来说，我个人还是建议使用一个比较固定的阈值，可以方便我们有一个明确判断，否则你早期会有很多的误报，甚至可能你都会觉得这东西很正常。预测的数据也是基于现状的，如果可以对预测数据进行判断报警，理论上，也可以针对现有的数据进行判断报警。刘宇：这块我们实践的案例倒不是特别多，我主要还是对数据库的监控比较熟，所以就说一下我们在数据库的自动治愈上是怎么实现的吧。比如说告警，它发送出来的同时，也会发送给数据库的一个自动化平台，这个平台会有一个程序根据告警内容来调一些自动治愈的程序来处理这种简单的故障。但这个其实做的也比较有限，就是说我的这种能够自愈的程序，都是根据具体场景的，并不是所有的东西都可以做。比如说清理日志、杀读库大查询，以及需要加一些表空间这些场景，类似这种比较固定的会采用自愈来做，其他的尝试倒不是太多。石鹏：嗯嗯，这个问题其实比较前沿，并且涉猎的范围是比较广的。像自动治愈，其实Zabbix也有一些相关的功能，它可以去配置action，当发现告警，有问题，我就可以绑定脚本去做一下处理。但这个东西要做到什么程度，或者说要用什么技术来打造这个底座，可能都会有些差别。蔡翔华：是的，因为我觉得Prometheus和Zabbix或者说其他平台，都支持调action、调脚本去做一些重启，但是我觉得关键问题的点是在于你敢不敢做这个事情。因为我们知道我们的环境其实是很复杂的。比方说，我发觉数据库宕了，服务停了，我敢不敢通过这个服务自己切过去。因为很多时候并不是数据库本身的问题，是网络的问题，网络抖动了，监控数据拿不到了。这个是非常依赖于整个整体环境的，你可能要想到方方面面，这个规则会非常复杂。你可能在做服务自愈的时候，还要去对其他的东西做一个完全的检查，确保其他东西是没有问题的。所以不说服务自愈，哪怕在我们日常的故障处理当中，也很依赖于经验。就是说这个东西是能做的，但是我们不太敢，因为要考虑的要素很多，就不太敢去直接做自愈这一块。石鹏：没错，本身其实它是一个体系化的工程，不仅仅是跟监控相关。我这边的一个想法是这样，关于自动治愈这块，我们可能还是要更多去依靠业务侧的能力。就是说，业务侧要具备一些这种架构设计上的考量，比如说架构的柔性，可以自己去做限流、降级、做熔断，这要求业务侧有这样的能力才可以，而不是说仅仅依靠监控系统去做某些动作触发。至于说一些算法和策略的话，之前美图这边也是有过一些简单的尝试，应用不算非常广泛。但业界的话，DataOps、AIOps的概念也是比较火热，这些东西在像BAT这些公司其实也有一些实际的应用已经在落地了。之前我们做的话，有做这么几个小东西，关于故障预测是有这么几个算法：有同期的数据比较、同期的振幅比较、有一个移动平均算法、然后再有一个变点监测。然后这几个的话，可以简单说一下思路，其实也比较好理解。同期数据，是我按照周期，比如说今天某个时间点这个数据，我去比较昨天这个点是什么样子的，去比较数据；振幅，其实它就相对更柔性一点，里面会给你加上一个权重，加上一个比例，比如正态分布里边的3-sigma，作为振幅系数去比较同期的数据，看在算上振幅之后，你是不是已经超出了，去做一个预测；变点监测，就是说我整体的数据曲线是什么样子的，突然出现了一个离我正常预测曲线偏离非常远的一个点，这种的话会有一个这样的算法来做这个事情。然后这块相对比较成熟的工具的话，像腾讯之前有开源的运维学件METIS，它里面集成了非常多的算法模型，这个有兴趣的同学可以去做一些了解。 Q5：监控大屏是怎么设计的？蔡翔华：首先从技术本身来说，5.0版本可以看到Zabbix的UI都很不错，可以很多的组、主机都往大屏里面去拖。大屏的话，我们大概会分几块：第一块是整个系统运行状态。我可能整个系统有从用户登录到用户支付，包括到购物车等等，有一个链路。我对于每个链路其实都会有一个监控，它每一个S组 Service的组，那么Service的组里面包括它的应用、数据库缓存、应用系统甚至硬件服务器，一旦这里有任何东西出问题之后，直接会在大屏上显示一个警告，那么我就会知道现在整个生产环节哪个系统是有问题的。那么另外就是一个summary，一个overview的全局的导览，因为一旦我知道这个有问题，我就希望更加细化知道这个东西哪里有问题。那么在下面就会有一个trigger list的问题列表，就是说有哪些触发器被触发了，我会看到比方说，数据库端口不通了，还是说磁盘空间已经满了。下面会有trigger list，然后这个trigger list会按照故障等级是disaster还是warning，同时对应的管理员或者运维人员也会收到这个短信，就知道要立即去处理了。所以我们尽可能就在大屏里从两方面来把控，一方面从大的来讲，有一个over view看到全局，从小的来讲，我要知道我的故障发生在哪里。基本上保证这两个要素在大屏里面就OK了。刘宇：我们这边大屏其实主要还是应用的维度以及网络流量的维度为主。比如说从公网的一个出口和入口的流量来看会不会有大面积的一个问题。如果发现已经达到外面防火墙或者它流量的一个阈值了，就可以迅速定位问题。如果是细节的话，我们会在大型活动前夕，梳理活动链路上的所有应用，根据应用的维度来设计这样一个大屏。大屏可以看到链路上所有应用、数据库或者是中间件的情况，一旦哪个应用的QPS高了，或者是其他压力的情况，就可以第一时间定位到问题出现在哪里，是这样一个思路来做。石鹏：监控大屏做得好，确实可以辅助我们技术同学去更快地定位和排查问题，还有一个比较重要的点，我是这么想的，就是老板会关注。有些公司会把大屏设计得非常有科技感，让老板看的话，可能老板也觉得我的技术团队还挺牛的。当然这是一个题外话。前面蔡老师和刘老师都给了一些建设上的思路，就是你应该去包含哪些数据，应该怎么去做。这方面的话，我的一个思考是你可能要去做服务的梳理，然后可以以分块、分业务或者说按照分层的方式来做。分块的话，就是你按照业务线来分。你公司可能有很多块业务，然后按照不同的业务去提供一个视角。在每个业务里，你可以去做分层，分层的意思就是说可以把整个链路，从客户端一直到CDN、 DNS链路，然后到LB入口层，以及应用这一层是什么样的，再关联到后面的一些后端资源，像数据库、缓存这些东西，还有一些其他的周边依赖，按照这样分层的方式来做。具体实践的话，可以跟大家做个预告，最近我们美图有一些实践经验可以分享，近期会把一些完整的设计思路和细节放出来，大家可以期待一下，持续关注dbaplus社群的发文。关于技术实现方面，我简单赘述两句。我们公司的监控大屏是用了Grafana来做的，Grafana可能已经成为了事实上的监控UI、数据可视化的标准了，它可以后面去接各种各样的数据源，然后你各个监控系统、各种数据原理的数据可以统一来展示。这里需要感谢一个社区的插件，叫Flow Charting，这个插件可以非常好地去做监控链路的事情，就是你可以用这个插件去把整个链路关键环节，以这种图的方式绘制出来，然后给每一个点、每一条线绑定上监控数据，最后生成的图就动起来了，就可以看到一个全局性的链路状态：从入口一直到后端资源，包括各种依赖，当前它的状态是什么样子的。当然这个前提是，你整个链路的监控数据是要完备的，然后你才可以借助这个插件去把它呈现出来，大概是这个样子的，在这个图上就一目了然了。 Q6：自动化运维管理是Zabbix和Prometheus同时使用还是二选一更合适？蔡翔华：如果是个纯容器化的，就说你环境里面全是Docker，那么说实话我也不推荐你去使用Zabbix。因为Zabbix对容器的监控，虽然官方已经开始重视了，甚至说现在也支持了Prometheus的很多metrics和exporter这种方式去做监控，就是它也可以原生的去支持Prometheus这些东西，但相对来说，Prometheus在容器化监控这边还是会更好一些。如果你的监控需求是又要监控硬件服务器，又要监控中间件，又要监控业务指标，那么我推荐使用Zabbix，因为Zabbix覆盖的面会更广一些。的确我觉得任何需求Zabbix和Prometheus都可以去做，但是从实现成本来说，相对于Prometheus，你的服务环境越复杂，Zabbix可能就越适合这种比较复杂的异构的环境。刘宇：我们目前公司情况是两个都在用，的确是偏容器的会往Prometheus优先考虑，如果是旧的，比如说是有偏服务化的这种监控，也会慢慢地往Prometheus做一些迁移。如果你的环境是一种就可以满足的话，建议还是一种，因为毕竟只需要维护一种技术栈就可以了。或者是你可以做一些偏重，比如说把一些不变的放在一种上面，经常会变的放在另外一种上面。尽量去减少你维护的技术栈。如果你的环境比较简单的话，只用一种，当然是最好了。石鹏：其实还是看场景，美图跟刘老师这边比较类似，我们也是多种监控工具在用，不过我们现在没有在用Zabbix，是用了Open-Falcon、Prometheus、InfluxDB，还有很多基于大数据的一些流式处理的组件，我们都是混合在用。主要还是看你具体的需求和场景，没有银弹，没有说一个工具可以非常合适去搞定所有事情。当然它有可能有能力，但是它并不一定特别合适。至于具体的选择上，还是要看具体场景。比较明确的一个思路可能就是要看你的监控对象到底是容器还是非容器，它是这种易变的还是比较稳定态的。这两个思路的话，也是跟蔡老师和刘老师比较一致的。 Q7：Zabbix和Prometheus在配合使用时，应该怎么分工？怎么落地？蔡翔华：其实从场景来说，Prometheus更适合容器。你可以看一下整个环境里，容器和Zabbix的占比，像刚才刘老师说的，这两者数据其实是可以互相使用、互相监控甚至是互相触发报警，那么在Zabbix现在其实已经原生支持了Prometheus的这些exporter的功能，即使你没有Prometheus后端，Zabbix也可以直接去exporter上拿一些数据，通过Zabbix的一些逻辑和机制去报警。那么相同的，Zabbix也可以通过action把这些数据扔给Prometheus。也就是说，你可以把它们两者当中的一个作为数据的采集器，另外一个作为整个数据的逻辑处理的功能，类似于alert manager或者是在zabbix server一样，这样做的好处就是说，收集数据会非常方便，比方说Prometheus不能收集硬件数据，但Zabbix可以收集，我们就用Zabbix收集，同时把它的数据扔给Prometheus，做一个统一的报警。这样的确还是要维护两个平台，但是相对来说，维护成本会有所降低，不需要对Zabbix那边做太多的模板，它其实只是一个数据采集器。那么稳定性、可用性、性能及监控这些东西，其实也基本上可以基于Prometheus现成的这些规则、Zabbix现成的这些模板来做。其实Zabbix社区里面也有很多模板可以提供到。关键我觉得有一点就是，我们要思考它模板里面提供的东西，是否是我真的需要的，因为很多时候大家觉得我啥都要监控，但事实上不是这样子，只有真正需要关注的点，才是需要监控的东西。所以说大家在部署监控之前，要先思考一下监控的目的是什么。刘宇：我的看法其实还是这样，比如说偏基础的，像主机、网络这种可以用Zabbix来监控，偏服务类的和容器的，就用Prometheus来做监控。我们监控Redis的一个集群，在以前没有Grafana或者Prometheus的情况下，用Zabbix去看集群的整体情况就会比较麻烦，因为Zabbix依赖的监控的一个点还是以host为基础的，所以你去看整个服务的话会比较麻烦。而Prometheus因为它是时序的数据，可以方便地去打一些你想要的标签，这样就可以比较方便地监控单个服务上一个整体的情况，所以服务这块来说，还是Prometheus比较方便。而前面其他蔡老师也说了，比如说硬件这种还是Zabbix比较好用。石鹏：OK，这个点上我们理解还是非常一致的。像现在美图这边，就单讲Prometheus和Open-Falcon，我们基础的这些监控都是在Open-Falcon里，然后容器会在Prometheus里。这里需要补充一下我们的环境，现在我们所有业务都是基于云上来做的，业务容器化程度的话，应该是只有个别服务没有容器化，整个比例应该95%以上都是容器化的。但即使是这样，我们也没有完全摒弃掉Open-Falcon。我们在这个容器里，容器层的这些服务，像servive、pod这些监控，比如说业务上暴露出来的metrics，这些东西我们都是用Prometheus来做的。但是像k8s node节点、ECS，它本身的一些监控，包括一些网络质量的监控，还是要有一个更适合做这种基础监控的平台来做。我们就是在Open-Falcon里做的。所以主要还是看场景，怎么去侧重就是看你具体的需求了。 Q8：如果已经部署了Zabbix，怎么平稳过渡到Prometheus？蔡翔华：如果已经部署了Zabbix，我估计你直接通过数据库去导入这种方式会很难做，因为它的表结构，包括一个是时序数据库，一个是TSDB，就没办法直接做。我建议如果真的要过渡到Prometheus的话，可以仍然使用Zabbix agent，在数据采样完之后，把它扔到Prometheus，触发一些action去提供给Prometheus。这是一种中转方式。另外一种方式，我会通过一些ansible去部署一些Prometheus expoter到那些机器上去，把这些数据扔给Prometheus。其实也就回到刚才那个问题，我这边所有的数据都可以扔给Prometheus使用，去触发报警，这都OK的。刘宇：如果真的要把Zabbix迁移到Prometheus，就是涉及到一个监控迁移的过程。我这边的建议还是按照Zabbix先模块划分，比如说其中一个模块准备迁到Prometheus，然后首先会把这个模块Prometheus的监控也加上，会把两边的监控进行一个比较，至少Prometheus能把原来Zabbix的监控都能覆盖掉，不仅是监控的覆盖，还有告警覆盖，这样一个并行的过程。最终完全能够达到一样的效果，我就可以把原来Zabbix相关模块的监控给下掉，是这样一个建议的路径。蔡翔华：对，而且其实Prometheus和Zabbix同时存在并不冲突，并不是说两者只能选其一。其实可以说，我先把Prometheus的exporter规则都配上去，两边同时监控，然后再根据需求，把Zabbix给下了，也OK，这是不存在冲突的。石鹏：没错，既然你要平滑，那两边同时有，这应该是最平滑的。我们之前是有从Zabbix迁到了Open-Falcon，迁移经过了一个比较长的耗时，大概用了一年多的时间。其实就是你把另一边的监控也布起来，同时监控，然后逐步去下旧监控。在这个过程里，你还可以去比较两者之间是不是有差异，是不是都能满足需求，这样的话应该是比较平滑的。 Q9：分布式链路的可观测性和端到端诊断怎么做？蔡翔华：分布式链路其实我们没有用Zabbix，因为分布式链路要考虑上下游的关系，所以我们会基于APM去做。现在像业内比较流行的CAT，可以参考这些去做。端到端的侦测的话，其实Zabbix也支持，它支持两种方式：一个是它可以在本地跑一些脚本去做，就是说我这个检测是从Zabbix某个Agen端出发，到另外一台目标机器，而不是通过Zabbix server去做检测。所以说这是Zabbix 提供的另外一种方式，Zabbix active的一种方式，它可以去实现这种端到端的侦测。Zabbix active的监控方式也是比较好的一种方式，可以减轻Zabbix server端的压力，或proxy端的压力，能提供更丰富的一些监控。刘宇：这块因为Prometheus是一个基于数值的监控，对于这种全链路的话，一般不太会用Prometheus来做，基本上会用APM的一些分布式链路追踪的工具，比如skywalking等来做。还会通过一些日志系统来做分布式的监控，在链路上，提前写入一些标签，这样从始至终都可以拿到整个链路上的一个关系，就可以做一些分布式链路上的监控的东西。石鹏：是的，这也就回到我们前面讨论的，没有银弹，没有一种技术栈可以解决所有需求的。包括Zabbix和Prometheus，其实更关注的还是在偏服务端，如果是应用端的话，其实还是要依赖一些APM的工具。就像刘老师说的Apache的skywalking，还有像鹰眼、基于open tracing的其他工具。这些东西其实都是一种思路。还有一些有技术能力的公司，会选择自研一些APM工具，需要自己去开发各种SDK，然后需要迁到客户端，去上报数据，是这个样子的。其实端到端整体的建设思路应该是分段的，客户端的是一段，中间链路是一段，服务端又是另外一侧。所以想做端到端，很难说用一个工具就可以完全覆盖起来。现在基于云原生、微服务这些发展的比较火热，可能会有一些各个服务之间调用链路的服务治理相关的监控需求，可能也不是说通过Prometheus或Zabbix就可以很好地去完成。还是要看需求场景，选择更合适的工具，并且组合起来使用。 Q10：大规模场景下，Prometheus和Zabbix的性能和成本哪个比较低？蔡翔华：首先我觉得还是看应用场景，因为大规模场景下，要看这个场景是容器多还是非容器环境多，这是一个主要依据。 Zabbix性能的话，其实瓶颈主要是在数据库，只要把数据库的优化做得足够好，其实开头也说了，业内也有做到40万NVPS的这种案例，已经是比较变态了。那无非就是说，去做数据库分区分库拆表、加SSD存储，通过这种方式。成本的话，我个人觉得在底层资源满足的前提下，成本应该都OK。因为Prometheus是基于exporter，Zabbix是基于Agent，通过Zabbix agent，配合自动发现和低级别发现的这种方式去实现自动化。配置成本可能Zabbix会低很多，因为都是基于UI去做，而Prometheus是基于配置文件去做，这个可能Zabbix会更好些。所以我综合成本，觉得Zabbix稍微会好一些，但还是取决于你的场景里有多少虚拟化。刘宇：我觉得如果是性能的话，通过一些分区的手段都能解决。但如果是非常大的规模，通过Zabbix，其实它的数据库瓶颈还是比较严重的，这块还是需要一些比较好优化手段才能解决。监控采集的agent的方式而言，我觉得Prometheus的exporter做得非常全面，像我们以前用Zabbix，基本上有很多东西监控都是自己去开发的；而现在用Prometheus，基本上对于这种采集器的开发都没有了，用社区的就可以全部解决了。所以在采集的层面上，去实现它最底层和服务的一个数据采集，我感觉Prometheus的成本会更低一点。当然因为Prometheus相对来说还是一个微服务的架构，它的所有组件都是分开的，在搭建成本、学习成本会稍微高一点。石鹏：其实还是要针对个性化的场景去做一些选择。成本的话，如果说你的环境是一个比较纯粹的，要么是全容器，要么是虚拟化或者物理环境，你就选一种就好了。如果说你是异构的话，可能就不可避免的要选两种同时维护。这两种里如果有所侧重的话，成本其实就会有所侧重，所以还是看你的具体需求。选型，在于抓住监控的核心对于大家比较关注的监控工具选型，用一句话来概括就是：没有最好的，只有最适合的，要具体场景具体分析。总的来讲，如果是比较纯粹的环境，比如是纯物理机、纯虚拟机，更关注一些偏基础设施层面的需求的话，Zabbix会是一个非常不错的选项；如果是容器化场景，Prometheus的适应性会更好；如果是异构的话，建议两者或更多其它工具结合起来使用。纵观整个监控发展史，其实监控方案一直是跟随着行业技术、业务发展不断变化的。到现在，比较火热的技术像5G互联、物联网、人工智能……各种技术层出不穷，我们需要去监控的目标对象也一直发生着变化。随着多云、混合云架构在更多行业里持续落地开花，容器、云原生等各种技术的蓬勃发展，对监控系统其实也提出了新的需求。技术更新迭代速度越来越快，很多同学难免会有一些焦虑的情绪。这种焦虑是不可避免的，我们应该做的还是要去抓住事物的本质。针对监控这个需求，也就是说监控的核心是什么？监控在高度抽象之后，无非可以这么来分：监控数据的暴露、数据的采集和传输、监控数据的存储和处理……这个过程里，包括各种优化、各种格式化处理等；最后是我们怎么去用好监控数据，把监控数据的价值最大化，比如说我们去做报表展示、做数据分析，像前面讲到的用一些DataOps、AIOps的算法、能力介入，把监控数据的价值挖掘出来。这其实就是监控系统所要承载的功能，我们要做的就是抓住这些核心路径里的原理，然后掌握它，其实也就OK了。另外，我们需要保持对这些新鲜事物的热忱，保持对技术的敏锐，要有行业发展趋势的感知能力。比如企业上云，其实从行业报告来看，从去年就已经过了上云的拐点，会有越来越多公司选择把服务迁移到云上；再看容器和云原生，会有越来越多的周边生态完善起来。我们要有这样的感知能力，要能够感受到这个行业发展的脉搏，然后做好相应的技术储备，只有这样，我们才可能在技术的浪潮里做到从容不迫，才能够乘风破浪。特别推荐一个分享架构+算法的优质内容，还没关注的小伙伴，可以长按关注一下：长按订阅更多精彩▼如有收获，点个在看，诚挚感谢免责声明：本文内容由21ic获得授权后发布，版权归原作者所有，本平台仅提供信息存储服务。文章仅代表作者个人观点，不代表本平台立场，如有问题，请联系我们，谢谢！

时间：2020-09-30 关键词：网络监控系统
安防平台的建设就是在打造一个智能化系统

本文来源：中国安防协会现如今，传统的视频监控已经无法满足日益增长的业务需求，在AI、云计算、大数据分析等技术的驱动下，智能安防产业变得越来越开放，单一视频监控已经不能够满足多元化的安防业务需求，而多业务融合的安防实战平台越来越被各地政府机关所看重，在智慧城市建设、雪亮工程、刑侦案情管理等公共社会安全领域展现出极大的市场应用价值。安防平台的建设就是在打造一个智能化系统，系统中各模块之间紧密合作，主系统对不同子系统之间集中管控，各系统之间在平台中实现资源共享和信息交互，按照既定行业的功能特点形成具有行业特点的智能化管理平台。安防监控系统的重要组成部分是采集、传输、存储、显示和控制，而安防管理平台就是控制的核心部分。安防平台拥有超大的安防业务处理性能，因为是控制的核心组成部分，所以前端摄像机之间需要通过平台来实现多点位融合联动处理机制，包括与其他平台、手机APP之间的对接等。以人脸识别技术为主的智能前端在小范围的社区、街道有着不可比拟的优越性，其集成了视频监控采集、深度人脸识别算法、智能人脸分析及行为分析等众多功能于一身，在小范围组网方案的应用中部署快捷、系统简单，深受社区、门头经销商的热捧。但对于诸如平安城市建设这种大型领域来说，智能前端的应用仅仅只能解决部分监控场景的需求。而放眼整个城市安防综合管理，这种独立工作的模式却不利于智慧城市安防的体系化建设，管理起来相当复杂。由此可见，智能前端的应用是片面的。随着社区街道标准化建设的不断深入，这种安防监控模式势必会被集成化程度高的模式所替代，但短时间内此类小集成解决方案还是占据绝大多数市场的。从长远来看，打造智能一体化安防平台是很有必要的，智能安防平台有助于把控城市全局领域，对城市一体化管理建设有着重要影响。换句话说，智能一体化安防平台能够利用现有各零散布控点位将它们集中起来统一管理，以布控、抓拍、存储的传统监控模式为主导，通过平台大数据分析、智能化管理、多业务融合等解决手段，提供真正的城市安防综合管理一体化服务。 1.在智慧城市领域中的应用依靠传统的视频监控仍然需要耗费大量的警务人力对警情发生情况进行人员筛查以及案情回放查看，而基于人脸识别技术的人脸安防实战平台可以针对突发事件进行精准的事后溯源，在绝大多数情况下还能够针对危险警情进行事前干预、事中取*等，例如在城市布控中，针对在逃嫌疑犯，人脸安防实战平台可通过前端人脸摄像机进行大范围街道布控，并可将街道抓拍的人脸图片与在逃人员人脸图片库进行比对识别，从而在社区街道提供精准化的布控应用。 2.在交通领域中的应用视频结构化平台能够提供人车属性识别，通过智能视频结构化相机获取前端抓拍图片，前端通过对过往的人、车等进行抓拍，并依托精准的视频结构化属性分析，将前端抓拍的图片数据不断传送至后端平台进行大数据信息融合处理，平台通过对各类人车属性的数据进行分析，为人群、车辆的管控策略提供数据支撑。 3.在社区维稳中的应用人脸实战平台通过对人脸大数据的分析，将前端抓拍的图片对频繁滞留在某一区域的人员进行频次报警，从而减少进入社区嫌疑人员蹲点的风险，并且在确认该嫌疑人员后，社区管理人员可将该嫌疑人员的人脸抓拍图片上传至嫌疑人员布控图片底库，当嫌疑人员再次进入社区时便会自动触发平台报警，从根本上提升社区布控的精准度。 4.在金融领域中的应用在金融领域领域，安防平台还能够实现多项金融业务的融合处理。随着金融行业的发展，各大银行机构针对重要客户的关系维系越发积极，银行之间不断抢占市场争取更多的金融客户，人脸实战平台可以帮助银行管理者维系客户关系，对重要客户的到访可以记录下来并提前周知银行管理者，生成报表数据，结合大客户交易情况的分析，可以给银行管理者提供重要的决策依据，根据产生的报表数据调整其内部运营策略，从而达到增长业绩的目的。由此可见，除了安防的防护特点，现阶段智能安防平台不断迸发出新的活力，本质上还是以视频监控为主要方式，但监控数据已不仅仅是防范安全隐患的用途，而是利用更多的信息去创造再生的财富，从而实现可持续发展的重要理念。现阶段，安防平台的应用绝大多数都是围绕人或者车开展业务，很多安防厂商在推进自己品牌的智能解决方案时，都会看重软件平台与其智能硬件的结合，未来的安防市场应更注重的是如何提升前端监控效果以及大数据计算技术。安防行业的发展态势取决于国家政策的引导以及社会市场需求，安防平台的发展主要看各行业对以视频监控为基本方式的多业务融合需求。安防平台是一个开元化、多功能的平台，其本质是视频监控，但处理的业务已经涉及各行各业。智能化安防平台正以其丰富多样的扩展性业务逐渐被市场所接受，安防平台将会在智慧城市建设中扮演着越来越重要的角色。 ~END~ 免责声明：本文内容由21ic获得授权后发布，版权归原作者所有，本平台仅提供信息存储服务。文章仅代表作者个人观点，不代表本平台立场，如有问题，请联系我们，谢谢！

时间：2020-09-28 关键词： AI 监控系统
智能车载监控系统解决方案

智能车载监控系统解决方案为应对和防范公共安全，全球各地的组织都在增加经费以加强安全装备或增加新的安全防范设备。考虑到这一点，新汉扩展VTC系列，推出 VTC 6200 car PC专用机，专注于智能车载监控系统的解决方案。增加PCI-104 槽作为视频捕捉卡或SUMIT PoE接口设备应用。 VTC 6200 car PC采用Intel Pineview D 处理器，支持双核技术，有着功能强大的视频处理性能，并支持-30到60 度的宽温，坚固耐用和无风扇的设计使VTC 6200 car PC可以放心长久的使用在严苛的室内或户外环境，无须象普通设备一样时常维护。

时间：2020-09-10 关键词：智能车载监控系统
由亚运看体育场馆监控系统发展

　　网络化　　早期的远程监控系统均带有明显的本地化特征，即使采用的是数字化监控设备，所构成的系统仍然缺乏全网集中性，用户需要分别登录这些设备，才能完成图像的浏览与控制。而网络化监控系统则是通过设立一个统一的中心监控平台对系统内所有视频编码器及DVR等设备进行集中管理与控制，平台与这些设备之间通过数据网络互联，用户仅需登陆平台，即可完成全网中各个监控点的控制和图像的浏览与调用。　　数字化　　随着数字信号处理技术的不断进步和各类高效编解码算法的出现，目前已经可以实现低带宽下的高清视音频应用，编码后的信号与診-始信号的差距基本上可以忽略。由于监控联网系统采用何种技术将会直接影响接下来的实施效果和后期的应用扩展，故而采用数字化技术是必然趋势。　　智能化　　单纯的数字化、网络化视频监控技术仅仅解决了传输与控制的问题，而对于大型体育场馆监控联网系统，要实现真正的应用整合还必须依赖智能化的监控系统技术。智能化的监控系统以网络化传输、数字化处理为基础，以各类功能与应用的整合与集成为核心，实现单纯的图像监控向报警联动、GIS、GPS、流媒体、图像识别以及移动侦测等应用领域的广泛拓展与延伸。　　高清化　　由于专业监视器必须能够不间断工作，相对于普通电视机、电脑显示器来说具有更高的要求。液晶是目前公认的最适合应用于安防领域作为专业监视终端的产品，其使用寿命在一般情况下可达到5万小时以上，分辨率可以轻易达到标准高清以上甚至达到1920(H)× 1080(V)的全高清等级，功率与发热量也相对较小。

时间：2020-09-09 关键词：亚运监控系统
基于MCGS的电动汽车充电站监控系统设计

　　1 引言　　电动汽车由于燃料的可再生性、清洁性，逐渐成为国家在新能源汽车产业大力发展的对象，而电动汽车充电站是电动汽车大规模产业化后必须建设的基础设施。本文首先介绍了基于专用停车场的充电站监控系统的结构设计，根据国家标准设计监控系统实现的功能，最后介绍基于mcgs技术的充电站监控系统的实现。　　2 充电站监控系统结构设计　　参照国家电网公司电动汽车充电设施指导意见[7][8]、电动汽车充电设施典型设计[9]、电力监控系统的技术实现路线及发展趋势，充电站监控系统采用c/s和b/s相结合的方式进行设计，如图1所示　　　　图1 充电站监控系统结构图　　整个监控系统采用工业以太网连接，充电机、bms(电池管理系统)和智能电表由通讯控制器经协议转换后接入以太网并与上位机进行通讯，配电监控系统同样由以太网与监控系统通信，这些部分采用c/s结构;上级监控系统通过以太网与本地监控系统通信，该部分采用b/s结构;服务器负责存储充电站内的各种数据信息，gps时钟提供本地时钟校准功能。监控系统能通过工业以太网实现各种类型充电机的接入，对充电机和电池管理系统进行监控。此外，本地监控系统可以通过以太网与多个上级监控系统进行通信，实现分级和远程监控。这种结构使系统具备较强的可伸缩性，可以满足充电设施规模不断扩容的要求。　

时间：2020-09-09 关键词：充电站电动汽车 mcgs 监控系统
NiosII+GPS/GSM实现汽车状态监控系统

　　引言: 　　基于SoPC的汽车安全监控系统采用Altera公司最新的SoPC(可编程片上系统)解决方案——Nios处理器软核为核心，配合GPS和GSM系统，对汽车的停放和运行状态进行监控。　　基于SoPC的汽车安全监控系统可广泛应用于汽车的防盗、日常维护和交通事故的处理，为车辆故障提供有效的测试手段。　　1 系统硬件组成　　设计采用Altera公司的SoPC开发工具。系统的开发包括硬件和软件两大部分。使用SoPC Builder生成Nios嵌入式处理器，Nios嵌入式处理器开发工具允许用户配置一个或多个Nios CPU，从标准库中添加外围设备，综合处理自定义系统，与Quartus II设计软件一起编译系统。软件开发的步骤是：利用SoPC Builder生成的软件文件，用文本编辑器编写汇编语言或C/C++源程序，用GNUPro软件开发工具进行程序设计、连编和调试。GNUPro将源程序连编(包括汇编/编译和连接)成可执行程序，通过下载电缆对可执行程序进行调试和运行。Quartus II设计软件提供全面有效的设计环境，将设计、综合、布局和验证以及第三方EDA工具接口集成在一个无缝的环境中。利用集成在Quartus II 3.0中的SoPCbuilder可以创建自己的Nios CPU系统。Nios是Altera公司开发的16/32位嵌入式处理器软核。　　校科研基金项目“基于SOPC的汽车安全监控系统”资助。 Altera公司推出了新一代多种系列FPGA，本设计选用低成本的Cyclone系列器件EP1C12，其具有12 060个逻辑单元，52个M4K RAM块，239 616个RAM位和2个锁相环，最大用户I/O引脚249。　　系统硬件组成框图由Nios系统和外部设备两部分组成，如图1所示。　　　　Nios系统包括CPU(Nios)、存储器(memory)、定时器(TImer)、总线和并/串行接口(key_pio、led_pio、lcd_pio、ccs_pio、uart_0和uart_1)等，并/串行接口分别实现与键盘、LED和LCD显示器、汽车中控系统以及GPS和GSM系统等外部设备的连接。Nios系统设计和设计结果分别如图2和图3所示。　　　　　　Nios系统同键盘、LED和LCD显示器、汽车中控系统以及GPS系统等外部设备的连接比较简单，GSM系统的连接较为复杂，如图4所示。　　　　整个系统的工作过程是：来自汽车中控系统和GPS系统的信息可以显示在LED和LCD显示器上，也可以通过GSM系统进行无线发送。用户可以通过键盘对系统进行控制，也可以通过GSM系统对汽车中控系统进行远程无线控制。　　

时间：2020-09-08 关键词： gsm GPS niosii 监控系统
监控系统中如何选择图象信号的传输线

　　每个监控工程都有其自身的特点和特殊性，因此在组建监控网络时需要充分考虑这些具体情况，选用最为合适的图象和信号传输方式。鉴于同轴电缆、双绞线和光纤是目前监控系统中使用最广的三种传输介质，我们可以从几个方面对它们作一些分析和比较。　　一、特点和传输特性分析　　1、同轴电缆　　一般在小范围的监控系统中，由于传输距离很近，使用同轴电缆直接传送监控图象对图象质量的损伤不大，能满足实际要求。但是，根据对同轴电缆自身特性的分析，当信号在同轴电缆内传输时其受到的衰减与传输距离和信号本身的频率有关。一般来讲，信号频率越高，衰减越大。所以，同轴电缆只适合于近距离传输图象信号，当传输距离达到200米左右时，图象质量将会明显下降，特别是色彩变得暗淡，有失真感。　　在工程实际中，为了延长传输距离，要使用同轴放大器。同轴放大器对视频信号具有一定的放大，并且还能通过均衡调整对不同频率成分分别进行不同大小的补偿，以使接收端输出的视频信号失真尽量小。但是，同轴放大器并不能无限制级联，一般在一个点到点系统中同轴放大器最多只能级联2到3个，否则无法保证视频传输质量，并且调整起来也很困难。因此，在监控系统中使用同轴电缆时，为了保证有较好的图象质量，一般将传输距离范围限制在四、五百米左右。　　另外，同轴电缆在监控系统中传输图象信号还存在着一些缺点：　　1)同轴电缆本身受气候变化影响大，图象质量受到一定影响; 　　2)同轴电缆较粗，在密集监控应用时布线不太方便; 　　3)同轴电缆一般只能传视频信号，如果系统中需要同时传输控制数据、音频等信号时，则需要另外布线; 　　4)同轴电缆抗干扰能力有限，无法应用于强干扰环境; 　　5)同轴放大器还存在着调整困难的缺点。　　2、双绞线　　双绞线的使用由来已久，在很多工业控制系统中和干扰较大的场所以及远距离传输中都使用了双绞线，我们今天广泛使用的局域网也是使用双绞线对。双绞线之所以使用如此广泛，是因为它具有抗干扰能力强、传输距离远、布线容易、价格低廉等许多优点。双绞线对信号也存在着较大的衰减，视频信号如果直接在双绞线内传输，也会衰减很大，所以视频信号在双绞线上要实现远距离传输，必须进行放大和补偿，双绞线视频传输设备就是完成这种功能。加上一对双绞线视频收发设备后，可以将图象传输到1至2km。双绞线和双绞线视频传输设备价格都很便宜，不但没有增加系统造价，反而在距离增加时其造价与同轴电缆相比下降了许多。所以，监控系统中用双绞线进行传输具有明显的优势：　　1)传输距离远、传输质量高。由于在双绞线收发器中采用了先进的处理技术，极好地补偿了双绞线对视频信号幅度的衰减以及不同频率间的衰减差，保持了原始图象的亮度和色彩以及实时性，在传输距离达到1km或更远时，图象信号基本无失真。如果采用中继方式，传输距离会更远。　　2)布线方便、线缆利用率高。一对普通电话线就可以用来传送视频信号。另外，楼宇大厦内广泛铺设的5类非屏蔽双绞线中任取一对就可以传送一路视频信号，无须另外布线，即使是重新布线，5类缆也比同轴缆容易。此外，一根5类缆内有4对双绞线，如果使用一对线传送视频信号，另外的几对线还可以用来传输音频信号、控制信号、供电电源或其它信号，提高了线缆利用率，同时避免了各种信号单独布线带来的麻烦，减少了工程造价。　　3)抗干扰能力强。双绞线能有效抑制共模干扰，即使在强干扰环境下，双绞线也能传送极好的图象信号。而且，使用一根缆内的几对双绞线分别传送不同的信号，相互之间不会发生干扰。　　4)可靠性高、使用方便。利用双绞线传输视频信号，在前端要接入专用发射机，在控制中心要接入专用接收机。这种双绞线传输设备价格便宜，使用起来也很简单，无需专业知识，也无太多的操作，一次安装，长期稳定工作。　　5)价格便宜，取材方便。由于使用的是目前广泛使用的普通5类非屏蔽电缆或普通电话线，购买容易，而且价格也很便宜，给工程应用带来极大的方便。　　

时间：2020-09-08 关键词：传输线图象信号监控系统
4G技术下新型监控报警系统的设计

　　本系统以汽车为开发平台，通过安装传感监控装置，收集信息传递给以单片机为中心的控制系统，经过分析处理后经由GSM(全球移动通信系统)/GPRS(通用分组无线电业务)网络，将报警信息通过电话、SMS(短信业务)或MMS(多媒体信息业务)等形式通知用户，从而实现远距离、准确和实时报警。现在市场上的GPS(全球定位系统)可实现精确的定位寻车及一般的导航，但是GPS的核心技术掌握在美国手中，如果一旦发生战争，美国关闭应用，后果不堪设想，尤其不利于军用，所以我们采用了GPS和我国自主研发的"北斗双星"双模导航定位技术。　　1、硬件系统　　本系统由MCU控制模块、数据采集模块、信息的接收和发送模块、GPS模块和北斗双星定位模块5部分组成。数据采集模块利用不同的传感器将采集到的信号送到MCU，MCU进行分析和处理后发出控制信息和报警指令给GSM模块，然后通过GSM/GPRS网络或北斗双星向用户传递报警信息，达到监控报警的目的。系统将根据用户的决策采取诸如远程喊话示警、遥控拍照和切断油路等操作保证车辆安全。同时，该系统还利用GPS和北斗双星双模定位的方法，实现全天候、高精度的实时导航定位，定位精度可达3m～10m。　　MCU以串行通信的方式实现与GSM、GPS和北斗双星终端的物理连接，并且留有与PC机的。RS-232串行通信接口。利用北斗双星定位终端实现快速定位，并将位置信息通过GSM或者双星简短通信的方式发送到用户和中心站，同时，北斗卫星的双向短报文通信功能可以实现区域报警。　　1.1 MCU控制模块　　该模块起着对传感器报警信息和用户控制信息的接收、分析和处理，是本系统的核心组成部分。它的设计包括电源部分、电平转换部分、存储器设计部分和外部接口部分(包括传感器信号输入、MCU控制外部设备信号输出显示、MCU与北斗双星定位模块和GSM模块之间的通信接口)。　　1.2 数据采集模块　　数据采集模块中可供利用的有多种传感器，如振动传感器、压力传感器、开关式和断线式传感器等多种类型的传感器，当汽车受到振动、车门被打开或者有人坐在座位上时就会产生不同的信息，将这些传感器收集到的不同数据和信息输入系统MCU，以供后续处理。　　此模块设计思路是充分利用车载已有的安全成熟的产品作为系统部分。其优点是：系统安全性和稳定性将大幅提高;可以较好地解决系统状态控制问题，若仅考虑利用手机短信进行设防和解防，不仅很不方便，而且长期的额外信息费用也是不可忽视的;可在原有基础上进行改装，降低产品的成本，同时还可以合理有效地利用已有车载设备，使资源得到合理有效的配置。　　1.3 信息的接收和发送模块　　以GSM模块为核心，实现系统与用户之间的信息交互，在系统中发挥了发送报警信息和接收用户回应的功能。该模块通过GSM网络进行数据通信，无需设置运营中心，大大降低了生产推广成本。此模块的设计思路是：使用开放性较好的GSM模块，并且严格执行欧洲电信联盟的GSM0707、GSM0705、GSM0338等规范和协议，方便系统软件开发，并增强系统软件的通用性。　　1.4 GPS模块　　GPS技术在军用和民用方面的应用都很成熟，通过使用GPS和北斗双星双模定位的方法，可以大大提高导航定位的精度。　　1.5 北斗双星定位终端　　利用此终端实现快速定位，并将位置信息通过GSM和双星简短通信两种方式发送到用户和中心站，并且利用双星简短通信实现区域报警。主要功能是：快速定位，为服务区域内的用户提供全天候、实时定位服务，定位精度与GPS相当;短报文通信，一次可传送多达120个汉字的信息;精密授时，精度达20ns。　　

时间：2020-09-07 关键词： 4g 报警系统监控系统
导入人体区域网路技术，医疗系统实现远程智能监控

　　1月8日早间消息（桑菊）如果不出意外，这应该是2013年的首个大单，对处于萧瑟寒风中的电信设备制造商而言，谁都想攥住这根金羊毛。但从招标的最新进展来看，结果却是令业界大跌眼镜。　　向设备商们伸出温暖之手的并不是财大气粗的中国移动，而是一直勒紧裤腰带过日子的中国联通。据知情人士透露，于上月正式启动的中国联通2013年分组传送设备集中采购，已经初步有了结果。“目前集团公司已经初步划定了各个中标厂商的排名，但最终的结果还需要综合各省分公司的统计，预计很快就会出炉。” 　　在华为、中兴、烽火、上海贝尔和威发新世纪（思科系统）参与的此次招标中：华为排名第一，中兴排名第二，烽火紧随其后，思科排名第四，这四家企业都有所收获；而上海贝尔则由于高商务的因素抱憾出局。　　招标　　在去年5月，中国联通进行了首轮IPRAN设备的集采：采购核心汇聚层设备5000端、接入层设备5万端，为123个本地网、125个城市进行基站分组化升级，这将是全球最大规模的IPRAN网络。中国联通为是次集采准备了30亿元的预算，但由于厂商大幅度降价，最终仅耗资13亿元。　　2012年集采刚刚落幕，中国联通又马不停蹄的启动了2013年的集采：共涉及256个本地网，招标核心汇聚层设备5610端，边缘接入层设备8.03万端。2013年集采在技术标准、建网方案均遵循2012年集采时所规定，不做变更。依旧采用3+2模式，即核心层采用IPRAN，接入层设备对IPRAN、PTN不做限制。　　一改往日的慢节奏，联通此举颇令业界侧目。但来自中讯邮电咨询设计院的专家给出了这样的答案：“半年多的现网应用已经帮我们积累了大量的建网经验与现网需求，从现网需求来看，上一次的建网工期较长、交付较慢，落后于现网节奏。所以这一次，联通决定尽早启动2013年的分组传送设备集采，为3G以及即将来临的LTE搭建更优越的网络基础。” 　　“此次集采的规模差不多是2012年的两倍，主要包括新建和扩容两个部分。新建主要集中在一些三四线城市，而扩容主要是2012年就已经开始部署的一二线城市。“该知情人士说，“此次不少省分都是以新建需求上报，但以扩容形式来落地。” 　　变局　　此次集采过后，中国联通IPRAN网络的规模将会达到13万端，基本上覆盖了国内的大中小城市，这也就意味着设备商“抢地盘”的时代结束了，转而进入利润率较高的升级扩容阶段。　　但从目前所披露的进程来看，几大设备商之间还是存在着一定的变局。而其中最大的变化就在于上海贝尔的出局和思科的逆势入围。“上海贝尔在IP领域有非常强的产品和技术积累，光传输和IP也是整个阿尔卡特朗讯的强项，此次高商务因素所导致的出局，将会对上海贝尔产生不小的影响。”有业内人士如此指出。　　与上贝相比，思科的逆势入围更令业界惊叹。在2012年的集采中，由于高商务和定制能力都比较差，思科没有入围最终集采，但此次思科却所用了完全不同的策略。“在商务因素中，思科和国内厂商报价差不多，局部报价甚至比国内厂商还低。”该知情人士指出。　　“思科充分吸取了去年的教训，这次很务实。但思科的难题并不仅仅是调低商务标，而是如何重新去判定国内电信级市场，在中国联通、中国电信和中国移动三家集采中保持价格体系均衡。”该人士说，“思科最近几年一直奉行高商务策略，此次集采也可能是思科整体市场策略转变的信号。” 　　但这终是局部变化，整体市场格局已经确定。华为和中兴在2012年的IPRAN集采中，分别占据了50%和38%的市场份额；此次集采最终结果虽然还未揭晓，但这两家企业还将牢牢占据了绝大部分疆土。

时间：2020-09-06 关键词：传感器智能医疗远程监控伺服器监控系统
基于单片机和FPGA的远程医疗监控系统

　　一、设计目的　　随着电子信息的飞速发展，近年来，远程医疗监控技术也渐渐成为医疗界的一个热点。重要生命参数的远程监控给年老体弱者带来了方便，也给现代医疗界的发展做出了很大的贡献。　　远程医疗监控系统，它是一种集成信息科学、计算机技术和通信应用技术于医疗卫生领域的高科技产业品。系统主要组成部分为：基于微控制器和传感器节点组成体征采集模块，基于GPRS/GSM的无线收发模块，基于FPGA的上位机监控模块。体征采集模块利用各类专用传感器采集人体体征，并由微控制器进行处理打包，经由GPRS/GSM通信网络上传至上位机监控中心，远程医生/监护人可定时/实时监控病患。该系统测量准确，实用创新性强，性价比高，具有很好的推广价值。　　二、设计要求　　设计一个远程医疗监控系统。要求：　　1.通过各传感器节点准确采集各项体征信号并交于89c51单片机进行处理，计算出各项体征信息（包括体温、血压、脉搏、心率），组成体征采集子模块，完成各项体征信息采集，并上传到GPRS/GSM无线模块。　　2.GPRS/GSM无线模块将接收到体征信息，并准确地送往上位监控机。　　3.基于FPGA的上位监控机接收到下位机信息，并进行分析处理及控制。　　三、设计器材　　1.各类体征传感器（ASDX100压力传感器、HK-2000B脉搏传感器、DS18B20温度传感器）；　　2.微控制器、GPRS/GSM模块、FPGA开发箱；　　3.镊子、钳子、电阻电容电位器导线等若干、焊锡若干。　　四、设计原理及设计方案　　1. 设计原理　　远程监控系统可以定义为通过无线通信技术将远端的体征生理信息和医学信号传送到上位机监控中心进行分析并给出诊断意见的一种技术手段。　　（1）医疗监测原理　　重要生命参数的远程监护是年老体弱者口常监护的一个重要内容，检测的生理信息主要包括：体温、脉搏、血压、心率、心电图、呼吸、血气（氧分压和二氧化碳分压）、血氧饱和度、血糖等。这类生理参数在远程监控系统中一般要求无创或微创检测。本文以温度、脉搏、血压及心率信号为采集对象，选择了简单方便的传感器和无创测量的方法。　　（2）无线通信技术　　随着信息技术的不断发展和社会需求的口益增长，无线通信已经进入规模化发展的阶段，快速发展的无线通信已成为信息产业中最为耀眼的“亮点”，为各种潜在的工程技术提供了新的方法和手段，并成为推动社会发展的强劲动力。无线通信以其不需辐设明线、使用便捷等特点，展示出广阔的市场前景。无线通信技术正以较快的速度进入许多产品，它与有线相比主要具有成本低、携带方便和省去布线的烦恼等优点，特别适用于遥控、遥测、无线抄表、门禁系统、小区传呼、工业数据采集系统、无线标签、身份识别、非接触RF智能片、小型无线数据终端、安全防火系统、无线遥控系统、生物信号采集、水文气象监控、机器控制、信息家电、无线232、无线422/485数据通信等领域。　　利用GPRS/GSM技术进行无线通信，使传统的串口通讯扩展为GPRS/GSM无线网络通讯，可以实时的把采集到的数据发送到上位机，实现数据的及时交换及串口设备的快速无线联网。　　2.设计方案　　（1）医院监控网络体系方案　　医院监护系统由有线网络（局域网）和无线网络两部分组成，如图4.1所示。患者身上佩戴的采集终端，将采集到的生理信息数据（体温、脉搏、血压、心率）发送到AP （Access Point ）。AP通过医院的局域网，将数据转发到上位监控机上，由上位监控机对数据进行分析和处理。　　AP上电后立即尝试连接局域网上的服务器，服务器的IP和端口号以及AP的网络配置都写在配置文件中，用户可以手动修改，连接成功后进入就绪状态。　　如果有携带移动监护设备的患者进入AP的覆盖区域移动监护设备将会查询到AP并与之建立ACL链路，AP接受连接将会进行主从切换，保证AP作为传感器网络的主单元可以继续被其他移动监护设备发现和建链。之后移动监护设备和AP之间进行SDP ， L2CAP， RFCOMM连接。AP向服务器报告有移动监护设备进入该区域，此后AP将透明地转发AP和移动监护设备之间的双向数据。主机可以通过AP和移动监护设备的串口替代功能完成控制、数据采集的功能。当患者离开此AP的覆盖范围后，链路中断，AP向服务器报告移动监护设备离开该区域，同时患者携带的移动监护设备开始搜索新的 AP。医护人员根据移动监护设备与哪一个AP相连可以获知患者在整个病区内的活动情况。其设计结构如图1所示。　　图1 医院无线监控系统结构　　（2）家庭监护网络体系方案　　远程家庭监控网络体系结构如图2所示。　　图2 家庭无线监控系统结构　　无线系统主要由各个传感器节点（脉搏、体温、血压、心率等传感器节点）、若干个具有路由功能的无线节点和中心网络协调器（监护基站设备）组成。监护基站设备连接无线网络与以太网，是家庭无线网络的核心部分，负责传感器网络节点和设备节点的管理。各项体征数据经过家庭网关传输到远程监护服务器。远程监护服务器负责脉搏生理数据的实时采集、显示和保存。医院监护中心和医生可以登录监护服务器查看被监护者的生理信息，也可以远程控制家庭无线网络中的传感器和设备，从而在被监护病人出现异常时，能及时检测到并采取抢救措施。被监护者的亲属等也可以登录监护服务器随时了解被监护者的健康状况。　　五、设计流程　　1.传感器单元的设计　　传感器节点主要功能为采集人体体征信息（包括体温、脉搏、血压、心率），其节点主要包括5部分：中央处理器模块（51单片机）、无线数据通信模块（GPRS/GSM）、传感器、A/D转换及相关调理电路、电源模块。节点框图和处理器单元如图3所示。　　图3 监控传感器节点结构　　2 .GPRS/GSM模块的设计　　介绍了一种通过GPRS/GSM短消息的收发实现对工程上数据采集系统的远程监控，其能够完成对工程上数据采集系统的运行状况监测及采集数据的传输。同时也能够通过短消息控制数据采集系统完成指定的操作。系统自带有存储器，能够按接收到的指令对设备进行配置，并将其存储到设备自带的存储器中。同时系统配备了看门狗，能够使系统在异常状态下重启系统，使系统做到永不死机。由于该系统采用了GSM短消息作为通信载体，使其克服了普通电话监控的人机界面不友好，话费高，且控制功能少等缺点。GSM硬件图如下图4所示。　　更多设计详情及源代码：【详见】

时间：2020-09-06 关键词：医疗监控远程医疗监控系统
雷泰Raytek推出非接触式温度测量系统

　　福禄克公司旗下子品牌雷泰Raytek，作为全球领先的红外测温仪供应商，推出了一种非接触式温度测量系统——装有DataTemp MulTIdrop软件的雷泰EMS设备监控系统，其可为有源元件或运转机械提供全天候的状态监控，并支持预测性和预防性的维护方案。　　设备表面的温度升高或温度到达峰值是故障发生的最主要迹象。雷泰设备监控系统，作为关键资产（包括开关设备和电气柜、电机、泵、燃烧炉控制和加热元件）的早期警告设备，在散热问题开始出现时，便对操作人员发出报警通知并记录数据以作趋势分析，且支持预测性维护计划。　　对热量引发的故障和失效进行早期检测，并执行必要的维护而非预期维护，可降低维护成本并减少意外停机引发的浪费。温度将显示在EMS系统的LCD控制模块上和/或通过计算机Windows 7兼容DataTemp MulTIdrop软件远程实现。　　雷泰EMS设备监控系统为“即插即用”型（即，设有自动检测探头功能），包括一个装有断路器的控制箱，电源和控制器；电缆接线盒；和装有可调安装设备的传感器。采用雷泰紧凑型MI3系列传感器的成熟技术，该系统体积较小，适用于难以接触或封闭的位置，可监控温度范围为-40?C至600?C（1112?F）。控制箱和传感器采用了IP65（NEMA 4）等级，可确保在恶劣环境下的较长使用寿命。　　雷泰解决方案的设计融入了对操作人员安全性的考虑，允许任何人在有源系统上从一个安全位置读取温度，而不需要额外设备或特殊培训。用户可通过控制模块上的集成按钮面板手动设置音响报警，或通过RS-485串行接口和DataTemp软件从中心位置轻松实现远程通讯。对于整个工厂或机械的控制，ASCII协议允许系统与内部控制网络进行通讯。　　要了解更多相关信息，请访问官方网站 www.raytek.com 或www.raytek.com.cn，也可拨打客服热线电话400-810-3435。　　福禄克公司（FLUK）　　福禄克公司成立于1948年，是世界电子测试工具的领导者，多年来，创造和发展了一个特定的技术市场，为各个工业领域提供了优质的测量和检测故障产品。福禄克的用户涵盖面广，包括技术人员、工程师、计量人员等等，他们利用福禄克的测试工具进行工业用电、电器设备和过程校准的安装、故障诊断和管理，并以此控制质量。在过去的五年中，福禄克的测试工具屡获殊荣，赢得了《测试与测量世界》最佳测试工具奖、《控制工程》工程师选择奖等50多个年度产品奖项，备受用户赞誉。　　福禄克旗下子品牌------雷泰创立于1963年，全球总部位于美国加州的圣克鲁斯（Santa Cruz），欧洲总部位于德国柏林，分支机构和授权分销渠道遍布全球。雷泰综合设计、研发、生产、销售渠道建设等多种能力，为客户提供全系列的非接触红外测温仪，以应用于工业生产、过程控制、故障诊断等众多方面。近年，其在福禄克强大的财务支持和广阔的分销渠道下持续健康增长。

时间：2020-09-06 关键词： LCD 测温仪监控系统
基于PLC和ZigBee的路灯无线控制系统设计方案

　　随着我国经济建设的发展，能源的开发和利用也显得日益紧张起来。3月份以来，我国多地出现淡季“电荒”现象，而电能利用效率低下是导致“电荒”的重要原因之一，在这种情况下，提高电能效率迫在屠睫。而随着城市路网建设的不断发展，路灯数量增多，使得人们对电能节约以及路灯的管理要求也越来越高。采用先进技术节约能源以及提高路灯自动化控制与管理水平，已成为城市照明系统建设的当务之急。　　1 路灯照明管理现状　　1）照明设施开关灯统一性差，智能化水平低，不具备远程修改开关灯时间，不能根据实际情况修改开关灯时间，能源浪费大，增加了财政负担；　　2）路灯设备分散，管理人员少，管理困难，不能实时、准确、全面地监控设备运行状况，缺乏灵活的控制手段；3）人工巡检工作量大，效率低，成本高，浪费人力、物力、财力，缺乏有效的故障预警机制。　　2 ZigBee简介　　ZigBee是一种新兴的短距离、低复杂度、低耗功、低传输速率、低成本的双向无线组网通讯技术。它是一种介于RFID（Radio Frequency IdenTIficaTIon，无线射频识别）和蓝牙之间的技术。　　3 GPRS简介　　GPRS通用分组无线业务是一种新的承载业务，提供了一种高效、低成本的无线分组数据业务，特别适用于间断的、突发性的和频繁的数据传输。GRPS永远在线，接入速度快，用户可随时与无线网络保持连接，可使远程数据采集的效率大幅提高。　　4 PLC简介　　PLC即可编程控制器，是一种带有指令存储器，数字或模拟输入/输出接口，能够完成逻辑，顺序、定时、等功能，用于控制机器或生产过程的自动控制装置。PLC具有通用性强、使用方便、适应面广、可靠性高、抗干扰能力强、编程简单等特点。　　5 系统工作原理　　运用组态软件作为上位机的控制平台，通过GPRS与现场控制器PLC通讯。监控中心软件通过GPRS网络向各个现场控制器发送动作指令，使现场控制器完成各种配置和数据采集工作，并对现场控制器发送上来的数据进行分析和处理。现场控制器通过ZigBee无线通讯设备接收单灯控制器所发送来的信号，进行分析处理并通过GPRS通讯系统向监控中心发送信息，以此来实现对路灯的远程无线控制，如图1所示。　　　　6 系统组成　　系统由3部分组成：现场控制器、单灯控制器、监控中心。　　6.1 现场控制器　　由PLC独立控制模块、GPRS通信模块、ZigBee无线通信模块等组成，完成数据采集、控制输出、数据通信、故障报警等功能。现场控制器通过GPRS与照明管理监控中心服务器相连，通过ZigBee无线通信模块与单灯控制器相连，以此实现实时通信，如图2所示。　　　　图2 现场控制器的组成　　6.2 单灯控制器　　每盏路灯都装有单灯控制器，由ZigBee无线通信模块、完成电量采集和模块遥信功能的单片机模块组成。ZigBee无线模块具有网状拓扑结构，这样 ZigBee子网就有内置冗余保证，如果网络中有节点脱离网络，无法工作：【更多详情】

时间：2020-09-05 关键词： Zigbee 无线通讯 plc 监控系统
高等病房远程监控系统解决方案详解

　　一、概述　　闭路电视监控系统正日益受到人们的广泛重视和应用，其产品的种类和档次也越来越多。根据医院的要求，本着高水准、高质量，提高产品的性能价格比，在设计上充分体现建设者的意图，同时考虑到今后使用者的使用、维护、保养的方便性，设计了该系统的总体方案。本方案分为两部分：病房呼叫系统和病房监护系统。　　二、系统架构　　　　高等病房远程监控系统设计方案系统架构　　三、系统功能　　系统主要由两部分软件组成，第一为系统管理软件，基于WEB方式，主要用于护士管理病人，包括向系统添加新住院病人，出院登记;病人家属远程登入系统，在线观看病人现场情况;医生在医院或家中观看病人情况，系统管理员添加护士、医生进入系统等操作。第二为监控软件，主要用于护士对所有病人的集中监控，一个电脑画面可以同时显示16个画面，可以设置10组，可以设定循环时间，在10个组中切换。并且当病人需要呼叫医生时可以按一个按钮，改按钮接到服务器上，护士的电脑上将显示该病人的画面，同时可以与该病人对话。　　四、集中监控软件　　1、多画面监视　　1/4/6/8/9/16画面分割模式，支持不规则画面分割，可以通过简单操作实现放大、还原、全屏、图像交换等操作，可以通过拖放摄像机图标实现对不同摄像机图象的监视，简单易用，并且可以拍照、设置图像循环播放等。　　2 、监控录象和回放　　新版软件在录象上做了很大的改进，新软件在不播放的情况下也可以进行录象，极大的节省了CPU资源，一台P4电脑可以同时记录30~40路图象。　　为增强录像的灵活性，软件同时提供了多种录象方式，有移动录象、自动录象、手动录象、单个录象、预置点录象、报警录象等。　　移动录象：动录象是当服务器检测到现场发生图象运动就自动把现场情况记录下来（例如有人在摄象机前走过，服务器会自动记录到本地计算机上）。　　自动录象：自动录象是指在软件中设置服务器的录象时间段，当客户端软件所运行的电脑系统时间进入设定的时间段后自动把这一时间段的图象记录下来。　　手动录象：使用手动录象方式时，只能通过人为地去控制才能起作用，即用户设定某一通到为手动录像机那么只有用户去停止它，它才会停止录像。　　单个录象确：右击需要录象的某一窗口，在弹出的菜单中选择“单个录象”软件自动把此窗口的图象记录到当前设置盘符的MP4_RecData文件夹中。关闭的时候直接在弹出的菜单中单击“停止录象”即可。　　预置点录象：是在软件中预先设定摄象机的观测点，当服务器接受到报警信号时触发摄象机快速准确的回到预先设定的状态。一台球机一般最多可以设定63个预置点。　　3、监控短信功能通知功能　　可以通过专用的手机短信息发送设备将报警信息发送到指定的手机号码上。　　4、监控呼叫功能　　病人可以通过安装在床头的按钮来呼叫护士，同时护士的电脑是即显示呼叫病人的图像，并提示是否与其对话。　　5、监控断电后自动连接功能　　当软件处在播放或者录像状态时，如果此时视频服务器停止供电，那么软件将停止播放图象同时也停止录像，但是如果视频服务器正常供电后，软件将自动连接服务器，同时恢复原来的播放及录像，无须人工干预。　　6、远程监控控制　　远程控制云台的上下左右转动，镜头光圈、焦距、变倍的调节，也可以控制远程灯光的控制。　　7、远程监控配置　　远程登录到服务器上，配置服务器的各项参数，如修改用户名，密码， IP地址，调节码流等。对服务器，远程升级，远程重启等。　　8、监控状态查看　　通过软件可以查看某一服务器上有多少用户在线，分别在观看哪些通到的图像，当前图像的码流是多少等信息。　　9、监控调节码流　　根据实际需要设定视频服务器的输出码流大小，支持定码流和定码流。　　10、监控双向语音对讲　　即通过电脑可以与远程视频服务器的现成进行双向的语音交流。　　11、监控报警功能　　视频服务器可以输入8个报警信号开关，如红外报警，烟感报警等，输出4个报警信号开关，如警笛等。　　12、监控多播功能　　在LAN环境下，每一个摄像机允许无限多用户同时访问返回，并且只占用一个通道的带宽。

时间：2020-09-05 关键词：远程监控监控系统
基于网络化的平安城市监控与报警系统的建设

　　平安城市监控与报警系统的目的是通过构建一个覆盖整个城市的集成化、多功能、综合性治安防控网络，帮助公安部门更高效、更精确的控制和打击犯罪，从而保证城市环境的和谐与稳定发展。　　平安城市监控与报警系统带有典型的跨地域、跨行业、跨应用特征。在地域方面，整个系统涉及基层派出所、区县公安局（分局）以及市公安局三级监控中心联网。在行业方面，其监控资源涵盖了公安内部与外部众多场景，包括道路、治安卡口、重要单位、重点部位、公共场所以及消防、学校、社区、宾馆、银行、工业厂矿等。在应用方面，系统要完成图像监控、录像回放、智能识别、报警联动等各类功能，并实现与CK报警、 110/119报警、GIS以及GPS等外部系统的整合。　　正因如此，网络化正在成为平安城市监控与报警系统的主流趋势，因为只有网络化才能满足平安城市监控与报警系统复杂的应用需求。也正是因为网络化，平安城市监控与报警系统在建设模式上有了更多的选择。　　从全国各地部分已建以及在建项目的实际情况来看，基于网络化构建的平安城市监控与报警系统建设模式主要有两类：一类是自建专网，一类是与运营商合作。　　在自建专网模式中，投资建设以及维护管理的主体主要是公安部门，所有公安内部监控资源均位于公安内部网，外部监控资源则通过前端模拟对接或平台数字对接两种方式接入。在与运营商合作模式中，投资建设和维护管理的主体可以是运营商，公安部门采用租赁方式，为保证安全，内、外部监控资源同样采用分别接入。本质上，这两种建设模式没有太大差异，都分为内外部两个系统，不同之处在于，前者公安自主性强，后者公安初期投资少。　　　　自建专网模式解决方案　　由于牵涉面广，各地情况又千差万别，因此平安城市监控与报警解决方案在实际部署中通常会采用因地制宜的策略，组网架构不尽相同。其中，三级级联架构是最典型和最常见的，如下图所示。　　

时间：2020-09-05 关键词：报警系统存储设备监控系统
研华触摸式工业平板电脑在远程监控系统上的应用

　　随着网络技术的发展，网络运营商可提供给用户的带宽越来越高，但收入却没有得到相应的增长，宽带用户的ARPU值一直在下降。电信运营商一直在探索差异化运营，为用户提供差异化的服务，以提高业务收入，但成效并不明显。　　自2011年开始，运营商着眼于智能管道的研究，希望通过对网络的有效改进和整合，为用户提供更好的服务，增加业务收入，提升网络运营商在产业链中的地位。运营商提出要做智能管道的主导者，实现用户可识别、业务可区分、流量可调控、网络可管理。在此基础上，延伸到业务质量有保障，提升用户体验。　　用户业务体验难保障　　用户的主要需求可以描述为：观看视频时，需要高清晰画面，播放流畅；下载文件时，希望下载速度快。而目前存在的问题是：很多时候，用户观看在线视频，需预先缓冲一段时间，且观看时，常出现卡顿、马赛克等现象；甚至，视频页面会提示：“当前网络状态不佳，请选择标清模式”、“当前网络状态不佳，建议缓冲一段时间再观看”等；在下载文件时，存在下载速率不高，甚至出现没有种子的情况，下载链接异常中断等。　　为解决上述问题，运营商和互联网内容提供商各自有应对方案。　　电信运营商采用的是BoD方案，为用户提供更高的带宽和质量保障。但这种方案存在以下问题：网络层保障能力有限，缺乏应用层保障。单纯的网络提速无法解决用户的问题。　　互联网内容提供商采用的方案是部署或租用CDN（内容分发网络）服务，加速内容分发。但这种方案存在以下问题：无法突破网络带宽的限制，无法提供更高的速率；受限于网络质量，无法保障用户体验；CDN的加速与网络的不协同，也会导致网络拥塞，影响网络的性能和稳定性，同时，拥塞导致的丢包也必然影响业务质量。由此可见，单纯靠CDN加速也无法解决用户的问题。　　从用户的体验需求出发，发现影响用户体验的因素主要有两个方面，一个是网络质量，一个是应用服务提供的质量，如果两者都能得到保障，则能从根本上保障用户的业务体验。　　因而，我们希望把网络层的保障和应用层的保障协同起来，实现针对特定用户所请求的特定内容，在特定时段进行特定的保障。用户无需到特定的页面上去申请网络提速或者应用保障，只需在其所使用的应用界面上点击所需的内容，即可得到应用和网络的联合保障。具体地实现对用户透明。　　应用与网络联动落地方案　　为实现应用和网络的联合加速保障，需要解决三个问题。　　网络层的加速和保障　　由于BRAS/SR以上的网络为分组统计复用，且不具备用户级的管理和控制，难以基于用户进行策略的控制和质量保障。因而，建议把内容分发节点下移至BRAS/SR，有效避开网络中的拥塞点；在BRAS/SR用户侧端口及以下的网络中的网络质量保障，可借用BoD实现。　　应用层的加速和保障　　应用层的加速和保障，可借用目前CDN的应用加速和保障方法，还可结合P2P+CDN或P2SP+CDN方式。　　网络层和应用层的协同　　在具备网络层加速和保障以及应用加速和保障的基础上，为了实现针对特定用户所请求的特定应用内容、在特定时段进行保障，需要把两者协同起来。BRAS/SR设备集成CDN功能，提供专用的业务板卡为用户提供CDN服务，建立和维护用户业务状态机，可有效和网络层的用户状态机实现协同和联动（见图）。　　用户在应用页面点击特定的、高等级的应用后，网络层带宽可以在使用该应用内容期间得到自动提升；同时，应用内容得到加速和保障，加速和保障的方式可以采用P2SP方式，多CDN节点同时向该用户传送，其他正在使用该应用内容的用户也可以给该用户传送。用户同时得到了应用与网络的联合加速和保障，体验提升。　　联合方案的四大应用价值　　本方案的应用价值可以从用户、电信运营商、互联网内容提供商、设备和方案提供商四个角度分析。　　基于用户角度，用户观看在线视频的清晰度和流畅度得到提升，并能实现超高速大文件下载，按照现有的设备和网络情况，理论上可提供1Gbit/s的下载速率，相比现有的下载速率呈数十倍的提升。　　基于电信运营商角度，应用和网络的联合加速保障，使得网络和应用更紧密地结合，使得电信运营商能充分发挥其网络优势，在市场竞争中取得更大的优势。同时，电信运营商可利用应用与网络联合的优势，发展更多的增值业务，比提供更快的下载服务、高清视频服务、提供更灵活的套餐，从而促进业务增长。　　基于互联网内容提供商角度，由于电信运营商提供了包括网络接入和CDN服务的全套解决方案，互联网内容提供商无需再担心网络和内容分发的问题，无需考虑CDN的建设和维护，可以专注于内容的运营。　　基于设备和方案提供商角度，其发挥了自身的核心技术，解决了用户和电信运营商最为迫切的需求。同时，也使得电信运营商在综合业务运营和信息服务提供上更近一步，扩大了市场规模，获得更多的市场份额；从而拉动了更多的投资建设需求，设备和方案提供商可从中取得更多的收益。

时间：2020-09-04 关键词：人机界面平板电脑研华远程监控工业以太网监控系统
如何为远程医疗设备选择合适的实时操作系统？

　　发达国家的医疗保健服务已经超越了以医院为中心的模式，以初级和二级医疗为重点而不仅局限于医院。这些举措推动了用于医院之外、通常由病人自己使用的远程医疗设备的发展。　　对远程医疗设备的迫切需求正在推动市场增长。美国2010年的无线消费医疗设备销售额达到6亿美元，2011年有望达到13亿美元，然而与全球医疗设备市场每年2000 亿美元的销售额相比仍然微不足道。　　操作系统 - 关键区分要素　　操作系统是所有电子医疗设备的关键区分要素，而且制造商也非常明白这一点。事实上，他们往往在选择板卡前先选择操作系统。　　　　图 1 不同行业中首先选择操作系统的项目所占比率　　本文的讨论未包括消费级医疗设备，例如其发生故障时不会造成严重后果。对于出现故障时会导致严重后果的设备，可将其操作系统的关键特征归类如下：　　· 可信性：在规定的时间内对事件进行及时正确地响应　　· 连接性：直接或通过网络与不同设备和系统进行通讯　　· 数据完整性和安全性：安全地存储数据并防止未经授权的查阅　　以上每个特征都值得深入讨论，在此我们只重点介绍其中最重要的一种特征--可信性。　　　　图2 一种简单的远程病人监护网络　　选择GPOS 还是RTOS？　　可信性将可用性和可靠性合二为一。可用性要求系统能够及时响应请求的概率，可靠性则表明响应的正确率。对一个可靠的操作系统的要求是排除使用通用操作系统（GPOS），因为GPOS不能提供严格的可用性和可靠性的保障。　　与此相反，实时操作系统（RTOS）本身就是为了保证可用性和可靠性而精心设计的。设计人员可以信赖实时操作系统随时响应需求的可用性和按要求完成任务的可靠性。因此，可以得出这样的结论，即：大部分的医疗设备需要实时操作系统。　　实时操作系统架构　　即使像配药机这样简单的设备也不允许出现故障。假如故障导致数据损坏，配药机可能改变剂量，最终的严重后果可想而知。既然操作系统架构对系统的可靠性有重要影响，那么首先就应对它进行严格评估。实时操作系统最常见的三种架构是实时执行、宏内核和微内核。　　实时执行架构　　基于实时执行架构，所有的软件组件包括内核、网络协议栈、文件系统、驱动程序和应用程序都在同一个内存地址空间内运行。这种架构虽然高效，但它有两个明显缺点。首先，任何模块内的单个指针错误都可能损坏内核或任何其他模块所用的内存。其次，系统崩溃后不会留下诊断信息。　　宏内核架构　　有些实时操作系统通过宏内核架构（其中的程序可作为内存受保护的进程运行）解决可能引起整个系统故障的内存错误。这种架构的确能防止用户故障代码损坏内核。但是，内核组件仍与其他服务共享相同的地址空间。因此，任何服务中的单个编程错误都可能导致整个系统崩溃。　　微内核架构　　在微内核实时操作系统中，设备驱动程序、文件系统、网络协议栈和应用程序都运行在内核外部的独立地址空间，因此它们不仅与内核隔离，而且彼此之间也互不影响。一个组件出现故障不会导致整个系统瘫痪，组件中的内存故障不会影响其他进程或内核。这样，操作系统就能自动重启故障组件。　　　　图 3 病人监护系统中的微内核操作系统　　实时操作系统的关键特征　　在众多操作系统特征中，除了系统架构必须仔细评估，其他重要特征包括：　　· 确保实时性　　· 防止优先级反转　　· 确保可用性　　· 监视和重启进程　　确保实时性　　对所有需要确保实时性的系统而言，抢占式内核至关重要。例如，病人摔倒时触发了报警器应能抢占进程并发出警报。　　为确保优先级高的进程随时获得所需的CPU周期，实时操作系统的内核需要进行抢占式运行，此外内核的设计必须尽可能简单，以保证最长的不可被抢占代码路径有执行时间的上限。只要操作系统的内核能将任务密集的运行分配到外部进程或线程，并只包括路径短的服务就能在操作系统内核实现这种简洁性设计。

时间：2020-09-04 关键词：操作系统内核远程医疗医疗设备监控系统
基于3G通信网的移动机器人远程监控的设计与实现

　　德克萨斯州，奥斯汀——2013年4月26日，Cirrus Logic公司（纳斯达克代码：CRUS）近日推出首款适合白炽灯替换市场的单级LED驱动系列CS1615/16。由于使用专利技术，CS1615/16 能够在相同的总物料成本情况下，提供比其它单级LED驱动器更高的调光兼容性。Cirrus Logic 已经拥有一系列双级LED驱动器，并于2012年进入LED替换市场。　　在众多品种的调光器中，CS1615/16可一直调节至几乎零光输出，非常接近白炽灯泡的调光性能。而很多同类LED驱动器的调光性能却达不到这种程度，很多情况下它们甚至不能调暗至光输出的50％以下。调光范围有限、闪烁和开关失灵是导致LED灯泡高退货率的主要因素。　　Cirrus Logic 公司能源部门副总裁兼总经理Tom Stein表示：“CS1615/16系列延续了我们的产品战略，不仅提供最佳调光兼容性，还能降低系统成本。这种对性能和用户体验的专注将是推动广大消费者选择LED照明产品的关键所在。” 　　据市场研究公司Datapoint Research预计，LED升级替换市场将从2012年的2.485亿个增长至2016年的19亿个。　　为测试调光兼容性，Cirrus Logic开发出一种测试方法，根据多重因素综合评定，包括无闪烁操作（灯泡在调光范围内任何一个点都不闪烁）、流畅的“单调”调光（灯泡稳步变暗，输出亮度无突然下降、无跳跃）以及完整调光范围（灯泡能在最高与最低光输出范围内进行有效调节）。Cirrus Logic对300多个调光器进行测试，这些产品涵盖当今市场上最流行的款式，代表了全球多数用户使用的调光器。在上述测试中，CS1615/16在单灯和多灯配置上均优于其它品牌。　　数字控制决定性能　　大多数调光器是为纯电阻负载的白炽灯设计的，但是，在LED灯泡内的额外电子元件对兼容性构成挑战。Cirrus Logic的调光兼容性专利技术可识别使用中的调光器类型，并提供相应的操作模式搭配使用。这种自适应数字技术即使是在最具挑战的前切、后切以及智能数字调光器上，都能持续实现全部功能。Cirrus Logic的LED驱动器使得新一代灯泡达到能源之星计划、美国电气制造商协会和加州能源委员会制定的标准，也能满足其他组织对调光器兼容性提出的更新、更严格的要求。　　CS1615/16提供原边恒流控制和精确的LED电流调节，并具有高效率、主动功率因数校正、总谐波失真率低等特点。这些IC支持隔离和非隔离的拓扑结构，并将EMI的设计简化到最小。CS1615/16能够提供输出开路保护、输出短路保护和通过热敏电阻（NTC）实现的外部过热保护。CS1615专为120VAC线电压应用而设计，CS1616专为230VAC线电压应用而设计。　　关于 Cirrus Logic 公司　　Cirrus Logic 公司致力于为广泛的创新市场研发高精度、模拟、数字和混合信号集成电路产品。以其品种繁多的模拟混合信号专利产品为基础，Cirrus Logic 公司为多种音频和能源相关的应用提供最优化的产品。公司总部位于美国德克萨斯州奥斯汀市，并在欧洲、日本以及亚洲其它国家设有分支机构。详情请访问www.cirrus.com。　　Cirrus Logic、Cirrus和TruDim都是 Cirrus Logic 公司的注册商标。本文中涉及的其它产品名称均隶属于相关公司。

时间：2020-09-04 关键词： 3g 机器人远程监控监控系统
基于GS1011的无线远程医疗监控系统的研究

　　摘要：本文分析了无线远程医疗监控存在的必要性，从总体结构、硬件分布和软件实施详细介绍了以超低功率单片系统GS1011为核心的解决方案，并通过仿真实验验证之。　　近年来，随着社会的不断发展和人们生活水平和质量的提高，人们对医疗服务的各个方面提出了新的要求，社会需要更加完善的医疗系统提供服务，要求改变传统的医疗模式，使医院与医院、医生与病人直接通过远程医疗合作，建立了一种全新的关系，达到提高医疗效果的目的。因此应用成熟的WiFi无线传感器网络技术，发展面向个人的远程监护系统已成为迫切需要。　　1、系统总体概述　　针对当代医疗监护系统的发展需要，并结合WiFi无线传网络技术的在空间移动上的灵活性，传感器的实时测试的优点以及GS1011超低功率单片系统的解决方案，将嵌入式WiFi无线传感器网络技术应用于传统医疗监护系统中，建立起新一代远程医疗监护系统。系统将实时数据传送到医生和护士办公计算机上，并能实现短信群发到医生护士手持PDA，方便其掌控其责任病人的情况。此系统将改善传统医疗监护系统在时间和空间上的局限性，提高医疗监护系统的实时性、灵活性，是一个集监控、医疗和信息管理于一体的医疗监护系统。　　2、硬件组成与工作　　在系统中，监护病人的无线传感节点以自组织形式构成网络，通过多跳中继方式将监测数据传到监护基站，并由基站装置将数据传输至所连接的PC，医生或护士可以通过PC获得病人的生理数据，对监护病人做出及时处理。主要由监护基站、路由节点和无线传感节点组成。系统中的数据采集包括人体生理信号如：体温、血压、脉搏、心电等通过传感器采集，通过模数转换把人体生理参数的模拟信号转化为待处理的数字信号。当医生和护士离岗时，相关数据信息能以短信息群发的方式发送到手持PDA上，医生和护士能及时掌控患者的详细数据信息。　　系统采用的无线传感器网络能够协作地实时感知和采集网络分布区域内的各种信息，并进行处理，再以无线方式传送给用户终端。而WiFi技术保障设备之间可以自由直接地进行通信，也可以在基站或者访问点的协调下进行通信。同时基于IP的联网技术能够非常方便地实现与已经安装在企业和家庭中的网络进行无缝连接，而且还具有更好的安全性和系统的课扩展性。系统核心部分采用GainSpan公司的超低功耗的无线芯片GS1011，集成了802.11 无线电， MAC和基带，以及PA，应用CPU， RTC， SRAM 与闪存。支持IEEE 802.11，具有802.11i/WPA2身份验证， AES 硬件加密。GS1011结构如图2.1所示。

时间：2020-09-04 关键词： Wi-Fi 无线网络远程医疗无线医疗 gs1011 监控系统
基于WIFI技术的医疗监控系统

　　摘要：结合当今信息技术及无线传输技术的发展，通过WIFI技术将信息技术运用到个人医疗设备上，并整合互联网与社会医疗资源，建立一套面向病患、围绕病患的新型社区医疗信息系统。　　前言　　近年来，信息技术在各个领域的广泛应用给人们的生活生产带来了极大的便利，特别是在医疗领域的运用减轻了医务工作者的工作强度，提高了医疗水平，减少了患者的负担与痛苦。更重要的是，它带来了一系列的医疗模式，推动着医疗事业的发展。例如，发展日趋成熟的医院信息系统，远程医疗系统等都在不断的更新着人们对医疗保健的印象。　　同时电气技术的高度发达使越来越多的病患拥有了与自己病情相应的小型诊疗设备，如老人监护仪、血压仪、血糖仪等。但是目前个人诊疗始终停留在独立封闭的状态中，信息技术并未充分运用其中，所以几乎所有病患都面临着这样几个问题：　　（1）遇到一些身体异常情况，甚至紧急状况时得不到及时的专业指导和救助；　　（2）难以对治疗仪器反馈的数据进行长期的准确记录；　　（3）无法对自身记录的数据进行科学分析，难以窥测病情的变化。　　针对以上问题，结合当今信息技术及无线传输技术的发展，可以通过WIFI技术将信息技术运用到个人医疗设备上，并整合互联网与社会医疗资源，建立一套面向病患、围绕病患的新型社区医疗信息系统。　　一、WIFI技术　　WIFI的全称是Wireless Fidelity，又叫802.11b标准，是IEEE定义的一个无线网络通信的工业标准。该技术使用的使2.4GHz附近的频段，该频段目前尚属没用许可的无线频段。其主要特性为：速度快，可靠性高，在开放性区域，通讯距离可达305m，在封闭性区域，通讯距离为76~22m，方便与现有的有线以太网络整合，组网的成本更低。　　二、系统描述　　1．无线传输的实现　　本系统的WIFI由于是用在移动的监护系统上的，所以可以称为嵌入式WIFI，嵌入式WIFI的结构与标准PC/OS平台上的实现有所不同。要在普通的微处理器/微控制器上实现WIFI通信，其硬件结构、软件层次都必须进行裁减。此处我们采用了完善的WIFI模块，软件层次对协议进行了按需的裁剪以适应嵌入式的要求。系统由于采用嵌入式WIFI技术，支持数字分组，可以根据需要对被测对象分组检测，同时进行实时数据传输；保证了监护的可靠性与准确性，在实际使用中有很好的效果。

时间：2020-09-04 关键词： Wi-Fi 医疗监控血糖仪诊断设备监控系统
提高医疗保健及疾病监控设备的资料存取和软件升级能力

　　疾病监控设备通常用于测量患者的生命迹象，例如，血压、心率等参数，管理这些重要资料的要求远远超出了简单的库存控制范围，需要设备能够提供设备检查、校准和自我检测结果，并具有安全升级功能，同时最大幅度地降低设备故障停机时间。维修人员经常把记录维修资料的标签粘贴在设备上，由于需要记录大量资料，过一段时间后逐渐损坏，标签贴纸不再是一个合理的选择。随着技术迅猛发展，疾病监控设备通常需要软件升级。　　与静态的标签贴纸不同，动态的双界面RFID EEPROM电子标签解决方案则能够记录测量参数，以备日后读取，还能把新资料登录系统，例如，校准常量和检查信息，而且无需外接任何外部连接器。双界面电子标签可通过I2C界面连接疾病监控设备，当设备正在执行时，设备可以通过I2C界面读写电子标签。即便疾病监控设备没有工作，医务人员也可以通过一个普通的符合ISO 15693 13.56 MHz RFID标准的电子标签读写器读写电子标签的资料，因为能够确保资料最新、安全且随时读写，双界面存储让射频识别技术链变得更加完美。　　双界面无源RFID系统的目标应用包括设备保养条件及记录、授权附件验证、传感器、假冒商品识别、一次性用品重复使用控制、增加新的授权产品。当监控设备工作或待机时，操作人员可以通过监控设备读写双界面RFID内的资料，当设备关机时，操作人员可以使用电子标签读写器管理双界面RFID内的资料，这一大优点为设计人员开创更多的机会。　　疾病监控系统分类　　疾病监控系统通常分为三大类：床边监控仪、便携式手持监控仪和人体配戴式监控仪。　　床边监控仪在提供医疗监控诊断信息方面起着重要作用，在医疗保健专业人员所需的监控信息中，床边监控仪提供的信息所占比例越来越大。床边监控设备通常被安装到重要的密集型护理的监护区，例如，重症病房，目前大多数床边监控设备都能通过医院网络与中央监控系统连接，通过设施网络交换资料。　　便携监控仪的管理具有不小的挑战性，因为这类设备似乎能够“离开群体甚至迷路”。虽然查看设备位置不在本文讨论范围内，但是了解设备发生了何种状况对确保设备连续达标和验证设备主人身份有很大的帮助。　　人体配戴式监控仪虽然不是新发明，但是，随着产品更新换代，测量方式和资料量正在快速增加，这正是一个双界面RFID解决方案的用武之地。作为连接系统内部工作的闸道，双界面RFID解决方案与监控设备相连无需纠缠不清的连接线，因此可提高监控仪的实用性和使用寿命。　　人体配戴式监控仪还可以再分为以下几个类别：　　• 移动/配戴式个人监控仪（MPM）：配戴式个人监控设备即时监控慢性病症患者的生命特征活动，并储存和转发测量资料或者报警。　　• 移动聚合器：能够通过移动无线技术报告患者状态的有或无外接传感器的智能手机类设备。　　• 配戴式医疗保健设备：配戴在手腕/手臂/胸部的医疗保健设备或嵌在鞋和衬衫织物内的传感器，用于检测心率、呼吸、步调等生命活动特征。　　• 远距患者管理（RPM）设备：内建患者专用传感器的特殊监控设备。这些系统配备医院专门为患者定制的传感器，能够报告所有的生命迹象参数，例如，心率、患者的姿势（站立还是倒卧）。　　不论是床边监控器，还是便携或配戴式监控仪，所有的疾病监控设备都面临共同的挑战：如何让设备保持最新的软件、校准资料或保养记录？如何发现故障设备？　　管理系统资料的好处　　一次简单的设备故障就会对疾病检测报告结果产生很大的影响。毫无疑问，在困扰业界多年的问题中，监控设备备用电池故障始终高居榜首。系统自我检测在该报警的时候没有报警，而在不该报警的时候报警。对于床边监控设备，中央监控功能可以报告故障，并派维修人员排除故障，从而能够避免严重的问题发生。　　便携式和身体配戴式监控设备给设计人员带来一系列更具挑战性的问题。其中一个问题是，这两大设备是增长最快的市场，而交互操作标准直到最近才真正成为人们关注的焦点。例如，最近，康体佳健康联盟指定四个主要的互通性界面：USB、蓝牙、低功耗蓝牙（BTLE）和 ZigBee。这四种界面技术的共同点是，监控设备必须上电且执行（即执行监控功能），才能通过这些界面报告故障，指示设备工作正常。当关闭这些设备时，监控器与错误信息通常会断开联系，从而增加了减少甚至发现任何问题的难度。　　便携式和身体配戴式监控设备还有另一个新出现的挑战性，为了防水和防尘，便于清洁，不会损坏电子元件，今天的便携式和身体配戴式监控设备都採用整体密封式设计，在这种情况下，增加连接器或在连接器上增加功能势必提高传感器端的体积、成本或系统复杂性。　　读写相关资料　　掌握可读的且可靠的追溯性产品信息资料，了解从生产线到工作状态的全部产品信息，对于管理执行这些资产（监控设备）非常有用。很久以来，设备厂商都是在标签贴纸上用代码简明地描述产品的制造日期、修订版本、生产线/工厂、序号等产品信息，然后把这些标签粘贴在相关产品上，这类资料是品质控制与设备信息追溯所需的基本信息。　　今天的系统需要选项配置、多个传感器校准常数、保养间隔等资料。某些系统还提供使用者可程式设计“热键”，让用户设置和锁定这些功能，仅设备维护管理就需要如此多的资料，就不用说“检查发动机状态指示灯”的即时资料了。能够记录并即时读取错误事件可大幅降低设备的维护成本，减少检修保养时间。　　通过I2C界面给每台设备连接一个电子标签，医务人员即可记录并即时读取错误事件。

时间：2020-09-04 关键词： RFID 传感器监控设备医疗保健监控系统