机载软件设计技术思维和技术基础

机载软件设计技术的思想（计算的原理）

计算与计算机器

1. 机载软件设计技术核心要求

    机载软件核心：高可靠，高安全
    设计技术核心：建模、分析、验证

2. 什么是计算？

    个人回答：根据输入从开始状态经过有限步的状态转换，并对这个输入进行修改最终到达结束状态或停机状态得到输出的这个过程。并且这个过程无二义性。

    图灵眼中的计算：就是一个读写头在一条纸带上按照一个状态转移图进行操作的过程。

    1: 计算通过在一条被划分成方格的纸带上写下符号来进行
    2: 执行计算的人在每一步都只注意其中一个方格的符号
    3: 她的下一步仅仅取决与这个符号 和 她的头脑中的状态
    4: 她的下一下将做:
    她在当前注意的方格里写下一个符号,
    然后 把注意力转向它的左边或者右边的相邻方格

3. 以运算器为中心的冯诺依曼计算机

计算思维

1. 定义

   计算思维是运用计算机科学的基础概念进行问题求解、系统设计、以及人类行为理解等涵盖计算机科学之广度的一系列思维活动。

   

机载系统

机载软件不能脱离系统。把机载软件当作复杂的系统来考量。

机载软件系统属于复杂安全关键系统

发展趋势：综合模块化，分布式体系化，可软件定义

机载软件的重要性：

    1. 软件规模越来越大
2. 软件比重越来越大
    3. 软件复杂度越来越高
4. 软件问题越来越突出

计算与系统工程

1. 系统与系统工程

   1. 系统

       我们把极其复杂的研制对象称为“系统”，即由相互作用和相互依赖的若干组成部分结合成的具有特定功能的有机整体，而且这个“系统”本身又是它所从属的一个更大系统的组成部分。

   2. 系统工程

       “系统工程”是组织管理“系统”的规划、研究、设计、制造、试验和使用的科学方法，是一种对所有“系统”都具有普遍意义的科学方法。

   3. 强有力的工具
      系统工程不仅需要科学理论工具，而且需要强有力的运算手段——电子数字计算机

2. 基于模型的系统工程（MBSE:model-based systems engineering method）

   

   研发思路

   1. 基于MBSE的基本V型模型

   2. 通过数字模型对系统进行描述，实现方案的早期动态仿真

   3. 实现以模型为核心的研发模型数据中心建立研发数据的关联

   4. 实现继承性设计，设计数据通过模型方式传递，可自动生成设计文档

   5. 实现可追溯性验证，验证数据来自上游设计结果，验证结果可以自动反馈到设计需求，可自动生成验证文档

   6. 建立具备支撑上述过程的工具链体系

软件设计的工程化

SysML是对UML的一个扩展。

软件的过程管理与控制： CMM / CMMI

需求建模（思想、标准、建模）

机载软件的适航标准（DO-178B/C）

适航

• 航空器能在预期的环境中安全飞行（起飞和着陆）的固有品质，这种品质可以通过合适的维修而继续保持。

• 要考虑： 飞机的运行环境、正常操作下的安全、使用寿命内的安全性，符合标准的维修。

• 如何确定民机的安全标准：安全水平应等同于人的自然意外死亡率。

DO-178B是”机载系统和设备合格审定中对软件的考虑”，是做什么而不是怎么做。

DO-178C

目的：为机载软件的研制提供指南，保证其按照适航要求的安全性实现其预期功能

内容：各软件生命周期过程中所要达到的目标；
            为达到目标实施的工作和设计考虑；
            表明目标已满足的以软件生命周期数据的形式描述的证据；
            因等级不同，在目标（objectives）、独立性（independence,）、数据（software life cycle data）、构型控制（control categories）上的不同；
            各项特殊考虑（PDS（previously developed software）等）；
            定义和术语

66个目标：

6个过程：

20个资料：

与软件开发相关的系统方面

分配给软件的系统需求

包括与安全相关的需求，被开发并细化为软件需求，通过软件验证过程活动验证并验证。

