DEOS 実用化のための オープンシステム ディペンダビリティ 国際標準化戦略 2012-11-23 ET2013 スペシャルセッション オープンシステムディペンダビリティが世界を変える 木下佳樹武山誠 ( 神奈川大学 ) 所眞理雄 (Sony CSL) 横手靖彦 ( 慶応義塾大学 ) Research supported by JST CREST research area DEOS
DEOS 実用化のためのオープンシステム ディペンダビリティ国際標準化戦略 標準化は OSD 達成の基本技術 OSD の乱れの弊害と標準化の対象 標準化戦略 OSD 要件の規格化と DEOS 技術の標準仕様化 OSD 要件の規格化活動 ISO/IEC 15026 Systems and software assurance IEC 62853 Open Systems Dependability IEC 62741 Dep. case, IEC 60300-1 Dep. Mgmt. Sys. DEOS 技術の標準仕様化活動 The Open Group: Real-Time and Embedded Systems: Dependability through Assuredness Framework OMG 仕様 Structured Assurance Case Metamodel OMG 仕様提案 Machine-checkable Assurance Case Language まとめ 2
標準化は OSD 達成の基本技術 全体のディペンダビリティ向上なしには 自システムのディペンダビリティ向上もなし 社会全体でディペンダビリティの基準を共有することが必須 なにをどこまですればディペンダブル? に論理的正解はなし OSD の標準化は技術開発と一体 開発済み技術の普及のための標準化とは異なった性格 運用中のシステム変更 外部サービスへの依存 3
OSD の乱れの弊害と標準化の対象 各社がばらばらに OSD 導入を目指しても リスク対策の 相場感 のなさ 開発 運用プロセスの標準化 意志疎通の難しさ 意思疎通の手段 アシュランスケースの標準化 意志疎通の内容 品質のばらつき アシュランスケースを対象とした アシュランス メタケース の標準化 ツール 技術の互換性のなさ 技術仕様の標準化 4
リスク対策の相場観とプロセス標準化 リスク対策の相場観のなさ : - 達成度 価値に相場のない目標にコストをかけることの不安 他社のシステムの障害や変更を どこまで想定して頑張れば十分と認められるのか? うちだけがコストを負担するのは避けたい - 手探りで他社との新協調体制を作ることの不安 開発側のうちとしても運用側と一体的にリスク対策をしたいけど 何しろ別会社でやり方が全然違うからなあ 変に介入されても困るし 開発 運用 アシュランスのプロセスの標準化 仕事についての概念の標準化 ( 用語 プロセス 成果物 ) (cf. IPA 共通フレーム ISO/IEC 12207 Software life cycle processes) 5
意思疎通とアシュランスケース標準化 意思疎通の難しさ まさかうちのシステムがこんな使い方をされるとは これで障害をうちのせいにされても困る まさかあそこのシステムはこう使うとおかしくなるとは これで障害をうちのせいにされても困る ( 被害者 ) どこも責任をとってくれない 困る どこまで障害発生の事情を説明したら被害者は理解してくれるのだろう 必要以上に他社に秘密をさらすのは困る アシュランスケースの標準化リスクコミュニケーション 責任体制の在り方の標準化 アシュランスケース : (D-Case 概念の一般形 ) リスク対策の有効性などシステムの性質に関する主張を明示的な議論で証拠から示す文書 6
意思疎通の質とアシュランス メタケース標準化 評価のばらつき 目的意識のばらつき うちで使った市販コンポーネントについてきたアシュランスケースは 全部うちの基準ではOKだった でも発注元には別の基準でダメだといわれてしまった 買ってきたコンポーネントのアシュランスケースまで 相手に合わせてうちが書き直すのは大変すぎる 障害が起こったときの対処を予め相手と話し合っておきたいのに そんなことにならないように お互いちゃんとやりましょう といって応じてくれない アシュランス メタケースの標準化意思疎通の結果であるアシュランスケースが持つ性質を明示的に示すメタケースを要求して意思疎通の質 内容の評価を明示化 7
OSD 標準 = オープンシステム間の I/F コンポーネント / 接続先サービスが詳細不明 勝手に変化するのではシステムのディペンダビリティは達成できない クローズドな立場 : 全詳細 全変化を利用システム側に報告せよ! 報告する方もされる方も結局対処できない OSDの立場 : コンポーネント / サービスが一定のディペンダビリティを満たすことを 利用側が確信できる根拠となる情報を要求 OSD 標準は 一定 の基準 根拠情報の内容 様式を定める I/F 運用中のシステム変更 外部サービスへの依存 8
要件のD Case 手法技術の標準化ツール標準化戦略 : 要件の規格化と技術の標準化 DEOS 成果を二分 OSD の価値 必要条件の認識 OSD 達成要件の規格化 実現のための DEOS 技術体系 標準技術仕様の策定 標準内容 DEOS 成果規格化規定 実現 枠組IEC 62853 Open Sys. Dep., IEC 60300 1 Dep. Mgmt. Sys OSD を持つライフサイクルとは OSD 概念 DEOS プロセスの仕様 ISO/IEC 15026 Sys. Sw. Assurance, IEC 62741 Dep. case, IEC62853 ライフサイクルの持つ OSD のアシュランスとは TOGAF Dep. through Assuredness (O DA) Framework Normative part Assured アーキテクチャの開発の枠組み Informative part 実装のためのツール 技術 DEOS プロセスの構成 DEOS アーキテクチャ D Script, D ADD, D RE, DS Bench, OMG Spec. SACM 電子化アシュランスケース D Case Editor OMG RFI MACL 機械的に検査可能なアシュランスケース記述言語 D Case in Agda 9
標準化戦略 : 要件の規格化と技術の標準化 DEOS 成果を二分 OSD の価値 必要条件の認識 OSD 達成要件の規格化 実現のためのDEOS 技術体系 標準技術仕様の策定 標準に適合するものは自然と DEOS 成果を含むように
OSD 要件はデジュール国際規格として OSD 要件は国際標準化団体のデジュール規格として標準化 最も広く 公な合意 としての権威 国家規格 業界標準への影響力 11
DEOS 技術はフォーラム標準仕様として DEOS 技術は有力な業界コンソのフォーラム標準仕様として標準化 ツールベンダ ユーザからの支持 技術的詳細に強み 12
OSD 達成要件の規格化活動 IEC TC 56 Dependability - 電気電子に限らず Dep. 規格の元締め IEC 62853 Open Systems Dependability IEC 60300-1 Dependability Management Part 1: Guidance for management and application IEC 62741 Guide to the demonstration of dependability requirements. The dependability case Information Technology Software and systems engineering ISO/IEC JTC 1 / SC 7 / WG 7 Life cycle management IEC 15026 Systems and software engineering Systems and software assurance Part 1 ~ 4 13
IEC 62853 Open Systems Dependability OSD 関連の最上位規格となるもの OSD をもつシステムライフサイクルに対する要求を規格化 JISC JSA ー TC 56 信頼性専門委員会 DEOS 主導で日本から New Work Item Proposal 提出 12 年 12 月国際投票通過 13 年 1 月 PT4.8 発足 (PL 木下 ) 豪中丁仏日韓英が作業参加 14
IEC 62853 Open Systems Dependability 4 つのプロセス ビューを規定して その実現を要求 合意形成 説明責任 障害対応 変化対応 アシュランスケースによるアシュランスは前提 4 つのアシュランス メタケースを規定して アシュランスケースの品質の明示化を要求 Intra-system consistency, Inter-system consistency, Validity, Confidence purpose, outcomes, implementing activities 15
IEC 62853 Open Systems Dependability TC 56 / WG 4 / PT 4.8 (OSD) の新設他を契機に WG 4 の主査に木下佳樹 (DEOS 神奈川大チーム代表 ) が就任 WG 4 スコープ変更 Information Systems - maintains and develops standards on dependability of information systems including open systems. ( 旧題 :system aspects of dependability) 16
ISO/IEC 15026 Systems and Software Assurance アシュランスケース関連の最上位規格となるもの ISO/IEC JTC1 SC7 WG7 での大幅改訂作業に DEOS メンバー 2 名がエディタとして参加 OSD 的考えを導入 4 パート構成 今年 10 月までに全パートが IS として発行済み Part 1: Concepts and Vocabulary 概念 用語集 Part 2: Assurance Case 要素 構成 内容の必須要件 Part 3: System Integrity Level 完全性水準 体系を設定して適用するとは の要件 ガイド Part 4: Assurance in the life cycle ライフサイクルプロセス遂行の中でのアシュランス活動のガイド 2 つのプロセス ビュー :Sys. assurance と Sw. assurance 17
ISO/IEC 15026 Systems and Software Assurance アシュランスケース関連の最上位規格になっていくもの ISO/IEC Part 2 JTC1 からJIS SC7 化作業進行中 WG7 での大幅改訂作業に DEOS メンバー 2 名がエディタとして参加 OSD 的考えを導入 4 パート構成 今年 10 月までに全パートが IS として発行済み Part 1: Concepts and Vocabulary 概念 用語集 Part 2: Assurance Case 要素 構成 内容の必須要件 Part 3: System Integrity Level 完全性水準 体系を設定して適用するとは の要件 ガイド Part 4: Assurance in the life cycle ライフサイクルプロセス遂行の中でのアシュランス活動のガイド 2 つのプロセス ビュー :Sys. assurance と Sw. assurance 18
IEC 60300-1 Dependability Management 従来型ディペンダビリティの最上位規格 Dep. Mgmt. の枠組み ガイド D-メン2 名がEd 3.0 策定に参加 OSD 規格向けのフック等を導入 例 : 4.3 Challenges of managing dependability Systems are becoming more complex and can exhibit the characteristics of open systems or systems of systems. The systems can be managed by different parties that have different objectives and can be at different stages of the life cycle. This, together with the scale and complexity of the system makes it difficult for any stakeholder to comprehend the system as a whole and changes are thus less predictable and controllable. For that reason, it is crucial for stakeholders to understand and agree on the boundaries of their responsibilities and to assign accountability for implementation. Planning for dependability needs to take into account major failures and changes outside respective boundaries as well as inside. 19
IEC 62741 Dependability Case Dep. case の内容 適用のガイド 作成の一般的原則 英防衛省の信頼性 保守性ケース標準を英国標準にしたものが元 Customer( 軍 ) Supplier 2 者間に閉じた関係が基本 D-メン3 名が IEC 規格化に参加 多様なステークホルダを考慮する文言等を導入 20
DEOS 技術の標準仕様化の活動 The Open Group TOGAF エンタープライズアーキテクチャフレームワークの発行元 Open Group Standard Real-Time and Embedded Systems: Dependability through Assuredness (O-DA) Framework Object Management Group UML 仕様の発行元 OMG Specification Structured Assurance Case Metamodel (SACM) (OMG RFI) Machine-checkable Assurance Case Language (MACL) TOG, OMG ともに IT ベンダ / ユーザ企業 政府機関 大学 研究機関等が参加する国際的コンソーシアム 21
DEOS: Made It Standard Dependability through Assuredness (O-DA) がオープングループ標準として 2013 年 7 月 18 日にボードミーティングにて承認され 2013 年 7 月 15 日に CEO の Allen Brown によって発表されました
O-DA Objective Assured and/or Dependable Architecture 開発のための Framework 定義とガイド Architect に概念的モデルを提供 Architecture 1. 実装の指針となる システムの形式的記述またはコンポーネントレベルの詳細な計画 2. コンポーネントの構造 コンポーネント間の相互関係 および コンポーネントの設計と時間的進化を律する原則とガイドライン Framework 内容またはプロセスの構造であって 整合性 完全性を確保しつつ思考を構造化する道具として使えるもの 幅広く様々なArchitectureを開発するのに使える道具 情報システムを基本要素の組み合わせとして設計する方法を記述 ツール群と共通語彙の定義を含む 基本要素の実装に使える推奨標準と適合製品のリストを含む
The Dependability through Assuredness TM (O- DA) Framework O-DA の Normative part. ( 第 3 章 ) Assured Architecture 開発において Architect が考慮すべき Assurance と Dependability に関するすべての概念を記述 5 つの要素 1) テ ィペンダビリティ モデリング 2) アシュランスケース開発 3) 説明責任 4) 障害対応サイクル 5) 変化対応サイクル IEC 62853 何が達成されるべきか / 抽象的 汎用 O-DA 如何に達成できるか / 具体的 実用で整理予定
O-DA Framework Guidelines etc. O-DA の informative 部 (4,5 章 ) には O-DA Framework を実行するためのガイドラインとして以下が含まれている 1) 関係標準規格 (FAIR,SACM,SBVR) との関連 2) アシュランスケースの表記方法に関する既存技術との関係 3) 確信度 (confidence) の高いアシュランスケース開発に関する議論 4) 形式的手法 (formal method) の利用に関する議論 付録情報 (appendix) として 以下が記載されている 1) TOGAF ADMのO-DA 標準を利用しての適用事例 2) DEOSプロセスおよびアーキテクチャへの適用事例
OMG SACM Structured Assurance Case Metamodel アシュランスケース記述用 XML スキーマと意味ツール間のデータ互換性を確保 26
OMG SACM Structured Assurance Case Metamodel アシュランスケース記述用 XML スキーマと意味ツール間のデータ互換性を確保 System Assurance Task Force で作業 元 D- メン Co-Chair + D- メン 2 名参加 13 年 2 月 Ver. 1.0 発行 来月 Ver. 1.1 成立予定 Core 部分 主張 議論等の概念をモデル化 ISO 15026-2 より詳細化された概念 Evidence Metamodel 部分 証拠と その収集 評価 管理に必要な概念をモデル化 D-Case Editor も準拠 27
OMG MACL Machine-checkable Assurance Case Language 機械的に検査可能なアシュランスケースの記述言語の仕様 D-Case in Agda 整合性検証ツールの原理を多くのツールで共有できるように Goal:G1 DemoLineTracker-Robot clears the DemoCourse within 35 sec Strategy:S1 Risk mitigation argument Context:C2 identified risks: Start command not received wirelessly Line tracking too slow Losing the course line Collision with other robots Course lighting interfering with line sensing Goal:G3 Each identified risk is mitigated to its mitigation target. Goal:G2 Risk identification and mitigation targets setting are adequate Evidence:E1 Risk Analysis Report Strategy:S2 Argue over identified risks Goal:G5 Goal:G7 Tracking pecision Disturbance by is auto-adjusted collision is within for speed (vs. recoverable range Line tracking too (vs. Collision with slow) other robots) Evidence:E3 Sub D-Case-1 Evidence:E5 Sub D-Case-4 Goal:G4 Communication failure activates auto-start (vs. Start command not received wirelessly) Goal:G6 Losing the line activates Searchmode (vs. Losing the course line) Goal:G8 Sensor threshold is autoadjusted for the lighting (vs. Course lighting interfering with line sensing) Evidence:E2 Sub D-Case-3 Evidence:E4 Sub D-Case-2 Evidence:E6 Sub D-Case-5 28
OMG MACL Machine-checkable Assurance Case Language 機械的に検査可能なアシュランスケースの記述言語の仕様 D-Case in Agda 整合性検証ツールの原理を多くのツールで共有できるように 12 年 9 月 Request For Information 発行 13 年 3 月 1 企業 1 研究機関 2 大学からレスポンス現在次段階の Request For Proposal を準備中 29
まとめ 二方面からの標準化が進行中 OSD 要件の de jure 国際規格化 DEOS 技術のフォーラム標準仕様化 国際 国内の関連標準化コミュニティで OSD, DEOS が認知されてきた TC56/WG4 Convener 獲得を含め DEOS pj が永続的効果を持つための土台を得た 30