JP2017076158A - 動作ログ処理装置 - Google Patents

Abstract

【課題】本来のＣＰＵのリルタイム性能や車載ネットワークのトラフィック性能を損なわないように、取り外しおよび後付け可能な動作ログ採集装置を実現するとともに、本装置が車両のどこに格納されていても人間が簡単にアクセス可能であるようにする。【解決手段】ＣＰＵからシリアル通信で伝送可能なログ記憶装置を設置し、ログ内容は無線ＬＡＮで外部に伝送する。その際、本来のＣＰＵバスと無線ＬＡＮ用のバスを分離し、本来のＣＰＵのリアルタイム性能を損なわせない。【選択図】図１

Description

本発明は、車載制御装置およびそのソフトウェアの動作ログを収集するシステムに関する。

近年車載用機能安全規格ＩＳＯ２６２６２が制定されるとともに、車載用機器に対する安全性・信頼性に対する要求の厳格化や国際規格への準拠の義務化が進展している。特に車載ソフトウェアに対しては、車の挙動の中核的特性を担うことともに、その全体的な（網羅的な）挙動解析の困難さから、新たな検証手法の登場が待たれている。

また、昨今車載用電子機器（ＥＣＵ：Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔと呼ばれる）が一つの車に複数台搭載されており、車載ネットワークを通じて相互に影響を及ぼしあって全体的な動作を実行している。したがって、当該車載ソフトウェアの検証は、単独の車載用電子機器（スタンドアローンＥＣＵ）のときと比較して格段に難しくなっている。この状況は複数ＥＣＵを経済効果のために集約した統合化ＥＣＵ（構成基板の上に複数のＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）が搭載されている）もしくはマルチコアＣＰＵを採用してコアごとに別々の処理を実行して性能を向上させたＥＣＵでも同じである。検証の難しさは、複数のＥＣＵ（ＣＰＵもしくはコア）の挙動を同一時間軸上で並行に追跡する困難さに起因している。（ＣＰＵもしくはコア間の情報のやり取りは車載ネットワークもしくは共有メモリを通じて行われる。）
加えて製品の市場リリースは必ずしもソフトウェア検証の終了という確証に基づいて、それ以降に設定されるものではない。つまり、量産段階においても稀頻度の障害を組み込みソフトウェアが含んだ状態で出荷せざるを得ないことは経済活動（開発コストや顧客誘引を促進する製品サイクルという観点）において自明である。

しかしながら、そのような稀頻度の不具合が発生したときに如何に乗員を保護するかは前述の機能安全の範疇であり、これを記録して次回の製品開発（差分開発による機能と信頼性の向上）に如何に活用するかは機能安全ライフサイクルの活動に関わる。この鍵を握っている手法は、ソフトウェア挙動のロギングシステムである。

一方、近未来における実現に向けて開発が加速している自動運転については、状況認識プログラムや意思決定プログラムが従来のルール・ベースの仕様ではなくなる可能性がある。機械学習（ディープラーニング（ニューラルネットの一種）、ベイジアンネットワーク（確率論的判断モデル）、遺伝的プログラミング）が取り入れられて、旧来の仕様書ベースの制御動作とは異なる、即ち人間にとっては理解不能なソフトウェア構造になることが予想される。

その際には、何らかの監視エージェントが（システム同定可能な）入出力の組を定期的にロギングし設計検証に反映できなければ、技術的にも法的にも従来の工業製品としての位置づけで製品を取り扱うことが困難となるであろう。この点においてもソフトウェア挙動のロギングシステムが益々重要視される所以である。

外界の情報とそれに対応するソフトウェア挙動のロギングは人工衛星や探査衛星などの宇宙機で知られた手法であり車載応用の用途では一般化していない。しかしながら、前述の機能安全対応手法として、もしくはロギングされたデータを設計検証に反映させる機能安全ライフサイクル手法の一つとして将来的に普及すると思われる。

