发控设备软件通用化技术实现探讨

赵伟忠 丁小芩

上海机电工程研究所， 上海 201109



发控设备软件通用化技术实现探讨

赵伟忠 丁小芩

上海机电工程研究所， 上海 201109

针对发控设备软件研制的现状，分析了存在的问题，结合软件业内的成熟做法和成功经验，提出了如何实现发控设备软件的通用化，从而有效提高发控设备软件生产效率以及有效保证发控设备软件质量。

发控设备软件；通用化技术；软件架构

发控设备软件(以下简称发控软件)是指与发控设备相关的软件，大多数属于控制软件，运行在嵌入式芯片上，具有如下的技术特点： 1)以C语言为主的嵌入式软件； 2)开发、联试周期长； 3)复杂接口、复杂流程和复杂时序要求； 4) 高实时性； 5) 高安全性 ； 6) 高可靠性。随着战术型号领域的跨越式发展，在研型号任务越来越多，意味着多个型号的多款发控软件同时开始工程化开发，对发控软件人员的需求出现了急剧增长，现有的发控软件人员储备已经疲于应对，急需寻求解决办法。如何实现发控软件的通用化，从而有效提高发控软件生产效率以及有效保证发控软件质量，是值得探讨的问题。

1 型号软件开发现状

按照软件实际运行环境分类，发控软件配置项大致可以分为基于VxWorks操作系统的产品软件、基于DSP平台的产品软件以及基于Windows操作系统的产品软件，其中，基于VxWorks操作系统的产品软件一般是功能最为丰富、设计最为复杂的软件，本文以基于VxWorks操作系统的产品软件为例加以说明。

一般来讲，各型号的发控软件工作模式有相似性，都是在上级系统的指挥下，根据通信报文进行数据分析、模型解算，进而完成对下级的数据传递、对设备的自动化控制等。

总体来说，随着X86，ARM，PowerPC等先进嵌入式硬件平台的广泛应用，基于实时多任务嵌入式操作系统VxWorks进行开发的产品软件也越来越多。在软件规模方面，1套发控软件大约会包含4个左右产品软件配置项和6个左右模拟器软件。每个产品软件代码行数从3000～20000不等。

在研发模式方面，现阶段，一个型号对应一支软件队伍，如图1所示。软件研发均以型号为主线，各型号软件产品的开发由各型号的设计师团队单独完成，贯穿了设计、开发、调试、测试和维护等软件全生命周期，即以型号为牵引、以软件工程化管理为核心的研发模式 。

图1 目前的型号软件研发模式

2 存在的问题

目前发控软件研发主要存在以下问题：

(1) 生产效率低，人力资源矛盾突出

生产效率低的核心原因是各项目各自为战，相互间没有共享设计成果。每个型号软件都要独立完成软件开发的各个步骤，软件设计各自为战，软件复用能力低，开发周期长，而每个型号针对每个软件配置项均需要配备一个软件设计人员，一旦型号任务多，则型号兼项情况严重，软件设计人员任务负担过重。

(2) 质量难以保证

以型号为主线的管理模式，导致各型号的设计师团队相互沟通较少，缺少共同探讨的学习平台，产品设计水平的高低主要由型号设计师的设计能力和经验来保证，无法借鉴其它型号的设计经验和优秀设计模式，容易造成软件设计质量参差不齐，软件质量较大程度依赖于个人水平，从而影响产品的可靠性、维修性和通用性。

(3) 可扩展差

软件产品可扩展性差的主要原因是软件产品在设计之初没有充分考虑拓展需求，也没有充分考虑软件整体架构。深层次的原因是各软件项目在需求分析时各自为战，对需求分析没有挖掘充分和在广度上拓展，导致后期出现需求变更时改动量大，灵活性差，不便于功能扩展。

(4) 软件测评效率低

每个型号都要完成独立的测评，因为没有形成独立的复用函数或者代码库，对于部分复用的代码依然要完成全部的测评。

(5) 后期维护困难(特别是人员变更以后)

多数型号软件是依据设计师个人思路和逻辑形成代码的，缺乏统一的、整体性框架的约束，在型号研制后期或者批产阶段，如果相应设计师换人，对原代码的熟悉是一个漫长而痛苦的过程。

(6) 难以创新

