SysML实践指南第二版（中文翻译：刘亚龙）第四章 汽车案例

1. 一个使用SysML基础特征集的汽车示例

本书可以被用来准备SysML认证考试。SysML认证被称为OMG认证的系统建模专家(OCSMP) [34]。OCSMP有四个级别的认证。前两个级别的认证，覆盖SysML基础特征集。第三个级别覆盖完整的特征集,第四个级别包括了附加的建模概念，超越了SysML。

本章介绍SysML基础特征集,应用到所有9类SysML图并表示语言特征的一个扩展子集，内容介绍顺序同第三章介绍的SysML-Lite。

基础特征集被应用到一辆汽车的系统设计，类似与被介绍在第1.3节。汽车例子也包含引用图和语言概念的更详细的描述，被详细说明在本书的第二部分包含基础特征集和完整特征集的章节中。本章可以被用来获得一个对基础特征集初始的理解,但您应该学习本书的第二部分获得一个更详细的对于基础和完整的特征集的理解。

1. 1. SYSML基础特征集

基础特征集是SysML语言特征的一个子集，将有助于理解个人努力建模的系统建模认证前两级要求的子集。这两个级别被参考作为模型用户和建模构建者的基础。一个建模者认证在模型用户层次被期望能解释SysML图，其使用基础特征集,和一个建模者认证在模型构建初级层级被期望能来构建模型，使用基础特征集。模型构建中级被期望能构建模型，使用SysML的完整特征集。

基础特征集使用到所有9类SysML图。而SysML-Lite仅包含9类SysML图中的6个和一个受限的语言特征子集。SysML构建的子集，组成基础特征集的被强调在第二部分通过阴影段落。基础特征集也被强调在符号表在附录A，说明通过阴影（注，在本书的翻译过程，段落取消了阴影）。

1. 1. 汽车例子概述

下面简化的例子说明，SysML基础特征集如何被应用作为一个基于模型的方法的部分来明确说明和设计一辆汽车系统。这个例子类似于介绍在第1.3节汽车例子,其描述系统工程过程如何可以被应用到明确说明和系统层级的一个汽车的设计。在第1章中,没有假设无论使用那种基于模型的方法。这个例子强调选择的建模构件其被生成从应用一个典型的MBSE方法类似于个介绍在第3.4节。第16和17章介绍MBSE方法如何可以被应用的更详细的例子。

例子包含至少每种SysML图的类型的一个图,并且大多数基础特征集被说明。有一些特征在例子中，其扩展基于 SysML基础特征集,包含连续流和生成集,由于它们说明这个特定例子的重要方面。这些附加的特征被备注在例子种，其中它们被使用。引用也包含在本节到本书第二部分的章节，提供这些特征的一个详细描述。

例子也包含下面的用户定义概念,其被显示使用名称概念在括号中,和被引用到作为构造类型（stereotype）。第15章描述构造类型如何被使用来客户化语言对应域特定应用。用户定义的概念使用在这个例子中是:

«hardware»

«software»

«store»

«system of interest»

所有SysML图包含一个图框，其封闭标题和绘图区域。标题描述图的类型、图的名称、和一些额外信息，其为绘图区域的内容提供语境。有关图框架、标题、和其它通用图元素的详细信息，应用到所有SysML图被描述在第5.3节。

1. 1. 1. 问题总结

描述SysML的例子问题使用正如它应用到一辆汽车系统的规范和设计。正如先前提及的,建模构件被包含在这个例子中是可表示建模构建的的类型，其被生成从一个典型的MBSE方法类似于描述在第3.4节。仅涉及的一小部分子集被解决来强调语言的使用。图使用在这个例子中被显示在表4.1。

一个市场分析，其被导入引入需要来增加汽车加速和燃油效率从它当前的功能。在这个简化的例子中,设计的选择方面被考虑来支持一个初始的权衡分析。权衡分析包含评估结算的车辆配置，其包含一个4缸发动机和一个6缸发动机来确定，是否它们可以满足加速和燃油效率需求。

1. 1. 汽车模型

下面的子节描述汽车例子的建模构件。

表4.1 使用在汽车例子中的图

图	图的类型	图名称
4.1	包图	Model Organization
4.2	需求图	Automobile System Requirements
4.3	模块定义图	Automobile Domain
4.4	用例图	Operate Vehicle
4.5	序列图	Drive Vehicle
4.6	序列图	Turn On Vehicle
4.7	活动图	Control Power
4.8	状态机图	Drive Vehicle States
4.9	内部模块图	Vehicle Context
4.10	模块定义图	Vehicle Hierarchy
4.11	活动图	Provide Power
4.12	内部模块图	Power Subsystem
4.13	模块定义图	Analysis Context
4.14	参数图	Vehicle acceleration analysis
4.15	Timing diagram (not SysML)	Vehicle Perfomance timeline
4.16	模块定义图	Engine Specification
4.17	需求图	Max Acceleration Requirement Traceability
4.18	包图	Architect & Regulator Viewpoints

1. 1. 1. 组织模型的包图

集成的系统模型概念是MBSE的一个基础概念，正如描述在第2.1.2节。模型包含模型元素,其被绘制在一个模型库中。一个特定的模型元素可以出现在0,1个或多个在图上。此外,一个模型元素常常与其它模型元素有关系，其可以出现在相同的图或其它图上。

模型的组织是必须的来管理模型。一个很好组织的模型类似与您有一组抽屉来组织的供应商,其中每个供应商的元素被包含在一个抽屉中,并且每个抽屉被包含一个特定的在舱室中。模型组织设施是可理解的,存取控制，并能变更模型的管理。

