首页 > 论文范文 > 工程工业论文 > 军事技术论文 > 武器工业论文 > 简析移动终端火控系统软件架构对空降兵武器装备的影响

简析移动终端火控系统软件架构对空降兵武器装备的影响

2020-05-06 343 上传者：管理员

摘要：为了解决传统火控车载终端软件架构无法满足空降兵武器装备小型、轻量、携行的需求，提出了一种基于移动终端的火控系统软件架构，充分发挥移动终端的特点。IMDA通过改变通信机制、改进交互理念、使用函数调用等方式解决了移动终端硬件资源受限的问题，弥补了车载终端交互效率低下以及多App之间的信息交互问题。并通过接口匹配法和半实物仿真相结合的方式验证IMDA架构的可行性和有效性。

关键词：
交互设计
武器装备
火控系统
移动终端
软件架构
通信机制
加入收藏

现役空降兵火控系统基于陆军体制进行适配，采用车载终端，未从空降体系对装备小型化、轻量化、携行化的特定作战需求统筹考虑。战士在空降以后，必须寻找炮车、登上炮车才可以执行作战任务。而使用移动终端战士可以使用移动终端对所有炮车进行定位，合理规划、动态接入距离最近的炮车，实现车下远程操控，完成作战任务。而且随着现代战争战场环境日益复杂，陆军火控系统也要求装备小型、轻量、携行，以应对不同的作战要求。使用手持无线移动终端代替传统的车载火控终端^[1]，成为了火控系统发展的一个必然趋势。

车载终端火控系统软件架构参考MVC（模型（Model）、视图（View）、控制器（Controller）），采用将视图与控制器分离的模式设计，但由于车载终端与移动终端在硬件条件、交互方式、使用环境等方面有很大的不同，其软件架构并不能直接适配于移动终端中，移动终端火控系统尚缺乏一种较为完备且通用的软件架构。面对这种问题的出现，同时兼顾移动终端的特性，基于此，本文通过设计划分原有火控系统功能软件、改变通信机制、分析移动终端的交互特性及具体需求，提出一种适用于移动终端的以交互层（Interaction）、中介层（Mediator）和数据访问层（DataAccess）为框架的火控系统软件架构。

1、移动终端与车载终端的对比

1.1 硬件资源

移动终端与车载终端相比，硬件资源更加受限，主要表现在：屏幕的大小、数据存储能力、计算能力、电池的容量以及通信的成本等方面。传统车载终端软件架构参考MVC模型^[2]，如图1所示，采用将视图与控制器分离的软件架构。

图1 MVC架构模型

这一设计在车载终端中的优势是，保证了系统构建的低耦合性，提高了程序的灵活性和可维护性。但在移动终端中会大大增加程序的代码量，并且，视图与控制器两个组件之间的大量传递数据，会耗费一定的时间，无法满足移动终端快速语义反馈的需求；另一方面也会增加两个组件之间的通信数据量，增大软件系统的功耗，无法满足移动终端低功耗的需求。

1.2 交互设计

车载终端使用屏边按键作为唯一的输入方式，既不同于人们常用的计算机鼠标键盘输入，也不具备移动设备的触屏输入，不能对交互对象进行直接准确的选择，战士需要将任务信息抽象成设备可以识别的模式进行操作，只能通过上移下移等二维操作进行选定对象，大大降低了任务操作中的效率，无法满足移动终端操作简单、学习成本低以及交互高效的需求^[3]。

移动终端更贴近战士的生活，有较低的学习成本。战士只需要在交互界面上进行点击、滑动等操作，由移动终端将信号转化为设备可识别的指令信息，完成操作。如图2所示。

图2 车载终端与移动终端的人机交互方式对比

1.3 功能划分

终端将所有战术功能集成为一个软件，导致易用性较差，战士完成所有的任务都需要从主界面开始，一步一步地进行操作，交互流程复杂且冗余，无法直接定位到想要看到的信息、想要执行的操作。

移动终端根据任务之间的关联性，更科学的将作战流程划分为多APP的设计，如作战应用、系统维护、报文管理、地图导航等，任务多具有临时性。故车载终端无法满足移动终端多任务之间的数据共享、任务迁移以及多APP间的相互调用和资源互斥管理的需求。

2、拟采用的解决方案

2.1 通过改变通信机制解决资源受限问题

