JP6138666B2 - In-vehicle control system logging system - Google Patents

Description

  The present invention relates to a logging system that collects operation logs of in-vehicle software.

  In recent years, in-vehicle functional safety standard ISO 26262 has been established, and stricter requirements for safety / reliability for in-vehicle devices and obligation to comply with international standards have been developed. Especially for in-vehicle software, it bears the core characteristics of car behavior, and the new (exhaustive) behavior analysis difficulty is waiting for the appearance of a new verification method.

  In recent years, a plurality of in-vehicle electronic devices (referred to as electronic control units (ECUs)) are mounted on a single vehicle, and the entire operation is performed by affecting each other through the in-vehicle network. Therefore, verification of the in-vehicle software is much more difficult than when a single CPU is used. In this situation, an integrated ECU (multiple CPUs are mounted on the configuration base) that consolidates multiple ECUs for economic effect or a multi-core CPU is used to perform separate processing for each core to improve performance. The same applies to the improved ECU. The difficulty of verification is due to the difficulty of tracking the behavior of multiple CPUs (or cores) in parallel on the same time axis.

  In addition, the market release of a product is not necessarily set after that, based on the assurance that software verification has ended. Then, in the mass production stage, there is a possibility that defects are rarely included in the embedded software.

  However, how to protect occupants when such infrequent problems occur is within the category of functional safety described above, and this is recorded for the next product development (function and reliability improvement by differential development). ) Is related to activities in the functional safety life cycle. The key to this is a software behavior logging system.

  Logging external information and the corresponding software behavior is a technique known for spacecraft such as artificial satellites and exploration satellites, and is not common in automotive applications. However, it is expected to become widespread as the functional safety support method described above or as one of verification methods for multi-core / multi-CPU.

  At that time, the decisive factor in the realization will depend on the cost increase and the ease of attaching and detaching the device. In the case of the aforementioned spacecraft, the cost of adding a logging system will be negligible considering the lost profit when an accident occurs.

  However, for durable consumer goods such as automobiles, the cost is as low as possible, and the simplicity of the connection mechanism when it is additionally set as an option is required.

  Although the prior art is not necessarily applied to in-vehicle devices, for example, as shown in Patent Document 1, a single high-resolution clock (which can be extrapolated as high resolution) is installed for a plurality of CPUs. A technique for collecting logs in consideration of time series is known.

Japanese Patent No. 3391990

  However, in Patent Document 1, an area where a plurality of CPUs discharge their operation logs is set in the common RAM. What this means is that multiple CPUs can cause interference with each other via a common RAM. Further, there is a possibility that a different CPU rewrites an operation log not related to itself.

  The concept of software partitioning has been introduced for functional safety, and it is important that the mechanism and resources that cause a specific malfunction are isolated from each other, so that the effects of the malfunction do not spread to others. From this point of view, the known example of the logging system is unsatisfactory, and the addition of the logging system causes the partitioning function to deviate.

Therefore, an object of the present invention is to realize partitioning while being able to appropriately record a log when an assertion event occurs.
The present invention has been made to solve the above-mentioned problems related to functional safety partitioning or the problem of device connection that becomes a problem at the time of mounting.

The present invention is a logging system for an in-vehicle control device that uniformly logs messages from a plurality of CPU cores related to each other, and a message output from each CPU core is input to a shift register unique to each CPU core. In addition, an event output indicating that information is stored in the shift register is output from each CPU core to the outside, and the shift register includes a plurality of CPU registers connected in series, and a plurality of event outputs. A logging operation is excited by logical sum, information of the plurality of shift registers is collectively read by serial communication by clock synchronization, and the read log information is stored in a storage device.

  According to the logging system of the present invention, since a plurality of CPUs and logging devices are connected by a serial bus, a specific CPU has resources of another CPU (including resources of a separate logging device itself). Cannot access and will not interfere. Therefore, the partitioning can be realized while the log when the assertion event occurs can be appropriately recorded.

1 is a configuration diagram of a logging system according to Embodiment 1. FIG. 3 is a program list showing output contents of a log message according to the first embodiment. FIG. 3 is a block diagram illustrating an internal mechanism of a CPU according to the first embodiment. It is a block diagram which shows the internal mechanism of CPU which concerns on Embodiment 2. FIG. 3 is a connection diagram illustrating external wiring between a plurality of CPUs and wiring between logging devices according to the first and second embodiments. 3 is a block diagram illustrating an internal mechanism of a logging device according to Embodiments 1 and 2. FIG. It is a flowchart which shows the internal operation | movement procedure of a logging apparatus.

