JP2013012092A - System and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a system which allows a user to correctly check actual user friendliness including operability, even in an early stage of use start in which information concerning driving of his/her vehicle recorded before an actual use start and during driving cannot be acquired sufficiently to reach a certain amount.SOLUTION: The system includes a regular mode execution part 11a for performing data processing to vehicle state information collected during driving of the vehicle, and a trial mode execution part 11b for performing data processing on the basis of sample data of vehicle state information stored in a sample data storage part 12b-3. The trial mode execution part reads the sample data at the start-up and registers it in a database for trial mode 12b-1 which is temporal storage means, and carries out a demonstration on the basis of the registered data, while it deletes the data registered in the database at the end of demonstration.

Description

  The present invention relates to a system and a program for analyzing and evaluating a driving state or the like based on log information measured and collected while a vehicle is running, and for managing operation.

  There is a management device that collects and analyzes information about traveling of a vehicle recorded during traveling to manage the driving state of the driver. When the operation management device disclosed in Patent Document 1 detects and counts an event when a speed difference within a unit time is equal to or greater than a threshold, if the event occurs continuously, the plurality of consecutive A speed change event is counted as one speed change. The event to be counted becomes a dangerous driving. The management of the driving state in the management device is not limited to counting the degree of dangerous driving described above, and there are various types such as managing traveling history information such as a traveling distance and a traveling route.

  This type of management apparatus is configured by installing a predetermined application program in a personal computer. Then, before actually installing and using the management apparatus, the user has a request to test the function and operability and confirm whether it is useful for the user. In order to satisfy such a requirement, an application program with a partial function restriction may be distributed as a trial version. With this partial function restriction, there is a problem that the restricted function cannot be confirmed. Therefore, there are some which have the same function as the regular version but limit the volume used such as the number of uses and the period of use. Users can try the same functions as the regular version, and if they want to continue using it, purchase a “key” to remove the restriction and use the “key” to remove the restriction. become. After release, it works as a normal regular version.

  Although not this type of management device, for example, in Patent Document 2, in a navigation device mounted on a vehicle, demonstration map data is provided and the map data is read out and a demonstration screen is displayed on the display screen. Techniques to do this are disclosed. By viewing this demonstration screen, the user can understand the functions of the navigation device by viewing the contents of the demonstration.

JP 2008-40766 A Japanese Patent No. 3351650

  In the system for evaluating and managing the driving state targeted by the present invention, it is impossible to correctly confirm the actual usability including operability unless a certain amount of information related to the traveling of the vehicle recorded during traveling can be acquired. Therefore, it takes days and the number of times to use it, and it takes time to introduce the official version. Also, since it takes time, the trial method using the “trial version” or “use volume restriction” in the general application program described above is not suitable. In the case of “use volume restriction”, after being released using the “key”, it becomes a regular version, and even when reconfirming operability, it is performed based on actually collected actual data. As a result, if the operation is wrong, the actual data used for the actual operation may be deleted or changed.

  In order to achieve the above-described object, a system according to the present invention is (1) a system that performs data processing based on vehicle state information obtained during travel of the vehicle, and obtains the data processing by actual travel. A normal mode executing means for performing the data processing based on the sample data, and a normal mode executing means for performing the data processing based on the sample data. The normal mode execution unit corresponds to the real mode execution unit 11a and the mode execution unit 11d of the embodiment, and the demo mode execution unit corresponds to the trial mode execution unit 11b and the mode execution unit 11d of the embodiment. The actual mode execution means and the demonstration mode execution means may be configured separately as in the embodiment, or may be configured integrally as in the modification.

  Data processing includes, for example, performing a predetermined evaluation based on vehicle state information and managing such information. For example, the evaluation is performed by analyzing vehicle state information such as the safe driving evaluation of the embodiment. Management includes, for example, extracting and summing up vehicle condition information that meets conditions without performing analysis such as operation management, taking statistics, and processing data. The actual data may be raw data collected as the vehicle travels, or may be processed data obtained by performing predetermined arithmetic processing on the raw data. By preparing sample data in advance and operating the demo mode execution means using the sample data, the user can actually operate the vehicle and collect actual data without analyzing the operability and analysis of this system. The output status such as the result can be confirmed correctly. Therefore, by preparing and providing a large number of sample data in advance, it is possible to confirm a state after a certain period of time in which a large number of data has been accumulated before actually starting use or immediately after the start of use.

  (2) The normal mode execution means and the demo mode execution means may operate alternatively. Since both execution means coexist in the system and operate alternatively, even after starting to use the normal mode, the demonstration mode execution means can be activated at any time and the operation can be confirmed using sample data or the like. Therefore, even if the vehicle state information is deleted or incorrect correction / processing is performed, the actual data actually used is not affected and there is no problem because it is in the demo mode. As a result, the user can confirm the operation at any time with peace of mind.

  (3) It is preferable to include means for switching between the normal mode execution means and the demo mode execution means. The switching means corresponds to the activation processing unit 11c in the embodiment. In the embodiment, an instruction input from the user is awaited at the time of activation, and the execution unit in the designated mode is activated.

  (4) The normal mode execution means reads the actual data stored in the nonvolatile recording medium and executes processing, and the demo mode execution means reads the sample data stored in the nonvolatile recording medium. It is good to execute processing. The non-volatile recording medium for recording actual data and the non-volatile recording medium for recording sample data may be the same non-volatile recording medium or different non-volatile recording media. In the embodiment, the non-volatile recording medium storing the actual data corresponds to the normal mode database 12a-1. The non-volatile recording medium in which the sample data is stored corresponds to the sample data storage unit 12b-3 in the embodiment. The process includes an operation evaluation process using the read data (actual data / sample data), an operation management process, and a data update process such as data correction / addition / deletion.

  (5) On the premise of the invention of the above (4), the sample data on the non-volatile recording medium is not changed at least at the end of the demo mode from that at the start of the demo mode. The actual data on the medium may be changed according to the operation of the normal mode execution means.

  The change of the actual data on the nonvolatile recording medium is, for example, that the contents of the recorded data are changed. In addition, for example, new data is added or recorded data is deleted. The addition of new data includes, for example, reading new actual data collected as the vehicle actually travels and adding it to the nonvolatile recording medium. Data deletion includes, for example, deleting data that is no longer necessary, such as data that is no longer a management target or is incorrect, from the recorded actual data. Updating data on a volatile recording medium includes adding, changing, and deleting data. Since the sample data is not changed at the end of the demo mode at the end of the demo mode, the sample data captured at the start of the next demo mode is the same as this time. In other words, the content of the sample data at the start of the demo mode is always guaranteed to be the same, so even if the user deletes the sample data or changes the content during the demo mode, a new demo is available. When the mode is activated, the original contents are not deleted. Therefore, the user can confirm the operability with peace of mind by freely correcting or deleting the sample data in the demo mode.

  (6) The sample data is a database, and has a function of creating a demo mode database for processing by copying the sample data when starting the demo mode, and the demo mode executing means is for the demo mode for processing. It is recommended to process the database. The sample data is a database with the same structure as the demo mode database to be processed and accessed by the demo mode execution means in the demo mode, and a simple process such as database copy (for example, overwriting copy of the database file) takes a short time. Can create a demo mode database for processing. Since the demo mode execution means accesses and updates the demo mode database for processing and does not rewrite the sample data, the contents of the sample data are always the same. Then, at the time of starting the demo mode, the contents of the sample data are recorded in the demo mode database for processing by using the overwrite copy of the database. The initial state is always the same as the content of the sample data no matter how the content changes. The demo mode execution means does not need to erase the demo mode database when the demo mode ends.

  (7) The sample data read by the demonstration mode execution means is recorded on a volatile recording medium, and the demonstration mode execution means executes the processing using the data recorded on the volatile recording medium, It is preferable to have a function of updating data on the volatile recording medium with the processing. The volatile recording medium in this case corresponds to the trial mode database 12b-1 of the embodiment. Since the data on the volatile recording medium is erased when the application (system) is terminated or the apparatus is turned off, the demo mode execution means does not need to erase the demo mode database at the end of the demo mode.

  (8) Based on the above inventions (5) to (7), the normal mode execution means has a function of updating the actual data stored in the nonvolatile recording medium based on the updated data. The demo mode execution means may include only a read function as an access function to the nonvolatile recording medium. In the actual data update, a part or all of the updated data in the volatile recording medium is reflected in the nonvolatile recording medium.

  The demo mode execution means performs processing based on the data stored in the volatile recording medium, so that the contents of the volatile recording medium are automatically erased when the system (demonstration mode execution means) ends, and then the demo When starting the mode execution means, the sample data recorded in the nonvolatile recording medium is registered in the volatile recording medium. The demo mode execution means can read but not write to the non-volatile recording medium. Therefore, when the user activates the demo mode execution means, the same sample data is always registered in the volatile recording medium regardless of the data content at the previous end. That is, the data registered in the volatile recording medium and processed by the demo mode execution means is valid only when the system or the demo mode execution means is activated. Therefore, the user can freely try various processes.

  (9) The demo mode execution means may have the same functions except for the function of updating the data stored in the nonvolatile recording medium, among the functions of the normal mode execution means. In this way, the function performed by operating the normal mode execution means can be confirmed by the demo mode execution means.

  (10) The demonstration mode execution means may have a function of fetching the actual data and processing the data. Capturing and processing the data means, for example, that the demo mode execution means reads the actual data, stores it in the storage means for storing the data processed by itself, and performs predetermined data processing on the actual data there, The demo mode execution means does not access the recording means in which the actual data to be processed by the normal mode execution means is changed (modification, deletion, etc.). This function of the demo mode execution means is such that the result of data processing on the actual data performed by the demo mode execution means does not change the contents of the storage means that records the actual data to be processed by the normal mode execution means. Is to do so. The actual data includes, for example, vehicle state information collected when the vehicle actually travels, data stored in the normal mode database 12a-1 and the like recorded in the SD memory card 7 referred to in the embodiment. . For example, the demo mode execution means reads the actual data recorded in the SD memory card, registers it in the storage area accessed by the demo mode execution means (the trial mode database 12b-1 of the embodiment, and executes the demo mode execution means. Is to access the registered database and perform predetermined data processing, in which case only actual data may be registered or mixed with sample data in the storage area. Further, for example, a demo mode database (for trial use of the embodiment) accessed by the demo mode execution means by a simple process of copying the normal mode database 12a-1 and copying the database (for example, overwriting copy of the database file). The database 12b-1) is generated, and the demo mode execution means is the demo mode database. Access to perform data analysis, data update, and other data processing, so that the recorded contents of the database etc. accessed by the normal mode execution means are not changed, and in the present invention, the demo mode execution means uses the actual data. Since it can be used for trial, a more realistic demonstration can be performed according to the user's usage environment and situation.

  (11) The demonstration mode execution means may have a function of processing the actual data and the sample data in a mixed state. This is preferable because the number of data to be processed (vehicle state information) increases. In particular, at the initial stage of actual operation, more data can be obtained by performing various processes using actual data collected as the vehicle actually travels, while securing the number of sample data. In addition to being able to confirm operability, etc. by demos using numbers, it is possible to check the user's usage environment and situation by using some actually collected data when performing aggregation processing and operation management over a certain period of time. A more realistic demonstration can be performed.

  (12) The sample data and the actual data may have the same data structure. The items of the sample data can be used as part of the actual data, and the functions of this system can be tested based on the data. However, using the same data structure as in the present invention is preferable because all functions can be demonstrated and confirmed more accurately.

  (13) The program of the present invention is a program for causing a computer to realize the functions in the system according to any one of (1) to (12).

  According to the present invention, it is possible to correctly confirm the actual usability including operability even during the initial period of use in which a certain amount of information related to vehicle travel recorded before actual use and during travel cannot be obtained. it can.

