「EV時代の到来とともに増加する
ソフトウェア起因の事故に対峙するには」〜 IoT時代に必要なリスクベースアプローチと安全アーキテクチャ 〜」
Rev. 1JaSST'19 Tokai
2019年10月4日
組込みソフトウェア管理者・技術者育成研究会 酒井 由夫
P.1

IEC SC62A TC62 JWG3 / JWG7 Japan Committee Member
・Discussing IEC 62304, IEC 82304-1, IEC80001 Series etc.

電子情報技術産業協会

工業会の活動
組織内活動

品質保証部門

支援部門

2006年 より製品開発部門私の職歴
19年
1987-2006
ソフトウェアエンジニア、アーキテクト、マネージャ

13年
2006－1019
規格適合支援、ソフトウェア品質支援

P.2

著書

2006年

2010年

2016年

ブログ
組込みソフトウェア工房
特集記事• ISO 26262 との向き合い方• USのヘルスITの取り組み• RaspberryPi3 を使ったリアルタイム波形描画
P.3

問題提起
そもそも何のために安全に関するソフトウェアの活動は必要なのか︖• 歴史的には事故の再発防止のために技術は発展してきた。
• FMEAしかり、FTAしかり• ⾃動⾞業界ではソフトウェア起因の事故は頻発している︖（してないのでは︖）• でも、今後 EV や⾃動運転技術導⼊後も同じか︖（同じではないのでは︖）• まったく異なる業務ドメインの技術者やソフトウェアと連携してサービスを提供することになる。
•

それが原因で発生するインシデントやアクシデントが増えてくる。それをどうやって防ぐのか。

→新しい要求、基本機能、基本アーキテクチャ、新しい要求と基本機能との関係
性、ハザードに至る一連の事象、安全を実現するアーキテクチャが必要になる。
P.4

1. 国際規格との向き合い方
a.
b.
c.
d.
e.
f.
g.

ソフトウェア起因の不具合の特徴
ソフトウェア品質の歴史的推移
文化の違い
そもそも国際規格ってなに？
ソフトウェア系の規格を認証する意味とは？
ISO 26262の概要とポイント
ISO 26262の工業会の取り組み
P.5

ソフトウェア起因の不具合の特徴
HARDWARE
ランダム故障は確率論的に発生する。

USABILITY
ユーザビリティエラーは可能性を推定する。
HIGH
しばしば
時々
わずかに
起こりそうにない考えられないLOWSOFTWARE
ソフトウェア起因の不具合の確率や可能性を推定することは困難である。

•ソフトウェアは⾒えない.
•ソフトウェア起因の不具合は確率論的ではなく、決定論的に
発生する。
P.6

Systematic Failures/Faults（決定論的原因故障/障害）
ハードウェアの設計に起因するもの、ソフトウェアのバグやソフトウェアに起因する問題やユーザーオペレーションが原因で発生する障害発生率の予測が難しい故障/障害
出荷前の検査で発⾒することが難しく、出荷後に故障や障害が発生してから始めて分かることが多い。
開発のプロセス（工程）、ライフサイクルの中で Systematic
Failures/Faults の作り込みを防止し、検証や妥当性確認によって発⾒・除去する。
参考︓IEC 61508-3:2010, ISO 26262-1:2011
P.7

参考︓広島市⽴⼤学 ⼤場充 教授 講演「⺠主主義原理に基づくソフトウェア品質論⼊門」

ソフトウェア品質論の歴史的推移（広島市立大学 大場充 教授 講演「民主主義原理に基づくソフトウェア品質論入門」 を参考に作成）

統計的品質管理論
統計重視

ZD(Zero Defect)運動

プラグマティズム的品質論
プロセス重視プラグマティズム的組織論（プロセス改善）

ソフトウェアで欠陥ゼロはあ
り得ないと思いません︖

ソフトウェア開発プロセスの成熟度評価モデル「当たり前品質」「魅力的な品質」

価値・顧客満足重視

CS（顧客満足）運動
民主主義原理に基づく品質論

1900年～

1960年代1970年代1980年代1990年代2000年代2010年代P.8

問題提起
⾃動⾞業界では、サプライチェーン上のサプライヤから供給された部品をアセンブリして商品化する製造工程を永年続けてきたた
め、部品の信頼性を高めることで製品の信頼性も高まると考えているのではないか︖
その考え方は、数百万⾏を超えた規模のソフトウェ
アシステムには、使えなくなっている。
もしも、できているならば奇跡的であり、日本人の“品質を⼼配する意識”がギリギリ実現可能にしているのではないか。
出典︓https://www.fujitsu.com/jp/group/fri/column/opinion/201112/2011-12-2.html

P.9参考︓ 日経ものづくり 2010年8月号 の特集記事『ソフトが揺さぶる製品安全』

安全設計の分類
個別最適の発想

全体最適の発想
フェール・セーフ
個々の構成要素に故障やバグがあっても必ず安全側に落ち着くようにする
設計（信頼性よりも安全性を優先する）

