JP2007001420A

JP2007001420A - Control unit for vehicle

Info

Publication number: JP2007001420A
Application number: JP2005183557A
Authority: JP
Inventors: Hiroyuki Nakabayashi; 宏之中林; Shuichi Nitta; 修一新田; Keisuke Matsuda; 啓資松田; Shinichi Senoo; 伸一妹尾
Original assignee: Denso Corp
Current assignee: Denso Corp
Priority date: 2005-06-23
Filing date: 2005-06-23
Publication date: 2007-01-11

Abstract

<P>PROBLEM TO BE SOLVED: To provide a control unit for a vehicle having a trouble shooting function capable of making rapid and accurate response upon occurrence of a communication trouble, even when a serial communication processing is asynchronously executed by a plurality of program modules. <P>SOLUTION: In this control unit for vehicle, a communication software includes: a drive module sendingly/receivingly driving a serial communication interface connected to a communication bus; a relay module performing sending/receive relay operation between the drive module and an application module; a drive control module commanding on sending/receiving operation for control messages according to a control state if it has transited to a right condition for sending/receiving operation for the control messages; and an anomaly monitoring module unifiedly notifying occurrence of anomaly to the drive, relay and drive control modules upon receiving the anomaly occurrence reports from the drive, relay and drive control modules. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

この発明は、自動車用制御ユニットに関し、特に自動車上の他の制御ユニットとシリアル通信バスにより接続された形で使用される自動車用制御ユニットに関する。 The present invention relates to an automobile control unit, and more particularly to an automobile control unit used in a form connected to another control unit on the automobile by a serial communication bus.

特開２００２−３１８７８３号公報JP 2002-318783 A

自動車には、各種機器（被制御要素）を制御するために、マイクロプロセッサ（ハードウェア制御主体）からなるＥＣＵが搭載されている。このようなＥＣＵとして、自動車上の他のＥＣＵと通信バスを介して通信できるようにしたマイクロプロセッサが使用されている。一つのＥＣＵは、一般には複数機能を統括的に司るために、制御処理用のアプリケーションも複数搭載されるのが常である。各アプリケーションによる制御は、ＥＣＵのプラットフォーム機能の一部として形成されたスケジューラによって順次起動され、プラットフォーム内の状態管理プログラムが、一連のアプリケーションの状態をまとめて管理するようになっており、制御状態を判定して状態遷移処理を行なう方式がとられる。シリアル通信処理を行なう場合、シリアル通信バスを介してアプリケーションが使用する制御用メッセージを受信する処理と、アプリケーションからの制御用メッセージがシリアル通信バス上に送信する処理とが必要になるが、その送受信のタイミングが、アプリケーション側の制御状態と適合している必要がある。この場合、ＥＣＵハードウェアによる通信バスとの間の直接的なメッセージ送受信のための駆動処理と、送受信に係るメッセージを、通信ハードウェア側とアプリケーション側との間で中継する中継処理と、アプリケーション側の状態遷移を監視しつつ、送受信に係るメッセージの中継タイミングの意思決定を行なう駆動管理処理とが、互いに独立して行なわれることが必要となり、それぞれが異なるプログラムモジュールにより非同期に実行されることとなる。 In order to control various devices (controlled elements), an automobile is equipped with an ECU composed of a microprocessor (hardware control main body). As such an ECU, a microprocessor that can communicate with other ECUs on a vehicle via a communication bus is used. In general, a single ECU is generally equipped with a plurality of control processing applications in order to generally control a plurality of functions. Control by each application is sequentially activated by a scheduler formed as a part of the platform function of the ECU, and the status management program in the platform manages the status of a series of applications collectively. A method of determining and performing state transition processing is employed. When serial communication processing is performed, processing for receiving a control message used by an application via the serial communication bus and processing for transmitting a control message from the application on the serial communication bus are required. The timing needs to match the control state on the application side. In this case, drive processing for direct message transmission / reception with the communication bus by the ECU hardware, relay processing for relaying messages related to transmission / reception between the communication hardware side and the application side, and the application side Drive management processing for determining the relay timing of messages related to transmission / reception while monitoring the state transition of each of them must be performed independently of each other, each being executed asynchronously by different program modules; Become.

上記のような方式で通信に異常が発生した場合、その異常対応処理も、各プログラムモジュールが全体に与える影響を考慮して非同期に行なうことになる。しかし、このようなモジュール単位での異常処理では、各モジュールが異常発生の認識に一定数の処理ステップを消費するために、発生した異常に対応する処理がなされるまでに時間を要する問題がある。また、同時に発生した異常処理をまとめて処理することもできない。 When an abnormality occurs in communication by the method described above, the abnormality handling process is also performed asynchronously in consideration of the influence of each program module on the whole. However, in such abnormal processing in units of modules, each module consumes a certain number of processing steps for recognizing the occurrence of an abnormality, so that there is a problem that it takes time until processing corresponding to the generated abnormality is performed. . In addition, it is also impossible to collectively process abnormal processes that occur at the same time.

本発明の課題は、シリアル通信処理を、複数のプログラムモジュールにより非同期に実行する場合においても、通信異常発生時に迅速かつ的確に対応できる異常処理機能を有した自動車用制御ユニットを提供することにある。 An object of the present invention is to provide an automobile control unit having an abnormality processing function capable of quickly and accurately responding to a communication abnormality even when serial communication processing is executed asynchronously by a plurality of program modules. .

課題を解決するための手段及び発明の効果Means for Solving the Problems and Effects of the Invention