It is a figure which shows an example of a vehicle travel data collection apparatus. It is a figure which shows the installation position etc. of an OBD2 connector. It is a figure which shows an example of the file structure in SD memory card. It is a figure which shows one Embodiment of the driving | running state evaluation system concerning this invention. It is a flowchart explaining the function of the arithmetic processing part of a driving | running state evaluation system. It is an example of the display screen explaining the function of an arithmetic processing part. It is an example of the display screen explaining the function of an arithmetic processing part. It is a figure which shows the principal part of one Embodiment of the driving | running state evaluation system concerning this invention. It is an example of the display screen explaining the function of an arithmetic processing part. It is an example of the display screen explaining the function of an arithmetic processing part. It is an example of the display screen explaining the function of an arithmetic processing part. It is an example of the display screen explaining the function of an arithmetic processing part. It is an example of the collected log information. It is a figure explaining the division of acceleration. It is a flowchart explaining the function of the arithmetic processing part of a driving | running state evaluation system. It is a figure which shows an example of the buffer memory structure explaining the function of an arithmetic processing part. It is an example of the display screen explaining the function of an arithmetic processing part. It is an example of the display screen explaining the function of an arithmetic processing part. It is an example of the display screen explaining the function of an arithmetic processing part. It is an example of the display screen explaining the function of an arithmetic processing part. It is an example of the display screen explaining the function of an arithmetic processing part. It is an example of the display screen explaining the function of an arithmetic processing part. It is an example of the display screen explaining the function of an arithmetic processing part. It is an example of the display screen explaining the function of an arithmetic processing part. It is an example of the display screen explaining the function of an arithmetic processing part. It is an example of the display screen explaining the function of an arithmetic processing part. It is an example of the display screen explaining the function of an arithmetic processing part. It is an example of the display screen explaining the function of an arithmetic processing part. It is an example of the display screen explaining the function of an arithmetic processing part. It is an example of the display screen explaining the function of an arithmetic processing part. It is a figure which shows the principal part of the modification of the driving | running state evaluation system which concerns on this invention. It is a flowchart explaining the function of the arithmetic processing part of the driving | running state evaluation system of the modification which concerns.

[Vehicle travel data collection device]
FIG. 1 shows an example of a vehicle travel data collection device that collects data to be analyzed according to the present invention. As shown in FIG. 1, the vehicle travel data collection device 1 includes a device main body 2, a vehicle connection adapter 3, and a GPS module 4. The apparatus body 2 and the vehicle connection adapter 3 are connected by a connection cable 5. The apparatus body 2 and the GPS module 4 are connected by a connection cable 6. One end of each of the connection cables 5 and 6 is integrally connected to the vehicle connection adapter 3 and the GPS module 4, and a male connector terminal is provided at the tip of the other end. This connector terminal is connected to a female connector terminal provided on the back surface of the apparatus main body 2.

  The vehicle connection adapter 3 is detachably attached to an OBD-II (II is a Roman numeral “2”, hereinafter “OBD-II” is referred to as “OBD2”) connector mounted on the vehicle. The OBD2 connector is also referred to as a failure diagnosis connector, and is connected to the ECU of the vehicle to output various vehicle information. Therefore, the vehicle travel data collection device 1 periodically acquires various types of vehicle information by connecting the vehicle connection adapter 3 and the OBD2 connector on the vehicle body side. Vehicle information to be acquired includes vehicle speed, engine speed, MAF value (mass air flow), injection opening time, throttle opening, and the like. The OBD2 connector is also connected to a battery on the vehicle side, and power can be supplied from a predetermined terminal of the OBD2 connector when the ignition switch is turned on. Therefore, the vehicle travel data collection device 1 also receives power supply from the battery on the vehicle side.

  The GPS module 4 incorporates a GPS antenna and a receiving circuit, receives a GPS (Global Positioning System) signal, detects the current position (longitude / latitude), time / altitude (3D positioning mode), etc. 6 to the apparatus body 2 side. In addition, the battery power supply of the vehicle from an OBD2 connector is used for the operation power supply of the GPS module 4.

  The apparatus main body 2 includes a case main body 2a formed of a rectangular housing, an SD memory card slot 2b provided on the front surface of the case main body 2a, an LED 2c for informing an operation state, and 2 formed on the rear surface of the case main body 2a. Two female connector terminals and a mode command switch 2d. Further, the case body 2a includes a control unit that performs arithmetic processing and other processes including a CPU, a triaxial acceleration sensor, a buzzer, and an interface for connecting to an external device.

  The control unit is a microcomputer including a CPU, ROM, RAM, nonvolatile memory, I / O, and the like. The above-described various input devices (SD memory card slot 2b, acceleration sensor, vehicle connection adapter 3, GPS module 4) ) Is executed on the basis of the information input from (), and a predetermined alarm or information is output using the above-mentioned various output devices (SD memory card slot 2b, LED 2c, buzzer).

  The LED 2c is turned on when the engine is started and turned off when the engine is stopped. The LED 2c that is lit flashes at regular intervals (for example, 1 second) in normal times, and blinks at a cycle shorter than the regular intervals when abnormal. Engine start / stop determination is made by detecting superimposed noise on the power line. These determinations and blinking control are performed by the control unit. Thereby, a user (driver) can confirm that it was operating normally and there was abnormality by seeing blinking of LED2c. Here, the abnormality may be, for example, dangerous driving.

  The acceleration sensor detects the behavior of the vehicle, and detects the acceleration applied to the X axis in the traveling direction, the acceleration applied to the Y axis in the horizontal direction, and the acceleration applied to the Z axis in the vertical direction. As a result, the X-axis detects sudden acceleration / deceleration, the Y-axis detects a sudden handle, and the Z-axis detects a predetermined behavior of the vehicle such as climbing a step or falling into a depression. In the present embodiment, dangerous driving is detected based on the outputs of the X axis and the Y axis. The LED 2c is turned on when the engine is started and turned off when the engine is stopped. The LED 2c that is lit flashes at regular intervals (for example, 1 second) in normal times, and blinks at a cycle shorter than the regular intervals when abnormal. Engine start / stop determination is made by detecting superimposed noise on the power line. These determinations and blinking control are performed by the control unit. Thereby, a user (driver) can confirm that it was operating normally and there was abnormality by seeing blinking of LED2c. Here, the abnormality may be, for example, dangerous driving.

  The buzzer is disposed immediately below the speaker opening 2e provided on the top surface of the case body 2a. The control unit outputs an alarm buzzer sound when the output of the acceleration sensor is equal to or greater than a set threshold value. The sounding pattern of the alarm buzzer sound varies depending on the type of dangerous driving (rapid acceleration, rapid deceleration, sudden steering) and the level (magnitude of sensor output).

The control unit accesses the SD memory card 7 inserted in the SD memory card slot 2b, and reads and writes data. That is, the control unit reads a file recorded on the SD memory card 7 to perform various settings, and regularly collects data (log information), position information, and the like relating to vehicle travel collected during operation in the SD memory. Or record on the card 7.
Hereinafter, the function of the control unit will be described while explaining the operation during actual use from the installation of the vehicle travel data collection device 1.

* Installation FIG. 2A shows an example of an installation position of the OBD2 connector, and FIG. 2B shows a front view of the OBD2 connector. As shown in FIG. 2 (a), the installation position varies depending on the vehicle type. For example, (1) the side of the accelerator pedal, (2) the right side of the driver's seat, (3) the center of the driver's seat, (4) the driver's seat Left side of foot, (5) Right side of center console, (6) Right side of foot of passenger seat, (7) Back side of steering panel, (8) Left side of foot of passenger seat, (9) Left side of center console, (10) Bottom of center console and so on. In any case, the OBD2 connector exists around the handle.

  Therefore, the user first connects the vehicle connection adapter 3 to the OBD2 connector of the vehicle. At this time, the vehicle connection adapter 3 and the apparatus main body 2 are connected by the connection cable 5. The apparatus main body 2 is fixed to a center console or an instrument panel so as not to hinder driving. For fixing, a double-sided adhesive tape or the like is used.

* Initial setting The communication protocol for vehicle information varies depending on the car manufacturer and the model. Therefore, prior to use, it is necessary for the vehicle travel data collection device 1 (control unit) to recognize which vehicle is installed. In the present embodiment, the vehicle type of the installed vehicle is set using the initial setting file recorded in the SD memory card 7.

  That is, as shown in FIG. 3, the SD memory card 7 stores a setting file and a data recording file. Two setting files, an initial setting file and a normal setting file, are prepared. In the initial setting file, vehicle type information including a vehicle manufacturer name and a vehicle type name is recorded. This vehicle type information is recorded on the SD memory card 7 by the driving state evaluation system, as will be described later.

  The initial setting is performed by pressing the mode command switch 2d while the SD memory card 7 is mounted in the SD memory card slot 2b. When detecting that the mode command switch 2d is pressed, the control unit reads the initial setting file in the SD memory card 7 to obtain the vehicle type information, and stores it in the nonvolatile memory in the vehicle travel data collection device 1 (case body 2). Write. Since the vehicle type information is registered and stored in the nonvolatile memory, the vehicle type information may be performed once at the time of installation in the initial setting.

* Normal setting Normal setting allows the vehicle travel data collection device 1 to memorize the card information of the SD memory card, the sensor level, and optional information such as whether or not the GPS module is connected. The sensor level (impact sensitivity level) determines the detection sensitivity of the acceleration sensor, and one of five levels is set. The lower the level (numerical value), the lower the sensitivity (the alarm buzzer will not sound unless there is a large impact), and the higher the level (numerical value), the higher the sensitivity (the alarm buzzer will sound even for a small impact). In an actual operation while the vehicle is running, an alarm buzzer is notified when the output of the acceleration sensor exceeds a set level. More specifically, the five levels are classified as follows: Level 1 sounds at 0.5G or higher, Level 2 sounds at 0.4G or higher, Level 3 sounds at 0.3G or higher, Level 4 sounds at 0.2G or higher , Level 5 is set to sound at 0.1G or more.

  This normal setting is performed each time the SD memory card 7 is inserted into the SD memory card slot 2b. That is, when the control unit detects that the SD memory card 7 is attached, the control unit reads the normal setting file in the SD memory card 7 and writes the acquired information in the RAM.

* Installation mode The case body 2 has a built-in triaxial acceleration sensor. The installation mode is a mode for initializing the built-in acceleration. It is executed when the installation location of the main body is changed or another vehicle is transferred. In this initialization, the following processing is performed with the case body 2 fixedly installed at a predetermined position of the vehicle. First, the user stops the vehicle at a horizontal position, and presses the mode command switch 2d for a long time (for example, 5 seconds or more) in a state in which the SD memory card is not installed, and then travels straight ahead. When the control unit 18 detects that the mode command switch 2d is pressed for 5 seconds or longer with the SD memory card not attached, the control unit 18 switches to the installation mode, determines the direction in which the acceleration is applied as the Z-axis direction, and then A traveling direction (X-axis) is determined from the direction of acceleration accompanying the straight traveling of the vehicle, and a direction orthogonal to the determined Z-axis and X-axis is determined as a lateral direction (Y-axis).

* Normal operation The user starts the engine with the SD memory card 7 inserted. The control unit records information (log information) on the traveling of the vehicle collected every second in the SD memory card 7 when both conditions of engine start and installation of the SD memory card 7 are satisfied. Information related to vehicle travel includes current date and time information, current position information (latitude, longitude, height, etc.), acceleration sensor output (X-axis, Y-axis, Z-axis), vehicle information (vehicle speed, engine speed, MAF). Value (mass air flow), injection opening time, throttle opening, etc.). The controller sets one data collection period from engine start to stop, and creates one file for each data collection period. This file has a configuration in which terminal information such as a driver is recorded at the head, and thereafter log information collected every second is sequentially recorded. This terminal information is registered in the SD memory card by executing the driving state evaluation system as will be described later.

  The control unit that acquired 100 acceleration sensor outputs (acceleration of X, Y, and Z) per second (10 ms cycle) divides each 100 values into 5 groups of 20 units, and averaged the values in each group. Further, the maximum values are recorded on the SD memory card. The unit of the output value of the acceleration sensor is gravitational acceleration (G) (1G = 9.8 m / sec ^ 2). The average value is obtained in this way because the output of the acceleration sensor includes errors and variations, so that the influence of the errors and variations is reduced. Moreover, it is divided into a plurality of groups (here, five), and the maximum value among them is obtained for the following reason. In this embodiment, the unit for collecting data is every second, but the driving behavior is not always the same during the one second. And, when driving with a large acceleration in one period (relatively short period) in one second and driving with a small acceleration in other periods, driving with a momentary large acceleration However, there is a case where it is determined that the driving is not dangerous driving because the obtained acceleration is lowered by calculating the average of 100 samples sampled in all sections. Therefore, by dividing into a plurality of groups and recording the maximum value between the groups as an acceleration, a large acceleration generated in one period in the one second is buried by a small acceleration generated in another period. That is restrained.

  The control unit outputs an alarm buzzer when the output value of at least one of the axes of the acceleration sensor (the value obtained by calculation recorded on the SD memory card) is equal to or higher than the sensor level set in the normal setting. To do. The volume of the alarm buzzer is a fixed level in this embodiment.

  The control unit determines whether the vehicle suddenly accelerates or suddenly decelerates based on the sensor output value of the X axis. That is, in this embodiment, when the speed is accelerated when traveling forward in the traveling direction, the sensor output value of the X axis shows a positive value, and the speed is increased when traveling forward in the traveling direction. When the vehicle is decelerating, the X-axis sensor output value is set to indicate a negative value. Therefore, the control unit determines that the X-axis sensor output value is an acceleration value when the absolute value of the X-axis sensor output value is equal to or higher than the set sensor level and the output value is positive. Is greater than the set sensor level and the output value is negative, it is determined that the vehicle is suddenly decelerating.

  Since the Y-axis sensor output value is the acceleration applied in the lateral direction, it is the lateral G applied to the driver when the steering wheel is turned. The sign of the sensor output value varies depending on whether the direction in which the handle is turned is right or left. The driving behavior is a dangerous driving that leads to an accident when the steering wheel is suddenly turned and a large lateral G is applied. If the absolute value of the magnitude is the same, the steering wheel is turned in either direction. But the risk does not change. Therefore, the control unit determines that the handle is in a sudden handle when the absolute value of the Y-axis sensor output value is equal to or higher than the set sensor level.

  And a control part performs the sounding of the alarm buzzer according to the kind of dangerous driving | operation, and blinking control of LED according to said determination result. The sensor output value of the Z axis is recorded but not used for alarming.

  When the user gets off the vehicle after stopping the engine, the user takes out the SD memory card 7 from the SD memory card slot 2b, sets the SD memory card 7 in a driving state evaluation system composed of a personal computer, and applies the information on the traveling of the vehicle recorded during the traveling. Suck into the driving condition evaluation system.

