JP6504065B2 - Vehicle control system - Google Patents

Description

  The present invention relates to a vehicle control system that performs processing in which a first electronic control unit and a second electronic control unit cooperate to control in-vehicle devices mounted on a vehicle.

For example, Patent Document 1 describes an on-vehicle electronic device control system including a plurality of control units arranged hierarchically. This on-vehicle electronic device control system is applied to, for example, operation control of the rear defogger and the defroster. The on-vehicle electronic device control system includes a control unit ECU ₁₁ of a rear control device of a basic control system, and a control unit ECU ₂₁ of an automation extension function system positioned above it. Further, the on-vehicle electronic device control system includes a control unit ECU ₁₂ of the basic control system of the defroster and a control unit ECU ₂₂ of the automation extended function system located above it. Furthermore, the on-vehicle electronic device control system has a cooperative control unit ECU ₃₁ positioned above the control unit ECU ₂₁ of the rear extended sensor automation extended function system and the control unit ECU ₂₂ of the defroster automated extension function system.

In such a configuration, when the rear differential switch is turned on, the control unit ECU ₁₁ of the basic control system controls energization of the rear defogger. At this time, the control unit ECU ₂₁ of the automation extended function system performs timer measurement of the operation continuation time of the rear defogger and performs automatic control of automatically turning off the rear defogger when the time is up.

Also, when the front differential switch is turned on, the control unit ECU ₂₁ of the basic control system selects the defroster as the air outlet mode. Then, the control unit ECU ₂₂ of the automation extended function system records the outside air temperature detected by the outside air temperature sensor and the operation history of the front differential switch by the user, and cumulatively learns the window fogging condition. The control unit ECU ₂₂ of the automation extended function system performs automatic control of automatically turning on the defroster even if the front differential switch is not operated, when the detected outside air temperature satisfies the window fogging condition next time.

Further, the cooperation control unit ECU ₃₁ records operation history of the rear defogger and the defroster, and performs cooperation operation learning. For example, when the rear defroster operates as a learning result that operates simultaneously with a certain frequency or more at the time of operation of the defroster, when the defroster starts the operation, the cooperative control unit ECU ₃₁ controls the control unit of the rear extension of the automatic extended function system. A command to automatically turn on the rear defogger is output to the ECU ₂₁ .

JP, 2009-56817, A

  Like the on-vehicle electronic device control system described in Patent Document 1 described above, the control system may be configured by a plurality of electronic control devices (control units), and cooperative control may be performed by each electronic control device. In order to perform such linked control, for example, it is assumed that signals and processing procedures exchanged between the electronic control units are strictly defined in advance, and a linked processing application program corresponding to it is created. In this case, the control system becomes a so-called special-purpose product, for example, corresponding to variations from low function to high function according to the grade of the vehicle and the type of vehicle, or corresponding to a change in hardware constituting the electronic control device. It becomes difficult to

  Therefore, when performing processing in which the first electronic control device and the second electronic control device cooperate, basic software for performing cooperative processing application programs in addition to the cooperation processing application. It is conceivable to provide the first and second electronic control devices with an OS program that plays the role of.

  For example, the OS program supports verification of communication data between electronic control units, conversion of data, synchronization mechanism, allocation of resources, etc., so that the application program for cooperation processing in the first and second electronic control units is , Can be created specifically for each control function, it becomes possible to easily cope with addition or change of control function. In addition, since each OS program can abstract the hardware of each electronic control device, the versatility of the cooperation processing application can be enhanced also in this respect.

  However, when the first and second electronic control devices are respectively provided with OS programs that support the cooperative processing by the first and second electronic control devices, those OS programs cooperate under a defined role assignment. Need to work. However, assuming that the division of roles is always constant, the roles do not necessarily match the capabilities of the respective electronic control devices, for example, due to the difference in the capabilities of the electronic control devices used, etc. There is a risk that support can not be performed efficiently.

  The present invention has been made in view of the above-described point, and the first electronic control unit and the second electronic control are performed by the OS program respectively provided in the first electronic control unit and the second electronic control unit. An object of the present invention is to provide a vehicle control system capable of efficiently supporting cooperative processing with a device.

In order to achieve the above object, a control system for a vehicle according to the present invention
In order to control the in-vehicle devices (31 to 33) mounted on the vehicle, the first electronic control unit (40) and the second electronic control unit (60, 70, 80) perform processing in cooperation with each other. There,
The first electronic control unit and the second electronic control unit respectively have cooperative processing application programs (41a, 61a, 71a, 81a) for performing cooperative processing, and cooperate with the cooperative processing application programs. Each having a first OS program (41b) and a second OS program (61b, 71b, 81b) operating cooperatively under a predetermined role allotment serving as basic software for executing Yes,
The second OS program held by the second electronic control device is selected from a plurality of roles that share the role,
The first OS program held by the first electronic control device is configured to be able to change the role to be shared, whereby it is possible to perform an operation coordinated with any second OS program among a plurality of different roles to be shared. And
The first electronic control unit is
An acquisition unit (S100) for acquiring information on the role shared by the second OS program from the second electronic control device;
A determination unit (S120) that determines the role to be shared by the first OS program so that it can operate in cooperation with the second OS program based on the information indicating the role shared by the second OS program acquired by the acquisition unit And.

  As described above, according to the vehicle control system of the present invention, the first OS program held by the first electronic control device acquires information about the role shared by the second OS program, and the second OS program shares Based on the information indicating the role, the role to be shared by the first OS program is determined so that it can operate in coordination with the second OS program. Therefore, for example, even if the role assignment of the second OS program changes due to the ability of the second electronic control device, the first OS program operates in cooperation with the second OS program according to the change of the role assignment As you can, you can automatically change the role of sharing. As a result, the OS program provided in the first electronic control device and the second electronic control device can efficiently support cooperative processing of the first electronic control device and the second electronic control device. become.

  The reference numerals in the parentheses above merely show an example of the correspondence with specific configurations in the embodiments to be described later so as to facilitate understanding of the present invention, and it is intended to limit the scope of the present invention in any way. It is not intended.

  The technical features described in the claims of the claims other than the features described above will be apparent from the description of the embodiments to be described later and the accompanying drawings.

