モデルベース開発導入へのチャレンジ AP 2 AP 3 AP 4 RTE COM IOHW MCU モデルベース開発で実装可能（基本的に）従来手法にて実装するモデルベース開発（自動コード生成）

9th WOCS2

Copyright © 2011 TOKAI RIKA Co.,Ltd. All rights reserved.

モデルベース開発導入へのチャレンジ

～単体コード検証への適用による導入の加速～

(株)東海理化　エレクトロニクス技術部

山口晶広　　足立秀和

Copyright © 2011 TOKAI RIKA Co.,Ltd. All rights reserved. 2/27

目次

１．会社紹介

２．モデルベース開発導入への取組みと課題

３．機能安全対応による再始動

４．現場に即した活用の模索（単体コード検証への適用）

５．まとめ

本資料に記載されている会社名、システム名、製品名は一般に各社の登録商標または商標です。なお、本文および図表中では、TM 、® は明記しておりません。


１．会社紹介




５．まとめ


当社のご紹介

《国内主要拠点》《海外拠点》

会社名：株式会社東海理化　　　　　　　(商号株式会社東海理化電機製作所)

所在地：愛知県丹羽郡大口町 (本社)

設立： 1948年8月30日

資本金： 228億円 (2011年3月末現在)

売上高 (連結) ： 3,276億円 (2010年4月1日～2011年3月31日)

社員数 (連結) ： 15,110名 (2011年3月末現在)

主要製品：自動車用各種スイッチ，電装部品

１．会社紹介


１．会社紹介




５．まとめ


当社におけるモデルベース開発への取組み

・先行開発部門においてシミュレーションを用いた計算アルゴリズムの開発。

・制御系システムにおけるラピッドプロトタイピングを用いた開発。

当時のモデルベース開発の利用状況

モデルベース開発では、ソフトウェア開発効率化に有用な多くの技術が実用化。

自動コード生成 SILS HILS ・・・PILS

ソフトウェア開発分野においてモデルベース開発の適用検討を開始！

複雑化、大規模化するソフトウェアの新たな開発手法として期待

２．モデルベース開発　　導入への取組みと課題

量産ソフトウェア開発への適用事例は無い・・・


適用範囲設定と想定する導入メリット

導入推進アプローチ

システム設計

要件定義

構造設計

詳細設計

コーディング（自動コーディング）

単体テスト

結合テスト

総合テスト

システム結合テスト

モデル流用を前提とした開発プロセスの構築を目指す。

プラントモデル

コントローラモデル＆


テストシナリオ




・上流から下流まで、全工程に渡ってモデルを中心とした一貫性ある開発が可能！・プラントモデルをテストへ流用でき、作成したモデルに無駄が無い！

【得られるメリット】

体系的にも完成された手法であり、開発の効率化を期待！



当社における適用可能な対象の実際

AP1

AP2

AP3

AP4

RTE

IOHWCOM

MCU

モデルベース開発で実装可能

（基本的に）従来手法にて

実装する

モデルベース開発（自動コード生成）

既存のソフトウェア資産

他手法（ハンドコード）

ACG

MCAL

MEMSYS

【ソフトウェア開発者から見た懸念点】

　モデルベース開発は主としてアプリケーションが対象であるが、当社製品は、比較的ソフトＰＦの比率が大きいため、依然、従来手法に依存する。

ＰＦ


AP

中小規模ソフトでは約４～７割がソフトPF。（ただし、製品による）

・自動コード生成に対するコード品質上の懸念。・モデルベース開発による現行プロセスへの影響。・モデリング技術者の育成コスト。　　

更に、

などなど・・・


量産適用への問題点

約１年の活動の結果、

－アプリケーション開発の置換えだけでは効果が出ない。（という印象）－従来手法に頼る部分が依然として多い。

－導入コスト（ツールコスト、技術者育成）。

－プロセスへの影響、品質への懸念。

一時休止

・ソフトウェアの大規模化への対応として有効であることは理解　できるが、「今この時点で必要か」というと・・・。

・リスクを負ってまで対応するメリットが感じられない。　（現状、従来手法でも業務をこなせている）

・道のりが長くメンバのモチベーションが維持できない。

