消費者機械の安全標準化 - IPAISO 12100やISO 14121がベースとなっており、 IEC61508は産業プラント安全がベースとなっている． 3. IEC61508は消費者機械の観点からは適用が難しいと

消費者機械の安全標準化

2011年4月19日

大畠明

トヨタ自動車株式会社

IPA-SEC特別セミナー「消費者機械の安全に関する最新動向」

動機

1. 製品に自身があっても、第３者に納得してもらうことが難しい。国際標準の枠組みで、この問題を緩和できないか？

2. 自動車の制御システムの複雑化はさらに進展すると予想される。交通システム、配送システム、エネルギーシステム、情報システムとの連携が進展すると予想される状況で、その準備をしておきたい。

3. システム開発とソフトウェア開発にギャップがあり、それを統合したい。 → 制御ソフトウェアは物理システムとしての制御対象の特徴が反映されているはずであり、それを利用することで、開発と検証を効率化することができないか？

目指したいこと

1. 素早い繰り返し(agile開発?)を標準に入れること！

2. 物理システムと制御装置の振る舞いモデルを標準化の枠組みに入れること！

3. ソフトウェア開発者の意図とは別に、制御ソフトウェアには制御対象の物理と数学が反映しているはず．

物理と数学をソフトウェア開発に反映させること！

発表概要

1. 消費者機械とは？2. ISO262623. 問題提起4. モデルベース開発 (MBD)5. 提言6. まとめ

産業機械と消費者機械

産業機械消費者機械

産業機械と消費者機械の違い

産業機械消費者機械

生産数 a few many a huge number

ユーザ experts general users要求コスト high lowメンテナンス現場

(strongly managed)ﾕｰｻﾞ、ｻｰﾋﾞｽｽﾃｰｼｮﾝ

(weekly managed)環境工場環境

（ほぼ定常）

生産現場

ﾕｰｻﾞ環境

(quite open and dynamic)

消費者機械安全は、開発・製造・利用環境全体を考える必要がある。

消費者機械の特性

ソフトウェアと物理システム間で頻繁な相互作用がある.(There are frequent interactions between physical system and control software.)

Physical systems Control software

Operation environment(passengers, pedestrians, atmosphere, road)

Drivers

関係する領域

ﾌﾟﾛｾｽの小変更が大きな問題に繋がるｹｰｽもある．

検出された不具合は素早く修正が必要

全ての要求・制約を予め把握することは容易でない．

ﾌﾟﾛｾｽの改善情報

開発ﾌｪｰｽﾞ製造ﾌｪｰｽﾞ

ﾕｻﾞｰ利用ﾌｪｰｽﾞ

ｻｰﾋﾞｽｾﾝﾀｰも含める必要

がある．

自動車産業は継続的改善によって、安全高品質な製品を提供できるシステムを構築してきた！

消費者機械の利用環境

産業機械の環境:専門化によって高度に管理され、動作環境は比較的安定している．

消費者機械の環境:非常に多くの一般ユーザが利用し、極めて多様(diverse)、動的(dynamic)、かつ、外界の影響を受け易い(open)環境で利用される。

製品とプロセスの素早い繰り返しと継続的改善が極めて重要！Rapid iterations and continuous improvements are extremely

important for consumer machines working in open, dynamic and diverse environment.

発表概要


背景

1. 自動車の電子制御は急速に複雑化し、その対応が緊急課題となっている．

2. 現在の system assurance は産業機械安全に関するISO 12100やISO 14121がベースとなっており、IEC61508は産業プラント安全がベースとなっている．

