嵌入式系统|Ansys SCADE在巴黎地铁交通集团RATP的应用

2 形式化方法在RATP的扩大应用

不过，1998年后在RATP众多供应商中仅有西门子(Siemens)和阿尔斯通(Alstom)两家继续使用B方法进行其他项目轨交信号系统的研发，而以安萨尔多Ansaldo，泰雷兹Thales，阿海珐Areva为代表的供应商则选择使用SCADE产品进行轨交信号系统的开发，还有其他供应商使用Petri网或者Ada语言行开发……之后西门子和阿尔斯通在不少项目上也开始使用SCADE进行大规模的研发。值得一提的是，Z语言和Lustre语言都是创立于上世纪80年代初，之后又分别演进出了B语言(Event     B语言)和SCADE语言。在同样都是形式化语言的基础上，B语言的语法语义的掌握既需要专家的长期支持，又需要经常实践才能达到一定的门槛；而SCADE语言是基于模型的开发验证工具及可桥接的第三方工具更多，这可能是其应用更广泛的原因。

图表1: RATP的CBTC和联锁项目中的供应商与采用的形式化开发技术

3 RATP的PERF

为了在评估软件系统时能独立于各供应商选用开发的形式化模型，RATP根据内部的安全政策，研制出了独立的工具链，并在此基础上提出了PERF（Proof   Executed over a Retro-engineered Formal   model）方法论。PERF是在系统开发之后执行的一种形式化证明方法。与诸如B方法这类贯穿于系统的开发阶段的形式化技术不同，PERF的验证技术仅在V流程开发周期的右侧上升阶段(即验证阶段)应用。即使在系统开发的早期阶段没有计划要使用形式化方法来验证，这种技术依然允许在后期应用形式化方法。除了确保开发阶段的独立性之外，从安全的角度来看，PERF还具有以下与形式化开发方法相关的强大特性：

• 属性验证的穷尽性

• 通过形式化建模来确认需求本身，这种建模揭示了需求中任何含糊不清或缺乏准确性的地方 

PERF对应的完整工具链，是围绕一个验证引擎进行构建，将模型检查和归纳证明技术相结合。该工具链基于传统Lustre语言(与SCADE同宗同源)，能以同步语言的方式描述要检查系统的形式化模型。此外，PERF工具链还包括几个“基本构建块”，它们能以不同的方式组织以解决特定问题。这样就可以用于不同类型的验证。因此，PERF工具链可以通过调整其用途来用于不同的项目，这意味着工程师可以利用单一工具的专业知识进行工作。 

PERF工作流如图表1，其形式化引擎有三个输入，三个输出。

左侧输入的是源软件(可以是SCADE，Ada或C代码)被转换成一个的形式化的HLL语言后，再传给形式化分析引擎Proof     engine。右侧输入的是将安全需求改为全部或部分安全属性，也用HLL语言实现。左侧的形式化模型和右侧的形式化属性构成一个证明结构。中间输入的是某些情况下可能会包含描述环境模型的约束或假设，也需要用HLL语言实现。这个环境模型对于消除不可能的情况和更好地指导证明过程非常有用。

所有三个模型(软件、安全属性和环境)都输入到形式化分析引擎中进行运算后，中间输出的是检查的安全属性是否有效；右侧输出的是在正确验证属性的情况下，可提交鉴定的日志，以供审查方追溯用于验证安全属性的操作步骤；左侧输出的是在属性无效的情况下，引擎可提供了这些属性被篡改的反例。

图表2: PERF工作流

上面提到的HLL语言，是一种基于数据流的、声明性的同步语言，也具有形式化的语法和语义。它类似于Lustre或SCADE，但具有稍微丰富的类型系统(标准标量和结构化类型、函数、谓词、层次枚举等)，这些类型上有一组广泛的运算符(包括基本的前、后时态运算符)，以及旨在表达通用安全规范的特定结构(对有限集、约束、证明义务等的量化)。

第一次应用PERF的成本相当于基于验证测试活动的传统方法成本。这一初始成本主要根据供应商使用的开发方法而对工具进行的必要调整，并建立了适当的流程。而在未来处理变更(非回归测试和影响评估)时，形式化证明的成本将显著下降，这使得PERF在项目的整个生命周期内更具优势。

4 PERF的精化与抽象

和使用其他形式化方法一样，为应对程序的状态空间爆炸问题，都可能需要对程序进行切片，精化，抽象等处理。在使用PERF时，RATP也提出了推荐的精化refinement与抽象abstraction的方法。

某案例目标系统的实现是分别基于SCADE模型和ADA手写代码。在开发阶段，系统被分解成与SCADE操作符或ADA代码块（主要是过程）对应的多个组件。然后在组件级别执行抽象。直接影响所研究的安全属性组件不作修改，因为它们正是需要分析的对象。而其他组件可以抽象为表示所有可能的行为，这是通过忽略组件的所有实现细节并将抽象（未定义）值作为输出来执行的。由此产生的抽象模型比原始模型更为通用；它是包含原始行为集的超集。证明安全属性在此超集上有效，意味着此安全属性对于其任何子集(特别是原行为子集)仍然有效。