上記の課題を解決するために、本発明の自動車用制御ユニットは、
ＣＰＵからなる主制御部を有し、自動車上の他の制御ユニットとシリアル通信バスにより接続され、自動車上に搭載される電子機器の制御処理を、予め定められた複数のアプリケーションの実行に基づいて実施する自動車用制御ユニットであって、
アプリケーションによる電子機器の制御状態を管理するとともに、制御状態を判定して状態遷移処理を行なうアプリケーション状態管理手段と、
シリアル通信バスを介してアプリケーションが使用する制御用メッセージを受信する処理と、他方、アプリケーションからの制御用メッセージをシリアル通信バス上に送信する処理とを、主制御部による通信ソフトウェアの実行に基づいて実施するシリアル通信制御手段とを有し、通信ソフトウェアが、
制御用メッセージの通信バスへの送信ないし通信バスからの受信のために、通信バスに接続されたシリアル通信インターフェースを駆動する駆動モジュールと、
駆動モジュールとアプリケーションとの間の送受信中継処理として、アプリケーションからの制御用メッセージの送受信要求を受け付けるとともに、駆動モジュールが受信した制御用メッセージをアプリケーションに転送する一方、アプリケーションから送信要求のあった制御用メッセージを駆動モジュールに転送する中継モジュールと、
アプリケーション状態管理手段による制御状態が、該アプリケーションにおける制御用メッセージの送受信に適した状態に遷移しているか否かを判定し、該判定結果に基づいて駆動モジュール及び中継モジュールに対する制御用メッセージの送受信に関する指令を行なう駆動管理モジュールと、
駆動モジュール、中継モジュール及び駆動管理モジュールのうち、少なくとも駆動管理モジュールからの異常発生報告を受け、駆動モジュール、中継モジュール及び駆動管理モジュールのそれぞれに一元的な異常発生通知を行なう異常監視モジュールと、を有することを特徴とする。 In order to solve the above problems, the control unit for automobiles of the present invention includes:
Based on the execution of a plurality of predetermined applications, a main control unit comprising a CPU is connected to another control unit on the automobile via a serial communication bus, and the electronic equipment mounted on the automobile is controlled. An automotive control unit to implement,
Application state management means for managing the control state of the electronic device by the application and determining the control state and performing state transition processing;
Processing for receiving a control message used by an application via the serial communication bus and processing for transmitting a control message from the application on the serial communication bus based on execution of communication software by the main control unit Serial communication control means to implement, communication software,
A drive module for driving a serial communication interface connected to the communication bus for transmitting a control message to the communication bus or receiving from the communication bus;
As a transmission / reception relay process between the drive module and the application, the control message received from the application is received and the control message received by the drive module is transferred to the application. A relay module that forwards messages to the drive module;
It is determined whether or not the control state by the application state management means has transitioned to a state suitable for transmission / reception of a control message in the application, and based on the determination result, transmission / reception of a control message to / from the drive module and the relay module A drive management module for commanding;
An abnormality monitoring module that receives at least an abnormality occurrence report from the drive management module among the drive module, the relay module, and the drive management module, and performs unified abnormality occurrence notification to each of the drive module, the relay module, and the drive management module; It is characterized by having.

上記の構成によると、アプリケーションとシリアル通信バスとの間での通信メッセージの送受信処理が、駆動モジュールと、中継モジュールと、駆動管理モジュールとの連携により、制御状態に状態遷移に合わせて的確に実施することができる。そして、通信異常が発生した場合は、駆動モジュール、中継モジュール及び駆動管理モジュールのうち、少なくとも駆動管理モジュールからの異常発生報告を受け、駆動モジュール、中継モジュール及び駆動管理モジュールのそれぞれに一元的な異常発生通知を行なうようにしたから、これら３つのモジュールによる非同期のシリアル通信処理であるにもかかわらず、通信異常発生への対応処理を迅速かつ的確に実施できる。 According to the above configuration, communication message transmission / reception processing between the application and the serial communication bus is performed accurately in accordance with the state transition to the control state by cooperation of the drive module, relay module, and drive management module. can do. When a communication abnormality occurs, at least an abnormality occurrence report is received from the drive management module among the drive module, the relay module, and the drive management module, and the abnormality is centralized in each of the drive module, the relay module, and the drive management module. Since the occurrence notification is performed, the processing for dealing with the occurrence of the communication abnormality can be performed quickly and accurately despite the asynchronous serial communication processing by these three modules.

この場合、駆動管理モジュール、中継モジュール及び駆動モジュールが、予め定められた異常状態が成立した場合に、いずれも異常監視モジュールに異常報告を個別に行なうように構成しておくと、各モジュールレベルに特有の通信異常にきめ細かく対応することができる。駆動管理モジュール、中継モジュール、駆動モジュール及び異常監視モジュールは、予め定められた時系列順序にて周期的に実行するようにしておくと、モジュール間の処理のコンフリクトが発生せず、時分割による効率的な非同期処理が可能となる。 In this case, if the drive management module, the relay module, and the drive module are configured so that when the predetermined abnormal state is established, the abnormality monitoring module individually reports the abnormality to each module level, It is possible to meticulously cope with specific communication abnormalities. If the drive management module, the relay module, the drive module, and the abnormality monitoring module are periodically executed in a predetermined time-series order, processing conflict between modules does not occur, and the efficiency by time division Asynchronous processing is possible.

異常監視モジュールは、異常発生時に通信ソフトウェアの動作をスリープ状態に移行させるスリープ指示を行なうものとして構成することができる。通信異常発生時にＥＣＵが余計な動作を行なわず一旦スリープすることで、ＥＣＵ動作を介して異常不具合が以降の処理に伝播することを防止できる。また、再度通信が必要か否かを上位のアプリケーションからの指示を待って判断することで、シリアル通信全体への影響を少なくすることができる。 The abnormality monitoring module can be configured to issue a sleep instruction for shifting the operation of the communication software to the sleep state when an abnormality occurs. When the communication abnormality occurs, the ECU once sleeps without performing any extra operation, so that it is possible to prevent the abnormal malfunction from being propagated to the subsequent processes via the ECU operation. Further, it is possible to reduce the influence on the entire serial communication by determining whether or not the communication is necessary again after waiting for an instruction from the upper application.

上記した機能からもわかる通り、中継モジュール及び駆動モジュールによる送受信処理の統括管理は駆動管理モジュールが行なっている。従って、スリープ状態に移行するためのハードウェアないしソフトウェアの準備設定を、適切なタイミングで実施できるようにする観点から、異常監視モジュールは、異常発生時に駆動管理モジュールを介して駆動モジュールにスリープ指示を行なうものとすることが望ましい。 As can be seen from the above functions, the drive management module performs overall management of transmission / reception processing by the relay module and the drive module. Therefore, from the viewpoint of enabling hardware or software preparation settings for shifting to the sleep state at an appropriate timing, the abnormality monitoring module issues a sleep instruction to the drive module via the drive management module when an abnormality occurs. It is desirable to do it.

駆動管理モジュール、中継モジュール及び駆動モジュールは、この順序にて周期的に実行することができる。中継モジュール及び駆動モジュールによる送受信タイミング調整をスムーズに行なうには、駆動管理モジュール、中継モジュール及び駆動モジュールをこの順序で立ち上げるのが合理的である。そして、異常監視モジュールは、駆動管理モジュール、中継モジュール及び駆動モジュールのいずれかから異常発生通知を受けることにより、それら駆動管理モジュール、中継モジュール及び駆動モジュールの全てにスリープ指令を行ない、制御ユニットハードウェアのスリープ設定を行なうように構成することで、上記のごとく異常発生時に駆動管理モジュールを介して駆動モジュールにスリープ指示を行なう処理もスムーズに進めることができる。 The drive management module, the relay module, and the drive module can be periodically executed in this order. In order to smoothly adjust the transmission / reception timing by the relay module and the drive module, it is reasonable to start up the drive management module, the relay module, and the drive module in this order. The abnormality monitoring module receives an abnormality occurrence notification from any one of the drive management module, the relay module, and the drive module, and issues a sleep command to all of the drive management module, the relay module, and the drive module. By configuring so as to perform the sleep setting, as described above, it is possible to smoothly proceed the process of issuing a sleep instruction to the drive module via the drive management module when an abnormality occurs.