実務者の本音

懸念点を全て払拭するだけの導入メリットを提示できなかった

ソフトウェア開発への適用範囲が限定的である



１．会社紹介




５．まとめ


ISO26262機能安全規格への取組み

現在、自動車業界では機能安全規格に関する活動が活発化

当社においても機能安全規格の対応に向けた活動を鋭意実施中

ISO26262ISO26262

当社には馴染みの無い、「新しい技術」への対応が求められている

「形式検証」、「準形式検証（シミュレーション）」、「Back to Backテスト」、「MC/DC」　・・・

ASIL

MC/DC

安全機構

従属故障分析

トレーサビリティ

形式手法

安全要求

Back to Backテスト

インスペクション

安全計画

準形式手法

デコンポジション

３．機能安全対応　　による再始動


新しい技術への対応①　【モデル検査（形式検証）】

２次状態

３次状態

４次状態

初期状態

N次状態

いかなる条件・状態においても「仕様違反が無いこと」を証明する。

全状態の網羅が求められ、階層が深くなると人手で検証するのは困難。モデル検査ツールを用いた自動検証が望ましい。


仕様違反


新しい技術への対応②　【Back to Backテスト】

モデル（仕様）と実装されたコードの振舞いが同一であることを検証する。（ただし、何を以って「一致」とみなすかは難しい・・・）

テストベクタ

モデル（仕様）

検証対象コード（モデルから作成したコード）

==

モデル出力とコード出力が同一であることを検証する

人手での一致確認作業には相当な工数を要する。特にサンプル数の多い検証にはツールの利用が望ましい。

同一の入力信号を、モデルとコードに同時に入力し、両者の出力が同一である、ことを以って「一致」とみなす。

と規定



機能安全対応のための開発技術の選定

・自動車業界にてデファクトのツール。・機能安全対応に関するツールが多く、技術会社も多数。・過去の取組みによる知見が活かせる。

主な選定理由

UML （MDD）フローチャート/DFD

MATLAB/Simulink （MBD） VDM/SPIN （FM）proctype P(){do :: func1 ! Get; func2 ! Get ->

skip; func1 ! Put; func2 ! Putod

}

※一部のダイアグラムに限る

記述： ○（準形式）

検証： ○（準形式※）

BtoB： ×


検証： ○（準形式）

BtoB： ×


検証： ◎（準形式／形式）

BtoB： ○

記述： ◎（形式）

検証： ○（形式）

BtoB： ×

SCADE （MBD/FM）

記述： ◎（形式）

検証： ◎（準形式／形式）

BtoB：－（不要）



・実運用上の課題抽出と対応。

・実務者へのトレーニング。

これまでの活動内容

量産ソフトウェア開発分野でのモデルベース開発技術適用事例として、実績を作ることができた。

機能安全対応のためのモデルベース開発技術の導入を実施。

今後実施すべきこと

実施したこと

・モデル検査のための機能モデリング。

・モデル検査ツール使用方法の習得。

・ Back to Backテスト実施環境の構築。



１．会社紹介




５．まとめ


モデルベース開発への期待再び

機能安全規格への対応を通じて、

・モデル検査などの新たな技術の知見を得た。

・モデルベース開発の導入に強力な後ろ盾を得た。

以前の導入検討時

現在

従来型開発の「代替となる技術」

機能安全対応に「必要な技術」

当社におけるモデルベース開発の位置づけの変化

４．現場に即した　　活用の模索

モデルベース開発導入を再チャレンジできる状況に。

機能安全対応に留めず、ソフトウェア開発力向上に向けた活動へ。


導入手順の検討

projectA

全適用後の段階的横展開

方法２

部分適用の段階的横展開

全適用後の一斉横展開

方法１

横展

期間：中工数：短期＆分散リスク：小～中

期間：長工数：分散リスク：小

期間：短工数：短期集中リスク：中～大

横展横展

projectB

projectC

projectA

projectB

projectC

projectA

projectB

projectC

開始時点途中経過終目標

方法３

類似タイプのプロジェクトへの展開に適する。

比較的類似タイプのプロジェクトへの展開に適する。

比較的異なるタイプのプロジェクトへの展開に適する。

