　ケーススタディーとして実際にこの検証手法を活用した事例を紹介する。ECU数は8個で、通信仕様は異なるものが4種類ある場合の検証を行った。通信信号の種類は2つで、イベント通知信号と制御信号がある。イベント通知信号は各ECUの状態遷移を流す。それに伴って送信される制御信号の送受信可否が重要な判定基準となる。通信仕様は共通して「起動」「過渡1」「過渡2」「停止」の4つの状態を持つ。状態遷移時間とイベントは各通信仕様により異なる。制御信号は起動状態のみで送受信できる。起動状態に向かう遷移は1つの遷移時間であり、停止状態に向かう遷移は遷移時間にバラツキを持つとする。

事例におけるネットワーク環境（クリックで拡大）出典：デンソー

　ここでの協調仕様検証は、仕様間不整合検出（送受信タイミング不整合検出）について、今回、テストパターンとして26万2144の網羅的な組み合わせとして検証した。その結果「従来の1000倍の組み合わせ評価にもかかわらず解析実行時間は5時間、結果処理時間は3日と従来の12分の1の期間で検証することができた。STIMULUSをつかうことで膨大なテストパターンでも短い期間で検証することが可能となった」と山口氏は評価した。不整合の発見は240個で、発生条件を分析しこれらを解決する検討を行った。そして解決したもので、協調仕様を作り出すことができたという。これにより、使用品質の向上と期間短縮を実現し、また、多変量解析との連携により、早期に仕様値を最適化することが可能となった。

仕様不整合の検出（クリックで拡大）出典：デンソー

　今後の展望としては、さらに仕様の種類が増加したり、ネットワーク構成が複雑化したりする中で、検証パターンの増加が見込まれている。そうした状況でも素早い協調仕様作成・最適化を維持するため、仕様検証、結果分析をさらに自動化できるように手法の確立に取り組む方針を示している。

⇒ 「車載ソフトウェア」のバックナンバーはこちら

状態遷移表を使用した要求分析モデル
実際に、要求仕様から状態遷移表を作成するプロセスを紹介する。モデリングを行いながら、要求仕様書で定義されていない曖昧な部分を検討し、明確化。上流工程の段階でモデルを洗練しておくことで、無駄のない最適なソースコードを作成できる。
いまさら聞けない車載ネットワーク入門
ますます高度化するカーエレクトロニクス。その土台を支える車載ネットワークも用途に応じて多くの仕様に細分化されている
車載イーサネットのフィジカルレイヤーはどのようになっているのか
インターネット経由で誰とでもつながる時代。個人が持つ端末はワイヤレス接続が大半を占めていますが、オフィスなどではいまだに有線によるローカルエリアネットワーク（LAN）が使われています。そのLANの基盤技術の1つとして広く使われているイーサネット（およびTCP/IP）が、次世代の車載ネットワーク技術として注目を浴びています。本稿では注目される背景、役割や規格動向から、関連するプロトコルの概要まで、複数回にわたり幅広く解説していきます。
CAN通信におけるデータ送信の仕組みとは？
CANを理解するうえで欠かせないフレーム。今回はデータフレームとリモートフレームの構造や使われ方、通信調停を解説する
次世代車載ネットワーク FlexRayとは？
次世代車載ネットワーク通信プロトコル「FlexRay」。本連載では、その仕様から、現在の状況・今後の動向までを詳しく解説していく
AUTOSARの最新動向：2018年3月版
既に量産車への適用が始まっている車載ソフトウェア標準「AUTOSAR」。これまでMONOistでAUTOSARの解説連載を2回執筆してきた櫻井剛氏が「AUTOSARを使いこなす」をテーマに新たな連載を始める。第1回は、まず現状を確認するためにAUTOSARの最新動向を紹介する。
AUTOSAR Adaptive Platformとは？
車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載の第7回では、AUTOSAR Classic Platformに次いで新たに登場したAUTOSAR Adaptive Platformについて説明する。