<Basic configuration of operating state evaluation system>
The driving state evaluation system is configured by a personal computer. Therefore, as shown in FIG. 4A, the hardware configuration of the driving state evaluation system includes an arithmetic processing unit 11, a storage unit 12, an input unit 13, a display unit 14, and a card reader 15. The storage unit 12 is a non-volatile memory that stores an application program executed by the arithmetic processing unit 11, a work memory that the arithmetic processing unit 11 uses during the execution of the operation, and an administrator to be specified for performing the operation state evaluation. Internal or external storage device for recording management information such as driver, vehicle, SD memory card, etc. (registrant file, vehicle information file, terminal information file) and vehicle status information recorded during driving (Hard disk) (see FIG. 4B). The input unit 13 is a pointing device such as a mouse or a keyboard. The card reader 15 is a device that reads / writes data from / to the loaded SD memory card 7.

  This driving state evaluation system analyzes the information on vehicle travel collected by the vehicle travel data collection device described above, evaluates the behavior of the driver, more specifically, safe driving and eco-driving, and outputs the result. It has a function to do.

  Evaluation of safe driving is as follows. In the present embodiment, it is assumed that there is a dangerous driving when the acceleration sensor output exceeds a predetermined threshold, and the number of times that the dangerous driving has occurred is counted and output. In other words, the safe driving index decreases as the number of dangerous driving occurrences increases. If the number of dangerous driving occurrences is zero, it can be said that the driving is safe driving. In this way, the safe driving index is evaluated based on the number of dangerous driving occurrences.

  When the vehicle travel data collection device 1 includes the GPS module 4 as in this embodiment, the travel history is also recorded. Therefore, the driving state evaluation system links the travel history data and the acceleration sensor output, and also provides information such as at which position there is a dangerous driving in which the output value of the acceleration sensor exceeds the threshold value.

* Starting process By starting an application program (referred to as “PC viewer” in the present embodiment) installed in the storage unit 12, the personal computer operates as an operating state evaluation system.

  As shown in FIG. 5, when the PC viewer is started in accordance with normal program startup processing (clicking on shortcut keys, clicking on menu items in the program menu list, etc.) of the personal computer (S1), the arithmetic processing unit 11 A PC viewer activation screen shown in FIG. 6A is displayed on the display unit 13 and waits for selection of whether to use the trial mode or the normal mode (S2). The user operates a pointing device that is the input unit 14 and clicks one of two input buttons of “normal mode activation” and “trial mode activation” provided in the PC viewer activation screen. Therefore, the arithmetic processing unit 11 detects which of the two input buttons is clicked and activates the corresponding mode.

  When “normal mode activation” is selected (No in S2), the arithmetic processing unit 11 determines whether or not the administrator user is unregistered (S3). That is, the arithmetic processing unit 11 accesses the registrant file in the storage unit 12 to determine whether or not at least one administrator user is registered. If it is not registered, the caution shown in FIG. A message is displayed on the display unit 13 (S4), waits for the click of the “OK” button, and executes an administrator user registration process (S5). The arithmetic processing unit 11 displays a new registration screen for the administrator user shown in FIG. The user operates the input unit 14 to input an administrator name, an account name, and a password in each text input box on the new registration screen, and clicks the “Register” button. Therefore, the arithmetic processing unit 11 creates administrator user information having a table structure in which they are associated based on the input information, and stores the administrator user information in the registrant file.

  Here, the administrator user has the authority to register / delete / change registrant information / vehicle information / terminal information, which will be described later, and the authority to set SD card, import SD card data, and view operation data for all users. Have. The administrator name is the user's screen display name and can be changed later. The account name is the account at login and cannot be changed. Further, the password is a password at the time of login, and can be changed later.

  Next, the arithmetic processing unit 11 executes a login process (S6). That is, the arithmetic processing unit 11 displays a login screen shown in FIG. The user operates the input unit 14, inputs a user account and a password in each text input box on the login screen, and clicks a login button. The arithmetic processing unit 11 determines whether or not the combination of the input user account and the password matches the one stored in the registrant file. The main screen (see FIG. 7B) is displayed. As will be described later, the normal mode is executed by the normal mode execution unit 11a shown in FIG.

  If the administrator user has already been registered (Yes in S3), the process jumps to step S6, and the arithmetic processing unit 11 displays the login screen and executes the login process (S6). Further, when an administrator user is registered as will be described later, the administrator user also registers information related to the driver to be managed. Therefore, by registering a user account and password for the driver, the driver can also log in to the system and view the PC viewer screen. The registered administrator user adds a user account for the driver and a new administrator user account.

  The main screen of the PC viewer shown in FIG. 7B is displayed with the execution of a series of processing steps after new administrator user registration. That is, since information related to vehicle travel has not been registered, each result display area is blank. When information related to vehicle travel is registered in the storage unit 12, the arithmetic processing unit 11 accesses the storage unit 12 to read out information related to vehicle travel registered therein, and to the read information. The analysis process is performed, and the analysis result is displayed on the main screen of the PC viewer.

  Also, as shown in Fig. 7 (b), clicking on the menu prepared in the upper part of the main screen (the part surrounded by an oval) executes the corresponding functions and displays the results displayed during data collection and analysis. Can be set. The menu items are “operation data list”, “operation data all day management”, “operation data period totaling”, “form”, “data import”, “terminal SD card setting”, “management”, “order” from the left. “Change Password”, “User Switch”, “Version Information”.

  On the other hand, when “trial mode activation” is selected (S2 is Yes) in the PC viewer activation screen (FIG. 7A) and waiting for instructions (S2), the arithmetic processing unit 11 performs the trial mode. The main screen (see FIG. 7B) of the PC viewer based on the execution of is displayed. The trial mode is executed by the trial mode execution unit 11b shown in FIG. 8, as will be described later. In brief, the arithmetic processing unit 11 accesses the storage unit 12, reads a sample data file for demonstration registered in the storage unit 12, and tries the storage unit 12 as trial mode data for processing. Copy to the mode processing database file. The arithmetic processing unit 11 accesses the storage unit 12 to read the overwritten and copied trial mode processing database file, perform analysis processing, and display the analysis result on the main screen of the PC viewer (FIG. 7B). Output to the result display area.

** Trial Mode As is clear from the flowchart described above, the present invention has a “trial mode” for demonstration in addition to the “normal mode” for performing various evaluations and operation management. In the normal mode, the driver who is actually subject to evaluation and management drives the vehicle, records the vehicle state information collected during the vehicle's travel, and performs various evaluations and operation management based on the recorded vehicle state information. It is a mode to perform. In the trial mode, various evaluations and operation management are performed based on virtual sample data corresponding to the vehicle state information.

  The operation of this trial mode is the same as the normal mode with the data to be used as sample data, and it is possible to register additional information related to new vehicle travel and user accounts, It has a function to change or delete.

  Since these processes and operations are the same as in the normal mode, the user can check the operability of the operating state evaluation system and the output status of the analysis results by starting and using this trial mode. Can be assumed correctly. Therefore, by easily providing a large number of sample data in advance, it is possible to confirm a state after a certain period of time in which a large number of data has been accumulated immediately after the start of use. Furthermore, in the present embodiment, as described later, it is possible to take in vehicle state information collected when the vehicle actually travels, and use the test mode using the actual vehicle state information. However, the registration / change / deletion of data when starting in the trial mode is only a temporary change, and the data change is not saved when the application ends.

  FIG. 8 shows a main configuration of the driving state evaluation system having the trial mode and the normal mode. As shown in the figure, the application program installed in the arithmetic processing unit 11 includes a normal mode execution unit 11a, a trial mode execution unit 11b, and an activation processing unit 11c. The activation processing unit 11c has a function of executing each process of S1 to S6 in the flowchart shown in FIG. And the starting process part 11c receives the input from a user, and starts the normal mode execution part 11a and the trial mode execution part 11b alternatively.

  The storage unit 12 includes a normal mode database 12a-1 as a normal mode storage area 12a and a normal mode management file 12a-2, and a trial mode database 12b-1 as a test mode storage area 12b. A trial mode management file 12b-2, a sample data storage unit 12b-3, and a management information template storage unit 12b-4.

  The normal mode database 12a-1 and the trial mode database 12b-1 have the same data structure, and correspond to the database storing the vehicle state information file of FIG. 4B. The normal mode management file 12a-1 and the trial mode management file 12b-2 have the same file types and items to be recorded. The registrant file and vehicle information shown in FIG. Corresponds to file and terminal information file.

  Further, the sample data storage unit 12b-3 records sample data for demonstration. This sample data is demo data corresponding to vehicle state information collected when the vehicle is running. There are various types and numbers of files, such as files with different dates, files when traveling multiple times on the same day, files with different patterns of driving behavior, and files with different drivers and vehicles. There are different driving behavior patterns, for example, safe driving patterns and dangerous driving patterns. Even when driving dangerously, the output level of the acceleration sensor is different, as in the X-axis and Y-axis. Some items have different levels. Furthermore, the appearance of various items of vehicle status information other than the dangerous driving judgment (acceleration sensor output value) differs from the driving behavior different patterns (traveling speed exceeds the threshold, idling is long ... ...) There is also a thing.

  In the management information template storage unit 12b-4, a template of management information associated with the sample data is registered. That is, it is information on the vehicle and the driver who traveled, and information on the manager.

  The normal mode execution unit 11 a accesses the normal mode storage area 12 a set in the storage unit 12, acquires the vehicle state information collected along with the travel recorded in the SD memory card 7, and Store in the mode database 12a-1, analyze the vehicle state information stored in the normal mode database 12a-1, output the analysis results, create / update the normal mode management file 12a-2 Various types of processing are performed. Specific functions of the normal mode execution unit 11a, and details of the normal mode database 12a-1 and normal mode management file 12a-2, settings, and the like will be described later.

  On the other hand, the trial mode execution unit 11b accesses the sample data storage unit 12b-3 at the time of activation, reads the sample data stored therein, and registers it in the trial mode database 12b-1. In addition, the management information template (each file such as a registrant file and a vehicle information file) stored in the management information template storage unit 12b-4 is read out, and is also stored in the trial mode management file storage unit 12b-2. sign up. Then, the trial mode execution unit 11b performs an analysis process on a predetermined file (for example, the latest running date) stored in the trial mode database 12b-1, and outputs the result to the main PC viewer. Display as a screen.

  Further, the trial mode execution unit 11b acquires vehicle state information collected along with the travel recorded on the SD memory card 7 in the same manner as the normal mode execution unit 11a, and stores it in the trial mode database 12b-1. A function for additional storage is provided. The vehicle state information acquired by actual vehicle travel added at this time and the sample data registered in advance at the time of activation are registered in the same database without being distinguished from each other. Therefore, it is possible to create and analyze a form by combining both. Further, the trial mode execution unit 11b has a data update function for adding, correcting, or deleting data registered in the database or the management file as in the normal mode execution unit 11a.

  Then, the trial mode execution unit 11b deletes the data stored in the trial mode database 12b-1 and the trial mode management file storage unit 12b-2 at the end. Since the sample data is stored in the sample data storage unit 12b-3, when the trial mode is selected at the next start-up, the trial mode execution unit 11b accesses the sample data storage unit 12b-3 again. Sample data is acquired and registered in the trial mode database 12b-1. Therefore, even if part or all of the sample data is deleted or the recorded contents are changed while the previous trial mode is activated, the application returns to the initial state once it is terminated and restarted. In this way, the user can perform processing based on sample data prepared in advance. Therefore, the user can feel free to try the process of changing or deleting the sample data or the data about the vehicle state information.

  Furthermore, even after registering the administrator user and starting to use the normal mode, the user can activate the trial mode at any time and confirm the operation using the sample data and the actual vehicle status information. There is no problem even if the vehicle status information is deleted or the wrong correction is made during the work. Therefore, for example, when the operation is unknown during actual operation, the user once ends the process, starts the trial mode, and operates using the actual vehicle state information and the like. At that time, there is no problem even if the vehicle state information registered in the trial mode database is mistakenly deleted, so that the user can confirm the operation with peace of mind.

  Next, actual processing functions of the normal mode execution unit 11a and the trial mode execution unit 11b will be described. As described above, the registration / change / deletion of data when starting in the trial mode is only a temporary change, and all execution units are basic except that the data change is not saved when the application ends. The general process is the same. Therefore, in the following description, it demonstrates as a function of the arithmetic processing part 11. FIG. Each function of the arithmetic processing unit 11 is a function of the normal mode execution unit 11a and also a function of the trial mode execution unit 11b.