• 功能和操作方面的要求。

• 接口要求。

• 性能要求。

• 系统安全目标。

• 与安全相关的要求，包括安全策略、设计约束和设计方法，如分区、差异、冗余或安全监控。如果系统是另一个系统的组成部分，则该其他系统的需求和故障条件也可以构成分配给软件的系统需求的一部分。

• 安全要求。

• 维护要求。

• 认证要求，包括任何适用的认证机构规定、签发文件等

• 辅助系统生命周期过程所需的额外要求。

系统和软件生命周期过程之间的信息流

包括：从系统流程到软件流程的信息流、从软件流程到系统流程的信息流以及软件与硬件之间的信息流。

软件生命周期过程分析确定的系统需求不充分或不正确可能会影响系统安全评估和系统需求细节和修改

系统安全评估流程和软件级别

软件错误可能是潜在的，因此，不会立即产生故障。导致从软件错误到故障状态的事件序列可能很复杂，并且不容易用一系列事件来表示。

故障状态分类

1. 灾难级（Catastrophic）：会导致多人死亡，通常是由于飞机的失事。

2. 危险级（Hazardous）：会降低飞机能力或机组人员应对不利操作条件的能力。（大幅降低、会造成严重或致命伤害）

3. 严重级（Major）：会降低飞机能力或机组人员应对不利操作条件的能力。（显著降低、可能受伤）

4. 轻微级（Minor）：不会显著降低飞机安全的故障条件及机组人员在其能力范围内的行动。（轻微、不适）

5. 无影响级（No Effect）：对安全没有影响。

软件等级

用后续软件开发的生命周期数据来验证应用程序具有更高的软件级别可能是困难的。

如果一个软件组件的异常导致了多个故障条件以最严重的评级

对于由操作规程规定的，但不影响飞机的适航性的机载系统和设备。在某些情况下，软件级别可以在设备的最低性能标准中指定。

1. Level A：系统安全评估过程中显示的异常会导致或加剧系统功能故障并导致飞机出现灾难级故障。

2. Level B：系统安全评估过程中显示的异常会导致或加剧系统功能故障并导致飞机出现灾难级故障。

3. Level C：系统安全评估过程中显示的异常会导致或加剧系统功能故障并导致飞机出现严重级故障。

4. Level D：系统安全评估过程中显示的异常会导致或加剧系统功能故障并导致飞机出现轻微级故障。

5. Level E：系统安全评估过程所显示的异常将导致或加剧系统功能故障，而不影响飞机操作能力或飞行员工作量。

软件规划过程

目标：定义生产能够满足系统需求的软件的方法，并提供与软件水平相一致的置信度水平。

软件开发过程

软件开发过程要保证可追溯性。

1. 软件需求过程

通过对系统需求和系统架构的分析，直接产生高级需求。通常，这些高级需求会在软件设计过程中得到进一步的开发，从而产生一个或多个连续的、较低级别的需求。但是，如果源代码是直接从高级需求生成的，那么高级需求也被认为是低级需求。低级需求是指软件需求，其中源代码可以直接实现，而不需要进一步的信息。

2. 软件设计过程

高级需求通过软件设计过程中的一个或多次迭代进行改进，以开发软件体系结构和可用于实现源代码的低级需求。

3. 软件编码过程

在软件编码过程中，源代码是从软件架构和低级需求中实现的。

开发的源代码是可追踪的、可验证的、一致的，并正确地实现了低级需求。

4. 软件集成过程

将软件编码过程中的目标计算机、源代码和目标代码与链接和加载数据一起使用，以开发集成的系统或设备。

可执行对象代码将被加载到目标硬件中，以进行硬件/软件集成。

软件验证过程

软件验证过程按照软件规划过程和软件验证计划的定义对输出进行的技术评估。

系统设计建模 （Enterprise Architect软件）

SysML（System Modeling Language）复杂系统的建模语言

SysML 是一种表述（Specifying）、分析、设计以及验证复杂系统的通用图形化建模语言；复杂系统可能包括软件、硬件、信息、人员、过程和设备等其他系统元素。

