基于模型驱动的航电系统设计方法
计划和观点(即系统需求),然后将这些需求明确地叙述成规范(即系统规范),我们只是关心系统需要做什么,需要完成什么。功能分解将规范中的系统需求表达成系统设计的抽象实体,实际上,功能分解的过程就是描述如何去实现这些功能。在系统设计阶段,我们将精力集中到系统的实时限制以及各种功能完成的先后顺序,我们仍然不会关心采用什么样的处理器或可用到的存储器等。在软件/硬件分析、设计及实现阶段,我们才关心诸如操作系统、处理器、内存等最终的具体实现。这四个步骤带给我们的是从概念化的系统到真正的产品。
在“V”型设计的系统综合过程中,包含了从软件/硬件的单元测试,到模块综合与测试,再到子系统综合与测试,最终到系统验收测试。这个过程体现了“V”型设计中最重要的一点,即在系统分析/设计的每一个阶段,都必须为今后的综合和验收测试定义测试场景,并进行测试定义。
系统需求捕获和分析
系统需求捕获和分析是任务系统设计的第一步,充分理解设计需求是进行正确设计的重要基础。经过认真分析飞机的战技指标要求,并与用户进行充分交流的基础上,确定任务系统的使命,明确任务系统的主要功能性能,将用户需求转化为系统需求。系统需求是用户需求的解决方案,是把能力观点转化为以方案为基础的观点。系统需求包括功能性需求和非功能性需求两个方面,功能需求是外部可观察到的系统的预期行为,非功能需求包括性能、可靠性、安全性、设计约束条件等特性。为了保证可追溯性,将建立系统需求与用户需求之间相应的可追溯性链接关系。
需求分析过程将明确任务系统与电源、环控、座舱、起落架、机电等飞机系统以及与飞控系统、武器、操作者、地面站、体系外成员等之间的接口,确定任务系统的主要输入和输出。在任务系统需求分析阶段,飞行员操作程序(POP)将是任务系统设计的一个主要需求,它需要对座舱人机接口设备的功能、信息显示和控制操作逻辑等进行了定义。
系统需求定义完成后,下一个重要步骤则是根据系统需求,将系统的功能需求进行分组,确定系统用例。HarmonySE系统设计方法以用例图(Use Case Diagram)捕捉系统的需求,它以图形化的方式表示系统内部的一系列用例,它以一种技术人员和非技术人员都容易理解的方式来描述系统在功能上的特殊需求。每个系统用例描述了任务系统其中一个特定的系统操作流程,定义了由参与者感知到的行为以及参与者与用例之间的信息流。参与者可能是一个人、另一个系统或者是正在开发的系统外部的一个硬件。一旦系统级用例被确定,以及所有的功能性需求和相关的性能需求都被用例所覆盖且都被确认后,需要根据对系统架构定义的重要度对系统用例进行排序和分类,从而确定系统工程增量式迭代工作流的顺序,经过每轮设计迭代后,用例实现的优先级也许会发生变化。
系统用例应该分层次进行构架,遵循模块化、自顶向下和易于修改的原则是合理可靠的。首先从顶层系统用例开始,采用结构化的设计方法给出对整个任务系统的一般定义,然后分解成第一层的用例,每一个第一层的用例又被分解成再下一个层次的用例,直到最底层。为了达到易于理解的要求,在用例分层的过程中,应遵循信息隐藏和解耦的原则,每下一层的用例都将包含比上一层用例更详细的功能,每个用例的描述不应含有其下一层用例描述的细节,并应隐含那些不会影响同一层其他用例和上一层用例的信息,同一层用例描述的详细程度也应是一致的。易于修改可通过检查用例结构的稳定性来验证,如果删除任何用例,仅影响要删除的用例和它所有的子用例的功能分配,而不需要对其余的用例所包含的功能做任何修改;修改功能应当仅影响含有该功能的用例和子用例;增加功能可用增加一个新的用例或在现有的用例中增加功能的方法,而不必改变现存的用例架构。
需求分析阶段的模型包含需求模型和系统用例模型。需求模型将需求分类直观化,系统用例模型将需求分组到系统用例当中,这些模型是不可执行的。
系统功能分析过程
当系统的需求明确以后,就明确了系统所要完成的任务和主要功能,为使我们能够理解、描述和设计这个复杂的系统,需要将这些系统功能分解成具有层次结构的更简单部分,由此引出任务系统的功能分析过程。
在这个阶段,整个任务系统仍然是作为飞机的一个功能模块来考虑,即把任务系统当做一个黑盒。功能分析阶段的主要目的是将系统的功能性需求转化为对系统功能或行为的一致性描述,这个分析过程是基于在需求分析阶段所确定的用例,每个用例将被转化为一个可执行的模型。
功能分析过程中,通过黑盒活动图、顺序图和状态图对系统的功能和行为进行描述,每个图在描述用例行为的过程中都起到不同的作用。活动图描述了用例所有的功能流,将所有的功能需求以行为/操作的方式进行分组,并展示这些活动是如何相互连接的;顺序图描述了一个特定的用例路径,并定义了在操作和参与者之间的信息流。状态图集合了功能流和参与者相互之间行为的信息,将这些信息加入到系统状态的内容中,并根据外部不同优先级别的触发条件加入系统行为。因为状态图是用标准的语法规范进行定义的,因此最终系统行为的正确性和完整性可以通过模型执行来进行验证。
根据功能分析过程中建立的黑盒用例场景,通过模型的执行来对相关过程进行分析,主要目的在于验证生成的顺序是否满足要求,而并非验证用例所包含的功能本身。一旦用例模型和其包含的功能需求被验证后,可能需要进行“雨天”场景分析,专注于确定在初始需求分析阶段未覆盖到的系统故障或失效的场景。
如果在建模过程中确定了有新的或衍生出来的需求,那系统需求规范也需要进行相应的更新,并纳入需求管理体系。
最终,系统功能分析过程的成果是生成带基线的系统需求规范以及系统级的逻辑接口控制文件,定义系统与参与者之间的功能和逻辑接口。
系统的设计综合过程
在系统需求分析和功能分析阶段,任务系统都是被当做一个黑盒来处理,所有的行为都是系统的行为,未涉及系统内部的组成和架构以及系统中每个子系统应完成的功能和它们之间的交互关系,在设计综合过程中将解决这些问题。在系统设计综合过程,系统进入白盒设计阶段,工作的重心在于将系统的功能性需求和非功能性需求分配至一个确定的系统架构中,该架构可以在指定的性能限制约束下完成所需的功能,这个过程包括了架构分析、架构设计和详细设计三个方面的内容。
在系统功能分析过程中定义了系统要做什么,但并没有确定怎么去做。架构分析的目标就是确定在合理的范围内达到某个特定功能和能力的最佳方法。在架构分析过程中,首先定义关键的系统功能,确定候选的解决方案,明确评估标准和权重,将这些标准和权重分配给候选的解决方案,经过分析比较和论证,权衡各方面的因素,确定解决方案。当所有的关键功能的解决方案都确定后,对这些解决方案进行合并,确定满足系统功能和能力的最佳的系统架构。
架构设计过程是将系统功能分析过程中所定义的功能和行为分配至系统架构中的相关的功能子系统里,这个架构可以是根据前面架构分析得到结果,也可能是一个给定的系统架构。这个功能和行为分配的过程是个迭代的过程,一般与各领域专家协作完成,可能存在很多不同的分配策略,不同的策略可能考虑不同的设计限制,例如在需求分析阶段所获取的性能和安全性需求。
详细设计阶段的重心在于定义端口与接口,以及在系统最底层架构中每个功能子系统基于状态的行为。在这个阶段,活动图将产生“泳道”,用来将系统的行为操作划分到子系统中,每个泳道代表任务系统下的一个子系统。顺序图也会根据新的活动图产生,描述某个场景下任务系统所包含的子系统的信息交互。设计综合阶段的状态图,也不再是针对整个任务系统的状态,而是针对子系统的状态表述。
HarmonySE系统设计方法中用结构图(Structure Diagram)来表述系统层级关系及接口,包括用块定义图(Block Definition Diagram)来描述任务系统与其包含的子系统之间的关系,用内部块图(Internal Block Diagram)来详细定义任务系统内部子系统之间的接口关系,即ICD。
系统设计模型的一个非常自然的预期读者就是软件工程师,同时也是系统设计产物的交付对象之一。对于软件工程师而言,结构图形象化地表述了他们所熟悉的子程序:层次结构、输入数据和输出数据等。
模型的验证和确认以及文档生成
“V”型设计的一个特性是当我们沿“V”过程的左边向下进行过程中,每一阶段都必须定义今后系统综合中使用的各种测试。按照我们的分析过程,这意味着在系统层次结构的每一层,在进入下一层之前,该层的模型必须经过验证和确认。
HarmonySE的模型不仅仅只是一个静态图,它是一个能进行仿真并生成代码的正式模型。进行仿真时,仿真器对设计图中处于激活状态行为和功能加亮显示,以此为设计者提供反馈。仿真时的一个重要工具是人机交互面板,用于驱动或控制模拟过程,可以非常直观地显示仿真结果。此外,仿真器环境提供了所有传统的调试装置,如波形、监视器和调试窗口等。这样,系统设计者就能够分析确定系统运行是否正确,并获得测试数据,这些数据将用于以后系统综合和验收时的测试。在验证过程中,各种激励和响应能被记录下来,这提供了用于综合的按照输入和期望输出之间的关系所确定的测试用例定义。
任务系统的设计最终要变成设计文档并连同设计模型一起提交给下一级软件开发和子系统承制单位,最终变成嵌入式系统的可执行代码。HarmonySE的文档生成工具能自动摘录包括图形和文字在内的所有模型数据,然后输出成为标准的或用户自定义的文档,便于整理和归类,这些文档将作为子系统设计者和软件设计工程师的主要的参考文件。
结束语
采用面向用户需求的基于“V”型设计方法提供了一种全新的迭代式系统设计流程,以建模语言为核心的图形化行为建模技术和快速原型生成技术,使系统设计工程师能够在设计过程中实现对系统的功能要求、行为方式、控制方式等进行可视化的调试和验证,及时发现并纠正错误,避免在系统综合和测试阶段才发现上述问题,从而大大提高系统的设计效率,降低系统的开发和维护费用。这种系统设计方法现已在美国和欧洲的高科技和军事/航空领域中得到广泛应用。
推荐访问: 模型 驱动 方法 设计 系统