3. IEC61508は消費者機械の観点からは適用が難しいと思える．→ ISO26262（自動車）、ISO13482(パーソナルロボット）などの領域毎の標準制定の動向

ISO26262 has been developed by the concern of automotive specific based on IEC61508.

ISO26262とIEC61508の関係1. 自動車のE/Eシステム機能安全

(ISO26262 is the adaptation of IEC61508 to comply with the needs specific to the application sector of Electrical and/or Electronic systems within road vehicles.

2. IEC61508との関係（Part10 Guidelineより抜粋）① IEC61506は産業プラントなどの安全装置のモデルに基づく

a. IEC61508では安全機能のハザードリスクを同定する.b. 自動車安全は制御システム自身の振る舞いに依存する．

② ISO26262は安全検証をリリース前に実施a. IEC61508: one-off or low volumeb. ISO26262: 大量生産

③ ISO26262は複数の組織・サプライチェーンを考慮④ ISAO262はAutomotive scheme for hazard classification

a. IEC61508: SIL (Safety Integrity Level) stated in probabilistic termsb. ISO26262: ASIL (Automotive Safety Integrity Level)

⑤ MBD (Model-Based Development)など最新技術が反映．

ISO26262の特徴1. E/E/EPを対象としている．

2. ASIL(severity, probability of exposure, controllabilityからALARP*ﾚﾍﾞﾙまでの距離で決定）に基づく機能安全のためのマネジメントとプロセスを規定．

3. V-modelに基づいている．(Introduction: Figure 1 shows the overall structure of ISO26262 is based upon a V-model as a reference process model for the different phases of product development.)

4. Safety cases (requirements, argument, evidence)をベースとする．Safety requirements & Objectives

Safety Evidence

Safety Argument

ISO26262 Figure 6 Key elements of a safety case

(ALARP*: as low as reasonably practicable)

発表概要


軽薄な兎と深慮な亀の例え

ほとんどの場合で兎が勝つ！

しかし、複雑さが進むにしたがって、亀が勝つようになる！

This metaphor is from Prof. Fujimoto of University of Tokyo

wise turtlestupid rabbit

消費者機械の品質確立「ほとんどの場合、軽薄な兎が勝つ！」という例えは、

極めて重要なメッセージ！

単純な境界と高精度・高品質な要素素早い繰り返しで全体最適化

高コスト, 荒い最適化？複雑な境界,きめの細かい最適化？

深慮な亀(wise turtle) 軽薄な兎(stupid rabbit)

expensive and rough optimization?complex boundary and fine optimization?

本質的問題

想定内の部分は、通常、上手く対応されている。問題を起こすのは想定外の部分！(The issue is how to manage the portions out of scope.)

想定外(out of scope)

誤想定経験内(experiences)

想定内

試行(trials)

新想定 (new assumptions)

(wrong assumptions)

(right assumptions)

想定を逐次改善

消費者機械安全確立の基本

1. 精度の高い想定の設定

2. 想定外のシステマティックな管理① 想定の設定

② 試行

③ 評価

④ 修正・定着

• 最初のplanの質が低くなり易い• 複雑な開発では上手く行かない事例もPDCAの問題:

Plan

Do

Action Check

Plan

Action：良い事柄を以降の開発に定着させること!

Do

Action Check

Plan

想定外の発見！

日本の強みと弱み

1. 素早い繰り返し

2. 現地現物

3. 入念な擦り合わせ

合理的な価格・安全・高品質

複雑性への対応力が弱い・遅い・標準化困難

短所

長所

ﾄｯﾌﾟﾀﾞｳﾝｱﾌﾟﾛｰﾁが必要

（深慮な亀）

精度の高い予測の課題

Physical systems Control software

Operation environment(passengers, pedestrians, atmosphere, road)

Drivers

1.可能性のある不具合状況を全てｶﾊﾞｰする必要がある。2.検査するｹｰｽが膨大で実行困難！3.モデル誤差の扱いが重要！

リスク同定は制御システムの振る舞い予測がベース

モデルによる事前予測の困難1.文章などで事前に記述することは困難な不具合がある．

2.しかし,現象を見れば（＝振る舞いのデータを見れば）問題を指摘できるｹｰｽがある．

制御対象

(controlled object)コントローラ

(controller)操作

観測

環境(environment)

動的振る舞いの予測

課題： ① 如何に全運転状態をｶﾊﾞｰするか？

(How to cover all possible operation conditions)② モデル誤差をどのように扱うか？

(How to deal with model error)

離散事象系と連続事象系

Controlledobject

controller操作量

environment

観測量

discrete event

discrete＋continuous

Multi dimensional complex logical branches

x1

x2Simple logical branches

複雑なﾛｼﾞｯｸ分岐が検証を

困難にする(NP困難）！

制御ｿﾌﾄｳｪｱは本来もっと単

純なﾛｼﾞｯｸ分岐のはず！

発表概要


MD* and MB*のモデル

ND*: Model Driven DevelopmentModel Driven Architecture

NB*: Model Based DevelopmentModel Based Engineering

System Engineering, Control Engineering

Software Engineering

Model: 動的振る舞いモデル

Model: 関係図?

System assurance

両者は system assuranceで出会うかも？

MBDの概念

controllersoftware hardware

validation

plant hardwarevehicle actuators sensors

Real World

validationVirtual World

*HILSRapid Prototyping ECU

*SILS

combining

combining

Functional Spec. Functional Spec.

*SILS: Software In the Loop Simulation*HILS: Hardware In the Loop Simulation

control design

plant behavior model controller behavior model

要求と制約の例

システム要求 = 望ましい振る舞い(例)

PZEVの排気規制を満たすこと燃料消費率を10%低減触媒床温度は1200K以下であることアイドル時のエンジン速度650±50rpmであること etc.

システム拘束 = 前提とする制約

(例)開発予算は $100M開発期間は 30ヶ月燃料噴射量は [1, 100] mgの範囲スロット弁の最大開速度は20 r/s. etc.

制御設計

Constraints

制御対象の振る舞いモデル望ましい振る舞い

Control design

Control algorithm

Evaluation

Modeling Process

Requirements &Constraints

capturing process

ConstraintsConstraintsConstraintsConstraintsConstraintsConstraintsConstraintsConstraintsConstraintsConstraints制約

MBDの特徴

動的な振る舞いモデル(微分・差分方程式)

1. 制御対象の振る舞いモデル2. 制御装置の振る舞いモデル3. 望ましい制御システムの振る舞いモデル4. ドライバーのモデル5. 環境のモデル

数学的記述

A) 制御アルゴリズムと制御定数の導出B) 制御システムの動的振る舞いの予測

これまでの制御設計ワークフロー

Requirements Specification Sourcecode Object code

CalibrationV&V

Control design process

Verification

Implementation process

制御設計プロセスの中に時間を要す実装プロセスが入り込んでいる。

MBDの制御設計ワークフロー• 制御設計と実装プロセスが分離されている．• 実装プロセスは定義された「入出力関係を目標ECU上で許容誤差範囲内で再現すること」と定義される．

Requirement

VerificationCalibration

simplification objectcodeControlModel

V&V

Control design process

Implementation process

実機試験, SILS, HILS, Rapid Prototyping ECU, Auto-Code Generation,MC/DC, Mode-Based Calibration, etc

発表概要


OMGへの期待

1. 消費者機械 System Assurance標準化体系構築の取り組み（現在の標準化体系は、産業機械安全のISO12100, ISO14120をﾍﾞｰｽとしている。）

2. 信頼性の高いﾌﾟﾛｾｽ構築のためのﾌﾟﾛｾｽ、方法、ﾂｰﾙ連鎖を示すこと（OMGではImplementationを示すことが求められる。）

3. 標準化体系をISOやIECなど他の国際標準化に展開すること

OMGへの提言1. ISO26262のメタモデル(meta model)表現

① 素早い繰り返し、入念な擦り合わせ、現地現物をどのように

組み込むかを明確にし、方向のコンセンサスを形成する。

① 想定外の管理（素早い繰り返し）プロセスの明確化

2. MD*とMB*の統合① Multi-physics modelingをOMGの活動領域とすること② MD*とMB*の統合

3. ソフトウェアへの物理と数学の導入① 離散事象系と連続事象系の明確化

(to distinguish discrete and continuous event portionsof control software)

① 振る舞いモデル表現

(description of dynamic behavior models)

ISO/DIS 26262 機能安全（概念ﾌｪｰｽﾞ）のメタモデル

Multi Physics Modeling

OMGの活動領域Modelingの領域

Modelicaの活動 SysMLとModelicaのinterfaces

標準化活動

現在は、Modelingの領域はOMGからは見えないのでは？(Currently, it’s hard for OMG to see emerging modeling activities?)

今，モデリングが注目されている。（平成２２年度システム

科学技術推進委員会モデリング分科会報告書など）

CRDS-FY2010-XR-20

エンジン制御ソフトウェアの考察

( ){( )

} {( )

};

;

0

1

xfcontrolelse

xfcontrolrpmif s

=

=>ω

if then else logic

( );,ωxfcontrol =physical phenomena

近似

x

ω

control

if then else logic

physical phenomena

engine speed

control

（近似方法は沢山ある！）

sω

数学的な一般表現

( ) ( )( )kukxf ,( )ku

( )kx

( )kx( ) ( )( )kukxg , ( )ky

( ) ( ) ( )( )( ) ( ) ( )( )kukxgky

kukxfkx,

,1=

=+ ( ) ( ) ( )[ ]( ) ( ) ( )[ ]( ) ( ) ( )[ ]ttdtc

ttd

tc

ttd

tc

kykyky

kukuku

kxkxkx

=

=

=

, where

1つのtask内でのロジックは全て下記で表現できる!

( ) ( )( ) ( )( ) ( ) outputsdiscretekyoutputscontinuousky

nputsidiscretekunputsicontinuouskuvariablesdiscretekxvariablescontinuouskx

dc

dc

dc

::::::

理論的にはﾃｰﾌﾞﾙ表現できる（= ﾛｼﾞｯｸ変更はﾃｰﾌﾞﾙ変更に帰着する，ﾃｰﾌﾞﾙは静的なので検証は容易）！

z1

物理と数学の導入

1.ロジック分岐が検証を困難にしている．2.可能な限りロジック分岐(≒離散事象系）を減らしたい．

連続事象系と離散事象系の区別が困難

例）

z11 z12 z13z21 z22 z23z31 z32 z33

x

y

( )yxfz ,=

テーブルは関数の近似表現かもしれない．連続事象系か離散事象系かはコードではなく，対象の物理的意味で決定する．

(The distinction between discrete and continuous events highly depends on the physical meanings.)

テーブル参照のコードは多数のロジック分岐から

なるが．．．

最初のステップ1. アルゴリズムの選択肢は無限にあると考えるべき．

2. 検証の観点から，ロジック分岐は最小限にすべき．

物理的な意味からｿﾌﾄｳｪｱの連続事象と離散事象系を区別

(Discrete and continuous event portions of control software are distinguished by the physical contexts.)

しかし，ｺｰﾄﾞでは全てが離散事象系になってしまう．

それぞれに最適な検証を適用することで，効率的な

検証の道が開ける可能性がある．(The distinction willderive effective verification and validation.)

Auto-code generationも容易になると思われる．

発表概要


まとめ

1. OMGを通した消費者機械安全国際標準化の取り組み！

2. 想定外を減らすには，素早い繰り返しによって対応しなければならない．

3. システムの動的振る舞い予測がリスク同定の本質であり，物理システムの振る舞いモデルをOMGの活動領域にして欲しい．

4. ISO26262の体系をメタモデル化し，２と３項への取り組みを明確化したい。

5. 長期的には物理と数学をソフトウェア開発に導入したい．

消費者機械の安全標準化動機目指したいこと発表概要発表概要産業機械と消費者機械産業機械と消費者機械の違い消費者機械の特性関係する領域消費者機械の利用環境発表概要背景ISO26262とIEC61508の関係ISO26262の特徴発表概要軽薄な兎と深慮な亀の例え消費者機械の品質確立本質的問題消費者機械安全確立の基本日本の強みと弱み精度の高い予測の課題モデルによる事前予測の困難離散事象系と連続事象系発表概要MD* and MB*のモデルMBDの概念要求と制約の例制御設計MBDの特徴これまでの制御設計ワークフロー MBDの制御設計ワークフロー発表概要OMGへの期待OMGへの提言ISO/DIS 26262 機能安全（概念ﾌｪｰｽﾞ）のメタモデルMulti Physics Modelingエンジン制御ソフトウェアの考察数学的な一般表現物理と数学の導入最初のステップ発表概要まとめ

Documents

消費者機械の安全標準化 - IPAISO 12100やISO 14121がベースとなっており、 IEC61508は産業プラント安全がベースとなっている． 3. IEC61508は消費者機械の観点からは適用が難しいと