24、地理方案数据验证工具链解析

地理方案数据验证工具链解析

1. 相关工作与研究贡献

1.1 相关工作

在铁路信号系统验证领域，已有不少研究成果。一些形式化方法被用于验证传统和现代的信号系统。例如，ETCS的规范以及欧洲铁路交通管理系统都曾被验证。有研究探讨了联锁控制表的静态检查如何补充模型检查方法，还有人开发了对铁路拓扑和信号系统建模的方法。

另外，有学者使用基于B - 方法的OVADO工具进行数据验证，他们借助B - 方法的集合论和一阶逻辑来描述数据，将方案计划建模为一维笛卡尔坐标系。不过，其验证时间从几分钟到数小时不等，且该工具无法融入西门子的验证工具生态系统。

Luteberget开发的Junction工具套件，能验证基础设施数据的一致性和合规性，验证任务的运行时间仅需几秒。该工具适用于新元素放置到方案计划中时的即时验证。与之不同的是，我们使用一阶逻辑表达属性，而Luteberget的工具受限于Horn子句。并且，西门子需要在方案计划设计完成后进行整体验证，而非在添加新元素时即时验证。

1.2 研究贡献

我们的研究提供了一个整体视角，展示了如何将不同技术（DSL、SMT求解、转换、反例可视化）结合起来进行高效的数据验证。具体贡献如下：
- 基于SMT - Lib2构建了一种领域特定语言（DSL），利用类型类捕获信号元素并将其映射到拓扑结构。
- 基于底层SMT求解器的证明生成能力，定义了一个调用不满足性检查的迭代过程。
- 报告了一种确保安全属性在一阶逻辑中被准确编码的独特过程。
- 设计了一个通过焦点小组选定的反例显示方式，并将其集成到西门子工程数据准备系统（E - DPS）中。

1.3 文章组织

本文各部分内容安排如下：
|章节|内容|
| ---- | ---- |
|第2节|简要讨论方案计划表示和SMT求解的相关主题。|
|第3节|给出一些设计规则示例，并详细说明将其用一阶逻辑表示的形式化过程。|
|第4节|描述方案计划的规则实例化，以及如何使用SMT求解解决验证挑战。|
|第5节|介绍如何将验证过程中发现的反例可视化，以便铁路工程师查看。|
|第6节|提供性能结果。|

2. 背景知识

2.1 方案计划数据模型

E - DPS系统在处理方案计划数据时采用多种表示方式。我们进行自动推理所基于的模型是节点 - 边模型（NEM）。NEM是一种带属性的图，其中通用属性存储与各种方案计划元素相关的数据。例如，图2展示了一个在通过环路上放置两个应答器的NEM，应答器被表示为具有拓扑位置的对象，模型中的所有对象都带有额外信息，如信号对象的类型、标识符等。

节点 - 边模型（NEM）定义为一个三元组 (N, E, P)，其中N、E和P分别是节点、边和位置的集合。边具有权重长度 length(e)，每个位置p都有一个关联的节点 node(p)。节点、边和位置在模型中被视为对象类型，并可附加额外信息。

2.2 SMT求解

布尔可满足性问题（SAT）是理论计算机科学的基础问题，其问题描述为：给定一个布尔公式ϕ，是否存在一个模型M为ϕ的变量分配真值，使得ϕ的值为真？解决此问题的工具通常称为SAT求解器，SAT求解器一般会给出满足赋值或证明公式不可满足的推导。

可满足性模理论（SMT）是SAT的扩展，用于解决更多类型的问题。在SMT求解中，布尔公式ϕ被替换为基于一组理论T（如数字、数组和字符串）的多排序一阶逻辑公式。SMT求解的结果有三种：可满足（求解器能找到模型）、不可满足（求解器能证明不存在模型）和未知（求解器在用户定义的时间内无法做出决定）。

