安心安全のための技術 ~データを保証するソフトウェア~

この記事の目次

    Page Top

    デンソーのソフトウェア領域における取り組みや技術活用の舞台裏を語る「DENSO Tech Night」。4回目となる今回のテーマは、「0.0001秒の攻防!? 快適な運転を支えるリアルタイム制御と組み込みエンジニアの実践知」。100µsで回す制御、µs級で見守る電池、1msで保証する安全――見えない時間をどう設計するかが、快適さ・寿命・信頼性を決めます。同社の車載ECUソフトウェア開発者がその方法論を実装と検証のリアリティとともに明かしました。

    • 株式会社デンソー ソフトウェア統括部 ソフトウェア技術3部 課長長野 雄二YUJI NAGANO

    続いて登壇したのは、ソフトウェア統括部の長野 雄二です。2006年にデンソーに中途入社し、パワートレインの車載ECUソフトウェア開発に従事してきました。現在は、ダイアグ(故障診断)や通信などプラットフォームの設計を幅広く担当しています。

    基幹系システム出身という経歴を持ちながら、「データを動かすだけでなく、物を動かしたい」という想いでモビリティの世界へ。

    安心・安全のための技術、データを保証するソフトウェアをテーマに、HEV(ハイブリッド車両)制御の全体像から具体的な監視・通信の設計、そして将来展望までお話しします。
    (長野)

      この記事の目次

        電動車の「頭脳」──パワートレインECUとHEVの仕組み

        長野はまず、HEV制御の仕組みを説明しました。

        電動車の頭脳を担うパワートレインECUのソフトウェア、HEV車の仕組み

        HEVの価値は、環境負荷低減と走行性能を電動制御×エンジン制御で両立する点にあります。なかでもシリーズ・パラレル方式は、エンジンとモーターの双方を駆動源として活用でき、車両メリットが大きい一方、制御ロジックとソフトウェアの複雑度が高くなります。

        HEV制御の働きを説明した図

        中枢となるのがHEV ECUです。アクセルペダル位置などの入力を受け、演算のうえでモーター(MG / インバーター)へのトルク指令、エンジンへのパワー指令、周辺機器への出力要求を協調的に出します。背後ではバッテリーECU(BMS)が充放電状態を監視し、HEV ECUへSOC / SOH等を供給。複数ECUの連携で、ドライバー要求と車両状態に最適な出力配分を決めていきます。

        ここで長野は、HEV ECUの基本要件を端的に整理します。

        1.ドライバー要求の充足(加速・減速・操縦の意図を忠実に反映)
        2.燃費最適化(コンポーネント協調でエネルギー効率を最大化)
        3.使用限界の遵守(各部の温度・電圧・電流・寿命制約に違反しない)

        この3要件を支える横串のキーテクノロジーが「機能安全の監視」と「通信データの保証」です。

        機能安全の監視──「多層防御」で致命傷を回避する

        機能安全は、許容できないリスクを安全機能で回避するという考え方です。長野は踏切の例で直感的に説明します。

        機能安全の監視の重要性

        人が線路をわたる箇所に踏切センサーを設置することで、列車や人の侵入を検知し、遮断・警告を行うことで危険を許容可能な水準へ低減します。このように発生しうる危険性を低減するために対策するのが機能安全の基本的な考え方です。

        一方、線路をわたること自体を回避する方法は「本質安全」の対策といわれます。これは、車両ではコストやスペースの制約から現実的でない場合が多いです。

        ゆえに車載ECUでは、プロセス / ルール(設計手順)×ハードウェア×ソフトウェアの三層で故障モードを塞ぐ「多層防御」を採用します。どの層の異常かを捉え、致命的状況に至る前に安全側へ落とす仕掛けです。

        機能安全と「時間」── FTTIで安全移行を保証する

        ここで、機能安全をこのイベントのテーマである「時間」で捉えます。

        分析・設計した時間内に安全対策を完了させている

        安全設計を語るうえで不可欠なのが時間制約。異常が検出可能状態になった瞬間を起点に、検知→処置→車両が安全状態へ移行するまでの時間を設計上束ねた概念がFTTI(Fault Tolerant Time Interval:安全状態移行時間)です。

        制御対象によってユーザーが危険を感じる時間は変わります。だからこそ、対象に合った時間粒度で検知・処置を設計し、FTTI内に安全側へ移す必要があります。
        (長野)

        アクセル操作におけるトルク制御の例

        アクセルは重要入力のため二重化(2系統)。1ms周期でセンシングし、5ms前のデータを確定、1ms周期で出力します。

        この処理列のなかに安全に移行できる監視タイミングを設け、異常に対する処置を差し込みます。監視は二層構えで、(A)機能そのものの故障検出(例:アクセルセンサーの物理的断線)と、(B)「機能が正しく動いているか」を保証する監視を同時に行います。

        以下、(B)に焦点を当てます。

        ソフトウェアの「正常動作保証」── RRFIで要所を固める

        ソフトウェア側の故障モードを想定し、RRFI(ROM / RAM / Flow / Instruction)を網羅してチェックします。

        機能安全の監視はどのタイミングで動作するかの設計図

        ⚫︎ROMチェック:チェックサム等で内容破損を検知
        ⚫︎RAMチェック:既知パターンのリード&ライト、マイコン内蔵ECCの結果監視
        ⚫︎Flowチェック:想定時間どおりに処理が回っているか(定期ロジックと独立した監視ロジックで二重化)
        ⚫︎Instructionチェック:ソフトウェアの命令実行結果を既知値と照合。ロックステップ等のハード機能も活用

        これらを時間要件に合わせて配置し、異常を間に合うタイミングで拾う設計を徹底しています。

        通信データの保証── CAN / CAN FDの「その先」を見る

        通信データの監視の必要性

        車載ネットワークではCAN(Controller Area Network) / CAN FD(CAN with Flexible Data Rate)が標準的。物理層の差動信号とプロトコル上のCRC※でバス上のデータ破損は検出できるが、ECUへ取り込んだ後の完全性は別途担保が必要です。そこでデンソーでは、ECU内でも受信後の一貫性チェックを行っています。

        シフトバイワイヤ×トルク制御の例がわかりやすいです。シフト位置はCAN経由で伝送され、期待外れのデータを通してしまえば安全リスクが直撃。ゆえに通信データの監視は必須となります。

        ※Cyclic Redundancy Check(巡回冗長検査)

        故障モードの動作が定義されており細かな対策でデータの信頼性を確保している

        ISO 26262で定義される通信故障モード――メッセージ破損・遅延・損失・反復・入れ替え・挿入・ID誤りなど――に対し、デンソーは標準化以前から検出と対策を積んできました。なかでも効果的なのがシーケンスカウンタです。

        データフィールドにカウンタを持たせ、受信のたびに連番で増えるのが期待値。固定化 / 非連続を検知したら、そのデータは破棄します。シンプルですが、この積み重ねがデータの信頼性を確かなものにする、というのが我々のECUでやっていることです。
        (長野)

        ECUアーキテクチャの進化と「つながるソフトウェア」

        車載ECU・ソフトウェアの将来性

        ここで、長野は車載ECU・ソフトウェアの将来の展望を述べます。将来の車載ECUは、個別ECUの連携からネットワーク型を経て、さらに集約・統合アーキテクチャへと進化していきます。機能を束ねることで協調度が増し、大規模開発の生産性や品質を引き上げられます。
        もう一つの潮流が、ユーザーとつながるソフトウェア。多様な利用シーンで得た車両データの収集・活用をOEMと連携し、OTAで機能を素早く届けます。これにより、ユーザー体験はアップデートで継続的に進化していくと長野は考えています。

        車載ECUソフトの重要度は、これからますます高まります。デンソーが社会に貢献できる領域も、いっそう広がっていくはずです。
        (長野)

        「つくる喜び」が駆動力になる

        最後に長野は、エンジニアの醍醐味に触れました。

        ゼロから生み出す:──白紙のテキストに自身が設計したコードを書き、製品へ育てる手応えが感じられる
        仮説と検証:──負荷や処理速度の打ち手がピタッとハマる快感がある
        価値創出:──ユーザーが満足する姿を目にする喜びがある

        自分が設計したものを自ら運転して確かめられるのはモビリティならではだと私も思います。だからこそ「つくる喜び」が、次の挑戦へ走らせます。
        (長野)

        【Q&Aセッション】

        Q&Aセッションでは、株式会社デンソーのECUソフトウェア開発者3名がイベント参加者から投げかけられた質問に回答しました。

        Q. ソフトが100µsなど極短周期でモーター制御をしているとのことですが、トランジスタや回路の遅延・ばらつきで期待性能が出ないことは? 事前に厳密な検証をしていますか?

        浜田:影響は確実にあるので、設計で必ず折り込んでいます。三相の上側・下側トランジスタは同時オン厳禁で、オフ→オンのデッドタイムを設けます。応答はµsどころかnsオーダーまで詰め、素子やRCの経時劣化・初期誤差も含めて最悪値 / 典型値を積み上げ、必要なソフト側遅延や制御ロジックを決めます。

        そのうえで実機評価、いわゆるチャンピオン品(良品代表)とワースト品(ばらつき端)を用意して​​​​動かすなど、折り込みが妥当か実測で検証しています。

        Q. BMSソフトウェア開発のテストはどのように行っていますか?

        鬼頭:BMSはHILS(Hardware-in-the-Loop Simulator)に加え、バッテリー・シミュレータを用います。数百V級かつ多数セルの電圧 / 電流 / 温度を個別セル相当で模擬し、通常系と異常系(過電圧 / 温度連動 / 電流変動など)を再現してテストします。最終段階では実電池も使いますが、専用設備で安全に実施しています。

        浜田:ハイブリッド側もHILSで、アクセル・シフト等の入力を与えて走行状態を再現し、OEMさまと実機連携評価も行います。モーターはプラントモデルに加え実機ベンチで回し込み、モデル外挙動も確認しています。

        さらに「想定外はダメ」という前提で、全端子FMEA※をハードと共同で行っています。各センサー / 電源 / 信号線の断・短・ズレを網羅し、「その瞬間だけOK」というわけではなく幅をもって安全に落とせるかを見ていて、「想定外」を減らす設計ができるように意識しています。

        ※Failure Mode and Effects Analysis(故障モード影響解析)

        Q. RAMは定期的にチェックしなければならないのでしょうか?

        浜田:正直、頻繁には壊れません。壊れていたら制御は成り立ちませんからね。ただし「万が一の一撃」──例えばRAM化けでアクセル値が跳ね上がれば事故に直結します。だから常時監視を掛けているわけです。多層防御で、品質管理・設計・監視を重ねます。理屈は「1%を1ppmへ、さらに0に近づける」。壊れるからやるのではなく、​「​壊れなくてもやる​」​設計です。

        鬼頭:バッテリーも同じ考え方です。基本的にハードウェアが壊れる可能性はゼロではありません。壊れたときにお客さまに安心・安全をご提供するために必ず対策しています。

        Q. 8µs±10%のばらつきは、MCU命令時間も含みますか?

        鬼頭:両方含みます。ただ多くの場合はIC内部クロックのばらつきです。MCU側はクリスタル基準で精度が高く、変動は小さいものの、ゼロではないので入れています。さらにデイジーチェーン通信の伝搬時間など周辺遅延も加算します。すべて積んだうえでも時間要件を満たすようにスケジューリングします。ここまで全部込みで設計です。

        Q. デンソーに合うエンジニア像は?

        長野:連携を楽しめる人。多人数・多職種(ハード / ソフト)で分担しながら開発するので、協働で良いものをつくり出す喜びを感じられる方は活躍できると思います。

        鬼頭:新しいことに挑戦したい人です。事業化や電動化の立ち上げのように、未知を形にする場面が多い会社です。一方で量産設計は難しい。技術を追求し、できるまで粘れる方が向いています。

        浜田:一言で何ごとにも興味がある方。興味があると想像力が働きます。ソフトを書いて終わりではなく、回路は? アクチュエータ​ー​は? センサーは?と隣接領域へ踏み込む好奇心こそが想定外を減らすはずです。そういう人にぜひ入社してほしいですね。

        ※所属組織および取材内容は2025年9月時点の情報です。

        COMMENT

        あなたが実現したいこと、学びたいこと、可能性を広げたいことに、この記事は役に立ちましたか?
        ぜひ感じたことを編集部とシェアしてください。

        「できてない」 を 「できる」に。
        知と人が集まる場所。