[論文レビュー] Event-based Formalization of Safety-critical Operating System Standards: An Experience Report on ARINC 653 using Event-B

Yongwang Zhao, Zhibin Yang+2 more|arXiv (Cornell University)|Aug 26, 2015

Formal Methods in Verification参考文献 13被引用数 7

ひとこと要約

本論文は、数学的モデリングと証明義務を用いて、安全制御システム用オペレーティングシステムのARINC 653 Part 1標準仕様の完全なEvent-B形式化と帰納的検証を提示している。検証の結果、標準仕様に隠れた3件の誤りと3件の不完全な仕様事例が特定され、形式手法が重要なシステムインターフェースの正しさを保証する価値を示した。

ABSTRACT

Standards play the key role in safety-critical systems. Errors in standards could mislead system developer's understanding and introduce bugs into system implementations. In this paper, we present an Event-B formalization and verification for the ARINC 653 standard, which provides a standardized interface between safety-critical real-time operating systems and application software, as well as a set of functionalities aimed to improve the safety and certification process of such safety-critical systems. The formalization is a complete model of ARINC 653, and provides a necessary foundation for the formal development and verification of ARINC 653 compliant operating systems and applications. Six hidden errors were discovered from the verification using the Event-B formal reasoning approach.

研究の動機と目的

• 安全制御システム標準（ARINC 653など）に隠れた誤りが検出されないことで、リアルタイムオペレーティングシステムに実装上の欠陥が生じるリスクを低減するため。
• Event-Bを用いてARINC 653 Part 1（バージョン3）の形式的に検証済みの完全なモデルを提供し、厳密な仕様定義と検証を実現するため。
• 開発者を誤導し、システムの安全性を損なう可能性がある、標準仕様における一貫性の欠如、曖昧さ、欠落を特定するため。
• ARINC 653準拠のオペレーティングシステムおよびアプリケーションの形式的開発、検証、コード生成の基盤を構築するため。

提案手法

• 集合論とイベント駆動型形式的枠組みを用いて、Event-BでARINC 653 Part 1標準仕様全体をモデリングし、システムの動作と状態遷移を表現する。
• 安全性インバリアントと精錬関係を含む形式的仕様として、上位レベルのシステム機能とサービス要件を定義する。
• Rodinツールを用いた証明義務による帰納的検証を実施し、抽象化レベル間の一貫性とインバリアントの正しさを検証する。
• 自動推論と証明の放棄を用いて、パーティショニング、タイム管理、インtra/inter-partition通信を含む57のサービスを検証する。
• 標準仕様のテクスト記述をEvent-Bモデルに手動で形式化することで、意味的整合性を確保する。
• 状態空間解析のためのモデルチェック（ProB）を実施したが、高レベルの抽象化ではスケーラビリティの制限により限定的であった。

実験結果

リサーチクエスチョン

• RQ1 安全制御オペレーティングシステムへの誤った実装を引き起こす可能性がある、ARINC 653 Part 1標準仕様に隠れた一貫性の欠如や誤りは何か？
• RQ2 Event-Bを用いてARINC 653の完全な形式的モデルを構築するにはどうすればよいか？ これにより、システム動作とサービス意味論の厳密な検証が可能になる。
• RQ3 Event-Bにおける証明義務による帰納的検証は、抽象化レベル間の整合性を保証し、仕様上の欠陥をどの程度検出できるか？
• RQ4 形式的手法（例：Event-B）は、従来のテストや非形式的分析を超えて、安全制御システム標準の信頼性を向上させることができるか？
• RQ5 現在の形式的検証アプローチには、liveness特性や時間に敏感な動作を扱う際の限界がある。ARINC 653においては、そのような限界は何か？

主な発見

• ARINC 653 Part 1標準仕様に、プロセス管理サービスに1件、インtra/inter-partition通信サービスに2件の隠れた誤りが特定された。
• 特にプロセス状態遷移に関する3件の不完全な仕様が検出され、実装における曖昧または未定義の振るまいを引き起こす可能性があった。
• 帰納的検証プロセスでは、最大80％の証明義務が自動的に放棄され、人的作業の大幅な削減が達成された。
• ProBによるモデルチェックは、状態空間の爆発のため、低レベルの抽象化でのみ実行可能であり、スケーラビリティの課題を浮き彫りにした。
• 形式的モデルは、今後のRodinプラグインによるコード生成を可能にし、ARINC 653準拠システムのモデルベース開発と検証を支援する。
• 本研究では、liveness特性を検証するための強化されたツール支援の必要性が明らかになった。現行のEvent-Bツールチェーンは、グローバル全称記号や複雑な時相論理をネイティブにサポートしていない。