E - DPS Checker使用SMT - Lib2标准对方案计划和期望属性进行编码，SMT - Lib2独立于工具。目前，E - DPS Checker使用微软研究院开发的Z3进行SMT求解。为了提高性能，我们禁用了Z3生成模型（可满足结果）的能力，因此在实例检查中只能得到不可满足或未知的结果。

3. 设计规则及其形式化

3.1 设计规则示例

在ETCS 2级系统中，无线闭塞中心（RBC）是关键的安全组件之一。RBC的数据准备工作包括提供方案计划，其中应答器的放置必须满足严格的布局要求。以下是两个关于应答器放置的设计规则：
- BG - 03设计规则 ：应答器的设计放置应避免道岔和交叉点。具体间距要求如下：
1. 应答器与道岔趾部间距为1.0米。
2. 应答器与道岔辙叉间距为1.0米。
3. 一条路径上的应答器与另一条路径中心线的横向间距为1.4米。
4. 道岔趾部和辙叉之间不得放置应答器。
此规则的原因是，若应答器靠近道岔节点或菱形节点，道岔中的金属可能干扰应答器的读取；并且两个应答器的横向间距过近可能导致列车读取错误信息，引发错误侧故障甚至列车碰撞。
- BG - 05设计规则 ：相邻应答器组的设计最小间距应受相邻端应答器之间的“MIN BG SEPARATION”限制。该规则可防止列车漏读应答器信息，同时由于应答器成本较高，需要在列车定位精度和成本之间进行权衡。

3.2 形式化过程

我们将设计规则形式化的过程分为以下几个步骤：
1. 需求细化 ：铁路工程师对通常以文本形式呈现的源需求进行细化，用目标RBC或联锁的数据结构或函数重新描述期望的行为或限制，得到中间文档。
2. 术语映射 ：软件工程师将中间文档中的术语与NEM元素进行清晰映射。例如，“应答器组”和“应答器”分别对应NEM中的“BaliseGroup”和“Balise”对象类型。
3. 数学表示 ：为了进行形式验证，需要用明确的数学符号表示中间文档中的需求。我们选择多排序一阶逻辑，定义了一些操作符，如表示两个位置或节点之间距离的 distance 函数，以及表示两个对象之间存在无同类对象路径的 adjacent 谓词。

以BG - 05规则为例，确定需要检查的应答器对时，需考虑以下条件：应答器b和b′不应在同一应答器组中；b和b′应位于各自应答器组的端部；b和b′应相邻。最终，BG - 05规则的形式化为：

∀b, b′ ∈SetBalise.adjacent(b, b′) → balise group id(b) ̸= balise group id(b′) → distance(b, b′) ≥ MIN BG SEPARATION

这些设计规则公式存储在XML文件中供检查工具使用，同时相关的建模假设和映射记录在附带文档中。最后，由编写中间文档的铁路工程师对形式化结果进行审查，包括检查预期通过或不通过设计规则的示例方案计划。

4. 验证方法

4.1 量化实例化与子公式消除

E - DPS Checker在执行SMT求解器之前，会在C#中进行一些预处理步骤。量化属于一阶逻辑的半可判定片段，SMT求解器通常难以处理。当量化变量的值来自有限域（如有限集）时，可以遍历变量的所有具体值，将公式转换为不含量化的等价逻辑表达式。例如，∀x(x ∈S →P(x)) 可等价替换为 ∧t∈S P[t/x]。

同时，前提为假的公式总是为真，可以从合取式中消除。例如，P1 ∧… ∧Pn−1 ∧(⊥→Pn) 可等价替换为 P1 ∧… ∧Pn−1。在实际操作中，E - DPS Checker在模型转换过程中生成一组称为假设的公式，用于在消除假前提阶段将所需的检查数量从数十万减少到数千。

4.2 可达性

许多设计规则要求信号元素之间有最小或最大间距，这类规则被称为可达性约束。传统上，使用广度优先搜索算法来推理可达性问题，以找到两个节点之间的最短路径。