* Initial setting process After starting up the PC viewer, it is necessary to use the SD memory card to collect information on vehicle travel, and to perform operations such as analysis and result display. "And" terminal "information must be set and registered. Further, by this initial setting, a file in which each information is registered in a non-volatile storage area such as a hard disk constituting the storage unit 12 is generated. Information registered in this file can be added or updated thereafter.

* Driver information management When the driver information to be used is unregistered, the administrator user executes driver registration processing. Specifically, the administrator user clicks “management” in the menu at the top of the main screen. When the arithmetic processing unit 11 detects that the “management” is clicked, it displays a pull-down menu having three menu items of “vehicle list”, “terminal list”, and “registrant list”. When the arithmetic processing unit 11 detects that the “registrant list” has been clicked, the arithmetic processing unit 11 accesses the registrant file in the storage unit 12 and acquires the registered administrator user and driver information. The registrant list screen shown in 9 (a) is displayed.

  When the arithmetic processing unit 11 detects that the “new driver registration” button on the registrant list screen is clicked, the arithmetic processing unit 11 displays a new driver registration screen shown in FIG. 9B on the display unit 13. This new registration screen is actually displayed over the registrant list screen. The administrator user operates the input unit 14 to input the driver name, account name, and password in each text input box on the new registration screen, and clicks the “Register” button. Therefore, the arithmetic processing unit 11 creates driver information having a table structure in which the information is associated based on the input information and stores it in the registrant file. When there are a plurality of drivers to be managed, the above process is repeated.

  The driver user specified by the driver information can set the SD card of the logged-in user, import the SD card, and view the operation data. Other driver users can set the SD card, import the SD card, and view the operation data. Can not. The driver name is the screen display name of the user, and can be changed later. The account name is the account at login and cannot be changed. Further, the password is a password at the time of login, and can be changed later.

  If a new administrator user is to be added, this can be done by clicking the “new administrator registration” button in the registrant list screen shown in FIG. When the “new administrator registration” button is clicked, the arithmetic processing unit 11 displays a new administrator user registration screen shown in FIG. Then, the administrator user operates the input unit 14 to input an administrator name, an account name, and a password in each text input box on the new registration screen, and clicks a registration button. The arithmetic processing unit 11 creates administrator user information having a table structure in which they are associated based on the input information, and stores the administrator user information in the registrant file.

  Furthermore, when performing an update process such as correcting / deleting an already registered administrator user or driver information by executing the above-described process, the administrator user performs an update process on the registrant list screen shown in FIG. Click the "change" button B1 or the "delete" button B2 in the target management user or driver information column. The arithmetic processing unit 11 that has detected such a click executes an update process. Specifically, when the arithmetic processing unit 11 detects that the “change” button B1 is clicked, the arithmetic processing unit 11 displays the registered information in each text input box of the new registration screen illustrated in FIG. 9B or 6C. After that, when a click on the “Register” button is detected, the information in each text input box is updated. Further, when detecting the click of the “delete” button B2, the arithmetic processing unit 11 displays a confirmation message for confirming whether or not to delete, a “Yes” button and a “No” button, and a “Yes” button. When it is detected that is clicked, the corresponding driver / administrator user is deleted from the registrant file. When the arithmetic processing unit 11 detects that the “No” button has been clicked, the arithmetic processing unit 11 does not delete it. If at least one administrator user is required and the number of registered administrator users is “1” and the “delete” button is clicked for the administrator user, the arithmetic processing unit 11 cannot be deleted. A confirmation screen having a message to that effect and an “OK” button is displayed. When a click on the “OK” button is detected, the confirmation message is deleted. As described above, only the administrator user can add / modify / delete these management users and driver information.

* Vehicle information management When the vehicle information to be used is not registered, the administrator user executes a vehicle information registration process. Specifically, first, click “Management” in the menu at the top of the main screen. When the arithmetic processing unit 11 detects that the “management” is clicked, it displays a pull-down menu having three menu items of “vehicle list”, “terminal list”, and “registrant list”. When the arithmetic processing unit 11 detects that the “vehicle list” is clicked, the arithmetic processing unit 11 accesses the vehicle information file in the storage unit 12 and acquires information on the registered vehicle information. The vehicle list screen shown is displayed. As shown in the figure, when the vehicle information is not registered, the arithmetic processing unit 11 displays only item names (vehicle manufacturer name, vehicle type name, vehicle number, reference fuel consumption value), and data in each item is blank. .

  Then, when detecting that the “new vehicle registration” button on the vehicle list screen is clicked, the arithmetic processing unit 11 displays a new registration screen for vehicle information shown in FIG. 10B on the display unit 13. This new registration screen is actually displayed over the vehicle list screen. The administrator user operates the input unit 14 to input the vehicle manufacturer name, vehicle type name, vehicle number, and reference fuel consumption value in each text input box on the new registration screen, and clicks the registration button. Therefore, the arithmetic processing unit 11 creates vehicle information having a table structure in which the information is associated based on the input information, stores the vehicle information in the registrant file, and displays the vehicle information on the vehicle list screen. When there are a plurality of vehicles to be managed, the above process is repeated.

  When the arithmetic processing unit 11 detects that the “correction” button in the registered vehicle information column displayed on the vehicle list screen is clicked, the arithmetic processing unit 11 includes each text input box on the new registration screen shown in FIG. The registered information is displayed on the screen, and after that, when the “register” button is clicked, it is updated to the information in each text input box. Thereby, the registered vehicle information can be corrected. In addition, when the arithmetic processing unit 11 detects a click on the “delete” button in the registered vehicle information column displayed on the vehicle list screen, the arithmetic processing unit 11 confirms whether or not to delete the “Yes” button / “No” button. Is displayed, and when it is detected that the “Yes” button has been clicked, the corresponding vehicle information is deleted from the vehicle information file. Accordingly, the corresponding vehicle information is deleted from the vehicle list screen.

* Terminal information management An administrator user performs terminal information registration processing, when terminal information about a terminal to use (the above-mentioned vehicle run data collection device) is unregistered. Specifically, first, click “Management” in the menu at the top of the main screen. When the arithmetic processing unit 11 detects that the “management” is clicked, it displays a pull-down menu having three menu items of “vehicle list”, “terminal list”, and “registrant list”. When the arithmetic processing unit 11 detects that the “terminal list” is clicked, the arithmetic processing unit 11 accesses the terminal information file in the storage unit 12 and acquires information on the registered terminal information, as shown in FIG. The terminal list screen shown is displayed.

  When the arithmetic processing unit 11 detects that the “new DMR terminal registration” button on the terminal list screen is clicked, the arithmetic processing unit 11 displays a new terminal registration screen shown in FIG. 11B on the display unit 13. This new registration screen is actually displayed over the registration terminal list screen. Here, “DMR” is an abbreviation of “Drive Monitoring Recorder” and refers to a vehicle travel data collection device in relation to this embodiment. The administrator user operates the input unit 14 to input the terminal ID, the attached vehicle, the product model setting, the GPS setting, and the acceleration sensor range into each input box on the new registration screen, and clicks the “Register” button. Therefore, the arithmetic processing unit 11 creates driver information having a table structure in which the information is associated based on the input information, and stores the driver information in the terminal information file. When there are a plurality of terminals to be managed, the above process is repeatedly executed.

  The terminal ID is set to a value that does not overlap with other terminals among 1 to 9999. The arithmetic processing unit 11 displays “1” by default, and when it detects that the upper and lower key buttons at the right end of the input box are clicked, the arithmetic processing unit 11 increases or decreases the numerical value by one. You may enter a value directly in the input box. In the arithmetic processing unit 11, the vehicle information that can be specified is listed in a pull-down menu method, so the user selects the corresponding vehicle. That is, the arithmetic processing unit 11 accesses the vehicle information file, acquires the registered vehicle information, makes a pair of the vehicle type name and the vehicle number, and displays one vehicle in the input box of the attached vehicle. And if the arithmetic processing part 11 detects that the input box was clicked, it will display the acquired registered vehicle information (vehicle model name + vehicle number) by a pull-down menu system. The administrator user clicks and selects one of the vehicle information listed using the input unit (pointing device) 13. The arithmetic processing unit 11 displays the clicked vehicle information in the input box of the attached vehicle. If the vehicle on which the terminal (vehicle travel data collection device) is installed is not registered, the “new vehicle registration” button is clicked to register the vehicle information first.

  The GPS setting is for setting whether or not the terminal (vehicle traveling data collection device) is a device with a GPS module. In the embodiment shown in FIG. 1 described above, since the GPS module 4 is connected, the administrator user designates the radio button by clicking the “GPS” radio button. The acceleration range setting designates the range of the acceleration sensor mounted on the terminal, and is selected from ± 2G, ± 4G, ± 8G, and ± 16G.

* Terminal SD card setting After the registration of the driver information, vehicle information, and terminal information described above is completed, the administrator user next sets an SD memory card to be used during daily driving and operation. The setting process to the SD memory card is to create an initial setting file used at the time of initial setting for the vehicle travel data collection device described above, a normal setting file used at the time of normal setting, and the like. The actual setting process is performed as follows.

  First, the administrator user attaches the SD memory card to be set to the card reader 15 for the SD memory card. By the function of the personal computer, the arithmetic processing unit 11 recognizes the SD memory card. Further, the administrator user clicks “terminal SD card setting” in the menu at the top of the main screen. When detecting that the “terminal SD card setting” is clicked, the arithmetic processing unit 11 displays a DMR terminal SD card setting screen shown in FIG. This DMR terminal SD card setting screen is actually displayed over the main screen. At this time, the arithmetic processing unit 11 accesses the registered terminal file, acquires the registered terminal ID, acquires the terminal information of the terminal ID that matches the default condition, and stores the information in each input box shown in FIG. Each information about the minimum terminal ID is displayed as default information. Further, the impact sensitivity is displayed as level 3. Furthermore, the date and time information at the time of initial setting displays the date and time information of the internal clock of the personal computer when “Terminal SD card setting” in the menu is clicked as a default value. The default condition may be, for example, that the terminal ID is minimum / maximum, or the last condition registered. In particular, the last registered one is preferable because the setting process for the SD memory card is likely to be performed immediately after that, so that it is often possible to select and execute as it is displayed as default information.

  Since the arithmetic processing unit 11 acquires the registered terminal ID, when detecting that the input box of the terminal ID on the DMR terminal SD card setting screen is clicked, all the acquired terminal IDs are displayed in a pull-down menu method. indicate. When any terminal ID is selected from the list, the corresponding terminal information is read and displayed in the corresponding input box.

  When the arithmetic processing unit 11 detects that the “setting” button on the DMR terminal SD card setting screen is clicked, the arithmetic processing unit 11 registers each information displayed in the input box on the DMR terminal SD card setting screen at that time in the SD memory card. To do. At this time, the arithmetic processing unit 11 creates a file by dividing each information into an initial setting file and a normal setting file, and stores them in the SD memory card.

  Furthermore, the data displayed on the DMR terminal SD card setting screen can be changed except for the terminal ID. When the “setting” button is clicked in the changed state, both files are stored in the SD memory card as described above. The stored contents in the storage unit 12 are also updated.