その際、実現の決め手になるのはロギング装置そのもののコストとロギングされたデータをＥＣＵ外部に取り出す仕組みに関するコストである。前述の宇宙機の場合は、事故が発生したときの逸失利益を考慮すると、ロギング装置およびそれを伝送するテレメトリー装置を追加することのコストなどは微々たるものであろう。

しかしながら自動車のような耐久消費財についてはできるだけコストが安いことと、オプションとしてロギング装置を追加設定可能と成すときの（本来のＥＣＵを構成する）ＣＰＵに対する接続機構の単純さが求められる。

従来技術は、車載ネットワークに繋がる複数のＥＣＵが動作ログを交換し、動作の相互監視やバックアップ動作に役立てようとするものがある。例えば特許文献１に示すように、複数のＥＣＵがノードを構成する各ＥＣＵの動作状況を相互監視し、問題が発生したノードの代わりに他のＥＣＵがバックアップ動作を行う技術が知られている。

特開２０１２−２５３９０号公報

しかしながら、上記特許文献１では、動作ログを交換する経路が車載ネットワークであり、動作ログの総量および交換頻度によっては、本来の車載ネットワークを使用すべき通信データの交換タイミングや通信帯域を妨害して支障が出ることが予測できる。

加えて、車載ネットワークに動作ログを流す手続きは、ノード（ＥＣＵ）本来のＣＰＵが行っており、本来の車両制御手続きと同時にネットワークプロトコルを稼働させることは該ＣＰＵにとっても大きな負担になる。上記と同様に動作ログの総量および交換頻度によっては、最悪の場合リアルタイム制御性に支障をきたす事態になることも予測できる。

本発明は、上記のログ伝送経路に関するトラフィック占有の課題と、伝送に際してプロトコルで消費されるＣＰＵリソースによってＥＣＵ本来のリアルタイム性が損なわれる両課題を解決するためになされたものである。

本発明に係るログ採集装置においては、ログ情報の出力はＥＣＵが接続される従来の車載ネットワークを用いず無線通信手段により外部伝送することとする。

また、検証対象ＣＰＵとログメッセージを格納するログ記憶装置との間の接続に用いられるバスと、ログ記憶装置と外部出力のための無線通信手段との間の接続に用いられるバスとを分離し、検証対象ＣＰＵ本来のリアルタイム性を損なわないよう配慮する。

これは換言すれば、無線通信通信プロトコルを実行するＣＰＵを、検証対象ＣＰＵとは別に設定しログ採集装置側に増設することを意味する。

本発明に係るログ採集装置によれば、本来の検証対象ＣＰＵのリソースを制御以外に消費せずリアルタイム性を損なうことが無い。また、ログ情報の出力経路が車載ネットワークではなく無線通信であるので、車載ネットワーク本来のトラフィックを妨害することがない。

加えて、出力手段が無線通信であるので、ＥＣＵが車両の人間が触れることが難しい車両の奥深くに実装されていても容易にログ情報にアクセスすることが出来る。

また、検証対象のＣＰＵには、無線通信出力に関する如何なる動作仕様も実装されていない。すなわち、検証対象ＣＰＵはログ記憶装置に対するログ情報の書き込みのみの動作仕様しか実装されていない。

したがって、ログ記憶装置を接続境界として検証対象ＣＰＵ側と無線通信出力側が独立であるので、ログ採集装置自体を追加オプションとして設定可能である。もし、このオプションが有効でなくログ採集装置が実装されていないならば、検証対象ＣＰＵはログ記憶装置が接続されていると仮定して動作ログを吐き出す（無意味な）動作を行うのみであり、他に何の副作用も無い。

これにより、ＥＣＵ開発期間の特性取得フェイズ（車両試作期やソフトウェア検証期）のサンプル群にはログ採集装置を付け、それ以外の例えば量産車においてはログ採集装置を省略することによりコストの増加を抑制することが出来る。

実施形態１に係るログ採集装置の構成図である。 実施形態１に係るログメッセージの出力内容を示すプログラムリストである。 実施形態２に係るログ採集装置の構成図である。 実施形態２に係るＣＰＵの内部機構を示すブロック図である。 実施形態１および２に係る無線ＬＡＮ手続きの動作タスク図である。 実施形態１および２に係る内部動作手順を示すＳＤＬ（Ｓｐｅｃｉｆｉｃａｔｉｏｎ ａｎｄ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）フローチャートである。