<Embodiment 1>
In the logging system according to the present embodiment, a register for storing a log message from a CPU is configured as a shift register, a plurality of shift registers are connected in cascade by a plurality of CPUs to configure a serial bus, and a batch dump of messages is performed. Is what you do. The batch dump timing is the logical sum of the event timings when at least one CPU wrote the log message to the shift register, and the time stamp pressed on the message is the only one installed on the logging system side. It is done by the clock. This will be specifically described below.

  FIG. 1 illustrates one embodiment of the present invention. Although two sets of CPUs 110 and 120 (or CPU cores 111 and 121) exist in FIG. 1, the number is not limited to two, and three or more sets may exist.

  The shift registers 112 and 122 used for sending messages of each CPU are connected in series in series and are configured to perform a shift operation with the same clock. Since a serial connection, that is, a serial bus is used, the main subject of operation is the logging device 140 (which supplies the clock source 142) as a bus master, and a specific CPU cannot interfere with the operation of other CPUs or logging devices. Therefore, software partitioning for functional safety is completely secured.

Also, even if the number of CPUs to be logged increases, the unified dump method can be used only by increasing the number of serially connected shift registers. (The number of pulses output from the transmitter 142, the number of stages of the serial / parallel converter 145, and the number of inputs of the event OR circuit 130 change, but the essence of the algorithm does not change.)
The CPU cores 111 and 121 generate event outputs 113 and 123 at the same timing as writing log information to the shift registers 112 and 122, respectively. This signal is an on-demand signal that prompts the logging device 140 to record because meaningful data is stored as a log in the shift register. These signals are ORed by the OR circuit 130 and transmitted to the logging device 140.

  That is, when at least one log information is prepared in the shift register, a batch serial dump is executed, and information from the shift register for which no log information is output includes invalid initial value data that can be discriminated later. Become.

  This initial value data is generated by the shift register initialization data unit 143 and stored in advance in all shift registers. This initial value storage mechanism is based on the fact that the initial value is stored from the opposite digit of the shift-out so as to fill the gaps in the bits vacated by the shift operation while the batch serial dump operation described above is executed sequentially. When the process is completed, all the digits of the shift register are automatically initialized.

  Accordingly, when the log data contains valid data in at least one CPU message digit (see 151) and the remaining CPU digits are invalid or the log timing overlaps at the same time, valid data in a plurality of CPU digits. Multiple variations of whether or not is included will occur. In any case, it is obvious from this mechanism that data is reliably collected in the time-series order in which log timings occur and no contradiction occurs in the context of time.

  As described above, the logging device 140 reads the messages stored in the plurality of shift registers via the serial bus, and converts them into character data by the serial / parallel converter 145. At that time, the time stamp when the on-demand signal (the output signal of the event logical sum 130) is generated by the timer 144 is stored together with the above-mentioned data. This makes it easy to track and interpret the log in chronological order using the time stamp as a landmark.

  FIG. 2 shows an example of the embedded software source code 200 executed by each CPU. If there is an abnormality in this, the condition for logging is embedded as an assertion instruction. For example, the assertion instruction 201 is an example of an assertion, and the conditional expression in parentheses of the assert function becomes false when the integer division divisor is 0 or the quotient is likely to overflow. At this time, the assert function writes a message to the shift register 112 or 122 and configures a function library so that the event output terminals 113 and 123 of the corresponding CPU request the logging device 140 to read out.

  The assertion log 210 is an example of information stored by the logging device 140, and a record when a log dump is generated by the assertion command 201 (collected for a plurality of CPUs and pressed with a time stamp) is set to 211. In addition, information resulting from only the assertion instruction 201 is shown at 212.

  In the assertion message 212, as an example, a conditional expression, a program file name, and a line number when it becomes false by an assertion instruction is output so that a software malfunction can be easily identified. In the figure, “(time_stamp)” is a time stamp value added by the logging device 140, and “CPU_A” and “CPU_B” are marks added by the logging device 140 to make it easy to understand which CPU has issued the log message.

  In FIG. 2, since an assertion has occurred for “CPU_A” and no log event has occurred for “CPU_B”, the message of “CPU_B” is “none”.

  In FIG. 3, the shift registers 112 and 122 are realized by a serial peripheral interface (SPI) which is one of peripheral devices of the CPU. The serial peripheral interface is a general-purpose device that can be used for clock-synchronized serial communication, and can shift in external data from the serial input 304 and shift out internal data from the serial output 305 in synchronization with the external clock source 306. it can. Therefore, it is suitable for cascade connection of shift registers. The serial peripheral interface shift register 112 itself can transfer data from the CPU core 111 through the internal bus, and this data may be used as the aforementioned assertion log.