静态视图：定义结构化的元素 (模块) 和他们之间的关系

动态视图：定义系统范围• 组织需求到用例中  (“内容表”)

SysML通用结构（外框、内容框、头部）

头部包含（图的类型：图的缩写即表示图的类型；模型元素类型：图所表示的模型元素是模型层级关系；模型元素名称：用户自定义；图的名称：用户自定义。）示例：

SysML中的结构模型（Structure）

模块定义图 （BDD：Block Definition Diagram）

类似UML中的类图，可以通过该图展示不同类型的模型元素和组合来说明系统结构的信息。

在模块定义图中显示的模型元素有：模块、执行者、值类型、约束模块、流说明、接口等。

不同时期的作用：

• 在系统分析阶段：模块定义图主要用于表达 角色和提供系统行为的实体的职责；

• 在系统设计阶段：模块图主要用于表达 组成系统体系结构的模块结构；

• 系统编码阶段：根据模块定义图中的模块及它们之间的关系实现系统的功能。

模块可通过分割框划分不同属性。分割框属性分为：组成部分、参考、值、约束、操作、接收、标准端口、流端口、完整端口、代理端口、流属性等

模块结构属性：

1. 组成部分属性(parts)

   模块的组成部分；组成部分属性代表模块的内部结构。表示一种从属关系。

2. 引用属性（reference）

   表示模块外部的一种结构。通常可以用于描述“需求的关系”。

3. 值属性（value）

   本质上就是表示一个模块中所包含的变量信息。

   原始值类型：String、Boolean、Integer和Real。

   结构值类型：拥有内部结构的值类型，以一个定义好的模块为类型的类型。

   枚举值类型：定义一系列数值。

4. 约束属性（constraint）

   一般代表一种数学关系。

   此外约束属性可以作为一个**约束模块(constraint module)**：扩展了基本模块，其也是一种定义元素，它定义了一种布尔型的约束表达式。

   

5. 端口（port）

   代表模块与外部环境进行交互的不同出入口的性质。又可分为流端口和标准端口。

   • 流端口（flow port）：为在边界交互点流入、流出模块的事件、能量或者数据建模。

   • 标准端口：模块在边界交互点上提供或者请求的服务的模型。（类似于标准库函数调用）

SysML中的行为模型（Behavior）

SysML BDD图中

SysML BDD图中提供了两种类型的行为特性：操作和接收。

1. 操作（operation）：表示客户端调用模块的时候它所执行的行为。操作由调用事件触发，操作代表的是一种同步行为。
2. 接收（receive ）：当客户端发送信号(signal)来触发的时候，模块就会执行该行为。接收是由信号事件触发的，它是一种异步的行为。

执行者(actor): 表示人、组织或者其他系统在与当前系统交互时所扮演的角色。

注释：一种模型元素。它包含唯一的属性：一段文字。‘

关系：

• 模块之间关联关系
  • 引用关联：两个模块之间的引用关联意味着系统的模块实例可以存在一种彼此访问的连接。
  • 组合关联关系：是一种特殊的关联关系：两个模块之间的组合关联表示结构上的分解
• 模块之间泛化关系：泛化是模块中的继承关系，子模块完全继承父模块的所有保护和公有的属性、操作等。
• 模块之间依赖关系：依赖表示当提供者元素发生改变时，客户端元素可能也需要改变。

系统内部模块图(IBD：Internal Block Diagram)

是模块定义图（BDD）中模块内容的补充。组成部分属性和引用部分属性之间的连接；在连接之间流动的事件、能量和数据的类型；以通过连接提供和请求服务。

BDD：首先定义模块和它的属性；IBD：显示对某个模块的合法配置

系统约束参数图（Par：Parametric Diagrams）

参数图用于说明系统的约束。参数图与BDD的关系，就类似于IBD与BDD的关系，是互补的视图。

活动图（act：Activity Diagrams）

活动图可以表达复杂的控制逻辑，这要比序列图和状态图更强；且活动图是唯一能够说明连续系统行为的图；（动作执行顺序、动作执行结构、动作触发结构）

