JP2018093398A

JP2018093398A - 制御装置

Info

Publication number: JP2018093398A
Application number: JP2016236154A
Authority: JP
Inventors: 坂本　浩; Hiroshi Sakamoto; 浩坂本
Original assignee: Denso Corp
Current assignee: Denso Corp
Priority date: 2016-12-05
Filing date: 2016-12-05
Publication date: 2018-06-14
Anticipated expiration: 2036-12-05
Also published as: US20180158503A1; JP6772797B2; US10403350B2

Abstract

【課題】無線通信の通信チャネルを変更することなく、有線通信により生じる電波が無線通信を妨害してしまうことを抑制できる制御装置を提供する。【解決手段】内部バス７を介した信号送信を行う信号送信処理と、内部バス７を介した信号送信を行わない非送信処理とを含んだ処理である混合処理の起動周期を定める起動周期情報を記憶している不揮発性メモリ４と、不揮発性メモリ４に記憶されている起動周期情報に基づいて、混合処理の実行開始タイミングを決定して、決定した実行開始タイミングから混合処理を実行するＣＰＵ６とを備える。不揮発性メモリ４に記憶されている起動周期情報を変更すれば、混合処理内で実行される信号送信処理の実行周期も変化する。よって、混合処理の起動周期から定まる周波数が無線通信の通信チャネルの周波数とならないように混合処理の起動周期を変更することで、無線通信を妨害してしまうことを抑制できる。【選択図】図１

Description

本発明は、制御装置に関し、特に、電波干渉を回避する機能を備えた制御装置に関する。

特許文献１に記載されているように、無線ＬＡＮと有線ＬＡＮとを備えているシステムでは、有線ＬＡＮでの通信時に有線ＬＡＮ用ケーブルから発生する電波により、無線ＬＡＮ通信が妨害されるおそれがあることが知られている。そこで、特許文献１では、有線ＬＡＮ用ケーブルが接続されたことを検出した場合には、無線ＬＡＮの通信チャネルを切り替えている。

特開２０１６−２９７６８号公報

無線ＬＡＮと有線ＬＡＮに限られず、バスすなわち信号線から放射される電波が、無線通信のアンテナに受信されてしまう場合に、その電波により無線通信が妨害されてしまう恐れがある。

特許文献１に記載の技術を用いる場合、無線通信が妨害されないようにするためには、無線通信の通信チャネルを変更しなければならない。

本発明は、この事情に基づいて成されたものであり、その目的とするところは、無線通信の通信チャネルを変更することなく、有線通信により生じる電波が無線通信を妨害してしまうことを抑制できる制御装置を提供することにある。

上記目的は独立請求項に記載の特徴の組み合わせにより達成され、また、下位請求項は、発明の更なる有利な具体例を規定する。特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本発明の技術的範囲を限定するものではない。

上記目的を達成するための本発明は、バスを介した信号送信を行う信号送信処理と、バスを介した信号送信を行わない非送信処理とを含んだ処理である混合処理の起動周期を定める起動周期情報を記憶している書き換え可能な記憶部（４）と、
記憶部に記憶されている起動周期情報に基づいて、混合処理の実行開始タイミングを決定して、決定した実行開始タイミングから混合処理を実行する混合処理実行部（６）とを備える制御装置である。

本発明では、書き換え可能な記憶部に、混合処理の起動周期を定める起動周期情報を記憶している。つまり、本発明では、混合処理の起動周期を書き換えにより変更可能としている。混合処理の起動周期を変更すれば、混合処理内で実行される信号送信処理の実行周期も変化する。よって、混合処理の起動周期から定まる周波数が無線通信の通信チャネルの周波数とならないように混合処理の起動周期を変更することで、無線通信を妨害してしまうことを抑制できる。