次に、本発明の自動車用制御ユニットは、アプリケーション状態管理手段が行なう状態遷移処理に伴い、遷移により設定された制御状態が制御状態特定情報の形で制御状態メモリに記憶されるよう構成することができる。この場合、駆動管理モジュールは、制御状態メモリの記憶内容に基づいてアプリケーション側の異常判定を行ない、異常監視モジュールに異常発生報告を行なうものとすることができる。通信異常が発生した場合、状態遷移設定の際に一度書き込まれた制御状態特定情報が、アプリケーション状態管理手段を司るソフトウェア以外による不正なメモリアクセスにより書き換えられることが多い。従って、これを利用すれば、制御状態メモリの記憶内容を確認することにより、通信異常の有無を容易に判定することができる。具体的には、制御状態メモリには、状態遷移が発生するたびに、制御状態特定情報とともに、そのミラー情報が記憶され、駆動管理モジュールは、該制御状態特定情報と該ミラー情報とを照合し、その照合結果に基づいて異常判定を行なうものとすることができる。ミラー情報は、アプリケーション状態管理手段が状態遷移設定に伴い、制御状態特定情報と対にして意図的に作成されるものであり、通信異常による不正アクセスでは、制御状態特定情報とそのミラー情報とが照合の取れた形で同時に書き換わる可能性は限りなくゼロに近い。従って、制御状態特定情報と対応するミラー情報との照合により、通信異常が発生したか否かを的確に判定することができる。 Next, the automobile control unit of the present invention is configured so that the control state set by the transition is stored in the control state memory in the form of control state specifying information in accordance with the state transition process performed by the application state management means. Can do. In this case, the drive management module can perform an abnormality determination on the application side based on the storage contents of the control state memory, and report an abnormality occurrence to the abnormality monitoring module. When a communication error occurs, the control state specifying information once written at the time of setting the state transition is often rewritten by an unauthorized memory access by software other than the software that manages the application state management means. Therefore, if this is used, it is possible to easily determine the presence or absence of communication abnormality by confirming the storage contents of the control state memory. Specifically, each time a state transition occurs, the control state memory stores the mirror information together with the control state specifying information, and the drive management module collates the control state specifying information with the mirror information. The abnormality determination can be performed based on the collation result. The mirror information is intentionally created by the application state management means in combination with the control state specifying information in accordance with the state transition setting. In the case of unauthorized access due to a communication error, the control state specifying information and its mirror information are The possibility of rewriting at the same time in a collated form is almost zero. Therefore, it is possible to accurately determine whether or not a communication abnormality has occurred by comparing the control state specifying information with the corresponding mirror information.

以下、本発明の実施の形態を、図面を参照して説明する。
図１は、本発明の自動車用スリープ制御システムの概念が適用されるＥＣＵの電気的な構成図である。ＥＣＵ１は、ＣＰＵ３、ＲＯＭ５、ＲＡＭ４及び入出力部（Ｉ／Ｏポート）２がバス接続されたマイクロプロセッサからなる。ＥＣＵ１は、本実施形態では自動車のボデー系の制御を司るボデー系ＥＣＵとして構成され、図２はその概略アーキテクチャを示すものである。マイクロプロセッサからなるハードウェア制御主体上に搭載されるソフトウェアは、プラットフォームと、そのプラットフォーム上で動作する、ボデー系機能を実現するためのアプリケーションである。なお、複数のアプリケーションを区別するために、１〜ｎの記号を付して示した。プラットフォームは、ベースとなるハードウェアが相違する場合にも、各アプリケーションに共通の動作環境を与えるためのものであり、該アプリケーションに対する基本ソフト（ＯＳ）のほか、アプリケーションやハードウェアとの連携を図るインターフェースプログラムなどを含んで構成されるが、概念的には周知の部分なので説明の詳細は省略する。 Hereinafter, embodiments of the present invention will be described with reference to the drawings.
FIG. 1 is an electrical configuration diagram of an ECU to which the concept of an automobile sleep control system of the present invention is applied. The ECU 1 includes a microprocessor in which a CPU 3, a ROM 5, a RAM 4, and an input / output unit (I / O port) 2 are connected by a bus. In the present embodiment, the ECU 1 is configured as a body system ECU that controls the body system of the automobile, and FIG. 2 shows a schematic architecture thereof. The software installed on the hardware control entity composed of a microprocessor is a platform and an application for realizing a body function that operates on the platform. In addition, in order to distinguish a some application, it attached | subjected and shown with the symbol of 1-n. The platform is for giving a common operating environment to each application even when the base hardware is different. In addition to the basic software (OS) for the application, the platform is linked with the application and hardware. Although it is configured to include an interface program and the like, it is a well-known part conceptually and will not be described in detail.

アプリケーションは、車両利用者による車両各部の操作に係る機能であるボデー系機能を実現するものである。このボデー系機能とは、具体的には、ドア開閉に伴う制御、窓開閉に伴う制御、ライトスイッチのオン／オフに伴う制御、キーレスエントリ方式等に採用されるワイヤレスドアロック機構の制御、・・・といったものをいう。具体的には、以下のようなものを例示できる：
・運転席ドア、助手席ドア、後部右側座席ドア、後部左側座席ドア、ルーフなどのロック／ロック解除、パワーウィンドウ動作など。
・エアコン、カーオーディオ、カーナビゲーションシステムなどの電源動作など。
・ルームランプ、コックピットランプ、ヘッドライト、スモールランプ、ハザードランプ、テールランプなどのスイッチ点灯制御など。
各アプリケーション１、２、‥は、図１のＲＯＭ５に記憶されており、ＲＡＭ４の各アプリケーションに対応したワークエリア上でＣＰＵ３により実行される。 The application realizes a body function that is a function related to operation of each part of the vehicle by the vehicle user. Specifically, the body system functions include control associated with opening / closing of a door, control associated with opening / closing of a window, control associated with turning on / off a light switch, control of a wireless door lock mechanism employed in a keyless entry system, etc.・・ Etc. Specific examples include the following:
-Driver door, passenger door, rear right seat door, rear left seat door, roof lock / unlock, power window operation, etc.
・ Power supply operation for air conditioners, car audio systems, car navigation systems, etc.
-Switch lighting control for room lamp, cockpit lamp, headlight, small lamp, hazard lamp, tail lamp, etc.
Each application 1, 2,... Is stored in the ROM 5 of FIG. 1 and is executed by the CPU 3 on a work area corresponding to each application in the RAM 4.

