灾难环境下的Mobile应用构建及部署

灾难环境下的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)我们必须配备大功率的电池,并且配备手机电源伴侣,能够让PDAGPS等电子设备坚持72小时以上。

2)并且配备各种充电设备,增强电子设备的可用时间,考虑太阳能、汽车电源、发电机等备用充电方式。

2,  网络

已有数据网络,比如有线网络、GPRSCDMA等肯定会被摧毁。

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作为每条记录的唯一标记ID2,使用时间戳来判断记录是否为新。

2)  Server进行数据同步

在进行数据交互之后,Mobile设备的信息还是需要与Server进行交互的。途径有两种:1,当救援人员从灾区出来时,有无线或有线网络被发现时,系统会自动上传未上传信息(至少有些救援人员是穿梭于灾区与后方之间运送物资的,使用他们的设备作为信息载体,将信息进行及时后送是可行的);2,架设临时的数据传输系统,比如卫星地面站,成本会比较高。

 

 

待解决的问题

我们无法预知下一次的灾难是什么样子的,所以救灾系统的最大敌人就是——时间。我们无法根据已知需求来针对下一次灾难来部署IT系统,只有在灾难发生后的几个小时迅速根据已知情况来进行部署工作,然后在随后的几天时间中逐步修改已有系统。如果某个功能需要两周时间来实现,对于灾难情况下的IT系统来说,是没有任何价值的。

所以我们尽可能做的是:

1,  依赖现有系统

比如GoogleLive使用已有系统来搭建灾情信息系统,尽管实际作用有限,不过已经是可喜的第一步了。目前很多网站都提供二次定制的API,这将是我们可以利用的宝贵资源;

2,  组件化、模块化

预先开发救灾系统的某些模块,根据具体需求进行定制或分类部署;

3,  可定制性

根据现场需求定制某些模块中的特殊功能,比如增加新的数据信息分类等;

4,  可修改性

一旦发现现有救灾IT系统不符合实际要求,开发人员能够在很短时间内进行修改,将修改之后的软件进行再次发布。

 

也许这一切都是纸上谈兵,但是IT的意义就于让信息交换更加顺畅、有序,而在灾难的背景之下,信息的正常传递就显得尤为重要。

保证已有IT系统的正常运行,并将其快速转入灾难体系,参与到灾难救援过程中,其实是我们之前很少考虑的一个问题。有个很简单的例子,我们经常在做系统设计时,说到网络连接,随口就是GPRS/CDMA,可是在灾难背景下,这一切都不存在了。GPRS/CDMA不存在了,网络就不存在了吗?错,我们还有蓝牙。于是,我循着这个思路,写了上面的文字,期望对面对下一次灾难的救援有所帮助。尽管很不成熟,但我认为有实现的可能。

借用这次灾难中的一句名言作为结尾,期望灾区的人一切都好:

所谓奇迹——就是你修房子时能在十年前,想到十年后的事情。


本文转自马宁博客园博客,原文链接:http://www.cnblogs.com/aawolf/archive/2008/05/20/1203557.html,如需转载请自行联系原作者

上一篇:正则匹配指定字符之间的内容,并替换(多个匹配替换)


下一篇:3.5 tensorflow 中LSTM和GRU模块使用意境级讲解