フォールト・アボイダンス

フォールト・トレランス

個々の構成要素の信頼性を高めることで安全性を確保しようとする設計（構成要素の故障やバグを認めない）個々の構成要素の故障やバグがあっても別の⼿段（冗⻑性や多重化など）によって機能を維持しようとする設計（構成要素の故障やバグを前提とする）

対照的

エラー・プルーフ（フール・プルーフ）
間違った操作をしようとしても危険が発生しないようにする設計。

機器の使用者

ユーザビリティ

P.10

2008年 第15回 品質機能展開シンポジウム 特別講演 GD3 コンサルティング代表/JMAC GD3 センター⻑ 吉村達彦 ⽒発表資料より文化の違い(Difference in Cultures)

顧客満⾜度 99.5〜99.6%

顧客満⾜度 99.7〜99.8%
P.11

そもそも国際規格って何？
ISO規格とは
ISOとは International
Organization for Standardization（国際標準化機構）の略称
電気・電子及び電気通信以外のあらゆる分野の国際規格の作成を⾏う国際標準化機関

IEC規格とは
IECとは International
Electrotechnical Commission（
国際電気標準会議）の略称
電気及び電子技術分野の国際規格の作成を⾏う国際標準化機関

標準規格には、強制規格と任意規格があり、ISO, IEC, JIS は任意規格であり、規制に使うかどうかは、各国の規制当局が決める。
ISO/IEC規格は、各国から代表（国際エキスパート）が新規提案、コメント募集、議論を重ね、最終的には投票によって国際規格とするかどうかを決定する。規格の⾒直しの期間も定められている。→国際規格を神の啓示のようにあがめるのは間違い。
規格を取りまとめている国内委員会に参加すれば、意⾒を⾔うこともできる。
P.12

ソフトウェア系の規格を認証する意味とは？
⾃動⾞
メーカ
プライベート認証
第三者認証機関による試験

ソフトウェアエンジニア

規制当局認定されたテスト機関による試験
CBスキーム認証
P.13

認証を受けることの意味
良い⾯
⾃社の取り組みについて第三者に認められたことになる。
取り組みを普及促進、継続するためのモチベーション・インセンティブとなる。
業界全体の底上げにつながる。

悪い⾯
そもそも、ソフトウェア系の規格要求への適合の可否の判定が妥当かどうかが怪しい。
規格に適合することが目的となり、本質（何のための活動か︖）が忘れられる。
規格認証ビジネスが活発になり、認証コストが利益を圧迫する。

【⼤事なこと】• 規格要求事項の一つ一つが「何のためにあり」「目的（例えば安全）にどう役⽴つのかを常に考えておくこと。
• 目的（安全）に役⽴つという確信がなければ、モチベーション高く活動を続けることは
できない。
P.14

ISO 26262 の概要図とポイント

安全を実現するために必要な具体的な要求がなんなのかを押さえる。

3.6 及び 12.8 のハザード分析及びリ
スクアセスメント12.10 安全妥当性確認

安全を実現するためのソフト
ウェアアーキテクチャが、ソフトウェアの変更によって、崩れていないかどうかを確認する必要がある。

が EVや⾃動運転が実用化されると重要になると予想される。

ツール使用の信頼性やソフト
ウェアコンポーネントの認定は全体の中の一部にすぎない。

構成管理、変更管理を含むソフトウェアのプロセスアプ
ローチは近代のソフトウェア
開発では、避けることのできない管理⼿法である。

出典︓一般財団法人 日本⾃動⾞研究所（JARI） WEBサイトより
http://www.jari.or.jp/tabid/112/Default.aspx

P.15

ISO 26262に対する工業会の取組み

出典︓一般財団法人 日本⾃動⾞研究所（JARI） WEBサイトより
http://www.jari.or.jp/tabid/112/Default.aspx
P.16

2. そもそも何のための活動？

1.
2.
3.

セーフティ・クリティカルシステムを取り巻く環境
ソフトウェアに対する安全要求がある分野
プロセスアプローチだけで安全は確保できるか？

P.17

そもそも
（機能安全って）何のための活動なの？
P.18

安全の技術は事故の再発防止のため
歴史的には事故の再発防止のために技術は発展してきた。
FMEAしかり、FTAしかり、Thearc-25しかり
⾃動⾞業界では、何か現時点で起こっているのか︖
日本では、技術者の気付き（Awareness）で未然に防いでいたのではないか。

今後の EV でも同じように、Awareness事故を防ぐことができるのか︖
P.19

P.20

http://ja.wikipedia.org/フォルトツリー解析 参照

FTA(Fault Tree Analysis)とはフォルトツリー解析（Fault Tree Analysis︓略してFTA）とは、故障・事故の分析⼿法である。
国際規格
IEC 61025:1990 Fault tree analysis(FTA)JIS Z 8115:2000
フォールトの木解析と定義されているが、故障の木解析と呼ぶこともある。

JIS C 5750-4-4ディペンダビリティ マネジメント