＜実施の形態１＞
図1は、本発明の実施例の一つを図示したものである。ＥＣＵ筐体１００の中に、検証対象ＣＰＵ１０１および検証対象制御ソフト１０２が格納されており、それとともにログ採集装置１１０が格納されている。

ログ採集装置１１０は、ログ記憶装置１０５、通信プロトコル用ＣＰＵ１０６、セカンド・バス１０７および無線通信手段としての無線ＬＡＮ手段１０８で構成されている。

ログ記憶装置１０５には、電源が切断されても記憶内容が消去されないよう図示するようにフラッシュメモリが使われているが、不揮発性の記憶装置ならばいかようのものを用いても良い。

ＥＣＵ１００本来のＣＰＵ１０１は、バス１０３に接続された制御記憶、すなわち検証対象の制御ソフトウェア１０２に指示に従い動作を実行するが、その際１０２にはアサーション命令（詳細は図２に示す）が記述されている。

アサーション命令に出会ったとき、そこに記述された条件に従い動作状況における正常か否かを判定する。もし、異常であった場合は同じくバス１０３に繋がる周辺装置、図示ではＳＰＩ（Ｓｅｒｉａｌ Ｐｅｒｉｐｈｅｒａｌ Ｉｎｔｅｒｆａｃｅ）１０４を通じて動作ログがログ記憶装置１０５に送られ記憶される。これにより異常状態が後から解析可能となる。

以上が本来のＣＰＵ１０１で行われる動作であり、出力されたログ情報がその後どのように取り扱われるかには関知しない。したがって、ログ採集装置１１０が実際に実装されているか、それともオプションとして省略されているかは、ＣＰＵ１０１自体は関知しない。

これにより、いわゆる検証済みの量産製品ではログ採集装置１１０は非実装にでき、コストの上昇を抑えることができる。

一方、ログ記憶装置１０５に格納されたログ情報は、通信プロトコル用ＣＰＵ１０６によってセカンド・バス１０７を通じて無線ＬＡＮ手段１０８に送られる。無線ＬＡＮ手段１０８は、いわゆるＷｉ−Ｆｉ（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ）手段を通じてログ情報を外部に伝送し、図示の例ではノートパソコン１０９の内蔵無線インターフェース（図示せず）でこれを受信して、該ログ情報をパソコン上で解析することができる。

従って本来ＣＰＵ１０１のバス１０３とＷｉ−Ｆｉ出力用のセカンド・バス１０７とが完全に分離されるので、ＣＰＵ１０１のリルタイム性や車載ネットワーク（図示せず）の性能を損なうことも無い。

図２は、ＣＰＵ１０１が実行する組み込みソフトウェアのソースコード２００の一実例を示したものである。このソースコード２００は、図１では検証対象の制御ソフト１０２の中に記述されるものとする。

このソースコード２００の中に異常があればログを取りたい条件をアサーション命令として埋め込んでおく。例えばアサーション命令２０１は、アサーションの一例であって、整数割り算の除数が０であるか、商がオーバフローしそうな時にａｓｓｅｒｔ関数のカッコ内の条件式が偽となる。このときａｓｓｅｒｔ関数は、前述の周辺装置であるＳＰＩ・１０４を経由してログ記憶装置１０５に情報を書き込むよう関数ライブラリを構成しておく。

アサーションログ２１０は、ログ記憶装置１０５が保存した情報の一例であって、その中でアサーション命令２０１によりログダンプが発生したときの記録を２１１に、またその中でアサーション命令２０１のみに起因する情報を２１２に示す。