包图对应汽车例子被显示在图4.1。包图显示模型如何被管理进包。这个模型组织包含一组扩展的包集，通过哪些被介绍在空气压缩机例子使用SysML-Lite在第3.3.2节包。每个包包含一组模型元素集，和每个模型元素被包含仅一个包中。包是说占有它内部的元素。对于包含的模型元素，包也表示一个命名空间。在模型内部，每个模型元素有一个唯一的名称,被称为完全限定名称。在一个包中一个模型元素可以与其它包中的模型元素有联系。如何来组织模型使用包的详细描述被提供在第6章。

对于这个例子的模型组织包含一个包名称为Automobile Domain。这个包是模型的顶层，其包含对应汽车例子的所有其它模型元素。模型组织显示一个包结构其包含包对应Use Cases、Behavior、Structure、Parametrics、IO Definitions、Viewpoints,Value Types和Vehicle。此外,Vehicle包包含3个内嵌包，分别为Requirements、Behavior和Structure。Use Cases、Behavior、Structure和Parametrics包包含有关车辆的语境和它的外部环境的模型元素,Vehicle包包含有关车辆设计的模型元素。IO Definitions包包含模型元素需要来明确说明接口，诸如，端口定义、和输入和输出定义。Viewpoints包被包含来定义选择的模型视图建模，其解决特定的利益相关者关注正如描述在第4.3.19节。Value Types包包含定义，其被使用来指定带有单位制的数量属性称为数值属性。建模构件在这个例子的剩余部分描述这些包的特定内容。

图4.1 包图显示模型如何被组织在包中，Automobile Domain包示例

1. 1. 1. 绘制Automobile Specification到一个需求图

车辆系统的需求图被显示在图4.2。图的右上角显示req，说明图的类型是需求图,并且图的名称为Automobile System Requirements。标题也说明图框架表示一个包。

图描绘典型的捕捉在一个文本规范中的需求。需求被显示在一个容器层次来描述它们之间的层次关系。Automobile Specification是一个顶层需求，其包含规范需求。顶部的十字准线符号表示容器。

图4.2 需求图显示系统需求包含在汽车规范中

Automobile Specification包包含需求：Passenger and Baggage Load、Vehicle Performance、Riding Comfort、Emissions、Fuel Efficiency、Production Cost、Reliability、Occupant Safety。Vehicle Performance需求包含需求Maximum Acceleration、Top Speed、Braking Distance和Turning Radius。每个需求包含一个唯一标识、文本、并可以包含其它用户定义的属性,诸如，验证状态和风险,典型的与需求关联。Maximum Acceleration需求的文本是“The vehicle shall accelerate from 0 to 60 mph in less than 8 seconds under specified conditions”，Fuel Efficiency需求的文本是“The vehicle shall achieve a minimum of 25 miles per gallon under specified driving conditions”。

需求可以被直接生成在SysML建模工具中,或它们可以被导入从一个需求管理工具或一个需求文本文档。需求可以与其它需求、设计元素、分析、和测试用例关联，使用derive、satisfy、verify、refine、trace和copy关系。这些关系可以被用来建立清晰的需求可追溯性，确保需求被满足和验证,并管理需求和设计的变更。这些关系的一些被强调在第4.3.18节。需求可以被表示使用多个显示选项来显示需求,它们的属性,和它们的关系,也包含一种表格形式的表示。第13章提供一种详细的描述需求如何被建模在SysML中,并在第17.3.7节提供对应建模需求的附加指导。

1. 1. 1. 使用一个模块定义图定义Vehicle和它的外部环境

在系统设计中,非常重要来标识什么是外部系统，可以直接或间接的与系统交互。模块定义图对应Automobile Domain在图4.3定义Vehicle和外部系统、用户、和其它实体，车辆可以直接或间接与它们交互。

模块（block）是一个非常通用建模概念在SysML中，被使用来建模结构实体,诸如，系统、硬件、软件、物理对象、和抽象实体。也就是,模块可以表示任何实际或抽象实体，可以被概念化作为一个结构单元带有一个或多个明确的特征。模块定义图绘制模块之间的关系，诸如，模块层次。

在图4.3的模块定义图显示包含在Structure包中的模块，正如说明通过标题。Automobile Domain是模块定义图中的最顶层，提供车辆的语境。模块由其它模块组成，正如说明通过黑色钻石标志和线的箭头方向指向其组成模块。这个整体-部分关系被称为组合关联（composite association）。组合的层次解释在第7.3.1节与容器是不同的(即,十字符号)其连接父到子，需求正如显示在图4.2。需求容器层次被描述在第13.9节。箭头旁边的名称在组合关联的组成部分一侧表示一个模块的一个特定用法,随后描述在第4.3.10节和第4.3.12节。Vehicle模块也包含构造类型«system of interest»使用一个书名号标志。其它模块是车辆的外部，包含Driver、Passenger、Baggage 和Physical Environment。注意，即使驾驶员、乘客、行李被假定为Vehicle物理内部的,它们不是车辆结构的部分，因此对车来说是外部的。

Driver和Passenger是Vehicle Occupant的子类，正如说明通过中空的三角形标志。这意味着，它们是Vehicle Occupant类型，它们继承通用特征从Vehicle Occupant。以这种方式,一个分类可以被生成通过指定模块从更通用的模块。

Physical Environment由Road、Atmosphere和多个External Entities组成。External Entities可以表示任何物理对象，诸如，一个交通灯或另外一辆车，驾驶员与其交互。Driver和一个External Entity的交互可以影响Driver如何与Vehicle交互，诸如，当交通灯从绿色变化为黄色或红色时，驾驶员应用刹车。多重性标志0..*表示最大数量不详的外部实体。多重性标志也可以表示一个正整数,诸如，4，或一个范围，诸如，0..4的的重性,对应乘客的数量。

正如先前描述的，每个模块定义一个结构化单元,诸如，一个系统、硬件、软件、数据元素、或其它概念实体。一个模块可以有一组特征集。模块的特征包含它的属性(例，重量),它的行为根据活动分配到模块或模块的操作,和它的接口正如定义通过它的端口。这些特征一起使一个建模者能来明确说明描述的层次，对于应用是协调的。