* Terminal SD card reading The SD memory card in which the terminal SD card setting described above is executed and the terminal information is stored is removed from the card reader 15 and delivered to the driver. Then, the driver uses the SD memory card to attach to a vehicle travel data collection device mounted on the vehicle that he / she drives, performs a predetermined setting process as necessary, and then performs normal driving. . Then, after the operation is completed, the SD memory card is removed from the vehicle travel data collection device, set in the card reader 15, the information recorded in the memory card is read, and the data is taken into the driving state evaluation system. Such reading processing is actually performed as follows.

  The administrator user attaches the SD memory card to the card reader 15 for the SD memory card. By the function of the personal computer, the arithmetic processing unit 11 recognizes the SD memory card. The administrator user clicks “data import” in the menu at the top of the main screen. When the arithmetic processing unit 11 detects that the “data import” is clicked, it displays an SD card data import screen shown in FIG. This SD card data capture screen is actually displayed over the main screen.

  The administrator user designates an SD memory card drive, a product model (here, DMR), a driver, and a vehicle from an input box for designating a read drive, and clicks an “execute” button. When it is detected that the execution button has been clicked, the arithmetic processing unit 11 reads the travel data recording file in the SD memory card and stores it in the database in the storage unit 12. In this database, the period from when the engine is started until it is turned off is defined as one unit, and each unit is filed and registered.

  FIG. 13 shows an example of the data structure of a database that stores vehicle state information in the storage unit 12. As shown in the figure, time information (actually date is included), position information (latitude / longitude), acceleration sensor output values (X axis, Y axis, Z axis), and vehicle information are recorded in time series. It has a structure. Other log information collected by the vehicle travel data collection device 1 every second is also recorded. A file having the above-described data structure is created and registered in the database with one run from the start of the engine to the stop as one unit.

  When the processing of the terminal SD card is completed, the arithmetic processing unit 11 displays a completion confirmation screen with a message “Completed” and an “OK” button, and detects that the “OK” button has been clicked. Delete the completion confirmation screen.

* Analysis Processing The arithmetic processing unit 11 reads out information related to vehicle travel registered in the database as described above, performs various types of analysis, and outputs the results. Specifically, the following various processes are performed. This analysis process is performed by accessing the database each time when outputting an analysis result to be described later, and acquiring information related to the traveling of the target vehicle.

** Analysis of dangerous driving (safe driving index) In this embodiment, the unit of output of each axis of the acceleration sensor is gravitational acceleration (1G = 9.8 m / sec)), and the presence of dangerous driving is determined using the gravitational acceleration as an index. to decide. Specifically, as shown in FIG. 14, the level is divided in increments of 0.1G. Each section includes a lower limit value and does not include an upper limit value. When a human (driver) feels acceleration while driving, the speed change in the felt direction is large, and the greater the degree, the higher the degree of danger. And in the case of acceleration sensor detection error range (0 to 0.1G) or minute acceleration (0.1 to 0.2G) that can be detected only by the sensor but not felt by humans, there is no effect on driving. It is safe. On the other hand, experience shows that when the acceleration is 0.2 G or more and less than 0.3 G, a weak G is sometimes felt, and when the acceleration is 0.3 G or more and less than 0.4 G, the weak G is felt. If you feel weak but G, you should drive carefully. Therefore, in the range from 0.2G to less than 0.3G where you sometimes feel weak G, it can be said that you need a little attention. In the range where you always feel weak G from 0.3G to less than 0.4G, you need to be careful. It can be said. And if it becomes 0.4 G or more, it will be in the dangerous state which feels strong G during a driving | operation.

  Therefore, in this embodiment, 0.4G is set as a threshold value, and it is determined that there is a dangerous driving when the acceleration is 0.4G or more. The vehicle travel data collection device 1 described above is configured to sound an alarm buzzer sound when the output value of the acceleration sensor exceeds a level set by the user. The reference level for sounding is variable, and the alarm buzzer sound can be sounded even at an acceleration lower than 0.4 G that is determined as dangerous driving. On the other hand, in the present embodiment, the dangerous driving is determined by using the X-axis, Y-axis, and Z-axis accelerations recorded by the vehicle travel data collection device 1 every second. The threshold for determining that there has been a dangerous driving is fixed at 0.4 G, and further, analysis and evaluation is performed for each traveling data unit as shown below.

  Therefore, the arithmetic control unit 11 searches the X-axis and Y-axis accelerations stored in the analysis target file (one run unit) in time series, and extracts a threshold value of 0.4 G or more. And count. At this time, the number of occurrences of single dangerous driving that exceeds the threshold once in a single shot (less than the threshold before and after) and the number of occurrences of continuous dangerous driving that exceeds the threshold continuously twice or more are counted separately. To do. Furthermore, for continuous dangerous driving, the number of consecutive occurrences is not counted as one time but the number of consecutive occurrences is counted as it is. That is, when the threshold value is exceeded for three consecutive times (for three seconds continuously), the number of consecutive dangerous driving occurrences is three. In other words, whether it occurs continuously or in a single shot, each occurrence is counted as one time, but it belongs to either single-shot dangerous driving or continuous dangerous driving Are counted separately.

  Furthermore, in the present embodiment, three types of sudden acceleration, sudden deceleration, and sudden handle are prepared as the types of dangerous driving to be determined. For each type of dangerous driving, there is a distinction between single and continuous as described above. As a result, the number of continuous rapid acceleration, continuous rapid deceleration, continuous sudden handle, single sudden acceleration, single sudden deceleration, single sudden handle The number of occurrences of each event is counted individually in 6 types.

  As described in the configuration of the vehicle travel data collection device 1, the acceleration sensor mounted on the vehicle travel data collection device 1 has an X-axis when the speed is accelerated while traveling forward in the traveling direction. The sensor output value is a positive value, and the X-axis sensor output value is set to a negative value when the speed is decelerating while traveling forward in the traveling direction.

  Therefore, the arithmetic processing unit 11 determines that the acceleration is in a rapid acceleration state when the absolute value of the X-axis sensor output value is 0.4 G or more, which is a set threshold value, and the output value is positive. The count value of either the number of times or the number of continuous rapid acceleration is incremented by one. In addition, the arithmetic processing unit 11 determines a sudden deceleration state when the absolute value of the X-axis sensor output value is 0.4 G or more which is a set threshold value and the output value is negative, and the single sudden deceleration The count value of either the number of times or the number of continuous rapid deceleration is incremented by one. Furthermore, the arithmetic processing unit 11 determines that the steering wheel is in a sudden handle state when the absolute value of the Y-axis sensor output value is 0.4 G or more, which is a set threshold value, and determines either the number of single sudden steering or the number of continuous sudden steering. The count value is incremented by one.

  And the arithmetic processing part 11 calculates | requires the number of dangerous driving | operations totaling the frequency | count of occurrence of six types of events as mentioned above. The number of dangerous driving times is obtained by simply adding the number of occurrences of each event without weighting. That is, when the single sudden acceleration occurs twice at different locations every second and when the continuous sudden acceleration occurs continuously for 2 seconds, both the single sudden acceleration number and the continuous sudden acceleration number are two times. Therefore, the total number of times 4 is the number of dangerous driving. Also, for example, if there is a driving behavior such as sudden acceleration while turning suddenly for 1 second, the number of times of dangerous driving is added to the number of single sudden steering and the number of single sudden acceleration, respectively. Will be twice, and will be evaluated as a more dangerous driving.

  Specifically, the count processing of the number of occurrences of single and continuous dangerous driving events is realized by the arithmetic processing unit 11 executing the flowchart shown in FIG. A counter A that counts the number of single occurrences and a counter B that counts the number of consecutive occurrences are provided. The X-axis output value of the i-th acceleration sensor recorded in time series is Gx (i), the threshold value ThresX (0.4G) at which the output value of the acceleration sensor is determined to be dangerous, and the number of acquired data are iMax.

  The arithmetic processing unit 11 sets i = 1 and resets the counters A and B to 0 (S11). Next, the arithmetic processing unit determines whether or not the X-axis output value Gx (i) of the i-th acceleration sensor is equal to or greater than a threshold value ThresX (S12). If Gx (i) is less than ThresX, the branch determination in process step S12 is No, jumps to process step S22, and i is incremented. The arithmetic processing unit 11 determines whether i exceeds the number of acquired data (iMax) (S23). If the number does not exceed the number of acquired data, the processing unit 11 returns to the processing step S12 and increments the output value of the i-th acceleration sensor. It is determined whether or not the threshold value is greater than or equal to the threshold value.

  As shown in FIG. 13, in general, idling is performed at the beginning of the engine, and it does not start very much within one second. Therefore, Gx (i) becomes ThresX several times from i = 1. Since this is the case, the above routine is often executed repeatedly.

  On the other hand, when Gx (i) is equal to or greater than ThresX in S12, the arithmetic processing unit 11 increments the counter B for the number of consecutive occurrences (S13), and the output value (Gx (i + 1)) after 1 second of the acceleration sensor is obtained. It is determined whether or not the threshold value is exceeded (S14). When Gx (i + 1) is less than the threshold value (No in S14), the counter A for single occurrence is incremented and the counter B is decremented (S21).

  If Gx (i) to be processed is the final data (i = iMax), there is no Gx (i + 1) data. In such a case, the arithmetic processing unit 11 makes a branch determination in S14 with Gx (i + 1) = 0. In other words, when stopping the engine during normal driving, the engine is stopped once and then the engine is turned off. Therefore, the output value of the acceleration sensor is less than the threshold value for at least one second immediately before stopping the engine. It can be said that the last output value Gx (iMax) of the travel data hardly exceeds the threshold value. Therefore, in the analysis process for normal driving data, there is actual data for Gx (i + 1) in S14. For example, the data file is cut off halfway for some reason, and it happens that the final iMax Gx (i + 1) is 0 even if the output value is greater than the threshold value, or when the final iMax output value is greater than or equal to the threshold value, for example, when the engine is shut down and the engine is turned off by sudden braking. , S14 is No.

  When the branch determination of S12 is performed, it is the case of No in S12, No in S14, and No in S17 in the previous process. First, if a certain i-th output value Gx (i) is less than the threshold value, No in S12. The output value at this time is T1 for convenience. Since i is incremented by 1 in S22, Gx (i-1) at the time of branching determination in S12 is T1, so Gx (i-1) is less than the threshold. Thus, when the branch determination in S12 is No, Gx (i−1) for the next output value Gx (i) to be processed is the output value that was previously determined No in S12. (I-1) is less than the threshold value. Then, the loop of S12 → S22 → S23 → S12... Is repeatedly executed until Gx (i) becomes equal to or greater than the threshold (except when i exceeds iMax in S23).

  In the case of No in S14, the output value (Gx (i + 1)) immediately after the current output value Gx (i) to be processed is less than the threshold value, and the output value at that time is T2. Since S14 is No and i is incremented by 1 in S22, the output value to be processed next is T2, and therefore S12 is No.

  When S17 is No, the output value determined to be No in S17 is Gx (i-1) when branch determination is performed in the next S12, as in S12 above. i-1) is less than the threshold value. Thereafter, the loop of S12 → S22 → S23 → S12... Is repeatedly executed until Gx (i) becomes equal to or greater than the threshold (except when i exceeds iMax in S23). If Gx (i) is equal to or greater than the threshold value, the process proceeds sequentially from S12 → S13 → S14 as described above.

  The branch determination is Yes in S12 because, in the previous process, No in S12 or No in S17, Gx (i-1) is less than the threshold and Gx (i) is greater than or equal to the threshold. In other words, the output value Gx (i) that becomes Yes in S12 is the head when it is generated once or continuously.

  Therefore, when the branch determination in S12 is Yes, Gx (i-1) is less than the threshold value. Therefore, if Gx (i + 1) is also less than the threshold value, the output value equal to or greater than the threshold value determined as Yes in S12 is a single shot. Therefore, the value obtained by incrementing the counter B in S13 is returned to the original value, and the single occurrence counter A is incremented.

  Then, the arithmetic processing unit 11 increments i (S22), determines whether i exceeds the number of acquired data (iMax) (S23), and returns to processing step S12 if it does not exceed the number of acquired data. It is determined whether or not the incremented output value of the i-th acceleration sensor is greater than or equal to a threshold value.

  On the other hand, if the branch determination in processing step S14 is Yes, the current output value Gx (i) to be processed and the next output value Gx (i + 1) are both equal to or greater than the threshold value. In this case, the output value Gx (i) is the head of continuous generation. Gx (i + 1) in S14 is the second continuously generated. Thus, since Gx (i) is the head of continuous occurrence, the arithmetic processing unit 11 increments i (S15), and then determines whether i exceeds the number of acquired data (iMax) (S16). If the number of acquired data is not exceeded, the process jumps to step S17 to determine whether or not the incremented output value of the i-th acceleration sensor is equal to or greater than a threshold value.

  When Gx (i) is equal to or greater than ThresX, the arithmetic processing unit 11 increments the counter B for the number of consecutive occurrences (S18), and after i is incremented (S19), i exceeds the number of acquired data (iMax). (S20), if the number of acquired data has not been exceeded, the process jumps to step S17 to determine whether or not the output value of the incremented i-th acceleration sensor is equal to or greater than a threshold value. As described above, the output of the sensor that made the branch determination in S17 via S15 is the second output value that is continuously generated. After that, if the output value is continuously greater than or equal to the threshold value, S17 → S18 → The loop of S19 → S20 → S17... Is repeatedly executed.

  If the answer is No in process step S17, the process jumps to S22 to execute the process described above. If the branch determination of S16, S20, S23 is executed and i exceeds the number of acquired data, all the data in the file has been searched, and the process is terminated.

  The data shown in FIG. 13 will be described as an example. In FIG. 13, the output value on the X-axis in the portion not shown is less than the threshold value (0.4G). When i = 1 to 4, and further, n and n + 1, the output value of the X-axis is less than 0.4 G, so that the process returns to S11 via S12 → S21 → S22 → S23. When i = n + 2, the X-axis output value of the acceleration sensor is 0.428 G, which is equal to or greater than the threshold value, so S13 is executed to increment the value of counter B. As a result, the value of the counter B becomes 1. Since the output value Gx (n + 3) of the X-axis of the acceleration sensor (i + 1), that is, (n + 3) exceeds the threshold value, the process proceeds from S15 → S16 → S17, and Gx (n + 3) is equal to or greater than the threshold value. Incrementing, the counter B value becomes 2. Since Gx (n + 4) is less than the threshold value, the result is No in S17 and jumps to S22. Therefore, the value of the counter B is 2 in the process so far, and the continuous number is 2.

  Further, since Gx (m + 1) which is the sensor output value of i = m + 1 is less than the threshold value, the process goes from S22 to S12 through S23. Since Gx (m + 2) is equal to or greater than the threshold value, the value of the counter B is once incremented. However, since Gx (m + 3) becomes less than the threshold value, the counter A is incremented and the counter B is decremented in S21. Therefore, in this state, the value of the counter A is 1 and the value of the counter B is 2. The same applies to the case of i = m + 5, and the counter A is incremented. Finally, the values of the counters A and B both become 2.

