JP2012165033A - 自動車用制御システム及び電子制御ユニット - Google Patents

自動車用制御システム及び電子制御ユニット Download PDF

Info

Publication number
JP2012165033A
JP2012165033A JP2009140890A JP2009140890A JP2012165033A JP 2012165033 A JP2012165033 A JP 2012165033A JP 2009140890 A JP2009140890 A JP 2009140890A JP 2009140890 A JP2009140890 A JP 2009140890A JP 2012165033 A JP2012165033 A JP 2012165033A
Authority
JP
Japan
Prior art keywords
data
signal
pdu
protocol
com
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2009140890A
Other languages
English (en)
Inventor
Takuya Tsujimoto
拓哉 辻本
Toshiyuki Kamimura
俊之 上村
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Renesas Electronics Corp
Original Assignee
Renesas Electronics Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Renesas Electronics Corp filed Critical Renesas Electronics Corp
Priority to JP2009140890A priority Critical patent/JP2012165033A/ja
Priority to PCT/JP2010/059841 priority patent/WO2010143686A1/ja
Publication of JP2012165033A publication Critical patent/JP2012165033A/ja
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level

Abstract

【課題】自動車用ソフトウェアによる抽象化に伴う処理速度の低下を、専用のハードウェア及び自動車用ソフトウェアに特化したアルゴリズムを用いることで、処理速度の向上を図る手段を提供する。
【解決手段】CPU2−1に並存する形でCOM−ACC(COMアクセラレータ)2−5を設ける。該CPU2−1で動作するプロトコルスタックはPDU及びPDUIDを抽出する。抽出したPDU及びPDUIDはCOM−ACC2−5に送出された後、COM−ACC2−5がPDUの更新判断を行う。
【選択図】図3

Description

