用jxTMS开发智能转运箱（1）

本系列以开发管控类危化品的智能转运箱为例讲述了jxTMS的智能硬件支持下的业务管控体系：

用jxTMS开发智能转运箱（2）

用jxTMS开发智能转运箱（3）

jxTMS目前已打包为docker容器，可以下拉jxTMS的docker镜像并按jxTMS使用示例尝试使用。

开发背景

管控类化学品按公安部门的要求，必须集中保管，但其使用却是分布在各使用单位的，有的大学的化学实验室高达上千个，所以管控类化学品在使用时，必须从集中保管处运输到使用点，投料后再运输回集中保管处。相比可以严密设防的存储与使用地，管控类化学品的在途安全就成为公安部门要求补上的一个空白环节。

管控类化学品在途安全的核心诉求就是提高机防水平以弥补传统过于依赖人防的缺陷，确保：在化学品安全风险日益增大的当下，管控类化学品在途的人防加机防的综合防护水平足以打消潜在攻击者的攻击欲望。

也就是说，管控类化学品的在途安全不仅仅只是一个硬件防护的问题，还必须要纳入到管控类化学品安全使用流程的闭环管理中，和申领、投料、回库、计量等作业环节无缝衔接、相互验证、不留安全空隙，确保管控类化学品的使用安全。这方面恰好可以充分发挥jxTMS在业务管理、流程管控方面的强大能力，大家可参考jxTMS使用示例进行了解，本文不复赘述。

针对智能转运箱在转运过程的安全防护，我们的思路是把集中保管处和使用处等可按要求提前部署相当水准的安全防护系统的固定点，称为安全堡垒区，通过基站发送蓝牙信标进行标记。然后智能转运箱根据基站发送的安全堡垒区信标，实现对安全堡垒区的识别，进入转运目的地的安全堡垒区后自动解除保险，全程实现自动控制以避免人来开锁所具有的天然的高风险。

根据这一思路，我们分解出主要的工作任务：

• 用基站来标记安全堡垒区，在核验安全堡垒区符合相关制度所规定的安全防护标准后，必须在系统中通过审批流程的审批后自动指派基站进入工作状态。此后如掉电、断网等可能导致基站移动的情况出现后，基站自动切换到故障状态并告警，必须现场再次核验后才能在系统中复位其工作状态

注：在管理制度中分别对应基站开通流程与基站修复流程，jxTMS衔接这两个流程自动设置基站工作状态，以避免人为设置的风险

• 基站进入工作状态后，广播一个蓝牙信标，用于智能转运箱的测距，以判定智能转运箱是否处于安全堡垒区中；同时提供无线AP功能，用于智能转运箱登入后访问系统服务器，来走完整个转运流程

• 智能转运箱自动识别安全堡垒区的出区事件和【到达转运目的地的】入区事件，将两事件之间视为高危的在途状态，并自动布防：箱门锁闭，全程录像，开门与超时则高音警号报警；进入指定的安全堡垒区后，自动撤防：电锁开启、取消定时器、回库后自动上传录像文件等

• 智能转运箱没有手控操作点，报警后高音警号鸣叫，这时需要执行一系列专业而繁琐的消警处置动作，以增加攻击者的暴露时间

• 以转运和使用的分工界面为安全责任转移点，围绕安全责任的转移来设计转运流程，实现以智能硬件来保障管理制度的落地

注：本文主要讲解智能转运箱的软件实现，箱体防护与硬件设计不涉及。

jxTMS智能硬件支持下的业务管控体系

jxTMS的智能硬件支持下的业务管控体系是：

即jxTMS的智能硬件支持下的业务管控分为两个系统：

• 业务系统，即之前介绍过的jxTMS的业务管理部分，主要处理业务办理、业务流转、业务管控等管理制度落地的部分

• 智能硬件的控制系统，即对智能硬件的设备管理、事件报告、控制等

两者以目录服务为纽带进行勾连，可在业务过程中嵌入智能硬件的操作与反馈，从而强制规范操作以推动管理制度的落地、业务合规。

也就是说，jxTMS智能硬件支持下的业务管控的立足点是以智能硬件的防卡控来落地管理制度，即将智能硬件嵌入到业务过程中，确保数据采集、卡口防控、责任交接清晰准确而且不可绕过，从而以不可绕过、可追溯、可审计、责任明确来推动业务合规。

业务系统和智能硬件控制系统以目录服务进行勾连，前端智能硬件系统以事件的形式报告到jxTMS中，jxTMS以命令的方式下达管理指令。

智能硬件向的jxTMS报告的事件包括两类，一类是系统事件，包括：

• checkRegister：前端系统向jxTMS注册时触发，可在本事件的响应函数中对待注册的前端系统执行准入审查，如未通过审查，则可拒绝其注册

• register：jxTMS准许前端系统注册时触发本事件

• stateChange：前端系统报告状态变化时触发本事件

• del：前端系统失联时触发本事件

另一类是用户自定义事件。

这两类事件的响应处理都只需在用myModule.initAtLoad修饰的函数中用listenStateChange注册就好：

#用户自定义的transTaskReport事件的响应函数
def dualTransTaskReport(self,db,c,param):
	......

#initAtLoad修饰的函数在组织加载本模块【系统启动、管理员执行热机刷新操作】时，会被自动调用
@myModule.initAtLoad('initDevDual')
def initDevDual(self, org):
	#获取本组织的目录服务，没有则创建
	cs = catalogService.addCS2Org(org.getAbbr())
	#在此目录服务中注册事件响应函数dualTransTaskReport函数，用以响应transBox类型的设备报告的transTaskReport事件
	cs.listenStateChange('transBox','transTaskReport',self.dualTransTaskReport)

智能硬件向jxTMS报告transTaskReport也非常简单：

def _inform(self,active,msg=None):
	#ps是自定义的参数，就是响应函数dualTransTaskReport中所接收到的param
	ps = {}
	ps['type'] = self._type
	ps['name'] = self._name
	ps['taskOrder'] = self.taskOrder
	ps['active'] = active
	......
	#调用基础服务所提供的inform2CatalogService函数向jxTMS报告transTaskReport事件
	self.inform2CatalogService('transTaskReport',ps)

智能硬件系统主要包括三个部分：

• 设备管理，即该硬件所管理的前端软硬设备，如智能转运箱中的输入输出设备【Modbus RTU】、时钟等

• 作为目录服务的前端实现的系统管理模块，事件和jxTMS下达的命令执行都在这一部分实现，所以这一部分是智能硬件的主控与驱动模块。同时还提供了基础服务，如消息服务、shell调用、本地日志、远程日志、系统状态等

• 逻辑控制部件，主要用于实现本硬件的控制逻辑，jxTMS提供了状态机、模糊推理、序列捕获/模式识别、决策表等逻辑部件，智能转运箱只用到了状态机

智能硬件系统的实现包括两个层面：

• 设备管理【包括具体的设备功能实现】、消息、日志、逻辑部件等主要功能都是用go实现的，然后编译为so库

• 目录服务的前端以及系统管理等基本框架，是用python实现的，以CTypes方式调用so库加以整合后提供了智能硬件的系统框架