Petri Nets Petri网

**Place(库所)**：表示系统部件及其状态，如：一个磁盘驱动器，一个程序，某种资源等等；
Transition（变迁）：表示能够改变系统状态的动作/事件；如：从磁盘读取数据动作，向磁盘写入数据，等等；
Arc（有向弧）：表示Place和Transition之间的关系；
Token（令牌）：表示了整个Petri Nets的状态。

形式化定义：

A Petri net as a five tuple, M= (P, T,I, O,MP)：
P represents a set of places, P = {P_l, P₂…. ,P_n},
T represents a set of transitions, T= {t₁, t₂, … ,t_m},
I represents a bag of sets of input functions for all transitions, I = {I_(t1),I_t2. . . . . I_tm}, mapping places to transitions;
O represents a bag of sets of output functions for all transitions, O = {O_tl, O_t2, … ,O_tm},；
MP represents the marking of places with tokens.

作用：系统中多个进程进行资源共享的行为建模。

活动图与Petri网对应

直角方框表示place；需要特殊强调的place用大直角框；一般的也可用小方框依附在Transition圆角框并在旁用文字标注。如图有三个place。

圆角方框表示Transition

Token不直接在活动图中显示

活动图

1. 动作节点：一个动作表示：某种类型的处理或者转换；

   

2. 对象节点：出现在两个动作之间，以表示第一个动作会产生出对象令牌作为输出，第二个动作会将这些对象令牌作为输入。

   • 一般的对象节点：

   • 栓（Pin）：是一种特殊类型的对象节点。栓可以附加到动作上

   • 活动参数：附加在活动图的外框上，表示整个活动图的输入或输出。

     

   • 流与非流：非流要等动作结束才能继续，流直接传递token。

     流行为要在栓旁标注{Stream}

3. 边：

   • 对象流是一种边，用于传输对象令牌（传数据？）

   • 控制流 常用虚线箭头来表示控制流，当对象流无法有效表示活动/动作的传递序列的时候，可以使用控制流来表示一系列动作的序列约束；（不传数据？）

4. 特殊的动作：

   • 调用行为动作：将一个高层次的行为分解成一系列低层次的行为。

   • 发送信号动作、接受信号动作

   • 发送信号动作、接受事件动作

   • 等待时间动作

5. 控制节点：引导活动沿着路径执行，可以指引活动中控制令牌的流，也可以指引活动中对象令牌的流。

   • 初始节点标记活动的起点 ：如果活动图有活动参数（在外框上的），可以不需要初始节点

   • 活动最终节点 ： 表示整个该活动图的流程结束

   • 流最终节点：表示活动图中的该动作流结束。

   • 判定节点、合并节点：都用菱形表示，但是出入边数量不同，且判定节点输出边要有条件。

   • 分支节点：拥有一条输入边和多条输出边。当一个令牌——可能是对象令牌，也可能是控制令牌——到达分支节点的时候，它会被复制到所有输出边上。

     

   • 汇聚（集合）节点：标记活动中并发序列的结束（同步点）。汇聚节点一般拥有两条或多条输入边，而只有一条输出边。

6. 活动分区：用泳道

状态机图 (stm: state machine diagram)

通常用于模块的详细设计阶段，可以自动生成代码框架；

1. 初始状态和终止状态：

   • 一个状态只能有一个初态；复合状态中可以使用新的初态；
   • 终态的数目可以不确定。

2. 简单状态：

   • 状态名（name）
   • 进入/退出动作（entry/exit）：原子动作
   • 执行动作（do）：非原子动作
   • 内部转换（internal transition）：不导致状态改变的转换，不会执行 entry 和 exit 动作

3. 复合状态：（圆角方框表示；可选extry,exit和do行为；拥有内嵌的子状态）

   复合状态可以从其边界跳出；也可以从其中的某个子状态直接跳出；

4. 伪状态

   引入伪状态的目的：在状态转换之间增加较为复杂的逻辑控制，伪状态用于更为简便的表示。不能在伪状态上停留