アサーションメッセージ２１２では、一例としてアサーション命令で偽となったときの条件式、そのプログラムファイル名、行番号を出力してソフトウェア不具合を特定しやすいようにしている。図中“（ｔｉｍｅ＿ｓｔａｍｐ）”はＣＰＵ１０１が付加したアサーションメッセージ２１２が発行された瞬間のタイムスタンプ値であり、ＣＰＵ周辺装置の一例であるリアルタイムカウンター（図示せず）よりＣＰＵ１０１が値をキャプチャして記録された時間情報である。これは主に複数のアサーションメッセージ間の相対時間を計算するのに使用される。

＜実施の形態２＞
図３は、本発明の別の実施形態を示したものでＣＰＵ１０１とログ記憶装置１０５の間にＪＴＡＧ出力バス３００とＪＴＡＧコントローラ３０１が結線されておりＪＴＡＧ出力を通じてログ情報を転送する方式を示したものである。

この実施形態においてもＣＰＵ１０１のバス１０３とＷｉ−Ｆｉ出力用のセカンド・バス１０７とが完全に分離されているのでＣＰＵ１０１のリアルタイム性能を損なうことが無い。

また、実施形態１と同様にログ採集装置３１０はＣＰＵ１０１から見て完全にオプショナルであり、実装時と非実装時でＣＰＵ１０１の性能に変化が無いことは実施形態１と同様である。

ＪＴＡＧコントローラ３０１は、ＪＴＡＧを通じてＣＰＵ１０１内部のレジスタを定期的に読み出し、アサーションメッセージが書かれていたならば、その内容をログ記憶装置１０５に転送する動作を行う。この動作はＣＰＵ１０１が非関与およびＣＰＵ１０１とは非同期に行われる。該ＪＴＡＧコントローラ３０１を設置する代わりに通信プロトコル用ＣＰＵ１０６がその機能を兼ねてもよい。

図４は、本実施形態のＣＰＵ１０１の内部を示したもので、アサーションメッセージの出力レジスタとしてＪＴＡＧ（Ｊｏｉｎｔ Ｔｅｓｔ Ａｃｔｉｏｎ Ｇｒｏｕｐ）のオプションレジスタ４０９を利用したものである。

ＪＴＡＧは、集積回路や基板の検査、デバッグなどに使える、バウンダリスキャンテストやテストアクセスポートの標準 ＩＥＥＥ １１４９．１ の通称である。半導体技術の進歩により集積回路チップのピン間隔も狭くなりプローブを立てての検査が困難になってきている。表面実装のＢＧＡ（ｂａｌｌ ｇｒｉｄ ａｒｒａｙ）などのパッケージに至っては、物理的に不可能である。そのため検査時に、チップ内部の回路を数珠繋ぎにして内部状態を順番に読み出すしくみが考え出された。これをバウンダリスキャンテスト（Ｂｏｕｎｄａｒｙ Ｓｃａｎ Ｔｅｓｔ）といいそれを規格化したのがＪＴＡＧである。１９９０年にＩＥＥＥ １１４９．１として標準化されている。

ＪＴＡＧにはオプションレジスタというデバイス固有のレジスタが存在し、これを実装メーカが自由に機能拡張して使ってよいことになっている。これを図１におけるＳＰＩ・１０４の出力レジスタ相当に用いれば本発明をＪＴＡＧの機能に沿った形で実現することができる。

通常、ＪＴＡＧのデバイスはＣＰＵコア４００と情報のやり取りができるような内部バス接続を行っていない。これはＪＴＡＧがＩＣチップとプリント基板との電気的接続を検証する目的で使用されていることによる。

ただし、ＪＴＡＧをオンチップＩＣＥ（Ｉｎ−ｃｉｒｃｕｉｔ ｅｍｕｌａｔｏｒ）に拡張しているＣＰＵ実装メーカも存在しており、そのときにはＣＰＵ内部バスに接続してレジスタ値を読み書きしたり、制御メモリ（ＲＡＭ）４０２の内容を読み書きしたりできるものもある。

しかしその時においてもＣＰＵコア４００とＪＴＡＧデバイスとは本来無関係であって本発明向けに拡張するにはＣＰＵコア４００がシフトレジスタ（オプションレジスタ）４０９内容を操作可能のように改造しなければならない。