Road是一个模块，其有一个属性称为坡度（incline）使用单位制弧度（Radians）,和一个属性称为摩擦（friction）被定义作为一个实数。相似的Atmosphere是一个模块，其有2个属性对应温度（temperature）和空气密度（air density）。这些属性被使用与其它属性一起支持车辆加速和燃油效率的分析,讨论在第4.3.13到4.3.16节。

模块定义图指定模块和它们的组成部分的相互关系。常常被使用在系统建模中来描绘系统中的层次，层次从顶层域模块或语境模块(例，Automobile Domain)向下到表示汽车组件的模块。第7章提供模块如何在SysML建模中被详细描述,包含它们的特征和关系。

1. 1. 1. Operate Vehicle用例图

在图4.4是Operate Vehicle用例图，描述操作汽车的一个高层功能。用例被包含在use case包并包含Enter Vehicle、Exit Vehicle、Control Vehicle Accessory和Drive Vehicle。Vehicle是用例的主题，被表示通过矩形。Vehicle Occupant是一个参与者（actor），其在的外部，并被表示为贴片图。在一个用例图中主题(例，Vehicle)被使用通过参与者(例，Vehicle Occupant)来获得参与者的目标，定义通过用例(例，Drive Vehicle)。参与者被分配到相应模块在图4.3，这些元素之间建立一个等效。注：分配没显示在图中。

Passenger和Driver是车辆的乘员类型，正如描述在先前的章节。所有车辆乘员参与在进入和退出车辆和控制车辆配件,但仅驾驶员参与Drive Vehicle。

SysML提供能力来明确说明用例之间的联系。Enter Vehicle和Exit Vehicle用例包含Open Door用例。Open Door用例表示通用功能，常常被Enter Vehicle和Exit Vehicle用例执行。Enter Vehicle和Exit Vehicle作为引用用例的基础,和Open Door被引用到作为包含的用例。关系被称为包括或包含关系。Perform Anti-Lock Braking用例扩展基础用例称为Drive Vehicle。防抱死制动仅被执行在一定的条件下，正如明确说明通过扩展点称为Loss of Traction。这种联系被称为扩展或延伸,关联扩展的用例(即,Perform Anti-Lock Braking)到基础用例(即,Drive Vehicle)。除了包含和扩展联系,用例可以被明确说明正如指示通过Control Vehicle Accessory用例的子类。明确说明用例对应Control Climate Control和Control Entertainment System将共享Control Vehicle Accessory共享用例的通用功能,但也有它们自己唯一的功能与特定的配件关联。

用例定义使用贯穿在整个系统生命周期的系统目标,诸如，目标与制造、操作、和维护车辆关联。对于这个例子主要强调的是操作性对应Drive Vehicle用例，来解决车辆加速和燃油效率需求。第12章提供如何在SysML中建模的一个更详细的描述的用例。

需求常常被关联到用例，由于用例表示高层功能或系统的目标。有时,一个用例文本描述被定义来陪伴用例定义。一种方法来关联需求到用例被捕捉用例描述正如SysML需求和关联它们到用例使用一个细化（refine）关系。

用例描述系统的顶层目标，正如先前描述的。目标被完成通过参与者之间的交互(例，驾驶员)和主题(例，车辆)。这些交互实现通过更详细的行为描述，描述在下一节.

1. 1. 1. 使用一个序列图表示Drive Vehicle行为

Drive Vehicle行为对应的用例在图4.4中，表示通过序列图4.5。序列图说明驾驶员和车辆之间的交互通过生命线顶部的名称说明。时间过程垂直向下。第一个交互是Turn On Vehicle车辆。紧随其后的是驾驶员和车辆Control Power、Control Brake和Control Direction交互。这三个交互平行出现说明通过par。alt在Control Power交互上，表示对应可选的，并说明Control Neutral Power、Control Forward Power或Control Reverse Power交互发生根据vehicle state作为条件显示在括号内。在第4.3.8节的状态机图说明vehicle state。Turn Off Vehicle交互出现在这些交互之后。

使用在图中的交互，每个引用一个更详细的交互，说明通过ref。交互对应Turn On Vehicle引用在另外一个序列图中，在第4.3.6节说明。引用对一个Control Neutral Power、Control Forward Power和Control Reverse Power被分配到一个活动图，第4.3.7节描述。

1. 1. 1. Turn On Vehicle引用序列图

Turn On Vehicle序列图在图4.6中，是一个交互引用图4.5的序列图。正如先前描述的,时间过程垂直向下。在这个例子中,序列图显示驾驶员发送一个消息请求启动车辆。车辆响应回复vehicle on消息，显示为一条虚线。一旦驾驶员接收回复,驾驶员和车辆可以处理下一个交互。

序列图可以包含多种类型的消息。在这个例子中,消息是同步的，说明通过消息上填充的箭头。一条同步消息表示一个操作调用指定一个服务请求,发送者等待响应。操作调用的参数表示输入和返回的数据。消息也可是被异步的，表示通过一个开放的箭头,其中发送者不等待响应。

图4.3 汽车领域模块定义图显示车辆作为系统自身，与车辆使用者和环境一起，对应路面和大气也被显示

图4.4 用例图描述主要的功能，根据车辆如何被使用通过车辆乘员来操作车辆

图4.6的例子是非常简单的。更复杂的序列图可以包含多条生命线，和它们之间的多个消息交换，生命线表示交互的实体。序列图也提供相当强的附加功能来表达行为，包含其它消息类型、时间约束、附加的控制逻辑、和分解一条生命线的行为到它的组成部分之间的交互的功能。第10章提供了如何使用序列图建模交互的更详细描述。

图4.5 驾驶车辆的序列图描述驾驶员和车辆之间交互实现驱动车辆用例在图4.4.

