| 编辑推荐: |
| 本文来自于csdn，译者刘亚龙，本文介绍系统工程方法的建模概念，并设置SysML如何被使用的语境等内容，希望对您能有所帮助。 |
|
系统工程概述
OMG SysMLTM [1]是一种表示系统的通用图形化建模语言，包含硬件、软件、数据、人员、设备、和自然对象的组合。SysML支持基于模型的系统工程(MBSE)的实践，MBSE被使用来开发系统面对复杂的技术挑战性问题的解决方案。
本章介绍系统工程方法的建模概念，并设置SysML如何被使用的语境。描述系统工程的动机、介绍系统工程过程、随后描述一个简化的汽车设计例子来强调复杂性如何被解决在系统工程过程中。也汇总系统工程涉及的标准,诸如，SysML帮助编写系统工程的实践。
在本书第一部分后续的三章中，分别介绍：基于模型的系统工程；SysML语言概述；本章汽车设计示例的一部分SysML模型。
系统工程的动机
无论产品是一架高级军用飞机、一辆混合动力汽车、一部移动电话、或一个分布式信息系统,今天，系统被期望执行以前时代不可想象功能。由于产品竞争性需要，系统利用技术进步持续增加新功能同时降低成本和缩短交货周期。对应新增功能的需求驱动增加功能、互操作性、性能、可靠性、和缩小规模。
系统之间的互联也增加了相关的系统的需求。系统不再被当作孤立的,而被当作一个更大的整体的一部分，其中包含其它系统及人员。作为互联体系(SoS)的部分，系统被期望支持许多不同的使用。这些使用驱动需求演变，可能导致当初不曾预测的系统被开发。一个例子是通过电子邮件和智能手机的互联，如何影响我们今天的生活活动。明显的,电子邮件和智能手机提供的互联导致我们没有预料到的的需求,这些新技术的使用影响谁与我们通讯、通讯频率、和我们如何响应。对于互联的系统这是相同的。
开发系统的实践必须支持这些增长的需求。系统工程方法已经在航空航天和国防工业域居于主导地位，为系统提供面对技术挑战和关键任务问题的解决方案。解决方案常常包含硬件、软件、数据、人员、和设备。系统工程实践已经持续演变来解决今天复杂性持续增加的系统,不限于航空航天和国防系统。作为一个结果,系统工程方法已经获得了广泛的认可和接受在其它的工业领域，诸如，汽车、通讯、和医疗设备等。
系统工程过程
一个系统包含一组元素集合，它们之间相互交互,并可以被看作一个整体与外部环境交互。系统工程是一种多学科方法，用来开发系统平衡响应复杂的涉众需求的解决方案。系统工程包含管理和技术过程的应用来达到平衡和降低项目成功的风险。系统工程管理过程被应用来确保开发成本、计划安排、和技术性能目标被满足。典型的管理活动包含技术工作的计划、监控技术性能、管理风险、和控制系统技术基线。系统工程技术过程被应用来说明需求规格、设计、和验证将构建的系统。系统工程实践不是静态的,动态处理持续演变增加的需求。
系统工程技术过程的一个简化视图显示在图1.1。系统规范和设计过程被使用来明确说明系统需求并分配到组件需求来满足涉众需求。组件随后被设计、实施、和测试来确保它们满足需求。系统集成和测试过程包含集成组件到系统并验证系统需求被满足的活动。在整个系统开发中，这些过程使用不同过程之间的持续的反馈迭代应用。在更复杂的应用中,系统分解成更多的层级，开始在一个企业或体系（SoS）层级。在这种情形中，这个过程的变体被递归地应用到每一个中间的设计层次，在该中间层次下面的层级的组件被购买或建造。
图 1.1 简化的系统工程技术过程
系统规范和设计提供一个平衡的解决复杂的涉众需求的系统解决方案，图1.1中的过程包含下面的活动：
抽取和分析涉众需求来分析系统需要解决的问题、系统试图来支持的目标，和有效性测量需要来评估系统如何很好的支持目标。
明确说明需要的系统功能、接口、物理的和性能特征、和其它支持目标和有效性测量质量特性。
综合可选的系统解决方案，通过划分系统设计到可以满足系统需求的组件。
执行权衡分析来评估和选择首选的解决方案，满足系统需求并提供优化平衡来获得完整的有效性测量。
维护从系统目标到系统和组件需求、同时验证结果之间的可追溯性，确保需求和涉众需求被解决
系统工程过程典型应用
系统规范和设计过程可以被说明通过应用这个过程到一辆汽车的设计中。执行这个过程是一个多学科系统工程团队的职责。典型的系统工程团队的参与者和角色被讨论在1.4节。
团队必须首先辨别利益相关者并分析他们的需要。利益相关者包含车辆的购买者和车辆的使用者。在这个例子中,用户包含驾驶员和乘客。他们的每个需求必须被解决。涉众需求更进一步地依赖于特定的细分市场,诸如，一辆家庭用车和一辆跑车和一辆越野车。对于这个例子,我们假定汽车面向个人职业生涯处于中期的用户，他或她使用这辆车作为日常的交通工具。
此外,系统工程的一个重要宗旨是解决那些可能影响整个系统生命周期的其它利益相关者的需要，所以附加的利益相关者包含生产车辆的制造者和那些维护车辆的人员。它们关注的每个必须被解决来确保一个平衡的生命周期解决方案。不太明显的利益相关者是政府，政府表达它们的需要通过法律和法规。明显的,每个利益相关者的关注在车辆的研发中的重要性是不同的。因此不同的利益相关者的关注必须适当的加权。分析被执行来理解每个利益相关者的需要,并使用目标值定义相关的有效性测量。目标值被绑定到解决方案空间,用来评估可选方案,和来与竞争对手的解决方案区分。在这个例子中,有效性测量可以关联到解决交通需求的主要目标，诸如，性能、舒适性、燃油经济性、加油或充电之间的范围、安全性、可靠性、维修时间、采购成本、环境影响、和其它重要但难于量化的测量，诸如，审美品质。
明确说明系统的需求，解决利益相关者的需求和相关的有效性测量。开始于系统边界的定义，以便在系统和系统外部和用户之间建立清晰的接口，如图1.2所示。在这个例子中，驾驶员和乘客（未显示）是与汽车互动的外部用户。加油站和维修设备（未显示）是车辆外部系统的例子。此外，车辆与道路的物理环境相互作用。所有的这些外部系统、用户和物理环境必须指定来划分系统边界及其相关接口。
图1.2 定义系统边界
对应汽车的功能需求被详细说明通过分析，系统必须做什么来支持它的整体目标。这辆车必须执行加速、刹车、和驾驶的功能,和许多附加功能来满足驾驶员和乘客的需要。功能分析识别每种功能的输入和输出。正如显示在例子中在图1.3,车辆的加速功能需要一个来自驾驶员的加速输入并产生输出，输出对应汽车推力和驾驶员获得的速度计读数。功能分析指定动作的序列和顺序。
图1.3 明确说明功能需求
功能需求也必须被评估来确定性能需要的级别。正如指示在图1.4,在一定的条件下，汽车需要加速从0到60英里每小时(mph)在8秒内。相似的性能需求可以是从60mph到0mph对应的刹车距离和相应的驾驶需求，诸如，转弯半径。
图1.4 汽车性能需求
附加的需求被明确说明来解决每个利益相关者的关注。需求的例子包含明确说明乘坐舒适性、燃油效率、可靠性、可维护性、安全性、和排放。物理特征,诸如，最大车重可以衍生自性能需求，最大车辆长度可以被描述通过其它需求，诸如，标准停车位尺寸。系统需求明显追溯到涉众需求，并被验证确保需求解决了它们的需要，在这个过程中，代表性的利益相关者早期和持续参与是整个开发工作成功的关键。
系统设计涉及标识系统组件并明确说明满足系统层级需求的组件的需求。这可能首先是一个逻辑系统的设计，不依赖与具体使用的技术，和随后反映特定的技术选型的物理系统的设计(注：逻辑设计是技术独立的，可能包含一个组件称为一个力矩生成器,和备选的物理设计是技术依赖的，可以包含一个点火发动机或一个电器电机)。显示在图1.5的例子中,系统的物理组件包含发动机、变速箱、离合器、底盘、车体、制动器等等。这个系统包含从系统到组件层次的一个单一层级划分。然而,正如先前描述的,复杂的系统常常包含系统分解的多个层次。
图1.5 汽车系统分解成它的组件
设计约束被常常施加在解决方案上。一个通用的约束类型常常是重用一个特定的组件。例如,或许有使用已经存在于存货清单的发动机的需求。这条约束隐含说明不需要开发新的发动机，虽然设计约束常常节省实施的时间和成本,有时分析表明放松约束会更便宜更快。例如,如果发动机被重用,昂贵的过滤设备或许需要来满足最近实施的污染法规。另一方面，一个重新设计的成本，包括较新的技术，可能是一个不太昂贵的选择。系统工程师应检查设计约束背后的原理，并通知利益相关者是否分析验证约束背后的假设。
组件被指定，这样，如果它们的需求被满足,系统需求也被满足。动力子系统显示在图1.6，包含发动机、变速箱、和离合器组件、并必须提供动力来加速车辆。相似的,转向子系统必须控制车辆的方向、和制动子系统必须降低车辆速度。
图1.6 组件间的交互满足功能和性能需求
通过执行工程分析来确定衍生的组件性能和物理需求，来自组件的什么满足系统需求。例如,一个分析被执行来衍生发动机的马力需求、车体的阻力系数、每个组件的重量来满足车辆加速的系统需求。相似的,分析必须被执行从其它系统性能需求来衍生组件需求关联到燃油经济性、燃油排放、可靠性、和成本。乘坐舒适性需求解决人员因素关注的问题可能需要多种分析，考虑关联到路面振动，汽车内部的噪声传播、空间-体积分析、和显示控制布置等。
系统设计可选方案被评估来确定最优的系统解决方案，解决多个竞争性需求获得一个平衡的设计。在这个例子中,提升加速度和燃油经济性的需求是竞争性需求，它们被提交到权衡分析来获得一个平衡的设计。这可能导致评估可选设计的发动机配置,诸如，一个4缸发动机和一个6缸发动机。可选的设计方案随后被评估基于可以追溯到系统需求和有效性测量的准则。对于利益相关者来说，选择的解决方案被确认通过利益相关者，它解决了它们的需要等等。
组件需求是组件设计、实施、和测试过程的输入来自图1.1。组件开发者提供反馈到系统工程团队，来确保组件需求可以被满足通过它们的设计,或它们可以请求组件需求被重新分配。在开发过程中这是一个迭代过程，常常被需要来获得一个平衡的设计解决方案。
系统测试用例也被定义来验证系统满足它的需求。作为系统集成和测试过程的部分,验证的组件被集成到系统中，系统测试用例被执行来验证系统需求被满足。
正如指示在图1.7,需求可追溯性被维护在涉众需求、系统需求、和组件需求之间来确保设计的完整性。对于这个例子的系统和组件需求,诸如，车辆加速、车辆重量、和发动机马力，可以被追溯到与性能和燃油经济性相关的涉众需求。
系统工程过程来开发一个平衡的系统解决方案，其解决随着系统复杂性增长变为必须的复杂的涉众需求。系统工程的有效应用需要维护一个广泛的系统视角，其聚焦在整个系统目标和每个利益相关者的需要,而在同时保持对细节的关注和严格要求，将确保系统设计的完整性。SysML的表达能力和精确程度使能这个过程。
图1.7 涉众需求向下流动到系统和组件需求.
多学科系统工程团队
为了广泛代表利益相关者的关注,系统工程的参与者需要来自许多工程和非工程学科。参与者必须有对最终用户领域的理解,诸如，汽车驾驶员的跨系统生命周期的领域知识，诸如，汽车的制造和维护。参与者也必须有系统的技术领域知识。诸如，动力和转向子系统和一个专业工程领域的知识,诸如，可靠性、安全性、和人员因素,来支持系统设计的权衡分析。此外,他们当中必须有来自组件开发和测试团队人员，他们的充分参与确保规范可实施和可验证。
图1.8 一个典型的多学科系统工程团队需要来表示复杂的利益相关者视觉
一个多学科系统工程团队应该包含来自每个学科的代表。依赖于系统的复杂性和参与者团队成员的知识范围。一个系统工程团队在一个小的项目上，可以包含：一个单一的系统工程师,他有广泛的领域知识可以紧密与硬件和软件开发团队和测试团队一起工作。另一方面,一个大型系统开发可能包含一个系统工程团队由一位系统工程经理管理，他计划和控制系统工程工作。这种类型的项目可能包含几十个或几百个不同经验的系统工程师。
一个典型的多学科系统工程团队显示在图1.8。系统工程管理团队的职责是管理与计划相关的活动并控制技术工作。需求团队的职责是分析涉众需求、开发运行构想（the
concept of operations）、并指定和确认系统需求。架构团队的职责是综合系统架构通过划分系统组件、并定义它们之间的互动和互联。这包含分配系统需求到可能包含的硬件和软件组件需求。系统分析团队的职责是执行系统不同方面的工程分析,诸如，性能和物理特征、可靠性、可维护性、和成本。集成和测试团队的职责是开发测试计划和过程并进行测试验证需求被满足。有许多不同的组织结构来完成相似的功能,并且个人可以参与到不同的团队扮演不同的角色。
编写系统工程实践通过标准
正如先前提及的,系统工程已经在复杂工程、最先利用先进技术关键任务占主导的航空航天行业和国防工业域占主导地位。这些系统包含：陆地、海洋、空气、和基于空间的平台；武器系统；命令、控制、和通讯系统；和后勤保障系统等。由于系统相互关联的本质,系统工程的重点已经转变到将一个系统视为一个更大的整体的一部分，被称为体系(SoS)或企业。
在本章前面讨论的由于竞争和技术进步的需要，其它行业部门开发的系统的复杂性已显著增加。具体而言，许多商业产品已经包含了最新的处理器和网络技术，伴随后来新增的功能具有明显的软件开发内容，并通过越来越多的复杂接口相互连接。产品使用采用了新的方式,诸如，集成了摄像头的移动电话、使用在汽车系统中的全球定位系统，这些以前是不可想象的。系统工程已经被应用到许多其它工业领域帮助处理这种复杂性。需要在这些工业领域内推进系统工程实践，对系统工程概念、术语、过程、和方法建立标准已经变得越来越重要。
系统工程标准过去好多年一直在持续演变中。图1.9显示部分分类的标准，包含系统工程过程标准、框架架构标准、建模方法标准、建模和仿真标准、和数据交换和元建模标准。完整的基于系统工程的标准方法还未形成，但可以实施来自这个分类中每个层级的至少一个标准。
图 1.9系统工程标准分类的一个部分
系统工程过程标准主要强调的是开发过程的标准，包含EIA632[2]、IEEE1220[3]和ISO15288[4]。这些标准解决广泛的工业需要并反映系统工程的基本原则，为建立一个系统工程方法提供一个基础。
系统工程过程标准与软件工程实践共享许多共同之处。管理实践对应计划,例如,相似的是，是否它对应复杂的软件开发或系统开发。作为一个结果,
在标准社区中，是否调整系统和软件标准在它们实践的领域已经越来越重要。
系统工程过程定义什么活动被执行,但没有给出有关它们如何被执行的详细描述。一个系统工程方法描述活动如何执行，并生成数据构件和数据构件如何被开发。例如,一个重要的系统工程构件是运行构想（Concept
of Operations）。正如它的名称隐含的, 运行构想定义系统试图从用户的视角执行什么。它描述系统与它的外部系统和用户的交互，但可以不显示系统内部的任何操作。不同的方法可以使用不同的技术来开发运行构想。对于许多其它系统工程构件也是如此。
系统工程建模方法的例子被标识在一个基于模型的系统工程方法的汇总中[5]，包含Harmony SE[6,
7]、面向对象的系统工程方法(OOSEM)[8]、Rational系统工程统一过程方法(RUP SE)[9,10]、状态分析方法-SA
[11]、Vitech基于模型的系统工程方法[12]、和对象过程方法(OPM)[13]。许多组织也有他们内部的开发过程和方法。方法不是官方的工业标准,但事实上，如果随着时间方法和标准证明了它们的价值，标准有可能会出现。选择一种方法的准则包含方法的易用性,它解决系统工程关注范围的能力,和工具层面的支持。在本书的第三部分中给出了两个例子问题，一个使用功能分析和分配方法，另一个是场景驱动的方法(OOSEM)的使用。SysML试图支持许多不同的系统工程方法。
除了系统工程过程的标准和方法,一些架构框架标准已经形成来支持系统架构。一个架构框架包含特定的概念、术语、构件、和分类法对应描述一个系统架构。Zachman
Framework [14]方法在1980年被介绍来定义企业架构；它定义了一组利益相关者视角集和一个构件集，解决每个利益相关者关联的基础问题。C4ISR框架[15]
在1996年被引入，为美国国防部(DoD)提供一种架构信息系统的框架。国防部架构框架(DoDAF)[16]从C4ISR框架演化而来，对应为国防工业提供一个体系的架构，通过定义架构的操作、系统、和技术视图。
英国国防部基于DoDAF（国防部架构框架）的开发了(MODAF)[17]，在DoDAF的基础上增加了战略和采购视图。2000年，IEEE
1471-2000标准被审批通过，作为“Recommended Practice for Architectural
Description of software-Intensive Systems”[18]。这个实践提供了附加的基础概念,诸如，视图和视点的概念，已经被应用到软件和系统架构中,这个标准最近已经被ISO/IEC42010:2007[19]替代。开放组织架构框架(TOGAF)[20]被初次通过在1990年作为开发架构的一种方法。
系统工程建模和仿真标准是另外一类系统工程标准，其包含描述系统的通用建模语言。行为模型和功能流程图事实上已经是建模标准好多年,并在系统工程社区被广泛使用。国家标准和技术委员会发布功能建模集成定义(IDEF0)[21]在1993年。OMG
SysML标准被OMG采纳在2006年，作为一种通用的图形化系统建模语言，SysML扩展统一建模语言(UML)，SysML是本书的主题。UML的一些其它扩展已经被开发来支持特定领域,诸如，DoDAF和MODAF的统一配置文件(UPDM)[22]来描述体系和企业架构，UPDM与DoDAF和MODAF的需求是兼容的。UML建模语言的基础-OMG元对象机制(MOF)[23],MOF是一种语言被使用来定义其它建模语言。有许多其它相关的系统建模标准，诸如，Modelica[24]是一种系统仿真建模语言,和高层架构(HLA)[25]被使用来支持设计分布式仿真,和MathM是一种全面描述和定义数学等式的语言。
模型和元数据互换标准建模标准的一个关键类，其支持模型和数据和在工具之间进行互换。在OMG内部,XML元数据交换(XMI)标准[26]，支持基于MOF语言的模型的数据互换，诸如，UML、SysML或另外一个UML扩展。XMI被总结在第18.4.2节。另外一种系统工程数据数据交换标准是是ISO
10303(AP233)[27],也被简单描述在第18.4.2节。
来自OMG的附加建模标准关联到模型驱动架构(MDA@)[28]。MDA包含一组概念集，包含生成技术依赖和技术独立的模型。MDA标准使能表示在不同的建模语言中的模型可以互相传输，正如描述在MDA基础模型中[29]。OMG查询视图转变(QVT)[30]是另一种建模标准，定义一种映射语言到准确的特定语言转换。MDA包含的OMG标准在图1.9的建模和交换层。
这些标准的开发和演化是基于标准的方法到系统工程实践的一个趋势的所有部分。此类方法使能通用培训、工具互操作性、和系统规范和设计构件的重用。期望这种趋势将持续，正如系统工程在更广泛的行业变得普遍应用。
小结
系统工程是一个多学科方法，试图转变一组利益相关者需要到满足那些需要的一个平衡的系统解决方案。系统工程是一个关键实践来解决复杂的和常常面对的技术挑战问题。系统工程过程包含活动来建立一个系统必须支持顶层目标、明确说明系统需求、综合可选的系统设计、评估可选方案、分配需求到组件、集成组件到系统、并验证系统需求被满足。它也包含需要管理一个技术工作的必要的计划和控制过程。
多学科团队是系统工程实践必需的元素，解决复杂的利益相关者期望和技术领域问题并能获得一个平衡的系统解决方案。系统工程实践持续演化来处理系统作为一个更大的整体的一部分。系统工程实践正在编纂的各种标准，是推进系统工程实践在工业领域不可缺少的制度。
问题
驱动系统开发的一些需求是什么?
系统工程的目的是什么?
在系统规范和设计过程关键活动是什么?
谁是典型的跨越一个系统的生命周期的利益相关者?
需求的不同类型是什么?
为何有一个多学科系统工程团队是非常重要的?
一个系统工程团队的一些典型的角色是什么?
标准在系统工程中扮演的角色什么? |