在车载终端的软件模式中，各个组件之间采用直接通信，而且移动终端采用图形界面与手势输入相结合的交互方式，具有高连续性，紧密的输入输出的特点，如果采用原有通信方式，会给系统带来极大的通信负担。

在移动终端的软件架构中，对原有的MVC模型进行改进，将视图与控制器结合，以此适应移动终端手势输入交互模式下，输入输出过于紧密的特性。在层与层之间的通信采用事件全局广播与粗粒度通信相结合的通信方式，采用事件全局广播的设计，使每一层不需要时刻监视各个组件的当前状态信息，而是可以对相应的组件广播进行注册，这样就可以接收到组件的状态信息，从而作出响应。粗粒度通信可以大大降低系统复杂度，因为移动终端采用手势交互，所以用户的操作具有连续性。例如用户在屏幕上用手指划出一个不规则的轨迹，如果采用细粒度通信，系统需要轨迹上每个点精确地计算出坐标位置，然后构成完整的操作轨迹，这样的通信开销对于移动终端而言是无法接受的。

2.2 采用“所见即所得”的理念进行交互设计

所见即所得是这样一种状态：你在屏幕上看到的就是结果，即用户不需要过多地考虑，进行保存设置或编辑以后应该是什么样子直接可以呈现在屏幕上^[4,7]。例如对一个复选框进行操作，直接勾选即可自动保存，不需要再点击“保存”或者“应用”^[10]。

移动终端的交互设计具体包括以下几个方面：

1）可学习性

用户在已有知识和经验以及系统提示或帮助的基础下，无需花费过多时间思考即可正确理解交互界面，可学习性主要是指：了解当前界面能够进行哪些操作，接下来能进行哪些操作并且能够快速辨别界面中的组件并明确其具体功能。

2）一致性

在相似的场景下，一方面要与生活中移动设备的APP保持一致，另一方面不同的界面中保持一致。主要体现在以下方面：视觉效果、交互行为、操作结果。保持一致性可以降低用户的学习成本。

3）及时反馈

当用户对界面组件进行任何操作后，都应及时给予反馈，让用户了解操作是否生效。反馈的内容主要是指：用户操作反馈和元素状态反馈。用户操作反馈是指界面中的元素在用户执行操作时元素的变化反馈；元素状态反馈是指，当被操作元素运行中需要用户等待或者出现错误时的反馈。

4）容错性

软件应允许用户操作错误，并在犯错后给用户重新尝试的机会。在设计交互时，要尽量帮助用户避免犯错，在交互过程中给予用户帮助或者提示。当错误发生后，需要提供撤销返回功能，使用户返回至上一步重新进行操作，并给予相应的提示。

2.3 通过函数实现App间的跳转及数据传递

在移动终端的环境下，用户需要对多个app进行操作来完成一个完整的作战流程。例如，在报文管理app中收到报文信息后跳转至作战应用app使用报文信息进行下一步操作，在这个过程中两个关键的需求是实现app间的相互调用以及数据传递。实现app间的交互和通信，最常见的是使用Intent函数。Intent函数负责对app中一次操作的动作、动作涉及的数据进行描述，操作系统根据此描述找到对应的app，将Intent传递给被调用的app。这个方法的缺陷是当涉及两个以上的app交互时，数据传递效率低下，每一级传递都需要进行读取，重新写入Intent函数的操作，而采用Bundle函数进行数据传递时，只需要将Bundle传递即可，所以本架构采用Intent函数进行app间的跳转与Bundle函数进行数据传递相结合的方法。

3、软件架构模型详细设计

本文从传统车载终端软件架构借鉴的同时，考虑到移动终端的特定需求^[6,8]，结合民用移动平台的发展趋势^[5,9]，基于安卓操作系统，提出了IMDA软件架构模型，将软件系统分为3个层次，如图3所示。

图3 IMDA软件逻辑架构分层图

交互层I主要由View、Activity和XML文件组成。负责和用户直接进行交互。主要由两方面的功能，一方面是用户通过手势交互，将信息输入，交互层获取用户输入的信息。另一方面，交互层将软件系统的处理结果输出显示给用户。将输入与输出结合，采用粗粒度通信的机制，并将用户界面切换的逻辑放在交互层，减少与底层的通信，以此来满足移动终端对通信和能耗的高需求。一个应用中有多个Activity,Activity使用方法setContentView调用对应得View显示在屏幕中。