第 4-4 部︓システム信頼性のための解析技法−故障の木解析（FTA）

FTAは、望ましくない事象に対しその要因を探る、トップダウンの解析⼿法を特徴とする。これは、類似のFMEA（故障モード影響解析）とは逆のアプローチになる。

P.21

FTA(Fault Tree Analysis)の歴史
原子力、化学プラント、
交通システムなどに幅広く利用されている。

1965年

1961年

現在

ボーイング社によって補完され完成度が高められた。

米国のBELL研究所の H・A・ワト
ソンらによってミニットマンミサ
イルの信頼性評価・安全性解析を目的に考案された。
P.22

ミニットマンミサイル■旧ミサイル旧大陸間弾道ミサイル、アトラ
ス・タイタンは液体燃料ロケッ
トで、発射直前に酸化剤の注入に必要性があり即応性に問題があった。
• 燃料漏れ事故が多かった■新ミサイルの特長
ミニットマンミサイルは即応性を高めるため固体燃料を使っている。燃焼制
御技術の開発が必要だったが、小型軽量かつ安価だった。
• ボーイング社が開発• 3段式• 1基6億円(700万ドル）• 1965年までに800基配備• メンテナンス不要• 即時発射可能

ハードウェア
起因の事故■新ミサイルの欠点
燃焼制御が難しく、振動がひどい。
電子装置が振動に耐えられず故障する。
↓
そのためFTAが考案された■技術的課題の克服
4基ジンバルノズルによる3軸制御姿勢制御、振動にも故障しないロバートノイスが発明した7mm四方のシリコン基板に電子回路を組み込んだ集積回路による高性能コンピユータ制御により小型化に成功。

P.23

https://commons.wikimedia.org/wiki/File:Minuteman_III_diagram.png http://blogs.yahoo.co.jp/bdcxs228/33339822.html 参照

ミニットマンミサイルの構造

ミニットマンの電子誘導装置。これだ
け液体燃料ロケットの大型トランジス
タ回路誘導装置に比べて小型軽量、高性能化したのは集積回路のおかげ。
P.24

http://ja.wikipedia.org/FMEA 参照

FMEAとはFMEA（Failure Mode and Effect Analysis）は、故障・不具合の防止を目的とした、潜在的な故障・不具合の体系的な分析方法である。
国際規格

IEC 60812:2006 システム信頼性の解析技法－故障モード影響解析(FMEA)の
⼿順
JIS C 5750-4-4第 4-4 部︓システム信頼性のための解析技法−故障の木解析（FTA）

FMEA(意味︓故障モードとその影響の解析）は、「設計の不完全や潜在的な欠点を⾒出すために構成要素の故障モードとその上位アイテムへの影響を解析する技法」である。
フォルトツリー解析(Fault Tree Analysis)FTAがトップダウン⼿法であるのに対し、FMEAはボトムアップ⼿法という違いがある。

P.25

FMEA（Failure Mode and Effect Analysis)の歴史"Procedure for performing a failure mode effect and criticality analysis, November 9, 1949, United States Military Procedure, MIL-P-1629"

⽶国フォード社の「ピント」が高速道路で突然エンストして停⾞していたところ、約50km/hの速度で⾛ってきた
後続⾞に追突されて炎上し、運転者が死亡、同乗者が重度の⽕傷を負う事故が発生した。
フォードモーター社の Pinto のトラブルをきっかけにして、
FMEAは自動車業界に安全性、生産、設計分野での改良の方法として取り入れられた。

1960年代1949年

1970年頃
ハードウェア
起因の事故

アポロ計画などのミッションのためのロケット工学のテストでNASAに採用され、1960年代に月に初めて人間が降り立ったことでその有効性が認められた。

“故障モードの影響及び分析の手順”というタイトルのマニュアルとして米陸軍マニュアルが発行された。
••

システムや設備の故障の影響を決定するための信頼性及び評価のテクニックとして使われた。
故障はミッションの成功及び人員や設備の安全への影響の度合いによって分類された。
P.26

そもそも何のための活動？
答え

1. 事故（インシデント/アクシデント）を未然に防ぐため。

現状で、事故（インシデント/アクシデント）が多く発生していないなら、活動にモチベーションが上がらない。
– 特に Awareness で動く日本のエンジニアにとってインセンティブにならない。

これまで⾃動⾞業界でソフトウェア起因の事故が多発してこなかったのは、「⾛る」「止まる」「曲がる」の基本機能、基本性能が侵食されるケースがなかったからではないか。それは EV時代でも同じか︖

2. 発生してしまった事故（インシデント/アクシデント）の再発を防止するため。
•

Intended Use（意図する使用）や使用環境が多様であればあるほど、ソフト
ウェア起因の事故は⼤小様々発生する。

医療機器では体温計からMRI（スモールMEからラージME）まで、診断装置から生命維持装置（クラスⅠからクラスⅣ）までさまざまな機器が存在し、ソフトウェア起因の多種多様な事故が発生している。
P.27

自動車業界の取り組みの過去/現在/未来
過去/現在

インシデント/アクシデントが発生していない状況で、規格に適合していることが求め
られる。

未来

規格適合ビジネスが盛んになる。
エンジニアは活動の効果を実感することができず、モチベーションが下がり、活動が形骸化する。

EV時代には、限られたメーカーだけでなく、新規参⼊を含めさまざまな企業が⾃動⾞ドメインに参⼊する。
⾃動⾞がネットワークに接続し、⾃動運転が普及することで、ソフトウェアが「⾛る」「止まる」「曲がる」の基本機能・基本性能を制御するようになる。
いままで想定もしなかったインシデント/アクシデントが発生し、危害に至る。
安全なソフトウェアを開発し、維持する活動は、事故を未然に防ぐ、また、再発防止の活動となる。
エンドユーザと対峙しないソフトウェアエンジニアの関わりも増えることになり、セーフティを実現するためのマネジメントの重要性が増す。(Awarenessだけでは事故を防げなくなる）
P.28

3. ケーススタディ

1.
2.
3.
4.

緊急操舵回避システム
システムの複雑化とリスクコントロール
エレベータモデル
電気メスモデル

P.29

3-1.
Case Study 1

P.30

自動車のアーキテクチャの基本
曲がる

止まる

走る

どっちの責任でしょう？
転載禁止

P.31

参考︓ 日産ニュースリリース『日産⾃動⾞、「緊急操舵回避支援システム」を開発』

システムは複雑化し協調して Intended Use（意図した使用目的） を満たすようになる【前方衝突回避支援コンセプト】
対象物を検知・識別する。
ドライバーに警告を発する。
緩やかな減速を開始。
衝突に備えてシートベルトをきつく締める。
コンマ数秒後、システムが衝突回避の限界に近づきドライバーが自力で衝突を回避できないと判断す
ると緊急ブレーキを作動しはじめ、衝突回避動作を支援する。

【緊急操舵支援システム】
対象物を検知・識別する。
ドライバーに警告を発する。
物理的に回避可能な限界に近づきドライバーの操作は不十分と判断する。
ECUは緊急ブレーキと緊急ステアリングのどちらで対応するかを一瞬で決定する。
ステアリングが最適な措置の場合ハンドルを切ることが可能な方向をドライバーにモニタで知らせる。
その直後に必要な操作（緊急ブレーキの作動か、緊急操舵か、それらの両方）を正確に実行する。

P.32

自動車のアーキテクチャの変化

転載禁止

P.33

独立していた機能が結合していく

衝突リスク分析判定ECUを介して「曲がる」と「止まる」が結合してしまった。
転載禁止

P.34

衝突回避システムの安全対策案
対象物を認識していないときは「曲がる」と「止まる」の関連を絶つ。
対象物がないのにあると判定することを確実に防止する。

「対象物がないのにあると判定する」をトップ事象にしてフォルト
ツリー分析を実施する。

衝突判定に使う要素の故障を検出し、故障がある場合は運転⼿に知らせる。
故障検出センサの故障に注意
故障がある場合は確実に伝える。（ユーザビリティ）

日本では交通事故による死亡者数は減少しており、
2009年からは年間5000
人を切っている。

衝突回避のシナリオテスト

衝突回避のシナリオをどれだけ想定できるかが鍵となる。
ソフトウェアのアーキテクチャを複雑化は絶対に防ぐ。

しかし、世界規模で⾒ると、運転⼿の不注意による⾃動⾞事故の死亡者数は年間150万人もいる。

P.35

ソフトウェアによるリスクコントロールの落とし穴
フィールドで発生した不具合の対策をソフトウェアの追加・変更で実施すると、セーフティアーキテクチャが崩れる危険性があるので注意が必要
ハザード分析によりハザード項目を追加し続けると、何の対策をしているのか開発者⾃身が分からなくなってくる。

リスクコントロール⼿段の要求と検証の実施はトレースを取ることになる（トレーサビリティ・アナリシス）が、複合的な分かりにくい不具合を埋め込んでしまう危険がある。

そういう時は FTA により、危険事象がどのようにブロックされるのかを可視化する。
セーフティ・アーキテクチャが有効であることを確認する。
重要度の高いソフトウェアアイテムを重点的に検証する。

P.36

3-2.

P.37

油圧式ブレーキと電子制御のブレーキシステム

単純な構造の油圧式ブレーキ

電子制御の油圧ブレーキ

P.38

日経ものづくり8月号 『ソフトが揺さぶる製品安全』 図Aより

P.39

日経ものづくり8月号 『ソフトが揺さぶる製品安全』 図Aより

ブレーキシステムの上部

P.40

日経ものづくり8月号 『ソフトが揺さぶる製品安全』 図Aより

P.41

油圧式ブレーキと電子制御のブレーキシステム

単純な構造の油圧式ブレーキ

電子制御の油圧ブレーキ

P.42

数十万行クラスのソフトウェアの例

パッケージ

依存関係

転載禁止

P.43

3-3.
Case Study 2

P.44

日経ものづくり 2006年10月号 [特集] シンドラーの波紋 p67 図2 ⼾開⾛⾏を防止する安全装置の概要 より

エレベータの安全装置の例
トビラが開いていれば、モータは動かないはず！

エレベータのかご及び乗り場側のト
ビラには、閉まっていることを検知するスイッチ（センサ）取り付けてある。
電磁ブレーキの解除や駆動モータを制御するプログラムは、これらのス
イッチがすべて「入」の状態にならな
い限り、エレベータを動かさない。

2019/10/14
P.45

ミスを誘発しやすい安全処理 モータ制御関数
void driveMotor（ 命令 ）{if ( 命令 == STOP) {モータを止める;
電磁ブレーキON︔}

エレベータ制御メイン
void main(){︓︓/* かごを上げる */driveMotor ( UP ):︓︓}else if ( 命令 == UP ) {status = getCageStatus();if ( status != open ) {電磁ブレーキを解除︔
モータを正転させる;}}

ドア開ならモータを動かさない完全処理

else if ( 命令 == DOWN ) {status = getCageStatus();if ( status != open ) {電磁ブレーキを解除︔
モータを逆転させる;}}

安全処理が分散しているため、安全性が網羅されているかどうかわかりにくし、漏れが生じやすい
}

転載禁止

P.46

driveMotor (Check→OK→Drive)
エレベータ制御メイン

モータ制御関数void main(){︓/* かごを上げる */driveMotor ( UP ):︓}

int driveMotor( 命令 ){status = checkCageStatus();if ( status == open ) {モータを止める;
電磁ブレーキON;
return ERROR;}
ドア開ならモータを動かさない安全処理

else {
driveMotorAtferCheck( 命令);}

void checkAbnomalRun(){
⼾開⾛⾏を監視し止める;}

エレベータメイン制御から直接モータを駆動する関数を隠蔽する
チェック後のモータ制御関数
void driveMotorAfterCheck（ 命令 ）{if ( 命令 == STOP) {モータを止める;}
else if ( 命令 == UP ) {モータを正転させる;}}}

else if ( 命令 == DOWN ) {モータを逆転させる;

}
転載禁止

P.47

日経ものづくり 2006年10月号 [特集] シンドラーの波紋 p72 図5 レベル合わせの考え方 より

さらに例外処理がミスを誘発する
ドアゾーン

トビラが開いていても例
外的にモータを動かすこ
とがある！
着床レベル

再床合わせゾーン（リレベルゾーン）
床合わせゾーン（着床ゾーン）

乗り場床

カゴと乗り場側の床に段差が生じた
場合に、その差を自動的に解消する制御を行う場合に限って、トビラが開いたままでもゆっくりとカゴを動かす。ただし、そのような制御が可能
か範囲は再床合わせゾーンに限ら
れる。
P.48

driveMotor (Check→OK→Drive)
エレベータ制御メイン

モータ制御関数void main(){︓/* かごを上げる */driveMotor ( UP ):︓}

int driveMotor( 命令 ){status = checkCageStatus();if ( status == open ) {モータを止める;
電磁ブレーキON;
return ERROR;}
ドア開ならモータを動かさない安全処理

else {
driveMotorAtferCheck( 命令);}

void checkAbnomalRun(){
例外を除き⼾開⾛⾏を監視し止める;}

エレベータメイン制御から直接モータを駆動する関数を隠蔽する
チェック後のモータ制御関数
void driveMotorAfterCheck（ 命令 ）{if ( 命令 == STOP) {モータを止める;}
else if ( 命令 == UP ) {モータを正転させる;}

調整のためのモータ制御関数
再床合わせゾー
ンならゆっくりモー
タを動かす例外
処理

void driveMotorSlowly（ 命令 ）{if ( 命令 == SLOWUP) {モータをゆっくり正転させる;
︓}}

else if ( 命令 == DOWN ) {モータを逆転させる;

}
転載禁止

P.49

責務を明確にしてモデリングする
エレベータシステム<<sensor>>
ドアオープンセンサ

ドア開閉の
状況を直接
getする

+
+

CageDoorStatus :int
FloorDoorStatus :int
getFloorDoorStatus()
getGageDoorStatus()

Fail Safe
安全装置-

elevatorstatus :int+

getElevatorStatus()<<controller>>
かご巻き上げコントローラ<<SafetySystem>>
エレベータ安全システム-

エレベータマネージャ++

notifyAlarm()
stopElevatorImmediately()

downElevatorCage()
upElevatorCage()<<actuator>>
モータドライバ+++

backMotor(speed)forwardMotor(speed)
stopMotor()<<actuator>>
ブレーキアクチュエータ++

applyBreak()releaseBreak()

転載禁止

P.50

追加仕様もすっきり結合できるエレベータシステム

追加仕様<<sensor>>
ドアオープンセンサ

ドア開閉の
状況を直接
getする

-

CageDoorStatus :int
FloorDoorStatus :int++

getFloorDoorStatus()
getGageDoorStatus()

エレベータマネージャ+

再床合わせ処理を追加する<<SafetySystem>>
エレベータ安全システム-<<controller>>
かご巻き上げコントローラ

notifyAlarm()
stopElevatorImmediately()
stopElevatorWithoutLimit()++

downElevatorCage()
upElevatorCage()<<controller>>
フロアレベルアジャスタ+

adjustFloorLevel()<<actuator>>
モータドライバ

独立した安全装置
+
+
+

フロアレ
ベルを直
接getす
る

elevatorstatus :int
getElevatorStatus()

フロアレベルセンサー

backMotor(speed)forwardMotor(speed)
stopMotor()<<actuator>>
ブレーキアクチュエータ++

applyBreak()releaseBreak()<<sensor>>
フロアレベルセンタ+

floorlevel :int
getFloorLevel()

転載禁止

P.51

メカとエレキによるインターロック機構
扉が完全に閉まって通電がないとエレベータが動かないインター
ロック機構
実現の方法
フォールト・アボイダンス

Fault Avoidance 信頼性を高める
フェール・セーフ
Fail Safe 安全側に倒す○

フォールト・トレランス

Fault Tolerance 冗長設計を施す
エラー･プルーフ（フール・プルーフ）

Error Proof / Fool Proof 間違いにく
い操作性
P.52

http://www.toshiba-elevator.co.jp/elv/common/contents/products/new/new_safety.jsp

独立した安全用ブレーキの設置
エレベーター新安全基準とは
平成18年6月に港区で発生した死亡事故
および、平成17年7月の「千葉県北⻄部地震」で、多くの「閉じ込め」が発生した事象を受けて国土交通
省は建築基準法の一部改正を⾏いました。
P.53

ハードとソフトの安全設計の違い
ハードウェアによるリスクコントロール手段（安全装置）
統計確率的な故障のしかたをする。(Random Failure)
変更が容易ではない。
システムにおける安全機能の独⽴性が明⽩。
コストダウンで取り除かれてしまう可能性がある。

ソフトウェアによるリスクコントロール手段

決定論的な問題発生のしかたをする。(Systematic Failure)
変更が容易なため、デグレードの危険がある。
システムにおける安全機能の独⽴性を示すことが難しい。

ハードとソフトのリスクコントロールは相互に補完すべきだが、ハードではブロックできないリスクもある。
P.54

3-4.
Case Study 3

P.55

意外と知らない電気メスの話より http://or-nurse.seesaa.net/article/21976211.html

電気メスはソフトウェアで切開と凝固を切り替える

切開と凝固

切開
(cut)

凝固
(coagulation)

原理

モード

Pure
高周波を連続して発生させる。
高周波エネルギーによって人体組織は数百度に熱せられるため、体内の⽔分が瞬時に気化して蒸発する。
Blend
その蒸発によって組織が一緒に吹き飛び切れたように⾒える。

特⻑出血がある。
高周波を断続的に出しながら凝固させながら組織を切るように調整したモード

やや弱めの高周波を断続的に発生させるモード。
温度が数百度まで上がらないように100℃程度に調整し、組織を凝固（止血）させる。
転載禁止

P.56

ハードウェアの安全装置が使えない
電気メス
高周波
発生回路

電源回路

出力トランス

波形回路

制御回路
波形出力

ステータス表示

切開モード

異常監視

電気メスコントローラ

出力監視

タイマー

切開

凝固

A/Dコンバータ

切開と凝固の制御はソフトで⾏っており、検出が難しいことからハードウェアの安全装置が使えない
転載禁止

P.57

意図しない異常出力

FTAの分析
異常出⼒の監視を異常監視ソフトが担っている。
切開と凝固のモードの不整合はソフトウェアの問題で、ハードウェアでバックアップすることができない。

ハード起因の異常
出力

ソフト起因の意図しない切開出力ソフトウェアの信頼性で安全が担保される。

出力系ハードの故
障

異常監視ソ
フト不良

モードの不
整合（ソフト）

異常検出の失敗

切開と凝固のモードの不整合は致命的なリスクであり、
ソフトウェアの検証と妥当性確認で安全を担保する。
高周波発生
回路の故障

波形回路の
故障

タイマーの
故障

異常監視ソ
フト不良

転載禁止

A/D変換器不良

P.58

FMEAの分析（ハザード分析）
ハザード

潜在的原因

半定量的な確 定性的な重大
率レベル
さレベル

意図しない モード切り替え NA
重⼤な
切開モードの ソフトに誤りがあ (Systematic (Critical)
出⼒る
Failure)

リスクコントロール手段

対策後の残留リ 関連するソフトウェア ソフトウェア安
スク評価
アイテム
全クラス
ハード
ソフトウェアウェア
出⼒波形を a) 出⼒波形の 受容できる
電気メスコントローラ Class C
A/D変換して監視し、異常 (Acceptable) 切開
CPUへフィー
検出時に出凝固Class C
ドバックする
⼒を止める。
切開モード
Class Bb) 関連するソフ
ステータス表示
Class C
トウェアアイテ
出⼒監視Class Bムの独⽴性の
異常管理
Class C検証
波形出⼒Class Cc) アイテムごとのClass C
信頼性検証d) 負荷試験を含むテスト計画の⽴案と実施a) Fail Safeb) Fault Avoidancec) Fault Avoidanced) Fault Avoidance

