基于模型的系统工程在航电系统设计中的研究与仿真

随着计算机领域技术的跨越式发展,人们对航空电子系统所能完成的任务也有了更多的期待,系统的综合化能力和复杂程度也随之提高,如何在新型的航电系统设计中控制好技术成熟度、进度、质量和成本成为一个摆在我们面前必须解决的难题。也正是由于飞机航电系统综合化程度越来越高,涵盖的功能项目越来越广,我们亟需一套自顶向下囊括需求捕获与分析,功能设计与验证、软硬件开发与测试的系统方法来指导我们的设计。

目前航电设计中面临着以下挑战：

(1)需求的捕获、分析、确认和管理不到位。设计主要依赖于个人的经验积累,需求描述存在不确定性,无法保证被无歧义的贯彻,对没有建立需求追踪关系,不能保证所有需求在开发中被完全覆盖,对需求没有经过前期验证,需要依靠原理验证、C型件甚至S型件试验才能发现问题;

(2)传统的设计文件采用纸质文档的形式,无统一标准化要求,容易产生二义性,同时单纯的文字和图型难以表达出现代航电复杂的活动过程和内部逻辑变化,因此下游软件设计人员无法全面了解和掌握系统设计人员的思路想法,影响后期实现;

(3)缺少一套成体系的方法将航电系统设计中各岗位的工作有机、高效的链接起来,使得各个环节的工作人员都能够非常清晰的了解自己应当负责的工作内容。

系统工程是一种使系统能成功实现的跨学科的方法和手段。主要应用于系统前期的方案设计阶段,通过科学的方法捕获目的系统的需求并以此开展功能分析,同时支持对多个子系统进行设计综合、接口测试和逻辑验证。

基于模型的系统工程(MBSE)方法：通过为用户提供可视化的模型,引导用户按照需求管理、功能分析、架构设计、集成测试的流程一步步实现对系统需求的分解、建模和综合,经过对初始需求不断的“确认”和“验证”,得到一套完整的确认化需求和一系列可执行模型库,最终通过这样的仿真手段在产品设计前期便查找出后续环节可能存在的隐患和故障问题,大大减少系统设计成本。如图1所示。

近年来,国际领先的航空企业都在积极实践和推进MBSE。例如波音公司、空客公司、洛克希德·马丁公司等,不约而同的在新型号或新产品的设计中全面采用MBSE方法,涉及到系统任务和需求定义及管理、系统功能和内外部接口设计、电子设备和软件的生产及测试、系统架构设计和系统综合等各个领域。

飞机系统是典型的系统之系统,从飞机级看包含了飞控、机电、航电、液压等众多系统,对航电系统进行分解又包含了综合显控系统、综合处理系统、无线电导航系统等分系统。在进行型号设计工作时,需要分开对飞机级和系统级开展建模仿真,上层系统设计结果是进行下层系统设计的输入条件,下层系统设计结果是对上层设计的确认和验证过程,层级之间分工明确,经过不断地迭代过程,最终达到一个最优的设计结果。

MBSE是能够将最初用户需求转化成为可执行功能模型的一整套规范方法,特别针对与复杂系统,按照这样的方法和步骤能够帮助设计员深入了解系统,进行合理的功能划分和接口设计,从而分工完成各部分设计工作,最后再进行系统综合。如图2所示。

按照设计流程首先明确所分析的系统要干什么,即系统的功能是什么,定义为系统工程的黑盒阶段,然后分析系统的功能如何来实现,定义为系统工程的白盒阶段。黑盒阶段和白盒阶段的分析过程基本一致,不同点在于完成黑盒分析后,需要完成一轮架构设计,得到系统的逻辑架构,随后在进行白盒分析时,将各个功能项全部分配到架构设计中划分出来的各个分系统里。

一、需求分析

需求分析阶段工作包括需求定义、系统用例定义和建立追踪关系三部分。将捕获到的初始系统需求从DOORS系统导入到Rhapsody系统中,然后系统进行分析,绘制系统边界,定义系统用例,建立用例和需求之间的追踪关系,确保每一条需求都得到覆盖。

1、需求定义

需求定义是整个MBSE方法最顶层的设计输入,是对用户需求和行业设计规范的条目化管理,需要对需求建立各类属性以便进行分类和查询。通常需求属性包含有编号、类型、状态、阶段等。后续的设计仿真只针对其中功能性需求进行建模。

2、系统用例定义

用例图通过描述系统的各类外部用户和系统之间的交互操作来分解和迭代已有的系统的功能需求,对之前条目化需求进行更新完善,定义用例的过程通常会对需求进行更改、新增和删除,在完成全部用例定义之后,需要将确认之后的需求由Rhapsody系统重新导入到DOORS系统进行完善。

用例模型描述的是系统必须能“做什么”,关注系统是如何被外部用户所使用的。

用例图由边界、用例、参与者和关系四部分组成,其中边界描述了系统所要实现的具体功能,而用例则是实现该功能所要具备的一个个子功能项目,边界以外的都是参与者,他们与子功能项之间的交互动作称之为关系。