ＥＣＵ１は、必要に応じて外部からのスイッチやセンサからの入力信号等も参照しつつ、各アプリケーションの実行により、前述した各種ボデー系の制御対象機器（被制御要素）の動作制御を司る。しかし、ＥＣＵ１は、ある条件で、例えば、車両が駐車状態にある場合、又はあるスイッチ操作がない場合にはスリープモードに移行する。このスリープモードへの移行は、具体的には全てのアプリケーションが動作終了し、次の動作開始のための待機状態になっている場合に、ＥＣＵ１全体を低消費電力モード（ＣＰＵ３の動作クロックを与えるメインクロック回路８を停止したスタンバイモードや、通常動作と異なる低周波数の発振器で動作するスロークロックモード、あるいは一定時間ごとにＣＰＵを間欠的に動作させる間欠モードなど）へ移行させる形で行なうものであり、その制御は図２のプラットフォーム部分が担うこととなる。 The ECU 1 controls the operation of the above-described various body-related control target devices (controlled elements) by executing each application while referring to external switches, sensors, and other input signals as necessary. However, the ECU 1 shifts to a sleep mode under certain conditions, for example, when the vehicle is parked or when there is no switch operation. Specifically, the transition to the sleep mode is performed when the entire ECU 1 is put into a low power consumption mode (the operation clock of the CPU 3 is given) when all applications have finished operating and are in a standby state for starting the next operation. The main clock circuit 8 is switched to a standby mode in which the main clock circuit 8 is stopped, a slow clock mode in which a low-frequency oscillator different from the normal operation is operated, or an intermittent mode in which the CPU is operated intermittently at regular intervals). Yes, the control is performed by the platform portion of FIG.

ＥＣＵ１は、通信バスを介して他のハードウェア制御主体（例えば他のＥＣＵ）と接続されており、シリアル通信によりウェイクアップ要因を判断すると動作を開始する。該ウェイクアップ要因を判断した場合、ウェイクアップ時のシステム設定（リソース設定など）を行なう。いずれも、そのシステム設定の後で複数のアプリケーションの状態が判定され、所定条件成立時にスリープ時のシステム設定を行ない、その後、スリープする。この判定を含めたＥＣＵ１のスリープ状態への移行、及びウェイクアップのための準備制御などを統括的に司るのが、図１のスリープ管理・制御ソフトである。 The ECU 1 is connected to another hardware control entity (for example, another ECU) via a communication bus, and starts operating when a wake-up factor is determined by serial communication. If the wake-up factor is determined, system settings (resource settings, etc.) at the time of wake-up are performed. In any case, the states of a plurality of applications are determined after the system setting, the system setting at the time of sleep is performed when a predetermined condition is satisfied, and then the sleep is performed. The sleep management / control software shown in FIG. 1 is responsible for overall control of the ECU 1 to enter the sleep state, including this determination, and preparation control for wakeup.

図３に示すように、各アプリケーションによる制御は、プラットフォームの機能の一部として形成されたスケジューラによって、複数のアプリケーション１，２‥ｎが順次起動されることにより実施される。このとき、プラットフォーム内の状態管理プログラムが、一連のアプリケーションの状態をまとめて管理するようになっており、制御状態を判定して状態遷移処理を行なう。状態管理プログラムによる状態遷移処理を示すのが、図４の説明図である。状態管理プログラムは、アプリケーションの状態として３つの状態、すなわち準備状態α、制御状態β、そして、制御開始監視状態γを定義しており、図３に示したスケジューラによる一連の起動処理毎に、各アプリケーションからの信号に基づき、必要に応じて状態を遷移させる（アプリケーション状態管理手段）。 As shown in FIG. 3, control by each application is performed by sequentially starting a plurality of applications 1, 2,... N by a scheduler formed as a part of the platform function. At this time, the state management program in the platform collectively manages the state of a series of applications, and determines the control state and performs state transition processing. FIG. 4 is an explanatory diagram showing state transition processing by the state management program. The state management program defines three states as an application state, that is, a preparation state α, a control state β, and a control start monitoring state γ. For each series of startup processing by the scheduler shown in FIG. Based on the signal from the application, the state is changed as necessary (application state management means).

すなわち、リセット指示によって動作を開始している場合、最初は準備状態αとし、一方、ウェイクアップ要因を判断して動作を開始している場合、最初は制御開始監視状態γとする。そして、準備状態αにある場合、各アプリケーションから準備完了の通知があると、次に制御状態βへ状態を遷移させる（記号(1)）。また、制御状態βにある場合、前述のスリープ管理・制御ソフトは、アプリケーションソフトウェア毎に異なる要求スリープ期間の開始時刻及び終了時刻を直接的又は間接的に特定するためのスリープ制御情報を取得し、全てのアプリケーションからスリープ制御情報を取得すれば、制御開始監視状態γへ状態が遷移する（記号(2)）。 That is, when the operation is started by the reset instruction, the preparation state α is initially set. On the other hand, when the operation is started by determining the wake-up factor, the control start monitoring state γ is initially set. Then, in the preparation state α, when there is a notification of preparation completion from each application, the state is then shifted to the control state β (symbol (1)). Further, when in the control state β, the sleep management / control software described above acquires sleep control information for directly or indirectly specifying the start time and end time of the requested sleep period that differs for each application software, If sleep control information is acquired from all applications, the state transitions to the control start monitoring state γ (symbol (2)).

該状態遷移処理に伴い設定された制御状態は、状態データ（制御状態特定情報）の形で、図６に示すようなＲＡＭ４内の制御状態メモリに記憶される。このとき、状態データのミラーデータ（本実施形態では、状態データの各ビットの０／１を反転させたビット反転データとしてミラーデータを作成している）も作成し、個々の状態データに対応付けて記憶する。 The control state set with the state transition process is stored in a control state memory in the RAM 4 as shown in FIG. 6 in the form of state data (control state specifying information). At this time, mirror data of the state data (in this embodiment, mirror data is created as bit inversion data obtained by inverting 0/1 of each bit of the state data) is associated with each state data. Remember.

各アプリケーションは、要求するスリープ期間をタイマー設定し、スリープとウェイクアップとを定期的に繰り返すようにプログラミングされている。例えば、キーレスエントリ方式が採用される場合、図１の「スイッチ／センサ等の入力」として、ユーザー携帯器からの無線信号が受信入力され、キーレスエントリ方式に対応したドアロック制御アプリケーションは、その受信スタンバイ期間を通常モード期間として、スリープ期間と交互に繰り返すようにＥＣＵ１の作動制御を行なうこととなる。 Each application is programmed to set a requested sleep period as a timer and periodically repeat sleep and wakeup. For example, when the keyless entry method is adopted, a radio signal from the user portable device is received and input as “input of switch / sensor, etc.” in FIG. 1, and the door lock control application corresponding to the keyless entry method receives the received signal. The operation control of the ECU 1 is performed so that the standby period is the normal mode period and is repeated alternately with the sleep period.