Fault Avoidance
だけでは安⼼できな
い
転載禁止

P.59

ソフトウェアによるリスクコントロールの落とし穴
フィールドで発生した不具合の対策をソフトウェアの追加・変更で実施すると、セーフティアーキテクチャが崩れる危険性があるので注意が必要
ハザード分析によりハザード項目を追加し続けると、何の対策をしているのか開発者⾃身が分からなくなってくる。

リスクコントロール⼿段の要求と検証の実施はトレースを取ることになる（トレーサビリティ・アナリシス）が、複合的な分かりにくい不具合を埋め込んでしまう危険がある。

そういう時は FTA により、危険事象がどのようにブロックされるのかを可視化する。
セーフティ・アーキテクチャが有効であることを確認する。
重要度の高いソフトウェアアイテムを重点的に検証する。

P.60

4. まとめ（安全を実現するには）
a.
b.
c.
d.
e.
f.
g.

安全の実現に有効なサイクル
注意すべき点
業務ドメイン別 リスクマネジメントの未来
医療機器ドメインの昔と今の違い
ネットワークが絡むリスク
自動運転ソフトウェアの意図しない動きは誰のせい？
まとめ
P.61

安全の実現に有効なサイクル
1. 要求分析(QFD) Intended Use の特定

4. Safetyアーキテクチャ設計
エレベータシステム<<sensor>>
ドアオープンセンサ++