また、本発明では、干渉を回避するために起動周期を設定する処理を、バスを介した信号を行う信号送信処理とするのではなく、この信号送信処理と、バスを介した信号の送信を行わない非送信処理とを含んだ混合処理全体としている。よって、信号送信処理と非送信処理に分類する必要がない。これにより、混合処理を実行するためのプログラムを異なる製品へ移植する都度、混合処理に含まれる具体的な処理を、信号送信処理と非送信処理に分類する手間を省略することができる。

さらに、本発明では、起動周期情報を記憶している記憶部が、書き換え可能な記憶部である。よって、干渉を回避すべき無線通信の周波数が異なる制御装置へ適合させる際には、記憶部に記憶された起動周期情報を変更すればよいので、干渉を回避すべき無線通信の周波数が異なる制御装置への適用も容易になる。

マイクロコントローラ１の構成を示すブロック図である。図１のＣＰＵ６が実行するタスクのタイミングチャートである。比較例における、バスアクセスを行う処理のタイミングチャートである。アイドルタスク区間にＣＰＵ６が実行する処理を示すフローチャートである。

以下、本発明の実施形態を図面に基づいて説明する。

［全体構成］
図１に示すマイクロコントローラ１は、本発明の制御装置に相当する。マイクロコントローラ１は、ＲＯＭ２、ＲＡＭ３、不揮発性メモリ４、周辺回路５、ＣＰＵ６、内部バス７、アンテナ８を備える。このマイクロコントローラ１は、たとえば、ＥＣＵ（electronic control unit）の一部要素として備えられる。

ＲＯＭ２には、ＣＰＵ６が実行するプログラムが記憶されている。ＲＡＭ３は、ＣＰＵ６がＲＯＭ２に記憶されたプログラムを実行する際にデータを一時記憶する。不揮発性メモリ４は、請求項の記憶部に相当しており、記憶しているデータを書き換え可能である。不揮発性メモリ４としては、たとえば、ＥＰＲＯＭを用いることができる。不揮発性メモリ４には、リソースをリフレッシュする処理（以下、リソースリフレッシュ処理）の起動周期を、アンテナ８を用いた無線通信に対する干渉を抑制する周期となるように適合させたカスタマイズ値が記憶されている。

周辺回路５は、たとえば、タイマ、ウォッチドッグタイマ、割り込みコントローラ、ＡＤ変換回路、ＤＡ変換回路などである。

ＣＰＵ６は、ＲＡＭ３の一時記憶機能を利用しつつ、ＲＯＭ２に記憶されているプログラムを実行する演算回路である。ＣＰＵ６は、内部バス７により、ＲＯＭ２、ＲＡＭ３、不揮発性メモリ４、周辺回路５と接続されている。ＣＰＵ６は、ＲＯＭ２に記憶されているプログラムを実行することで種々の機能を実行する。たとえば、ＣＰＵ６は、周辺回路５との間でデータの送受信を行ったり、周辺回路５に制御信号を送信して、周辺回路５のリフレッシュ処理を実行したりする。周辺回路５のリフレッシュ処理としては、たとえば、周辺回路５が備えるレジスタやバッファをリフレッシュする処理がある。

本実施形態では、ＣＰＵ６が実行する処理は、メインタスクとアイドルタスクとに区別されている。メインタスクは一定周期で開始される。メインタスクの終了後、次のメインタスクの開始タイミングまではアイドルタスク区間となる。

［タスク実行タイミングチャート］
図２に、ＣＰＵ６が実行するタスクのタイミングチャートの一例を示す。図２に示すように、本実施形態では、メインタスクの実行周期は５ｍｓである。また、図２に示すように、本実施形態では、アイドルタスク区間には、リソースリフレッシュ区間と未処理区間とが存在する。リソースリフレッシュ区間は、前述したリソースリフレッシュ処理を実行する区間である。リソースリフレッシュ処理以外の処理はメインタスクで実行する。なお、リソースは、ＣＰＵ６に接続されている要素あるいはＣＰＵ６が内部に備える要素を意味する。前者にはＲＡＭ３、周辺回路５などがあり、後者にはＣＰＵ６が備えるレジスタなどがある。リソースリフレッシュ処理は、これらリソースの初期値を再設定する処理である。