他方、アプリケーションの一部又は全部は、上記のスリープサイクルとは無関係に、外部の操作信号（ライト点灯、ドアロック解除指令など）をトリガーとした割り込み処理指令を受けた場合も、これをウェイクアップ要因として随時ウェイクアップするようになっている。そして、その後一定期間ウェイクアップ要因がなければ要求スリープ期間が再設定され、スリープに移行する。 On the other hand, part or all of the application wakes up even if it receives an interrupt processing command triggered by an external operation signal (light lighting, door lock release command, etc.) regardless of the sleep cycle described above. Wake up from time to time as a factor. After that, if there is no wake-up factor for a certain period, the requested sleep period is reset and the process shifts to sleep.

次に、アプリケーションが使用する制御用メッセージを受信する処理と、アプリケーションからの制御用メッセージをシリアル通信バス上に送信する処理とは、図１のＣＰＵ３（主制御部）による通信ソフトウェアの実行に基づいて実施される。シリアル通信バスとＥＣＵ１の内部バスとは、シリアル通信インターフェース６を介して接続されている。また、受信メッセージを一時格納する受信バッファ６Ｂが設けられている。 Next, the process of receiving the control message used by the application and the process of transmitting the control message from the application onto the serial communication bus are based on the execution of the communication software by the CPU 3 (main control unit) in FIG. Implemented. The serial communication bus and the internal bus of the ECU 1 are connected via the serial communication interface 6. Further, a reception buffer 6B for temporarily storing received messages is provided.

通信ソフトウェアの階層構造を図５に示している。下層ほどハードウェア（ここでは通信バス）層に近く、上層ほどアプリケーション層に近いことを意味する。具体的には、下記のモジュール群よりなる。
・駆動モジュール（以下、ＤＲＶモジュールともいう）：制御用メッセージの通信バスへの送信ないし通信バスからの受信のために、通信バスに接続されたシリアル通信インターフェース６を駆動する。
・中継モジュール（以下、ＣＯＭモジュールともいう）：駆動モジュールとアプリケーションとの間の送受信中継処理として、アプリケーションからの制御用メッセージの送受信要求を受け付けるとともに、駆動モジュールが受信した制御用メッセージをアプリケーションに転送する一方、アプリケーションから送信要求のあった制御用メッセージを駆動モジュールに転送する。
・駆動管理モジュール（以下、ＮＭモジュールともいう）：アプリケーション状態管理手段による制御状態が、該アプリケーションにおける制御用メッセージの送受信に適した状態に遷移しているか否かを判定し、該判定結果に基づいて駆動モジュール及び中継モジュールに対する制御用メッセージの送受信に関する指令を行なう。
・異常監視モジュール：駆動モジュール、中継モジュール及び駆動管理モジュールのうち、少なくとも駆動管理モジュール（本実施形態では、上記３つのモジュールの全て）からの異常発生報告を受け、駆動モジュール、中継モジュール及び駆動管理モジュールのそれぞれに一元的な異常発生通知を行なう。 The hierarchical structure of the communication software is shown in FIG. It means that the lower layer is closer to the hardware (here, communication bus) layer, and the upper layer is closer to the application layer. Specifically, it consists of the following module group.
Drive module (hereinafter also referred to as DRV module): Drives the serial communication interface 6 connected to the communication bus in order to transmit a control message to the communication bus or receive from the communication bus.
Relay module (hereinafter also referred to as COM module): As a transmission / reception relay process between the drive module and the application, it receives a control message transmission / reception request from the application and transfers the control message received by the drive module to the application. On the other hand, the control message requested by the application is transferred to the drive module.
Drive management module (hereinafter also referred to as NM module): Determines whether or not the control state by the application state management means has transitioned to a state suitable for transmission and reception of control messages in the application, and based on the determination result Then, a command relating to transmission / reception of control messages to the drive module and the relay module is issued.
Abnormality monitoring module: Upon receipt of an abnormality occurrence report from at least the drive management module (all of the above three modules in the present embodiment) among the drive module, relay module, and drive management module, the drive module, relay module, and drive management Centralized error notification is sent to each module.

ＤＲＶモジュールが最もハードウェア層に近く、ＣＯＭモジュール、ＮＭモジュール及び異常監視モジュールはアプリケーション層とＤＲＶモジュール層との中間に位置する。なお、本実施形態では、通信容量の増大を図るために、シリアル通信バスを複数チャネルにて構成し、ＤＲＶモジュールとＮＭモジュールとはチャネル毎に設けられている。 The DRV module is closest to the hardware layer, and the COM module, the NM module, and the abnormality monitoring module are located between the application layer and the DRV module layer. In this embodiment, in order to increase the communication capacity, the serial communication bus is configured by a plurality of channels, and the DRV module and the NM module are provided for each channel.

図１のＲＡＭ４には、通信制御メモリが設けられている。図７に示すように、通信制御メモリには、通信バスから受信した制御用メッセージを格納する受信メッセージボックスメモリ、これから通信バスへ送信しようとしている制御用メッセージを格納する送信メッセージボックスメモリ、アプリケーションからの制御用メッセージの送信要求を受け付けて登録するための送信受付メモリ、ＮＭモジュールによるＤＲＶモジュールへの指令内容を格納するＮＭ通知メモリ（送信用と受信用とが個別に設けられている）及び異常監視モジュールへの異常通知内容を記憶する異常通知メモリが設けられている。図８に示すように、アプリケーションとは別のスケジューラによって、ＮＭモジュール、ＣＯＭモジュール、ＤＲＶモジュール及び異常監視モジュールは、この順序で周期的に実行される。 The RAM 4 in FIG. 1 is provided with a communication control memory. As shown in FIG. 7, the communication control memory includes a reception message box memory for storing a control message received from the communication bus, a transmission message box memory for storing a control message to be transmitted to the communication bus, and an application. Transmission acceptance memory for accepting and registering transmission requests for control messages, NM notification memory for storing command contents to DRV module by NM module (transmission and reception are provided separately) and abnormality An abnormality notification memory for storing abnormality notification contents to the monitoring module is provided. As illustrated in FIG. 8, the NM module, the COM module, the DRV module, and the abnormality monitoring module are periodically executed in this order by a scheduler different from the application.

