派生開発のテスト
概要
派生開発の理解
特殊な制御構造；RTOS/周期タスク
プロダクトラインの理解
変化点管理（T社 生産管理）
派生開発テストの要件
ロジックの変更とテスト
回帰テスト
派生手順を変える技術導入は困難
制御基板：RTOSの特殊性
プロダクトラインと変化点管理
派生の要件は何か
ロジック変更とテスト設計
回帰テスト/受け入れテスト
1
ハードリアルタイム制御：RTOS
1.1
歴史的な方式
1980年代，MSDOSと同時代
国内ではTRONの組込み版
ITRON（アイトロン）/μITRON
仕様定義のみ
TOPPERSプロジェクト
μITRON仕様のオープンプロジェクト
1.2
チープなHWで動作
動作環境：製造業のコスト課題対応
最小構成は８ビットECU
数キロバイトRAM
ソフトの実装は特殊構造
周期タスク，イベントタスク
1.3
その後のトレンド
２１世紀初頭
ガラ携帯の複雑化，カーナビ高機能化
RTOS方式の限界
複雑系はソフトリアルタイムへ
Andoroid, Ios, Linux_RT
伝統的な車載製品は今も
RTOS（QNX，BSWなども）
1.4
派生開発として残っている
複雑な新規開発には使われない
３限目のテスト技術へ
派生開発＝RTOS
AUTOSAR（AUTomotive Open System ARchitecture）
Classic Platform はRTOS対応
対象は機構部品のドライバー系製品
2
プロダクトラインと
変化点管理
2.1
ソフトウェアプロダクトライン
Software Product Line Engineering: SPLE
カーネギーメロン大学
Domain Engineering for Software Reuse
1988年 G. Arango が提唱
2.2
プロダクトラインの基本原則
2つのライフサイクル活動を分離
ドメインエンジニアリング：コア資産開発
BSWやモデルベース，開発環境
アプリケーションエンジニアリング：製品開発
製品固有の機能や振舞い
2.3
PL構成：主な活動
コア資産開発
製品群全体で共有するコア資産
派生製品開発
特定の顧客や市場の要求への対応
アプリケーション派生開発
プロダクトライン管理
コア資産の共有、再利用を促進
プロダクトライン全体の経済性を管理
2.4
変化点管理
トヨタ生産方式の一部
部品のコストダウンや改善が原因となる不具合
リコールなど大きな損失
対策として
信頼性や安全性を保つための
一連の管理手法
2.5
過去トラの教訓から
コスト改善，プロセス改善
好ましい成果を求める一方で
部品の信頼性低下や不具合
結果的にコスト爆発的増大
そのため，派生開発の安全管理
非常に保守的だが確実
2.6
変化点管理の目的
派生開発による
製品の信頼性や安全性の変化を分析
変化が想定される場合，詳細な分析
不明点があれば，派生中止の判断
この一連の管理プロセス
信頼性や安全性への変化が無いか？
変更箇所の管理とは異なる
3
派生源と要件定義
3.1
ライフサイクルと派生要件
頭出し開発
ベース版の流用が中心
OEM要件からの派生開発請負
ECUのロット特性変化
仕向対応
リファクタリング
3.2
OEM対応の場合（1，2）
何らかの契約行為
その文書化：要件定義
実体は要件概要と納期や付帯事項
技術面より営業管理面がある
安全性，信頼性の確保と変更特性
3.3
仕様変更の裏付け
要件定義時に，双方の技術間で打ち合わせ
主に外部仕様レベル
内部仕様の詳細化は開始以降
経験者に依存している
3.4
ポストモダン技術
要件定義には，多様な関連情報の網羅が必要
法規制や安全規格（欧州対応）
過去からの引継ぎ
これらの資料リンク整理に活用
RAG（拡張検索）の利用
課題：込み入ったエクセル表
3.5
ECU特性対応(3)
ECUメーカのリリース仕様から
特性の変化（動作の応答時間など）
機能の変化
などかを読み取り，I/O関連処理の変更
専門的な知識が必要
3.6
ポストモダン技術
膨大なECUリリース仕様（PDF）から
HW特性を抽出し要約
例えばジッターの変化判定など
既に使われている
コードの制御用定数の自動設計
研究が進んでいる
例えばジッタ時間の推測
3.7
車種や仕向対応(4)
この種のバリエーションは
実装レベルで条件コンパイル
コンパイラーの機能
ヘッダファイルやライブラリ置換
専用のconfig機能
BSWやモデルベースの定義ファイル
仕向個別にコードを修正しない
何らかの生成機構を使う（複雑）
3.8
モダン技術
xml/yaml/JSON などで記述
相互変換可能
人間でも理解できる
コンパイラ側に対応機能がある
3.9
ポストモダン
「ワンストップ構築」のトレンド
複雑なタスク連携で，多様なツールや設定を個別に行う煩雑さを解消するため，例えば，一つのIDEから，すべてのタスクを実行する． 「cursor」などは，このトレンドで進化している．
派生開発での導入は進んでいない
3.10
リファクタリング(5)
概念はあるが，組込み派生開発での事例はほぼ無い
理由：変化管理＝変えないことが原則
費用を出すスポンサーが無い
費用効果が示せない
4
ロジックの変更と
テスト設計
4.1
演習を使って考える
work12-12/
【Exc04】割引問題ベース版
テストケースは４１
【Exc05】派生版
テストケースは４８
【Exc06】派生２版
テストケースは９９
いずれも処理（機能）は単純化，
ロジックの追加，変更時の演習
4.2
Jupyter Lab にログイン
ログイン後，左側のフォルダ操作
work01/work12-12/Exc04
ファイルwaribiki_mini_spec.Rmd を開く
内容をすべてコピーする
Ctrl + a その後で Ctrl + c
使えるAI（Copilotなど）にテストケース設計を依頼
結果を確認して
4.3
cursorの結果と比較
test_report.md
これは実行結果だが
これと比べて
4.4
プログラム開発も試す
copilot にテスト対象の作成を依頼
多分，Python で回答するので
Cに変更して
waribiki.c と比べる
4.5
この一連の演習をグループで
画面を共有しながら進めて
グループで討論して
どんなことが解ったか
疑問は何か
など共有ノートに書き出して
Breakout Rooms
15分
4.6
Cursor の能力差だけではない
違いが出るのは
Cursor が関連情報を
テスト演習プロジェクトから見つけ
RAG機能で絞り込んでいるから
使うための環境設定，使い方に意味がある
5
回帰テスト/受け入れテスト
5.1
回帰テスト
一般定義では
以前のバグ対処の再発確認
回帰：以前のバグが再発
車載文化では
派生開発の悪影響確認テスト
基本機能や振舞いの確認
製品，職場で多様
5.2
受け入れテスト
請負側が納入前に行う
内容は回帰テスト＋派生要件
テストの範囲や規模は
製品，職場で多様
5.3
ワークフロー
派生開発の最終段階で実行
ここで「NG」＝後戻り
想定外事象で納期に影響
派生要件は事前確認だが
回帰部分の不具合は想定外
デバッグをスケジュール上，想定していない
5.4
対策
NGの原因処置：
事案個別の問題
プロセス改善
派生開発ワークフローの不足不備
チェック項目を追加
5.5
ポストモダン
RAG：検索拡張生成の利用
Retrieval-Augmented Generation
検索範囲を自動的に絞り込んで精度向上
Agent/cursor の場合，自動でRAG
指定したプロジェクトのファイル群
GPTの状態保持モデル（12/5 5限目）
横展開に使える
6
まとめ
安全性/信頼性の確保=変化させない
そのため固いワークフロー遵守
原点はハード向けの対策だった
次は，
次のスライドへ
その前にちょっと休憩
トップページへ
共有ノートへはここから