リソースに、ＣＰＵ６に接続されている要素とＣＰＵ６が内部に備える要素とがあることから、リソースリフレッシュ処理には、バスアクセスを行う処理と、バスアクセスを行わない処理とがある。バスアクセスを行う処理は、内部バス７を介して信号送信を行う処理を意味し、バスアクセスを行わない処理は、内部バス７を介した信号送信を行わない処理を意味する。なお、バスアクセスを行う処理は請求項の信号送信処理に相当し、バスアクセスを行わない処理は請求項の非送信処理に相当し、リソースリフレッシュ処理は請求項の混合処理に相当する。また、ＣＰＵ６は、混合処理に相当するリソースリフレッシュ処理を実行するので、ＣＰＵ６は請求項の混合処理実行部としての機能を備える。

アンテナ８は、マイクロコントローラ１の外部から送信される電波を受信する受信アンテナ、および、外部へ電波を送信する送信アンテナの一方または両方として機能する。アンテナ８は図示していない無線部に接続されている。この無線部は、マイクロコントローラ１が備えていてもよいし、ＥＣＵに備えられていてもよい。

前述したように、リソースリフレッシュ処理には、バスアクセスを行う処理とバスアクセスを行わない処理とがある。これらの処理は、アイドルタスクにおいて周期的に行うようになっている。周期的にリフレッシュ処理を実行することで、何らかの要因で設定値が間違った値に変化してしまったとしても、その周期経過後には、設定値を正しい値に戻すことができるので、誤動作を抑制できる。

しかし、バスアクセスを行う毎に内部バス７からはノイズが放射される。そのため、バスアクセスを行う処理を周期的に実行すると、その周期により定まる周波数のノイズが生じることになる。バスアクセスにより生じるノイズの周波数が、アンテナ８の通信周波数と同じであると、アンテナ８を用いた無線通信を妨害してしまう恐れがある。

設計段階において、バスアクセスを行う処理により生じるノイズが、アンテナ８を用いた無線通信を妨害してしまう恐れがあることが判明した場合、そのノイズが無線通信へ与える影響を軽減させるためには、バスアクセスを行う周期を変更すればよい。

［比較例］
ここで、本実施形態における、バスアクセスを行う周期の変更手段を説明する前に、比較例を説明する。リソースリフレッシュ処理には種々の具体的処理が含まれ、それら具体的処理には、前述のように、バスアクセスを行う処理とバスアクセスを行わない処理の２種類がある。そこで、バスアクセスを行う周期を変更するために、リソースリフレッシュ処理を、バスアクセスを行う処理とバスアクセスを行わない処理に分類する。以下、比較例の説明において、バスアクセスを行わない処理を実行する区間を第１リソースリフレッシュ区間とし、バスアクセスを行う処理を実行する区間を第２リソースリフレッシュ区間とする。

バスアクセスを行う周期を変更するためには、第２リソースリフレッシュ区間の周期を変更すればよいことになる。第１リソースリフレッシュ区間の実行周期に影響を与えずに、第２リソースリフレッシュ区間の周期を変更する方法として、周期的に生じる第２リソースリフレッシュ区間において毎回、バスアクセスを行う処理を実行するのではなく、次の方法が考えられる。すなわち、一部の第２リソースリフレッシュ区間のみバスアクセスを行う処理を実行し、残りの第２リソースリフレッシュ区間では、バスアクセスを行わないダミー処理を実行することが考えられる。

図３は、周期的に生じる第２リソースリフレッシュ区間のうち、５回に１回のみ、バスアクセスを行うリフレッシュ処理を実行し、残りの４回はダミー処理を実行する場合を概念的に示している。図３では、ｔ１１〜ｔ１２、ｔ１３〜ｔ１４、ｔ１５〜ｔ１６、ｔ１７〜ｔ１８ではダミー処理を実行し、ｔ１９〜ｔ２０でバスアクセスを行うリフレッシュ処理を実行する。この例では、ｔ１１〜ｔ１２、ｔ１３〜ｔ１４、ｔ１５〜ｔ１６、ｔ１７〜ｔ１８、ｔ１９〜ｔ２０で、いずれもバスアクセスを行うリフレッシュ処理を実行する場合に比較して、ノイズの周波数が１／５になる。

