基調講演】 『車載ソフトウェアの品質を考える

１．車載ソフトウェアに求められる品質とは
車載ソフトウェアの品質を考える
２．開発段階で考えることができる範囲
３．検証技術の可能性
2011年5月20日
平山雅之
４．開発における基本動作と技術の限界
Masayuki HIRAYAMA
1.
Masayuki HIRAYAMA
車載ソフトウェアに求められる品質とは
走行コンテキスト vs. 自動車
走行コンテキスト
ドライバー
走行状況
基本機能
走る ＋
止まる
＋
曲がる
＋ ？
--- 速度
車間距離
制御可能な要素
エンジントルク
エンジン回転数
走行経路 --- 直線/カーブ
登り勾配/下り勾配
ブレーキ制動力
路面状況 --- ドライ / ウェット
ステアリング回転角
ステアリングアシスト力
ドライバー
操作
自動車
エンジン
制御
ブレーキ
制御
ステアリング
制御
無数の組み合わせ
走行コンテキスト
Masayuki HIRAYAMA
自動車の挙動
走行コンテキストに自動車の挙動が
合致しているか
Masayuki HIRAYAMA
ドライバーの意図/感覚に
自動車の挙動が
合致しているか
ソフトウェア・システムの品質視点
ISO/IEC9126
Software Engineering
- Product Quality
直接的なソフトウェア品質
作る側の視点
・機能性 ・信頼性
・効率性 ・機能性
・保守性 ・移植性
全ての品質視点をカバーする
⇒ どのよう
どのような方法を用いるか？
ような方法を用いるか？
品質を確認する
前提：彼（彼女）との距離・間柄----
ISO/IEC9241
Guidance on Uasbility
“愛情”
利用者視点の品質
・ユーザビリティ
ISO/IEC15504
Information technology
-- Process assessment
開発作業の品質
定式化が難しい -- 定式化できないものの「質」
を論じるのも難しい
前提：システムの置かれた（利用される）状況
どうやって“表わす” ？
どうやって“計る”
？
そもそもどの程度だったら ？
そもそも不具合があったら？
IEC61508
Functional safety of electrical/electronic/programmable
electronic safety-related systems
システムの安全性に関する視点
・機能安全
Masayuki HIRAYAMA
どうやって“表わす” ？
どうやって“計る”
？
そもそもどれくらいだったら ？
そもそも偽りだったら？
Masayuki HIRAYAMA
ソフトウェアを定式化（=表現）するということ
前提
システムの置かれた状況
利用される状況
１．車載ソフトウェアに求められる品質とは
機能的側面
⇒機能実現のからくり
⇒処理のアルゴリズム
２．開発段階で考えることができる範囲
非機能的側面
⇒ 性能
⇒ ユーザビリティ
３．検証技術の可能性
４．開発における基本動作と技術の限界
開発プロセス側面
⇒ 直接作業（要求分析～実装）
V&V作業(検証、テスト)
間接作業(管理）
Masayuki HIRAYAMA
Masayuki HIRAYAMA
全てを予め
考えることができるか
決めることができるか
表現することができるか
ソフトウェアの定式化 -- 全てを予め考え表現する
飛行船を所定の位置で
ホバリングさせる
周囲の気流
-水平方向/垂直方向
⇒ 飛行船形状の影響
飛行船の空間位置の影響
想定外を想定する？
豪雨・豪雪
花粉・黄砂
放射能
単純事象の想定
乗員の重量バランス
強風-向かい風・横風
ダウンバースト
飛行船自身がもつ慣性力
飛行船の浮力
⇒ 周囲の気温
事象複合の想定
路面
物理法則 / 流体力学
などの支配法則
-制御条件、パラメータとして
モデルに表現することは可能
-情報処理分野の知識だけでは
考えられない/決められない世界
穴があいている
鋲・釘が散乱している
部分凍結している
粘着性液体が覆っている
枝や葉が散っている
カエルが群がっている
より深刻な結果へ
４輪パンク
ブレーキ系統故障
エンジンストール
Masayuki HIRAYAMA
Masayuki HIRAYAMA
ソフトウェアの定式化 – 全体と部分
システム内動作の競合
※ 様々な指令を用いて特殊な機能を実現
システムとしての自動車
個々のＥＣＵ
それぞれの挙動/サービス
それぞれの構造・構成
ＶＩＣＳ
（例）地震管制、火災管制…
※ 指令間
指令間には優先度
には優先度があり、それによって
優先度があり、それによって機能の優先関係表現
があり、それによって機能の優先関係表現
vs.
ＥＴＣ
ＥＣＵ
ブレーキ制御
エンジン制御
系としての
システム全体の挙動/
サービス
システム全体の構造・構成
ステアリング制御
エアコン制御
システム全体を
どのようにして定式化するか
どのようにして見通すか
パーキング運転
乗りかごを駐留させる
・駐留させる階
＝パーキング階
火災発生時、乗りかごを
避難階へ動かす
【主動作対象指令】
《優先度》
優先度》
【競合対象指令】
スタート禁止指令
＞
避難階移動指令
駐留中に出される指令
Masayuki HIRAYAMA
火災管制運転
Masayuki HIRAYAMA
避難階移動中に出される指令
動作タイミング競合の特定
システム全体像の把握とエラー処理
※ 対象とする指令が同時に出される状態を特定
パーキング
スイッチONかつ
パーキング階以外
または移動中／
携帯電話: 大規模化（約700万LOC程度）
火災管制
スイッチONかつ
スイッチ かつ
避難階以外
または移動中／
パーキング階
移動運転中
set
スイッチONかつ
パーキング階
かつ停止中／
パーキング階
停止中
パーキング階
移動指令
パーキング階
かつ停止中／
一旦戸開完了／
スイッチONかつ
避難階
かつ停止中／ 避難階
かつ停止中／
パーキング階
駐留中
set
set
一旦戸開指令
スタート禁止
指令
避難階
停止中
Sub1:
音声通話
避難階
移動運転中
set
避難階
移動指令
避難階
待機中
一旦戸開完了／
set
set
一旦戸開指令
スタート禁止
指令
スイッチＯＦＦ／
Sub4:
カメラ
Sub2:
メール
Sub3:
ブラウザ
システム全体像の整理
システム全体像の整理
機能ユニットの整理と優先順位付け
機能ユニットの整理と優先順位付け
Sub5:
ユーティリティ
サブシステム分割図
カメラ
Air
2つのCPU
HMI
にどのように機能を
振り分けるか
モータ
Sub1:
音声通話
Sub2:
メール
Sub3:
ブラウザ
Sub4:
カメラ
Sub5:
ユーティリティ
システム機能による
スイッチＯＦＦ／
メモリ
Masayuki HIRAYAMA
Masayuki HIRAYAMA
周辺デバイスなどとのIF
並行動作整理＆エラーハンドリング
各機能サービス間の
並行動作や割り込み関係な
どをマトリクス状に整理
１．車載ソフトウェアに求められる品質とは
２．開発段階で考えることができる範囲
機能サービスごとに
異常動作時のエラー
ハンドリングのレベルを
検討する
３．検証技術の可能性
４．開発における基本動作と技術の限界
Masayuki HIRAYAMA
Masayuki HIRAYAMA
リソース競合
検証の網羅性
検証技術とは
設計や実装の「正しさ」を確認する
⇒「正しさ」の判断基準はどこにある？
設計者の意図通りの
設計内容になっているか
システム
設計内容
設計通りの挙動を
実現しているか
ドライバーの意図通りの
挙動をするか
設計者
設計者の意図通りの
挙動をするか
システム
挙動
ドライバー
搭乗者
目視によるトレース（レビュー）
特定条件を設定して動作確認（テスト）
論理パスを網羅的に
トレース（モデル検査）
Masayuki HIRAYAMA
Masayuki HIRAYAMA
適用結果
モデル検査は万能か
システム動作記述
対象：ＣＤプレーヤ
（トレーユニット）
/*mtype =
{TEJECTED, NTEJECTED, ON, OFF, PLAY, PAUSE, FORWARD, REWIND,
STOP}*/
#define p (count == 0);
byte count = 0;
mtype = {eject, power, play, pause, forward, rewind, stop};
chan c = [0] of {mtype};
active proctype switch(){
/*電源オフ状態*/
S_OFF:
if
:: c?power -> /*パワーボタンが押されたら：電源オン状態でかつストップ状態*/
printf("電源オン¥n");
goto S_ON
/*それ以外は、自己遷移*/
:: c?eject -> goto S_OFF
:: c?play -> goto S_OFF
:: c?pause -> goto S_OFF
:: c?forward -> goto S_OFF
:: c?rewind -> goto S_OFF
:: c?stop -> goto S_OFF
Ｐｒｏｍｅｌａ記述
Promeｌｌa記述：約
記述：約300行
行
記述：約
検証システム
(SPIN)
により動作検証
•
fi;
/*電源オン状態*/
S_ON:
if
:: c?power -> /*パワーボタンが押されたら：電源オフ状態*/
count ++;
printf("電源オフ¥n");
count --;
goto S_OFF
Masayuki HIRAYAMA
•
Masayuki HIRAYAMA
どのような状況でも特定の状態に到達するか？
– S_ONへ行かない場合がある。
– S_OFF状態で電源ボタン以外のボタンが
押され続ける。
特定のボタンが押されると期待する状態に到達するか？
– 「電源ＯＮ・停止・トレー排出状態で再生ボタンが
押されると、いつかは再生状態に行く」が成立しない。
モデリングとは
モデル検査の作業の流れと問題点
ソフトウェア仕様
モデル
システムなどを特定の視点から
象的に整理した像
問題点3
問題点0
状態モデル(仕様)
モデル
/ プログラム実装
検査モデル
検査モデル
検査モデル
作成
影し、
制御のビュー
状態遷移のビュー
ユーザビリティのビュー etc.
モデル検査
ツール
仕様修 正
特定のビューについての検証
だけでは不 分
問題点2
検査条件
反例
<>(p && q)
#define p p_state == RUN
#define q s_state == WAIT
システムを 象的に整理する
⇒結構難しい
システムの
不具合解析
りうる“状態”とは ？
問題点1
状態モデルに問題あり
⇒“反例” として検査条件を たさないシ
ステムの動作シークンスの一例を出力
Masayuki HIRAYAMA
仕様・設計の
性排
SoC技術
技術
との 合
SystemC
SpecC
UMLによるモデリング
UML profile for Real Time Systems
組込みソフトウェア
LSI,マイコン etc
SECでのトライアルの場合
でのトライアルの場合
者：3
（開発経
フェーズ
アプリクーシュン, OS
ハードウェア
Masayuki HIRAYAMA
モデル検査適用に関する考 点
組込みシステムのモデリング
組込みシステム
モデルを考えながら整理するだけでも
仕様の
性検討としては 効
は5年前 ）
ＩＳＴ
(3日間）
•プログラミング経
プログラミング経
•状態遷移の考え方を理解
状態遷移の考え方を理解
していることが
外部
センサ
アクチュエータ
UMLのハードspecへの利用
この部分のモデリング
が 題
Point-1: ソフトウェアのモデリング
Point-2: ハード＆ソフト＆外部
の接点を 確化
Point-3: 信頼性/安全性を実現する信頼性保証
信頼性 安全性を実現する信頼性保証 法の
Masayuki HIRAYAMA
トライアル
フェーズ
対象システムの状態図整
Ｐｒｏｍｅｌａ記述作成
SPINによる検証
Promelaは対象システムの設計モデルのすべてを記述するには
は対象システムの設計モデルのすべてを記述するには
記述能力が い。
⇒ モデル検査で える部分は、設計の一部。
ハードウェアとのインタラクシュンの部分などは い
検証のためのモデル（検証モデル）を作成しなければならない
⇒検証したい部分の特定。
検証可能なように
化。
検証したい性質が り えるよう 形や め込み。
Masayuki HIRAYAMA
ソフトウェア・テストの 題と 用法
ソフトウェア・テスト
ソフトウェア・テスト
様々な動作コンテキストの中で
特定の状況における特定のデータに
動作のストップシュット確認
した
非正常動作
想定外状況下での挙動
テスト
の構
⇒ シミュレータ利用
テストのみを 重するのは
Masayuki HIRAYAMA
仕様 /安全 の重要な個所・機能を
重点的にテスト
テストクースの設計
テスト再現確認
テスト＝動作ストップシュット
↓
テストログの記 と再現
Masayuki HIRAYAMA
Fault Tree Analysis
異常動作パターンの 出方法
システムにとって ましくない事象の
論理ツリーによって
開
を
Fatal Trouble
車が停止できない
＋
適 な制動力が
られない
＋
ブレーキ中にタイヤロック
デビエーシュン
分析
＋
できない
一 に正常系動作
設計情報
対象システムの動作仕様 中
UML, 状態遷移図 など
準 Ⅱ）
マスタシリンダが動作しない
力が
されない
力を
大規模ソフトウェア
⇒ 全ての論理パスをテストするのは不可能
全ての時間をテストするのは不可能
設計
実装
テストでは
りのあることは確認できても
システムが正しいことは証 できない
(準 Ⅰ）
テスト
仕様
力が られない
FunctionFailure
＋
各動作の 目での
正常系動作からの逳
正常系動作からの逳 クースを検討
クースを検討
遃 の
の不具合事例に
不具合事例に
する状況を
する状況を い出し
異常動作の い出し ミスユースクース分析
ブレーキヘダルが
っ かり動かない
かり動かない
ヘダル 力を検知できない
力を検知できない
み込み速度が検知できない
み込み角度が検知できない
Masayuki HIRAYAMA
設計レビュー
設計レビュー / テストなどで
重点的に確認
重点的に確認
Software
Errors
Masayuki HIRAYAMA
ｏ
の限界
情報の
象度
モデル(仕様)
テスト仕様
High
１．車載ソフトウェアに求められる品質とは
２．開発段階で考えることができる範囲
Generate
設計
３．検証技術の可能性
Create
４．開発における基本動作と技術の限界
ソフトウェア
設計
Low
実装
Masayuki HIRAYAMA
Masayuki HIRAYAMA
モデルを 用した品質向
程の内容
検証の特
要求分析
アーキテクチメ設計 実装(設計)
整理
仕様定
方式検討
基本構造定
品フゟミリー定
ユースクースの
検証技術
安全性 信頼性向 のための 法
用 シトリオベース
実装技術（プラットフェー
ムや
）
の
な設計
正確性
性
網羅性
レビュー
プロトタイヒング
レビュー
シミュレーシュン
スコアリング
レビュー
シミュレーシュン
形式仕様
モデル検査
モデル検査
検証の正確さ
再利用
ツール化
レビュー
テスト
モデル検査
定理証
検証目的の さ
自動化
コスト
レビュー
適用コスト
検証の正確さ
効な形式
法
検証目的の
コスト
形式化の目的
理解の基
くり
仕様の 確化
との 通理解
シトリオでの確認
再利用の意識
実装技術を意識した確
認（タスク設計の
性 ）
適用コスト
ツール化
自動化
再利用
Masayuki HIRAYAMA
Masayuki HIRAYAMA
２
さ
テスト
モデル検査
定理証
品質の作りこみ
レビュー
品質管理/向 の基本
テスト
テスト
要求分析
モデリング
＆
モデル検査
Plan
Do
どの程度の品質
-不具合の検出目
-信頼性の度合い
どのような方法で実現するか
どのような指 で
するか
アーキテクチメ設計
どのドキュメントのどの部分をどのような
視点から重点的にレビューするか
どの部分をどのようにテストするか
どのような
で動作させる
どのようなテスト ースを確認する
モデル検査でどのような性質をチェック
するか
設計
ｏ
確認した品質
正
実装
コード解析
コードレビュー
Masayuki HIRAYAMA
Masayuki HIRAYAMA
Check
の問題点を
設定した目
を達成しているか
どこに問題があるか