The assertion instruction 201 shown in FIG. 2 is described in the program memory (ROM) 301 in FIG. 3 (the machine language corresponding to the instruction 201 is stored), and the message when an assertion condition occurs is displayed. Is written to the shift register 112 and a log dump request is externally output from the event output terminal 113 through the peripheral I / O device 303. Since the event output terminal 113 is also one of the digital signal input / output 307 terminal groups originally existing in the CPU, the present invention can be easily realized with the current CPU.
<Embodiment 2>
FIG. 4 shows another embodiment of the present invention, in which an option register 112 of JTAG (Joint Test Action Group) is used as a shift register.

  JTAG is the common name of the standard IEEE 1149.1 for boundary scan test and test access port that can be used for inspection and debugging of integrated circuits and substrates. With advances in semiconductor technology, the pin spacing of integrated circuit chips has become narrower, making it difficult to perform inspections with probes. A package such as a surface mount BGA (ball grid array) is physically impossible. For this reason, a mechanism has been devised for reading out the internal state in sequence by connecting the circuits inside the chip in a row. This is called a Boundary Scan Test, and JTAG standardizes it. It was standardized as IEEE 1149.1 in 1990.

  JTAG has a device-specific register called an option register, which can be used by a mounting manufacturer with freely expanded functions. If this is used for the shift register 112, the present invention can be realized in the form of the JTAG function.

  Normally, a JTAG device does not have an internal bus connection that can exchange information with the CPU core 111. This is because JTAG is used for the purpose of verifying the electrical connection between the IC chip and the printed circuit board.

  However, some CPU mounting manufacturers have expanded JTAG to on-chip ICE (In-Circuit Emulator). At that time, it is connected to the CPU internal bus to read / write register values, or control memory (RAM) 302 Some can read and write content.

  However, even at that time, the CPU core 111 and the JTAG device are essentially irrelevant, and the CPU core 111 must be modified so that the contents of the shift register (option register) 112 can be manipulated in order to expand for the present invention.

  Further, in the conventional JTAG / on-chip ICE, there is a type in which the CPU firmware writes variable data (registers and RAM values) around the CPU to the JTAG extension register at regular bus timing. In this case, since the CPU internal bus and the JTAG are already connected, it is only necessary to extend the instruction word so that the JTAG register is made visible (operable) from the programming model executed by the CPU. As a result, the result of the assertion instruction 201 stored in the program memory 301 can be output as an assertion message 212 via JTAG.

  The contents of the shift register (option register) 112 are serial dumped via the JTAG Test Data Out terminal 405 and a similar JTAG Test Data In terminal 404 connected to the next stage.・ Same as interface. The signal at the Test Clock terminal 406 of JTAG is used as the external clock at that time.

  The JTAG transition to this mode is performed using the function of the JTAG TAP controller 412. The state transition is performed by a combination of signals from the JTAG Test Clock terminal 406, the JTAG Test Mode Select terminal 407, and the JTAG Test Reset terminal 408.

  The JTAG function is an inspection hidden function for the CPU, and there is an advantage that the serial peripheral interface, which is a CPU peripheral device, is not explicitly consumed for the present invention as in the first embodiment of FIG.