図９は、ＮＭモジュールの処理の流れを示すものである。まず、Ｓ３で対象となるアプリケーションの状態データを読み出し、Ｓ４でこれに対応するミラーデータを読み出す（図６参照）。Ｓ５では、読み出した状態データとミラーデータの照合処理を行なう。図６に示すように、本実施形態ではミラーデータは状態データのビット反転データに相当し、状態データが書き換わって、ミラーデータの対応するビットとの間で不整合が生じていれば、その否定排他的論理和の値がゼロとなる。従って、その値の全ビットに対するサムを演算し、そのサムがゼロであれば照合一致、ゼロでなければ照合不一致として判定される。Ｓ６でその判定結果が不一致であればＳ１３に進み、異常監視モジュールに異常通知を行なって処理サイクルを終了する（本実施形態では異常通知メモリへの書込みによっているが、この形態に限られるものではない）。 FIG. 9 shows the process flow of the NM module. First, status data of the target application is read in S3, and corresponding mirror data is read in S4 (see FIG. 6). In S5, the read status data is compared with the mirror data. As shown in FIG. 6, in this embodiment, the mirror data corresponds to the bit inverted data of the status data. If the status data is rewritten and a mismatch occurs between the corresponding bits of the mirror data, The value of the negative exclusive OR is zero. Therefore, the sum for all bits of the value is calculated, and if the sum is zero, it is determined as a collation match, and if it is not zero, it is determined as a collation mismatch. If the determination result is inconsistent in S6, the process proceeds to S13 to notify the abnormality monitoring module of the abnormality and the processing cycle is terminated (in this embodiment, writing to the abnormality notification memory is performed, but the present invention is not limited to this form). Absent).

他方、Ｓ６で照合一致ならば状態データに異常なしなので、Ｓ７でその状態が送信許可に適合した状態であるか否かを判定する。送信不可であれば処理サイクルを終了する一方、送信可能であればＳ９に進み、ＮＭ通知メモリに制御用メッセージの通信バスへの送出許可をセットする。また、Ｓ１０では受信許可に適合した状態であるか否かを判定し、受信不可であれば処理サイクルを終了する一方、受信可能であればＳ１１に進み、ＮＭ通知メモリに制御用メッセージのＣＯＭモジュールへの転送許可をセットし、処理サイクルを終了する。 On the other hand, if the collation coincides in S6, there is no abnormality in the state data, so in S7, it is determined whether or not the state is suitable for transmission permission. If transmission is not possible, the processing cycle ends. If transmission is possible, the process proceeds to S9, and permission to send a control message to the communication bus is set in the NM notification memory. Further, in S10, it is determined whether or not it is in a state suitable for reception permission. If reception is impossible, the processing cycle is terminated. If reception is possible, the process proceeds to S11, and the control message COM module is stored in the NM notification memory. Set the transfer permission to, and end the processing cycle.

図１０は、ＣＯＭモジュールの処理の流れを示すものである。まず、Ｓ１０３では、先のサイクルでアプリケーションに転送してある制御用メッセージの、当該アプリケーションからの受領（アクノリッジ）があるかどうかを確認する。Ｓ１０４では、その結果を判定し、受領なしであればアプリケーション側の異常と判定してＳ１１２に進み、異常監視モジュールに異常通知を行なって処理サイクルを終了する。なお、ＮＭモジュールと同様に、監視対象となる状態データと、ミラーデータとの照合処理に基づいて異常判定を行なうようにしてもよい。 FIG. 10 shows the processing flow of the COM module. First, in S103, it is confirmed whether or not the control message transferred to the application in the previous cycle has been received (acknowledged) from the application. In S104, the result is determined. If there is no receipt, it is determined that the application is abnormal, the process proceeds to S112, an abnormality is notified to the abnormality monitoring module, and the processing cycle is ended. As in the case of the NM module, the abnormality determination may be performed based on the collation process between the status data to be monitored and the mirror data.

他方、Ｓ１０４で「異常なし」であれば、Ｓ１０５で受信メッセージボックスメモリをリードし、Ｓ１０６で処理対象となるアプリケーションへの受信メッセージがあるかどうかを調べる。受信メッセージがあれば、Ｓ１０７で対応するアプリケーションへ受信メッセージを転送する（この結果に対して、次サイクル以降にアプリケーションからアクノリッジが返されることとなる）。一方、Ｓ１０６で受信メッセージがなければＳ１０７をスキップする。 On the other hand, if “no abnormality” in S104, the received message box memory is read in S105, and it is checked in S106 whether there is a received message for the application to be processed. If there is a received message, the received message is transferred to the corresponding application in S107 (in response to this result, an acknowledge is returned from the application after the next cycle). On the other hand, if there is no received message in S106, S107 is skipped.

次いで、Ｓ１０８では送信受付メモリをリードし、Ｓ１０９で処理対象となるアプリケーションからの制御用メッセージの送信要求があるかどうかを確認する。送信要求があればＳ１１０に進み、その制御用メッセージを受け付けてこれを送信メッセージボックスメモリにセットする。一方、Ｓ１０９で制御用メッセージの送信要求がなければＳ１１０をスキップする。以上で処理サイクルを終了する。 Next, in S108, the transmission acceptance memory is read, and in S109, it is confirmed whether there is a control message transmission request from the application to be processed. If there is a transmission request, the process proceeds to S110 to accept the control message and set it in the transmission message box memory. On the other hand, if there is no control message transmission request in S109, S110 is skipped. The processing cycle is thus completed.

図１１は、ＤＲＶモジュールの処理の流れを示すものである。まず、Ｓ２０３にて、通信バスに断線やショートなどのハードウェア異常がないかどうかを、ポート電圧などを参照して判定する。異常があれば、Ｓ２１７に進んで、シリアル通信インターフェース６（図１）の送受信動作を停止させる。そして、Ｓ２１８に進み、異常監視モジュールに異常通知を行なって処理サイクルを終了する。なお、ＮＭモジュールと同様に、監視対象となる状態データと、ミラーデータとの照合処理に基づいて異常判定を行なうようにしてもよい。 FIG. 11 shows the process flow of the DRV module. First, in S203, it is determined with reference to the port voltage or the like whether there is any hardware abnormality such as disconnection or short in the communication bus. If there is an abnormality, the process proceeds to S217, and the transmission / reception operation of the serial communication interface 6 (FIG. 1) is stopped. In step S218, the abnormality monitoring module is notified of abnormality, and the processing cycle ends. As in the case of the NM module, the abnormality determination may be performed based on the collation process between the status data to be monitored and the mirror data.