The above is the count processing of the number of single / continuous rapid acceleration event occurrence based on the sensor output value of the X-axis, but the count processing of the single / continuous rapid deceleration event occurrence and single / continuous sudden handle event generation. The count process can be performed in the same manner. That is, single-shot / continuous rapid deceleration uses X-axis sensor output, but the sign of the output value is negative. And since dangerous driving is an absolute value of 0.4G or more, the number of single / continuous sudden acceleration events is counted when Gx (i) is -0.4G or less. Up. Therefore, ThresX = −0.4G, and branch determination of S12 and S17 is Gx (i) = <ThresX
The branch determination in S17 is Gx (i + 1) = <ThresX
And For the single / continuous sudden handle based on the Y-axis sensor output value, the flowchart shown in FIG. 15 is executed using the absolute value of the sensor output value.

* Analysis of other driving behavior Further, in the present embodiment, the calculation control unit 11 searches the output value of the acceleration sensor, and for each acceleration of 0.1G or more, sudden acceleration is performed every 10 stages in increments of 0.1G.・ The number of occurrences of sudden deceleration and sudden steering is also counted. That is, when the output value of the sensor is less than 0.1 G, since it includes an error, it is not effective information for analyzing the driving behavior, so that the data is not counted. Further, the sudden acceleration, sudden deceleration, and sudden handle here are counted together without dividing the single shot and the continuous as in the above-mentioned dangerous driving event. That is, for example, a buffer memory is prepared in which 10-stage divisions as shown in FIG. 16 are associated with three events (acceleration / deceleration / handle). The initial value of each buffer memory is 0. The arithmetic control unit 11 sequentially extracts the X-axis sensor output values in time series, and increments the value in the corresponding column by one. When the absolute value is 0.1 or more from the X-axis sensor output value, the value in either the acceleration event or deceleration event column is incremented. When the absolute value is 0.1 or more from the Y-axis sensor output value The value in either column of the handle event is incremented.