This is a field test or the like in the market after the shift to mass production, which is suitable for the purpose of temporarily adding a logging system and accessing the JTAG port to collect operation logs. <Items common to the first and second embodiments>
Hereinafter, an example of cascade connection of shift registers and an example of a logging device common to the first and second embodiments will be described.

  FIG. 5 shows a method of connecting the aforementioned shift registers of the CPUs and the logging device 140.

  The shift registers are connected in series (cascade connection). The serial bus output terminal DO501 of the logging device 140 is connected to the shift register input terminal 502 of the CPU 110, the shift register output terminal 503 is connected to the shift register input terminal 504 of the CPU 120, and the shift register is output. Connection is made from the terminal 505 to the serial bus input terminal DI 506 of the logging device 140. This means that even if the number of CPU stages to be transferred increases, the number of cascades only changes and the method itself does not change.

  The clock source for the shift operation of the shift registers 112 and 122 is provided by the logging device 140 (that is, the bus master of the serial bus). The clock supplied from the clock output terminal 508 of the logging device is connected to the serial bus clock input 509 of the CPU 110. In parallel with the serial bus clock input 510 of the CPU 120. Parallel introduction is the same even if the number of shift registers increases.

  The event output for transmitting the log dump request is input to the event OR circuit 130 from the respective CPUs 110 and 120 via the event output terminals 113 and 123. Even if the number of shift registers increases, the number of inputs to the event OR circuit 130 may be increased. Therefore, a request representing the fastest event occurrence timing is transmitted to the event input terminal 507 of the logging device.

  FIG. 6 shows an internal block diagram of the logging device 140, and FIG. 7 shows an operation procedure of the sequencer 141 inside the logging device in the form of a flowchart. For convenience of explanation, explanation will be given according to the flowchart of FIG. 7, and correspondence of the internal block diagram of FIG. 6 will be explained each time.

  The algorithm shown in FIG. 7 is implemented in the sequencer 141 shown in FIG. 6, and each configuration, function, processing unit, etc. is realized as hardware by designing all or a part thereof using, for example, an integrated circuit. It can also be realized as software by a processor executing a program for realizing each function.

  In step S701 of FIG. 7, the process continues to wait for a log dump request to be sent to the event input 507 of the logging device of FIG. If there is no request, the process reenters S701 to continue checking the input. If there is, there is a transition to step S702.

  In S702, the time when the dump request is generated is collected from the time stamp generation clock 144 in the logging device, and preparations are made for adding to the log. In step S703, preparations are made for outputting a prescribed number of clock pulses for serial dumping. Specifically, the transmitter (clock supply source) 142 is activated, and the clock count variable is reset (initialized to 0).

  Here, the clock count variable is a variable that counts how many clocks the entire mechanism connected by the serial bus has been shifted so far.

  In the subsequent determination step S704, it is checked whether the serial dump has been performed for the specified number of clocks. If the serial dump is continuing, steps S705 and S706 are executed.

  In step S705, a signal corresponding to one clock (one bit) is supplied from the transmitter 142 to the shift registers 112 and 122 via the clock output 508 of the logging device. This same clock signal is also supplied internally to the serial / parallel converter 145. At this time, 1-bit data shifted out from the shift registers 112 and 122 enters the serial / parallel converter 145 via the serial bus input 506 of the logging device, and on the contrary, the shift register initialization data is transferred to the free bits of the shift register. A value of 143 (indicated as null data in FIG. 6 because it is initialization data) is shifted in.

  In the following step S706, the clock count variable is incremented and the process returns to the determination step S704.

  When the clock for the specified output is output, the process proceeds to step S707. At this time, what is the location of the log information is that all the data stored in the shift registers 112 and 122 before the start of logging is the serial / parallel converter 145. Instead, the shift register is filled with the value of the shift register initialization data 143.

  Therefore, in the subsequent step S707, the serial / parallel converter 145 converts the assertion log from the bit string to the character base (restores from serial to parallel) and prepares to output it to the internal parallel bus 601 of the logging device.

  In the subsequent step S708, the log character string data 151 is generated by combining the time stamp and the character-based assertion log, and the contents are written to the log recording flash memory 603 via the file driver 602.

  These transmitter (clock supply source) 142, shift register initialization data 143, time stamp generation clock 144, serial / parallel converter 145, file driver 602, and the like are also configured, functions, and processes in the same manner as the sequencer 141 described above. The part or the like can be realized as hardware by designing all or a part of them by, for example, an integrated circuit, or can be realized as software by the processor executing a program that realizes each function. it can.

  After the log character string data 151 for each event is written in the log recording flash memory 603, the process returns to step S701 and waits for the event input 507 again.

  As described above, according to the first and second embodiments of the present invention, it is possible to solve the problems related to conventional functional safety partitioning or the problem of device connection that becomes a problem at the time of mounting.

  In other words, in the past, since the logging area common RAM was mapped to a memory space that can be directly written from the CPU, the logging area had to be directly connected to the CPU bus, and the amount of wiring connection increased accordingly. Only the logging device could not be retrofitted or removed easily. On the other hand, according to the present embodiment, it is possible to easily configure a multi-core / multi-CPU logging apparatus in consideration of functional safety partitioning.

  Since the logical sum signal of the serial bus and (log request) event is used, the time series context of the event occurrence can be recorded strictly, and the number of connections between each CPU and the logging device is small and can be removed later. Can be an easy logging device.

  Since the time stamp clock is held on the logging device side, the global time can be managed regardless of the internal time of each CPU, and the cost increase when the logging function is added is consolidated on the logging device side. Therefore, it is possible to configure an apparatus with little cost increase.

  110, 120: CPU, 111, 121: CPU core, 112, 122: Shift register, 113, 123: Event output terminal, 130: Event OR circuit, 140: Logging device, 141: Sequencer, 142: Transmitter (clock) 143: shift register initialization data, 144: time stamp generation clock, 145: serial / parallel converter, 150: log data, 151: corresponding output data description, 200: embedded software source code, 201: assertion Command: 210: Assertion log 211, 212: Assertion message 301: Program memory (ROM) 302: Control memory (RAM) 303: Peripheral input / output device 304: Serial serial interface (SPI) Input terminal 305: SPI serial output terminal 306: SPI serial clock 307: CPU input / output terminal 404: JTAG Test Data In terminal 405: JTAG Test Data Out terminal 406: JTAG Test Clock Terminal: 407: JTAG Test Mode Select terminal, 408: JTAG Test Reset terminal, 410: JTAG instruction register, 411: JTAG bypass register, 412: JTAG TAP controller, 413: JTAG cell, 501: Logging device Serial bus output, 502, 503, 504, 505: Serial bus input / output and link wiring of each CPU, 506: Logging device serial bus input, 507: Logging device input Cement Input, 508: clock output logging apparatus, 509 & 510: the serial bus the clock input of each CPU, 601: internal parallel bus of the logging device, 602: file driver, 603: Logging flash memory.