しかしながら、この比較例の手法を行うには、アイドルタスク区間で実行するリソースリフレッシュ処理を、バスアクセスを行う処理と、バスアクセスを行わない処理に分類しなければならない。また、マイクロコントローラ１が持つリソースが異なると、具体的なリソースリフレッシュ処理が異なる。そのため、比較例の手法を、異なるリソースを持つマイクロコントローラ１へ移植しようとすれば、改めて、アイドルタスク区間で実行するリソースリフレッシュ処理を、バスアクセスを行う処理と、バスアクセスを行わない処理に分類する必要がある。つまり、比較例の手法は、移植の度に生じる設計の手間が大きい。

［本実施形態におけるノイズ周波数変更方法］
これに対して、本実施形態では、図２に示しているように、１つのリソースリフレッシュ区間としており、バスアクセスを行う処理とバスアクセスを行わない処理を、別々の区間に区別していない。

本実施形態では、比較例のように、バスアクセスを行う処理とバスアクセスを行わない処理とに分けた上で、バスアクセスを行う処理を実行する区間の一部をダミー処理に置き換えるという手法は採用していない。本実施形態では、リソースリフレッシュ処理を実行する周期を可変にすることで、ノイズの周波数を変更している。リソースリフレッシュ処理を実行する周期を変更すれば、リソースリフレッシュ処理において実行するバスアクセスを行う処理の周期も変更される。そこで、リソースリフレッシュ処理を実行する周期を可変にすることで、ノイズの周波数を変更するのである。

［アイドルタスク区間の処理］
図４に、図２に示すアイドルタスク区間にＣＰＵ６が実行する処理を示す。図４に示す処理は、メインタスクが終了したことにより、つまり、タスクがアイドルタスクに移行したことにより開始する。なお、メインタスクは、周期的に実行を開始するが、実行時間は一定ではなく、そのときに実際に処理する内容により、メインタスクの終了時点は変動する。

ステップ（以下、ステップを省略）Ｓ１では、不揮発性メモリ４からカスタマイズ値を読み出す。続くＳ２では、カウンタ値がカスタマイズ値を超えたか否かを判断する。カウンタ値は、リソースリフレッシュ処理を開始する際にゼロになり、後述するＳ５において１ずつ増加する値である。よって、カウンタ値は、リソースリフレッシュ処理を開始してからの時間経過に対応して増加する値である。Ｓ２の判断がＹＥＳであればＳ３に進み、ＮＯであればＳ６に進む。

Ｓ３では、カウンタ値をゼロにする。Ｓ４では、リソースリフレッシュ処理を実行する。カウンタ値は、リソースリフレッシュ処理を開始してからの経過時間に対応しており、カウンタ値がカスタマイズ値を超えた場合に、リソースリフレッシュ処理を開始するので、カスタマイズ値は、リソースリフレッシュ処理の起動周期を定める情報である。つまり、カスタマイズ値は、請求項の起動周期情報に相当する。また、カウンタ値がカスタマイズ値を超えたことは、リソースリフレッシュ処理の実行開始タイミングになったことを意味する。

前述したように、リソースリフレッシュ処理は、バスアクセスを行う処理と、バスアクセスを行わない処理の２種類の処理があるが、本実施形態では、これら２種類の分類することなく、リソースリフレッシュ処理を行う。

