1.本发明涉及应急广播
技术领域：
：，特别指一种应急广播边缘计算方法。
背景技术：
：：2.在应急广播系统中，ip/4g广播是一种非常普及的广播通道，因为具备双向交互性、覆盖面积广、实施简单、总体工程费用经济等优点，深受青睐。3.随着应急广播终端数量的增加，对应急广播服务器的计算处理要求也越来越高，针对这种情况，传统上存在如下两种方法：方法一是对应急广播服务器进行扩容；方法二是降低单个应急广播终端的计算量，以提高接入的应急广播终端的数量。但是，传统的方法存在如下缺点：4.方法一：1、网络带宽的发展速度已经明显慢于计算机硬件的发展速度，虽然随着5g技术的出现，解决了短距离无线通信效率的问题，但是云端的带宽目前还是没有新的解决方案；2、云服务器的计算能力有上限，随着分布式系统的发展和大数据技术的成熟，计算能力得以提高，但是效率上也会受影响，因为分布式技术需要主系统和从系统的数据协同操作，导致效率会有所下降；3、由于链路、多平台协同等原因，应急广播终端的数据上报后，需要经过一系列的跳转处理，最终再回馈到应急广播终端，导致云服务器数据处理的响应比较慢，不能做到毫秒级的响应；4、对带宽进行扩容的成本成指数上涨。5.方法二：而降低单个应急广播终端的计算量，会导致应急广播终端的性能下降，进而影响应急广播质量。6.因此，如何提供一种应急广播边缘计算方法，实现在不大幅增加成本并保障应急广播质量的前提下，提升应急广播计算的响应速度，成为一个亟待解决的技术问题。技术实现要素：7.本发明要解决的技术问题，在于提供一种应急广播边缘计算方法，实现在不大幅增加成本并保障应急广播质量的前提下，提升应急广播计算的响应速度。8.本发明是这样实现的：一种应急广播边缘计算方法，包括如下步骤：9.步骤s10、在各边缘计算终端上分别搭建包括设备接入层、核心服务层、支持服务层以及导出服务层的边缘计算平台；10.步骤s20、配置所述设备接入层、核心服务层、支持服务层以及导出服务层的参数，进而对所述边缘计算平台进行初始化；11.步骤s30、边缘计算终端通过所述设备接入层接入应急广播终端，获取应急广播终端的运行数据并存储至所述核心服务层；12.步骤s40、所述支持服务层从核心服务层读取运行数据，基于所述运行数据执行对应的微服务；13.步骤s50、边缘计算终端通过所述导出服务层与云服务器建立连接，并周期性的进行数据同步。14.进一步地，所述步骤s10具体为：15.在搭载linux系统的各边缘计算终端上，通过docker分别搭建基于go编程语言的边缘计算平台，并为所述边缘计算平台创建守护进程脚本，通过所述守护进程脚本重启运行异常的边缘计算平台；16.所述边缘计算平台设有设备接入层、核心服务层、支持服务层以及导出服务层。17.进一步地，所述步骤s10中，所述设备接入层用于接入应急广播终端；所述核心服务层用于存储应急广播终端的运行数据；所述支持服务层用于依据运行数据执行对应的微服务；所述导出服务层用于边缘计算终端与云服务器的数据交互。18.进一步地，所述步骤s20中，所述配置设备接入层的参数具体为：19.配置设备接入层中，各应急广播终端的类和终端参数；20.所述终端参数至少包括终端id、工作状态、区域码、资源编码、网络信息、系统音量、版本信息以及系统时间。21.进一步地，所述步骤s20中，所述配置核心服务层的参数具体为：22.创建一redis数据库用于存储核心服务层接收的运行数据，在所述redis数据库中为存储的运行数据配置边缘计算标识；23.所述边缘计算标识的取值为是或者否，分别表示在边缘计算终端进行计算和在云服务器进行计算。24.进一步地，所述步骤s20中，所述配置支持服务层的参数具体为：25.配置支持服务层包括规则引擎服务、告警通知服务以及计划服务的微服务；26.配置所述规则引擎服务具体为：配置规则引擎触发的sql条件语句以及规则参数；27.所述规则参数包括url、method、datatemplate以及sendsingle；所述method为put或者get；所述url用于标识数据获取的路径；所述datatemplate至少携带音频id、音频内容、音量大小、关联的终端id、播放次数；所述sendsingle用于标识数据是否发送成功；所述put用于执行对应动作或者将参数设置到应急广播终端中；所述get用于从应急广播终端中获取数据；28.配置所述告警通知服务具体为：配置告警触发时发送的邮箱或者手机号；29.配置所述计划服务具体为：配置定时事件包括事件id、事件名称、开始时间、结束时间、对应定时广播的周期、需要触发的广播音频内容、restful的地址信息、音频调用接口、触发广播内容的定时参数。30.进一步地，所述步骤s20中，所述配置导出服务层的参数具体为：31.配置导出服务层链接的云服务器的地址以及同步数据；32.所述同步数据至少包括告警列表、应急广播终端运行监控表、广播列表、计划列表、规则参数、告警通知服务关联的邮箱或者手机号；33.所述告警列表至少包括告警发生的终端id、告警时间、恢复时间、告警广播id、触发源信息id；所述应急广播终端运行监控表至少包括终端id、上线时间、离线时间；所述广播列表至少包括广播id、广播开始时间、广播结束时间、广播内容；所述计划列表至少包括定时广播的开始时间、结束时间、触发周期、广播内容。34.进一步地，所述步骤s30具体为：35.边缘计算终端通过所述设备接入层的终端参数接入应急广播终端，实时获取应急广播终端的运行数据存储至所述核心服务层的redis数据库中，并更新所述运行数据的边缘计算标识。36.进一步地，所述步骤s40具体为：37.所述支持服务层通过restful的api接口从核心服务层的redis数据库中读取运行数据，基于所述运行数据执行规则引擎服务、告警通知服务或者计划服务。38.进一步地，所述步骤s50具体为：39.边缘计算终端通过所述导出服务层与云服务器建立连接，并周期性的通过restful的api接口进行数据同步。40.本发明的优点在于：41.1、通过在边缘计算终端上搭建包括设备接入层、核心服务层、支持服务层以及导出服务层的边缘计算平台，通过设备接入层接入应急广播终端，获取应急广播终端的运行数据并存储至核心服务层，支持服务层基于核心服务层的运行数据执行对应的微服务，并通过导出服务层与云服务器建立连接进行周期性的数据同步，即将原本需要云服务器进行计算的任务下移到边缘计算终端，通过边缘计算终端进行规则引擎服务、告警通知服务或者计划服务的微服务，再定期与云服务器进行数据交换，无需到云服务器上进行一系列的跳转处理，无需对云服务器进行扩容，无需降低应急广播终端的计算量，最终实现在不大幅增加成本并保障应急广播质量的前提下，极大的提升了应急广播计算的响应速度。42.2、通过创建守护进程脚本，保护边缘计算平台的进程不被破环和中断，进而极大的提升了边缘计算的稳定性。43.3、通过go编程语言搭建边缘计算平台，不仅减少了空间占用，加快了运行速度，还与用于发现和注册设备的consul服务采用相同的编程语言，使得配置修改更加高效，无需像c语言一样下载安装多种支持库。44.4、通过创建redis数据库用于存储核心服务层接收的运行数据，即使用redis数据库作为持久化存储的数据库，由于redis是一种内存虚拟化存储数据库，存取效率高，随着数据量不断的迭代，暂用的内存也会随着变大，在边缘端的边缘计算终端的数据量比较小，因此，不需要担心存储迭代的问题，只要在暂用内存限制中配置好边边缘计算终端内存的上限即可。附图说明45.下面参照附图结合实施例对本发明作进一步的说明。46.图1是本发明一种应急广播边缘计算方法的流程图。47.图2是本发明一种应急广播边缘计算方法的硬件架构图。具体实施方式48.本技术实施例中的技术方案，总体思路如下：通过在边缘计算终端上搭建包括设备接入层、核心服务层、支持服务层以及导出服务层的边缘计算平台，通过设备接入层接入应急广播终端获取运行数据并存储至核心服务层，支持服务层基于核心服务层的运行数据执行对应的微服务，并通过导出服务层与云服务器建立连接进行周期性的数据同步，将原本需要云服务器进行计算的任务下移到边缘计算终端，以实现在不大幅增加成本并保障应急广播质量的前提下，提升应急广播计算的响应速度。49.请参照图1至图2所示，本发明一种应急广播边缘计算方法的较佳实施例，包括如下步骤：50.步骤s10、在各边缘计算终端上分别搭建包括设备接入层、核心服务层、支持服务层以及导出服务层的边缘计算平台；所述边缘计算平台优选为edgexfoundry；51.步骤s20、配置所述设备接入层、核心服务层、支持服务层以及导出服务层的参数，进而对所述边缘计算平台进行初始化；52.步骤s30、边缘计算终端通过所述设备接入层接入应急广播终端，获取应急广播终端的运行数据并存储至所述核心服务层；53.步骤s40、所述支持服务层从核心服务层读取运行数据，基于所述运行数据执行对应的微服务；54.步骤s50、边缘计算终端通过所述导出服务层与云服务器建立连接，并周期性的进行数据同步。55.所述步骤s10具体为：56.在搭载linux系统的各边缘计算终端上，通过docker分别搭建基于go编程语言的边缘计算平台，并为所述边缘计算平台创建守护进程脚本，通过所述守护进程脚本重启运行异常的边缘计算平台；57.所述边缘计算平台设有设备接入层、核心服务层、支持服务层以及导出服务层。58.edgexfoundry使用consul服务来发现和注册设备，consul也是采用go编程语言进行开发的，使得配置修改更加高效。59.所述步骤s10中，所述设备接入层用于接入应急广播终端，采用mqtt协议；；所述核心服务层用于存储应急广播终端的运行数据；所述支持服务层用于依据运行数据执行对应的微服务(core-command)，实现自动告警、自动转播、定时广播等功能；所述导出服务层用于边缘计算终端与云服务器的数据交互；各层均采用restful的api接口进行数据交互，与语言无关，支持更多类型设备的接入。60.所述步骤s20中，所述配置设备接入层的参数具体为：61.配置设备接入层中，各应急广播终端的类(class)和终端参数；类是面向对象程序设计实现信息封装的基础，是一种用户定义的引用数据类型，也称类类型，每个类包含数据说明和一组操作数据或传递消息的函数，类的实例称为对象；62.所述终端参数至少包括终端id、工作状态、区域码、资源编码、网络信息、系统音量、版本信息以及系统时间。63.所述设备接入层的配置文件采用yaml文件，在设备接入层目录下的res/profile子目录下，用来描述应急广播终端(边缘设备)的类和终端参数，不同的应急广播终端对应一个配置文件，配置文件放在speaker_device.yaml文件下，ip话筒等控制设备的配置文件放在controller.yaml文件下，所有接入设备都是通过自定义的方式，声明了类和终端参数，这些参数存储在configuration.toml中，这个文件中有默认的设备信息和扩展的自定义参数，通过go编程语言载入的设备接入层会忽略这些自定义扩展的参数，需要通过sdk的api接口loadcustomconfig来启用自定义参数，接口原型是loadcustomconfig(configupdatableconfig,sectionnamestring)error，多个自定义的参数在开机时需要多次通过这个接口同步，参数在变换时，设备接入层通过注册监听接口listenforcustomconfigchanges来获取回调，形成完整的数据上行和下行交互，在完成配置后，需要使用go环境重新编译设备接入层，再使用docker-compose指令部署服务到docker中，进而完成设备接入层的微服务的部署。64.所述步骤s20中，所述配置核心服务层的参数具体为：65.创建一redis数据库用于存储核心服务层接收的运行数据，在所述redis数据库中为存储的运行数据配置边缘计算标识(writable.persistdata)；66.所述边缘计算标识的取值为是或者否，分别表示在边缘计算终端进行计算和在云服务器进行计算，即通过一个标识来兼容两种开播模式。67.所述步骤s20中，所述配置支持服务层的参数具体为：68.配置支持服务层包括规则引擎服务、告警通知服务以及计划服务的微服务；69.配置所述规则引擎服务具体为：配置规则引擎触发的sql条件语句以及规则参数；70.所述规则参数包括url、method、datatemplate以及sendsingle；所述method为put或者get；所述url用于标识数据获取的路径；所述datatemplate至少携带音频id、音频内容、音量大小、关联的终端id、播放次数；所述sendsingle用于标识数据是否发送成功；所述put用于执行对应动作或者将参数设置到应急广播终端中；所述get用于从应急广播终端中获取数据；71.在应急广播的应用中,put和get可以满足应急广播终端的功能需求，包括参数的设置、开/关播操作、ip话筒请求开播上报等，核心指令的get大多情况下基本就是获取心跳数据，心跳数据转换成参数/值的格式进行上报，上报数据为：设备id、工作状态、故障id；72.所述规则引擎服务为条件判断的应用，适合条件告警类的边缘计算，比如红外检测设备、人物识别设备、烟感检测设备，当判断接收到这些设备的告警信息上报时，立即做出处理并进行广播告警联动，不需要将信息回传到云服务器，再从云服务器发布告警指令给应急广播终端，大大提高了告警的响应速度。edgexfoundry的规则引擎是由设备到数据，由数据监测再到规则的，因此在创建规则就是从数据判断再到动作，规则引擎中需要写入判断数据的sql语句，例如在创建烟感联动的应用中，sql语句为select*fromsomkerwhereavg(concentration)》50，其中烟感的浓度concentration值是通过烟感的传感器实时上报的，上报间隔为100ms，存在redis数据库中的数据量为近20条，即两秒内平均烟雾浓度达到50以上时就会立即触发告警，告警的action条件为rest接口，其中有url，method，datatemplate,sendsingle四个字段，url是下发的commond接口地址，method方法是put，datatemplate为下发指令的数据模板，sendsingle值为true，这样就完成了一次烟感广播告警的边缘计算规则的绑定，当烟感2秒内检测烟雾浓度到达50后，就会立即触发相关的终端进行告警，规则中的参数是可以通过规则导出进行更新的，比如浓度检测要求在60以上，可以更新其中的sql语句为select*fromsomkerwhereavg(concentration)》60即可实现，不需要重新部署docker。73.配置所述告警通知服务具体为：配置告警触发时发送的邮箱或者手机号；邮箱需配置对应的端口port、服务器host、账号sender、密码password；74.所述告警通知服务为了让系统管理员可以接收到告警通知进行设计的，比如烟感检测到烟雾浓度到达一定值后，联动告警了相关的广播，并且通过告警通知服务，发送邮件或者手机短信到相关责任人的手机里。75.由于手机的通知服务不能进行封装在edgexfoundry内，因此提供了告警id，由外部服务进行处理，在发送告警restfulapi中附带上设备的id和相关参数(如状态码)即可，具体处理由云服务器进行。76.配置所述计划服务具体为：配置定时事件包括事件id、事件名称、开始时间、结束时间、对应定时广播的周期、需要触发的广播音频内容、restful的地址信息、音频调用接口、触发广播内容的定时参数。77.所述计划服务是一个边缘端的定时微服务，适合给定时广播使用，解决了脱离服务器定时、终端容量不够大、开播时间不准、开播不同步等问题，在edgexfoundry中的定时器是一个类型；所述计划服务的流程为：定时器-》触发计划-》数据库-》核心数据-》数据库。其中intervalaction(定时事件)就存在redis数据库中，第一次访问redis数据库为触发事件(遍历事件列表，满足条件的则触发)，第二次为调用事件后，更新redis数据库的信息(遍历事件列表，删除过期的事件)。78.所述步骤s20中，所述配置导出服务层的参数具体为：79.配置导出服务层链接的云服务器的地址以及同步数据；80.所述同步数据至少包括告警列表、应急广播终端运行监控表、广播列表、计划列表、规则参数、告警通知服务关联的邮箱或者手机号；81.所述告警列表至少包括告警发生的终端id、告警时间、恢复时间、告警广播id、触发源信息id；所述应急广播终端运行监控表至少包括终端id、上线时间、离线时间；所述广播列表至少包括广播id、广播开始时间、广播结束时间、广播内容；所述计划列表至少包括定时广播的开始时间、结束时间、触发周期、广播内容。82.所述导出服务层提供go语言的sdk包，数据调用后通过函数管道的封装(restful的api接口)，发送到微服务上，微服务经过一系列的函数筛选过滤，获取到提供相对应服务的应用进行调用，微服务再和云服务器进行数据同步。83.所述步骤s30具体为：84.边缘计算终端通过所述设备接入层的终端参数接入应急广播终端，实时获取应急广播终端的运行数据存储至所述核心服务层的redis数据库中，并更新所述运行数据的边缘计算标识。85.所述步骤s40具体为：86.所述支持服务层通过restful的api接口从核心服务层的redis数据库中读取运行数据，基于所述运行数据执行规则引擎服务、告警通知服务或者计划服务。87.所述步骤s50具体为：88.边缘计算终端通过所述导出服务层与云服务器建立连接，并周期性的通过restful的api接口进行数据同步。89.综上所述，本发明的优点在于：90.1、通过在边缘计算终端上搭建包括设备接入层、核心服务层、支持服务层以及导出服务层的边缘计算平台，通过设备接入层接入应急广播终端，获取应急广播终端的运行数据并存储至核心服务层，支持服务层基于核心服务层的运行数据执行对应的微服务，并通过导出服务层与云服务器建立连接进行周期性的数据同步，即将原本需要云服务器进行计算的任务下移到边缘计算终端，通过边缘计算终端进行规则引擎服务、告警通知服务或者计划服务的微服务，再定期与云服务器进行数据交换，无需到云服务器上进行一系列的跳转处理，无需对云服务器进行扩容，无需降低应急广播终端的计算量，最终实现在不大幅增加成本并保障应急广播质量的前提下，极大的提升了应急广播计算的响应速度。91.2、通过创建守护进程脚本，保护边缘计算平台的进程不被破环和中断，进而极大的提升了边缘计算的稳定性。92.3、通过go编程语言搭建边缘计算平台，不仅减少了空间占用，加快了运行速度，还与用于发现和注册设备的consul服务采用相同的编程语言，使得配置修改更加高效，无需像c语言一样下载安装多种支持库。93.4、通过创建redis数据库用于存储核心服务层接收的运行数据，即使用redis数据库作为持久化存储的数据库，由于redis是一种内存虚拟化存储数据库，存取效率高，随着数据量不断的迭代，暂用的内存也会随着变大，在边缘端的边缘计算终端的数据量比较小，因此，不需要担心存储迭代的问题，只要在暂用内存限制中配置好边边缘计算终端内存的上限即可。94.虽然以上描述了本发明的具体实施方式，但是熟悉本
技术领域：
：的技术人员应当理解，我们所描述的具体的实施例只是说明性的，而不是用于对本发明的范围的限定，熟悉本领域的技术人员在依照本发明的精神所作的等效的修饰以及变化，都应当涵盖在本发明的权利要求所保护的范围内。当前第1页12当前第1页12