难以进行高层次创新的主要原因是缺少高层次的决策指导。不断创新是航天工程持续发展的不竭动力。以往，每个软件项目都是以满足上级任务书要求为基本目标，加之时间、人手的限制，很少主动去考虑技术创新，并且有大量低层次的重复劳动。长此以往下去，会造成技术停滞不前。

3 解决思路

首先观察一下整个软件行业，在解决代码复用的问题上，目前业界普遍在用3种不同层次的方法：代码模式(函数模式)、设计模式和架构模式。以下分别针对3种模式分析用于型号发控软件研发的可行性和意义。

3.1 代码模式

代码模式(函数模式)主要指函数的复用，目前已开始运用，但是局限在一些细节层面，整体利用率低，因为函数是最基本的复用单元，如果没有统一的规划，单纯进行函数复用，很难提高整体复用率。例如某型号的发控软件的函数复用率仅为3%左右，具体数据如表1所示。

表1 函数复用率具体数据举例

3.2 设计模式

设计模式是对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述。它确定了所包含的类和实例，它们的角色、协作方式以及职责分配。每一个设计模式都集中于一个特定的面向对象设计问题或设计要点，描述了什么时候使用它，在另一些设计约束条件下是否还能使用，以及使用的效果和如何取舍。因为设计模式描述的是面向对象设计，其实现语言是C++、JAVA等主流面向对象编程语言，而不是过程式语言。目前经典的设计模式共包含23个(如抽象工厂模式、适配器模式、观察者模式等)。设计模式可以帮助人们运用对象、接口、类和继承之类的概念写出灵活的、可复用的软件。

目前的型号发控软件基本都是在VxWorks或DSP下使用C语言开发的，如果引入设计模式，需要采用面向对象的设计方法和面向对象设计语言，目前整个航天的软件工程管理需要做一定的调整。这是一个发展方向，也是需要比较漫长的过程。

3.3 架构模式

软件体系结构通常被称为软件架构，指可以预制和可重构的软件框架结构。软件系统的架构也被描述为软件组件与组件之间的交互。软件的架构设计是软件的核心，任何一个软件都有其架构，区别在于架构的好坏。总结来说，软件架构的主要特点如下：

1) 软件架构(Architecture) 不是软件，而是关于如何设计的决策；

2) 框架 (FrameWork) 是软件架构的代码实现；

3) 架构是关于如何划分系统，及各部分如何交互的；

4) 架构是系统的高层次策略，可作为具体软件体系结构的模板；

5) 已经成熟的软件架构模式包括十多种，如分层模式、仓库系统知识库模式和过程控制模式等。

如果说函数是砖，设计模式是墙体，那么架构是整栋建筑的框架。一旦将整栋建筑的框架设计好，在这个基础上灵活地增加墙体和砖，就像软件的二次开发和扩展，是比较容易的事情。也即，只有将软件的架构设计好，才能研发出通用性好、扩展性好、复用率高和代码质量高的软件，才能进一步地进行功能创新。

综上所述，基于通用架构的软件复用是最高层次、最具效率、能最大范围规范产品质量的复用模式。在型号发控软件通用化研发方面，应当采用基于通用架构的软件复用方式进行研发，以最大程度提高软件的复用率和质量，保证发控软件的生产效率。

4 具体方案

依据软件架构设计思想，必须结合型号嵌入式软件的自身特点，有针对性地进行型号软件的通用化软件架构的设计。

现在研发的基于VxWorks系统的发控软件一般有如下特点：

1)操作系统VxWorks提供底层BSP支持、中断处理、多任务调度和任务间通信等支持，其wind内核保证任务间切换时间严格限制在毫秒级，且任何时刻系统的状态都可预测；

2)驱动程序一般由硬件开发商提供，负责处理与底层扩展板卡的交互，包括网络、CAN、1553B、串口、DIO、DA、AD和定时器等。在运行时态上一般分为函数调用、中断处理和任务查询等几种方式；

3)产品应用代码更多地关注功能的实现，比如数据分析、算法解算和硬件自动化控制，从而完成发控设备的工作流程。性能上，要实现软件内部复杂逻辑关系的有序衔接，必须规划好任务间的时序，做好CPU的时间分配，多任务间资源的互斥保护等，最终依靠VxWorks操作系统的实时调度，保证软件运行的可靠性和可控性。