每一个Activity都可以使用方法startActivity启动其他的Activity，从而满足用户的切换功能。当用户执行操作时，一个新的Activity启动，原先的Activity会暂时挂起，放入后台栈中，遵循先进后出的原则，当用户完成操作后，返回原先的Activity。在View中注册并绑定事件监听器，如果XML文件发生变化，Activity会重新加载View。Activity通过Bundle函数进行通信，提高传输效率。事件转换器用于实现语义的转换，将低级的、具体的用户事件转换为高级的、抽象的计算机可识别的指令，把指令传递给中介层的事件处理器进行处理。

中介层M由多种算法以及事件转换器组成，算法包括处理接口与各类数据的交换、对进程的控制及处理app间的交互和通信。事件转换器主要负责接收交互层传递的抽象事件，将其分解成统可执行的原子命令，并进行封装。进而调用数据访问层的接口，实现后台的方法间的映射关系，完成进程控制和语义转换。

数据访问层DA主要包括数据部分和逻辑部分，逻辑部分核心为事件处理器，主要负责处理数据、执行后台服务、完成系统的业务逻辑。具体表现为实现用户所操作的功能，接收由中介层传递的数据并进行处理，最终由交互层显示给用户；数据部分主要负责存取所涉及的各种数据、配置文件。数据流程如图4所示。

图4 数据流程图

4、IMDA软件架构验证方法

对于软件架构的验证而言，国内外还没有成熟的验证方法，因为软件架构是软件系统的最顶层的设计，是整个软件的框架。所以本文采用接口匹配法和半实物仿真相结合的方式来进行验证。

接口匹配法验证步骤：

1）抽象IMDA软件架构，确定最小功能组件的接口与外部的连接关系；2）对最小功能组件进行功能、交互模拟，是其具备正确的响应关系。

此方法是软件架构阶段最直接、最简洁的验证方。后期采用半实物仿真试验，运用的半实物仿真试验结构如图5所示。待测单体为移动终端，通过无线自组网与火控系统机箱相连，执行基本操作流程，通过外围模拟工装查看是否可以完成操作，如果有问题，通过串口调试线以及CAN盒查找问题所在。在编码完成之后进行综合验证，采用相同环境进行闭环试验。这样，对系统前期、后期分别进行验证，软件开发过程中采用软件测试方法进行跟踪测试，使软件架构的稳定性得以保证。

图5 半实物仿真试验结构图

5、结论

由于现有车载终端软件架构在移动终端移植中的种种缺陷和填补现存火控领域移动终端的空白，本文提出一种基于火控领域的移动终端软件架构IMDA。通过改变通信方式克服移动终端的局限性，并集成化解决了移动终端资源受限性、交互方式及多APP交互问题。最后提出了IMDA软件架构的验证方法。试验表明，此架构能够适配与移动终端的开发，提高开发效率，为武器装备的小型化、轻量化、携行化提供基础。

参考文献：

[1]谢大勇.掌上智能终端对军事信息技术的影响[D].长沙:国防科学技术大学,2012.

[2]田嘉乐.基于可用性模式的移动软件架构研究与实现[D].西安:西北大学,2014.

[3]王俊.面向可用性的智能手机软件交互设计研究[D].西安:西北大学,2011.

[4]王子甲.移动计算中交互范型和软件架构模型的研究[D].西安:西北大学,2013.

[5]李晓燕,王立冬,郭金良,等.电子战三维视景软件适应性架构设计[J].电光与控制,2014,21(4):86-90.

[6]盛大同.关于预警机任务系统的软件架构研究[J].中国电子科学研究院学报,2016,11(2):182-186.

[7]郭翠,华庆一,郭亚维,等.基于服务的移动用户界面软件架构研究[J].计算机应用研究,2011,28(11):4180-4183.

[8]张闻乾,王琳,李国玉.某无人直升机的软件架构设计[J].测控技术,2010,29(7):65-67.

[9]高晶.校园业务中混合模式移动应用软件架构的实现[J].中国信息技术教育,2015(Z2):119-121.

[10]林嘉怡.大数据时代移动终端界面设计创新趋势研究[J].包装工程,2017,38(2):239-242.

刘宇轩,宋跃进,张振华,霍文健,段宇江.基于空降兵的移动终端火控系统软件架构[J].火力与指挥控制,2020,45(02):166-169.