Claims (7)

A vehicle-mounted control device logging system that uniformly logs messages from a plurality of CPU cores related to each other,
A message output from each CPU core is input to a shift register unique to each CPU core, and an event output indicating that information is stored in the shift register is output from each CPU core to the outside. Registers for CPUs are cascaded in series, and a logging operation is excited by a plurality of logical sums of the event outputs, and information of the plurality of shift registers is read and read collectively by serial communication by clock synchronization. A logging system for a vehicle-mounted control device, wherein log information is stored in a storage device.   The shift register unique to each CPU core is arranged only in the memory space of the CPU and cannot be accessed from another CPU core, and the storage device for storing the logging result is directly written by all the CPU cores. The logging system for a vehicle-mounted control device according to claim 1, which is impossible. A structure enclosing a clock for counting the event occurrence time to the Symbol 憶 the apparatus, during the logging operation is excited by a plurality of logical sum of the event output, adding a time stamp of said time meter in the log results The logging system for a vehicle-mounted control device according to claim 1.   2. The logging system for an in-vehicle control device according to claim 1, wherein the shift register unique to each CPU core uses a serial peripheral interface (SPI).   The in-vehicle controller logging system according to claim 1, wherein an optional register of JTAG (Joint Test Action Group) is used as the shift register unique to each CPU core. The Symbol 憶 device is configured as a rear attachment and removable separate relative configured ECU (Electronic Control Unit) system with multiple CPU,
At least the serial communications clock output憶 apparatus outputs, serial communication output of ECU system side multiple CPU is mounted is output, connected by event logic sum output, minimum 3 signal of the ECU system side the more CPU is mounted to the output The logging system for a vehicle-mounted control device according to claim 1.   The contents collected as log information via the shift registers unique to each CPU core are information contents that can be regarded as evidence of functional safety by a software assertion log and an abnormal warning on the control operation corresponding thereto. The logging system for an in-vehicle control device according to claim 1.