转换：

状态之间的变化联系：

• 触发器（trigger）:某个事件，能够触发状态发生变化
• 守卫（guard）：布尔表达式，T/F
• 影响（effect）：转换过程中的执行行为（原子行为）

转换中的事件：

1. 信号事件(signal)：接受到别人发生的信号从而调用这个事件。如上图的commLinkLost

2. 调用事件(call)：如上图的 acquireTarget( orderedAttitude :Attitude )

3. 时间事件(time)：

   相对时间事件：用关键词at 开头

   绝对时间事件：用关键词 after 开头

4. 改变事件(change)：定义为一个布尔表达式。在系统执行过程中，每当某个特定的布尔表达式从假切换为真的时候，其对应的改变事件就会发生。（对比：不变式，断言）when（。。。）/ 。。。

特殊的转换->内部转换：是改变事件的直接应用，表示系统在某个状态内部的细节变化，但不会触发entry/exit行为。

分区

分区的作用：与活动图中类似，用于表示并发的行为。

系统建模之序列图（sd： sequence diagram）

目的：序列图的目的在于描述系统中各个模块实例按照时间顺序的交互过程。

在系统的详细设计阶段也常常会用到序列图，用于仿真和代码框架的自动生成。

模型元素

1. 生命线：表示参与交互场景的系统、模块、子系统等的实例；

   1. 头部：矩形方框
   2. 虚线：时间线（从上至下，时间增长）

2. 消息

   1. 异步：带开口箭头的实线
   2. 同步：带有实心箭头的实线，
   3. 回复：带有开口箭头的虚线，可在图中忽略不表示
   4. 创建：带开口箭头的虚线，指向一个对象实例。

   与消息有关的事件：

   消息发送事件、消息接收事件、生命线创建事件、生命线销毁事件、行为执行开始事件、行为执行结束事件

3. 增加语义

   • 时间约束：

   • 状态常量：可以用关联的状态机中的状态名来标示，

     

   • 逻辑操作：

     • opt （条件 ， T/F）满足条件 就执行opt 框中的交互序列
     • alt （多选一） alt框中有虚线（划分 true，else分支）；alt条件只能同时有且只有一个为真；
     • loop （循环） Loop(min,max);
     • par （并行）表示多个场景的交互处于并发执行的语义；
     • ref操作

用例图（ud: usecase digram）

用例图是从用户角度描述系统功能，是用户所能观察到的系统功能的模型图。是系统的一种黑盒视图。

用例图需要配置用例说明书，对用例进行详尽描述。先用自然语言描述清楚，然后进行图形化/形式化建模、分析与验证

用例图中事物及关系

1. 参与者（执行者）

   是指存在于系统外部并直接与系统进行交互的实体。

   参与者不仅可以由人承担，还可以是其他系统、硬件设备，甚至是时钟。

2. 用例（系统功能）系统外部可见的一个系统功能单元。

3. 系统边界：系统边界是指系统与环境之间的界限。用例图中的系统边界用来表示正在建模系统的边界，边界内表示系统的组成部分，边界外表示系统的外部。

4. 用例图中的关系

   • 关联：参与者与用例之间的关系
   • 包含和扩展：用例之间的关系"include" 、"extend"
   • 泛化：参与者之间的关系

需求图(req: requirment diagram)

需求是用户解决问题或达到领域目标所需的系统功能；包括系统及子系统/模块等都要满足合同、标准，规范或其它正式规定文档所需具有的条件或能力。

需求分析的目的是确定系统应具备哪些功能。

机载系统/软件的需求建模与分析方法

基于模型的系统工程（MBSE）与SCR方法

什么是系统？系统就是交互的元素组织起来的组合，以实现一个或多个特定的目的。
概念：

1. 需求（requirements）：能满足用户期望的各种系统各种特征的集合
2. 需求规约（requirement specification ）：用某种准确的描述方式将需求内容表达出来，使得能够进行有效的需求层级分析、验证等工作。（条目化->图形化->形式化）
3. 需求模型(requirement model): 在MBSE框架下，需求规约就是需求模型
   需求要满足：明确、正确、完整、一致、可追溯、可实现、可验证
   一个好的需求模型（规约）应该是以某种方法学为基础来进行良好的设计来得到的