It is a block diagram showing composition of a control system for vehicles concerning an embodiment. FIG. 7 is a diagram showing an example in which a PTC of an exercise domain control unit is implemented as a PTC application in an electronic control device, and an OS program is provided as one of application software of the electronic control device. It is a figure which shows the example of the list of the service which OS program provides. It is a flowchart which shows the specific processing content of the 1st OS program in master ECU. It is a flowchart which shows the specific processing content of the 2nd OS program in slave ECU. It is a figure which shows the example which lightened the role of the 1st OS program of master ECU, and made the role of the 2nd OS program in a slave ECU heavy. It is a figure which shows the example which made the role of the 1st OS program of a master ECU heavy, and made the role of the 2nd OS program in a slave ECU light. It is an explanatory view for explaining some examples which a 1st OS program of master ECU judges that change of transfer information to a 2nd OS program is required. It is an explanatory view for explaining some examples in which the 1st OS program of master ECU receives the change demand of operating conditions from the 2nd OS program of slave ECU.

  Hereinafter, a control system for a vehicle according to an embodiment of the present invention will be described with reference to the drawings. The control system 1 for a vehicle according to the present embodiment is applied to a hybrid vehicle having an engine 31 and an electric motor (motor generator) 33 as a traveling drive source, as shown in FIG. 1, for example. It is used to control the various in-vehicle devices 31 to 35. However, the vehicle control system 1 according to the present embodiment is not limited to the application of the on-vehicle devices 31 to 35 in a hybrid vehicle to control, and includes only a normal vehicle having only an engine and only an electric motor. The present invention may be applied to control of in-vehicle devices of an electric vehicle.

  FIG. 1 is a functional block diagram showing an example of various functions of the vehicle control system 1 in order to control the plurality of on-vehicle devices 31 to 35 in the hybrid vehicle described above. However, not all the functions of the vehicle control system 1 are shown in FIG. This is because FIG. 1 shows only one example of the configuration of the vehicle control system 1 according to the present embodiment for the convenience of description.

  In FIG. 1, the vehicle control system 1 has a function for controlling an engine 31, a transmission (TM) 32, a motor generator (MG) 33, a brake device 34, a steering device 35 and the like as in-vehicle devices. However, as described above, the vehicle control system 1 may further have a function for controlling other in-vehicle devices such as, for example, a suspension, a high voltage battery, and an air conditioner.

  As shown in FIG. 1, in the vehicle control system 1, functions for controlling various in-vehicle devices 31 to 35 are divided in advance into a plurality of logical blocks (functional blocks) 12 to 16 and 22 to 26. Are defined by defining the connection between the logic blocks 12-16 and 22-26. That is, the logic structure for controlling various in-vehicle devices 31 to 35 in the vehicle control system 1 is based on the connection between the logic blocks 12 to 16 and 22 to 26 and the logic blocks 12 to 16 and 22 to 26. It is prescribed. The vehicle control system 1 controls the various on-vehicle devices 31 to 35 by operating the plurality of logic blocks 12 to 16 and 22 to 26 in cooperation in accordance with the defined connection relationship.

  Although not shown in FIG. 1, each of the logic blocks 12 to 16 and 22 to 26 has at least one, usually a large number of control blocks. The respective logic blocks 12 to 16 and 22 to 26 exert their respective functions (roles) by appropriately combining the arithmetic processing in the large number of control blocks.

  For example, the engine control unit 24 as a logic block has a control block that inputs sensor signals from various sensors and converts them into signals that can be handled in the logic block in order to detect the operating state of the engine 31. . Moreover, the control block which calculates the present generation torque from the driving | running state of the engine 31 grasped | ascertained from a sensor signal is provided. Furthermore, if there is a difference between the command torque instructed from the upper logic block (power train coordinator (PTC) 22) and the current generated torque, control to calculate the target engine operating state to eliminate the difference. Have a block. Further, a control block is provided to calculate the throttle valve opening degree, the fuel injection amount, the fuel injection timing, and the ignition timing for achieving the target engine operating condition. However, these are merely examples, and the engine control unit 24 may have a control block that performs other arithmetic processing necessary to exert its function. In addition, the control blocks in the engine control unit 24, including the illustrated control blocks, can be integrated or divided as appropriate.

  The control system 1 for vehicles is actually embodied by allocating each logic block 12-16 and 22-26 to a plurality of electronic control devices as control applications, such as a program and a database, and implementing them. In this case, the plurality of electronic control units are connected via separate communication lines, or each electronic control unit is connected to a common network so as to maintain the connection of the logic blocks 12-16 and 22-26. Desired electronic control devices according to the connection relationship may be configured to be communicable with each other. The logic blocks 12 to 16 and 22 to 26 do not necessarily have to be mounted on separate electronic control units, but several logic blocks may be mounted on a common electronic control unit.

  Control system 1 for vehicles concerning this embodiment is beforehand divided into a plurality of domains according to a function of a plurality of in-vehicle devices 31-35. In other words, each of the logical blocks 12 to 16 and 22 to 26 is divided into a plurality of domains 10 and 20 in advance according to a group of functions to be performed.

  The plurality of in-vehicle devices 31 to 35 are allocated to one of the domains 10 and 20. Then, the domain control units 11 and 21 belonging to the allocated domains 10 and 20 calculate control target values of the on-vehicle devices 31 to 35, and control the on-vehicle devices 31 to 35. , 24 to 26 and so on. As shown in FIG. 1, each of the domain control units 11 and 21 includes at least one logical block.

  Specifically, in the example shown in FIG. 1, the control system 1 is divided into an exercise domain 10 and an energy domain 20. The exercise domain control unit 11 is provided in the exercise domain 10 to control the behavior of the vehicle in the front-rear direction and the lateral direction. Further, in the energy domain 20, an energy domain control unit 21 having a function of controlling the power of the vehicle is provided so as to accelerate or decelerate the vehicle or keep the speed constant.

  Further, in the vehicle control system 1 according to the present embodiment, as shown in FIG. 1, according to commands (control target values) from the corresponding domain control units 11 and 21 under the respective domain control units 11 and 21, On-vehicle device control units 15, 16, 24 to 26 are provided to control the operating states of the on-vehicle devices 31 to 35. The in-vehicle device control units 15, 16, 24 to 26 generate control signals for bringing the operating states of the in-vehicle devices 31 to 35 close to the control target values from the domain control units 11 and 21, respectively. Output to 35.

  Specifically, in the example shown in FIG. 1, a brake control unit 15 for controlling the brake device 34 and a steering control unit 16 for controlling the steering device 35 are provided under the motion domain control unit 11. Further, under the energy domain control unit 21, an engine control unit 24 for controlling the engine 31, a transmission (TM) control unit 25 for controlling the transmission 32, and an MG control unit 26 for controlling the motor generator 33 are provided. .

  The motor generator 33 generates regenerative energy at the time of deceleration of the vehicle or the like. A motor generator coordinator (MGC) 23, which is a high-order logic block of the MG control unit 26, also manages generation of its regenerative energy. This energy is DC converted by an inverter and stored in a high voltage battery (not shown).

  Here, various functions possessed by the vehicle control system 1 illustrated as the logic blocks 12 to 16 and 22 to 26 in FIG. 1 will be described in detail.

  Various types of information necessary for performing the functions given to the respective logic blocks 12 to 16 and 22 to 26 are input to the vehicle control system 1. For example, various sensors (not shown) detect the operation of various operation parts (accelerator pedal, brake pedal, shift lever, steering wheel, etc.) operated by the driver for driving the hybrid vehicle, and the operation detection signal thereof Is input to the vehicle control system 1. In addition, the running state of the vehicle (for example, speed, acceleration, yaw rate, etc.) and the operating state of various on-vehicle devices 31 to 35 (for example, engine temperature, engine speed, transmission gear ratio, inverter temperature, motor speed, brake An operation detection signal from a sensor that detects oil pressure, steering angle, etc.) is also input to the vehicle control system 1.

  The various signals described above are given to the domain control units 11 and 21 and the in-vehicle device control units 15, 16 and 24 to 26 of the vehicle control system 1.

  For example, the motion domain control unit 11 receives an operation detection signal indicating the operation of the various operation units by the driver and an operation detection signal from a sensor that detects the traveling state of the vehicle. Then, in principle, the motion domain control unit 11 calculates control target values of the brake device 34 and the steering device 35 so that the vehicle behaves according to the operation of the operation unit by the driver. Specifically, in order to control the behavior of the vehicle so as to respond to the driver's operation while the vehicle behavior control unit 12 stabilizes the behavior of the vehicle, the target acceleration in the front-rear direction with respect to the longitudinal behavior control unit 13 While giving (the target deceleration), the target acceleration in the lateral direction is given to the lateral behavior control unit 14. The longitudinal behavior control unit 13 applies a target drive torque (acceleration torque or braking torque) to the power train coordinator (PTC) 22 of the energy domain control unit 21 to achieve the given target acceleration (target deceleration) in the front-rear direction. While outputting a target braking torque which is a control target value of the brake device 34 to the brake control unit 15. Further, the left-right behavior control unit 14 outputs a target assist torque, which is a control target value of the steering device 35, to the steering control unit 16 in order to realize the given target acceleration in the left-right direction.

  Note that, for example, the motion domain control unit 11 may be provided with information on the external environment of the vehicle, such as recognition information of a white line dividing the traveling lane of the vehicle, information on a preceding vehicle and an obstacle. Thereby, in the motion domain control unit 11, for example, the control target value can be calculated so as to adjust the assist force of the steering device 35 (lane keeping assist) so as not to deviate from the traveling lane divided by the white line. It becomes. Further, in the motion domain control unit 11, for example, it is possible to calculate control target values of the brake device 34 and the steering device 35 so as to avoid a collision with a preceding vehicle or an obstacle.

  Further, the energy domain control unit 21 receives, for example, a sensor signal for detecting the voltage or current of a high voltage battery (not shown), a sensor signal indicating the traveling state of the vehicle, or the like. The MGC 23 of the energy domain control unit 21 calculates the storage amount of the high voltage battery based on the sensor signals. Furthermore, the MGC 23 mainly calculates the maximum MG torque that can be generated by the motor generator 33 based on the storage amount of the high voltage battery, and gives it to the PTC 22. The PTC 22 takes into consideration the maximum MG torque that can be generated by the motor generator 33 and the traveling state of the vehicle based on the sensor signal in order to most efficiently realize the target driving torque (acceleration torque) given from the motion domain control unit 11. Then, the target engine torque to be generated by the engine 31, the target gear ratio to be realized by the transmission 32, and the target MG torque to be generated by the motor generator 33 are calculated. The calculated target engine torque, target gear ratio, and target MG torque are respectively given to the engine control unit 24, the TM control unit 25 and the MGC 23 as control target values. In addition, the TM control unit 25 may also be provided with a control target value related to the operation of the clutch (such as the clutch connection start timing, the time until completion of the clutch connection, etc.).

  Furthermore, the MGC 23 of the energy domain control unit 21 calculates the amount of regenerated power that can be generated by the motor generator 33 mainly based on the storage amount of the high voltage battery at the time of deceleration of the vehicle or the like. The information on the regenerative braking torque corresponding to the regenerative electric energy is given from the MGC 23 to the front-rear behavior control unit 13 of the motion domain control unit 11 via the PTC 22.

  When the target deceleration is given from the vehicle behavior control unit 12, the front-rear behavior control unit 13 calculates a target braking torque for achieving the target deceleration. When the motor generator 33 can generate regenerative braking torque, a target braking torque by the brake device 34 and a target regenerative braking torque by the regenerative brake are determined so as to utilize the regenerative braking torque as much as possible. The target regenerative braking torque is given to the MGC 23 of the energy domain control unit 21 via the PTC 22 as a control target value.

  The brake control unit 15 controls the brake device 34 in accordance with a target braking torque which is a control target value of the brake device 34 given from the front and rear behavior control unit 13. More specifically, the brake control unit 15 outputs a control signal for controlling the brake fluid pressure so that the brake device 34 generates the target braking torque. The steering control unit 16 also controls the assist torque in the steering device 35 by outputting a control signal so that the steering device 35 generates the target assist torque provided from the left and right behavior control unit 14.

  The engine control unit 24 outputs a control signal for realizing the target engine torque given from the PTC 22 to the engine 31. More specifically, the engine control unit 24 receives sensor signals from various sensors (rotation speed, temperature, air flow rate, and the like) that detect the operating state of the engine 31. Then, the current generated torque is calculated from the operating state of the engine which is grasped from the sensor signal. The engine control unit 24 calculates an engine operating state for bringing the current generated torque close to the target engine torque, and obtains a fuel injection amount, a fuel injection timing, and an ignition timing for achieving the calculated engine operating state. An injection control signal and an ignition control signal corresponding to these are output to the engine 31.

  The TM control unit 25 also receives the target gear ratio from the PTC 22 and outputs a control signal for realizing the given target gear ratio to the transmission 32. Further, when changing the transmission gear ratio in the transmission 32, the TM control unit 25 also outputs a control signal for controlling the operation of the clutch in accordance with the control target value regarding the operation of the clutch.

  When the target MG torque is given from the MGC 23, the MG control unit 26 outputs a control signal to the inverter of the motor generator 33 so as to generate the target MG torque. On the other hand, when a target regenerative braking torque is applied from MGC 23, MG control unit 26 causes motor generator 33 to apply a braking force corresponding to the target regenerative braking torque to the axle of motor generator 33. Output control signal to inverter.

  As described above, each of the logical blocks 12 to 16 and 22 to 26 constituting the vehicle control system 1 performs the control process in cooperation with the plurality of logical blocks 12 to 16 and 22 to 26 so that each in-vehicle device 31 Control ~ 35. For example, the PTC 22 executes inter-domain cooperation control in cooperation with the longitudinal behavior control unit 13 in the motion domain 10 and intra-domain cooperation control in cooperation with the MGC 23, the engine control unit 24 and the TM control unit 25.

  Here, in the above-described vehicle control system 1, signals and processing procedures etc. exchanged between the electronic control units in which the respective logic blocks 12 to 16 and 22 to 26 are mounted are strictly determined, and for cooperation processing corresponding thereto It is also possible to create an application program. However, in this case, the vehicle control system 1 becomes a so-called exclusive item, and for example, corresponds to a variation from low function to high function according to the grade of the vehicle or the type of vehicle, or hardware configuring the electronic control device It becomes difficult to respond to changes in

  Therefore, when performing processing in which a plurality of electronic control devices in which the respective logic blocks 12 to 16 and 22 to 26 are implemented cooperate, in addition to the cooperation processing application, the cooperation processing application program is cooperatively executed. It is conceivable to provide an OS program serving as basic software for each electronic control unit.

  For example, the OS program supports verification of communication data between each electronic control device, conversion of data, synchronization mechanism, allocation of resources, etc., so that the application program for cooperation processing in each electronic control device has its own control function. Can be created in a specialized manner, and can easily cope with addition or change of control functions. Further, since each OS program can abstract the hardware of each electronic control device, also in this respect, it is possible to enhance the versatility of the cooperative processing application.

  However, when each electronic control device is provided with an OS program that supports cooperative processing by each electronic control device, the OS programs need to operate cooperatively under a defined role assignment. However, assuming that the division of roles is always constant, for example, due to the difference in the capabilities of the electronic control device used, the role does not necessarily match the capabilities of the respective electronic control devices, and support for cooperative processing There is a risk that can not be done efficiently.

  Therefore, in the vehicle control system 1 according to the present embodiment, the role of the OS program supporting the cooperation processing by each electronic control device is configured to be changeable. Specifically, when one of the at least two electronic control units performing linked processing is a master ECU and the other is a slave ECU, first, the first OS program held by the master ECU is held by the slave ECU 2 Acquire information on the roles assigned to the OS program. Then, based on the information indicating the role of the second OS program, the first OS program determines the role of the first OS program to be able to operate in cooperation with the second OS program. Therefore, for example, even if the role assignment of the second OS program changes due to the ability of the slave ECU, the first OS program can operate in cooperation with the second OS program according to the change of the role assignment As such, it is possible to automatically change the role of sharing. As a result, each OS program provided in the master ECU and the slave ECU can efficiently support cooperative processing between the master ECU and the slave ECU.

  First, referring to FIG. 2, an example of a configuration in the case of providing an OS program in each electronic control device will be described, and a specific example of processing contents to be implemented by the OS program to support cooperative processing will be described.

  FIG. 2 shows a configuration in which the PTC 22 of the energy domain control unit 21 is mounted on the electronic control unit 40 as the PTC application 41 a and the electronic control unit 40 is provided with the OS program 41 b as one of the applications. In FIG. 2, applications 51a, 61a, 61a, and 61b functioning as logic blocks (front and rear behavior control unit 13, MGC 23, engine control unit 24, and TM control unit 25) that communicate directly with the PTC 22 and execute cooperation processing. The configuration of the electronic control units 50, 60, 70, 80 in which 71a, 81a are respectively mounted is also shown. Also in these electronic control units 50, 60, 70, 80, OS programs 51b, 61b, 71b, 81b are provided as one of the applications.

  The PTC application 41a, the longitudinal behavior control application 51a, the MGC application 61b, the TM control application 71a, and the EMS control application 81a respectively correspond to a cooperative processing application.

  Further, FIG. 2 shows that each of the electronic control devices 40, 50, 60, 70, 80 has one OS program 41b, 51b, 61b, 71b, 81b, respectively. 40, 50, 60, 70, 80 have different OS programs for each communication partner. This is because the service content to be provided in order to support cooperative processing is different because the communication counterpart is different. For example, the electronic control device 40 in which the PTC application 41a is implemented is an OS program for supporting cooperative processing with the electronic control device 50 as the longitudinal behavior control unit 13 which is the upper domain control unit, the same energy domain control unit OS program for supporting cooperative processing with the electronic control device 60 as the MGC 23 belonging to 21. OS program for supporting cooperative processing with the electronic control device 70 as the TM control unit 25 which is a lower device control unit. And an OS program for supporting processing in cooperation with the electronic control unit 80 as the engine control unit 24.

  However, the electronic control unit 40 as the PTC 22 supports the cooperation processing with the TM control unit 25 classified into the device control unit and the electronic control unit 70 and the electronic control unit 80 in which the engine control unit 24 is mounted respectively. The OS program may be made common. In this case, the OS program of the electronic control device 40 is set so as to provide data and services that include the differences between the roles and operating conditions of the OS programs of the electronic control device 70 and the electronic control device 80. By doing this, the OS program can be made common.

  In principle, the upper electronic control unit is the master ECU, and the lower electronic control unit is the slave ECU. In the case of the electronic control unit of the same class, one of them is a master ECU and the other is a slave ECU.

  Each of the electronic control units 40 to 80 has a memory, and software of the structure shown in FIG. 2 is stored in each memory. Each of the electronic control units 40 to 80 has a software structure conforming to so-called AUTOSAR (AUtomotive Open System ARchitecture), as shown in FIG. Therefore, the software structure of each of the electronic control devices 40 to 80 will be described by taking the electronic control device 40 mounted with the PTC application 41a as a representative example.

  In the electronic control unit 40, as shown in FIG. 2, software is installed to the microcontroller 47 which is hardware, and the software is largely composed of basic software 43 to 46, runtime environment (RTE) 42 and application software included in the application layer. Among them, the PTC application 41 a is mounted in the application layer, and the electronic control device 40 exhibits the function as the PTC 22 by executing the PTC application 41 a. The PTC application 41 a is actually divided into a plurality of sub applications for each of various functions as the PTC 22. The OS program 41 b is also implemented in the application layer as one piece of application software.

  The basic software 43 to 46 are hierarchized into the microcontroller abstraction layer 43, the ECU abstraction layer 44, and the service layer 45, and the higher the hierarchy, the stronger the degree of abstraction and the independence from various hardware. It has become. The basic software 43 to 46 also includes a composite driver 46.

  The microcontroller abstraction layer 43 is located at the lowest layer of the basic software 43 to 46, and includes a microcontroller driver, a memory driver, a communication driver, an I / O driver, and the like. The microcontroller abstraction layer 43 is a portion depending on the hardware configuration of the microcontroller 47. However, since the microcontroller abstraction layer 43 abstracts the microcontroller 47 and its peripheral devices, layers higher than this are independent of the microcontroller 47 and the peripheral devices. The microcontroller abstraction layer 43 has a plurality of communication drivers (for example, CAN (registered trademark) driver, LIN driver, FlexRay (registered trademark) driver, and the like) as communication drivers. Then, the electronic control unit 40 communicates using different communication drivers, that is, different communication networks, depending on, for example, whether the electronic control unit at the other end of the communication is within the domain or outside the domain.

  The ECU abstraction layer 44 is located above the microcontroller abstraction layer 43. The ECU abstraction layer 44 makes the upper software layer independent of the hardware of the electronic control device 40 by abstracting the basic components of the electronic control device 40. The ECU abstraction layer 44 includes on-board device abstraction, memory hardware abstraction, communication hardware abstraction, I / O hardware abstraction and the like.

  The service layer 45 is partially located above the ECU abstraction layer 44 to provide basic services for the application. Specifically, the service layer 45 provides services such as an OS, communication and management of a vehicle network, a memory service, a diagnostic service, and ECU state management. This service layer 45 is largely independent of hardware.

  The composite driver 46 is used when a complex function which is not available in other layers is needed to meet special functions and timing requirements for operating complex sensors and actuators. The composite driver 47 is used, for example, in the case of driving and controlling an injector that injects a fuel.

  The RTE 42 is located above the basic software 43 to 46 including the above-described layers, and is for making the various applications 41 a and 41 b included in the application layer not depend on the electronic control device 40. . Therefore, the RTE 42 provides communication between the applications 41a and 41b and communication between the applications 41a and 41b and the basic software 43 to 46.

  As described above, by adopting the software structure compliant with AUTOSAR, the applications 41a and 41b do not depend on the hardware of the microcontroller 47 and the electronic control device 40, so that the reusability of the applications 41a and 41b is achieved. Can be enhanced.

  Next, the OS program 41b will be described in detail. As shown in FIG. 2, the OS program 41b is embodied as one of application software. The OS program 41b provides various services for supporting the cooperation processing when each sub application of the PTC application 41b performs processing in cooperation with the other electronic control devices 50-80. In the example shown in FIG. 2, on the premise of basic software conforming to the current AUTOSAR, an OS program for realizing cooperation between ECUs is combined with the basic software via the RTE as application software. However, the OS program can be incorporated into the basic software as well as embodied as application software.

  FIG. 3 shows an example of a list of services provided by the OS program 41b. In FIG. 3, various services provided by the OS program 41b are divided into three layers of a domain virtual function bus (DVB), a domain system OS (domain system OS), and a domain system abstraction. It is classified and shown. The OS program 41b may provide a part of the service shown in FIG. 3, and conversely, the service shown in FIG. 3 is an example, and includes a service other than the service shown in FIG. It may be

  In the domain external-internal abstraction service classified as DVFB, for example, data (control target data, sensor detection data, etc.) for performing linkage processing is transmitted from the master ECU to the slave ECU In this case, the processing order of each service of the OS program executed in the master ECU and the domain ECU is set, or matching regarding the time when the service is executed is achieved. In addition, Semantic Gateway Service classified as DVFB translates data into corresponding data when data is different outside the domain.

  A resource arbitration service classified as a domain system OS is, for example, a master ECU and a slave ECU installed in the same electronic control unit, and when resources such as a memory and a core are shared, resource allocation and the like Make adjustments. The system mode (System Mode) service performs mode management so that the control mode in the master ECU and the control mode in the slave ECU match. The event management (Event Manager) service is, for example, for generating and distributing an event serving as a trigger for performing processing synchronized by the master ECU and the slave ECU. The scheduler (Scheduler) service defines a schedule of linkage processing in the slave ECU based on a schedule of linkage processing in the master ECU. The Synchronized Mechanism service is to synchronize control with events or time. The clock (Clock) service generates time common to the master ECU and the slave ECU, and performs time stamp on data as needed. The security (Security) service is for, for example, authenticating a legitimate communication partner based on ID data, or confirming the normality of communication data by parity check or the like. The diagnostic service performs, for example, abnormality diagnosis of the master ECU and the slave ECU, and executes fail-safe processing as needed. The safety function mechanism service is to stop the coordination function between the master ECU and the slave ECU when the abnormality is serious.

  The Function Distribution Abstraction service classified as a domain system abstraction is a division of roles between the first OS program on the master side and the second OS program on the slave side in realizing the various services described above. It manages. That is, in the present embodiment, the various services described above are realized by operating the first OS program on the master side and the second OS program on the slave side in cooperation. At this time, in the present embodiment, the roles of the first OS program on the master side and the second OS program on the slave side are configured to be changeable. Therefore, it is necessary to manage what role the first OS program on the master side and the second OS program on the slave side play. The Ownership Abstraction service manages the sharing of control responsibility for a control target device, a sensor device, and the like by the first OS program on the master side and the second OS program on the slave side. Control responsibility includes outputting a control signal to the control target device, performing reception processing of a detection signal from the sensor device, and monitoring whether the control target device and the sensor device are operating normally. We say that we play a role.

  Next, a setting method for enabling the first OS program on the master side and the second OS program on the slave side to operate in cooperation with each other will be described with reference to the flowcharts of FIGS. 4 and 5. The setting of the first OS program and the second OS program is performed at a stage where the vehicle control system is built in the vehicle manufacturing line. Moreover, it is implemented also when application software of a master ECU or a slave ECU is updated for functional improvement.

  The flowchart of FIG. 4 shows the process executed by the first OS program on the master side, and the flowchart of FIG. 5 shows the process executed by the second OS program on the slave side.

  First, in step S100 of the flowchart of FIG. 4, role information shared by the second OS program held by the slave ECU is acquired from the slave ECU. As this role information, the master ECU may acquire information indicating the role played by the second OS program of the slave ECU with respect to the various services described above, or the second OS program may include, in advance, a second OS program related to various services. Role pattern information that uniquely indicates a combination of roles may be held, and the role pattern information may be acquired.

  As described above, the second OS program held by the slave ECU is selected from a plurality of patterns having different roles to be shared by the second OS program with respect to the various services described above. Therefore, it is possible to appropriately set the role of the second OS program according to the configuration of the vehicle control system, the capability of the slave ECU, and the like.

  In the following step S110, it is determined whether the roles of the acquired second OS program regarding various services are consistent with the current roles of the first OS program in the master ECU. That is, the first OS program of the master ECU is preset to correspond to the role of the average second OS program. In step S110, it is determined by such basic setting of the first OS program whether the role of the second OS program is already matched. In this way, it is possible to suppress the amount of change of the first OS program in the subsequent step S120. However, without setting the first OS program in advance, all the service items may be set to correspond to the acquired second OS program. In that case, the process of step S110 can be omitted.

  In step S120, the role of the first OS program is changed so as to be consistent with the role of the second OS program related to various services. At this time, since the role of the first OS program may be changed only for the service item which is not consistent with the role of the second OS program, the change process of the first OS program can be performed easily.

  Here, two typical examples will be shown as to how the roles of the first OS program and the second OS program change with respect to each service item.

  FIG. 6 shows an example in which the role of the first OS program of the master ECU is reduced and the role of the second OS program in the slave ECU is increased.

  In this case, regarding the out-of-domain abstraction service, the first OS program of the master ECU is not involved in the setting of the processing order processing time of each service by the second OS program of the slave ECU, and the second OS program of the slave ECU Set the service processing order and processing time by the second OS program. In addition, with regard to the semantic interpretation gateway service, semantic translation of data transmitted from the master ECU is executed in the second OS program.

  With regard to the resource arbitration service, in order to give priority to cooperative processing in the master ECU, the first OS program performs processing to secure the resources for the cooperative processing, but the second OS program adjusts the use of the remaining resources. Do at As for the system mode service, the first OS program generates a mode of cooperative processing, and the second OS program receives the cooperative processing mode, performs conversion to the corresponding local mode, and converts the control mode of the slave ECU. Set to local mode.

  With regard to the event management service, the first OS program generates a linkage event used for linkage processing and distributes it to the slave ECU. Then, the second OS program converts the distributed linkage event into a local event that can be handled by the slave ECU. Regarding the scheduler service, the first OS program generates a schedule of cooperation processing, and the second OS program converts the cooperation processing schedule into a local schedule in the slave ECU. Regarding the synchronization mechanism service, when the first OS program selects the synchronization instruction by the predetermined event as the synchronization means, the second OS program selects the implementation function for realizing the synchronization by the predetermined event. For example, when the event management service generates a local event, the second OS program selects the local event as the synchronization means.

  Regarding the clock service, the first OS program generates a linkage time, and the second OS program converts the linkage time into a local time in the slave ECU. Regarding security services, the first OS program authenticates the communication partner of the master ECU and confirms the normality of received data, and the second OS program authenticates the communication partner of the slave ECU and confirms the normality of received data. I do. With regard to the diagnostic service, the first OS program performs abnormality detection of cooperation processing in the master ECU and failsafe processing at the time of abnormality, and the second OS program performs abnormality detection of cooperation processing in the slave ECU and failsafe processing at the time of abnormality I do. Regarding the safety function mechanism service, the first OS program is responsible for stopping the coordination function in the master ECU, and the second OS program is responsible for stopping the local function in the slave ECU.

  Regarding the function distributed abstraction service, the first OS program of the master ECU does not participate in the management of the function sharing between the master and the slave, and the second OS program of the slave ECU manages the function sharing. Similarly, with regard to the control abstraction service, the first OS program of the master ECU does not participate in the responsibility sharing management, and the second OS program of the slave ECU manages the responsibility sharing.

  On the other hand, FIG. 7 shows an example in which the role of the first OS program of the master ECU is increased and the role of the second OS program in the slave ECU is reduced.

  In this case, for the in-domain abstraction service, the first OS program of the master ECU sets the processing order and processing time of each service by the second OS program of the slave ECU, and transmits data indicating the contents of the setting. The second OS program of the slave ECU receives data indicating the setting content, and executes various services in accordance with the received data. Further, with regard to the semantic interpretation gateway service, the first OS program of the master ECU performs semantic translation of data and transmits the translated data to the slave ECU. The second OS program of the slave ECU receives the translated data and uses it for processing.

  With regard to the resource arbitration service, the first OS program performs processing for securing resources for cooperation processing by the master ECU, and further processing for allocating remaining resources. The second OS program performs resource management so as to use the allocated resources. Regarding the system mode service, the first OS program generates a mode of cooperative processing, further converts the cooperative event into a corresponding local mode, and transmits it to the slave ECU. The second OS program receives the converted local mode, and sets the control mode of the slave ECU to the received local mode.

  Regarding the event management service, the first OS program generates a linkage event used for linkage processing, and converts the linkage event into a local event that can be handled by the slave ECU. The second OS program receives the local event and causes processing based on the local event to be performed. With regard to the scheduler service, the first OS program generates a schedule of linkage processing, and further converts the linkage processing schedule into a local schedule in the slave ECU and transmits it. The second OS program receives the local schedule and performs schedule management based on the local schedule. With regard to the synchronization mechanism service, the first OS program selects and transmits a local synchronization means corresponding to the synchronization means in the cooperation process. The second OS program receives the received local synchronization means and uses it for the subsequent processing.

  Regarding the clock service, the first OS program generates a linkage time, and further converts the linkage time into a local time in the slave ECU and transmits it. The second OS program receives the local time and uses it for processing. Regarding the security service, the first OS program collectively manages the master ECU and the slave ECUs. For example, the first OS program authenticates the communication partner of the master ECU and the slave ECU, and confirms the normality of data transmitted and received between the master and the slave. In this case, the second OS program does not handle security services. Regarding the diagnostic service, the first OS program performs abnormality detection of cooperation processing in the master ECU and failsafe processing at the time of abnormality, and notifies the slave ECU of the abnormality detection result. The second OS program receives the abnormality detection notification. With regard to the safety function mechanism service, the first OS program is responsible for stopping the linkage function in the master ECU and instructs the stop of the local function when necessary. The second OS program stops the local function in the slave ECU according to the stop instruction of the local function from the first OS program.

  With respect to the function distributed abstraction service, the first OS program of the master ECU manages the function sharing between the master and the slave, and the second OS program of the slave ECU does not participate in the management of the function sharing. Similarly, with regard to the control abstraction service, the first OS program of the master ECU performs the responsibility sharing management, and the second OS program of the slave ECU does not participate in the management of the responsibility sharing.

  In the above, an example of role assignment between the first OS program and the second OS program has been described, but in this role assignment, in addition to the two examples described above, the processing response of cooperation processing in the master ECU and local processing in the slave ECU Different from the processing response, the role assignment may change for each service depending on various factors such as the ability of the master ECU and the slave ECU, so various variations can be considered.

  Returning to the flowchart of FIG. 4 again, the description will be continued. By the processing up to step S120, the first OS program is set such that the first OS program and the second OS program can cooperate to support the cooperation processing. However, in some cases, the first OS program and the second OS program cooperate by performing fine adjustment such as changing the type of information transmitted from the master side to the slave side or correcting the operating conditions on the master side. In some cases, it may be possible to carry out the process more smoothly.

  Therefore, in step S130 of the flowchart of FIG. 4, it is determined whether it is necessary to change the transfer information to the second OS program. Then, when it is determined that the change of the transfer information is necessary, the change content of the transfer information to the second OS program is notified in step S140. Further, in step S150, the change of the transfer information according to the notification content in step S140 is reflected in the first OS program.

  Some examples in which it is determined that the first OS program of the master ECU needs the change of the transfer information to the second OS program will be described with reference to FIG.

  As shown in FIG. 8, there are several possible target services that may need to change transmission information, such as a system mode service, an event management service, a scheduler service, and a safety function mechanism service.

  For example, in the case of the system mode service, when the slave ECU is changed due to the version upgrade of application software in the slave ECU, it is predicted that the local mode linked to the cooperation processing mode of the master ECU changes. In this case, instead of the transmission of the local mode itself from the first OS program of the master ECU, the purpose (start, normal control, stop, etc.) of the corresponding mode is changed to be transmitted. As a result, the second OS program of the slave ECU can select an appropriate mode corresponding to the cooperation control mode.

  Also in the event management service, as in the case of the system mode service, when the slave ECU is changed, it is predicted that the local event corresponding to the linkage event of the master ECU will change. Therefore, in this case as well, instead of the transmission of the local event itself from the first OS program of the master ECU, the purpose (interrupt, periodic, abnormality detection, etc.) of the corresponding event is changed to be transmitted. As a result, the second OS program of the slave ECU can generate an appropriate local event corresponding to the cooperation event.

  Furthermore, also in the case of the scheduler service, as in the case of the system mode service, when the slave ECU is changed, it is predicted that the local schedule corresponding to the coordination schedule of the master ECU will change. Therefore, in this case as well, instead of the transmission of the local schedule itself from the first OS program of the master ECU, the purpose of the corresponding schedule (such as post-processing of XX) is changed to be transmitted. This enables the second OS program of the slave ECU to generate an appropriate local schedule corresponding to the cooperation schedule.

  In the case of the safety function mechanism service, when the master side instructs the slave side to stop and the slave side also has a function independent of the master side, the master side gives the stop instruction. And the situation on the slave side may be ignored. Therefore, the first OS program of the master ECU transmits the slave stop instruction for the purpose (control end, abnormal time stop, etc.). As a result, the second OS program of the slave ECU can take measures in accordance with the purpose of stopping based on its own processing status.

  In step S160 of the flowchart of FIG. 4, it is determined whether a change request from the second OS program of the slave ECU has been received. If it is determined that the change request has been received, the process proceeds to step S170, and the operating condition of the first OS program is corrected according to the change request from the second OS program of the slave ECU.

  Some examples in which the first OS program of the master ECU receives a change request of the operating condition from the second OS program of the slave ECU will be described with reference to FIG.

  As shown in FIG. 9, target services that may need to change operating conditions are out-of-domain abstraction services, resource arbitration services, synchronization mechanism services, function-distributed abstraction services, dominant abstraction services, security There are several possibilities, such as functional mechanism services.

  For example, there are a plurality of slave ECUs with respect to the master ECU, there is a difference in response time of control by the plurality of slave ECUs, and individual adjustment on the slave side corresponds to a difference in response time of control by a plurality of slave ECUs If it can not be done, it may be difficult to adjust the processing time on the slave side. In such a case, the slave side requests the master side to change the data notification timing with respect to the abstraction service inside and outside the domain. For example, it is assumed that the master ECU is the electronic control unit 40 in which the PTC 22 is mounted and the slave ECU is the electronic control unit 80 in which the electronic control unit 60 in which the MGC 23 is mounted and the engine control unit 24 . In this case, the PTC program is implemented in the OS program 61b (second OS program) of the electronic control unit 60 in which the MGC 23 is implemented, or the OS program 81b (second OS program) of the electronic control unit 80 in which the engine control unit 24 is implemented. With respect to the OS program 41b (first OS program) of the electronic control device 40, the control target value (the electronic control device 60 on which the MGC 23 is mounted is sufficiently slower than the electronic control device 80 on which the engine control unit 24 is mounted). Request to notify the target motor torque). Thereby, the difference in response time between the engine 31 and the motor generator 33 can be absorbed, and the engine 31 and the motor generator 33 can generate the target driving torque.

  Also, if there is a control target device or sensor device for which the slave ECU is responsible for control, among the data handled by the slave ECU, data for monitoring the abnormal state of the control target device or sensor device, and other data There may be different safety requirements. In such a case, regarding the resource arbitration service, the slave side requests the master side, for example, in the shared memory, to secure a memory area according to the safety of data used by the slave ECU. This makes it easy to handle data that meets safety requirements.

  Further, with regard to the synchronization mechanism service, when the slave can not select an implementation function for realizing synchronization, the slave may specify a condition for issuing a synchronization instruction.

  Furthermore, in the case where there are multiple slaves, it is the master side that is convenient to perform function sharing management and responsibility sharing management between master and slave, so in such a situation, function distributed abstraction service and control Regarding the abstraction service, the slave side may request the master side to perform function sharing management and responsibility sharing management.

  Also, when there are multiple slaves, it is unclear in what procedure it is appropriate to perform stop processing in each slave. With respect to the safety function service, the slave side to the master side and the local in each slave You may request to be notified of the procedure of the function stop processing of and its condition.

  As described above, the flowchart in FIG. 5 shows the process executed by the second OS program on the slave side, and in step S200, role information shared by the second OS program held by the slave ECU with respect to the master ECU. I will provide a.

  In the following step S210, it is determined whether or not there is a change request of the transmission information from the master ECU. If it is determined that there is a change request, the process proceeds to step S220, and the information acquired by the second OS program is changed according to the change request from the master ECU. Furthermore, the processing procedure of the information after change is defined as necessary.

  Then, in step S230, it is determined whether it is necessary to change the operating condition of the first OS program of the master ECU. If it is determined that the change of the operating condition is necessary, the change request of the operating condition of the first OS program is issued to the master ECU in step S240. Then, in step S250, the second program is corrected so that the change content of the requested operating condition of the first OS program is reflected in the second OS program.

  Although the preferred embodiments of the present invention have been described above, the present invention can be variously modified and practiced without departing from the spirit of the present invention without being limited to the above-described embodiments. .

  For example, in the embodiment described above, when there are a plurality of slave ECUs with respect to the master ECU, and in the individual adjustment on the slave side, matching of the processing time on the slave side is difficult, from the slave side I requested the master side to change the data notification timing. However, when the slave ECUs are configured to be able to communicate with each other, the processing time on the slave side may be matched by communication between the second OS programs of the slave ECUs. For example, based on information on the processing procedure and processing time by the second OS program of one slave ECU, the processing procedure and processing time in the second OS program of the other slave ECU are adjusted to be mutually consistent. As described above, when the slave ECUs cooperate with each other, time alignment of processing of each other can be easily achieved.

