DEOS実用化のためのオープンシステム・ディペンダビリティ

国際標準化戦略

2012-11-23ET2013 スペシャルセッション

オープンシステムディペンダビリティが世界を変える

木下佳樹 武山誠 （神奈川大学）

所 眞理雄（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運用中のシステム変更 外部サービスへの依存

標準化戦略：要件の規格化と技術の標準化

• 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要件はデジュール国際規格として

11

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 assurancePart 1 ~ 4

13

Information Technology Software and systems engineering

IEC 62853 Open Systems Dependability• OSD関連の最上位規格となるもの

• OSDをもつシステムライフサイクルに対する要求を規格化

• DEOS主導で日本からNew Work ItemProposal 提出

’12年12月国際投票通過、’13年1月PT4.8発足

(PL木下)豪中丁仏日韓英が

作業参加14

JISC ・・・ JSA ーTC 56 信頼性専門委員会

IEC 62853 Open Systems Dependability• ４つのプロセス・ビューを規定して、その実現を要求

– 合意形成、説明責任、障害対応、変化対応

• アシュランスケースによるアシュランスは前提

• ４つのアシュランス・メタケースを規定して、アシュランスケースの品質の明示化を要求

– Intra-system consistency,Inter-system consistency,Validity, Confidence

15

purpose, outcomes, implementing activities

IEC 62853 Open Systems DependabilityTC 56 / WG 4 / PT 4.8 (OSD) の新設他を契機に、

• WG 4の主査に木下佳樹（DEOS神奈川大チーム代表）が就任

• WG 4 スコープ変更Information Systems -maintains and developsstandards ondependability of information systemsincluding open systems.

(旧題：system aspects ofdependability)

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ライフサイクルプロセス遂行の中でのアシュランス活動のガイド。２つのプロセス・ビュー：Sys. assurance と Sw. assurance

17

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

Part 2 からJIS化作業進行中

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.

19

IEC 62741 Dependability Case• Dep. caseの内容・適用のガイド、

作成の一般的原則

• 英防衛省の信頼性・保守性ケース標準を英国標準にしたものが元。Customer(軍)⇔Supplier 2者間に閉じた関係が基本

• D-メン3名が IEC規格化に参加、多様なステークホルダを考慮する文言等を導入。

20

DEOS技術の標準仕様化の活動

• The Open Group – TOGAF エンタープライズアーキテクチャフレームワークの発行元

– Open Group StandardReal-Time and Embedded Systems:Dependability through Assuredness™ (O-DA) Framework

• Object Management Group – UML仕様の発行元

– OMG SpecificationStructured 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に概念的モデルを提供

• Architecture1. 実装の指針となる、

システムの形式的記述またはコンポーネントレベルの詳細な計画

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スキーマと意味ツール間のデータ互換性を確保

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 部分

–証拠と、その収集・評価・管理に必要な概念をモデル化

27

D-Case Editorも準拠

OMG MACL• Machine-checkable Assurance Case Language機械的に検査可能なアシュランスケースの記述言語の仕様

• “D-Case in Agda”整合性検証ツールの原理を多くのツールで共有できるように。

28

Goal:G1DemoLineTracker-Robot clears the DemoCourse within 35 sec

Strategy:S1Risk mitigationargument

Context:C2identified 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:G2Risk identificationand mitigationtargets settingare adequate

Evidence:E1Risk AnalysisReport

Goal:G3Each identified risk is mitigated to its mitigation target.

Strategy:S2Argue over identified risks

Goal:G4Communication failureactivates auto-start(vs. Start command notreceived wirelessly)

Evidence:E2Sub D-Case-3

Goal:G5Tracking pecisionis auto-adjustedfor speed (vs.Line tracking tooslow)

Evidence:E3Sub D-Case-1

Goal:G6Losing the lineactivates Search-mode (vs. Losingthe course line)

Evidence:E4Sub D-Case-2

Goal:G7Disturbance bycollision is withinrecoverable range(vs. Collision withother robots)

Evidence:E5Sub D-Case-4

Goal:G8Sensor threshold is auto-adjusted for the lighting (vs.Course lighting interferingwith line sensing)

Evidence:E6Sub 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 を準備中

29

まとめ

• 二方面からの標準化が進行中

– OSD要件の de jure 国際規格化

– DEOS技術の フォーラム標準仕様化

国際・国内の関連標準化コミュニティでOSD, DEOSが認知されてきた。TC56/WG4Convener獲得を含め、DEOS pjが永続的効果を持つための土台を得た。

30