また、従来のＪＴＡＧ・オンチップＩＣＥでは、ＣＰＵのファームウェアが定期的なバスタイミングでＣＰＵ周辺の変数データ（レジスタやＲＡＭ値）をＪＴＡＧの拡張レジスタに書き込むタイプのものがある。この場合にはＣＰＵ内部バスとＪＴＡＧとは既に接続されているので、ＣＰＵが実行するプログラミングモデルからＪＴＡＧレジスタを可視（操作可能）にするような命令語の拡張をするだけで済む。こうすることによってプログラムメモリ４０１（図１では１０２に相当）に格納されたアサーション命令２０１の結果をアサーションメッセージ２１２としてＪＴＡＧ経由で出力することができる。

シフトレジスタ（オプションレジスタ）４０９の内容は、ＪＴＡＧのＴｅｓｔ Ｄａｔａ Ｏｕｔ端子４０５と次段に接続された同様のＪＴＡＧのＴｅｓｔ Ｄａｔａ Ｉｎ端子４０４を経由してシリアルダンプされることは図１のＳＰＩ・１０４と同様である。またそのときの外部クロックはＪＴＡＧのＴｅｓｔ Ｃｌｏｃｋ端子４０６の信号が使われる。

このモードへのＪＴＡＧの遷移はＪＴＡＧのＴＡＰコントローラ４１２の機能を用いて行われる。状態の遷移は、ＪＴＡＧのＴｅｓｔ Ｃｌｏｃｋ端子４０６、ＪＴＡＧのＴｅｓｔ Ｍｏｄｅ Ｓｅｌｅｃｔ端子４０７、ＪＴＡＧのＴｅｓｔ Ｒｅｓｅｔ端子４０８の信号の組み合わせにより行われる。

これらのＪＴＡＧ用制御端子（４０６〜４０８）の操作は、図３のＪＴＡＧコントローラ３０１が自律的に行い、プログラムメモリ４０１に格納される制御ソフト（図１では１０２に相当）では考慮する必要は無い。

図３のＪＴＡＧ出力バス３００と図示されている情報は、図４ではＴｅｓｔ Ｄａｔａ Ｏｕｔ端子４０５から得られる情報に相当する。

ＪＴＡＧの機能はＣＰＵにとっては検査用の隠し機能であって、図１の実施形態１のようにＣＰＵ周辺デバイスであるＳＰＩ・１０４を本発明用に明示的に消費しないという利点がある。

これは量産移行後の市場におけるフィールドテスト等で、ログ採集装置（図３の３１０）を一時的に仮設後付し、ＪＴＡＧポートにアクセスして動作ログを採取するという目的に適する。

＜実施の形態１および２に共通な項目＞
以下、実施の形態１および２に共通な実行プロセス上のタスク形態や全体的な動作シーケンスについて記述する。

図５は、ログ採集装置（図１における１１０、もしくは図３における３１０）内部の通信プロトコル用ＣＰＵ１０６が実行するプロトコルスタック上のタスク構成５００を示したものである。物理層の無線ＬＡＮ通信手段１０８からその階層のプロトコルを処理するタスクが順次通信データを解釈および中継しつつ処理を行う。

ここでプロトコルスタックとは、コンピュータ上で、通信を実現するための一連の通信プロトコル群を実装しているモジュール（プログラム部品）のことである。通信プロトコルは階層的な構造を持っている。そのため各階層で、それぞれ異なる役割のプロトコルが機能しており、各プロトコルが連携して初めて通信が実現されている。例えば、インターネットで用いられているＴＣＰ／ＩＰでは、ＴＣＰやＩＰに加えて、ＨＴＴＰ、Ｅｔｈｅｒｎｅｔ（ＩＥＥＥ ８０２．３）などの通信プロトコルが機能しており、それらが連携して初めて通信機能を実現している。

ログ記憶手段１０５に格納されたログ情報は読み出されてｈｔｔｐｄタスク５０５に入り、いわゆるＨｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌに翻訳される。すなわちこのｈｔｔｐｄタスク５０５がＨＴＴＰサーバ（Ｗｅｂサーバ）を構成している。