CageDoorStatus :int
FloorDoorStatus :int
getFloorDoorStatus()
getGageDoorStatus()

3. FTAによるリスクコントロールの効果分析

エレベータマネージャ+

elevatorstatus :int
getElevatorStatus()<<controller>>
かご巻き上げ コントローラ<<SafetySystem>>
エレベータ安全システム-

SafetyAnalysis

2. ハザード分析(FMEA)リスクの洗い出し++

notifyAlarm()
stopElevatorImmediately()

downElevatorCage()
upElevatorCage()<<actuator>>
モータドライバ+++

backMotor(speed)forwardMotor(speed)
stopMotor()<<actuator>>
ブレーキアクチュエータ++

applyBreak()releaseBreak()

転載禁止

P.62

注意すべき点システムの複雑化、多様化はセーフティの実現には危険信号
サプライヤ１社で実現できないリスクが伴う機能の安全性の確保
はリスクアセスメントを実施し、分析に基づき⾏動する。
エンドユーザの利益を最優先に考える。（安全にとってセクショナリ
ズムは最⼤の敵）安全は一発で実現しようとはしてはダメ。繰り返しプロセスを回す。
セーフティアーキテクチャを可視化しキープする。
エンドユーザーの安全を常に意識し、安全を実現するアーキテク
チャを保持すること。
（ハード、ソフトの実現方法は問わない）
P.63