3、建立追踪关系

建立系统用例到系统需求之间的追踪关系,该步骤主要用于确认在进行系统用例定义时有没有遗漏功能性需求,是否达到了百分之百的覆盖率。

二、功能分析

功能分析用于分析每一个系统用例的功能流程,识别系统与外界的交互关系,最终完整描述系统状态行为,是一个反复迭代的过程。功能分析阶段只关注系统的功能,不考虑系统的架构和实现方式。采用模型的方式直观的展示系统的活动顺序、接口关系、运行状态。最为关键的就是通过模型的执行,能够尽早的验证功能需求。

1、黑盒活动图

活动图表示系统为完成用例描述的功能所要执行的一系列活动与操作,阐明了用例实现的工作流程。展示出系统所有功能的业务流程、逻辑关系和数据交互。绘制活动图时要站在系统的角度看待系统的活动。

活动图涵盖定义的所有参与者,明确参与者与系统的输入输出关系。为了准确描述每一个活动,需要制定统一的活动描述的规则,方便设计人员之间沟通交流,同时使得设计员的意图能够无歧义的传递给下游开发人员。

2、黑盒顺序图

每个功能存在不同的使用场景,通过在不同使用场景下分析系统与外部参与者的输入和输出操作来识别出系统与外部的接口,此时设计的注意力集中于每一个场景,场景分析使用顺序图。顺序图通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作,表示用例的行为顺序,更加凸显系统的时序性。

在进行顺序图分析时要注意系统都与哪些外部参与者有交互,交互的具体事件,交互的时间顺序。其中外部参与者对应端口,交互的具体事件对应接口,交互的时间顺序对应系统逻辑。

3、端口和接口

以图形的方式展示系统与外部参与者的所有交互,创建系统的IBD图(内部块图),其中端口与接口是系统与外部参与者进行交互的一种手段,系统与外部参与者通过端口进行交互,接口配置于端口之上,一个端口可能配有多个接口,系统通过端口提供接口服务。

接口参数中描述系统与人之间的接口定义为系统的显示控制需求,与其他外部系统之间的接口定义为系统的逻辑接口,所有的接口都是通过系统的建模分析得到的,从而通过系统的设计方法保证了接口的正确性和完备性。

4、黑盒状态机

状态机主要用于描述一个对象在其生命周期内的动态行为,表现为一个对象所经历的状态序列、在特定状态下的行为、引起状态转移的条件、因状态转移而伴随的动作、以及对异常做出的响应等。是对系统一个更加深入、明确的过程。

5、运行状态机

运行状态机是将设计得到的状态机模型,加入网页等外部驱动手段,通过改变外部输入和内部参数,使之能动态运行起来,可视化的呈现系统运行状态,能够表现出系统逻辑和时序,方便设计人员进行系统需求确认。

运行状态机包括生产参与者状态机、生成系统参数和运行三个步骤。其中生成参与者状态机是将所有外部参与者对系统的输入操作进行仿真驱动,生成系统参数是提供对系统所有参数的一个动态更改页面,便于调整系统不同的运行状态,最后运行状态机,仿真系统内部的运行活动,更直观的检查系统行为。

选取航电系统中TCAS功能进行仿真建模分析,TCAS即空中防撞系统,包含了空中交通告警/防撞和空管应答两项重要子功能。

空中交通告警/防撞功能能够对空域中其他装有应答机的飞机进行询问,此时被询问的飞机会发送应答结果给发出询问的飞机,然后通过反馈的应答结果判断附近空域内是否有其他飞机,并结合本机的飞行状态评估出其他飞机的威胁等级,通过语音和画面的形式展示给飞行员,便于飞行员进行合理避让。

空管应答功能能够为地面雷达站提供本机编码、高度和识别信息,便于空管人员进行空中交通管理。

通过上述设计方法对该功能进行需求分析,随后建立黑盒活动图、顺序图、确定端口和接口,完成黑盒状态机的建立。最后通过图3可执行的Web网页界面对状态机进行运行测试,检验系统需求是否都准确实现,运行模型如图4所示。

基于模型的系统工程设计方法,使设计工作有章可循,依靠科学的方法,引导设计人员从系统需求出发,逐步深入明确系统功能,经过迭代测试,反过来完善系统需求,同时产生多类可视化模型,便于团队交流沟通,也为下游开发提供依据,系统整个开发过程中需求都可追溯,便于复杂系统设计时需求的变更管理,以及对系统状态的控制,实现从经验研发向需求研发的转变。

通过对系统的建模分析我们能够得到以下成果：(1)通过仿真建模分析得到确认的条目化需求;(2)得到了状态机模型,通过模型的执行,可以对需求进行验证、测试,尽早暴露问题,及时发现需求分析过程中的不足,迭代完善系统需求;(3)系统建模形成的接口控制文档可以为后续POP和ICD设计提供依据;(4)在当前文件体系结构下,加入系统建模分析过程,承接设计要求和技术方案,使方案论述更为完善。

（以上文章来源于《数字技术与应用》，作者：王扬，航空工业第一飞机设计研究院）