* Output Processing FIG. 17 shows an example of the output of the analysis result described above. This figure has shown an example of the display screen of "operation data all day total" which is one of the output screens. The display screen of “total operation data all day” includes a display condition input area R1, a map display area R2, an operation file list display area R3, an aggregate display area R4, and an analysis result display area R5.

  In the display condition input area R1, a driver and operation date input box for specifying information related to the traveling of the vehicle to be analyzed are arranged at the top, and an event extraction level designation box, a route map display mode designation button, A map window display location designation button is provided.

  The driver input box is an area for designating a driver to be analyzed. When the arithmetic processing unit 11 detects that the box is clicked by the pointing device which is the input unit 14, the arithmetic processing unit 11 displays a list of drivers registered in the database by a pull-down menu method, and any of the displayed drivers is displayed. When it is detected that is specified, the driver name is displayed in the driver input box. In the figure, “administrator” is designated.

  The operation day input box is an area for designating a date on which the analysis is run. When the arithmetic processing unit 11 detects that the box is clicked by the pointing device which is the input unit 14, the arithmetic processing unit 11 displays a calendar type date input screen, and any date is displayed from the displayed date input screen. When the designation is detected, the designated date is displayed in the operation date input box. The operation date input box displays today's date as a default value. Therefore, a function is also provided in which the displayed values for each date are changed by direct text input. In the figure, “November 14, 2010” is designated.

  There is a “display operation file” button at the lower right of the operation date input box. When the arithmetic processing unit 11 detects that the button has been clicked, the arithmetic processing unit 11 searches for a file of information related to traveling of the vehicle that satisfies the specified driver and the operation date. If the corresponding file exists, the arithmetic processing unit 11 reads the information related to the traveling of the vehicle stored in the file and performs the above analysis. In addition, when there are a plurality of files on the same day, the arithmetic processing unit 11 analyzes all the plurality of files.

  The arithmetic processing unit 11 outputs the analysis result to each of the operation file list display area R3, the total display area R4, and the analysis result display area R5, and the result to each display area.

  The operation file list display area R3 is an area for displaying the corresponding operation data designated by the display conditions in a list. If multiple files exist on the specified date, display all of the multiple files. The figure shows an example in which there are five files that match the conditions.

  The operation file list display area R3 includes a start time display field, a stop time display field, a Map display check field, and a display color selection button. In the start time display field and the stop time display field, the start time and stop time of the vehicle associated with one run are displayed. This is performed by the arithmetic processing unit 11 reading the first and last date / time data of the information related to the traveling of the vehicle recorded in time series in the analysis target file and displaying it. The Map display check column switches display / non-display of the travel route on the map displayed in the map window display region R2 by turning ON / OFF. The arithmetic processing unit 11 displays the travel route of the checked file in the map window display area R2. You can select a color by clicking the button in the display color row. When the arithmetic processing unit 11 detects that the button of the display color string is clicked, the arithmetic processing unit 11 displays the travel route in the selected color.

  In addition, among the file list lists displayed in the operation file list display area R3, what is to be counted when the analysis results are displayed in the analysis result display area R5 is indicated by shading / coloring or the like. Yes. In this embodiment, since it is managed in units of days, the default is totaling all day, that is, when there are multiple files on the same date, all are analyzed, and each analysis result is added together, and the total result is Output. That is, when there are a plurality of travel data files on the same day, the arithmetic processing unit 11 analyzes each travel data, and stores the result for each travel data file in the buffer memory or the like managed by the arithmetic processing unit 11. Record the number of events. And the arithmetic processing part 11 adds together about the same item about these some driving | running | working data, respectively, and displays it on the predetermined location of analysis result display area R5. Since all the files are selected and counted as described above, the background portions of all items No. 1 to No. 5 are painted in a predetermined color (for example, blue) in FIG.

  The analysis result display area R5 is an area for displaying various analysis results. The arithmetic processing unit 11 displays a plurality of tabs so as to protrude from the upper end of the analysis result region R5, detects the tab clicked by the pointing device, and displays the analysis result region associated with the tab. Here, a state where the “safe driving index” tab related to the present invention is selected is shown. This safe driving index analysis result display area R5 is provided with a dangerous driving frequency display area R5a representing a safe driving index on the left side, an event occurrence frequency display area R5b for each acceleration level, and a dangerous driving breakdown display area R5c. On the right side, an event occurrence graph display region R5d for each acceleration level is provided.

  Each region R5a, R5b, R5c on the left side of the analysis result display region R5 is a region for displaying each analysis result as a numerical value. When there are a plurality of files to be counted, the arithmetic processing unit 11 displays the total value of the analysis results of each file. That is, for example, in FIG. 17, the number of occurrences of 0.3G acceleration event in the event occurrence number display area R5b is five, which is 0.3G or more of each of the five files shown in the operation file list. This means that the number of occurrences of acceleration event less than 4G is obtained and the total value is 5 times. The same applies to other items. Further, in the event occurrence count display area R5b, when the occurrence count of the section of 0.3G or more and less than 0.4G requiring attention is 1 or more, the background portion of the column is displayed in yellow. As a result, when the number of event occurrences in the section is 0, the background remains white, and thus the user can immediately understand whether or not there is a driving with caution depending on the presence or absence of the yellow column. Similarly, when the number of occurrences of 0.4G or more that becomes dangerous driving is 1 or more, the background portion of the column is displayed in red. As a result, when the number of event occurrences in this section is 0, the white background remains, and the user can immediately understand whether or not there was a dangerous driving depending on the presence or absence of the red column.

  In this example, since there has never been an event that results in a dangerous driving of 0.4G or more, all of the six dangerous driving type events displayed in the dangerous driving breakdown display area R5c are zero. The number of dangerous driving times as a driving index is also zero. Therefore, the user who sees this can confirm that the analyzed driver is driving safely.

  The event occurrence graph display area R5d on the right side of the analysis result display area R5 displays the analysis results displayed in a table format (numerical value) in the event occurrence count display area R5b using a graph (here, a bar graph). Moreover, the graph elements corresponding to the three types of events of acceleration, deceleration, and steering wheel are displayed in different colors. For example, the acceleration event is blue, the deceleration event is green, and the steering event is red. By displaying the graph while changing the color in this way, the user who sees it can intuitively understand what kind of event occurs at the acceleration level (classification).

  As described above, in this embodiment, since the management is performed in units of days, the default is totaling all day. Therefore, when a plurality of files exist on the specified date as described above, all the files are analyzed and the results are displayed. The total display area R4 switches display contents by three tabs of “all day total”, “operation file selection”, and “instantaneous data display”. FIG. 17 displays the default “all day total”. In this “all day total”, the result totaled for each item of the total daily operation data is displayed.

  Further, in the present embodiment, when a plurality of files exist on the same day, the analysis result for each file can also be displayed. Specifically, when the arithmetic processing unit 11 recognizes that the “operation file selection” tab in the total display area R4 has been clicked, “operation file selection” shown in FIG. 18 is displayed. This “operation file selection” has an “operation file selection designation box” above. This “operation file selection specification box” is in a state where the file No. 1 in the operation file list is specified together with the screen switching. Accordingly, the No1 file is analyzed, and the result is displayed in each area of the analysis result display area R5. In addition, when one file is designated in this way, the operation file list display area R3 is in a state where only one (here, No. 1) column is painted (for example, blue).

  Moreover, when displaying about another file, it is performed by designating another file in an operation file selection designation box. Specifically, when the arithmetic processing unit 11 detects that the operation file selection designation box has been clicked by the pointing device that is the input unit 14, as shown in FIG. , “Range selection” that designates all of No1 to No5) is displayed by a pull-down menu method. When the arithmetic processing unit 11 detects that one of the menu items is selected (in FIG. 19, No 4 is highlighted and selected), the arithmetic processing unit 11 analyzes the detected file, and the result Is displayed in each area of the analysis result display area R5.

  Furthermore, on this “operation file selection” screen, an input box for the total period is prepared below the operation file selection instruction box. In the input box for the total period, the total start time and total end time are registered. First, the arithmetic processing unit 11 extracts the start time and end time of the designated file and displays them. Then, when the user inputs appropriate values for the aggregation start time and the aggregation end time, only the data registered in the specified file is extracted and analyzed within the range of the aggregation start time to the aggregation end time. Process. Thus, the total range can be changed by changing the time of the total period. This makes it easier to find out the tendency of the dangerous driving at what time (around noon, around the evening) and at which point the driving is dangerous, such as at the beginning of driving, near the middle point and near the end.

  The event extraction level designation box in the display condition input area R1 designates the event extraction level to be extracted from the value of the acceleration sensor. This designation can be individually set for each event type, and the arithmetic processing unit 11 displays the result on the right side as a result. This extraction level is specified in increments of 0.1G. Actually, when the arithmetic processing unit 11 detects that the extraction level designation box is clicked by the pointing device which is the input unit 14, the arithmetic processing unit 11 pulls down 10 menu items divided by 0.1G in a pull-down menu method. indicate. When the arithmetic processing unit 11 detects that one of the menu items is selected, the arithmetic processing unit 11 temporarily analyzes the number of event occurrences of the detected extraction level, and the analysis result (the number of times of each event for each travel data file). Is obtained from the buffer memory that is recorded automatically, and the value is displayed as a numerical value on the right side of the event extraction level designation box.

  The route map display mode designation button in the display condition input area R1 has three modes of “normal display”, “marker display”, and “event display”. By clicking a radio button arranged on the left of each title, specify. These three modes are used to determine the display mode when displaying the travel route superimposed on the map displayed in the map display region R2. That is, when there is a file to be counted, the arithmetic processing unit 11 displays a surrounding map in the map display region R2 from the position information stored in the file. This displayed map is obtained via the Internet. That is, the arithmetic processing unit 11 accesses a site that provides the map using the Internet, acquires map data including at least all position information registered in the file, and displays the map data in the map display region R2. .

  In normal display, route display is performed without marker display. That is, the arithmetic processing unit 11 extracts the history of position information about the file (background color is displayed in blue) that is the object of aggregation from the files displayed in the operation file list display area R3 and travels. A route is obtained and displayed in a superimposed manner at a corresponding position on the map displayed in the map display region R2. The travel route is a line connecting consecutive positions before and after, and the color is the display color specified in the operation file list display area R3.

  In the marker display mode, a marker is displayed at a corresponding position on a travel route corresponding to a position where data recorded in time series stored in information related to vehicle travel is recorded, and a pointer is placed on the displayed marker. In this mode, detailed data such as time, latitude, longitude, and speed at the corresponding point is displayed. As illustrated in FIG. 20, when the “mark display” radio button is checked, the arithmetic processing unit 11 obtains position information of data recorded in time series stored in the information related to vehicle travel, For the marker corresponding to the position information, a marker M made of a blue circle is displayed at a corresponding position on the travel route. As illustrated in FIG. 21, when the arithmetic processing unit 11 detects that the pointer is positioned on the marker M, the arithmetic processing unit 11 generates a balloon F in which time, latitude, longitude, and speed are written for the position indicated by the marker M. indicate.

  In the event mode, a location where the acceleration selected at the event extraction level has occurred is indicated by a predetermined event occurrence location display mark. A mode that displays detailed data such as time, latitude, longitude, speed, traveling direction acceleration, lateral acceleration, and type of event that occurred when the pointer is placed on the event occurrence location display mark displayed in the same manner as the marker M It is.

  As illustrated in FIG. 22, when the “event display” radio button is checked, the arithmetic processing unit 11 acquires the extraction level for each event type specified in the event extraction level specification box, and An event satisfying the condition is extracted from the file, and a vent occurrence location display mark P is superimposed on the corresponding location on the travel route of the map displayed from the position information where the extracted event occurred. Further, the event occurrence location display mark P changes its color depending on the event occurrence content. That is, for example, the handle event occurrence location display mark (lateral acceleration) is a purple circle, the acceleration or deceleration occurrence location display mark (vertical acceleration) is a yellow circle, and the handle and acceleration / deceleration occurrence location display mark (vertical and horizontal direction). Acceleration) is a red circle. As a result, the type of event can be confirmed simply by looking at the color of the mark.

  Further, as shown in FIG. 23, when the arithmetic processing unit 11 detects that the pointer is positioned on the event occurrence location display mark P, the arithmetic processing unit 11 at the corresponding location with respect to the position indicated by the event occurrence location display mark P. A balloon F in which the time, latitude, longitude, speed, traveling direction acceleration, lateral direction acceleration, and type of the generated event are written is displayed.

  Further, the map window display location designation button in the display condition input area R1 designates the display position of the route map. As shown in the figure, the fixed screen display in which the display position is fixed and the route map pops out from the fixed position. Switches between two types of floating display screens to be displayed on a separate screen. Since the “floating display” button is displayed during the fixed screen display, when the arithmetic processing unit 11 detects that the button is clicked, the route map is removed from the fixed screen display area as shown in FIG. Display in a separate area. Since it is displayed in another area, the size of the area can be changed independently of the main screen (FIG. 24 shows a state after the area is enlarged). When the floating display is performed as described above, the display area of the fixed screen is blank. In addition, the arithmetic processing unit 11 displays a “fixed display” button in the display condition input area R1 in the case of floating display. Therefore, the display is switched to the fixed display by clicking the “fixed display” button or moving the floating display screen to the display area of the fixed screen.

  FIG. 25 shows the analysis result based on another file. In this example, both continuous sudden acceleration and single sudden acceleration events have occurred. In addition, an event of 0.3 to 0.4G that requires attention has also occurred. Therefore, in the event occurrence count display area R5b for each acceleration level in the analysis result display area R5, the column for the acceleration event of 0.4 G or more is “4”, and the background color is red. Further, in the dangerous driving breakdown display area R5c, it is displayed that the continuous sudden acceleration is twice and the single sudden acceleration is twice. In this case, since there are no acceleration events of 0.4 G or more other than the above two, the number of dangerous driving times is 4 times in total, and is displayed as 4 times in the dangerous driving frequency display area R5a.

  By outputting the analysis result in this manner, the driver can objectively check his / her driving state after driving. Therefore, the driver can improve the driving method so far so that the evaluation becomes higher, and the accident rate of the vehicle can be reduced.

  The user can easily confirm that the breakdown of the four occurrences is both continuous rapid acceleration and single rapid acceleration by looking at the dangerous driving breakdown display area R5c. It can be understood that there is a tendency to become too dangerous when stepped on, and that this acceleration tendency is both single-shot and continuous. Therefore, the driver can perform safe driving by suppressing depression of the accelerator and paying attention to the mood.

  In addition, when driving dangerously or driving with attention, the event display mode is used to check the travel route, and it can be easily determined whether or not a large G on the terrain such as a slope or a curve is likely to be applied. Thereby, the driving tendency can be known also in relation to the topography. In this way, by using the acceleration in units of gravitational acceleration as an index, it is easy for humans to determine and judge the danger level, and since the classification is set to 0.1 G units, each classification has a gravitational acceleration (1G ), And it is easy to understand the magnitude of the applied acceleration. As a result, it is easy to reflect on the existence of dangerous driving and try to improve the driving method to drive safely. It is preferable because it is easy to trigger.

  FIG. 26 and subsequent figures show examples of display screens for explaining the form output process. In this embodiment, it is possible to create a form that is summarized from various viewpoints such as various daily reports, monthly reports, period totals, and safe driving indicators. Specifically, when detecting that “form” in the menu at the top of the main screen is clicked, the arithmetic processing unit 11 switches to the form creation management screen. FIG. 26 shows a state in which a daily report is further selected and the type of daily report to be created is displayed by a pull-down menu method on the form creation management screen.

  In this state, when the arithmetic processing unit 11 detects that the daily safety driving report is clicked, as shown in FIG. 27, the arithmetic processing unit 11 is currently displaying a condition designation screen for designating a driving date and a driver for creating a daily report. Overlay on the screen. The operation date defaults to today's date according to the internal clock of the personal computer. In this way, when the user looks at the form immediately after reading the SD memory card, he simply clicks the “Create” button without entering the service date, and the daily report on the driving that was registered on the day is displayed. Can see.

  When viewing the daily report of another day, the user inputs the date corresponding to the operation date input box. That is, when the arithmetic processing unit 11 detects that the operation day input box has been clicked, the arithmetic processing unit 11 displays a calendar type input screen, and confirms that any date has been designated from the displayed date input screen. When detected, the designated date is displayed in the operation date input box. In addition, it has a function to change and specify each value displayed by directly entering text.

  When the arithmetic processing unit 11 detects that the driver input box on the condition designation screen has been clicked, it displays a list of drivers registered in the database in a pull-down menu method, and any of the displayed drivers is designated. When this is detected, the driver name is displayed in the driver input box. In the figure, “administrator” is designated.

  In the condition designation screen, a “create” button and a “cancel” button are prepared below the driver input box. When the arithmetic processing unit 11 detects that the “cancel” button is clicked, the calculation processing unit 11 ends the display of the condition designation screen. Further, when the arithmetic processing unit 11 detects that the “create” button is clicked, the arithmetic processing unit 11 searches for a file of information related to the traveling of the vehicle that satisfies the specified driver and the operation date, and stores the vehicle stored in the file. 28, the above-mentioned safe driving analysis is performed, and the daily safe driving report shown in FIG. 28 is displayed based on the analysis result.

  This daily report for safe driving displays the driver's name and date of driving in the upper area, as well as aggregate information related to common driving in each daily report, and on the left side of the center, it relates to three dangerous drivings: sudden acceleration, sudden deceleration, and sudden steering An area for displaying the analysis result in a graph is provided, and an area for displaying the number of occurrences and the total number of events of each dangerous driving in a tabular format is provided on the right side of the center. Further, an area for displaying a speed graph on a daily basis is provided in the lower area.

  Arithmetic processing unit 11 arranges each axis of rapid acceleration, rapid deceleration, and sudden handle at an interval of 120 degrees in the area to display the graph on the left side, plots the number of occurrences of each event in a corresponding axis shape, and sets adjacent axes A triangular graph is displayed by connecting the plotted points. By looking at the triangular shape of FIG. 28, the driving tendency can be intuitively understood. Also, the number of occurrences of events plotted on each axis is performed separately for single and continuous events. Then, the points where the number of single event occurrences is plotted are connected to the points where the continuous event occurrence numbers are plotted. Thereby, the arithmetic processing unit 11 displays two triangles, a single-use triangle and a continuous triangle. Therefore, the user can compare the shape of each of the two triangles to determine whether there are many single events or many consecutive events when driving dangerously. You can see at a glance which case to watch out for.

  FIG. 29A shows a state in which safe driving is further selected on the form creation management screen, and the type of the form relating to the safe driving to be created is displayed by a pull-down menu method. As shown in the figure, there are four menu items of “Safe driving daily report”, “Safe driving monthly report”, “Safe driving index”, and “Safe driving index (all drivers)”. As is clear from this menu item, when the above-mentioned daily safe driving report is output, it can also be performed by clicking on this "daily driving safety".

  When the arithmetic processing unit 11 detects that the “safe driving index” is clicked, the arithmetic processing unit 11 displays a condition designation screen for designating the total period and the driver shown in FIG. This condition designation screen is displayed so as to overlap the currently displayed screen. By default, the input box for the total period displays the date one month before and the last day displays the date of today. In this input box, an arbitrary date can be specified by a calendar method or a method of inputting text directly. The manner of input by the driver is the same as in the above examples.

  When the arithmetic processing unit 11 detects that the “Create” button has been clicked, the arithmetic processing unit 11 searches for a file of information on traveling of the vehicle that satisfies the designated total period and the conditions of the driver, and travels the vehicle stored in the file. 30 is read out and the above-mentioned safe driving analysis is performed, and the safe driving index shown in FIG. 30 is displayed based on the analysis result.

  This safe driving index displays “driver name and counting period”, “total number of periods”, and “detailed information” in order from the top. The “Total number of periods” column includes “Dangerous driving count”, “Consecutive sudden acceleration count”, “Continuous sudden deceleration count”, “Consecutive sudden steering count”, “Independent rapid acceleration count”, “Independent rapid deceleration count”, “ The total number of each value of “number of single sudden handles” is shown in a table format. “Detailed information” displays the number of occurrences of each event separately for each date. This makes it possible to objectively recognize the driving behavior during the specified period numerically and to check whether the driving behavior has been improved by looking at the detailed information.

