WO2022201597A1 - 車両制御装置 - Google Patents

車両制御装置 Download PDF

Info

Publication number
WO2022201597A1
WO2022201597A1 PCT/JP2021/035372 JP2021035372W WO2022201597A1 WO 2022201597 A1 WO2022201597 A1 WO 2022201597A1 JP 2021035372 W JP2021035372 W JP 2021035372W WO 2022201597 A1 WO2022201597 A1 WO 2022201597A1
Authority
WO
WIPO (PCT)
Prior art keywords
core
communication
data memory
shared data
vehicle control
Prior art date
Application number
PCT/JP2021/035372
Other languages
English (en)
French (fr)
Inventor
朋仁 蛯名
Original Assignee
日立Astemo株式会社
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 日立Astemo株式会社 filed Critical 日立Astemo株式会社
Priority to JP2023508440A priority Critical patent/JPWO2022201597A1/ja
Priority to DE112021005649.2T priority patent/DE112021005649T5/de
Publication of WO2022201597A1 publication Critical patent/WO2022201597A1/ja

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/02—Ensuring safety in case of control system failures, e.g. by diagnosing, circumventing or fixing failures
    • B60W50/023—Avoiding failures by using redundant parts
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/02—Ensuring safety in case of control system failures, e.g. by diagnosing, circumventing or fixing failures
    • B60W50/0225—Failure correction strategy
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W2050/0062—Adapting control system settings
    • B60W2050/0075—Automatic parameter input, automatic initialising or calibrating means
    • B60W2050/0082—Automatic parameter input, automatic initialising or calibrating means for initialising the control system
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W2050/0062—Adapting control system settings
    • B60W2050/0075—Automatic parameter input, automatic initialising or calibrating means
    • B60W2050/0083—Setting, resetting, calibration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
    • G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3024—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a central processing unit [CPU]