業務ドメイン別 リスクマネジメントの未来
自動車

Intended Useが多様化し、アー
キテクチャが複雑化する

医療機器

機器がネットワー
クにつながりこれ
までにはなかった
リスクが増える。

一体一の関係ではなくなる。

ロボット

Intended Use
が定まらず、リスクが特定しにくい。
P.64

医療機器ドメインの昔と今の違い
現在(2010年代)

30年前(1980年代)
ソフトウェアへの過信

ソフトウェアは完全ではないと認識されている

安全性と信頼性の混同

一部の分野で安全性と信頼性が混同されているモジュール分割の技術が進んでいなかった。

リアルタイムOS, オブジェクト指向設計あり。

防御的設計の欠如（アーキテクチャを可視化できない）

リスクアセスメント、リスクコントロール要求あり（アーキテクチャを可視化することが可能）

不具合発生時のトレース機能がない

不具合発生時のトレース機能を用意

非現実的なリスクアセスメント

今でもある

レガシーソフト、OTSの安易な利⽤

レガシーソフト、OTSへの要求がある

ユーザーの事故報告義務がない

ユーザーの事故報告義務がある

ソフトに対する当局の規制と監督がない

ソフトに対する当局に規制と監督がある

ユーザビリティのリスク分析要求なし

ユーザビリティのリスク分析要求あり