抽象通过去掉组件的所有不必要的细节，大大降低了模型的复杂度。值得注意的是，抽象组件输出的状态空间变得比原始组件输出的状态空间大，因为它是抽象组件输出的超集，这在理论上会加剧状态空间爆炸问题。然而，在实践中，与忽略所有中间变量引起的状态空间缩减相比，输出的这种增加是微不足道的。

抽象原则如下图所示。以一个由3个组件组成的系统为例。不同的组件通过输入/输出通道进行交互，以实现完整的系统行为。如果我们考虑只有组件2影响给定属性的情况，则在右侧给出用于验证该属性的系统的最佳抽象。整个系统的复杂性降低到了现在所考虑组件的复杂性。

图表3: 抽象前和抽象后的概览

抽象过程可以迭代地应用到系统的不同层次，从整个系统到组件的原子功能。在案例研究中，抽象能显著地减少目标系统的大小和复杂性。这种规模的缩减使得验证活动成为可行的。除了验证之外，抽象过程还帮助我们更好地理解被验证的系统及其不同的组件。然而，这种抽象技术的有两个主要缺点。一是需要时间来确定给定属性的最小抽象模型。二是要获得一个只包含必需组件的抽象模型，需要付出相当大的努力。目标是找到抽象层次与所获得的抽象模型的复杂度之间的最佳折衷。这种复杂的自底向上的解决方案也可以与自上而下的属性精化改进方法相耦合，以减少验证复杂性。

图表4: 抽象与精化的V模型图

精化过程从顶层规范开始，可尝试逐步进行，以达到目标抽象模型。抽象过程则相反，它从系统的具体实现开始，去除不必要的细节，以便得到只包含高级规范的抽象模型。

安全属性的精化过程不应该自动化，它需要CBTC软件和系统专家与安全评估工程师的合作，以达到合理的水平。验证活动的自动化是可行的，可确保手动精化过程是正确的。抽象过程可以是部分自动化的并仅由CBTC软件专家来操作。抽象过程的结果也可以用于未来演进版本的自动化影响分析，未来演进版本的回归分析可以忽略，因为它们不会影响已验证的行为。

RATP已经在下列巴黎地铁线路上应用PERF进行了形式化验证。

图表5: 2011年后形式化方法在RATP的应用统计

其中泰雷兹,     安萨尔多和阿尔斯通(前阿海珐的相关部门)开发了线路1,4,8,12的联锁系统和线路3,5,9,13的CBTC系统的轨旁和车载部分。图表6是RATP应用PERF方法论的统计，蓝色进度条显示的是使用PERF方法进行安全评估项目的百分比，PERF对右侧使用SCADE模型开发部分的安全评估达到近100%，代码量也远超前面三种开发手段，可见SCADE模型与PERF方法论的工具链是极其匹配的。

图表6: PERF的应用统计

使用SCADE工具开发的13号线CBTC轨旁项目，生成了6百万行代码。在该项目的某子系统上根据3个通用安全规范精化出了110个安全属性。在应用PERF提出的精化和抽象方法后，对其中一个安全属性进行形式化分析。在未抽象前，其形式化证明耗费了275G内存，用时4小时30分钟；而抽象后，其形式化证明仅耗费了20G内存，用时3分钟20秒。

[1]   Benjamin Blanc, Julien Ordioni. “HLL Tutorial by RATP”.[ EB/OL].   https://conferences.ncl.ac.uk/media/sites/conferencewebsites/rssrail2019/20190604_RSSR2019_Tutorial_HLL.pdf.   Jun 4, 2019

[2]   Benaissa N, Bonvoisin D, Feliachi A, et al. The PERF approach for   formal verification[C]//International Conference on Reliability,  Safety,  and Security of Railway Systems. Springer, Cham, 2016: 203-214.

[3]   Fredj M, Leger S, Feliachi A, et al. OVADO[C]//International  Conference  on Reliability, Safety and Security of Railway Systems.  Springer, Cham,  2017: 87-98.

[4] B method.[EB/OL].https://en.m.wikipedia.org/wiki/B-Method

[5]   Coupoux P. Combination of Formal Methods for Creating a Critical   Application[J]. Formal Methods Applied to Industrial Complex Systems,   2014: 353-389.

[6] Formal techniques in CBTC software development [EB/OL].Oct 22,2009

[7]   Feliachi A, Bonvoisin D, Chaou S, et al. Formal verification of   system-level safety properties on railway software[J]. Congrès Lambda  Mu  20 de Maîtrise des Risques et de Sûreté de Fonctionnement, 11-13   Octobre 2016, Saint Malo, France, 2016.