Definitions

  • the present invention relates to a vehicle control device, and more particularly to a vehicle control device having a multi-core CPU.
  • ECUs Electronic Control Units, that is, vehicle control devices
  • engine control brake control
  • transmission control transmission control
  • door control air conditioner control
  • ECUs Electronic Control Units
  • the ECU may have a multi-core CPU with multiple cores.
  • a multi-core CPU generally, when an abnormality occurs in one of the cores, the entire multi-core CPU is reset in order to recover from the abnormal state.
  • the entire multi-core CPU is reset, there is a problem that communication is interrupted between reset release and completion of OS initialization. Also, due to the communication interruption, other ECUs will determine that there is an abnormality.
  • Patent Document 1 can shorten the time from reset release to completion of OS initialization, there is still room for improvement.
  • the present invention has been made to solve such technical problems, and an object of the present invention is to provide a vehicle control device that can prevent interruption of communication from reset release to completion of OS initialization.
  • a vehicle control device comprises a multi-core CPU having at least a first core and a second core, a shared data memory configured to be accessible by each core and storing at least communication parameters, and operations of the multi-core CPU.
  • a monitoring circuit for monitoring and outputting a reset signal to the multi-core CPU, wherein the second core accesses the shared data memory from reset release to completion of OS initialization by the first core. It is characterized in that the communication parameters are confirmed, and communication with the outside is performed based on the communication parameters stored in the shared data memory.
  • the second core accesses the shared data memory to confirm the communication parameters and saves them in the shared data memory after the reset is released until the OS initialization is completed by the first core. Since communication with the outside is performed based on the communication parameters, communication can be performed without waiting for the completion of OS initialization. As a result, it is possible to prevent interruption of communication from reset release to completion of OS initialization.
  • FIG. 1 is a configuration diagram showing a vehicle control system including a vehicle control device according to a first embodiment
  • FIG. FIG. 5 is a sequence diagram showing control after reset release of the vehicle control device according to the first embodiment
  • FIG. 9 is a sequence diagram showing control before and after resetting of the vehicle control device according to the second embodiment
  • FIG. 11 is a sequence diagram showing control before and after resetting of the vehicle control device according to the third embodiment
  • FIG. 1 is a configuration diagram showing a vehicle control system provided with a vehicle control device according to the first embodiment.
  • a vehicle control device 10 of the present embodiment is configured by an ECU, and forms a vehicle control system together with a plurality of other ECUs (ECU 20, ECU 30).
  • the vehicle control device 10 is in charge of engine control
  • the ECU 20 is in charge of brake control
  • the ECU 30 is in charge of transmission control.
  • the vehicle control device 10, the ECU 20, and the ECU 30 are connected by an in-vehicle network 15 such as a CAN (Controller Area Network), etc., and communicate with each other through the in-vehicle network 15 to realize safe driving of the vehicle.
  • CAN Controller Area Network
  • the vehicle control device 10 mainly includes a multi-core CPU 11 and a monitoring IC (Integrated Circuit) 12 that monitors the operation of the multi-core CPU 11 .
  • a monitoring IC Integrated Circuit
  • the multi-core CPU 11 includes a plurality of cores (first core 111-1, second core 111-2, . . . n-th core 111-n) and a program memory (program memory 112-1, program memory 112-2, . . . program memory 112-n) and data memory (data memory 113-1, data memory 113-2, .
  • Each program memory and each data memory store programs and data for performing the functions of the corresponding core.
  • n is a natural number of 2 or more.
  • the program memory 112-1 corresponding to the first core 111-1 contains an initialization program for initializing the OS (Operating System) to be executed after the reset is released, and an initialization program assigned to the first core 111-1.
  • Application software hereinafter simply referred to as "application” for performing the processing is stored.
  • a program memory 112-2 corresponding to the second core 111-2 stores a communication program relating to communication processing to be executed after reset release and an application for performing processing assigned to the second core 111-2.
  • the monitoring IC 12 corresponds to the "monitoring unit" described in the claims, and monitors whether the multi-core CPU 11 is operating normally based on the signal 13 output from the multi-core CPU 11. Further, when the signal 13 is interrupted, the monitor IC 12 can output the reset signal 14 to the multi-core CPU 11 assuming that the multi-core CPU 11 is abnormal, and reset the multi-core CPU 11 . Furthermore, immediately after power-on (in other words, power-on), the power supply voltage is low, so the monitoring IC 12 can output the reset signal 14 to the multi-core CPU 11 to reset the multi-core CPU 11 . After the power supply voltage is stabilized, the monitor IC 12 stops outputting the reset signal 14 . As a result, the reset of the multi-core CPU 11 is released, and the multi-core CPU 11 starts operating.
  • the multi-core CPU 11 further comprises a shared data memory 115 accessible by each core, and a communication device 114 connected to each core. Each core is respectively connected to communication device 114 and shared data memory 115 via bus 116 .
  • the shared data memory 115 stores data such as communication parameters shared between cores. Communication parameters include communication speed, data size, and transmission cycle.
  • the multi-core CPU 11 may be composed of one IC, or may be composed of a plurality of ICs. Also, the monitoring IC 12 does not necessarily have to be provided independently from the multi-core CPU 11 , and a monitoring function corresponding to the monitoring IC 12 may be incorporated into the multi-core CPU 11 .
  • the vehicle control device 10 configured as described above is equipped with an OS, and programs related to each control process operate under the control of the OS. Then, when the multi-core CPU 11 is reset due to an abnormality or the like, the OS performs an initialization process after canceling the reset. In the OS initialization process, the OS initializes devices and applications, and further executes applications.
  • initialization is performed by one core in order to maintain initialization consistency.
  • the program memory 112-1 corresponding to the first core 111-1 stores an initialization program for initializing the OS to be executed after the reset is released. performs OS initialization processing after reset release.
  • the second core 111-2 executes the communication processing after the reset is released. conduct. At that time, the second core 111-2 accesses the shared data memory 115 to confirm the communication parameters by the communication program executed after the reset is released, and furthermore, based on the communication parameters saved in the shared data memory 115, Communicate with the outside world.
  • the communication processing of the second core 111-2 is executed in parallel with the initialization processing of the OS by the first core 111-1.
  • the communication is switched. That is, the communication program of the second core 111-2 is stopped, and communication processing led by the first core 111-1 is started.
  • steps S211 to S214 are processes performed by the first core 111-1
  • steps S221 to S225 are processes performed by the second core 111-2.
  • the first core 111-1 first activates the OS (step S211), and then performs OS initialization processing (step S212). At this time, the second core 111-2 performs each process in parallel with the process of the first core 111-1.
  • the second core 111-2 first accesses the shared data memory 115 and confirms the communication parameters (step S221). Confirmation of the communication parameters in this step is confirmation of whether or not normal communication parameters are set in the shared data memory 115 . Since the values in the shared data memory 115 are indefinite immediately after the power is turned on (in other words, immediately after the reset is released), normal communication parameters are not set. Therefore, the second core 111-2 performs communication parameter initialization processing (step S222). Subsequently, the second core 111-2 starts communication with an external device (eg, the ECU 20 or the ECU 30) via the communication device 114 based on the initialized communication parameters (step S223).
  • an external device eg, the ECU 20 or the ECU 30
  • the first core 111-1 activates an application related to communication (step S213).
  • the second core 111-2 performs communication switching processing (step S224). Specifically, the communication program of the second core 111-2 is stopped, and communication processing led by the first core 111-1 is performed. Subsequently, the first core 111-1 and the second core 111-2 execute their respective applications (steps S214 and S225).
  • the second core 111-2 accesses the shared data memory 115 for communication during the period from reset cancellation by turning on the power to completion of OS initialization by the first core 111-1.
  • communication with the external device is performed based on the initialized communication parameters, so communication is possible without waiting for the completion of OS initialization.
  • interruption of communication from reset release to completion of OS initialization is possible to avoid an abnormality determination from another ECU due to a communication interruption.
  • a vehicle control device 10 according to the second embodiment has the same structure as that of the first embodiment, but differs from the first embodiment in the control contents of the vehicle control device 10 . Only the differences will be described below.
  • an abnormality When an abnormality occurs, there is a method of resolving it by software-initializing the function in which the anomaly occurred, but there is also a method of resolving the anomaly by hardware-resetting the entire multi-core CPU.
  • a method of resolving an abnormality by resetting the entire multi-core CPU in terms of hardware is adopted.
  • the communication parameters currently in use Prior to resetting the entire multi-core CPU 11, the communication parameters currently in use are saved in the shared data memory 115, and after the reset is released, communication is performed based on the saved communication parameters currently in use. Continuity of communication before and after can be maintained.
  • the abnormality referred to in this embodiment is an abnormality that can be detected via a sensor or the like attached to the vehicle. Resets resulting from such anomalies are therefore intended resets.
  • steps S311 to S315 are processes performed by the first core 111-1
  • steps S321 to S325 are processes performed by the second core 111-2.
  • the first core 111-1 detects an abnormality (step S311), it instructs the second core 111-2 to save the currently used communication parameters.
  • the second core 111-2 stores the currently used communication parameters based on the instruction from the first core 111-1 (step S321). At this time, the second core 111-2 stores the currently used communication parameters in the shared data memory 115 instead of the data memory 113-2 corresponding to the second core 111-2.
  • communication parameters stored in shared data memory 115 are assumed to be communication parameters 331 .
  • the first core 111-1 transmits an instruction to generate a reset to the monitoring IC 12 (step S312). Subsequently, the multicore CPU 11 is reset.
  • the first core 111-1 first starts up the OS (step S313), and then performs OS initialization processing (step S314). At this time, the second core 111-2 performs each process in parallel with the process of the first core 111-1.
  • the second core 111-2 accesses the shared data memory 115 and checks the communication parameters 331 stored in the shared data memory 115 (step S322).
  • the confirmation of the communication parameters in this step is confirmation that the values in the memory are not undefined immediately after the power is turned on.
  • the second core 111-2 refers to the communication parameter 331 and performs communication parameter restoration processing (step S323).
  • the second core 111-2 starts communication with an external device (for example, the ECU 20 or the ECU 30) via the communication device 114 based on the restored communication parameter (that is, the communication parameter 331) (step S324).
  • the first core 111-1 activates an application related to communication and the like (step S315), and the second core 111-1 111-2 performs communication switching processing (step S325). After that, each process described in the first embodiment is performed.
  • the vehicle control device 10 of this embodiment in addition to obtaining the same effects as those of the first embodiment, the following effects are obtained. That is, the communication parameters currently in use are stored in the shared data memory 115 before resetting, and the second core 111-2 is set to the shared data memory 115 after the reset is released until the OS initialization by the first core 111-1 is completed. Since communication is performed based on the currently used communication parameters saved in the , it is possible to maintain continuity of communication before and after the reset. In addition, in the technique described in Patent Document 1, only initial communication is performed after the reset is canceled, so it is considered that there is a problem in that the continuity of communication cannot be maintained before and after the reset. According to the vehicle control device 10 of the present embodiment, it is possible to solve the technical problem described in Patent Document 1 above.
  • each data related to the communication parameter is duplicated or a checksum or hash is added. etc., can be used.
  • a communication program may be further stored in the shared data memory 115 in addition to the communication parameters.
  • shared data memory 115 may store a program that interprets and executes a script, such as a communication program written in a script language. In this way, even complicated communication processing can be handled.
  • a vehicle control device 10 according to the third embodiment has the same structure as that of the first embodiment, but differs from the first embodiment in the processing contents of the vehicle control device 10 . Only the differences will be described below.
  • FIG. 4 is a sequence diagram showing control before and after resetting of the vehicle control device according to the third embodiment.
  • steps S411 to S414 are processes performed by the first core 111-1
  • steps S421 to S424 are processes performed by the second core 111-2.
  • the first core 111-1 first performs processing for saving default values of communication parameters (step S411).
  • the default value of the communication parameter is the value of the communication parameter that is used when resetting occurs due to an unexpected abnormality, and is set in advance. A communication pattern indicating that the reset is due to an unexpected abnormality is preliminarily incorporated in this default value.
  • Default values are stored in shared data memory 115 using the techniques described above to distinguish them from indeterminate values in memory.
  • the default values stored in shared data memory 115 are assumed to be communication parameters 431 .
  • the monitoring IC 12 outputs a reset signal 14 to the multi-core CPU 11.
  • the multi-core CPU 11 is thereby reset.
  • the first core 111-1 first starts up the OS (step S412), and then performs OS initialization processing (step S413). At this time, the second core 111-2 performs each process in parallel with the process of the first core 111-1.
  • the second core 111-2 accesses the shared data memory 115, confirms the communication parameter 431 stored in the shared data memory 115, and checks that it is not an undefined value in the memory (step S421). ), and acquires the communication parameter 431 (step S422). As a result, the default value set in step S411 is acquired.
  • the second core 111-2 starts communication with an external device (eg, the ECU 20 or the ECU 30) via the communication device 114 based on the obtained communication parameters 431 (step S423). Since the communication parameter 431 incorporates a communication pattern indicating a reset due to an unexpected abnormality, the other ECUs (ECU 20 and ECU 30) can grasp it with the vehicle control device 10.
  • an external device eg, the ECU 20 or the ECU 30
  • the first core 111-1 activates an application related to communication (step S414)
  • the core 111-2 performs communication switching processing (step S424). After that, each process described in the first embodiment is performed.
  • the first core 111-1 presets default values of communication parameters and stores them in the shared data memory 115.
  • FIG. 1 When resetting occurs due to an unexpected abnormality, the second core 111-2 performs communication based on the default value, thereby enabling communication without waiting for completion of OS initialization. As a result, it is possible to prevent interruption of communication from reset release to completion of OS initialization. In addition, as a result, it is possible to avoid an abnormality determination from another ECU due to the communication interruption.
  • the default values of the communication parameters are set by the first core 111-1 in step S411. For example, only the flag is set. may be transmitted to the second core 111-2.
  • the reset pattern due to power-on (first embodiment), the intended reset pattern (second embodiment), and the reset pattern due to an unexpected abnormality (third embodiment).
  • first embodiment the reset pattern due to power-on
  • second embodiment the intended reset pattern
  • third embodiment the reset pattern due to an unexpected abnormality
  • vehicle control device 11 multi-core CPU 12 monitoring IC (monitoring unit) 13 signal 14 reset signal 15 in-vehicle network 20, 30 ECU 111-1 1st core 111-2 2nd core 111-n nth core 112-1, 112-2, . . . 112-n program memory 113-1, 113-2, . shared data memory 116 bus