Ｓ２０３でハードウェア異常が検出されなければ、Ｓ２０４に進んで受信バッファをリードし、Ｓ２０５で制御用メッセージを受信しているかどうか（受信していれば、そのヘッダＩＤの内容から、どのアプリケーションへの制御用メッセージなのか）を判定する。制御用メッセージを受信していれば、Ｓ２０６に進んでＮＭ通知メモリをリードする（制御用メッセージが受信されていなければ、Ｓ２０９へジャンプする）。そして、Ｓ２０７で、ＣＯＭへの転送許可が通知されているかどうかを確認し、転送許可されていれば、受信バッファ上の制御用メッセージを受信メッセージボックスメモリへ格納する（転送許可されていなければＳ２０８をスキップする）。 If no hardware abnormality is detected in S203, the process proceeds to S204 to read the reception buffer, and whether or not a control message has been received in S205 (if received, from which contents of the header ID to which application Control message). If the control message has been received, the process proceeds to S206 and the NM notification memory is read (if the control message has not been received, the process jumps to S209). Then, in S207, it is confirmed whether or not transfer permission to COM is notified. If transfer is permitted, the control message on the reception buffer is stored in the reception message box memory (if transfer is not permitted, S208 is stored). Skip).

Ｓ２０９では送信メッセージボックスメモリをリードし、処理対象となるアプリケーションからの送信メッセージがあるかどうかを確認する。送信メッセージがあればＳ２１１に進み、ＮＭ通知メモリをリードする（送信メッセージがなければ、処理サイクルを終了する）。Ｓ２１２では、ＮＭ通知メモリの内容が、制御用メッセージの通信バスへの送出許可を示す内容か否かを確認し、送出許可になっていればＳ２１３へ進み、メッセージを通信バスへ送出する（送出許可がなされていなければ、そのまま処理サイクルを終了する）。 In S209, the transmission message box memory is read to check whether there is a transmission message from the application to be processed. If there is a transmission message, the process proceeds to S211 and the NM notification memory is read (if there is no transmission message, the processing cycle is terminated). In S212, it is confirmed whether or not the contents of the NM notification memory indicate the permission to send the control message to the communication bus. If the message is permitted to send, the process proceeds to S213 to send the message to the communication bus (send). If permission has not been granted, the processing cycle is terminated.)

図１２は、異常監視モジュールの処理の流れを示すものである。Ｓ３０１〜Ｓ３０３では、ＮＭモジュール、ＣＯＭモジュール及びＤＲＶモジュールから、それぞれ異常通知（異常報告）があるかどうかを確認し、異常通知があれば、Ｓ３０６に進んで、各モジュールに対してスリープ設定を行なう。なお、あとで異常の原因をトレースする場合の便宜を図るため、各モジュールは、どのモジュールから異常通知があったかを区別できるように異常通知メモリに異常セットすることが望ましい（モジュール別に個別の異常通知メモリを設けておくことも可能である）。また、異常内容（例えば、異常の種別をコード化したもの）も合わせて異常通知メモリにセットすると、異常原因トレースがより容易になる。 FIG. 12 shows the flow of processing of the abnormality monitoring module. In S301 to S303, it is confirmed whether or not there is an abnormality notification (abnormality report) from each of the NM module, the COM module, and the DRV module. If there is an abnormality notification, the process proceeds to S306 to set sleep for each module. . For convenience when tracing the cause of an abnormality later, it is desirable that each module should be set in the abnormality notification memory so that it can be distinguished from which module the abnormality was notified (individual abnormality notification for each module). It is also possible to provide a memory). Further, when the abnormality content (for example, the abnormality type coded) is also set in the abnormality notification memory, the abnormality cause tracing becomes easier.

図９〜図１１に示すごとく、異常監視モジュールの上記機能により、どれかのモジュールから異常通知があった場合は、シリアル通信処理の動作を一旦停止するために、どのモジュールも直ちにスリープ対応処理を行なう。これにより、通信異常発生時には、ＥＣＵ１が余計な動作を行なわず一旦スリープすることになり、ＥＣＵ動作を介して異常不具合が以降の処理に伝播することを防止できる。また、再度通信が必要か否かを上位のアプリケーションからの指示を待って判断することも可能となり、シリアル通信全体への影響を少なくすることができる。 As shown in FIG. 9 to FIG. 11, when an abnormality notification is received from any module by the above function of the abnormality monitoring module, any module immediately performs a sleep handling process in order to temporarily stop the serial communication processing operation. Do. Thereby, when a communication abnormality occurs, the ECU 1 sleeps without performing any extra operation, and it is possible to prevent an abnormal defect from being propagated to subsequent processes via the ECU operation. Further, it is possible to determine whether or not communication is necessary again after waiting for an instruction from a higher-level application, and the influence on the entire serial communication can be reduced.

図１２の処理流れからもわかる通り、異常監視モジュールは、各モジュールからの異常報告を受け付け、それらモジュールのスリープ移行処理を統括的に管理する。つまり、ＮＭモジュール、ＣＯＭモジュール及びＤＲＶモジュールのいずれかから異常発生通知を受けることにより、それらＮＭモジュール、ＣＯＭモジュール及びＤＲＶモジュールの全てにスリープ指令を行ない、制御ユニットハードウェアのスリープ設定を行なうことが明らかである。 As can be seen from the processing flow of FIG. 12, the abnormality monitoring module accepts abnormality reports from the modules and manages the sleep transition processing of these modules in an integrated manner. In other words, by receiving an abnormality occurrence notification from any one of the NM module, the COM module, and the DRV module, a sleep command is issued to all of the NM module, the COM module, and the DRV module, and the sleep setting of the control unit hardware can be performed. it is obvious.

本発明の自動車用スリープ制御システムの機能を有したＥＣＵの一例を示すブロック図。The block diagram which shows an example of ECU which has the function of the sleep control system for motor vehicles of this invention. 図１のシステムのアーキテクチャを示す模式図。FIG. 2 is a schematic diagram showing an architecture of the system of FIG. 1. スケジューラによる複数アプリケーションの実行サイクルの概念を模式的に示す図。The figure which shows typically the concept of the execution cycle of the some application by a scheduler. リセット及びスリープに係る状態遷移の模式図。The schematic diagram of the state transition which concerns on reset and sleep. 通信ソフトウェアの階層構造を示す模式図。The schematic diagram which shows the hierarchical structure of communication software. 状態データとミラーデータの概念図。The conceptual diagram of state data and mirror data. 通信制御メモリの内容を示す模式図。The schematic diagram which shows the content of the communication control memory. 各モジュールの実行サイクルを示す概念図。The conceptual diagram which shows the execution cycle of each module. ＮＭモジュールの処理の流れを示すフローチャート。The flowchart which shows the flow of a process of NM module. ＣＯＭモジュールの処理の流れを示すフローチャート。The flowchart which shows the flow of a process of a COM module. ＤＲＶモジュールの処理の流れを示すフローチャート。The flowchart which shows the flow of a process of DRV module. 異常監視モジュールの処理の流れを示すフローチャート。The flowchart which shows the flow of a process of an abnormality monitoring module.

符号の説明Explanation of symbols

