灾难环境下的Mobile应用构建及部署
写下这个题目绝对不是为了哗众取宠。看题目大家都会知道这篇文章的源头在哪里,的确地震之后,我一直有一种无力感。IT系统无法快速切换到灾难状态,于是,很多的信息管理又再次回到笔和纸的时代。但是,信息管理系统在灾难中其实更为重要,比如救灾物资的跟踪、发放,遇难人员身份确认和统计,GPS导航等等。尤其是我们的Mobile移动终端设备,其实能够发挥比平时更大的作用。
在这篇文章中,我试图思考一个问题:如何让我们的IT系统在灾难面前更加有效的运行起来?至今我没找到答案,不过,我希望能够让大家重视灾难环境下的IT信息管理。
灾难后还剩下什么?
逃出生天的人们往往会下意识地检查一下肢体是否还完整,同样,一个灾难过后的IT系统,我们也要首先知道,哪些部分可用,哪些部分不可用。首先是不可用的:
1, 电源:
前24小时将完全依赖电池或后备电源供电,24小时后可能会间断性电源或发电机供电;
2, 信息网络:
灾难核心区,有线网络将无法使用,边缘地区的网络将在24小时后恢复;依赖移动电信网络的无线网络将遭到毁灭性打击;
3, 计算机设备:
因为无法移动,所以在灾难过程中计算机设备会遭到摧毁,而之后的电源、网络等问题会造成信息孤岛。
可用部分:
1, 便携设备:
不依赖AC电源供电的PDA等设备更容易适应灾难后的环境,但要考虑电源问题。
PDA能做什么?
在便携设备中,PDA是最能适应灾难环境的电子产品,只要有相应的软件配置,就可以快速切换到灾难救援之中。工业标准的PDA(或EDA)本身就可以工作在野外环境中,对于灾难环境来说,硬件本身不是问题。PDA设备能够提供的功能:
1, 信息管理平台
可以完成灾难环境下的信息管理,如灾民统计、遇难人员统计、物资统计、物资发放明细记录;
2, GPS导航平台
外接GPS设备后,可以用于指示救援人员位置、记录被困人员位置、获取地理信息等;
3, 信息交换平台
配合RFID,作为信息交换平台,如交换救灾物资的信息,记录和快速浏览伤员情况等;
4, 图像采集平台
采集视频、音频和图片信息,如遇难者身份确认等;
5, 信息查询平台
用于查询遇难者信息、寻亲、救灾物资信息、灾情通报等。
PDA的限制和应对之道
尽管PDA是最适合救灾的信息设备,不过PDA也有其局限性,接下来,我们试图来想办法解决:
1, 电源
灾区不会有电,所以
1)我们必须配备大功率的电池,并且配备手机电源伴侣,能够让PDA、GPS等电子设备坚持72小时以上。
2)并且配备各种充电设备,增强电子设备的可用时间,考虑太阳能、汽车电源、发电机等备用充电方式。
2, 网络
已有数据网络,比如有线网络、GPRS、CDMA等肯定会被摧毁。
1) 我们可以搭建依赖卫星地面站的无线网络,卫星地面站可以完成与外界通讯,而无线网络可以完成某个覆盖范围内电子设备的信息交换。
2) 更为残酷的现实是,很多电子设备必须通过点对点通讯来完成数据交换。
3, 数据库
因为网络的关系,外界的中心数据库是无法访问的。
1) 使用PDA本身自带的移动数据库存储信息;
2) 使用RFID等标签设备存储信息,如病人的医疗信息等;
3) 在有机会的情况下,PDA通过网络和中心数据库进行信息交互,比如PDA设备被带出灾区时。
4, 外设
必须能够连接的设备如下:
1) GPS:
地理信息的获取对于救援工作的作用毋庸置疑,我们还需要能够标记等待救援人员的方位等信息;
2) 蓝牙、红外:
在外部网络不通的情况下,作为短距离通讯手段,即可以连接外设,又可以作为PDA之间的通讯手段;
3) RFID:
作为身份识别的重要载体,能够读取和写入信息,随伤员或救灾物品一起部署;
4) 摄像头:
作为统计灾情、遇难者身份确认的手段,我们可以通过摄像头、数码相机等留存证据,待灾后辨认;或者上传灾区信息,用于救灾决策。
移动救灾系统的功能
将来开发这套系统的程序员肯定会很郁闷,谁都希望自己的软件能够被使用,但是用这套软件的时候,就意味着灾难的来临。我们无法预测灾难,不过只要能在灾后起到作用,也就足够了。先来试想一下救灾系统应该包括的功能:
1) 现场救援
现场信息记录、与生命检测仪等系统互联,获取生还者信息,统计遇难人数、身份,绘制现场简图;
2) 伤员救护
配合带RFID的手环,记录伤员身份信息、伤病情况、救治情况、后续治疗建议,待后送之后,医生可以根据信息进行快速诊断、救治。如果配合电子病历系统,可以快速将信息导入医院管理系统中,方便之后的治疗;
3) 地理信息
使用GPS及地图系统,为救援人员指示目前方位、目标方位等信息,还可以记录待救援人员的位置,方便指挥系统进行合理的人员分配;
4) 物资管理
进行物资管理及分发,从中心数据库中获取物资信息:如种类、数量、目的地、运输方式等;运送到救助点后,进行物资发放的同时,收集受救援者的信息。留待灾后进行统计时,防止物资发放过程中出现的问题;
5) 灾情报告
对于救灾决策而言,获取灾情信息的报告也至关重要。统计受灾人数、遇难者人数、房屋财产损失、检疫卫生信息等,获取视频、音频、图片资料,及时上报。
6) 遇难者身份确认
遇难者身份确认也是历次大灾难中的难点,获取遇难者信息,如图片、身份信息、DNA信息等,配合RFID或条形码标签,然后录入数据库中,进行伤亡人数统计、身份识别等工作。
7) 寻亲
登记遇难者、伤者与幸存者的身份信息、所处位置,为幸存者提供亲属、朋友的查询服务。
移动救灾系统的设计架构
Mobile系统为了应对Offline状态,已经有了离线访问、本地数据缓存等机制,来保证数据完整性,但是在灾难体系下,这种机制还要继续深化:
1) 无Server状态下的P2P信息传递
在无法访问Server的情况下,Mobile设备之间应该具备点对点信息交互的能力。当处于同一区域的两台设备相互发现后,应该按照一定的规则进行数据交换,当信息交换频率达到一定密度时,所有设备的信息应该都是最新的。
所以,在设计数据库时必须保证:1,使用GUID作为每条记录的唯一标记ID;2,使用时间戳来判断记录是否为新。
2) 与Server进行数据同步
在进行数据交互之后,Mobile设备的信息还是需要与Server进行交互的。途径有两种:1,当救援人员从灾区出来时,有无线或有线网络被发现时,系统会自动上传未上传信息(至少有些救援人员是穿梭于灾区与后方之间运送物资的,使用他们的设备作为信息载体,将信息进行及时后送是可行的);2,架设临时的数据传输系统,比如卫星地面站,成本会比较高。
待解决的问题
我们无法预知下一次的灾难是什么样子的,所以救灾系统的最大敌人就是——时间。我们无法根据已知需求来针对下一次灾难来部署IT系统,只有在灾难发生后的几个小时迅速根据已知情况来进行部署工作,然后在随后的几天时间中逐步修改已有系统。如果某个功能需要两周时间来实现,对于灾难情况下的IT系统来说,是没有任何价值的。
所以我们尽可能做的是:
1, 依赖现有系统
比如Google和Live使用已有系统来搭建灾情信息系统,尽管实际作用有限,不过已经是可喜的第一步了。目前很多网站都提供二次定制的API,这将是我们可以利用的宝贵资源;
2, 组件化、模块化
预先开发救灾系统的某些模块,根据具体需求进行定制或分类部署;
3, 可定制性
根据现场需求定制某些模块中的特殊功能,比如增加新的数据信息分类等;
4, 可修改性
一旦发现现有救灾IT系统不符合实际要求,开发人员能够在很短时间内进行修改,将修改之后的软件进行再次发布。
也许这一切都是纸上谈兵,但是IT的意义就于让信息交换更加顺畅、有序,而在灾难的背景之下,信息的正常传递就显得尤为重要。
保证已有IT系统的正常运行,并将其快速转入灾难体系,参与到灾难救援过程中,其实是我们之前很少考虑的一个问题。有个很简单的例子,我们经常在做系统设计时,说到网络连接,随口就是GPRS/CDMA,可是在灾难背景下,这一切都不存在了。GPRS/CDMA不存在了,网络就不存在了吗?错,我们还有蓝牙。于是,我循着这个思路,写了上面的文字,期望对面对下一次灾难的救援有所帮助。尽管很不成熟,但我认为有实现的可能。
借用这次灾难中的一句名言作为结尾,期望灾区的人一切都好:
所谓奇迹——就是你修房子时能在十年前,想到十年后的事情。
本文转自马宁博客园博客,原文链接:http://www.cnblogs.com/aawolf/archive/2008/05/20/1203557.html,如需转载请自行联系原作者