Landscapes

  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Human Computer Interaction (AREA)
  • Transportation (AREA)
  • Mechanical Engineering (AREA)
  • Debugging And Monitoring (AREA)
  • Hardware Redundancy (AREA)

Abstract

車両制御装置１０は、第１コア１１１－１と第２コア１１１－２とを少なくとも有するマルチコアＣＰＵ１１と、各コアがアクセス可能に構成されて少なくとも通信パラメータを保存する共有データメモリ１１５と、マルチコアＣＰＵ１１の動作を監視するとともにマルチコアＣＰＵ１１にリセット信号を出力する監視ＩＣ１２とを備える。第２コア１１１－２は、リセット解除から第１コア１１１－１によるＯＳ初期化完了までの間に、共有データメモリ１１５にアクセスして通信パラメータの確認を行い、共有データメモリ１１５に保存される通信パラメータに基づいて外部との通信を行う。

Description

車両制御装置
　本発明は、車両制御装置に関し、特にマルチコアＣＰＵを備える車両制御装置に関する。
　本願は、２０２１年３月２２日に出願された日本国特願２０２１－０４６９５３号に基づき優先権を主張し、その内容をここに援用する。
　近年、自動車等の車両において、エンジン制御、ブレーキ制御、トランスミッション制御、ドア制御、エアコン制御等を行うために複数のＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ、すなわち車両制御装置）が搭載されている。これらのＥＣＵは、車載ネットワークを介して互いに通信し協働することにより、車両の安全走行等を実現している。
　ＥＣＵは、複数のコアを有するマルチコアＣＰＵを備える場合がある。マルチコアＣＰＵでは、一般的に、いずれかのコアに異常が生じた場合、異常状態から回復させるべくマルチコアＣＰＵ全体のリセットが行われる。しかし、マルチコアＣＰＵ全体がリセットされると、リセット解除からＯＳ初期化完了までの間に通信が途絶する問題がある。また、通信途絶によって、他のＥＣＵからは異常であると判定されてしまう。
　このような問題を解決するため、例えば下記特許文献１に記載のように、ＦＰＧＡ（Ｆｉｅｌｄ　Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）を使用してリセット解除からＯＳ初期化完了までの時間を短縮する技術が検討されている。
特開２０１３-２４６４９５号公報
　しかし、上記特許文献１に記載の技術では、リセット解除からＯＳ初期化完了までの時間を短縮できるが、改善余地があった。
　本発明は、このような技術課題を解決するためになされたものであって、リセット解除からＯＳ初期化完了までの間の通信の途絶を防止できる車両制御装置を提供することを目的とする。
　本発明に係る車両制御装置は、第１コアと第２コアとを少なくとも有するマルチコアＣＰＵと、各コアがアクセス可能に構成され、少なくとも通信パラメータを保存する共有データメモリと、前記マルチコアＣＰＵの動作を監視するとともに前記マルチコアＣＰＵにリセット信号を出力する監視回路と、を備え、前記第２コアは、リセット解除から前記第１コアによるＯＳ初期化完了までの間に、前記共有データメモリにアクセスして通信パラメータの確認を行い、前記共有データメモリに保存される通信パラメータに基づいて外部との通信を行うことを特徴としている。
　本発明に係る車両制御装置では、第２コアは、リセット解除から第１コアによるＯＳ初期化完了までの間に、共有データメモリにアクセスして通信パラメータの確認を行い、共有データメモリに保存される通信パラメータに基づいて外部との通信を行うので、ＯＳ初期化の完了を待たずに通信が可能となる。その結果、リセット解除からＯＳ初期化完了までの間の通信の途絶を防止することができる。
　本発明によれば、リセット解除からＯＳ初期化完了までの間の通信の途絶を防止することができる。
第１実施形態に係る車両制御装置を備えた車両制御システムを示す構成図である。 第１実施形態に係る車両制御装置のリセット解除後の制御を示すシーケンス図である。 第２実施形態に係る車両制御装置のリセット前後の制御を示すシーケンス図である。 第３実施形態に係る車両制御装置のリセット前後の制御を示すシーケンス図である。
　以下、図面を参照して本発明に係る車両制御装置の実施形態について説明する。
[第１実施形態]
　図１は第１実施形態に係る車両制御装置を備えた車両制御システムを示す構成図である。本実施形態の車両制御装置１０は、ＥＣＵにより構成され、他の複数のＥＣＵ（ＥＣＵ２０、ＥＣＵ３０）とともに車両制御システムを形成する。ここでは、例えば車両制御装置１０はエンジン制御を担当し、ＥＣＵ２０はブレーキ制御を担当し、ＥＣＵ３０はトランスミッション制御を担当する。そして、車両制御装置１０、ＥＣＵ２０及びＥＣＵ３０は、ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）等の車載ネットワーク１５により接続され、該車載ネットワーク１５で通信を行い協働することで、車両の安全走行等を実現している。
　図１に示すように、車両制御装置１０は主に、マルチコアＣＰＵ１１と、マルチコアＣＰＵ１１の動作を監視する監視ＩＣ（Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）１２とを備えている。
　マルチコアＣＰＵ１１は、複数のコア（第１コア１１１－１，第２コア１１１－２，…第ｎコア１１１－ｎ）と、複数のコアに対して１対１に設けられたプログラムメモリ（プログラムメモリ１１２－１，プログラムメモリ１１２－２，…プログラムメモリ１１２－ｎ）及びデータメモリ（データメモリ１１３－１，データメモリ１１３－２，…データメモリ１１３－ｎ）とを有する。各プログラムメモリ及び各データメモリは、対応するコアの機能を果たすためのプログラム及びデータを保存する。なお、ｎは２以上の自然数である。
　本実施形態において、第１コア１１１－１に対応するプログラムメモリ１１２－１には、リセット解除後に実行するＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）の初期化に関する初期化プログラムと、第１コア１１１－１に割り当てられた処理を行うためのアプリケーションソフトウェア（以下では、単に「アプリケーション」という）とが保存されている。第２コア１１１－２に対応するプログラムメモリ１１２－２には、リセット解除後に実行する通信処理に関する通信プログラムと、第２コア１１１－２に割り当てられた処理を行うためのアプリケーションとが保存されている。
　監視ＩＣ１２は、特許請求の範囲に記載の「監視部」に相当するものであり、マルチコアＣＰＵ１１から出力される信号１３に基づいて、マルチコアＣＰＵ１１が正常に動作しているか否かを監視する。また、監視ＩＣ１２は、信号１３が途絶した場合、マルチコアＣＰＵ１１に異常が発生しているものとしてリセット信号１４をマルチコアＣＰＵ１１に出力し、マルチコアＣＰＵ１１をリセットさせることができる。更に、電源投入（言い換えれば、電源ＯＮ）直後の場合、電源電圧が低電圧であるため、監視ＩＣ１２はリセット信号１４をマルチコアＣＰＵ１１に出力し、マルチコアＣＰＵ１１をリセットさせることができる。そして、電源電圧が安定した後、監視ＩＣ１２はリセット信号１４の出力を停止する。これによって、マルチコアＣＰＵ１１のリセットが解除され、マルチコアＣＰＵ１１が動作を開始する。
　マルチコアＣＰＵ１１は、各コアがアクセスできる共有データメモリ１１５と、各コアと接続される通信デバイス１１４とを更に備えている。各コアは、バス１１６を介して通信デバイス１１４及び共有データメモリ１１５とそれぞれ接続されている。共有データメモリ１１５には、コア間で共有する通信パラメータ等のデータが保存されている。通信パラメータとしては、通信速度、データサイズ及び送信周期等が挙げられる。
　マルチコアＣＰＵ１１は、一つのＩＣで構成されても良く、複数のＩＣで構成されても良い。また、監視ＩＣ１２は、必ずしもマルチコアＣＰＵ１１から独立して設ける必要がなく、該監視ＩＣ１２に相当する監視機能をマルチコアＣＰＵ１１に組み込むようにしても良い。
　このように構成された車両制御装置１０では、ＯＳを搭載しており、各制御処理に関するプログラムはＯＳの管理下で動作する。そして、異常等の原因でマルチコアＣＰＵ１１がリセットされた場合、ＯＳは、リセット解除後に初期化処理を行う。ＯＳの初期化処理では、ＯＳはデバイスの初期化及びアプリケーションの初期化を行い、更にアプリケーションの実行を行う。
　そして、複数のコアを有するマルチコアＣＰＵ１１では、初期化の一貫性を保つために、１つのコアにより初期化を実行するようになっている。上述したように、第１コア１１１－１に対応するプログラムメモリ１１２－１には、リセット解除後に実行するＯＳの初期化に関する初期化プログラムが保存されているので、従って、第１コア１１１－１はリセット解除後のＯＳ初期化処理を行う。
　一方、第２コア１１１－２に対応するプログラムメモリ１１２－２には、リセット解除後に実行する通信処理に関する通信プログラムが保存されているので、第２コア１１１－２はリセット解除後の通信処理を行う。その際に、第２コア１１１－２は、リセット解除後に実行する通信プログラムによって、共有データメモリ１１５にアクセスして通信パラメータの確認を行い、更に共有データメモリ１１５に保存される通信パラメータに基づいて外部との通信を行う。なお、第２コア１１１－２の通信処理は、第１コア１１１－１によるＯＳの初期化処理と並行して実行される。
　そして、第１コア１１１－１によるＯＳ初期化処理が完了し、第１コア１１１－１におけるアプリケーションの起動した時点で、通信の切り替えが行われる。すなわち、第２コア１１１－２の通信プログラムが停止し、第１コア１１１－１が主導する通信処理を開始する。
　以下、図２を基に車両制御装置１０におけるリセット解除後の制御を説明する。ここでは、電源ＯＮによるリセットの解除から、ＯＳの初期化、通信、アプリケーション実行といった一連の処理の例を挙げて説明する。なお、図２において、ステップＳ２１１～Ｓ２１４は第１コア１１１－１により行われる処理であり、ステップＳ２２１～Ｓ２２５は第２コア１１１－２により行われる処理である。
　図２に示すように、電源ＯＮによるリセット解除後、第１コア１１１－１は、まずＯＳを起動し（ステップＳ２１１）、次にＯＳの初期化処理を行う（ステップＳ２１２）。このとき、第２コア１１１－２は、第１コア１１１－１の処理と並行して各処理を行う。
　具体的には、第２コア１１１－２は、まず共有データメモリ１１５にアクセスし、通信パラメータの確認を行う（ステップＳ２２１）。本ステップにおける通信パラメータの確認は、共有データメモリ１１５に正常な通信パラメータが設定されているか否かの確認である。電源ＯＮ直後（言い換えれば、リセット解除直後）は、共有データメモリ１１５の値は不定値であるので、正常な通信パラメータは設定されていない。このため、第２コア１１１－２は通信パラメータ初期化の処理を行う（ステップＳ２２２）。続いて、第２コア１１１－２は、初期化した通信パラメータに基づき、通信デバイス１１４を介して外部装置（例えばＥＣＵ２０やＥＣＵ３０）との通信を開始する（ステップＳ２２３）。
　そして、第１コア１１１－１によるＯＳの初期化処理が完了すると、第１コア１１１－１は、通信等に関するアプリケーションを起動する（ステップＳ２１３）。このとき、第２コア１１１－２は、通信切り替えの処理を行う（ステップＳ２２４）。具体的には、第２コア１１１－２の通信プログラムが停止し、第１コア１１１－１が主導する通信処理が行われる。続いて、第１コア１１１－１と第２コア１１１－２は、それぞれのアプリケーションを実行する(ステップＳ２１４とステップＳ２２５)。
　本実施形態の車両制御装置１０によれば、電源ＯＮによるリセット解除から第１コア１１１－１によるＯＳ初期化完了までの間に、第２コア１１１－２は共有データメモリ１１５にアクセスして通信パラメータの確認を行い、通信パラメータの初期化処理を行った後に、初期化した通信パラメータに基づいて外部装置との通信を行うので、ＯＳ初期化の完了を待たずに通信が可能となる。その結果、リセット解除からＯＳ初期化完了までの間の通信の途絶を防止することができる。更に、これによって、通信途絶に起因する他のＥＣＵからの異常判定を回避することができる。
［第２実施形態］
　第２実施形態に係る車両制御装置１０は、上記第１実施形態と同様な構造を有するが、車両制御装置１０の制御内容において上記第１実施形態と相違している。以下では、その相違点のみを説明する。
　従来では、例えばエンジン制御とモータ制御のような異なる機能について、別々のＥＣＵを設けてそれぞれの制御を行っていた。近年、装置のコンパクト化やコスト削減等を図るために、異なる機能を持つＥＣＵを統合することが進められている。そして、統合ＥＣＵにおいては、ある機能に異常が発生しても、他の機能の動作を継続することが求められている。
　異常が発生した場合は、該異常が発生した機能をソフトウェア的に初期化することにより解消する手法があるが、マルチコアＣＰＵ全体をハードウェア的にリセットすることで異常を解消する手法も考えられる。本実施形態では、マルチコアＣＰＵ全体をハードウェア的にリセットすることで異常を解消する手法が採用されている。そして、マルチコアＣＰＵ１１全体のリセットに先立ち、現在使用中の通信パラメータを共有データメモリ１１５に保存しておき、リセット解除後に上記保存された現在使用中の通信パラメータに基づいて通信を行うことにより、リセット前後における通信の連続性を維持することができる。なお、本実施形態でいう異常は、車両に取り付けられたセンサ等を介して検出できる異常である。従って、このような異常に起因するリセットは、意図したリセットである。
　以下、図３を基に本実施形態に係る車両制御装置のリセット前後の制御を説明する。図３において、ステップＳ３１１～Ｓ３１５は第１コア１１１－１により行われる処理であり、ステップＳ３２１～Ｓ３２５は第２コア１１１－２により行われる処理である。
　図３に示すように、第１コア１１１－１は、異常を検出すると（ステップＳ３１１）、現在使用中の通信パラメータを保存するように第２コア１１１－２に指示する。第２コア１１１－２は、第１コア１１１－１からの指示に基づき、現在使用中の通信パラメータを保存する（ステップＳ３２１）。このとき、第２コア１１１－２は、現在使用中の通信パラメータを該第２コア１１１－２に対応するデータメモリ１１３－２ではなく、共有データメモリ１１５に保存させる。ここで、共有データメモリ１１５に保存される通信パラメータを通信パラメータ３３１とする。
　続いて、第１コア１１１－１は、監視ＩＣ１２に対し、リセット発生する指示を送信する（ステップＳ３１２）。続いて、マルチコアＣＰＵ１１はリセットされる。
　リセット解除後、第１コア１１１－１は、まずＯＳを起動し（ステップＳ３１３）、次にＯＳ初期化の処理を行う（ステップＳ３１４）。このとき、第２コア１１１－２は、第１コア１１１－１の処理と並行して各処理を行う。
　具体的には、第２コア１１１－２は、共有データメモリ１１５にアクセスし、共有データメモリ１１５に保存されている通信パラメータ３３１の確認を行う（ステップＳ３２２）。本ステップにおける通信パラメータの確認は、電源ＯＮ直後のメモリの不定値ではないことの確認である。続いて、第２コア１１１－２は、通信パラメータ３３１を参照し、通信パラメータの復帰処理を行う（ステップＳ３２３）。続いて、第２コア１１１－２は、復帰した通信パラメータ（すなわち、通信パラメータ３３１）に基づき、通信デバイス１１４を介して外部装置（例えばＥＣＵ２０やＥＣＵ３０）との通信を開始する（ステップＳ３２４）。
　そして、第１コア１１１－１によるＯＳの初期化処理が完了すると、第１実施形態で述べたように、第１コア１１１－１は通信等に関するアプリケーションを起動し（ステップＳ３１５）、第２コア１１１－２は通信切り替えの処理を行う（ステップＳ３２５）。その後、第１実施形態で述べた各処理はそれぞれ行われる。
　本実施形態の車両制御装置１０によれば、上述第１実施形態と同様な作用効果を得られるほか、更に以下の作用効果を奏する。すなわち、リセット前に現在使用中の通信パラメータを共有データメモリ１１５に保存し、リセット解除から第１コア１１１－１によるＯＳ初期化完了までの間に、第２コア１１１－２は共有データメモリ１１５に保存される現在使用中の通信パラメータに基づいて通信を行うので、リセット前後における通信の連続性を維持することができる。なお、上記特許文献１に記載の技術では、リセット解除後に初期通信のみを行うので、リセット前後における通信の連続性を維持できない問題が生じると考えられる。本実施形態の車両制御装置１０によれば、上記特許文献１に記載の技術の問題を解決することができる。
　なお、本実施形態において、通信パラメータが正常な値か、電源ＯＮ直後のメモリの不定値かを区別するためには、通信パラメータに関する各データを二重化したり、チェックサムやハッシュを付加したりする等、既知の手法を用いることができる。
　また、本実施形態において、通信パラメータに加えて通信プログラムを更に共有データメモリ１１５に保存するようにしても良い。このようにすれば、複雑な通信処理にも対応できるので、例えば可変値を含む通信も可能となる。更に、共有データメモリ１１５には、スクリプトを解釈して実行するプログラムが保存されても良く、例えばスクリプト言語で記述された通信プログラムが保存される。このようにすれば、複雑な通信処理にも対応できる。
［第３実施形態］
　第３実施形態に係る車両制御装置１０は、上記第１実施形態と同様な構造を有するが、車両制御装置１０の処理内容において上記第１実施形態と相違している。以下では、その相違点のみを説明する。
　図４は第３実施形態に係る車両制御装置のリセット前後の制御を示すシーケンス図である。図４において、ステップＳ４１１～Ｓ４１４は第１コア１１１－１により行われる処理であり、ステップＳ４２１～Ｓ４２４は第２コア１１１－２により行われる処理である。
　図４に示すように、第１コア１１１－１は、まず通信パラメータのデフォルト値の保存処理を行う（ステップＳ４１１）。通信パラメータのデフォルト値は、予期せぬ異常によってリセットが起きた場合に使用される通信パラメータの値であって、予め設定されたものである。このデフォルト値には、予期せぬ異常によるリセットであることを示す通信パターンが予め組み込まれている。デフォルト値は、上述したメモリの不定値と区別するための手法を用いて共有データメモリ１１５に保存されている。ここで、共有データメモリ１１５に保存されるデフォルト値を通信パラメータ４３１とする。
　そして、マルチコアＣＰＵ１１に予期せぬ異常が発生した場合、監視ＩＣ１２は、リセット信号１４をマルチコアＣＰＵ１１に出力する。これによって、マルチコアＣＰＵ１１はリセットされる。
　リセット解除後、第１コア１１１－１は、まずＯＳを起動し（ステップＳ４１２）、次にＯＳ初期化の処理を行う（ステップＳ４１３）。このとき、第２コア１１１－２は、第１コア１１１－１の処理と並行して各処理を行う。
　具体的には、第２コア１１１－２は、共有データメモリ１１５にアクセスし、共有データメモリ１１５に保存されている通信パラメータ４３１を確認し、メモリの不定値ではないことをチェックし（ステップＳ４２１）、通信パラメータ４３１を取得する（ステップＳ４２２）。これによって、ステップＳ４１１で設定されたデフォルト値が取得される。
　続いて、第２コア１１１－２は、取得した通信パラメータ４３１に基づき、通信デバイス１１４を介して外部装置（例えばＥＣＵ２０やＥＣＵ３０）との通信を開始する（ステップＳ４２３）。そして、通信パラメータ４３１には予期せぬ異常によるリセットのことを示す通信パターンが組み込まれているため、他のＥＣＵ（ＥＣＵ２０及びＥＣＵ３０）は車両制御装置１０でそれを把握できる。
　そして、第１コア１１１－１によるＯＳの初期化処理が完了すると、第１実施形態で述べたように、第１コア１１１－１は、通信等に関するアプリケーションを起動し（ステップＳ４１４）、第２コア１１１－２は、通信切り替え処理を行う（ステップＳ４２４）。その後、第１実施形態で述べた各処理がそれぞれ行われる。
　本実施形態の車両制御装置１０では、第１コア１１１－１は通信パラメータのデフォルト値を予め設定し、共有データメモリ１１５に保存しておく。そして、予期せぬ異常によってリセットが生じた場合、第２コア１１１－２は該デフォルト値に基づいて通信を行うことで、ＯＳ初期化の完了を待たずに通信が可能となる。その結果、リセット解除からＯＳ初期化完了までの間の通信の途絶を防止することができる。また、これによって、通信途絶に起因する他のＥＣＵからの異常判定を回避することができる。
　なお、本実施形態において、通信パラメータのデフォルト値はステップＳ４１１で第１コア１１１－１により設定されるが、例えばフラグのみを設定し、ステップＳ４２１では、フラグが検知されると、固定の通信パラメータを第２コア１１１－２に送信するようにしても良い。
　また、上記３つの実施形態において、電源ＯＮによるリセットのパターン（第１実施形態）、意図したリセットのパターン（第２実施形態）、及び、予期せぬ異常によるリセットのパターン（第３実施形態）をそれぞれ説明した。例えば他のＥＣＵへの通信データに上記３つのパターンをそれぞれ識別できる識別番号等を付した状態で送信すれば、他のＥＣＵに車両制御装置１０が正常か異常かを明確に伝えることができる。
　以上、本発明の実施形態について詳述したが、本発明は、上述の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の精神を逸脱しない範囲で、種々の設計変更を行うことができるものである。
１０　　車両制御装置
１１　　マルチコアＣＰＵ
１２　　監視ＩＣ（監視部）
１３　　信号
１４　　リセット信号
１５　　車載ネットワーク
２０，３０　　ＥＣＵ
１１１－１　　第１コア
１１１－２　　第２コア
１１１－ｎ　　第ｎコア
１１２－１，１１２－２，…１１２－ｎ　　プログラムメモリ
１１３－１，１１３－２，…１１３－ｎ　　データメモリ
１１４　　通信デバイス
１１５　　共有データメモリ
１１６　　バス