形式化方法（Formal Methods）：是在计算机系统（包括硬件和软件）的规约、设计和构造中使用逻辑和离散数学中的技术
提供了一种计算手段，因而可以在一个数字系统的实现之前预测它的行为会是怎样。
需要建立形式化模型；(建模语言)；形式化分析需要一个工具来实现，这需要对这个工具进行鉴定。（工具输入／输出）

形式化方法带来的挑战：

• 缺少形式化方法的培训导致不理解（培训学习和用户友好的工具）；
• 并非适用于所有问题（在最关键的地方使用）；
• 形式化方法和非形式化方法的混合会带来困难（作为需求定义和验证活动的一个子集，与传统的过程集成）；
• 形式化方法专家太少（培训＋工具）；
• 有较高资源的需求（在关键、复杂区域使用，成本效益高）
• 对形式化方法验证能力有过高的信心（建立正确的系统 v.s. 正确的建立系统）
• 对测试存在偏见（测试仍然是需要，特别是基于目标机的测试来验证硬／软件的集成）
• 工业和合格审定指南还没有标准化（DO-333是重要一步）
• 工具支持仍不完整（需要适用于软件生命周期＋领域工程师使用）

SCR方法概述

Software Cost Reduction（SCR）目的是评价软件工程技术在实际工程应用中的有效性和可扩展性。
真正核心出发点是落在系统上

A-7E OFP 需求文档中建立了三种SCR方法中主要方面：

1. 标识出所有的输出，并将每个输出表示为系统运行状态和环境变化的数学函数；
2. 使用表格的形式来描述这些输出及关系；
3. 建立了需求文档的评价准则

为了准确定义所需要的系统行为，在A－7的需求文档中引入了“条件（condition）”、“事件（event）”、“模式/模式类（mode/mode class）”以及“项/宏（term）”等基本概念。

• 条件: 定义在单个系统状态上的约束;（如变量取值）
• 事件: 定义在系统状态发生变化时所触发的约束；
• 模式／模式类：系统总是运行在某些特定工作状态下；（大概就是不同的功能方面的划分？）
• 项（宏）：表示中间辅助说明变量。

需求文档需要满足的基本准则： 完整性；与系统如何实现无关；内容组织合理（如同编撰良好的参考手册）；

SCR利用表格定义函数

表格符号的优点：相比于逻辑符号，错误发生较少(表的结构消除了逻辑符号容易产生的错误); 比其他符号简单.

基于SCR方法的需求建模

四变量模型(FVM, Four Variable Model)

• 需求的说明包含以下两步：
  • 理想的系统行为（即系统的正常行为）
  • 真实的系统行为
• 系统行为通常根据其所处环境量表示

四变量：

1. 监视变量(Monitored Variables)：系统监视的环境量(如：温度，压力，高度)
2. 受控变量(Controlled Variables): 受系统控制的环境量（如：显示器 的显示——数值、文本、图形，作动器的阈值）
3. 输入(Inputs): 该变量来自于监视变量的估量
4. 输出(Outputs): 该变量对受控变量产生影响

为了定义理想的系统行为，需求规范必须

• 从环境中识别和指明受控变量
• 从环境中识别和指明监视变量
• 指明监视变量和受控变量之间的关系

为了指明真实的系统行为

• 在理想系统中使系统简化的假设需要移除
• 输入和输出变量的值能够从输入和输出设备中读出

监视变量与受控变量之间的关系对应着系统需求，输入变量和输出变量之间的关系对应着软件需求。
在监视变量和受控变量上的两种关系

• NAT: 环境约束（如：物理规律，系统所处环境的一些自然约束）
• REQ: 为了实现系统的要求，所添加的系统约束

另外两种关系

• IN: 监视变量和输入变量之间的关系
• OUT: 输出变量和受控变量之间的关系

验证方法