继续主题 ，我们从另一个侧面来看数学建模的问题。 当我们确信该模型符合生活的朴素真理后，我们就可以回答主要问题：“我们这里到底有什么？” 在创建技术对象的模型时，我们通常希望确保该对象满足我们的期望。 为此，对过程进行动态计算，并将结果与要求进行比较。 这是数字孪生、虚拟原型等。 时尚的小家伙，在设计阶段解决了如何确保我们得到我们计划的问题。
我们如何快速确保我们的系统完全符合我们的设计，我们的设计会飞翔还是漂浮？ 如果它飞的话，能飞多高？ 如果它漂浮的话，有多深？
本文讨论在创建技术系统的动态模型时自动验证是否符合技术建筑的要求。 作为示例，让我们看一下飞机空气冷却系统技术规范的一个要素。
我们考虑那些可以用数字表达并基于特定计算模型进行数学验证的要求。 显然，这只是任何技术系统一般要求的一部分，但正是在检查这些要求的过程中，我们花费了时间、精力和金钱来创建对象的动态模型。
当以文档的形式描述技术需求时，可以区分几种类型的不同需求，每种需求都需要不同的方法来形成需求满足的自动验证。
例如，考虑这组小但现实的需求：
- 水处理系统入口处的大气温度：
停车场 - 从负 35 度到 35 度，
飞行中 - 从负 35 度到 39 度。 - 飞行中大气的静压为 700 至 1013 GPa（526 至 760 毫米汞柱）。
- 飞行中SVO进气口入口处的总气压为754至1200 GPa（566至1050毫米汞柱）。
- 冷却空气温度：
在停车场 - 不超过 27 ℃，对于技术区 - 不超过 29 ℃，
飞行中 - 不超过 25 度，技术块 - 不超过 27 度。 - 冷却空气流量：
停车时 - 至少 708 公斤/小时，
飞行中 - 不低于 660 kg/h。 - 仪器室内空气温度不超过60℃。
- 冷却空气中细小游离水分含量不大于2克/千克干空气。
即使在这组有限的要求范围内，系统中至少有两类需要以不同的方式处理：
- 系统运行条件要求（第1-3条）；
- 系统的参数要求（第 3-7 条）。
系统运行条件要求
在建模过程中开发的系统的外部条件可以指定为边界条件或一般系统运行的结果。
在动态仿真中，需要确保仿真过程涵盖指定的运行条件。
参数化系统要求
这些要求是系统本身提供的参数。 在建模过程中，我们可以得到这些参数作为计算结果，并确保每次具体计算都满足要求。
需求识别和编码
为了便于处理需求，现有标准建议为每个需求分配一个标识符。 在分配标识符时，非常希望使用统一的编码系统。
需求代码可以只是一个代表需求订单号的数字，也可以包含需求类型代码、其适用的系统或单元的代码、参数代码、位置代码以及任何其他内容。工程师可以想象。 （编码的使用参见文章）
表 1 提供了需求编码的简单示例。
- 需求来源代码 R-需求 TK；
- 要求的代码类型 E - 要求 - 环境参数或操作条件
S——系统提供的要求； - 飞机状态代码 0 – 任意，G – 停放，F – 飞行中；
- 物理参数类型代号T——温度，P——压力，G——流量，湿度H；
- 需求的序列号。
| ID 需求 |
使用说明 | 参数 |
| 注册01 | 水冷系统入口处的环境空气温度：停车场内 - 零下 35°С。 高达 35 ℃。 | |
| 雷夫特01 | 防空系统入口处的大气温度：飞行中 - 从-35 ℃到39 ℃。 | |
| REFP01 | 飞行中的静态大气压力为 700 至 1013 hPa（526 至 760 mm Hg）。 | |
| REFP02 | 飞行中 SVO 进气口入口处的总气压为 754 至 1200 hPa（566 至 1050 mm Hg）。 | |
| RSGT01 | 冷却空气温度：停车时不超过27℃ | |
| RSGT02 | 冷却空气温度：在停车场，技术单位不超过29℃ | |
| RSFT01 | 飞行中冷却空气温度不超过25℃ | |
| RSFT02 | 冷却空气温度：飞行中，技术装置不超过 27 ℃ | |
| RSGG01 | 冷却空气流量：停车时不低于708公斤/小时 | |
| RSFG01 | 冷却空气流量：飞行中不少于660kg/h | |
| RS0T01 | 仪表室空气温度不超过60℃ | |
| RSH01 | 冷却空气中细小游离水分含量不大于2克/千克干燥空气 |
需求验证系统设计。
对于每个设计要求，都有一个算法用于评估设计参数与要求中指定的参数的对应关系。 总的来说，任何控制系统总是默认包含用于检查需求的算法。 甚至任何监管机构都包含它们。 如果温度超出限制，空调就会打开。 因此，任何调节的第一步都是检查参数是否满足要求。
由于验证是一种算法，因此我们可以使用与创建控制程序相同的工具和工具。 例如，SimInTech 环境允许您创建包含模型各个部分的项目包，以单独项目的形式执行（对象模型、控制系统模型、环境模型等）。
这种情况下的需求验证项目成为同一个算法项目并连接到模型包。 在动态建模模式下，它会执行分析以确保是否符合技术规范的要求。
图 1 显示了一个可能的系统设计示例。
图 1.验证项目的设计示例。
就像控制算法一样，需求可以制定为一组表格。 为了方便在 SimInTech、Simulink、AmeSim 等结构建模环境中使用算法，使用了以子模型形式创建多层结构的功能。 这种组织使得可以将各种需求分组，以简化处理一系列需求的工作，就像控制算法所做的那样（见图 2）。
图 2. 需求验证模型的层次结构。
例如，在所考虑的情况下，区分两组：对环境的要求和直接对系统的要求。 因此，使用两级数据结构：两组，每组都是算法的叶子。
为了将数据连接到模型，使用了生成信号数据库的标准方案，该方案存储用于项目各部分之间交换的数据。
创建和测试软件时，控制系统使用的传感器（真实系统传感器的模拟）的读数放置在该数据库中。
对于测试项目，动态模型中计算出的任何参数都可以存储在同一个数据库中，从而用于检查是否满足要求。
在这种情况下，动态模型本身可以在任何数学建模系统中执行，甚至可以以可执行程序的形式执行。 唯一的要求是存在用于向外部环境发布建模数据的软件接口。
图 3. 将验证项目连接到复杂模型。
图4给出了基本需求验证表的示例。从开发人员的角度来看，它是一个传统的计算图，在其上以图形方式呈现了需求验证算法。
图 4. 需求检查表。
检查表的主要部分如图5所示。检查算法的形成与控制算法的设计图类似。 右侧有一个用于从数据库读取信号的块。 该模块在仿真期间访问信号数据库。
分析接收到的信号以计算需求验证条件。 在这种情况下，执行高度分析以确定飞机的位置（无论是停放还是飞行中）。 为此，您可以使用其他信号和模型的计算参数。
正在检查的验证条件和参数被传输到标准验证块，在其中分析这些参数是否符合指定的要求。 结果以可用于自动生成检查表的方式记录在信号数据库中。
图 5. 需求验证计算表的结构。
待测试的参数不一定使用数据库中包含的信号，而是由仿真过程中计算的参数控制。 没有什么可以阻止我们在草案要求的框架内进行额外的计算，就像我们计算验证条件一样。
例如这个要求：
飞向目标过程中校正系统的激活次数不应超过5次，校正系统的总运行时间不应超过30秒。
在这种情况下，在需求的设计图中添加了用于计算启动次数和总运行时间的算法。
典型需求验证块。
每个标准要求复选框旨在计算某种类型的要求的满足情况。 例如，环境要求包括停放和飞行时的一系列环境工作温度。 该模块必须接收模型中的空气温度作为参数，并确定该参数是否覆盖指定的温度范围。/p>
该块包含两个输入端口：参数和条件。
第一个输入的是正在检查的参数。 在本例中为“外部温度”。
布尔变量被提供给第二个端口 - 执行检查的条件。
如果在第二个输入处接收到 TRUE (1)，则该块执行需求验证计算。
如果第二个输入接收到 FALSE (0)，则不满足测试条件。 这是必要的，以便可以考虑计算条件。 在我们的例子中，此输入用于根据模型的状态启用或禁用检查。 如果模拟期间飞机在地面，则不检查与飞行相关的要求，反之亦然 - 如果飞机在飞行中，则不检查与停机操作相关的要求。
该输入也可以在建立模型时使用，例如在计算的初始阶段。 当模型进入所需状态时，检查块被禁用，但一旦系统达到所需的操作模式，检查块就会打开。
该块的参数为：
- 边界条件：必须检查的上限（UpLimit）和下限（DownLimit）范围；
- 边界范围（TimeInterval）所需的系统曝光时间（以秒为单位）；
- 请求ID ReqName;
- 超出范围的允许性 Out_range 是一个布尔变量，用于确定超出检查范围的值是否违反要求。
在某些情况下，测试值输出表明系统有一定的余量，并且可能在其工作范围之外运行。 在其他情况下，输出意味着系统无法将设定点保持在范围内。
图 6. 图中的典型属性检查块及其参数。
作为该块的计算结果，在输出处形成 Result 变量，该变量采用以下值：
- 0 – rNone，值未定义；
- 1 – rDone，满足要求；
- 2 – r故障，不满足要求。
块图像包含：
- 标识符文本；
- 数字显示测量极限参数；
- 参数状态的颜色标识符。
模块内部可能存在相当复杂的逻辑推理电路。
例如，要检查图6所示单元的工作温度范围，内部电路如图7所示。
图 7. 温度范围确定单元的内部图。
在电路块内部，使用块参数中指定的属性。
除了分析是否符合要求之外，该块的内部图还包含显示仿真结果所需的图表。 该图既可用于计算期间的查看，也可用于计算后分析结果。
计算结果传输到块的输出，并同时记录在根据整个项目的结果创建的通用报告文件中。 （见图8）
基于模拟结果创建的报告的一个示例是根据给定格式创建的 html 文件。 该格式可以任意配置为特定组织接受的格式。
在电路块内部，使用块参数中指定的属性。
除了分析是否符合要求之外，该块的内部图还包含显示仿真结果所需的图表。 该图既可用于计算期间的查看，也可用于计算后分析结果。
计算结果传输到块的输出，并同时记录在根据整个项目的结果创建的通用报告文件中。 （见图8）
基于模拟结果创建的报告的一个示例是根据给定格式创建的 html 文件。 该格式可以任意配置为特定组织接受的格式。
图 8. 基于模拟结果的报告文件示例。
在本例中，直接在项目属性中配置报告表单，并将表中的格式设置为全局项目信号。 在这种情况下，SimInTech 本身解决了设置报告的问题，并且将结果写入文件的块使用这些行写入报告文件。
图 9. 在全局项目信号中设置报告格式
使用信号数据库来满足要求。
为了自动化属性设置工作，在信号数据库中为每个典型模块创建了一个标准结构。 （见图10）
图 10. 信号数据库中需求检查块的结构示例。
信号数据库提供：
- 存储所有必要的系统要求参数。
- 从指定参数和当前建模结果方便地查看现有项目需求。
- 使用脚本编程语言设置一个块或一组块。 信号数据库的变化会导致图中模块属性值的变化。
- 在需求管理系统中存储文本描述、技术规范项或标识符的链接。
需求的信号数据库结构可以很容易地配置为与第三方需求管理系统一起工作，与需求管理系统交互的一般图如图 11 所示。
图 11. 与需求管理系统的交互图。
SimInTech测试项目与需求控制系统之间的交互顺序如下：
- 职权范围分为要求。
- 技术规范的要求已确定，可以通过技术过程的数学建模进行验证。
- 所选要求的属性以标准块的结构传输到 SimInTech 信号数据库（例如，最高和最低温度）。
- 在计算过程中，结构数据被传输到模块设计图，进行分析并将结果存储在信号数据库中。
- 计算完成后，分析结果将传输到需求管理系统。
当设计和/或需求发生变更并且需要重新测试变更的影响时，可以在设计过程中重复需求步骤 3 到 5。
结论。
- 创建的系统原型大大减少了现有模型的分析时间，以符合技术规范的要求。
- 所提出的测试技术使用现有的动态模型，甚至可以用于任何动态模型，包括那些未在 SimInTech 环境中执行的模型。
- 使用批量数据组织可以让您在模型开发的同时创建需求验证包，甚至可以将这些包用作模型开发的技术规范。
- 该技术可以与现有的需求管理系统集成，而无需花费大量成本。
对于读到最后的人来说，
来源： habr.com