開発プロセス要求、V&V要求なし

開発プロセス要求、V&V要求あり

ネットワーク接続なし

ネットワーク接続による不具合が増加
P.65

自動運転ソフトウェアの意図しない動きは誰のせい？
表示灯

警告
ブザー

表示装置
（モニタ）

ステアリング
制御ECU

衝突リスク
分析判定ECU

ブレーキ
制御ECU

シートベルトIntended Use が変わる• 不具合の原因は誰の責
任︖• 不具合を起こしたサプライヤを責めることで問題は解決するのか。
• 事故の再発を防止するという視点と、リスクを低減するアーキエクチャが必要。

カーナビゲーション
システム

低リスクアイテムが高リスクアイテムに変わる責務が不明確な複合システムではリスク分析と対策が不可⽋
P.66

まとめ
国際規格は神の啓示ではありません。各国の国際エキスパート達の議論と投票の共同作業によってできた標準です。規格要求の一つ一つがエンドユーザの安全のためになぜ役に⽴つのかを常に考えながら、規格適合の活動を進めましょう。
ソフトウェア起因の不具合の特徴を理解した上で、プロセスアプローチの必要性を認識しましょう。
⼤規模複雑化したソフトウェアシステムにおいては、安全を実現するためのアーキテ
クチャが重要です。危害を防止するためのソフトウェアアーキテクチャ/ハードウェア
アーキエクチャを認識し、仕様変更等によってアーキテクチャが崩れていないかどうかを確認しましょう。
⾃動運転などがもたらす相互運用性（Interoperability）の要求は基本機能、基本性能の独⽴性を崩し、想定し得なかった事故や原因が分かりにくい不具合を誘発します。そのような場合は、リスクベースアプローチにより、個別最適の発想ではなく、全体最適の発想で問題を解決しましょう。