Claims (5)

  1. 　第１コアと第２コアとを少なくとも有するマルチコアＣＰＵと、
    　各コアがアクセス可能に構成され、少なくとも通信パラメータを保存する共有データメモリと、
    　前記マルチコアＣＰＵの動作を監視するとともに前記マルチコアＣＰＵにリセット信号を出力する監視部と、
    を備え、
    　前記第２コアは、リセット解除から前記第１コアによるＯＳ初期化完了までの間に、前記共有データメモリにアクセスして通信パラメータの確認を行い、前記共有データメモリに保存される通信パラメータに基づいて外部との通信を行うことを特徴とする車両制御装置。
  2. 　前記共有データメモリには、リセット前の現在使用中の通信パラメータが保存され、
    　前記第２コアは、前記共有データメモリに保存される現在使用中の通信パラメータに基づいて外部との通信を行う請求項１に記載の車両制御装置。
  3. 　前記共有データメモリには、通信を行うプログラムが更に保存されている請求項１又は２に記載の車両制御装置。
  4. 　前記共有データメモリには、スクリプトを解釈して実行するプログラムが更に保存されている請求項１又は２に記載の車両制御装置。
  5. 　前記共有データメモリには、通信パラメータのデフォルト値が更に保存され、
    　予期せぬ異常によってリセットされた場合に、前記第２コアは前記デフォルト値に基づいて外部との通信を行う請求項１～４のいずれか一項に記載の車両制御装置。