Ｓ４で実行する具体的なリソースリフレッシュ処理の内容は、たとえば、リソースリフレッシュ処理を実行する必要がある全部のリソースに対してリソースリフレッシュ処理を実行するという内容でよい。あるいは、リソースリフレッシュ処理を実行する必要がある全部のリソースを、予め定めた順番で、１回のリソースリフレッシュ区間において一定数毎にリソースリフレッシュ処理を実行するという内容でもよい。リソースリフレッシュ処理が終了したらＳ５へ進む。Ｓ５では、カウンタ値を１増加させる。

Ｓ２の判断がＮＯの場合にはＳ６に進む。Ｓ６では、一定時間、ダミー処理を実行する。ダミー処理は、バスアクセスを行わない処理であればよい。たとえば、たとえばＮＯＰ処理をダミー処理として実行する。Ｓ６を実行した場合にもＳ５に進み、カウンタ値を１増加させる。

この図４に示す処理は、タスクがメインタスクに移行するまで繰り返し実行される。タスクがメインタスクに移った場合、カウンタ値は、そのときの値に保持される。

次に、この図４に示した処理を、図２に示したタイミングチャートに対応させて説明する。図２において、メインタスクが終了し、アイドルタスクに移行する時刻ｔ０で、図４の処理を開始して、Ｓ１、Ｓ２を実行する。図２に示した例は、前回のアイドルタスク区間において最後に図４のＳ５を実行したことにより、カウンタ値がカスタマイズ値を超えた場合の例である。したがって、ｔ０において実行するＳ２の判断はＹＥＳになり、Ｓ３、Ｓ４を実行する。よって、時刻ｔ０から、リソースリフレッシュ処理を実行する。

図２の例では、時刻ｔ１で、初回のリソースリフレッシュ処理が終了する。時刻ｔ１では、リソースリフレッシュ処理は終了し、かつ、メインタスクの起動タイミングにもなっていないので、一定時間、ダミー処理を実行する。未処理区間は、ダミー処理が繰り返されている区間を意味する。一定時間のダミー処理が終了すると、Ｓ５が実行されてカウンタ値が１増える。カウンタ値がカスタマイズ値を超えるまではＳ６のダミー処理を繰り返すので、カウンタ値がカスタマイズ値を超えるまでは未処理区間が継続する。

カウンタ値がカスタマイズ値を超えると、再びＳ３、Ｓ４を実行するので、再び、リソースリフレッシュ処理区間となる。よって、図２の時刻ｔ２で再び、リソースリフレッシュ処理を開始する。

時刻ｔ２から開始するリソースリフレッシュ区間は時刻ｔ３で終了し、時刻ｔ３から再び未処理区間となる。時刻ｔ４でカウンタ値がカスタマイズ値を超え、再びリソースリフレッシュ区間となる。時刻ｔ４から開始するリソースリフレッシュ区間は時刻ｔ５で終了し、時刻ｔ５から再び未処理区間となる。このようにして、リソースリフレッシュ区間と未処理区間を交互に繰り返すうちにメインタスクの実行タイミングになる。時刻ｔ６は、時刻ｔ０からメインタスクの実行周期が経過した時点である。この時刻ｔ６においてアイドルタスク区間は終了し、メインタスクが開始される。

［実施形態のまとめ］
以上、説明した本実施形態では、不揮発性メモリ４に、リソースリフレッシュ処理の起動周期を定める情報であるカスタマイズ値を記憶している。不揮発性メモリ４は書き換え可能であることから、本実施形態のマイクロコントローラ１は、リソースリフレッシュ処理の起動周期が変更可能である。

リソースリフレッシュ処理の起動周期を変更すれば、リソースリフレッシュ処理内で実行されるバスアクセスを行う処理の実行周期も変化する。よって、リソースリフレッシュ処理の起動周期から定まる周波数が、アンテナ８を用いた無線通信の通信チャネルの周波数とならないようにリソースリフレッシュ処理の起動周期を変更することで、無線通信を妨害してしまうことを抑制できる。