以上这点可以开发出性能出色的产品软件，但是不能保证某些设计师写出非常糟糕的代码，为整个系统的后期联调、试验埋下诸多隐患。因此必须在此基础上，做好通用化的软件架构，提升软件整体质量。而通用化软件架构的设计和行业的业务逻辑关系紧密，好的软件架构设计是建立在对业务逻辑、数学建模的充分理解之上的。

下面通过汽车电子行业标准的研究得到一些启发。

现代汽车功能创新不断、多样化差异化加剧，给汽车电子系统的研发提出更多创新、定制、快速上市的要求。AutoSAR标准就是汽车电子控制单元(ECU)软件研发的行业标准，也就是行业顶层通用化软件架构。该标准的架构目标就是能跨平台、跨产品复用软件模块，避免不同产品之间的代码反复开发等。

AutoSAR标准的关键设计思想之一是将应用层、服务层、ECU抽象层和微控制器抽象层的分离。其中，微控制器抽象层包括与微控制器相关的驱动，封装了微控制器的控制细节，使得上层模块独立于微控制器。ECU抽象层，将ECU结构进行抽象、封装，该层的实现与ECU硬件相关，但与控制器无关。服务层提供包括网络服务、存储服务和操作系统服务等系统服务，与平台无关。应用层包括各种应用程序，与硬件无关。具体如图2所示。

图2 汽车电子行业标准(AutoSAR)

这样的分层模型，将一个大型软件按实现功能不同分成了若干个能力单元，并归入不同层中。这样在面对不同的应用需求时，可以在每个分层中都做到最大程度的复用，而且各层之间的关系耦合度低，只要层与层之间的接口不变，改变某层的内部代码，不会影响其他层的运行。借鉴外部经验，通过对发控设备的业务流程的分析，基于VxWorks的型号软件通用化架构非常适合采用分层模型。

总的来说，以VxWorks操作系统为平台，发控软件架构设计可以分为5层，自底向上分别为：

第1层——驱动层：相关硬件驱动。负责处理与底层扩展板卡的最基本交互，主要是包括网络、CAN、1553B、串口、DIO、DA、AD和定时器等芯片的初始设置、寄存器的操作等。在运行时态上一般分为函数调用、中断处理和任务查询等几种方式；

第2层——驱动管理层：调用驱动层的函数或者任务实现不同的通信功能或硬件动作，比如网络/串口/CAN/1553B的初始化、数据发送和接收，DIO，DA，AD的数据读取与赋值等；

第3层——数据解析层：将从驱动管理层接收到的报文解析后形成有定义的数据发送给过程层；将从过程层接收到的数据装订成报文发送给驱动管理层。数据解析层只负责数据的解析和传递，与硬件和驱动无关。报文的解析是可以根据不同的通信协议灵活定制的。该层的数据解析还包括了任务间的数据传递和解析；

第4层——过程层：也可以解释为最小执行单元层，系统工作流程被细化成最小执行单元，这些最小执行单元对于不同的型号来说，应当是相同的。比如目标的加电、自检、发射单步步骤、IO读写和故障检测等。最小执行单元被主控层调用；

第5层——主控层：负责根据不同型号的工作流程将最小执行单元组织起来，完成特定的功能，这一层是根据不同型号的需求个性化定制的，包括与运行机制相关的功能。

基于VxWorks的发控软件通用架构5层模型如图3所示。

图3 通用软件架构五层模型

在数据传递和软件时序控制方面，架构设计要充分考虑中断、任务调度、内存分配等因素，遵循数据传递的松耦合性、时序运行的可控性原则，定义数据传递规则和流程，确立任务调度关系，从而将软件的整体运行框架固化。

分层模型首先就要解决数据传递的问题，主要包括层与层之间的数据传递。在5层模型中，层与层之间的数据传递要制定统一的协议，数据格式也要统一，这样能保证个别层中发生更改，在数据接口不变的情况下不影响其他层。在数据传递机制上，各层大多以任务的形式在内存中运行，任务间要实现松耦合，可利用VxWorks的消息队列或管道机制实现数据传递[1-2]，必要时可以对消息队列或管道进行二次封装。