P.67

参考文献 (1)
国際規格/ガイダンス
ISO/IEC GUIDE 51:1999 Safety aspects — Guidelines for their inclusion in standards (JIS Z 8051:2004 安全
側面-規格への導⼊指針)
IEC 61508︓2000 Functional safety of electrical/electronic/programmable electronic safety － related systems（JIS C 0508－4︓1999 電気・電子・プログラマブル電子安全関連系の機能安全）
ISO 26262:2010 - Road vehicles - Functional safety

P.68

参考文献 (2)
書籍
『安全設計の基本概念』」, 向殿政男 監修, 日本規格協会, 2007年『ソフトウェア品質保証の考え方と実際』, 保田 勝通『セーフウェア 安全・安⼼なシステムとソフトウェアを目指して』, ナンシー・レブソン, 翔泳社『リアルタイムOSから出発して組込みソフトエンジニアを極める』, 酒井由夫, エスアイビーアクセス『リコールを起こさないソフトウェアのつくり方』, 酒井由夫, 技術評論社『FMEA・FTA実践法』, 鈴木 順⼆郎, 日科技連
文献/調査研究資料
医療用ソフトウェアに関する研究会-中間報告書, 平成25年3月28日, 経済産業省, Ⅱ医療用ソフトウェアの関連調査
広島市⽴⼤学 ⼤場充 教授 講演「⺠主主義原理に基づくソフトウェア品質論⼊門」
第15回 品質機能展開シンポジウム 特別講演 GD3 コンサルティング代表/JMAC GD3 センター⻑ 吉村達彦 ⽒発表資料
日経ものづくり 2010年8月号 の特集記事『ソフトが揺さぶる製品安全』
日経ものづくり 2006年10月号 [特集] シンドラーの波紋
SESSAME e-Learning シリーズ D-01 ソフトウェア安全分析・設計, 2013, 酒井由夫, http://www.sessame.jp/elearning/DomainSpecificContents/index.htm

P.69

参考文献 (3)WEBサイト
社会人MBA-技術者編 シックスシグマ(工程FMEA) , http://tech-d.blogspot.jp/2008/01/1fmea.html
話題沸騰ポット GOMA-1015型 要求仕様書, SESSAME WEBサイト , http://www.sessame.jp
新安全基準対応機能, http://www.toshibaelevator.co.jp/elv/common/contents/products/new/new_safety.jsp
意外と知らない電気メスの話, http://or-nurse.seesaa.net/article/21976211.html
日産ニュースリリース,『日産⾃動⾞、「緊急操舵回避支援システム」を開発』, http://www.nissanglobal.com/JP/NEWS/2012/_STORY/121017-01-j.html
Wikipedia
http://ja.wikipedia.org/故障率曲線
http://ja.wikipedia.org/フォルトツリー解析
http://ja.wikipedia.org/FMEA
http://ja.wikipedia.org/HACCP

P.70

SEESAME コンテンツのご利用に際して本著作物の著作権は作成者または作成者の所属する組織が所有し、著作権法によって保護されています
SESSAMEは本著作物に関して著作者から著作物の利用※を許諾されています
本著作物はSESSAMEが利用者個人に対して使用許諾を与え、使用を認めています
SESSAMEから使用許諾を与えられた個人以外の方で本著作物を使用したい場合は query@sessame.jp までお問い合わせください※ SESSAMEが著作者から許諾されている権利
著作物の複製・上演・演奏・公衆送信及び送信可能化・口述・展示・上映及び 頒布・貸与・翻訳・翻案・⼆次的著作物の利用
ドキュメント中には Microsoft社, Adobe社等が著作権を所有しているクリップアートが含まれています

P.71