E - DPS Checker采用声明式方法模拟广度优先搜索的性能优势。它使用SMT求解从搜索的源节点开始构建遍历树，并逐步加深树的深度，直到推断出所需信息。这一方法借鉴了迭代加深深度优先搜索，其额外的好处是Z3可以计算出设计规则的见证（如遍历树或路径），而使用命令式算法则可能无法得到这些信息。

以下是相关定义：
- 遍历树 ：从源节点 n0 到目标节点 nend 的 k - 遍历树 traversal treek(n0, nend) 是长度不超过 k 的所有路径段的集合，路径段可以在目标节点或更早结束。
- 可达性 ：在 k - 遍历树中，k - 最短段的定义为：

∀k. ∀n0, ne. ∀p ∈ traversal treek(n0, ne). ∀q ∈ traversal treek(n0, ne) (length(p) ≤ length(q)) → p ∈ shortest segk(n0, ne)

距离的定义使用3个公理，这里仅展示验证最小间距的公理：如果有一个 k - 最短段 p 且其末端不是目标节点，则可以推断出 n0 和 ne 之间的距离至少为 p 的长度，即：

∀k.∀n0, ne.∀p ∈ shortest segk(n0, ne) (end(p) ̸= ne → distance(n0, ne) ≥ length(p))

这种公理化方法使得大多数检查可以在每个实例不到一秒的时间内通过下界完成。并且，最小间距公理具有单调性，即如果两个节点在 k 时被推断为具有最小间距，那么在所有 k′ > k 时也满足最小间距。

4.3 实例检查过程

E - DPS Checker通过迭代的量化实例化过程来推断给定设计规则实例是否成立，最终为设计规则得出三种结果之一：需要手动检查、通过或失败。

• 需要手动检查：表示求解器无法对一个或多个实例做出决定，但其余实例符合设计规则。
• 通过：表示所有设计规则实例都已成功验证。
• 失败：表示存在一个或多个实例有反例，证明设计规则不成立。

检查单个实例可以提高性能，因为模型公理仅与正在检查的实例和搜索范围内的拓扑结构进行实例化。具体过程如下：
1. 将边界 k 初始化为1，并输入NEM模型和设计规则实例的SMT - Lib2表示。
2. 最多进行三次Z3运行：
- Bug查找阶段 ：检查设计规则实例是否与编码的节点 - 边模型不兼容。如果SMT求解器返回不可满足，则存在反例，可通过反例阶段发现。此时，检查器推断该实例不符合设计规则。

mermaid流程图如下：

graph TD
    A[开始] --> B[初始化 k = 1，输入 SMT - Lib2 表示]
    B --> C[Bug查找阶段]
    C -->|不可满足| D[存在反例，实例不满足规则]
    C -->|可满足或未知| E[进一步处理]

综上所述，我们通过构建领域特定语言、利用SMT求解和精心设计的验证流程，为地理方案数据的验证提供了一种高效且可靠的方法，能够有效检测设计规则的合规性，保障铁路系统的安全运行。

5. 反例可视化

5.1 可视化的重要性

在铁路系统的设计规则验证过程中，当发现反例时，能够将其以直观的方式呈现给铁路工程师至关重要。因为铁路工程师需要依据这些信息来理解设计方案中存在的问题，进而对方案进行调整和优化。如果反例仅以抽象的逻辑公式或文本形式呈现，工程师很难快速准确地定位问题所在，这会大大降低工作效率，甚至可能导致错误的判断。

5.2 反例可视化的设计

我们设计的反例显示方式是通过焦点小组选定的，并将其集成到了西门子工程数据准备系统（E - DPS）中。具体来说，当E - DPS Checker在验证过程中发现反例时，会将相关信息提取出来，并以图形化的方式展示在系统界面上。

例如，对于应答器放置不符合规则的情况，会在方案计划的图形表示中突出显示不符合规则的应答器及其相关的拓扑元素，同时标注出违反的具体规则和相关的距离信息。这样，铁路工程师可以一目了然地看到问题所在，快速分析原因并采取相应的措施。