图4.6 序列图对应‘Turn On Vehicle’的交互，起被引用在‘Drive Vehicle’序列图,显示消息来自驾驶员请求车辆启动,和汽车相应使用汽车在响应上

1. 1. 1. Control Power活动图

序列图是有效的表示聚焦在控制流上的分离类型行为的方法，正如说明使用Turn On Vehicle序列图在图4.6。然而,行为的持续类型与交互关联来Control Power、Control Brake和Control Direction有时可以是非常有效的使用活动图表示。活动图也使用来处理更复杂的输入和输出流。

Drive Vehicle序列图在图4.5包含引用到控制Control Neutral Power、Control Forward Power和Control Reverse Power。活动图可以被用来表示持续的详细交互。为完成这一点Control Neutral Power、Control Forward Power和Control Reverse Power之间的交互分配到一个相应的Control Power活动图使用SysML分配联系(没显示)。活动被包含在Behavior包中。

活动图在图4.7显示驾驶员和汽车需要的动作（action）来控制动力。活动分区(或泳道)表示驾驶员和车辆。动作在活动分区中明确说明驾驶员和车辆必须执行的功能需求。

当活动被初始化后,开始执行初始节点(即,填充的圆),并随后初始化被执行通过驾驶员的Control Accelerator Position和Control Gear Select动作。Control Accelerator Position动作的输出是Accelerator Cmd,其是一个持续的输入到汽车必须执行的Provide Power动作来。Control Gear Select动作生成一个输出称为Gear Select。Provide Power动作的输出是持续力矩生成从车轮到加速车辆。当Ignition Off信号被接收(称为一个接收事件动作),活动终止在活动最终节点(即,靶心标志)。基于这个场景,驾驶员需要来Control Accelerator Position和Control Gear Select,并为提供车辆需要的动力。Provide Power动作是一个调用行为动作，当它执行时调用一个更详细的行为，被表示在图4.11。(注:«continuous»不是基础特征集的部分。)

活动图包含语义来精确说明行为根据控制流和输入和输出流。控制流被使用来明确说明动作的序列,表示通过一条带有箭头的虚线在一个终点上在图4.7中。对象流用来说明流的输入和输出,其被表示通过在动作的矩形引脚上。对象流(即,带箭头的实线)连接输出端口从一个动作到另外一个动作上的输入端在。第9章提供一种活动如何被建模的详细描述。

1. 1. 1. Drive Vehicle States状态机图

Drive Vehicle States状态机图显示在图4.8。这个图显示车辆的状态、和可以触发车辆状态变更的事件。

当车辆准备被驾驶时,它的初始状态是vehicle off。ignition on触发一个汽车状态转变到vehicle on。有关状态转变的文本说明，Start Vehicle行为结果来自start vehicle消息在图4.6被执行，优先于进入vehicle on状态。进入vehicle on状态后,一个entry行为被执行来Check Status来确认车辆正常。紧跟完整的entry行为,汽车初始化Provide Power行为称为一个do行为，其被引用在图4.7的活动图中。

一旦汽车已经进入vehicle on状态,它很快转变到neutral状态，一个forward select事件触发一个转变到forward状态，如果看门狗条件：speed>=0 是true。neutral select事件触发转变从向前的状态返回到中性的状态。状态机图显示附加的neutral和reverse状态的转变。一个ignition off事件触发转变返回到vehicle off状态。优先于退出vehicle on状态并转变到vehicle off状态,它执行一个退出行为来Turn Off Accessories。从vehicle off状态,汽车可以重新进入vehicle on状态，当一个点火事件发生时。

状态机可以明确说明一个模块的生命周期行为根据它的状态和变化,并被常常与序列图和/或活动图一起使用,正如显示在这个例子中。状态机有许多其它特征，被描述在第11章,包括支持多个区域来描述并发行为和附加的转变语义。

图 4.7 活动图分配控制平稳行驶、向前、和倒车动力交互使用，其被引用在驾驶车辆序列图在图4.5

1. 1. 1. 使用一个内部模块图定义Vehicle Context

Vehicle Context图被显示在图4.9。图显示车辆、驾驶员和物理环境之间的接口(即,路面、大气、和外部实体)，定义在模块定义图4.3。车辆与驾驶员,大气,和路面之间有接口。驾驶员与外部实体之间有接口，诸如，一个交通灯或另外一个车辆,通过传感器输入到驾驶员。然而,汽车没有直接的与外部实体的接口。外部实体的多重性与多重性显示在模块定义图在图4.3是一致的。

这个语境图是一个内部模块图，其显示Automobile Domain模块的组成部分来自图4.3如何被链接。它被称为一个内部模块图由于它表示一个高层模块的内部结构,其在这种情况下是Automobile Domain模块。汽车的端口被表示作为在组成部分边界上小的正方形,并明确说明接口使用其它组成部分。连接器被表示作为端口之间的一条线,并定义组成部分如何互相连接。组成部分也可被连接不需要端口正如说明通过一些接口在图中,当接口的细节不是建模者感兴趣的细节。

外部接口需要对应汽车来提供动力被显示在图4.9。后轮胎和和路面之间的接口被显示,由于车辆被假定到后轮驱动。接口到两个后轮胎被显示由于动力可以被分布不同到左后轮胎或右后轮胎依赖于轮胎到路面的牵引和其它因素。前轮胎和路面之间的接口没显示在这个图上。仅表示感兴趣的方面在一个特定的图上，是通用的建模实践，尽管额外的信息可以被包含在模型中。

在连接器上的黑色实心箭头被称为项流（item flows），表示流动项在组成部分之间和可以包含质量、能量、和/或信息。在这个例子中,Accelerator Cmd被先前定义在活动图在图4.7，流从Driver Foot IF到车辆的Accelerator IF,和Gear Select流从Driver Hand IF到Gear Select IF在车辆上。对象流，其连接输入到输出在图4.7的活动图中，分配到在内部模块图中的连接器上的流动项。分配被讨论作为一个通用的关系对应映射一个模型元素到另外一个在第14章。