在软件运行时序控制上，整个软件是以主控层为核心运行的。主控层以任务方式运行，其基本调度模式有2种：1)靠定时器激励的定周期模式；2)靠外部消息激励的非定周期模式，包括外部报文、故障信息和任务间消息等。另外，驱动层以函数调用方式运行，是依靠外部激励或者驱动管理层的调用运行的。驱动管理层以任务方式运行，依靠外部数据进行激励，外部数据包括中断处理、数据解析层传递的数据等。数据解析层以任务方式运行，依靠外部数据进行激励，外部数据包括驱动管理层、过程层传递的数据等。过程层以函数调用或者任务方式运行，依靠主控层的调用或者数据解析层传递的数据进行激励。

两者结合起来的情况如图4所示。

以上给出了通用发控软件架构的分层模型、数据流关系、时序控制逻辑，基本确定了一个发控软件的核心，这样的架构可以普遍应用于基于VxWorks的发控设备的产品软件中。依据这样的软件架构可以生成最基本的软件框架代码，这是对于各个型号、各个软件都可用的软件代码。然后在此代码的基础上，进一步开发个性功能的本地化，最终得到型号发控产品软件。通过这种研发模式，实现软件架构的框架代码被复用到各个型号，提高了代码复用率，规范了各个型号的软件，也保证了代码的质量，实现了发控软件产品化。

5 管理模式改进

在项目管理方式上，由面向单项目管理改进为项目集管理，设定项目集经理进行顶层管控，在各项目之间统筹人力和知识资源，促进设计成果共享，协同完成各个项目。做好项目集管理的核心是各种资源的统筹复用，其中包括知识复用和人力复用。要实现知识复用，包括设计成果的复用，最好的方法就是发控软件产品化，复用到各个型号中；要实现人力复用，需要对应的组织架构支持和考核办法跟进。

图4 通用发控软件架构数据流和时序图

6 结论

目前面向多项目的发控软件研发模式还缺乏足够的实施案例，尚处于初期的研究与应用中，虽然推广这样的研发模式非常具有价值，但是鉴于传统的习惯做法和严格的规范要求，这种模式被广泛接受和采纳还需要时间。但型号软件研发面临的局面迫使管理者必须做出选择，随着应用的推广，该研发模式最终将被软件工程化规范接纳和吸收，成为指导所有型号软件研制的依据之一。另外，如果在硬件设计、作战流程设计及通信协议设计上考虑周全，不同型号间做到充分复用，那么不同型号间就可以实现软件需求上的充分复用。

[1] 王雷,樊晓桠,王党辉.龙芯3A平台VxWorks移植的研究和实现[M].西安：微电子学与计算机，2012，2.(Wang Lei，Fan Xiaoya，Wang Danghui. The Research and Realization of VxWorks Transplant for LongXin 3A Platform[M]. Xi’an：Microelectronics & Computer，2012，2.)

[2] 陈智育,温彦军,陈琪.VxWorks程序开发实践[M].北京：人民邮电出版社，2004，5. (Chen Zhiyu，Wen Yanjun，Chen Qi. The VxWorks’ Program Development Practice[M].Beijing: Posts and Telecommunications Press，2004，5.)

Research of the Generalized Technologies for the Software of Launch-Control Equipment

Zhao Weizhong1，Ding Xiaoqin2

Shanghai Electro-Mechanical Engineering Institute, Shanghai 201109, China

Theexistingproblemsaboutthestatus-quoofthedevelopmentofthelaunch-controlequipmentsoftwareareanalyzedinthispaper,whicharecombinedwiththematurityandsuccessfulexperienceofthesoftwareindustry.Thesolutionproposedishowtorealizethegeneralizedtechnologiesofthelaunch-controlequipmentsoftwareinordertoimprovetheproductivityofthelaunch-controlequipmentsoftwareandeffectivelyguaranteethequalityofthelaunch-controlequipmentsoftware.

Launch-controlequipmentsoftware;Generalizedtechnology;Softwarestructure

2015-12-07

赵伟忠(1970-)，男，江苏南通人，硕士研究生，高级工程师，主要研究方向为武器系统软件总体设计；丁小芩(1987-)，女，安徽潜山人，硕士研究生，工程师，主要研究方向为武器系统软件总体设计。

TP311.52

A

1006-3242(2016)03-0077-06