[Others]
[Modification of demo function]
In the above-described embodiment (see FIG. 8), the trial mode execution unit 11b reads a large number of sample data files recorded in the sample data storage unit 12b-3 and activates the trial mode database 12b. 1 is registered, and at the end of the process, the data stored in the trial mode database 12b-1 and the trial mode management file storage unit 12b-2 are erased. As a result, the contents of the trial mode database 12b-1 that is generated and processed at each start-up are set to the same initial state.

  The present invention is not limited to this. For example, the trial mode database 12b-1 may be formed on a volatile recording medium. The data recorded on the volatile recording medium is automatically deleted upon completion of the operating state evaluation system (application). As a result, the contents of the trial mode database 12b-1 that is generated and processed at the time of activation each time are in the same initial state.

  FIG. 31 shows a main configuration of another modified example of the driving state evaluation system having the trial mode (demonstration function) and the normal mode, and FIG. 32 is a flowchart for explaining the function of the arithmetic processing unit in the modified example. Show. In FIG. 31, members corresponding to the embodiment described based on FIG. 8 described above are denoted by the same reference numerals and description thereof is omitted. Similarly, in each process step in FIG. 32, the same step number is attached | subjected about the process step which performs the process similar to the flowchart shown in FIG. 5 mentioned above, and detailed description is abbreviate | omitted.

  The control unit 11 includes a mode execution unit 11d that executes processing in each mode, and an activation processing unit 11c that performs activation processing. The mode execution unit 11d functions as the normal mode execution unit 11a and the trial mode execution unit 11b of the above-described embodiment.

  Further, the storage unit 12 includes a template database 12b-5 instead of the sample data storage unit 12b-3. The template database 12b is a database file having the same contents as the database registered in the trial mode database 12b-1 in the initial state of the trial mode in the above-described embodiment. When “normal mode activation” is selected (S2 is No), the activation processing unit 11c sets the database to be processed accessed by the mode processing unit 12d as the normal mode database 12a-1 (S8).

  When “trial mode activation” is selected (Yes in S2), the activation processing unit 11c copies the template database 12b-5 as trial mode data for processing, and the trial mode database 12b-1 The database to be processed accessed by the mode processing unit 12d is set in the trial mode database 12b-1 (S9). The contents of the trial mode database 12b-1 are overwritten by copying the contents of the template database 15b-5 when the trial mode is started. Regardless, the contents of the trial mode database 12b-1 at the time of starting the trial mode are always in an initial state (registered in the template database 15b-5).

  Therefore, the user can start the trial mode and perform various operations as much as they like. For example, even if all the data is deleted, the contents of the original template will be restored when the next trial mode is started. So you can do various work with peace of mind. In addition, since the process for initializing the trial mode database 12b-1 performed when the trial mode is started and the process for copying and overwriting the database are sufficient, the calculation control unit 11 (start process) can be performed at high speed. Less load is applied to the part 11c).

  The mode execution unit 11d performs the same processing in the normal mode and the trial mode, but as described above, the mode execution unit 11d is switched depending on the mode in which the database accessed by the activation processing unit 11c is activated. Therefore, the mode execution unit 11d accesses the normal mode database 12a-1 in the normal mode, analyzes and manages data collected during actual driving, and stores the data in the SD memory card 7. The vehicle state information collected along with the recorded travel is acquired and stored in the normal mode database 12a-1. On the other hand, in the trial mode, the mode execution unit 11d accesses the trial mode database 12b-1, and performs analysis or analysis based on the sample data of the template database that is overwritten and stored in the database 12b-1. Management is performed, and the vehicle state information collected with the travel recorded in the SD memory card 7 is acquired and stored in the trial mode database 12b-1.

  As described above, the mode execution unit 11d has different access destination databases, but the other processes are the same in the normal mode and the trial mode. Therefore, the user activates the trial mode and operates the normal mode. The operability can be confirmed correctly. Further, since the mode execution unit 11d does not access the template database 12b-5 during the execution of the trial mode, the contents of the template database 15b-5 are not destroyed (overwritten, communicated, deleted). Instead, the initial state of the trial mode database 12b-1 when the trial mode is always activated is the same.

  In the above modification, the mode execution unit 11d executes both the normal mode and the trial mode. However, the model execution unit 11d is provided with a template database 12b-5 and is configured to overwrite and copy the database at startup. A configuration may be adopted in which the mode execution unit 11a and the trial mode execution unit 11b are provided separately. In this case, since each database execution destination is set for each mode execution unit, the processing for changing the access destination according to the start-up mode as in the above-described modification becomes unnecessary. Further, by configuring the normal mode execution unit 11a and the trial mode execution unit 11b separately, for example, the trial mode execution unit 11b has the same function as the normal mode execution unit 11a, and further, the normal mode database 12a. -1 can be copied and overwritten on the trial mode database 12b-1, which is a database for processing, and various processes can be tried using a database based on actual data. Even in this case, the trial mode execution unit 11b processes and changes the data or the like is the processing database, and the normal mode database 12a-1 is not destroyed. When a large amount of actual data is accumulated in the normal mode database 12a-1, by using the trial mode using actual data collected and accumulated during actual driving, an operation suitable for the user's environment Can be confirmed with confidence.

[Modified example of analysis of safe driving]
The threshold value for determining dangerous driving is set to 0.4 G based on an empirical rule, but a different value may be used. Further, although three types of events corresponding to the dangerous driving are sudden acceleration, sudden deceleration, and sudden steering, any one or two may be added, and other factors may be added. Furthermore, although the threshold values for determining dangerous driving for all three events are the same, they may be different.

  There may not be a GPS unit. If there is no GPS unit, or if the location information could not be supplemented even with a GPS unit, the driving history is not obtained and the occurrence position of an event such as dangerous driving on the map can not be confirmed, but even in that case, It is possible to count and output the number of dangerous driving times and the number of occurrences of single / continuous events. Therefore, the state of safe driving can be confirmed from such numerical values.

  In the above-described embodiment, those with a threshold value (0.4G) or more for dangerous driving are counted separately separately and continuously, and finally added together to obtain the number of dangerous driving times, and less than the threshold value. For each thing, it is counted for each of the three types of events of acceleration / retroportion / handle that belong to the normal 0.1G level division. In the present invention, the counts of the level divisions in increments of 0.1 G may also be divided into a plurality of numbers focusing on temporal continuity such as single and continuous. In that case, the graph display of the histogram may represent each (for example, six types) separately, or may represent single and continuous as one bar, and may be distinguished by color / pattern classification. For example, for events requiring attention that may lead to dangerous driving, such as 0.3G or more, you can check whether there are many cases of single or continuous occurrence, and know what kind of driving you should consider from the characteristics of driving .

  The log information during running was recorded every second and analyzed based on it, but the data collection period is not limited to 1 second, and it is better to collect data in detail by making it shorter.

  In the embodiment, the vehicle travel data collection device 1 samples the output of 100 acceleration sensors per second, and performs a predetermined calculation process on the output to obtain the output value of the acceleration sensor every second. As recorded. The present invention is not limited to this, and the vehicle travel data collection device may record all sampled data as it is without performing arithmetic processing, and may perform evaluation by appropriately performing arithmetic processing on the driving state evaluation system side.

  Further, in the above-described embodiment, the number of occurrences of events in which the output value of the acceleration sensor exceeds the threshold is divided into two types, single and continuous, and finally summed to calculate the final number of dangerous driving times. I asked for it. As described above, the time continuity of the collected data is divided into two groups. However, the present invention is not limited to this, and the number of consecutive times is further divided into a plurality of groups and divided into three or more groups. May be. Also, even when dividing into two groups in terms of temporal continuity, whether or not the criteria for the classification is continuous two or more times, such as single and continuous, is not N times or more (N is 3 or more) As such, any group may include a continuation. In particular, if the data collection cycle is shortened, the significance of dividing the data into single and continuous may be diminished (no single event occurs). Therefore, if N is set to an appropriate value in consideration of the data collection cycle. good.

  In the above-described embodiment, an acceleration sensor is used to measure the state of the vehicle, and the number of occurrences of each event is obtained and analyzed and evaluated based on the output value (acceleration) of the acceleration sensor. There is no limitation, and a movement distance / speed change per unit time may be obtained and analyzed based on it. As the movement distance per unit time and the speed change are larger, it can be said that the driving is dangerous. Therefore, the obtained value is compared with a threshold value, and the number of event occurrences exceeding the threshold value is counted. At that time, similarly to the above-described other embodiments, the single occurrence and the continuous occurrence are separately counted and counted.

  In the above-described embodiment, the evaluation and evaluation function in the driving state evaluation system has been described for evaluating safe driving (dangerous driving). However, the analysis and evaluation in the present system is not limited to this and can be obtained from vehicle state information. It can be done for various things.

  As an example, there is one that analyzes whether eco-driving is being performed. That is, idling consumes fuel unnecessarily and consumes more fuel at the time of acceleration than at normal time. Therefore, idling and acceleration driving are driving operations that deteriorate fuel consumption, and those two driving operations are deteriorated. The driving is performed, and the fuel consumption deterioration driving and the other driving are divided, and necessary items of the vehicle state information are divided and totaled to obtain an eco driving index. Idling is determined as idling when the speed is 0 km / h based on the vehicle speed information obtained from the vehicle information. Calculate the ratio of the idling time to the total driving time, the fuel consumed during idling, the ratio of fuel proved at idling to the fuel consumed under the driving assumption, and display it with numerical values and graphs . Further, the acceleration is determined to be accelerating when the sensor output value of the acceleration sensor is a certain value (eg, 0.1 G) or more. As with idling, it calculates the acceleration time and the fuel consumed at that time, and displays the percentage of the total operation in numerical values and graphs.

  The operating state evaluation system is realized by a stand-alone computer using a single personal computer, but may be realized by a network system in which a database or a part of arithmetic processing is executed by a server or a host computer connected via a network.

DESCRIPTION OF SYMBOLS 1 Vehicle travel data collection apparatus 2 Apparatus main body 3 Vehicle connection adapter 3
4 GPS Module 5 Connection Cable 6 Connection Cable 7 SD Memory Card 11 Arithmetic Processing Unit 11a Normal Mode Execution Unit 11b Trial Mode Execution Unit 11c Startup Processing Unit 11d Mode Execution Unit 12 Storage Unit 12a Normal Mode Storage Area 12a-1 Normal Mode database 12a-2 Normal mode management file 12b Trial mode storage area 12b-1 Trial mode database 12b-2 Trial mode management file 12b-3 Sample data storage unit 12b-4 Management information template Storage unit 12b-5 Template database 13 Input unit 14 Display unit 15 Card reader

Claims (13)

A system for data processing based on vehicle status information obtained during vehicle travel,
Normal mode execution means for performing the data processing based on actual data obtained by actual traveling;
Demo mode execution means for performing the data processing based on sample data;
A system characterized by comprising:   The system according to claim 1, wherein the normal mode execution unit and the demo mode execution unit operate alternatively.   The system according to claim 2, further comprising means for switching between the normal mode execution means and the demo mode execution means. The normal mode execution means reads the actual data stored in a nonvolatile recording medium and executes processing,
4. The system according to claim 1, wherein the demo mode execution unit reads the sample data stored in a non-volatile recording medium and executes processing.   The sample data on the non-volatile recording medium is not changed at the end of the demo mode at the end of the demo mode, whereas the actual data on the non-volatile recording medium is used for the operation of the normal mode execution means. 5. The system according to claim 4, wherein the system changes in response. The sample data is a database, and has a function of creating a demo mode database for processing by copying the sample data when starting the demo mode.
6. The system according to claim 5, wherein the demo mode execution means performs processing on the demo mode database for processing. The sample data read by the demo mode execution means is recorded on a volatile recording medium,
The demonstration mode execution means includes a function of executing the processing using data recorded on the volatile recording medium and updating data on the volatile recording medium along with the processing. The system according to claim 5. The normal mode execution means has a function of updating the actual data stored in the nonvolatile recording medium with the processing,
The system according to any one of claims 5 to 7, wherein the demonstration mode execution means has only a read function as an access function to the nonvolatile recording medium.   5. The demo mode execution unit has the same function except for a function of updating data stored in the non-volatile recording medium among the functions of the normal mode execution unit. The system in any one of 8-8.   The system according to claim 1, wherein the demo mode execution unit has a function of taking in the actual data and processing the data.   11. The system according to claim 1, wherein the demo mode execution unit has a function of processing the actual data and the sample data in a mixed state.   12. The system according to claim 1, wherein the sample data and the actual data have the same data structure.   A program for causing a computer to realize the functions in the system according to any one of claims 1 to 12.