Reference Signs List 1 control system, 11 motion domain control unit, 12 vehicle behavior control unit, 13 longitudinal behavior control unit, 14 left and right behavior control unit, 15 brake control unit, 16 steering control unit, 21 energy domain control unit, 22 power train coordinator, 23 Motor generator coordinator, 24 engine control unit, 25 TM control unit, 26 MG control unit, 31 engine, 32 transmission, 33 motor generator, 34 brake device, 35 steering device, 40 electronic control unit, 41a PTC application, 41b OS program, 42 RTE, 43 microcontroller abstraction layers, 44 ECU abstraction layers, 45 service layers, 46 composite drivers, 47 microcontrollers

Claims (6)

For a vehicle that performs a process in which a first electronic control unit (40) and a second electronic control unit (60, 70, 80) cooperate to control on-vehicle devices (31 to 33) mounted on the vehicle A control system,
The first electronic control unit and the second electronic control unit respectively have cooperation processing application programs (41a, 61a, 71a, 81a) for performing cooperation processing, and the cooperation processing application program Have a first OS program (41b) and a second OS program (61b, 71b, 81b) operating cooperatively under a predetermined role allotment, which functions as basic software for cooperatively executing Yes,
The second OS program held by the second electronic control unit is selected from among a plurality of roles having different roles,
The first OS program held by the first electronic control device is configured to be able to change the role to be shared, thereby performing an operation in cooperation with any second OS program among a plurality of different roles to be shared. Possible,
The first electronic control unit is
An acquisition unit (S100) for acquiring information on a role shared by the second OS program from the second electronic control device;
A determination unit that determines a role to be shared by the first OS program so that it can operate in cooperation with the second OS program based on the information indicating the role to be shared by the second OS program acquired by the acquisition unit The control system for vehicles provided with S120). There are a plurality of items as the role of the operating system, and the first OS program and the second OS program have their roles assigned to the plurality of items, respectively.
The first electronic control unit is
A change notification unit (S140) for notifying the second electronic control unit of a change in information to be transmitted regarding a specific item;
The vehicle control system according to claim 1, further comprising: a change unit (S150) configured to change information transmitted by the first OS program regarding the specific item so as to correspond to a change instruction of the change notification unit. There are a plurality of items as the role of the operating system, and the first OS program and the second OS program have their roles assigned to the plurality of items, respectively.
The second electronic control unit is
The first electronic control unit has a change instructing unit (S240) for requesting a change of the operating condition of a specific item,
The first electronic control device according to claim 1, further comprising: an operating condition changing unit (S170) configured to change an operating condition of the first OS program of the specific item according to a change instruction from the change instruction unit. Vehicle control system. The vehicle control system is hierarchically composed of a plurality of device control units (24 to 26) for controlling a plurality of in-vehicle devices and a domain control unit (21 to 23) which controls the plurality of device control units. Are
The first electronic control unit is implemented by the domain control unit.
The vehicle control system according to any one of claims 1 to 3, wherein the second electronic control unit is mounted with the device control unit. The vehicle control system is hierarchically composed of a plurality of device control units (24 to 26) for controlling a plurality of in-vehicle devices and a domain control unit (21 to 23) which controls the plurality of device control units. Are
The domain control unit is configured by at least two electronic control devices.
The vehicle control system according to any one of claims 1 to 3, wherein the first electronic control unit and the second electronic control unit are at least two electronic control units constituting the domain control unit. The vehicle control system is hierarchically composed of a plurality of device control units (24 to 26) for controlling a plurality of in-vehicle devices and a domain control unit (21 to 23) which controls the plurality of device control units. Are
The host computer further comprises an upper control unit (13) positioned above the domain control unit and performing control instructions to the domain control unit.
The first electronic control unit is implemented by the upper control unit.
The vehicle control system according to any one of claims 1 to 3, wherein the second electronic control unit is implemented with the domain control unit.

Images