SysML端口提供物理上的功能对应建模组成部分之间的接口。端口可以明确说明项的类型，其可以流进或流出一个组成部分,和服务被需要或提供通过一个组成部分。端口提供一种机制来集成系统的行为与它的结构通过通过使能存取到一个组成部分的行为。在SysMLv1.3中,端口被物理的增强超过SysML v1.2，并且SysML v1.2端口的一些方面被丢弃。讨论在第7.6和第7.9节获取详细信息。

内部模块图使建模者能明确说明一个系统或组件的内部和外部接口。一个内部模块图显示组成部分如何被连接,正如区别与一个模块定义图，模块定义图不显示端口和组成部分之间的连接器。内部模块图建模的细节被描述在第7.3节。

图4.8 状态机图显示驱动车辆的状态,和它们之间的转变

图4.9 内部模块图对应车辆域描述汽车语境,其显示车辆和它的外部接口与定义在图4.3的驾驶员和物理环境

1. 1. 1. 表示Vehicle Hierarchy在一个模块定义图上

这里聚焦说明，汽车与外部系统之间的交互和它们的接口。图4.10的Vehicle Hierarchy是一个模块定义图，其显示车辆的分解其被先前显示在它的组件中。车辆由车体、底盘、内饰、动力传动、和其它组件。每个硬件组件被设计作为«hardware»。

Power Train被进一步分解成Engine、Transmission、Differential和Wheel。注：right rear和left rear说明一个车轮的不同用法在动力传动语境中。因此,每个后轮有一个不同的功能和可以可以是不同力的主题,诸如，情形当一个车轮失去牵引。前轮没有显示在这个图中。

发动机可以是4缸或6缸，正如指示提供规范的关系。在考虑满足加速和燃油效率需求的情况下4缸和6缸发动机配置是可选的。engine size是{complete,disjoint},其隐含，4缸和6缸发动机表示所有可能的发动机类型对应这辆车,并且配置是互相排斥的。(注:这个构件被称为一个通用集和不是SysML基础特征集的部分。)

Vehicle Controller «software»已经被分配到Vehicle Processor正如指示在分配舱段。Vehicle Processor是车辆控制软件的执行平台。在这个例子中,软件控制许多车辆发动机和变速箱功能来优化发动机的性能和燃油效率。

燃油被显示在一个Fuel Tank模块的一个引用属性舱段。它被说明作为一个引用由于它不是燃油箱的部分。

组件之间的交互与互联，被表示以一种前面描述的相似的方式作为汽车黑盒交互与互联。建模构件在这个设计的层级被使用来明确说明车辆系统的组件正如描述在下一个小节。

1. 1. 1. Provide Power活动图

活动图在图4.7显示，车辆必须提供动力响应驾驶员加速命令和生成转矩在路面上。Provide Power活动图显示在图4.11，车辆组件如何生成这个力矩。

外部输入到活动包含来自驾驶员的加速指令和齿轮选择,和来自大气空气来支持发动机燃烧。来自活动的输出是力矩输出来自右和左后轮到路面来加速车辆。其它的一些输入和输出,诸如，发动机排气,为了简化没有包含。活动划分表示显示在模块定义图在图4.10中的汽车组件的用法。

汽车控制器接收驾驶员输入包含加速指令和齿轮选择,并提供输出到发动机和变速箱。燃油箱存储燃油并分配燃油给发动机。fuel-Air Cmd,来自汽车控制器和空气来自大气是输入到Generate Torque动作。发动机力矩Amplify Torque动作的输入执行通过变速箱。放大的力矩是输入到Distribute Torque动作执行通过离合器,分布力矩到右和左后轮。车轮提供牵引到路面平面生成力来加速车辆。离合器监控和控制后轮的转矩差异。如果一个车轮失去牵引,离合器发送一个Loss of Traction信号到刹车系统来进行刹车。Loss of Traction牵引信号被发送使用一个发送信号动作。

值得注意在这个例子中很少的项。流被显示将是持续的，对应所有除了齿轮的选择。持续流的输入和输出是动作的输入和输出。持续意味着一个很小的时间（delta）在0输入和输出到达之间。持续流构件在流输入和输出参数的概念上,其意味着，输入被接收和输出被生成，在动作执行的同时。相反,非流输入进可用优先于动作执行的开始，并非流输出被输出仅在动作完成执行时。表示流和持续流的能力增加了一个明显的功能来典型的行为建模使用功能流程图。持续流被假定将是流，但这没显示在图上。持续流不是基础特征集的部分。

许多其它活动图特征被解释在第9章,其提供一个功能来精确明确说明行为根据数据流和控制流。

1. 1. 1. Power Subsystem内部模块图

先前的活动图描述系统的组成部分如何交互来提供动力。系统的组成部分被表示通过活动划分在活动图中。车辆的内部模块图在图4.12显示组成部分如何来互联获得这种功能,和被使用来明确说明 组成部分之间的接口。这是一个系统的结构化视图和行为视图起被表示在活动图中。

内部模块图显示Power Subsystem，其仅包含汽车的组成部分，通过交互提供动力。图的框架表示汽车黑盒。在图4.12的上图框架端口对应相同的端口显示在汽车在Vehicle Context语境图在图4.9。外部接口被保留作为汽车汽车的内部结构被进一步明确说明。

发动机、变速箱、离合器、右后和左后轮、车辆处理器、和燃油箱被互联通过它们的端口。燃油被存储在油箱正如说明通过«store»。燃油被表示通过一个虚线的矩形来说明，燃油不是燃油箱的部分。仅选择流动项被显示在连接器上。流动项被分配从输入和输出在提供动力活动图在图4.11中。