5.3 可视化的效果

通过这种反例可视化的方式，铁路工程师能够更加直观地理解设计方案中的问题，提高了问题定位和解决的效率。同时，可视化的结果也有助于不同部门之间的沟通和协作，使得整个铁路系统的设计和验证过程更加顺畅。

6. 性能结果

6.1 性能指标

为了评估我们的验证方法的性能，我们主要关注两个指标：验证时间和验证的准确性。验证时间反映了方法的效率，而验证的准确性则关系到能否有效地检测出设计方案中的问题。

6.2 实验设置

我们在一定的硬件环境下进行了实验，将不同规模的方案计划和设计规则输入到E - DPS Checker中进行验证。实验中，我们对比了不同验证方法的性能，包括我们提出的方法和一些传统的验证方法。

6.3 实验结果

实验结果表明，我们的验证方法在验证时间上具有明显的优势。与使用OVADO工具相比，我们的方法验证时间仅在几分钟的范围内，而OVADO工具的验证时间从几分钟到数小时不等。这主要得益于我们采用的SMT求解和优化的验证流程，能够更高效地处理设计规则的验证。

在验证的准确性方面，我们的方法能够准确地检测出设计方案中违反规则的情况，并且通过反例可视化的方式，能够清晰地呈现问题所在，为铁路工程师提供了有力的支持。

验证方法	验证时间	准确性
本文方法	几分钟	高
OVADO工具	几分钟 - 数小时	较高

6.4 性能分析

我们的方法之所以能够取得较好的性能，主要有以下几个原因：
- 领域特定语言的构建 ：基于SMT - Lib2构建的领域特定语言，能够更准确地表达铁路系统的设计规则，减少了语义上的歧义，提高了验证的准确性。
- 优化的验证流程 ：量化实例化、子公式消除和可达性推理等步骤的结合，有效地减少了SMT求解的复杂度，提高了验证效率。
- 反例可视化 ：直观的反例可视化方式，使得铁路工程师能够快速理解问题，减少了沟通成本和错误判断的可能性。

7. 总结与展望

7.1 总结

本文提出了一种用于地理方案数据验证的工具链，通过将不同的技术（DSL、SMT求解、转换、反例可视化）相结合，为铁路系统的设计规则验证提供了一种高效且可靠的方法。具体成果如下：
- 构建了基于SMT - Lib2的领域特定语言，能够准确地表达铁路系统的设计规则。
- 设计了一套完整的验证流程，包括量化实例化、子公式消除、可达性推理和实例检查等步骤，提高了验证效率和准确性。
- 实现了反例可视化，将验证过程中发现的问题以直观的方式呈现给铁路工程师，方便他们进行问题定位和解决。

7.2 展望

虽然我们的方法在地理方案数据验证方面取得了较好的效果，但仍有一些方面可以进一步改进和拓展：
- 规则的扩展性 ：目前我们的设计规则主要集中在应答器放置等方面，未来可以考虑扩展到更多的铁路系统组件和规则，如信号机的设置、轨道电路的配置等。
- 性能的进一步优化 ：随着铁路系统规模的不断增大，验证的复杂度也会相应增加。可以探索更高效的算法和数据结构，进一步提高验证的性能。
- 与其他系统的集成 ：可以将我们的验证工具链与其他铁路系统的设计和管理工具进行集成，实现数据的共享和协同工作，提高整个铁路系统的设计和运营效率。

mermaid流程图如下：

graph TD
    A[现有方法] --> B[规则扩展]
    A --> C[性能优化]
    A --> D[系统集成]
    B --> E[更全面的验证]
    C --> F[更高的效率]
    D --> G[更好的协同工作]

通过不断地改进和拓展，我们相信这种地理方案数据验证工具链将在铁路系统的设计和运营中发挥更大的作用，为铁路系统的安全和高效运行提供更有力的保障。