また、本実施形態では、干渉を回避するために起動周期を設定する処理を、バスアクセスを行う処理のみとするのではなく、バスアクセスを行う処理とバスアクセスを行わない処理を含めたリソースリフレッシュ処理全体としている。よって、リソースリフレッシュ処理を、バスアクセスを行う処理とバスアクセスを行わない処理に分類する必要がない。これにより、本実施形態のリソースリフレッシュ処理に関するプログラムを異なる製品へ移植する都度、リソースリフレッシュ処理に含まれる具体的な処理を、バスアクセスを行う処理とバスアクセスを行わない処理に分類する手間を省略することができる。

さらに、本実施形態では、リソースリフレッシュ処理の起動周期を定める情報であるカスタマイズ値を、書き換え可能な記憶部である不揮発性メモリ４に記憶している。よって、干渉を回避すべき無線通信の周波数が異なるマイクロコントローラへ適合させる際には、不揮発性メモリ４に記憶されたカスタマイズ値を変更すればよいので、干渉を回避すべき無線通信の周波数が異なるマイクロコントローラへの適用も容易になる。

以上、本発明の実施形態を説明したが、本発明は上述の実施形態に限定されるものではなく、次の変形例も本発明の技術的範囲に含まれ、さらに、下記以外にも要旨を逸脱しない範囲内で種々変更して実施できる。なお、以下の説明において、それまでに使用した符号と同一番号の符号を有する要素は、特に言及する場合を除き、それ以前の実施形態における同一符号の要素と同一である。また、構成の一部のみを説明している場合、構成の他の部分については先に説明した実施形態を適用できる。

＜変形例１＞
前述した実施形態では、混合処理としてリソースリフレッシュ処理を示した。しかし、混合処理は、リソースリフレッシュ処理に限定されず、バスを介した信号送信を行う処理と、バスを介した信号送信を行わない処理とを両方とも含んだ処理であればよい。

したがって、たとえば、メインタスクが、バスアクセスを行う処理とバスアクセスを行わない処理とを含んでいる場合に、メインタスクを混合処理としてもよい。メインタスクを混合処理とする場合、メインタスクの起動周期を定める起動周期情報を不揮発性メモリ４に記憶することになる。

＜変形例２＞
バスは、内部バス７に限られず、マイクロコントローラ１と外部回路とを接続する外部バスでもよい。また、バスアクセスを行う処理を、内部バス７を介して周辺回路５に信号送信する処理に限定してもよい。

＜変形例３＞
アンテナ８は、マイクロコントローラ１や、マイクロコントローラ１を含むＥＣＵに備えられている必要はなく、マイクロコントローラ１の周囲にあればよい。アンテナ８がマイクロコントローラ１の周囲にあれば、マイクロコントローラ１が実行するバスアクセス時に発生するノイズにより、アンテナ８を用いた無線通信が妨害される恐れがあるからである。

１：マイクロコントローラ２：ＲＯＭ３：ＲＡＭ４：不揮発性メモリ５：周辺回路６：ＣＰＵ（混合処理実行部）７：内部バス８：アンテナ

Claims

バスを介した信号送信を行う信号送信処理と、前記バスを介した信号送信を行わない非送信処理とを含んだ処理である混合処理の起動周期を定める起動周期情報を記憶している書き換え可能な記憶部（４）と、
前記記憶部に記憶されている前記起動周期情報に基づいて、前記混合処理の実行開始タイミングを決定して、決定した前記実行開始タイミングから前記混合処理を実行する混合処理実行部（６）とを備える制御装置。
請求項１において、
前記制御装置は、ＣＰＵ（６）と、前記バスである内部バス（７）と、前記内部バスを介して前記ＣＰＵと接続された周辺回路（５）とを備えており、
前記ＣＰＵが前記混合処理実行部としての機能を備え、
前記混合処理は、前記制御装置が備えるリソースに対するリフレッシュ処理であり、
前記信号送信処理は、前記ＣＰＵが前記内部バスを介して前記周辺回路に制御信号を送信して行う、前記周辺回路に対するリフレッシュ処理を含んでいる制御装置。