韦彩色 曹云峰

（南京航空航天大学航天学院 南京 210016）

1 引言

随着计算机技术和航空航天技术的快速发展，新一代飞行器任务日益增加，促进了其各系统规模不断庞大，组成结构不断复杂，对系统的设计要求不断提高。有关研究表明，大量系统研制项目的失败是由于不合格的需求信息导致的［1～2］。因此，在系统设计开发的早期，有必要先对系统的需求进行详细分析。

传统的需求工程方法由于基于文档形式而不能进行需求跟踪以及检查各种错误和冲突；而且文档偏向于自然语言的表达方式，容易造成需求表达不充分性和二义性；甚至文档的不可执行性，使得系统需求缺乏必要的验证手段，降低了系统开发效率和质量［3～4］。为解决这些不足，国际系统工程学会（INCOSE）联合对象管理组织（OMG）提出了“基于模型的系统工程”的思想［4］。该思想通过模型从不同角度全面展示系统需求的内容，消除信息表达的二义性，可视性强，修改方便，具有可执行性。

传感器系统是一种涉及电子、机械等多学科领域的复杂系统。它相当于飞行器的感应器官，负责采集飞行器的姿态、高度等信息，是飞控系统等系统做出控制的判断依据。随着新一代飞行器高安全性和高可靠性的要求，使传感器系统变得种类繁多、功能复杂、需求多变［5］。在传感器系统需求分析和验证上，目前的研究大多采用有限元分析、Simulink仿真等方法［6，9］对单个传感器进行分析，无法对系统的需求进行整体分析与集成验证。鉴于此，本文提出一种基于MBSE 的飞行传感器系统需求建模分析方法，辅以DOORS对其需求进行管理。

2 飞行传感器系统需求管理

正如上面所述，飞行传感器系统种类繁多、功能复杂，需求多变，有必要对其需求进行管理。直接从用户捕获得的需求在系统工程中被称为涉众需求，其存在信息表达的不明确性和二义性等问题，需将涉众需求翻译成系统需求，即明确系统必须做什么（功能需求）以及如何执行好（服务需求的质量），方便设计人员的理解［10］。它们往往以Word形式存在。本文采用DOORS 作为需求管理工具，DOORS 在需求修改历程的记录、需求变更、需求跟踪、与Word 等软件的集成等方面显示出很大的优势［11］。设计人员可点击Word 工具栏中超链接Ex⁃port to DOORS 图标将需求导入DOORS 中；也可手动输入需求。系统涉及的传感器种类繁多，功能多样，因此，在DOORS中可按照传感器种类或者功能来划分，以文件夹方式进行组织。系统中每个部件涉及需求内容复杂多变，其需求在DOORS 中以条目化、分层级结构存在［12］，如：第一级描述初始需求，第二级用于对初始需求进行筛选、添加等变更，以此类推，直到形成完整的、明确的需求描述。这不仅便于修改需求，而且提高了浏览的便捷性，方便设计人员与用户之间的沟通。此外，设计人员可借助视图、链接等功能，对飞行传感器系统的需求进行跟踪管理，避免某需求的遗漏和需求之间的矛盾冲突。

3 飞行传感器系统需求建模

为应对复杂系统需求复杂性和多样性的挑战，MBSE 思想已逐渐应用于需求工程，SysML 则作为系统建模规范的手段，以构建需求模型，通过模型的执行，实现对需求分析和验证［13］。Rhapsody是由IBM 公司提供的、支持SysML 的工具，其提供与配置管理工具、需求管理工具等集成的接口［14］。本文通过集成接口Gateway，将飞行传感器系统需求从DOORS 导入Rhapsody 中，便于在后续设计中确立需求的可跟踪性；采用SysML用例图对飞行传感器系统需求进行静态建模，从每个参与者的角度分析系统需求，逐层细化，获得需求的元模型，使不同背景的设计人员对需求达成统一认识和理解，便于后期设计开发。用例图是设计人员常用于分析系统的一种图型。用例模型包含参与者（Actor）、用例（Use Case）以及关联（Association）三个模型元素［15］。

从参与者的角度分析飞行传感器系统的功能性需求和非功能性需求。根据飞行传感器系统的特点，将参与者进行简单分类。主要分为以下四大类：1）消费者（客户）。表示使用飞行传感器系统的利益相关者；2）供应商。代表参与项目交付的所有利益相关者，又细分为：设计人员、维修人员；3）系统外部环境。表示以某种方式约束传感器系统的利益相关者，例如：飞控系统；4）质量监管部门。表示负责验收系统相关质量指标是否达标的利益相关者。

图1 各个参与者对应的系统需求用例模型

图1 显示从各个参与者角度描述飞行传感器系统需求的用例模型。例如：从用户的角度，主要要求是“获取飞行器信息、高可靠性、高稳定性、容错性、经济性”，其中飞行器信息包含“高度、姿态、位置、相关温度”等，“容错性”包含“具有自检测功能、具有冗余通道”。即使所得的每个用例模型不完整，但也会带来三个好处：1）单独从每个参与者的角度考虑系统用例，确保每个系统用例都被捕获；2）通过一起查看这些用例模型，可捕获系统的所有需求；3）参与者可只关注其感兴趣的相关用例。通过比较每个用例模型，可发现潜在的冲突或重复。虽然表达方式可能不同，但最终从系统本身角度看，其需求的本质是一样的。例如，消费者、设计人员以及飞控系统都要求该系统能够获取飞行器的姿态、高度等信息。因此，为了避免需求之间的重复冲突，整理图1 中的所有用例模型，从系统本身的角度出发，最终建立完整的，无重复的飞行传感器系统需求的用例模型如图2 所示，获得了系统的需求用例元模型。

图2 飞行传感器系统需求的用例模型

4 需求建模实例分析

本节以某型号无人机传感器系统为例，利用上文建立的元模型库，搭建该系统需求模型。将根据用户得出的涉众需求转化成对应的系统需求，分别在DOORS 中进行描述。通过DOORS 中Link Mod⁃ule 将涉众需求与系统需求关联起来，建立满足（satisfy）关系，保证系统需求完整地覆盖涉众需求，从而保证后续系统建模与涉众需求的一致性，如图3所示。

通过Gateway将DOORS中的需求导入到Rhap⁃sody 飞行传感器系统项目中。该无人机传感器系统需求为：能够与飞行控制系统进行信息交互，将姿态、位置等信息反馈给飞行控制系统［16］；系统本身具有稳定性、可靠性以及容错性。利用上文获得的飞行传感器系统需求用例元模型，搭建该系统需求模型如图4 所示。系统用例模型中的参与者与用例之间存在关联（link）关系，用例之间存在包含（include）关系等。

图3 关联系统需求到涉众需求

图4 某型号传感器系统用例模型视图

5 结语

针对飞行传感器种类繁多，功能复杂，需求多变的特点，本文通过DOORS对系统需求进行管理，不仅可实现多人对需求更改，而且能实现需求的跟踪性，直观地描述需求之间的关系。通过Gateway集成Rhapsody 与DOORS，实现需求的动态转移。基于MBSE 采用用例图对系统需求进行建模，获得飞行传感器系统的需求元模型。以某型号无人机传感器系统为例进行分析与验证。可以发现，基于MBSE 的思想对飞行传感器系统需求进行分析，不仅可以消除信息表达的二义性，便于需求变更；而且需求模型具有重用性，方便系统后续的开发。本文主要工作是对飞行传感器系统需求进行静态建模，下一步可通过使用SysML 序列图、状态图等行为图对需求进行动态描述与进一步验证。