本発明は、自動車用伝送アーキテクチャに関するAUTOSAR(登録商標)仕様に準拠した自動車用のソフトウェアコンポーネント、特にハードウェアアクセラレータを併用することで処理負荷の軽減を図る手段に関する。
AUTOSAR(登録商標)(AUTomotive pen ystem ARchitecture)は自動車用伝送アーキテクチャに関するオープンなデファクトスタンダードの策定及び成立のために協業する自動車製造業者及び自動車サプライヤーのパートナーシップならびに該パートナーシップが策定する仕様群である。AUTOSAR(登録商標)は、各種の自動車用のソフトウェアコンポーネントを各種定義し、またそれらのソフトウェアコンポーネント間で用いるインターフェースを定義することで、自動車用ソフトウェアの再利用性、汎用性を確保することを目的に活動を行っている。
AUTOSAR(登録商標)はECU(電子制御ユニット)を単位としてソフトウェアを構成することを基本コンセプトとしている。ECU間は抽象的なVFB(Virtual Functional Bas:仮想機能バス)で接続され、実装上のハードウェアと切り離した形でシステムの初期検討が可能なようになっている。実装に際しては、VFBはCAN(Control Area Network)やFlexRayといったより具体的なハードウェアを想定して開発を行う。その際にも、CANドライバやFlexRayドライバといった標準コンポーネントによってハードウェア(特にCPU)が相違しても上位層の再利用性を確保することが想定されている。従って、CANやFlexRayと言ったハードウェアを想定した規格と分離した形でデータの送受信を行う必要に迫られる。AUTOSAR(登録商標)においてはPDU(Protocol Data Unit)がこれに当たる。
PDUは上位層であるアプリケーションソフトウェアで利用される各種データの最小単位であるシグナルをECU間で送受信するための論理的なデータコンテナである。PDUは8バイト(=64ビット)幅のデータである。図1はECU間でのPDUの取り扱いを表す概念図である。
この図においては、送信側ECU1と受信側ECU2がCAN3を介して通信を行うことを想定する。送信側ECU1はPDUに適切なヘッダ、フッダを添付したパケット4をCAN3経由で受信側ECU2に送信する。受信側ECU2のCANIP2−2は受信したパケット4からヘッダ及びフッダを切り離し必要な処理を行う。受信側ECU2内のCPU2−1はヘッダ、フッダを切り離したPDUからシグナルの分離、フィルタ処理を行うこととなる。
ここで、フィルタ処理とは、特定の状態にメッセージの値が合致しないときにメッセージフィルタによって受信したメッセージを無視することをいう。
これらの一連の処理ついてはAUTOSAR(登録商標) Specification of CAN Interface(非特許文献1)、AUTOSAR(登録商標) Specification of CAN Driver(非特許文献2)、Specification of CAN Communication(非特許文献3)などで規定されている。
AUTOSAR(登録商標) Specification of CAN Interface v3.0.3 AUTOSAR(登録商標) Specification of CAN Driver v2.2.3 AUTOSAR(登録商標) Specification of CAN Communication v3.0.3
これらAUTOSAR(登録商標)の仕様では、自動車用ソフトウェアの再利用性、汎用性を確保する、という目的から、ハードウェアへの依存は制限されている。
しかし、パーソナルコンピュータの分野でもそうであったように、ソフトウェアによる抽象化は処理工程、処理時間の増大を招かざるを得ない。これに対して、パーソナルコンピュータの分野では、一般的な処理を行うCPU(中央処理装置)に対して、特定の処理に特化したアクセラレータチップを並存させ、上記のような抽象化された処理を高速に処理する手段が考えられている。
一方、パーソナルコンピュータと異なり、自動車には特有な問題が多く存在する。すなわち、パーソナルコンピュータでは、送受信の対象となるのは、高位のアプリケーション層に位置するアプリケーションで取り扱われるデータがほとんどである。これに対し、自動車用ソフトウェアにおいては、自動車の状態を表す短いデータ長を表すデータがやり取りされることが多い、といった具合である。
本発明の目的は、自動車用ソフトウェアによる抽象化に伴う処理速度の低下を、専用のハードウェア及び自動車用ソフトウェアに特化したアルゴリズムを用いることで、処理速度の向上を図る手段を提供することにある。
本発明の前記並びにその他の目的と新規な特徴は、本明細書の記述及び添付図面から明らかになるであろう。
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、次の通りである。
本発明の代表的な実施の形態に関わる自動車用制御システムは、1又は2以上のシグナルを有するプロトコルデータユニットを含むデータフレームを受信する第1のハードウェアと、第1のハードウェアを接続しデータフレームの伝達に用いられる仮想機能バスと、を有し、第1のハードウェアは、仮想機能バス経由で受信したデータフレームからプロトコルデータユニット及びプロトコルデータユニットのデータフォーマットを識別するプロトコルデータユニットIDを抽出するプロトコルスタックを実行し、プロトコルスタックは、1又は2以上のシグナルの更新の有無の判定をプロトコルデータユニットへの一度の処理で実行することを特徴とする。
本発明の代表的な実施の形態に関わる電子制御ユニットは、CPUと、仮想機能バスインターフェースと、アクセラレータと、を有し、仮想機能バスインターフェースを介してプロトコルデータユニットを含むデータフレームを受信し、CPUは受信したデータフレームからプロトコルデータユニット及びプロトコルデータユニットのデータフォーマットを識別するプロトコルデータユニットIDを抽出するプロトコルスタックを実行し、CPUは、プロトコルデータユニット及びプロトコルデータユニットIDをアクセラレータに送信し、アクセラレータがシグナルの更新の有無の判定及びシグナルの更新を実行することを特徴とする。
この電子制御ユニットにおいて、アクセラレータは、プロトコルデータユニットに含まれるアップデートビットの判定と、プロトコルデータユニット内の各シグナルに設定されたアルゴリズムに従い実行されたフィルタリング処理の判定結果から、過去に処理したプロトコルデータユニットの値を更新するデータ更新用マスクを作成することを特徴としてもよい。
また、この電子制御ユニットにおいて、アクセラレータは、データ更新用マスクを用い、データの更新があったシグナルを抽出し、プロトコルスタックに前記データの更新があったシグナルを出力することを特徴としてもよい。
この電子制御ユニットにおいて、プロトコルスタックは、受信した前記データの更新があったシグナルを用いてプロトコルデータユニットを更新することを特徴としてもよい。
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下の通りである。
本発明の代表的な実施の形態に関わるCOMアクセラレータ並びにそれに対応するCOMソフトウェアを採用することで、AUTOSAR(登録商標)で規定するAUTOSAR(登録商標)COMの一定の処理の動作単位をPDU単位にすることができる。これにより、従来シグナル毎に反復処理を求められたシグナル更新の判定を一度に行うことができるという論理的な処理工数の低減、及びハードウェア処理による処理工数の低減を図ることが可能となる。
ECU間でのPDUの取り扱いを表す概念図である。 従来のAUTOSAR(登録商標)の各種ソフトウェアを動作させるためのハードウェアの構成を表すブロック図である。 本発明に関わるハードウェアの構成を表すブロック図である。 一般的なAUTOSAR(登録商標)用の通信用プロトコルスタックの構成を表す概念図である。 COM−ACC内のフィルタ回路を8ビット幅で表した概念図である。 シグナル抽出処理におけるフィルタ処理を説明するためのフローチャートである。 PDU受信時のCOMソフトウェアとCOM−ACCとの処理の分担についての概念図である。 本発明に関わるデータ更新用マスク生成回路の構成を表す概念図である。 本発明に関わる受信フラグデータの圧縮回路の一部を表す回路図である。 図9の圧縮回路の動作を説明するための図である。 COM−ACC内のシグナル挿入抽出回路におけるこのシグナル抽出処理の手順を表す概念図である。 シグナル送信時のCOMソフトウェアとCOM−ACCとの処理の分担についての概念図である。 シグナル挿入抽出回路でのシグナル挿入処理の手順を表す概念図である。 アップデートビットの判定方法及び対応するシグナルへの結果の反映方法の概念図である。 COM−ACCの概略構成を示すブロック図である。
以下、本発明の実施の形態について図を用いて説明する。
(第1の実施の形態)
図2は従来のAUTOSAR(登録商標)の各種ソフトウェアを動作させるための受信側ECU2の構成を表すブロック図である。図3は本発明に関わる受信側ECU2の構成を表すブロック図である。なお、これらは説明用の図面であるので、I/O等の回路等は省略している。
従来のAUTOSAR(登録商標)用の受信側ECU2はCPU2−1、CANIP2−2、RAM2−3、ROM2−4を含んで構成される。
本発明の実施の形態はCANによる通信にて構成されているが、他の通信プロトコルであるFlexRay、Eather等での利用も想定されている。
CPU2−1はAUTOSAR(登録商標)の規定する各種仕様に従ったソフトウェアを動作させるためのCPUである。自動車には数多くの制御対象となるハードウェアが存在する。そしてそれらのハードウェアの制御には、それぞれにCPUを用意する必要がある。しかし、自動車のモデルチェンジは4年以上であり、CPU等の電子部品の製造期間と相違することが多々ある。また、自動車のマイナーチェンジ時に新たな機能を追加するなどの理由により異なるCPUを利用しなければならなくなった時に、そのCPUの変更に迅速に対応することができるようにするのがAUTOSAR(登録商標)の目的である。
CANIP2−2は、CANバス対応の通信ハードウェアである。CANIP2−2とCPU2−1は図示しないブリッジチップ等を介して接続されている。
RAM2−3は、CPU2−1が動作する際の一時記憶領域として用いられる記憶媒体である。
ROM2−4は、CPU2−1で動作させるソフトウェアを記録するための不揮発性の記録媒体である。
CAN3はVFB(仮想機能バス)の一種である。
これに対し、本発明のハードウェアはCOM−ACC2−5が追加されている点が従来の物と相違する。
COM−ACC(COMアクセラレータ)2−5は、CPU2−1で処理すべきAUTOSAR COMソフトウェアのうち、所定の処理を専用に担当するためのアクセラレータチップである。このCOM−ACC2−5での処理が本発明の特徴となる。
図4は一般的なAUTOSAR(登録商標)用の通信用プロトコルスタックの構成を表す概念図である。
ハードウェアであるCANIP2−2を除くと、CANドライバソフトウェア102、CANインターフェースソフトウェア103、PDUルータソフトウェア104、COMソフトウェア105を含んで構成される。
CANドライバソフトウェア102は、CANIP2−2を直接制御し、PDUデータ及びCANプロトコルで規定されているデータパケット識別用のIDをCANIP2−2が管理するデータ保存領域から取得し、データの取得を上位のCANインターフェースソフトウェア103へ送信するためのソフトウェアである。
CANインターフェースソフトウェア103は、CANドライバソフトウェア102によって検出され処理されたイベントが送信される。またPDUルータソフトウェア104などの上位層からCANドライバソフトウェア102のサービスへのアクセス手段を提供する。CANインターフェースソフトウェア103を介することで、上位のモジュール(COMソフトウェア105など)は複数の異なるCANハードウェアデバイスの管理に単一のインターフェースを用いることが可能となる。
PDUルータソフトウェア104は、モジュール間での(I)PDUユニット(Interaction Layer Protocol Data Unit:中間層プロトコルデータユニット)ルーティングサービスを提供するモジュールである。
COMソフトウェア105は、上位のランタイム環境に対して、PDUルータソフトウェア104から送信されるPDUに対し適切な処置(例えばビッグエンディアンとリトルエンディアンの変換など)を行った後、PDU由来のデータ(例えばPDUに内包されるシグナル)を用いるランタイム環境に送信可能なようにするモジュールである。パソコンなどの技術分野では、送られたデータは全て上位層に送られることが多い。しかし自動車の場合は、このCOMソフトウェア105で送られたデータに変化があったか否かを判定し、変化があったときもしくは、PDUに内包されるシグナルの値が特定の条件を満たしている場合のみ図示しない上位のランタイム環境(COMソフトウェア105経由で信号の送受信を行うソフトウェア)に送信される処理を行う。これによりCPU2−1の負荷を減少させる。
図15はCOM−ACC2−5の概略構成を示す。COM−ACC2−5は、フィルタ回路、マスク生成回路、受信フラグデータ圧縮回路、シグナル挿入抽出回路、アップデートビット生成検出回路からなる。実線は受信したPDUからのシグナル抽出処理、破線は送信用の新たなPDUの生成処理でのデータの流れを示す。
それぞれの回路で処理されたデータは、PDUを下位へ送信する場合のモードを決定する送信モードコンディションTMC(Transmission Mode Condition)、更新されたシグナルを示す受信フラグ、送信用に新たに生成されたPDUに保存する送信PDUバッファ、更新されたシグナルを保存するシグナルバッファ2−6へ格納される。
COM−ACC2−5は、受信したPDUに含まれるシグナルの抽出処理においては、COMソフトウェア105からPDUと当該PDUを弁別するためのPDUIDが供給され、COMソフトウェア105からの起動信号によりフィルタリング処理を開始する。COM−ACC2−5は、フィルタリング処理によりCOMソフトウェア105において処理すべきシグナルをシグナルバッファに格納した後、CPU2−1に割り込み等もしくは受信フラグによる通知を行う。
また、COM−ACC2−5は他のECUに送信するためのPDUを生成する。このPDU生成処理においては、COMソフトウェア105から他のECUに送信するためのシグナルと生成するPDUを示すPDUIDを供給され、COMソフトウェア105からの起動信号によりPDU生成処理を開始する。COM−ACC2−5は、生成したPDUをPDU送信バッファに格納した後、CPU2−1に割り込み等による通知を行う。
フィルタ回路、マスク生成回路、受信フラグ回路、シグナル挿入抽出回路、アップデートビット生成検出回路のそれぞれの回路動作については、以下に説明する。
(シグナル抽出処理)
以下、別のECUから受信したPDUに含まれるシグナルを抽出する処理について説明する。
本実施の形態では、このCOMソフトウェア105におけるフィルタ処理にCOM−ACC(COMアクセラレータ)2−5を用いることが特徴である。逆を言えば、PDUルータソフトウェア104よりも物理層側のプロトコルスタックはCAN用のものであってもFlexRay用のものであっても、VFBに関係なく適用することが可能となる。
加えて、RAM2−3の記憶領域の一部として、後述するOLDデータ(図5のOLDデータ12)を保存するシグナルバッファ2−6を有する。
このCOM−ACC2−5における処理について説明する。
図1でも述べたとおり、CANバス上を経由して送信された64ビット固定長のPDUがCOMソフトウェア105に到達する。このPDU内には1ないし64ビットの可変長データである「シグナル」が含まれている。1つのPDU内には、容量の許す限り、複数のシグナルを含めることが可能である。それぞれのシグナルのPDU内での位置は設定データとして各ECUが保持している。各シグナルはシグナルIDにより区別されている。
シグナルの有意の容量は「シグナルの種別」によって決定される。この「シグナルの種別」及び2以上のシグナルがある場合の「シグナルの順序」はPDU毎に定義されている。このように1又は2以上のシグナルを検出し、それぞれを抽出する処理をReception Filteringと仕様上定義されている。
抽出したシグナルに対して、フィルタ処理等のチェックを行う。具体的には、該信号が更新されたかなどを判断の対象とする。このフィルタ処理後、条件をクリアしたシグナルはシグナルバッファへ保存される。
これらの処理を全てのシグナルに対して行い、通知すべきものについては図示しない上位のランタイム環境に通知されることになる。
しかし、この処理には問題がある。
すなわち、PDU内のシグナルの数が増えれば、その分1つのPDUの処理に時間を要することである。特に、シグナル長が1ないし64ビットの可変長であり、シグナル毎にフィルタ処理を行う場合、シグナル毎の処理設定に時間を要する。
本発明は、このフィルタリングの遅延の解消を図るものである。そして、COM−ACC2−5はハードウェア的にこれらの処理をPDU内の前シグナルに対して一括・並行して実行する。
本発明の実施の形態では、新たにシグナル境界情報10を定義する。これによりPDU内の全てのフィルタリングを一括して実行することが可能となる。
図5はCOM−ACC2−5内のフィルタ回路を8ビット幅で表した概念図である。このフィルタ回路は、CPU2−1から供給されたPDUのPDUIDからフィルタリング処理を行う条件と必要な情報を取得し、PDUの64ビットに含まれる1以上のシグナルのフィルタリング処理を並列に実行する。
このフィルタ回路の概念図はPDUIDから取得するフィルタリング処理の条件と情報を設定するシグナル境界情報10、OLDデータ12、X/MAXデータ13、Mask/Minデータ14、フィルタアルゴリズム選択データ15、フィルタリングの処理の対象となるPDUを格納する元データ格納部11、フィルタリング処理を行う比較器16とフィルタアルゴリズム選択回路17、及びフィルタリング処理結果を格納するフィルタ演算結果出力領域18を含む。なお、本図の各データにおいては、一番左が第1ビットであり、一番右が第8ビットであるとする。
シグナル境界情報10は、同一のPDUに含まれる各シグナルの境界点(各シグナルのMSB)に識別用のデータがセットされた64ビットのデータである。このシグナル境界情報により、シグナル毎に次のビットに接続する比較結果の制御を行っている。
PDU中には複数のシグナルが含まれるのは既述の通りである。シグナル境界情報10では各シグナルの最上位のビットを「1」にすることで、その境界を表す。
元データ格納部11は、今回の処理に関わるPDUの値を格納する記憶領域である。
OLDデータ12は前回受信処理を行って、シグナルデータを更新したPDUの値をいう。OLDデータ12の値はRAM2−3上のシグナルバッファに記録されているが、COM−ACC2−5はフィルタ処理を行う毎にRAM2−3に対応するOLDデータを読み出しにいき、一連の処理が終わりOLDデータ12の値を更新する必要があるときには、RAM上のシグナルバッファに更新値を書き込む。
X/MAXデータ13は、フィルタ処理時に用いる比較用データである。COMソフトウェア105におけるフィルタ処理は、AUTOSAR(登録商標)仕様上8つのフィルタが規定されている。X/MAXデータ13はこの8つのフィルタの特定のフィルタで用いるデータ群である。Mask/Minデータ14も同様であり、この8つのフィルタの特定のフィルタで用いるデータ群である。なお、XとMAX、MaskとMinは同時に用いることがない。このため、X/MAXデータ13及びMask/Minデータ14は1つのデータ領域を共用することができる。
フィルタアルゴリズム選択データ15は上述のAUTOSAR(登録商標)仕様の8つのフィルタのいずれを用いるかを決定するデータである。フィルタアルゴリズム選択回路17は、このフィルタアルゴリズム選択データ15を用いて動作させるフィルタアルゴリズムを選択する回路である。
このフィルタアルゴリズム選択データ15はシグナル毎に設定される。また、X/MAXデータ13及びMask/Minデータ14は対応するシグナルによってデータの意味が相違することに注意する。
比較器16は上述のOLDデータ12、X/MAXデータ13、Mask/Minデータ14及び各ビットの比較結果を隣接ビットに転送するか否かを表すシグナル境界情報10によって、元データ格納部11に格納された値をフィルタ演算するための比較器である。
フィルタ演算結果出力領域18は、上位層及び次回のフィルタ処理で利用可能なようにフィルタ処理の結果(更新用のOLDデータ)を記録するためのCOMハードウェア内の記憶領域である。
次にこのフィルタ回路の動作について図6を用いて説明する。
図6はシグナル抽出処理におけるフィルタ処理を説明するためのフローチャートである。
まず、CANIP2−2がCANバス経由でPDUを含むパケットを受信する。CANIP2−2は、このパケットからヘッダ、フッダを削除した後、CPU2−1にヘッダ等削除後のPDUを送信する。
該PDUを受け取ったCPU2−1上では図4に示したプロトコルスタックを持つAUTOSAR(登録商標)基本ソフトウェアで処理を行う。すなわち、CANドライバソフトウェア102、CANインターフェースソフトウェア103、PDUルータソフトウェア104、COMソフトウェア105の順で処理がなされる。この一連の処理の間に、PDU及びPDUIDを抽出する。このPDUIDはPDUのデータフォーマットを決定する際の識別子となる。また本発明におけるシグナル境界情報10やアップデートフラグイネイブル情報31、アップデートフラグビット位置情報32(全て後述)を決定する際にもPDUIDが用いられる。
この抽出したPDU及びPDUIDをCPU2−1で動作中のCOMソフトウェア105がCOM−ACC2−5に対して送信する(ステップS1001)。
COM−ACC2−5は受け取ったPDUを元データ格納部11にセットする。また、ここで渡されたPDUIDを検索キーとして、OLDデータ12をRAMから読み出す(ステップS1002)。
PDUIDによって、PDUにいくつのシグナルが含まれているか、各シグナルがどのようなフィルタ処理を行うか判断できる。そこでCOM−ACC2−5のフィルタアルゴリズム選択回路17はPDUIDを元にフィルタアルゴリズム選択データ15、シグナル境界情報10の設定を行う(ステップS1003)。さらに、フィルタアルゴリズムに合わせて、X/MAXデータ13、Mask/Minデータ14の設定を行う(ステップS1004)。
ここまで終了したところで比較器16が元データ格納部11、OLDデータ12及び他の設定に基づきフィルタ処理を行う(ステップS1005)。
このフィルタ処理の結果はフィルタ演算結果出力領域18に格納される。このフィルタ演算結果出力領域18に格納されたフィルタ処理の結果は次回のフィルタ処理においてOLDデータとして使用される。従って、RAM上のシグナルバッファ2−6に存在するOLDデータを更新する(ステップS1006)。
このステップS1006でRAM上に存在するOLDデータを更新する際、後述する書き込み用の「データ更新用マスク」を用いる。
また、フィルタ演算結果出力領域18に格納されたフィルタ処理の結果はシグナル単位でCOMソフトウェア105に戻される(ステップS1007)。
この一連の処理において、COMソフトウェア105とCOM−ACC2−5との処理の分担について図7を用いて説明する。図7はCOMソフトウェア105とCOM−ACC2−5との処理の分担についての概念図である。
まず、PDUルータソフトウェア104からCOMソフトウェア105に対して送信されるPDU及びPDUIDをCOMソフトウェア105は受信する(#1)。COMソフトウェアは、PDUに対して所定の処理を行う。処理後のPDUデータ及びPDUIDをCOMソフトウェア105はCOM−ACC2−5に対して送信する(#2(S1001))。送信後、COMソフトウェア105はCOM−ACC2−5に対して動作トリガを発行し(#3)、COM−ACC2−5の処理を開始する。
COM−ACC2−5はRAM2−3上のシグナルバッファからOLDデータを読み出し(#4(S1002))、フィルタ処理に必要なX/MAXデータ13、Mask/Minデータ14、フィルタアルゴリズム選択データ15をROM2−4から読み出し、フィルタ処理を開始する。COM−ACC2−5はフィルタ処理、アップデートビットチェック、データ更新用マスク作成、データ更新、シグナル抽出を行う。この際、アップデートビットチェックに用いるアップデートフラグビットイネイブル情報31とアップデートフラグビット位置情報32をROM2−4などから読み出す(#5)。
データ更新用マスクを作成した場合、COM−ACC2−5はRAM2−3上のシグナルバッファのOLDデータを更新する(#6(S1006))。
COM−ACC2−5はその後、抽出したシグナルデータをCOMソフトウェア105に送信する(#7(S1007))。COMソフトウェア105は受け取ったシグナルデータを上位に通知し、図示していない上位からの問い合わせに応じ上位へ送信する。なお抽出したシグナルデータの受け渡しを、直接インターフェースを通して行うか、アドレスの番地の引渡しで行うかは設計事項である。
次に、マスク生成回路でのデータ更新用マスクの作成方法について図8を用いて説明する。図8は本発明に関わるデータ更新用マスク生成回路の構成を表す概念図である。本図の各データにおいても、一番左が第1ビットであり、一番右が第8ビットであるとする。
このデータ更新用マスク生成回路は、データとして比較結果レジスタ21、シグナル境界情報10、書き込み用マスク22、書き込み用反転マスク23、元データ格納部11、OLDデータ12、シグナルバッファ入力値24を取り扱う。
本図においては、図5と共通の入力データとして、書き込みの元になるフィルタ演算結果出力領域18のデータだけでなく、シグナル境界情報10、元データ格納部の値11、OLDデータ12も用いられる。
比較結果レジスタ21はフィルタ演算結果出力領域18のデータに対してアップデートビットチェック結果(後述)を反映させた値(例えば論理積演算結果)である。このフィルタ演算結果出力領域18のデータにアップデートビットチェック結果を反映させた値を「受信フラグデータ」と規定する。
この比較結果レジスタ21の値とシグナル境界情報10のデータを書き込み用マスク生成器19で対比する。
既述の通り、シグナル境界情報10では各シグナルの最上位のビットを「1」にすることで、その境界を表す。書き込み用マスク生成器19には受信フラグデータとシグナル境界情報10のデータが入力される。該書き込み用マスク生成器19はシグナル境界情報10のシグナルの「区切り」を識別すること、及び、シグナルの対応するビットにフィルタ演算結果出力領域18に「1」がセットされているとき、出力である書き込み用マスク22の該当するシグナル(すなわちフィルタ処理をパスしたシグナル)に対応するビット全てを「1」にセットすることを特徴とする。
書き込み用マスク生成器19は、フィルタ処理をパスしたシグナルのビット全てを「1」に、フィルタ処理をパスしなかったシグナルのビットを全て「0」として書き込み用マスク22に出力する。図8では比較結果レジスタ21の第3ビット及び第5ビットで「1」が立っている。従って、書き込み用マスク22は16進数表記で「3F」となる。
書き込み用反転マスク23は書き込み用マスク22の出力を反転させたものである。従って、上述の例では書き込み用反転マスク23は16進数表記で「E0」となる。
その後、書き込み用マスク22と書き込み用反転マスク23を用いて、シグナルバッファ入力値生成回路20がシグナルバッファ入力値24を導出する。
シグナルバッファ入力値生成回路20は、このシグナルバッファ入力値24を生成するための論理回路である。すなわち、書き込み用マスク22と元データ格納部11の値の論理積で元データ格納部11の値のうちフィルタをパスしたシグナルデータのみを残し、他のシグナルのビットを全て「0」にする。
また、書き込み用反転マスク23とOLDデータ12の論理積でOLDデータ12のうち上書きされる部分のみを「0」にクリアし、残りのシグナルのビットはそのままの状態に維持する。
そして、書き込み用マスク22及び書き込み用反転マスク23に関する上記論理演算の結果の論理和をとることで、シグナルバッファ入力値24を生成する。このシグナルバッファ入力値24がデータ更新用マスクであり、図7のOLDデータ更新(#6)に用いる値である。すなわちRAM2−3上のシグナルバッファ2−6に、このシグナルバッファ入力値24が書き込まれることとなる。
次に、この受信フラグデータの格納について検討する。
既述の通り、受信フラグデータはフィルタ演算結果出力領域18のデータとアップデートビットチェック結果の論理積をとった値である。この受信フラグデータは最大64ビットのデータであり、COM−ACC2−5内で受信フラグデータをこのままの形で取り扱うと、受信フラグデータの取り扱いが複雑となり、メモリを多く消費する。そこで、COM−ACC2−5内で必要な受信フラグデータのみを圧縮する必要がある。
この受信フラグデータの圧縮に際して、シグナル境界情報10を用いる。すなわち、シグナル境界情報10中で「1」が立っているビットのみが受信フラグデータで変化する可能性のあるビットである。逆を言えば、シグナル境界情報10中で「1」が立っているビットのみを取り扱いの対象として、他のビットを削除すれば必要な受信フラグデータのみを圧縮することが可能となる。
図9は本発明に関わる受信フラグデータの圧縮回路の一部を表す回路図である。また図10はこの図9の圧縮回路の動作を説明するための8ビット分の概念図である。図10であげられている「10000010」という2進数のデータは8ビットの受信フラグデータである。また、この受信フラグデータとの対比の対象となるシグナル境界情報の値は「10010010」である。
図9にあらわす回路を図10の斜線の升目の様に8段43個の階段状に構成する。このように構成することで、右端から順にシグナル境界情報の値と受信フラグデータの値のANDを取って左端を検出する。「1」が埋まっていなければ、一段上の左となりから値を取得し、「1」が埋まっていれば「1」を選択データ分の段数重ねて実行する。このようにすれば、シグナル境界情報のうち1がセットされている数だけ右詰で1が埋まる。
このビットの動きにフィルタの結果を連動させると、フィルタの結果が右詰でセットされる。
次にCOM−ACC2−5におけるシグナル抽出処理について説明する。
図7でも述べたとおり、フィルタ処理後COM−ACC2−5は受信フラグデータを得る。ここからシグナルデータを抽出するのがここで述べるシグナル挿入抽出回路でのシグナル抽出処理である。
図11はCOM−ACC2−5におけるこのシグナル抽出処理の手順を表す概念図である。
まず、受信フラグデータ中の取得を欲するシグナルの右端をPDUの右端までシフトさせる(図11(a))。
その後、PDUの右端から取得を欲するシグナルのデータ長だけ「1」を挿入し、他のビットを「0」としたマスクデータを作成する(図11(b))。
この図11(a)のビットシフト後のPDUデータと、図11(b)のマスクデータの論理積を取る(図11(c))。これにより、取得を欲するシグナルのみを得ることが可能になる(図11(d))。
これとは逆に、COMソフトウェア105は、複数のシグナルを内包するPDUデータを構成する場合がある。すなわち、COMソフトウェア105より物理層に近いモジュール(例えばPDUルータソフトウェア104)に送信する場合である。この際、COMソフトウェア105によるシグナル挿入処理については後述するPDU生成処理で説明する。
最後にアップデートビットのチェックについて説明する。
このアップデートビットのチェックは、マスク作成回路の比較結果レジスタ21の値を導出するためのアップデートチェック結果を求める回路である。
アップデートビットはPDU内の任意の位置に設定可能なシグナルの更新情報である。アップデートビットはPDUの送信元である別のECUがセットする。
PDU内には送信側で更新したシグナル、更新しなかったシグナルが混在する場合がある。この際、更新されなかったシグナルについては受信側での利用価値が無い。従って、COMソフトウェア105ではこのような更新されていないシグナルの処理は行わない。
従来は、COMソフトウェア105が、反復してPDUデータからシグナルを切り出し、アップデートビットによりその変更の有無を判定し、アップデートビットが変更されていることを示すシグナルに対してフィルタ処理を行っていた。しかし、本実施の形態では、PDU単位での一括フィルタ処理を行うため、更新されていないシグナルのフィルタ処理を行わない、という判断はできない。そこで、受信したシグナルは全てフィルタ処理し、フィルタ及びアップデートビットがセットされているシグナルのみCOMソフトウェア105で処理を行うために送信する。さらにCOMソフトウェア105で処理を行ったシグナルのOLDデータを次のフィルタ処理で用いるために更新するために、各シグナルのフィルタ結果とアップデートビットのチェック結果の論理積を取った情報でマスクを作成し、OLDデータの更新を行う。
このアップデートビットは、シグナル毎にアップデートビットを持つか否かを設定できる。従って、全シグナル対応してアップデートビットが設定されているわけではない。また、PDU内でのシグナルデータの位置とアップデートビットの位置に関連性が無いため、シグナル境界情報10では、チェックできない。このため、アップデートフラグイネイブル情報31とアップデートフラグビット位置情報32が必要となる。
アップデートフラグイネイブル情報31は、PDU内の各シグナルのアップデートビット設定情報の有無を表す64ビットの情報である。該シグナルのシグナル境界情報10で「1」がセットされているビットに該シグナルのアップデートフラグイネイブル情報31が格納される。アップデートフラグイネイブル情報31が「1」のシグナルについては、PDU内のいずれかの位置にアップデートフラグが存在する。
アップデートフラグビット位置情報32は、PDU内の任意の位置に設定できるアップデートビットの設定場所に関する64ビット情報である。このアップデートフラグイネイブル情報31で「1」が立っているビットであれば、対応するPDUのビットにアップデートビット自体が存在することとなる。
まとめると次のようになる。
アップデートフラグイネイブル情報31及びシグナル境界情報10の双方共に「1」が立っているシグナルは、アップデートフラグを有するシグナルに関する情報であると判断する(状況1)。
一方、シグナル境界情報10が「1」で、アップデートフラグイネイブル情報31が「0」のPDUのビットであれば、アップデートフラグを持たないシグナルに関する情報であると判断する(状況2)。
また、アップデートフラグビット位置情報32が「1」であるPDUのビットは、いずれかのシグナルのアップデートフラグビットであると認識される。
なお、いずれのアップデートフラグビットがいずれのシグナルに対応するかを判定する手段については設計事項であり、本明細書では限定しない。例えば、アップデートフラグビットを有するシグナルの並び順と、アップデートフラグビットの並び順をかならず一致させるなどの解決方法が考えられる。
これらのアップデートフラグイネイブル情報31及びアップデートフラグビット位置情報32はPDUIDを参照してCOM−ACC2−5がRAM2−3もしくはROM2−4から読み出すこととなる。
本回路においては、PDU内のアップデートフラグビット位置情報32が指し示す位置のデータが「1」であればアップデートされていると判断する。これらのアップデートビット情報を集め、フィルタの結果と論理積を取るため、アップデートフラグビット位置情報32をシグナル境界情報10の位置に反映させたアップデートフラグチェック結果33を生成する(図14)。
その結果、1)フィルタ演算結果(フィルタ演算結果出力領域18に格納されている値)が「1」かつアップデートビットが設定され(状況1)、該シグナルに対応するアップデートフラグビットが「1」のとき、もしくは2)シグナル境界情報10が「1」で、アップデートフラグイネイブル情報31が「0」のとき(状況2)は更新されたシグナルであると判断する。そしてこれらをOLDデータ12の上書きの対象とし、既述の通り、データ更新用マスク生成回路の前段階で用いられる(比較結果レジスタ21の説明を参照)。
以上のような構成を取ることで、PDUデータ中に含まれるシグナル単位で処理を繰り返すことなく、PDUデータで一括してフィルタ処理、更新用マスクの作成、及び一時記憶への上書きを行うことが可能となる。
(PDU生成処理)
図12はPDU生成処理におけるCOMソフトウェア105とCOM−ACC2−5との処理の分担について説明する概念図である。
まず、COMソフトウェア105が他のECUに送信するシグナル(1以上)を上位アプリケーションより受け取る。COMソフトウェア105は受け取ったシグナルと生成すべきPDUを示すPDUIDもしくはPDUIDが関連付けされたシグナルIDをCOM−ACC2−5に対して送信する(#8(S2001))。送信後、COMソフトウェア105はCOM−ACC2−5に対して動作トリガを発行し(#9)、COM−ACC2−5の処理を開始する。
COM−ACC2−5はRAM2−3上のシグナルバッファからPDUIDに対応するOLDデータを読み出す(#10(S2002))。送信用の新たなPDUとして、シグナル挿入抽出回路を用いて、新たに生成されたシグナルが設定されるべき場所に設定する。また、新たに生成されたシグナルのアップデートビットを、アップデートビット生成抽出回路を用いて、送信用の新たなPDUに設定する。送信用の新たなPDUのうち、新たに生成されたシグナルではないシグナルが設定される場所にはRAM2−3から読み出したOLDデータを設定すればよい。
新たに生成された送信用のPDUに対して、他のECUへの送信タイミングを決定する等のフィルタ処理を図5のフィルタ回路を用いて行った後、シグナル・PDU送信バッファにフィルタ処理後の送信用のPDUを設定してCOMソフトウェア105に送信する(#11(S2007))。COMソフトウェア105は生成した送信用のPDUを他のECUへ送信するために、PDUルータソフトウェア104、CANインターフェースソフトウェア103、CANドライバソフトウェア102、CANIP2−2を経由してCANネットワークに出力する(#12)。
図13はシグナル挿入抽出回路でのシグナル挿入処理の手順を表す概念図である。
まず、COM−ACC2−5から受信したシグナルを所定のNビットシフトレジスタへ下位詰めで格納する。その際、該受信したシグナル以外のビットには「0」をセットする。その後、そのNビットシフトレジスタを、該シグナルを挿入する所定のビット数だけ左シフトする(図13(a))。
次に、図13(a)のシフト後のNビットシフトレジスタに対応して、シグナルデータ部が「0」で他のビットが「1」のマスクデータを作成する(図13(b))。
その後、該受信したシグナルを挿入するPDUとNビットシフトレジスタを、図13(b)のマスクデータを用いてマージする(図13(c))。
これによりNビットシフトレジスタに格納された受信したシグナルが挿入されたPDUの作成が完了する(図13(d))。
以上、PDUからのシグナル抽出処理と送信用のPDUの生成処理とにおいて、共通する回路を用いて処理を行うことが可能となる。
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更が可能であることは言うまでもない。
本発明は、AUTOSAR(登録商標)のCOMソフトウェア並びに該COMソフトウェアを有するECUの負荷軽減を目的とする。
1…送信側ECU、2…受信側ECU、
2−1…CPU、2−2…CANIP、2−3…RAM、2−4…ROM、
2−5…COM−ACC(COMアクセラレータ)、2−6…シグナルバッファ、
3…CAN、10…シグナル境界情報、11…元データ格納部、12…OLDデータ、
13…X/MAXデータ、14…Mask/Minデータ、
15…フィルタアルゴリズム選択データ、16…比較器、
17…フィルタアルゴリズム選択回路、18…フィルタ演算結果出力領域、
19…書き込み用マスク生成器、20…シグナルバッファ入力値生成回路、
21…比較結果レジスタ、22…書き込み用マスク、
23…書き込み用反転マスク、24…シグナルバッファ入力値、
102…CANドライバソフトウェア、
103…CANインターフェースソフトウェア、
104…PDUルータソフトウェア、105…COMソフトウェア。

Claims (6)

  1. 1又は2以上のシグナルを有するプロトコルデータユニットを含むデータフレームを受信する第1のハードウェアと、前記第1のハードウェアを接続し前記データフレームの伝達に用いられる仮想機能バスと、を有する自動車用制御システムであって、
    前記第1のハードウェアは、前記仮想機能バス経由で受信した前記データフレームからプロトコルデータユニット及び前記プロトコルデータユニットのデータフォーマットを識別するプロトコルデータユニットIDを抽出するプロトコルスタックを実行し、
    前記プロトコルスタックは、前記1又は2以上のシグナルの更新の有無をプロトコルデータユニットへの一度の処理で実行することを特徴とする自動車用制御システム。
  2. CPUと、仮想機能バスインターフェースと、アクセラレータと、を有し、前記仮想機能バスインターフェースを介してプロトコルデータユニットを含むデータフレームを受信する電子制御ユニットであって、
    前記CPUは受信した前記データフレームから前記プロトコルデータユニット及び前記プロトコルデータユニットのデータフォーマットを識別するプロトコルデータユニットIDを抽出するプロトコルスタックを実行し、
    前記プロトコルスタックによるシグナルの更新の有無の判定を行う前記CPUは、前記プロトコルデータユニット及び前記プロトコルデータユニットIDを前記アクセラレータに送信し、前記アクセラレータがシグナルの更新の有無の判定を実行することを特徴とする電子制御ユニット。
  3. 請求項2に記載の電子制御ユニットにおいて、
    前記アクセラレータは、
    前記プロトコルデータユニットに含まれるアップデートビットの判定と、
    前記プロトコルデータユニットの値と前記プロトコルデータユニットに内在する上位モジュールで利用されるデータの最小単位であるシグナル毎に設定されたフィルタ条件に従い判定を実行し前記アップデートビットの判定の結果と、前記プロトコルデータユニットのフィルタ判定の結果から、過去に処理した前記プロトコルデータユニットの値を更新するデータ更新用マスクを作成することを特徴とする電子制御ユニット。
  4. 請求項3に記載の電子制御ユニットにおいて、
    前記アクセラレータは、
    前記データ更新用マスクからデータの更新があったシグナルを抽出し、
    前記プロトコルスタックに前記データの更新があったシグナルを出力することを特徴とする電子制御ユニット。
  5. 請求項4に記載の電子制御ユニットにおいて、
    前記プロトコルスタックは、受信した前記データの更新があったシグナルを用いて前記プロトコルデータユニットを更新することを特徴とする電子制御ユニット。
  6. 請求項2に記載の電子制御ユニットにおいて、
    前記アクセラレータは通信経路を介して外部に接続される他の電子制御ユニットへ送信するためのデータフレームの生成において使用されることを特徴とする電子制御ユニット。
JP2009140890A 2009-06-12 2009-06-12 自動車用制御システム及び電子制御ユニット Pending JP2012165033A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2009140890A JP2012165033A (ja) 2009-06-12 2009-06-12 自動車用制御システム及び電子制御ユニット
PCT/JP2010/059841 WO2010143686A1 (ja) 2009-06-12 2010-06-10 自動車用制御システム及び電子制御ユニット

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2009140890A JP2012165033A (ja) 2009-06-12 2009-06-12 自動車用制御システム及び電子制御ユニット

Publications (1)

Publication Number Publication Date
JP2012165033A true JP2012165033A (ja) 2012-08-30

Family

ID=43308941

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009140890A Pending JP2012165033A (ja) 2009-06-12 2009-06-12 自動車用制御システム及び電子制御ユニット

Country Status (2)

Country Link
JP (1) JP2012165033A (ja)
WO (1) WO2010143686A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103576630A (zh) * 2012-08-06 2014-02-12 漳州鑫美达汽车零部件有限公司 一种基于can总线的车辆电器控制系统及其应用
CN104076716A (zh) * 2014-07-03 2014-10-01 湖北航天技术研究院特种车辆技术中心 一种车辆状态监测与综合显示系统
CN110495156A (zh) * 2017-04-04 2019-11-22 标致雪铁龙汽车股份有限公司 用于通过以太网元件管理以太网/ip网络的管理装置
WO2022004184A1 (ja) * 2020-07-01 2022-01-06 日立Astemo株式会社 電子制御装置

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113641406B (zh) * 2021-10-14 2022-02-08 阿里云计算有限公司 一种硬件管理方法和装置
US11943140B2 (en) 2021-12-16 2024-03-26 Nio Technology (Anhui) Co., Ltd. Context-based PDU identifier provisioning
CN114326674A (zh) * 2021-12-29 2022-04-12 深圳市元征科技股份有限公司 Ecu刷写的方法、装置、电子设备及存储介质

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3442633B2 (ja) * 1997-11-27 2003-09-02 矢崎総業株式会社 車両多重伝送装置
JP2006256457A (ja) * 2005-03-16 2006-09-28 Fujitsu Ten Ltd 車載データ管理装置、及び、車両情報供給システム

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103576630A (zh) * 2012-08-06 2014-02-12 漳州鑫美达汽车零部件有限公司 一种基于can总线的车辆电器控制系统及其应用
CN104076716A (zh) * 2014-07-03 2014-10-01 湖北航天技术研究院特种车辆技术中心 一种车辆状态监测与综合显示系统
CN110495156A (zh) * 2017-04-04 2019-11-22 标致雪铁龙汽车股份有限公司 用于通过以太网元件管理以太网/ip网络的管理装置
CN110495156B (zh) * 2017-04-04 2022-04-29 标致雪铁龙汽车股份有限公司 用于通过以太网元件管理以太网/ip网络的管理装置
WO2022004184A1 (ja) * 2020-07-01 2022-01-06 日立Astemo株式会社 電子制御装置
JP7454048B2 (ja) 2020-07-01 2024-03-21 日立Astemo株式会社 電子制御装置

Also Published As

Publication number Publication date
WO2010143686A1 (ja) 2010-12-16

Similar Documents

Publication Publication Date Title
US11599349B2 (en) Gateway device, in-vehicle network system, and firmware update method
JP2012165033A (ja) 自動車用制御システム及び電子制御ユニット
US20240053977A1 (en) Gateway device, in-vehicle network system, and firmware update method
CN110460573A (zh) 一种应用于汽车ecu安全升级管理系统及方法
US10698849B2 (en) Methods and apparatus for augmented bus numbering
US7827343B2 (en) Method and apparatus for providing accelerator support in a bus protocol
JP2013534680A (ja) Pciエクスプレス適合デバイスの資源にアクセスするためのシステム及び方法
CN115102780B (zh) 数据传输方法、相关装置、系统及计算机可读存储介质
US7036050B2 (en) Highly reliable distributed system
KR101612825B1 (ko) Can 컨트롤러, 차량 내부 통신을 위한 게이트웨이 및 그 제어 방법
CN112636987A (zh) 一种区块链的跨链网关确定方法、系统及终端设备
JP2006253922A (ja) ゲートウェイ装置及びゲートウェイ装置におけるデータ転送方法
CN114915499B (zh) 数据传输方法、相关装置、系统及计算机可读存储介质
US8041868B2 (en) Bus relay device and bus control system including bus masters, interconnect section, and bridge section
CN114925386B (zh) 数据处理方法、计算机设备、数据处理系统及存储介质
US20120072637A1 (en) I/o bridge device, response-reporting method, and program
CN115878212A (zh) 基于Autosar架构的控制器软件路由信息配置文件自动生成方法及装置
CN110795405B (zh) 一种分片数据还原方法、终端设备及存储介质
CN114756585A (zh) 车辆数据获取方法、装置、电子设备及存储介质
CN115687223A (zh) 用于嵌入式设备串口通信的方法及装置、嵌入式设备、存储介质
JP4952048B2 (ja) ネットワークシステム、情報自動修復方法、及びノード
CN111865794A (zh) 一种逻辑端口的关联方法、系统、设备及数据传输系统
JP2003280902A (ja) マイコンロジック開発システム及びそのプログラム
CN113141300B (zh) 用于机动车辆的传送数据帧的通信网关
US20230179443A1 (en) Gateway and method of processing can message