車載ソフトウェアにおけるソフトウェア仕様書の改善

車載ソフトウェアにおけるソフトウェア仕様書の改善
２．ソフトウェア開発プロセスと課題
2.1　ソフトウェア開発プロセスEPS制御用ソフトウェアの開発プロセスをV字プロセスで表すと図1となる。（1）当所が対応するプロセス当所は、V字プロセスの左側では顧客からの要求仕様に基づき要求分析を実施し、分析結果を踏まえてソフトウェア仕様書とソフトウェアテスト仕様書を作成し、作成したソフトウェア仕様書を委託先へ提示する。V字プロセスの右側では委託先から納入されたソースコードに対して、ソフトウェアテスト仕様書に基づくソフトウェアテストを実施する。（2）委託先が対応するプロセス委託先は、提示されたソフトウェア仕様書を確認し、不明点がある場合は、Q&Aを繰り返し、仕様を明確にした後に、詳細設計書とソフトウェア統合テスト仕様書を作成する。次に、詳細設計書に基づきコーディングと単体テストを実施し、ソフトウェア統合テスト仕様書に基づきソフトウェア統合テストを実施する。委託先は詳細設計書、ソースコード及びソフトウェア統合テスト仕様書・成績書を当所へ納入する。
１．まえがき
当所は電動パワーステアリング（EPS）制御用ソフトウェアの開発を担当している。従来のEPSのソフトウェア開発は小規模開発であった。しかし、近年は機能安全規格（注1）として制定されたISO26262（注2）への対応や自動運転などの付加価値機能の導入により、ソフトウェア規模が年々増加している。当所はソフトウェア規模の増加に対応するため、ソフトウェア製作を協力会社に委託している。委託先へはソフトウェア仕様書を提示し、Q&Aにより内容を合意している。しかし、近年に変更したソフトウェア構造に関わる部分は、内容の合意までに時間を要した。その結果、開発計画に遅れが生じ、対策が必要となった。本稿では、ソフトウェア構造の明確化を目的として実施したソフトウェア仕様書の改善を紹介する。車載ソフトウェアにおけるソフトウェア仕様書の改善姫路事業所　技術第1部　技術第1課岩元 慶介改善活動（注１）システムの機能不全により引き起こされるリスクを、許容できる状態に移行するための手法や管理方法を定めたもの（注２）自動車分野における機能安全の国際規格として、2011年11月に発行。システムアーキテクチャ設計ソフトウェア要求分析ソフトウェア設計コーディング単体テストソフトウェア統合テストソフトウェアテストシステム統合テストソフトウェア仕様書詳細設計書ソースコードソフトウェアテスト仕様書/成績書当所担当範囲委託先担当範囲Q&Aリスト要求仕様書ソフトウェア統合テスト仕様書/成績書単体テスト仕様書/成績書図１．EPS制御用ソフトウェアの開発プロセス68車載ソフトウェアにおけるソフトウェア仕様書の改善状態"に移行することを求めている。リスクの決定は、表1に示すとおり危害度S、発生頻度E、制御難易度Cの3つの指標がある。危害度Sは低い方からS1・S2・S3の3段階で表し、同様に発生頻度Eは4段階、制御難易度Cは3段階で表す。危害度S、発生頻度E、制御難易度Cの組み合わせからQM（Quality Management）とASILに大別され、ASILは低レベルからASIL-A・ASIL-B・ASIL-C・ASIL-Dの4段階に分類される。EPSは、ハンドル操作に係るシステムのため、故障が発生した際、人命に関わる恐れがあり危害度は最も重いS3。自動車を運転中は常に使用されるので発生頻度が高くなりE4。故障が発生すると危害を回避することが困難なので制御難易度は回避困難なC3となり、最も厳しいASIL-Dとなる。しかし、故障診断ツールとの通信機能などハンドル操作に関わらない付属処理は、危害が小さくS1、使用頻度が低くE1、危害の回避が容易C1であることから、最も低いQMになる。このように複数種類のリスクが共存したシステムで機能安全を満足するために、ASIL-D機能が他のASIL機能から影響を受けないように、ASIL間の干渉を回避する必要がある。2.2　ソフトウェア開発の課題開発計画を遅延させる大きな要因として、Q&Aの多発がある。この発生原因を調査すべく、｢Q&Aリスト｣の分析を行った。結果を図2に示す。大別すると、原因はソフトウェア仕様書の記載不足であり、ソフトウェア仕様書の記載不足箇所は、ソフトウェア構造に関わる部分が多くを占めた。また、ソフトウェア構造に関わる部分の中でも近年に変更した部分が多いことがわかった。上記のことから、近年に変更したソフトウェア構造に着目して仕様書を見直し、Q&A件数を30%削減することを目標とした。３．ソフトウェア仕様書の改善近年、EPS制御用ソフトウェアは、安全規格対応のためにAUTOSAR（Automotive Open System Architecture）のアーキテクチャが導入されている。AUTOSARのアーキテクチャでは、ASIL（AutomotiveSafety Integrity Level）と制御周期の依存関係を理解し、ソフトウェアを変更する必要があるが、ソフトウェア仕様書に明記できていなかったことで、委託先からの不明点に関する問合せ、確認が多く発生していた。そこで、ソフトウェアの静的な視点から配置図を、動的な視点からシーケンス図の導入を検討した。3.1　ソフトウェア構造の変更点（1）機能安全のASIL割り当てと干渉回避機能安全とは、ISO26262 Part1において、“電気電子（E/E）システムの機能不全のふるまいにより引き起こされるハザードが原因となる、不合理なリスクの不在"と定義され、システムが故障した際に“リスク"を“許容できる2314 139 9 86 6 5 4 30510152025Q&A件数[件]ソフトウェア仕様書の記載不足記述ミス、ソフトウェア設計上の検討不足図２．Q&Aリストの分析結果制御難易度C1容易に回避可能C2通常は回避可能C3回避困難S1E1極低QM QM QM軽度E2低QM QM QME3中QM QM ASIL-AE4高QM ASIL-A ASIL-BS2E1極低QM QM QM重度E2低QM QM ASIL-AE3中QM ASIL-A ASIL-BE4高ASIL-A ASIL-B ASIL-CS3E1極低QM QM ASIL-A生命をE2低QM ASIL-A ASIL-B脅かすE3中ASIL-A ASIL-B ASIL-CE4高ASIL-B ASIL-C ASIL-DQM：Quality MaｎagementASIL：Automotive Safety Integrity Level危害度発生頻度低 高高低表１．リスクの決定69車載ソフトウェアにおけるソフトウェア仕様書の改善3.2　ソフトウェア仕様書の改善（1）機能安全に適応した配置図の導入従来は図4に示すDFD（DataFlowDiagram）を使用し、左から右へ処理が流れるように機能の構成要素を配置し、データの流れを矢印で示すことで各構成要素間の依存関係を記載していた。導入した配置図（図5参照）はASILと制御周期の関係を意識して、大項目をASIL、中項目を制御周期、小項目として各構成要素を機種間の共通・非共通で区分配置することにより、ASILと制御周期の依存関係を整理し、ソフトウェアの構成要素間を矢印で結ぶことで依存関係を明確化した。（2）AUTOSARの導入によるソフトウェア構造の変更AUTOSARとはソフトウェアモジュールの共通化を図り、再利用性の向上を目的とした規格である。ASIL間の干渉回避には、MPU（注3）を用いた不正アクセス防止機能が有効であるため、AUTOSARが提供するMPUの設定モジュールが使用されている。ソフトウェア構造の変更として、従来は、ROM、RAM及びStackを分割せず共通で使用していたが、AUTOSAR導入後は、ASIL間の干渉を回避するために、ROMとRAMはASILに応じて、StackはASILと制御周期に応じて分割した。これにより、ASIL間の干渉回避を実現した。図3にイメージ図を示す。【ROM】【RAM】【Stack】【ROM】(ASIL-D)【RAM】(ASIL-D)【Stack】制御周期1 (ASIL-D)【ROM】(QM)【RAM】(QM)【Stack】制御周期2 (ASIL-D)【Stack】制御周期1 (QM)【Stack】制御周期2 (QM)【従来のソフトウェア構成】【機能安全対応/AUTOSAR対応】図３．ソフトウェアの構造変更内容（注３）マイコンが提供するメモリプロテクション機能。指定したメモリ領域に対して、不正なアクセスを保護する。ASIL-D制御周期1機種間非共通の制御入力処理(機種間非共通)制御周期1 (ASIL-D)機種間共通の制御入力処理(機種間共通)制御周期1 (ASIL-D)制御周期2機種間非共通の制御機種間共通の制御入力処理(機種間非共通)制御周期2 (ASIL-D)入力処理(機種間共通)制御周期2 (ASIL-D)制御処理(ASIL-D)QM制御周期1機種間非共通の制御入力処理(機種間非共通)制御周期1 (QM)機種間共通の制御入力処理(機種間共通)制御周期1 (QM)制御周期2機種間非共通の制御機種間共通の制御入力処理(機種間非共通)制御周期2 (QM)入力処理(機種間共通)制御周期2 (QM)制御処理(QM)構成要素図５．配置図入力処理(機種間共通)入力処理(機種間非共通)制御処理構成要素図４．DFD70車載ソフトウェアにおけるソフトウェア仕様書の改善4.2　副次効果：影響分析の精度向上機能の追加や変更を行う場合、ソフトウェアの影響分析には、従来DFDやコールツリーを用いていたが、機能が複雑な場合は、影響分析に漏れが発生し、その影響で後の工程でも手戻りが発生していた。改善後は作成した配置図とシーケンス図で構成要素の関連と処理順序を明確にしたた（2）シーケンス図の導入従来は図6に示すコールツリーを使用しており、最上位を各制御周期のメイン関数とし、上から下に処理が流れるようにサブ関数を記載して、関数単位のコール順序が把握できるようにしていた。そのため、複数の制御周期で実現される機能の場合は、複数のコールツリーから処理順序を確認する必要があり、機能単位の動作を把握することが難しかった。そこで動的な視点として、機能の実現に必要な各構成要素の相互作用を時系列で表現できるシーケンス図を追加した。作成したシーケンス図を図7に示す。実現する機能をアクターとして設定し、各構成要素を横方向にならべ、縦方向に上から下へ実行過程を示すことで、機能単位での処理順序を明確化することにした。４．改善効果4.1　Q&A件数の削減ソフトウェア仕様書改善による効果を、同程度の規模のソフトウェア開発で比較した結果を図8に示す。ソフトウェア仕様書の記載不足について、改善前の37件（23+14）に対し、改善後は6件（4+2）となり、Q&A件数を約60%削減した。表2に示すとおり、目標の30%を上回る改善となった。入力処理(カスタム)制御周期メイン関数：入力処理関数：〇〇〇関数：△△△関数：トルクセンサ情報取得関数：エンジン情報取得関数：・・・・関数：・・・・関数：車速情報取得関数：・・・・図６．コールツリー入力情報の生成入力処理(カスタム)制御周期1 (ASIL-D)エンジン情報を取得する車速情報を取得する入力処理(カスタム)制御周期2 (ASIL-D)トルクセンサ情報を取得するアクター構成要素2314 139 9 86 6 5 4 34 2135 683 5 4 4 50510152025Q&A件数[件]改善前改善後ソフトウェア仕様書の記載不足記述ミス、ソフトウェア設計上の検討不足図７．シーケンス図図８．Q&Aリスト分析結果（改善前と改善後の比較）項目改善前改善後ソフトウェア開発ライン数[Kline]44 68Q&A件数 [件] 100 59Q&A件数 [件/Kline] 2.27 0.87削減率[%] - 61表２．ソフトウェア変更規模あたりの改善効果71車載ソフトウェアにおけるソフトウェア仕様書の改善め、影響分析の精度が向上した。4.3　効果査定と次年度の工数改善見込みプロジェクト全体での効果査定を行うために、同程度の規模のソフトウェア開発で比較した結果を表3に示す。ソフトウェア設計工数は、ソフトウェア仕様書に配置図とシーケンス図を追加したことで工数が増加するが、委託先とのQ&Aの工数が削減できた。また、ソフトウェアテストでは4.2項で述べた影響分析の精度向上により、作業工数が改善され、ソフトウェアテスト工数削減の効果を得た。次年度で本改善を適用するプロジェクトの合計生産量が100Kline見込まれるので、次年度では年間327hrの工数削減が可能となる。５．むすび本稿で紹介した配置図及びシーケンス図の有効性を確認できたため、今後はソフトウェア仕様書作成時に配置図とシーケンス図を必ず作成するように、チェックシートへ追加するなど、抜け漏れを防ぎ定着させていく所存である。最後に、本活動に当たり多くの助力をいただいた関係者各位に深く感謝申し上げる。執筆者紹介岩元　慶介 イワモト　ケイスケ2007年入社。主に車載システムのソフトウェア開発に従事。現在、姫路事業所技術第1部技術第1課。項目改善前[hr]改善後[hr]効果[hr]ソフトウェア設計工数28.68 30.37 +1.69Q&A工数4.55 1.74 -2.81ソフトウェアテスト工数29.80 27.65 -2.15合計63.03 59.76 -3.27表３．ソフトウェア1Klineあたりの改善効果