過去の取組み

横展横展

横展

横展


従来手法モデルベース適用


適用工程の検討

ソフトウェア開発工程と利用ツール等の関係

固定小数ツール

HILS自動コード

ラピッドプロト

モデリングツール

○

○

○

○

○

○

△（選択）

○

○

○

○

○

○

○

○（機能レベル） ○機能設計

○（実装レベル） ○詳細設計

○（実装レベル）コーディング

○（単体）単体テスト

○（機能）結合テスト

○総合テスト


コントローラモデル

形式検証

BtoBテスト

検証手法必要となるモデル利用ツールソフトウェア開発工程

「単体テスト（ソフトウェア単体コード検証）」への応用が効果的と判断

・ Back to Backテストの知見を活かすことができる。

・コントローラモデルが不要。

・基本ツールを使用した比較的限定的なモデリングのみでテストが可能。



単体コード検証への適用方法（従来手法との比較）

ハンドコーディング

単体テスト

V字工程

ドライバテスト対象スタブ

ドライバ関数スタブ関数テスト対象関数

①スタブドライバ作成（テストシナリオ含む）

③ビルド ④実行＆ファイル出力

01010110101

010101

⑤処理結果の検証・解析

従来手法

②プロジェクト　作成

01

10

2 03 14 15 1

999897908887

unsigned char func01(signed short *pin_data){

signed char work;signed char loop_c;unsigned char result = 0;

for(loop_c = 0 ; loop_c<LOOP ; loop_c++) {work = calc(pin_data + loop_c);if( work > 0 ) {

result = work;break;

}}return result;

}

> break

run stop step exitmemory break watch

func.cmain.cfunc.hmain.h

テスト対象関数

テスト対象②ビルド

③検証用モデル作成＆ ④シミュレーション実行

Stub

ドライバ

スタブ

計測>mean(output)ans =

0.012

⑤処理結果の検証・解析

数値解析ツール

XX_sf.c

＋

ラッパー関数

①ラッパー関数作成

モデリングツール利用

1

0



単体コード検証への適用メリット

入力条件などを限定し易くモデルが簡素

・１つ（あるいは数個）のオブジェクトのみを対象とするため、入力条件が簡素。

・実行条件（動作周期など）を柔軟に変更することができる。

メリット１

基本的なモデリング知識で記述が可能

・「信号生成、コードブロック化、結果表示」を用いてモデリングが可能。

・多少複雑な信号も、基本ブロックの組合せで生成できる。

メリット２

テストシナリオの抽象化とレビューの効率化

・テストシナリオの記述が抽象化できるため、テストコードを書くより容易。

・また、テスト結果をグラフなどの形式に容易に可視化でき、テスト結果の

検証やレビューが効率よくできる。

メリット３


Simple！

S-Function


処理結果

検証用モデル

テストシナリオ２テストシナリオ１テストシナリオ１テストシナリオ２

シミュレーション結果

シグナルビルダー

計測ブロック

【事例】単体コード検証への適用～実施例～

R R R R L L L L －

Ａ相

Ｂ相

回転方向

<<対象>>　ロータリーエンコーダの回転方向検出関数

・信号変化の位相差で回転方向を検出・フィルタによるチャタリング除去

①二重カウントしないこと　（内部状態を保持し変化を正しく捉えること）② 初回の判定が正しく行なえること③ チャタリングにより複数カウントしないこと

Ａ／Ｂ相入力、回転量出力、フィルタ定数

関数の動作評価ポイント（一例）

入出力値およびパラメータ

③②②

①



【事例】単体コード検証への適用～ツール比較～

モデリングツール

機能検証テスト環境（従来手法）

単体検証ツール（専用）

カバレッジ計測 × × ◎

連続的な入力信号 ◎ △ ○

離散的な入力信号 ○ ○ ○

機能

期待値テスト

期待値がポインタ △ ○ ○

MCUシミュレータ上でテスト △ （PILSで実施） ◎ ◎性能

アセンブラコード検証 △ （PILSで実施） ○ ○

期待値テスト結果のグラフ化 ◎ △ ◎結果解析

処理結果の数値解析 ◎ △ （別ツール） △ （別ツール）