每个子系统可以被表示以一种相似的方式正如动力子系统来实现特定功能,诸如，提供刹车和提供转向。对应每个内部模块图封闭的框架可以是相同的车辆模块,但每张图仅包含组成部分关联到特定的子系统。这个方法可以被用来表示一个车辆内部结构的子系统视图。来表示一个内部模块图对应一个转向子系统，例如,附加的组件会需要被定义，再向后那些显示在模块定义图在图4.10来包含方向车轮、转向柱、动力转向泵、转向连杆、和前轮。一个所有互联的组成部分的组合视图对应所有子系统也可被生成在一个组合车辆内部模块图。抽象的合适层次必须被用来管理信息在这个图上。

图4.10 汽车层次模块定义图显示车辆和它的组件，力传动被分解到组件,和车辆处理器包含汽车控制软件

 

图4.11提供动力的活动图显示汽车组件如何生成力矩来使车辆移动。

适当的来详细说明关于定义和使用的概念，其 被首先介绍在第4.3.10节，当讨论右后和左后车轮时。一个部分一个内部模块图表示一个模块的一个特定用法。模块表示通用定义,其中作为组成部分表示一个模块的一个用法在一个特定的语义中。因此,在图4.10和图4.12中,右后和左后是不同的车轮模块的用法在动力传动语境中。每个模块的唯一用法，一个后轮对比一个左后轮,需要一个新的组合关联在模块定义图。冒号(:)符号被使用在图4.12来区分组成部分(即,用法)和模块(即,定义)。表达式到右侧的转向杆,车轮,是通用的定义。表达式到左侧的转向杆,右后和左后,是通用车轮的特定用法。一个组成部分使能相同的模块,诸如，一个车轮,将被重用在许多不同的语境中和被唯一的标识通过它的用法,诸如，右后和左后。每个组成部分可以有唯一的行为,属性,和约束，其应用到它的特定用法。

图4.12 内部模块图对应动力子系统显示汽车的组成部分如何提供相互的提供动力。

定义和用法的概念被应用到许多其它SysML语言构件。一个例子是流动项可以有一个定义和用法。例如,一个流动项输入油料箱可以是in:Fuel和流动项输出油料箱可以是out:Fuel。两个项流都使用油料，但“in”和“out”表示燃油的的不同用法在汽车语境中。

正如先前提及的,第7章提供详细的语言描述对应模块定义图和内部模块图,和许多其它关键概念来建模块和组成部分。

1. 1. 1. 定义等式来分析车辆性能

关键的需求对应这个车辆的设计是来加速从0到60mph在小于8秒内，而同时达到一个燃油效率大于25英里每加仑。这两个需求在设计空间是冲突需求,由于提升车辆的大加速度能力可以导致一个地燃油效率的设计。两个可选的配置,包含一个4缸和6缸发动机,被评估来确定，那个配置是好的解决方案来满足加速和燃油效率需求。

4缸和6缸发动机被选方案被显示在车辆层次树在图4.10。这里是其它设计影响可以导致车辆配置使用不同的发动机,诸如，车辆重量的影响、车体形状、和动力。这个简化的例子仅考虑对动力子系统的影响。汽车控制器被假定来控制油料和空气混合,并也控制当齿轮变更在自动化的变速箱中,来优化发动机和整体性能。

Analysis Context模块定义图4.13，被使用来定义等式对应分析。图引入一个新的类型模块被称为约束模块。代替定义系统和组件,约束模块定义约束根据等式和他们的参数。

在这个例子中,Vehicle Acceleration Analysis模块处于参数图中，说明通过标题,和由一些约束模块组成，其被使用来分析汽车加速。这个分析被执行来确定是否是一个4缸或6缸配置可以满足它的加速需求。约束模块定义通用的等式对应Gravitational Force,Drag Force、Power Train Force、Total Force、Acceleration和一个Integrator。Total Force等式,例如,显示ft是fi,fj,和fk的总和。注：参数被定义带有它们的单位制在约束模块中。

动力传动力被进一步分解成其它约束模块，其表示力矩等式对应发动机,变速箱,离合器,和车轮。等式不是显式定义的,但等式的关键参数被标识。非常有用在一个分析的早期阶段来标识关键的参数,并推迟等式定义直到详细的分析被执行。

Vehicle Acceleration Analysis也引用Automobile Domain模块，作为初始的显示在模块定义图在图4.3。车辆域表示分析的主题。这使汽车的属性和物理环境,可以作为车辆域的部分,显式绑定到通用等式的参数,正如描述在下一节。

1. 1. 1. 分析车辆加速使用参数图

先前的模块定义图定义等式和相关的参数需要来分析系统。参数图在图4.14显示这些等式如何被使用来分析时间对应车辆来加速从0到60mph和满足最大加速需求。图框架表示Vehicle Acceleration Analysis模块来自图4.13的模块定义图。

参数图显示一个网络的约束(等式)。每个约束是一个约束模块的一个用法定义在模块定义图在图4.13。等式的参数被显示作为小的矩形填充使用约束的内部边界。总的力约束被显示在这个参数图上,但其它等式没显示。

图4.13 模块定义图对应分析语境，其定义等式对应分析汽车加速需求

一个参数在一个等式中可以被绑定到一个参数在另外一个等式中通过一个绑定连接器。这种的一个例子时参数ft在总的力等式中，其被绑定到参数f在加速等式中。这意味着ft在总的力等式中，等于f在加速等式中。

参数也可被绑定到模块的属性来使参数值等于属性值。属性被显示作为矩形内嵌在组成部分内部。一个例子是绑定阻力系数参数cd在阻力等式到drag属性称为阻力系数（drag coef）,其是汽车车体的一个属性。有时非常有效来不显示组成部分,和标识属性使用‘.’符号。阻力系统会被标识作为ad.v.b.drag coef来说明，这是一个车体的一个属性,其是车辆的组成部分，是汽车域的组成部分。另外一个例子是绑定路面倾斜的角度theta在重力等式中。这个绑定是通用等式的值将被设置等于模块的特定属性的值。以这种方式,通用的等式可以被用来分析许多不同的设计通过绑定参数到不同设计的属性。