PCT/JP2021/035372 2021-03-22 2021-09-27 車両制御装置 WO2022201597A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2023508440A JPWO2022201597A1 (ja) 2021-03-22 2021-09-27
DE112021005649.2T DE112021005649T5 (de) 2021-03-22 2021-09-27 Fahrzeugsteuervorrichtung

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021-046953 2021-03-22
JP2021046953 2021-03-22

Publications (1)

Publication Number Publication Date
WO2022201597A1 true WO2022201597A1 (ja) 2022-09-29

Family

ID=83395502

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/035372 WO2022201597A1 (ja) 2021-03-22 2021-09-27 車両制御装置

Country Status (3)

Country Link
JP (1) JPWO2022201597A1 (ja)
DE (1) DE112021005649T5 (ja)
WO (1) WO2022201597A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008305317A (ja) * 2007-06-11 2008-12-18 Toyota Motor Corp マルチプロセッサシステム及びその制御方法
JP2013054434A (ja) * 2011-09-01 2013-03-21 Fujitsu Ltd Ｉ／ｏ制御装置およびｉ／ｏ制御方法
WO2017022364A1 (ja) * 2015-08-04 2017-02-09 オリンパス株式会社 異常監視方法及び異常監視装置
JP2018092571A (ja) * 2016-04-20 2018-06-14 株式会社リコー 電子装置、再起動方法およびプログラム

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013246495A (ja) 2012-05-23 2013-12-09 Hitachi Kokusai Electric Inc 通信装置
JP7360285B2 (ja) 2019-09-17 2023-10-12 東芝キヤリア株式会社 空気調和機

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008305317A (ja) * 2007-06-11 2008-12-18 Toyota Motor Corp マルチプロセッサシステム及びその制御方法
JP2013054434A (ja) * 2011-09-01 2013-03-21 Fujitsu Ltd Ｉ／ｏ制御装置およびｉ／ｏ制御方法
WO2017022364A1 (ja) * 2015-08-04 2017-02-09 オリンパス株式会社 異常監視方法及び異常監視装置
JP2018092571A (ja) * 2016-04-20 2018-06-14 株式会社リコー 電子装置、再起動方法およびプログラム