テストシナリオ作成容易性 ◎ △ △ （支援あり）

自動テスト（期待値との自動照合） ○ ○ ◎

使い勝手

自動レポート ◎ △ ○

◎ 適　○適する　△使用可　×適さない

◎ 関数の動的な振舞い検証モデリングツール

機能検証テスト環境

単体検証ツール

× 実施できないテスト項目がある

◎ MCUシミュレータ上でテスト可能 × 実施できないテスト項目がある

◎ 単体コード検証のほぼ全域をカバー △ 処理結果の解析を得意としない

結果解析や使い勝手の面で優位性あるが、総合的には専用ツールに劣る。



【事例】単体コード検証への適用　～副次効果～

本事例を実務者へ展開。本手法の実施経験から抽出された副次結果を以下に示す。

モデリングに対するハードルが下がった

・比較的簡単なブロックのみを使ってモデリング。

　⇒ 「モデリング＝難しい」というイメージを改善できたことに意義がある。

機能の構造化をより意識するようになった

・ブロック線図では結線の増加がモデルの見づらさに直結。

・テストシナリオのモデリングを通じ、仕様の抽象化を意識。

コード変更による振舞いの比較が容易になった

・変更前後のS-FunctionブロックをBack to Backテストと同様に接続し、

　振舞いの違いを容易に確認できる。

・「動的振舞いのDIFFツール」として、モデリングツールの適用が有効。

効果１

効果２

効果３

・単体コード検証への適用効果そのものではないが、モデルベース開発の適用に　前向きな意見が挙げられた。・実務者の意識付けという意味で、意義のある結果を得た。



１．会社紹介




５．まとめ


まとめ

導入推進上の問題点とその反省

・ソフトウェアの複雑化、大規模化に対応すべくモデルベース開発の導入推進に着手。

・しかし、現場ニーズとのアンマッチもあり推進活動は一時休止に。

・手法の良し悪しだけでなく、実務のニーズとの融和をきちんと考慮する必要がある。

モデルベース開発導入への第一歩

機能安全規格対応のための新技術導入

・取組み易く、かつ、実務のニーズに程近い対象への適用を実施。

・単体コード検証への適用に有益な結果を得た。（ただし、実際の適用には工夫が必要）

・それ以上に、モデルベース開発の適用に前向きな意見を得られたのは大きな成果。

・規格対応のための新技術を調査し、「モデルベース開発」の優位性を示した。

・専任体制のほかモデルベース開発環境も整備され、導入推進に強力な後ろ盾を得た。

新技術の導入は、その技術の優位性のみを以って適用することは難しい。

「現場を見て」、「実際を知り」、かつ「信念を持って」取り組むことが大切である。

５．まとめ

【第２章】

【第３章】

【第４章】


今後取り組むべき課題

・ツール別評価基準の策定。・自社コード品質基準への適合可否の検証。（自動コード生成）・運用によるツール品質の補完方法の検討。

（１）量産ソフトウェア開発の現場に即した有用性検証

（３）モデリング技術者の育成

（２）ツール信頼性の検証

・モデルベース開発技術者に求められるスキルの定義。・目的別育成計画の策定、および、自主改善活動への展開。

・モデルベース開発技術の適用基準の検討と導入の実践。・自動コード生成、ＨＩＬＳ、などの適用有効性検討。・現行プロセスへの取り込みによる影響の検討。

（４）導入推進者のモチベーション維持・向上

・目標の見える化と適正なマイルストンの設定。・組織への貢献度を評価するための仕組み作り。

品質

育成

推進

適用

適用

品質

育成

推進

５．まとめ

Copyright © 2011 TOKAI RIKA Co.,Ltd. All rights reserved.

ご清聴ありがとうございました

Documents

モデルベース開発導入へのチャレンジ AP 2 AP 3 AP 4 RTE COM IOHW MCU モデルベース開発で 実装可能 （基本的に） 従来手法にて 実装する モデルベース開発（自動コード生成）

モデルベース開発導入へのチャレンジ AP 2 AP 3 AP 4 RTE COM IOHW MCU モデルベース開発で実装可能（基本的に）従来手法にて実装するモデルベース開発（自動コード生成）