参数图和相关的建模信息可以被提供到响应的仿真和/或分析工具来支持执行。这个工程分析被使用来执行敏感性分析和确定属性值，其被需要来满足加速需求。在这个例子中,进很少的车辆属性被显示。然而,一个更完整的表示会绑定车辆属性到约束参数中的每个。虽然没有显示在图4.14,动力传动力约束包含内嵌的约束与约束模块一只，其组成它在分析语境模块定义图在图4.13。

图4.14 参数图使用等式定义在图4.13来分析车辆加速度

此外对于加速和燃油效率需求,其它分析可以解决需求对应刹车距离,车辆处理,振动,噪声,安全性,可靠性,生产成本,等等。这些其它分析可以被执行来确定系统组件的需要值(例，车体、底盘、发动机、变速箱、离合器、刹车、导装配)来满足整体系统需求。参数使系统的关键设计属性将被标识和集成使用参数在分析模型中。如何来建模约束模块的细节和他们的用法在参数图中被描述在第8章。

1. 1. 1. 分析结果来自分析车辆加速

正如先前的章节提及的,参数图被期望将被执行在一个工程分析工具来提供分析的结果。这可以是一个分隔的特定分析工具，其不提供作为SysML建模工具的部分,诸如，一个简单的电子表格或一个高保真的性能仿真依赖于需要。分析结果来自执行随后提供值，其可以被分配到特定系统属性,和不协调回到SysML模型。

来自执行约束的结果在参数图被显示在图 4.15。这个例子使用UML时间图来显示结果。虽然时间绘图不是SysML图的类型,它可以被使用与SysML的衔接中，它对于分析是有用的,伴随其它更健壮的可视化方法来表示多参数关系,诸如，响应面。在这个时间图中,车辆速度属性被显示作为一个时间的函数,和车辆状态被显示作为一个时间的函数。车辆状态对应到内嵌的状态在向前状态的内部在图4.8中。基于分析执行6缸(V6)汽车配置能满足它的加速需求。一个相似的分析显示，四缸(V4)汽车的配置不能满足需求。

1. 1. 1. 定义车辆控制器动作来优化发动机性能

分析结果显示V6配置被需要来满足车辆加速需求。附加的分析被需要来评估，在规定的驾驶条件下,是否V6配置可以满足燃油效率需求对应一个最小25英里/加仑，正如指定燃油效率需求在图4.2。

Provide Power活动图在图4.11被使用来支持需要来优化燃油效率和发动机性能的分析。:Vehicle控制车辆处理器的执行正如描述在第4.3.10节,和包含一个动作来控制燃油空气混合，其控制发动机加速指令。这个动作的输入包含加速指令来自驾驶员,和发动机参数，诸如，每分钟的转数(RPM)和发动机温度来自发动机。发动机控制器也包含含Control Gear动作来确定，当来变更齿轮基于发动机速度(即,RPM)来优化性能和燃油效率。车辆控制器软件的规范可以包含一个状态机图，其变更状态响应输入与状态机图在图4.8中的协调。

算法的规范来实现Vehicle Controller动作需要进一步分析。算法可以被表示通过详细的指定动作作为数学和逻辑表示，可以被绘制在一个更详细的活动图或直接在代码中。一个参数图也可被开发来指定算法的性能需求，其约束Vehicle Controller动作的输入和输出。例如,约束可以指定需要的燃料和空气混合作为RPM的一个功能和发动机温度来获得优化的油效率。算法必须满足这些性能约束通过控制燃料的流量和进气,和或许其它参数。基于工程分析,其详细的情形在这里被忽略,V6发动机能满足燃油效率需求和加速需求,和被选择作为理想的车辆系统配置。

1. 1. 1. 指定车辆和它的组件

模块定义图在图4.10定义模块对应车辆和它的组件。模型被使用来指定汽车和每个它的组件根据它们执行的功能,它们的接口,和它们的性能和物理属性。规范的其它方面可以包含一个状态机来表示基于系统和它的组件行为的状态,和项的规范被存储通过系统和它的组件,诸如，燃油在油料箱或在计算机内存中的数据。

6缸发动机模块一个简单的例子是规范，显示在模块定义图在图4.16。发动机模块和6缸发动机模块被初始化显示在车辆层次模块定义图在图4.10。

在这个例子中,发动机硬件元素执行一个功能称为生成力,其被显示作为一个模块的操作在opration舱段。这个操作对应到生成力矩动作在图4.11。在模块上的端口指定它的接口，正如：Air IF、Fuel IF、Engine Control IF和Engine Out IF。选择发动机的数值属性发动机被显示在表示的值舱段，其表示它的性能和物理属性包含它的位移,燃烧效率,最大功率,和重量。数值类型键入每个数值属性来指定它的数据结构(例，整数,实数)和它的单位制(例，百分比,立方英寸)。

6缸发动机模块是一个通用的发动机模块的子类,和继承所有特征来自发动机。然而,6缸发动机是一个特定的发动机其包含6个缸正如说明在它的零件舱段。此外,6缸发动机可以定义值对应每个数值属性包含在通用发动机,诸如，最大功率和重量。这个信息衍生自参数分析讨论在第4.3.13节到第4.3.15节。

其它车辆的组件可以被指定以一种相似的方式。如果期望,文本需求可以是书写到对应的功能,接口,性能和物理需求与每个模块关联来生成传统的文本规范从模型。

图4.15分析结果来自执行约束在参数图在图4.14, 显示车辆的速度属性和车辆状态作为一个时间的函数。

1. 1. 1. 需求可追溯性

汽车系统需求被显示在图4.2。捕捉基于文本需求在SysML模型中提供手段来建立基于文本需求和模型的其它部分之间的可追溯性。