この情報は、下位プロトコルであるｔｃｐタスク５０４→ｉｐタスク５０３→ｅｔｈｅｒｎｅｔタスク５０１→無線ＬＡＮ手段１０８と流れるうちにそのプロトコル階層独特の詳細情報が付加され、複数の手続きやシーケンスに分割されてＷｉ−Ｆｉとして外部に伝送される。

図５で、ａｒｐタスク５０２とは、ＩＰアドレスと通信相手のＭＡＣアドレス（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ ａｄｄｒｅｓｓ）を関連づけるＡＲＰプロトコル（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を処理するタスクであり、外部のＷｉ−Ｆｉ機器との相互通信の宛先確立に用いられる。

これらのタスク構成５００は、応答速度が要求される（通信ログの転送速度に最終的に還元させられる）処理であり、ＥＣＵ１００本来のＣＰＵ１０１で実行させるにはあまりにも負荷の高い処理である。したがって、通信プロトコル用ＣＰＵ１０６とセカンド・バス１０７に通信処理を分離・集約しなければ、本来のＣＰＵ１０１のリアルタイム制御性を大いに損なうことになる。

図６は、上記の実施の形態１および２の全体処理をＳＤＬ（Ｓｐｅｃｉｆｉｃａｔｉｏｎ ａｎｄ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）フローチャートとして示したものである。

全体として３つの独立フローに分かれ、左より本来のＥＣＵ制御を行うＣＰＵ１０１が実行する処理（ｔ６００〜ｅ６００）、ログ記憶装置１０５で行われる処理（ｔ６１０〜ｅ６１０）、通信プロトコル用ＣＰＵ１０６が行う処理（ｔ６２０：無限ループでＨＴＴＰサーバを構成する）である。

本来ＣＰＵが行う処理（ｔ６００〜ｅ６００）は、検証対象の制御ソフトウェア１０２に含まれるライブラリ（ｐ６０１）であり、ログ記録用ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）として、図２のアサーション命令２０１（ａｓｓｅｒｔ関数）の中から呼び出される。機能はアサーションメッセージ２１２をログ記録装置１０５に向けてシリアル出力（ｓ６００）することであり、図１ではＳＰＩ・１０４用のもしくは図３ではＪＴＡＧ３００用のシリアル出力レジスタ（図４ではオプションレジスタ４０９に相当）に書き込んだあとは何もせずにｒｅｔｕｒｎ（元制御への復帰）を行う。

したがって実際にログ記録装置１０５が接続されているかどうか本来ＣＰＵは関知せず、量産製品などの検証済みの製品にはログ採集装置（図１の１１０もしくは図３の３１０）を付けずにコストの上昇を抑えることが出来る。その際の制御ソフトウェア１０２には前記のアサーション命令２０１が入ったままとなるが、放置しても性能として問題にならない。（コンパイラに与える処理オプションを量産時に変更することで自動的に除去可能である。）
ログ記憶装置１０５で行われる処理（ｔ６１０〜ｅ６１０）では上記のシリアル通信で提供されるログメッセージを受信（ｐ６１１）し、フラッシュメモリなどの不揮発性メモリにログを蓄積（ｐ６１２）する。また、通信プロトコル用ＣＰＵ１０６が実行するＨＴＴＰサーバ（Ｗｅｂサーバ）からデータを送信する旨の要求があればログデータを出力（ｐ６１３）する。このログデータは、前述のセカンド・バス１０７を通じて（ｓ６１０）提供される。

通信プロトコル用ＣＰＵ１０６が行う処理（ｔ６２０）では、Ｗｉ−Ｆｉ通じてログ出力のリクエストがあるかどうかがチェック（ｐ６２１）される。もし要求が無ければ待機（チェック＆ループ動作）を行い、要求があれば次のステップに進んで前述のログ記憶装置１０５よりセカンド・バス１０７を通じて（ｓ６１０）ログ情報を取得する（ｐ６２２）。

