DEOS実用化のための
オープンシステム・ディペンダビリティ
国際標準化戦略
2012-11-23 ET2013 スペシャルセッション オープンシステムディペンダビリティが世界を変える 木下佳樹 武山誠 （神奈川大学） 所 眞理雄（Sony CSL） 横手靖彦（慶応義塾大学）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
• まとめ
標準化はOSD達成の基本技術
• 全体のディペンダビリティ向上なしには、 自システムのディペンダビリティ向上もなし • 社会全体でディペンダビリティの基準を共有することが必須 – 「なにをどこまですればディペンダブル？」に論理的正解はなし • OSDの標準化は技術開発と一体 – 開発済み技術の普及のための標準化とは異なった性格 運用中のシステム変更 外部サービスへの依存OSDの乱れの弊害と標準化の対象
各社がばらばらにOSD導入を目指しても… • リスク対策の「相場感」のなさ ⇒ 開発・運用プロセスの標準化 • 意志疎通の難しさ ⇒ 意思疎通の手段、アシュランスケースの標準化 • 意志疎通の内容、品質のばらつき ⇒ アシュランスケースを対象とした “アシュランス・メタケース” の標準化 • ツール、技術の互換性のなさ ⇒ 技術仕様の標準化 4リスク対策の相場観とプロセス標準化
× リスク対策の相場観のなさ： - 達成度・価値に相場のない目標にコストをかけることの不安 「他社のシステムの障害や変更を、どこまで想定して頑張れば十分と 認められるのか？うちだけがコストを負担するのは避けたい」 - 手探りで他社との新協調体制を作ることの不安 「開発側のうちとしても運用側と一体的にリスク対策をしたいけど、 何しろ別会社でやり方が全然違うからなあ。変に介入されても困るし」 ⇒ 開発・運用・アシュランスのプロセスの標準化 仕事についての概念の標準化（用語、プロセス、成果物、…） (cf. IPA 共通フレーム、意思疎通とアシュランスケース標準化
× 意思疎通の難しさ – 「まさかうちのシステムがこんな使い方をされるとは。 これで障害をうちのせいにされても困る」 – 「まさかあそこのシステムはこう使うとおかしくなるとは。 これで障害をうちのせいにされても困る」 – （被害者）「どこも責任をとってくれない。困る」 – 「どこまで障害発生の事情を説明したら被害者は理解してくれるの だろう。必要以上に他社に秘密をさらすのは困る。」 ⇒ アシュランスケースの標準化 リスクコミュニケーション、責任体制の在り方の標準化 アシュランスケース ： （D-Case概念の一般形） リスク対策の有効性などシステムの性質に 関する主張を明示的な議論で証拠から示す文書 6意思疎通の質とアシュランス・メタケース標準化
× 評価のばらつき、目的意識のばらつき – 「うちで使った市販コンポーネントについてきたアシュランス ケースは、全部うちの基準ではOKだった。 でも発注元には別の基準でダメだといわれてしまった。 買ってきたコンポーネントのアシュランスケースまで、 相手に合わせてうちが書き直すのは大変すぎる」 – 「障害が起こったときの対処を予め相手と話し合っておきたい のに、“そんなことにならないように、お互いちゃんとやりま しょう”といって応じてくれない。」 ⇒ アシュランス・メタケースの標準化 意思疎通の結果であるアシュランスケースが持つ性質を 明示的に示す メタケース を要求して 意思疎通の質・内容の評価を明示化OSD標準 ＝
オープン
システム間のI/F
• コンポーネント／接続先サービスが詳細不明、勝手に変化するので はシステムのディペンダビリティは達成できない。 • クローズドな立場： 「全詳細・全変化を利用システム側に報告せよ!」 – 報告する方もされる方も結局対処できない • OSDの立場: コンポーネント／サービスが一定のディペンダビリティ を満たすことを、利用側が確信できる根拠となる情報を要求 • OSD標準は「一定」の基準、根拠情報の内容・様式を定める I/F 8 運用中のシステム変更 外部サービスへの依存標準化戦略：要件の規格化と技術の標準化
• DEOS成果を二分 – OSDの価値、必要条件の認識→ OSD達成要件の規格化 – 実現のためのDEOS技術体系 → 標準技術仕様の策定 9 標準 内容 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の アシュランスとは D‐Case手法 技術の 標準化 枠組 TOGAF Dep. through Assuredness (O‐DA) Framework Normative part Assured アーキテクチャ の開発の枠組み DEOSプロセスの構成、 DEOS アーキテクチャ D‐Script, D‐ADD, D‐RE, DS‐Bench, … ツ ー ル Informative part 実装のためのツール、技術
OMG Spec. SACM 電子化アシュランスケース D‐Case Editor OMG RFI MACL 機械的に検査可能なアシュランスケース記述言語 D‐Case in Agda
標準化戦略：要件の規格化と技術の標準化
• DEOS成果を二分 – OSDの価値、必要条件の認識→ OSD達成要件の規格化 – 実現のためのDEOS技術体系 → 標準技術仕様の策定 • 標準に適合するものは自然と DEOS成果を含むように。OSD要件はデジュール国際規格として
OSD要件は 国際標準化団体の デジュール規格 として標準化 • 最も広く、公な合意 • …としての権威 • 国家規格、業界標準 への影響力DEOS技術はフォーラム標準仕様として
12 DEOS技術は 有力な業界コンソの フォーラム標準仕様 として標準化 • ツールベンダ、ユーザ からの支持 • 技術的詳細に強み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
• ISO/IEC JTC 1 / SC 7 / WG 7 Life cycle management
– IEC 15026 Systems and software engineering –
Systems and software assurance
Part 1 ~ 4
IEC 62853 Open Systems Dependability
• OSD関連の最上位規格となるもの
• OSDをもつシステムライフサイクルに対する要求を規格化
• DEOS主導で日本から New Work Item
Proposal 提出 ’12年12月国際投票通過、 ’13年1月PT4.8発足 (PL木下) 豪中丁仏日韓英が 作業参加 14 JISC ・・・ JSA ー TC 56 信頼性専門委員会
IEC 62853 Open Systems Dependability
• ４つのプロセス・ビューを規定して、その実現を要求 – 合意形成、説明責任、 障害対応、変化対応 • アシュランスケースに よるアシュランスは前提 • ４つのアシュランス・ メタケースを規定して、 アシュランスケースの 品質の明示化を要求 – Intra-system consistency, Inter-system consistency, Validity, ConfidenceIEC 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)
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
ライフサイクルプロセス遂行の中でのアシュランス活動のガイド。 ２つのプロセス・ビュー：Sys. assurance と Sw. assurance
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
ライフサイクルプロセス遂行の中でのアシュランス活動のガイド。 ２つのプロセス・ビュー：Sys. assurance と Sw. assurance
18
IEC 60300-1 Dependability Management
• 従来型ディペンダビリティの 最上位規格 • Dep. Mgmt.の枠組み、ガイド • D-メン2名がEd 3.0 策定に参加、 OSD規格向けのフック等を導入。 例： “4.3 Challenges of managingdependability…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.
IEC 62741 Dependability Case
• Dep. caseの内容・適用のガイド、 作成の一般的原則 • 英防衛省の信頼性・保守性ケース 標準を英国標準にしたものが元。 Customer(軍)⇔Supplier 2者間に 閉じた関係が基本 • D-メン3名が IEC規格化に参加、 多様なステークホルダを考慮する 文言等を導入。 20DEOS技術の標準仕様化の活動
• 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ベンダ／ユーザ企業、政府機関、 大学、研究機関等が参加する国際的コンソーシアム
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 AssurednessTM (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スキーマと意味 ツール間のデータ互換性を確保
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も 準拠
OMG MACL
• Machine-checkable Assurance Case Language
機械的に検査可能なアシュランスケースの記述言語の仕様 • “D-Case in Agda”整合性検証ツールの
原理を多くのツールで共有できるように。
28
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:G2 Risk identification and mitigation targets setting are adequate Evidence:E1 Risk Analysis Report Goal:G3
Each identified risk is mitigated to its mitigation target. Strategy:S2
Argue over identified risks
Goal:G4
Communication failure activates auto-start (vs. Start command not received wirelessly) Evidence:E2 Sub D-Case-3 Goal:G5 Tracking pecision is auto-adjusted for speed (vs. Line tracking too slow)
Evidence:E3 Sub D-Case-1
Goal:G6 Losing the line activates Search-mode (vs. Losing the course line) Evidence:E4 Sub D-Case-2 Goal:G7 Disturbance by collision is within recoverable range (vs. Collision with other robots) Evidence:E5 Sub D-Case-4 Goal:G8
Sensor threshold is auto-adjusted for the lighting (vs. Course lighting interfering with line sensing)
Evidence:E6 Sub D-Case-5
OMG MACL
• Machine-checkable Assurance Case Language
機械的に検査可能なアシュランスケースの記述言語の仕様 • “D-Case in Agda”整合性検証ツールの
原理を多くのツールで共有できるように。 • ’12年9月 Request For Information 発行
’13年3月 １企業、１研究機関、2大学からレスポンス 現在次段階の Request For Proposal を準備中