最大加速度需求的可追溯性被显示在图4.17。这个需求追溯到一个市场分析,其被推倒在系统需求分析支持中。需求被满足提供提供动力活动其被显示在图4.11。最大加速度测试案例也被显示作为方法来验证需求被满足。此外, 从最大加速度需求的发动机推力需求衍生而来并包含在发动机规范重。衍生需求的原理引用到车辆加速分析参数图在图4.14。6缸发动机模块提炼发动机规范通过精确表示文本需求在规范中的目的。上面的关系使能可追溯性从系统需求到系统设计、测试用例和分析、同时提供原理。

箭头方向指向从提供动力活动,最大加速度测试案例,和发动机最大推力需求到最大加速度作为原始需求。这些处于相反的方向，从被常常用来来表示需求的细化。方向反映了设计,测试案例,和衍生需求从原始需求，这样原始需求的变更,设计,测试案例,衍生的需求也将需要来变更。

需求被支持通过多种符号选项，包含直接直接的、舱段、标注、和表格表示。SysML需求和它们的联系如何被建模被详细描述在第13章。

图4.16 模块定义图显示发动机模块和特征使用来指定模块

图4.17 需求图显示最大加速度需求的可追溯性，其被显示汽车规范在图4.2。可追溯性到一个需求包含设计元素来满足它,其它需求衍生自它, 和一个测试案例来验证它。原理对应deriveReqt 关系也被显示

1. 1. 1. 视图和视点

SysML 包含视图和视点的概念来对应不同利益相关者的视角。在图4.18中,架构和监管机构的视点分别反应系统架构和国家高速路交通安全性管理的利益相关者的关注。视点包含利益相关者的标识,关注,和方法用来构建模型的一个视图来解决它们的关注。在这个例子中,系统架构被关注关于燃油经济性与加速度的权衡,和政府的法规被关注关于车辆的能力来满足安全性需求。视图被构建来反映模型的子集，其解决它们的关注。正如指示在图中，车辆的性能视图符合架构视点通过提供可追溯性到燃油效率和加速需求并关联设计原理。车辆安全性 监管视图符合监管机构的视点通过提供安全性需求、测试用例、和测试结果。建模工具可以构建视图根据文档和报告来自模型信息使用图的一个组合,表格符号并,和其它输出报告,包含文本文档。

图4.18 包图显示架构视点来解决关注的联到燃油经济性和加速权衡, 和一个监管机构的试点来解决关注关联到满足安全性需求

1. 1. 模型互换

系统建模的一个重要方面是在工具之间交换信息的能力。一个SysML模型被绘制在一个模型库中，可以被导入和导出从一个SysML兼容工具以一个标准格式称为XML元数据交换(XMI)。如果其它工具也支持XMI，也可以交换这些信息，。一个例子可以是功能来导入选择的SysML模型的组成部分到一个UML工具来支持软件开发车辆控制器软件,或来导入和导出需求从一个需求管理工具,或来导入和导出参数图和相关信息到工程分析工具。获得无缝交换能力的功能可以是有限的通过模型的质量并通过工具的有限性与标准兼容。第18章包含XMI的一个描述XMI和一个SysML如何满足系统开发环境的更广泛的讨论。

1. 1. 小结

SysML基础特征集是语言的一个子集，其被需要学习对应的先前的两个层级的SysML认证,称为模型使用者和模型基础构建者层级。一个建模者可以解释和构建模型使用SysML基础特征集可以是一个明显的贡献者到一个系统建模努力。学习完整的特征集被需要对应认证的第三级称为模型构建中级。基础特征集被应用到所有9类SysML图。

一个SysML模型可以被用来指定、设计、分析、和验证一个系统,和不同方面将被表示在一个精确、协调的、和容易理解的习惯。系统模型可以被表示通过9种SysML图，以及表格和其它表示，在后续章节详细说明。

• 包图：表示一个模型的组织根据包，其包含模型元素
• 需求图：表示基于文本需求和与它们之间的联系
• 需求,设计元素,和测试用例来支持需求可追溯性
• 活动图：表示行为根据次序，在其中动作执行基于它们的输入、输出、和控制的可用性，和动作如何转化输入到输出。
• 序列图：表示行为根据消息的一个序列交换在系统之间,或系统的部分之间
• 状态机图：表示一个实体的行为根据它在状态之间的转变，触发通过事件用例图表示概念根据一个系统如何被使用通过外部实体(即,演员)来完成一组目标集
• 模块定义图：表示结构元素称为模块,和它们的分解和分类
• 内部模块图:表示一个模块的零件之间的互联和接口
• 参数图:表示约束在属性值上,诸如，F=m*a ,使用来支持工程分析
  1. 问题

1. 显示一个停车距离需求如何捕捉到图4.2。
2. 在下面的问题中,假定一个变更在停车距离被需要。
3. 您能预见任何变化在图4.3的模块定义图吗?
4. 您能预见到任何明显的变化在图4.4的用例图吗?
5. 您能预见任何明显的变化在图4.5的序列图吗?
6. 描绘一个活动图类似于图4.7来解决刹车需求。
7. 描绘一个类似于图4.9的内部模块图来解决刹车需求。
8. 描述附加到汽车层次在图4.10来解决刹车需求。
9. 描绘一个类似于图4.11的活动图来解决车辆刹车如何被执行。
10. 描绘一个类似于图4.12的内部模块图对应车辆刹车子系统。
11. 描绘一个类似于图4.13的模块定义图来定义等是需要来分析车辆的刹车距离性能。
12. 描绘一个类似于图4.14的参数图来描述分析被使用来分析刹车距离性能。.
    1. 1. 讨论主题

什么是有关模型的变化的一些观察，其发生作为一个需求变更的一个结果，诸如，那一个上面描述的(即,刹车距离性能)?