取得されたログ情報は図５のタスク構成５００を通じてＷｉ−Ｆｉ用プロトコルを満足するデータに組み上げ直して無線出力される（ｐ６２３）。

次の判定ではログ情報が全て伝送終了したか、すなわち取り出されたログ情報が終端に達したかがチェック（ｐ６２４）され、終端に達していなければログ取得（ｐ６２２）に再び戻ってＨＴＴＰプロトコルによるログ情報の送信を継続する。また、達していれば出力リクエストのチェック（ｐ６１２）に戻って出力要求待ちとなる。

以上、本発明の実施形態１及び２によれば、量産時に撤去可能もしくはフィールドテスト時に簡単に後付け可能なログ採集装置を、簡便に構成することができる。これによりＥＣＵ本体コストを最小限に抑えることが出来る。

該ログ採集装置の出力は、Ｗｉ−Ｆｉにより行われるので、既存の車載ネットワークを使う方式に比べて、本来の車載ネットワークのパフォーマンスに悪影響を与えることが無い。また、ＥＣＵが車両のどこに格納されていても、即ち作業員がリーチしにくい車両部位にあっても無線により簡単に情報にアクセスすることが出来る。

無線によるプロトコル処理は、本来ＣＰＵとは別のＣＰＵおよび本来バスとは別のセカンド・バス経由で行われるので、本来制御のリアルタイム性を損なうことが無い。

以上、本発明者によってなされた発明を実施形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。

また、上記各構成、機能、処理部などは、それらの全部または一部を、例えば集積回路で設計することによりハードウェアとして実現することもできるし、プロセッサがそれぞれの機能を実現するプログラムを実行することによりソフトウェアとして実現することもできし、集積回路と密接に関連したデバイス制御言語もしくはファームウェアとして実現することもできる。各機能を実現するプログラム、シーケンス、プロトコルスタック、テーブルなどの情報は、メモリやハードディスクなどの記憶装置、ＩＣカードなどの種々の記憶媒体やＳＤカードなどの記録メディアに格納することができる。

１００：ＥＣＵ、１０１：ＣＰＵ、１０２：検証対象の制御ソフトウェア、１０３:バス、１０４：ＳＰＩ、１０５：ログ記憶装置、１０６：通信プロトコル用ＣＰＵ、１０７：セカンド・バス、１０８：無線ＬＡＮ手段、１０９：ログ解析用パソコン、１１０：ログ採集装置、３００：ＪＴＡＧ出力、３０１：ＪＴＡＧコントローラ、３１０：１１０とは別実施形態のログ採集装置。

Claims (4)

1. 車載制御装置の筐体中に一体となって構成され、
   通常時は、検証対象のソフトウェアを実行するＣＰＵがバスにより接続された周辺装置を通じて該ソフトウェアの動作情報を動作ログとして該記憶装置に書き込み、
   該記憶装置に蓄積された情報を外部に転送するときは、前記ＣＰＵとは無関係な独立バスを経由して無線通信手段により転送を行うことを特徴とする動作ログ処理装置。
2. 車載制御装置の筐体中に一体となって構成され、
   通常時は検証対象のソフトウェアを実行するＣＰＵからＪＴＡＧ出力を通じて該ソフトウェアの動作情報を動作ログとして該記憶装置に書き込み、
   該記憶装置に蓄積された情報を外部に転送するときは、前記ＣＰＵとは無関係な独立バスを経由して無線通信手段により転送を行うことを特徴とする動作ログ処理装置。
3. 前記動作ログ記憶装置の動作ログを外部に転送する無線通信手段の実現には、前記検証対象ＣＰＵ以外の別ＣＰＵを用いて通信プロトコルを実現することを特徴とする
   請求項１乃至請求項２記載の車載用記録装置。
4. 前記動作ログ記憶装置の動作ログを外部に転送する無線通信手段においては、通信プロトコルとしてＨＴＴＰサーバ機能を含むことを特徴とする
   請求項１乃至請求項２記載の車載用記録装置。

Images