Also Published As

Publication number Publication date
DE112021005649T5 (de) 2023-10-05
JPWO2022201597A1 (ja) 2022-09-29

Similar Documents

Publication Publication Date Title
EP2641176B1 (de) Mikroprozessorsystem mit fehlertoleranter architektur
US10102045B2 (en) Control device, control method and program
EP3249534B1 (en) Vehicle control device
US10698463B2 (en) Controller, control method, and program for power cut state restoration
CN102741818A (zh) 故障诊断系统、用于车辆的电子控制单元、故障诊断方法
KR20160110203A (ko) 안전 관련 중대한 에러를 처리하는 방법 및 장치
US11846923B2 (en) Automation system for monitoring a safety-critical process
CN105653306A (zh) 显示启动设置界面的方法和装置
JP2003115847A (ja) 制御システム及び冗長系信号処理装置
WO2022201597A1 (ja) 車両制御装置
KR20090000008A (ko) 차량진단시 진단단말기간의 충돌방지 시스템 및 그 방법
CA2106899A1 (en) Central unit for a process control system
US11982984B2 (en) Automation system for monitoring a safety-critical process
CN110103858B (zh) 汽车电子ecu与传感器连接系统和方法
JP2004221904A (ja) フィールドバスシステムの通信速度制御方法及びマスタユニット
JP2008310536A (ja) 安全リモートｉ／ｏターミナル
US11385977B2 (en) Reconfiguration control device
WO2022209458A1 (ja) 表示制御装置、表示制御方法
KR102275869B1 (ko) 차량 제어 장치 및 차량 제어 방법
WO2023106073A1 (ja) 車載装置、プログラム及び情報処理方法
DE102019200880A1 (de) Rechensystem zum Betreiben einer Infotainmenteinrichtung eines Fahrzeugs sowie Verfahren zum Aktivieren eines Reduktionsmodus für ein Rechensystem und Kraftfahrzeug
GB2146810A (en) Achieving redundancy in a distributed process control system
JP2018151717A (ja) 自動車用電子制御装置
JPH06161974A (ja) マルチｃｐｕボードの診断方法
CN117687338A (zh) 一种高安全多级看门狗架构控制系统、方法及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21933196

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 112021005649

Country of ref document: DE

WWE Wipo information: entry into national phase

Ref document number: 2023508440

Country of ref document: JP

122 Ep: pct application non-entry in european phase

Ref document number: 21933196

Country of ref document: EP

Kind code of ref document: A1