１ＥＣＵ（自動車用制御ユニット）
1 ECU (Automotive control unit)

Claims

ＣＰＵからなる主制御部を有し、自動車上の他の制御ユニットとシリアル通信バスにより接続され、自動車上に搭載される電子機器の制御処理を、予め定められた複数のアプリケーションの実行に基づいて実施する自動車用制御ユニットであって、
前記アプリケーションによる前記電子機器の制御状態を管理するとともに、前記制御状態を判定して状態遷移処理を行なうアプリケーション状態管理手段と、
前記シリアル通信バスを介して前記アプリケーションが使用する制御用メッセージを受信する処理と、他方、前記アプリケーションからの制御用メッセージを前記シリアル通信バス上に送信する処理とを、前記主制御部による通信ソフトウェアの実行に基づいて実施するシリアル通信制御手段とを有し、前記通信ソフトウェアが、
前記制御用メッセージの前記通信バスへの送信ないし前記通信バスからの受信のために、前記通信バスに接続されたシリアル通信インターフェースを駆動する駆動モジュールと、
前記駆動モジュールと前記アプリケーションとの間の送受信中継処理として、前記アプリケーションからの制御用メッセージの送受信要求を受け付けるとともに、前記駆動モジュールが受信した制御用メッセージを前記アプリケーションに転送する一方、前記アプリケーションから送信要求のあった制御用メッセージを前記駆動モジュールに転送する中継モジュールと、
前記アプリケーション状態管理手段による制御状態が、該アプリケーションにおける前記制御用メッセージの送受信に適した状態に遷移しているか否かを判定し、該判定結果に基づいて前記駆動モジュール及び前記中継モジュールに対する前記制御用メッセージの送受信に関する指令を行なう駆動管理モジュールと、
前記駆動モジュール、前記中継モジュール及び前記駆動管理モジュールのうち、少なくとも前記駆動管理モジュールからの異常発生報告を受け、前記駆動モジュール、前記中継モジュール及び前記駆動管理モジュールのそれぞれに一元的な異常発生通知を行なう異常監視モジュールと、
を有することを特徴とする自動車用制御ユニット。 Based on the execution of a plurality of predetermined applications, a main control unit comprising a CPU is connected to another control unit on the automobile via a serial communication bus, and the electronic equipment mounted on the automobile is controlled. An automotive control unit to implement,
Application state management means for managing the control state of the electronic device by the application and performing state transition processing by determining the control state;
A process for receiving a control message used by the application via the serial communication bus, and a process for transmitting a control message from the application on the serial communication bus. Serial communication control means implemented based on the execution of, the communication software,
A drive module for driving a serial communication interface connected to the communication bus for transmitting the control message to the communication bus or receiving from the communication bus;
As a transmission / reception relay process between the driving module and the application, a control message transmission / reception request from the application is accepted, and the control message received by the driving module is transferred to the application, while being transmitted from the application. A relay module for transferring the requested control message to the drive module;
It is determined whether or not the control state by the application state management means has transitioned to a state suitable for transmission and reception of the control message in the application, and the control for the drive module and the relay module based on the determination result A drive management module that issues commands for sending and receiving messages
Of the drive module, the relay module, and the drive management module, an abnormality occurrence report is received from at least the drive management module, and a unified abnormality occurrence notification is sent to each of the drive module, the relay module, and the drive management module. An anomaly monitoring module to perform,
An automobile control unit comprising:

前記駆動管理モジュール、前記中継モジュール及び前記駆動モジュールが、予め定められた異常状態が成立した場合に、いずれも前記異常監視モジュールに異常報告を個別に行なう請求項１記載の自動車用制御ユニット。 The vehicle control unit according to claim 1, wherein each of the drive management module, the relay module, and the drive module individually reports an abnormality to the abnormality monitoring module when a predetermined abnormality state is established.

前記駆動管理モジュール、前記中継モジュール、前記駆動モジュール及び前記異常監視モジュールを、予め定められた時系列順序にて周期的に実行する請求項１又は請求項２に記載の自動車用制御ユニット。 The vehicle control unit according to claim 1 or 2, wherein the drive management module, the relay module, the drive module, and the abnormality monitoring module are periodically executed in a predetermined time-series order.

前記異常監視モジュールは、異常発生時に前記通信ソフトウェアの動作をスリープ状態に移行させるスリープ指示を行なう請求項１ないし請求項３のいずれか１項に記載の自動車用制御ユニット。 4. The automobile control unit according to claim 1, wherein the abnormality monitoring module issues a sleep instruction for shifting the operation of the communication software to a sleep state when an abnormality occurs. 5.

前記駆動管理モジュール、前記中継モジュール及び前記駆動モジュールがこの順序にて周期的に実行されるとともに、前記異常監視モジュールは、前記駆動管理モジュール、前記中継モジュール及び前記駆動モジュールのいずれかから異常発生通知を受けることにより、それら駆動管理モジュール、中継モジュール及び駆動モジュールの全てにスリープ指令を行ない、制御ユニットハードウェアのスリープ設定を行なう請求項４記載の自動車用制御ユニット。 The drive management module, the relay module, and the drive module are periodically executed in this order, and the abnormality monitoring module notifies the abnormality occurrence from any of the drive management module, the relay module, and the drive module. 5. The vehicle control unit according to claim 4, wherein upon receiving the command, a sleep command is issued to all of the drive management module, the relay module, and the drive module, and the sleep setting of the control unit hardware is performed.

前記アプリケーション状態管理手段が行なう前記状態遷移処理に伴い、遷移により設定された制御状態が制御状態特定情報の形で制御状態メモリに記憶され、
前記駆動管理モジュールは、前記制御状態メモリの記憶内容に基づいて前記アプリケーション側の異常判定を行ない、前記異常監視モジュールに異常発生報告を行なう請求項１ないし請求項５のいずれか１項に記載の自動車用制御ユニット。 Along with the state transition processing performed by the application state management means, the control state set by the transition is stored in the control state memory in the form of control state specifying information,
6. The drive management module according to claim 1, wherein the drive management module performs an abnormality determination on the application side based on the storage contents of the control state memory, and reports an abnormality occurrence to the abnormality monitoring module. 7. Control unit for automobiles.

前記制御状態メモリには、前記状態遷移が発生するたびに、制御状態特定情報とともに、そのミラー情報が記憶され、前記駆動管理モジュールは、該制御状態特定情報と該ミラー情報とを照合し、その照合結果に基づいて異常判定を行なう請求項６記載の自動車用制御ユニット。
Each time the state transition occurs, the control state memory stores the mirror information together with the control state specifying information, and the drive management module collates the control state specifying information with the mirror information, and The vehicle control unit according to claim 6, wherein abnormality determination is performed based on the collation result.