JP2013156744A - Information processing device and data storage method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To preferentially store data of a specific task.SOLUTION: An information processing device includes: a storage unit for storing therein first data and second data whose storage priority is higher than the first data; a task execution unit for scheduling and executing a first task of storing the first data in the storage unit and a second task of storing the second data in the storage unit; and a data storage control unit for storing the first data in the storage unit in place of the first task in response to a data storage request from the first task, and for storing the second data in the storage unit in place of the second task in response to a data storage request from the second task. When receiving the data storage request from the second task at the time of storage of the second data, the data storage control unit stores the second data in the storage unit in response to the data storage request from the second task even if receiving the data storage request from the first task.

Description

  The present invention relates to an information processing apparatus and a data storage method, and more particularly, to an information processing apparatus and a data storage method for executing a task for storing data and a task for storing higher priority data than the data.

  Service robots must ensure functional safety by constantly monitoring the safety state with external sensors and self-diagnosis devices and executing appropriate safety control logic when any danger is detected.

  In addition to the service robots described above, IEC 61508 has been established as an international standard for functional safety for systems that operate on electrical principles such as transportation equipment. In IEC 61508, a system provided for ensuring functional safety is called a safety-related system. IEC 61508 defines various techniques for constructing a safety-related system using hardware such as a microprocessor and a PLC (Programmable Logic Controller) and a computer program (software). By using the technique defined in IEC 61508, it is possible to construct a safety-related system using a computer system.

  On the other hand, in recent years, the processing capability of programmable electronic devices such as microprocessors has improved. For this reason, a multi-task OS (Operating System) is used, and various application programs are executed in parallel on one computer system, thereby integrating multiple-use computer systems installed in service robots and automobiles. can do.

  For example, Patent Literature 1 discloses a technique for causing an application program (hereinafter referred to as a safety-related application) related to ensuring functional safety to operate on one computer system together with other application programs (hereinafter referred to as a non-safety-related application). Has been.

  When the technique defined in IEC 61508 is applied to the entire software including safety-related applications and non-safety-related applications, it is necessary to apply even to non-safety-related applications. For this reason, there is a problem that the software development cost increases.

  Therefore, in the technique disclosed in Patent Document 1, safety-related applications (safety monitoring program and safety control program) are made independent from non-safety-related applications (normal control program) by time partitioning of the system program. For this reason, the normal control program can be excluded from the safety-related system, which can contribute to the cost reduction of the safety-related system configured using the computer system.

  Here, the technique disclosed in Patent Document 1 employs a technique called resource partitioning. In this technique, fixed resources such as execution memory are partitioned into partitions called resource partitions. The application is prohibited from accessing other resources beyond the pre-assigned resource partition.

JP 2010-271759 A

  Based on the safety control device disclosed in Patent Document 1, the applicant of the present application has newly found a problem to be described below when examining a safety control device that stores a log. The problem will be described below. In addition, the content demonstrated below is the content which the present applicant newly examined, and is not what demonstrated the prior art.

  As a method for facilitating the investigation of the operation / control status of the safety control device, it is conceivable to save a log. Here, in the safety control device, a safety-related task activated from a safety-related application and a non-safety-related task activated from a non-safety-related application are executed in parallel.

  In such a survey, in order to enable a sufficient survey, it is preferable to save a log for each of all tasks (safety related tasks and non-safety related tasks). However, in such a case, the expected log may not be saved depending on the parallel execution status of the task.

  Specifically, a case where an abnormality is detected in the safety control device can be considered as a main case that requires the above-described investigation. Here, the detection of an abnormality in the safety control device is mainly performed by a safety-related task that executes processing related to ensuring functional safety. Therefore, the log to be saved is higher in the log related to the abnormality collected by the safety related task than the log collected by the non-safety related task.

  On the other hand, when an abnormality is detected, the microcontroller that controls each task in the safety control device may be reset to restore the safety control device. In this case, it is conceivable to reset the microcontroller after a certain time has elapsed by stopping the signal to the watchdog timer. According to this, it is also possible to collect a log before the certain time elapses.

  However, depending on the parallel execution status of the task, the non-safety related task operates for a certain time until the microcontroller is reset, and the log is saved by the non-safety related task. In some cases, the operation time of the safety-related task that saves a high log is lost, and the saving of the log by the safety-related task is not in time. On the other hand, by lengthening the time until the microcontroller is reset, it is possible to save the log by the safety related task even after the operation of the non-safety related task. However, if this is done, it takes a long time to restore the safety control device, which is not preferable for operation.

  This is not limited to the case described above, and the same can be said for any system in which a task for storing data and a task for storing data having a higher priority than that data operate.

  The present invention has been made based on the above-described knowledge, and an object thereof is to provide an information processing apparatus and a data storage method capable of preferentially storing data of a specific task.

  An information processing apparatus according to a first aspect of the present invention includes: a storage unit that stores first data and second data that has higher priority than the first data; and the storage unit A task execution unit that schedules and executes a first task that stores the first data and a second task that stores the second data in the storage unit, and data from the first task In response to a storage request, the first data is stored in the storage unit in place of the first task, and in response to a data storage request from the second task, in place of the second task. Data storage control for storing the second data in the storage unit, and the data storage control unit receives a data storage request from the second task when storing the second data In the case, the first tag Even when there is a data storage request from the click, depending on the data storage request from the second task, and stores the second data in the storage unit.

  According to a second aspect of the present invention, the first data is stored in a storage unit that stores the first data and the second data having a higher priority than the first data. In response to a data storage request from the first task, an execution start step for scheduling and starting execution of the first task and the second task for storing the second data in the storage unit, In response to a data storage request from the second task, the first data storing step of storing the first data in the storage unit instead of the first task, the second task instead of the second task A second data storage step for storing the second data in a storage unit, and in the second data storage step, data from the second task is stored when the second data is stored. When there is a storage request Includes storing the second data in the storage unit in response to a data storage request from the second task even when there is a data storage request from the first task. .

  According to each aspect of the present invention described above, it is possible to provide an information processing apparatus and a data storage method capable of preferentially storing data of a specific task.

It is a block diagram which shows the structural example of the safety control apparatus concerning embodiment of invention. It is a figure for demonstrating the concept of the time partitioning in embodiment of invention. It is a conceptual diagram for demonstrating the concept of the resource partitioning in embodiment of invention. It is a figure which shows the relationship between the partition scheduler and task in embodiment of invention. It is a figure which shows the specific example of a scheduling pattern. It is a figure which shows the specific example of a scheduling pattern. It is a figure which shows the relationship between the safety related type | system | group task concerning embodiment of invention, non-safety related, and the task for data Write. It is a flowchart which shows the specific example of the process sequence of the partition scheduler concerning embodiment of invention. It is a flowchart which shows the specific example of the process sequence of log storage concerning embodiment of invention. It is a sequence diagram which shows the specific process example by the process procedure of the log storage concerning embodiment of invention. It is a sequence diagram which shows the specific process example by the process procedure of the log storage concerning embodiment of invention. It is a figure which shows the relationship between the partition scheduler concerning other embodiment, and a task. It is a figure which shows the relationship between the partition scheduler concerning other embodiment, and a task.

  Hereinafter, specific embodiments to which the present invention is applied will be described in detail with reference to the drawings. In the drawings, the same elements are denoted by the same reference numerals, and redundant description is omitted as necessary for the sake of clarity.

<Embodiment of the Invention>
The safety control device 1 according to the present embodiment is mounted on a service robot, a transportation device, or the like, and executes safety control for ensuring functional safety. The safety control device 1 is configured to execute a safety-related application and a non-safety-related application on the same computer system. FIG. 1 is a block diagram illustrating a configuration example of the safety control device 1 according to the present embodiment.

  The processor 10 performs calculation processing according to acquisition of a program (instruction stream), instruction decoding, and instruction decoding result. Although only one processor 10 is shown in FIG. 1, the safety control device 1 may have a multiprocessor configuration having a plurality of processors 10. The processor 10 may be a multi-core processor. The processor 10 provides a multiprogramming environment by executing an operating system (OS) 100 as a system program. A multi-programming environment is an environment in which multiple programs are executed in parallel by periodically switching and executing multiple programs, or by switching the programs to be executed in response to the occurrence of a certain event. means.

  Multiprogramming is sometimes called multiprocess, multithread, multitask, and the like. A process, a thread, and a task mean a program unit that is executed in parallel in a multiprogramming environment. The multi-programming environment included in the processor 10 of the present embodiment may be a multi-process environment or a multi-thread environment.

  The execution memory 11 is a memory used for program execution by the processor 10. The execution memory 11 stores programs loaded from the nonvolatile memory 13 (OS 100 and applications 101 to 105, etc.), input / output data of the processor 10, and the like. The processor 10 may directly execute these programs from the nonvolatile memory 13 without loading the programs from the nonvolatile memory 13 to the execution memory 11.

  Specifically, the execution memory 11 may be a random accessible volatile memory such as SRAM (Static Random Access Memory) or DRAM (Dynamic Random Access Memory). The execution memory 11 in FIG. 1 represents a logical unit. That is, the execution memory 11 may be, for example, a combination of a plurality of SRAM devices, a combination of a plurality of DRAM devices, or a combination of an SRAM device and a DRAM device.

  The I / O port 12 is used for data transmission / reception with an external device. For example, when the safety control device 1 is mounted on a service robot, the external device is various sensors and actuators that operate the service robot. In this case, the various sensors include, for example, a visual sensor capable of measuring obstacles around the service robot, a posture sensor for detecting the posture of the service robot, and a rotation center for detecting the state of the actuator of the service robot. It includes a sensor that detects the internal and external status of the service robot.

  The non-volatile memory 13 is a memory device capable of maintaining stored contents more stably than the execution memory 11 without receiving power supply. For example, the nonvolatile memory 13 is a ROM (Read Only Memory), a flash memory, a hard disk drive or an optical disk drive, or a combination thereof. The nonvolatile memory 13 stores the OS 100 and the applications 101 to 105. Note that at least a part of the nonvolatile memory 13 may be configured to be removable from the safety control device 1. For example, the memory storing the applications 101 to 103 may be removable. Further, at least a part of the nonvolatile memory 13 may be disposed outside the safety control device 1.

  An EEPROM (Electrically Erasable Programmable Read-Only Memory) 14 is a memory device capable of maintaining stored contents more stably than the execution memory 11 without receiving power supply. In the EEPROM 14, logs are stored by the applications 101 to 103 through the data write applications 104 and 105. The EEPROM 14 includes an area in which logs of safety-related applications 101 and 103 (safety-related tasks) are stored and an area in which logs of non-safety-related applications 102 (non-safety-related tasks) are stored. Note that the applications 101 to 103 may use other nonvolatile memories such as a flash memory in addition to the EEPROM 14 as a storage device for storing logs. In the present embodiment, the case where a log is stored in the EEPROM 14 is illustrated, but the data stored in the EEPROM 14 is not limited to the log.

  The OS 100 is executed by the processor 10 to use task resources including task scheduling, interrupt management, time management, resource management using hardware resources such as the processor 10, the execution memory 11, and the nonvolatile memory 13. Provides inter-task synchronization and inter-task communication mechanism.

  Further, in order to increase the independence of the safety monitoring application 101 and the safety control application 103 related to ensuring functional safety from the normal control application 102, the OS 100 has a function of protecting hardware resources temporally and spatially. . Here, the hardware resources include the processor 10, the execution memory 11, and the I / O port 12.

  Of these, temporal protection is performed by partitioning a temporal resource called the execution time of the processor 10. Specifically, temporal protection is performed by partitioning the execution time of the processor 10 and assigning a task (process or thread) to each partition (referred to as a time partition). The scheduling function (partition scheduler 21) of the OS 100 guarantees the use of resources including the execution time of the processor 10 for tasks assigned to each time partition (hereinafter sometimes referred to as TP).

  FIG. 2 is a conceptual diagram related to time partitioning. In the example of FIG. 2, an example in which a predetermined cycle time is divided into three TP1, TP2, and TP3 is shown. For example, when one cycle time is 100 Tick, the first 20 Tick is defined as TP1, the middle 30 Tick is defined as TP2, and the second 50 Tick is defined as TP3.

  In the example of FIG. 2, the first application (APL1) to the fourth application (APL4) are assigned to any one of TP1 to TP3. The scheduling function (partition scheduler 21) of the OS 100 selects / determines which of TP1 to TP3 is activated as time elapses. Then, the application assigned to the active TP is executed by the processor 10.

  On the other hand, spatial protection is performed by partitioning fixed resources including the execution memory 11 and the I / O port 12 and assigning tasks to each partition (referred to as a resource partition). The scheduling function (partition scheduler 21) of the OS 100 prohibits a task from accessing other resources beyond a pre-assigned resource partition (hereinafter sometimes referred to as RP).

  FIG. 3 is a conceptual diagram related to resource partitioning. In the example of FIG. 3, two RPs (RP1 and RP2) are shown. A part of the execution memory 11 and the nonvolatile memory 13 (A area) and a part of the I / O port 12 (port A) are allocated to RP1. Further, another part (B area) of the execution memory 11 and the nonvolatile memory 13 and another part (port B) of the I / O port 12 are allocated to RP2. Access from RP1 to the resource assigned to RP2 is prohibited, and access from RP2 to the resource assigned to RP1 is prohibited.

  Note that not all resources need to be exclusively assigned to any RP. That is, there may be a resource shared by a plurality of RPs. For example, when performing safety control of a service robot, the actuator needs to be accessible from both the normal control application 102 and the safety control application 103. Therefore, the I / O port for controlling the actuator may be shared by the RP to which the normal control application 102 belongs and the RP to which the safety control application 103 belongs.

  Returning to FIG. The applications 101 to 105 are executed in a multiprogramming environment provided by the OS 100 and the processor 10. Among these, the safety monitoring application 101 executes the processor 10 to monitor the execution status of the normal control application 102, monitor the execution status of the safety control application 103, and monitor input / output data to the I / O port 12. Instruction code to make it Further, the safety monitoring application 101 includes an instruction code for causing the processor 10 to execute a result notification to the partition scheduler 21. Further, the safety-related application 101 includes an instruction code for causing the processor 10 to execute log generation and a request for storing the log in the EEPROM 14 for the data write application 105. That is, the safety monitoring application 101 is a safety related application.

  Further, the normal control application 102 includes an instruction code for causing the processor 10 to execute a control procedure for causing a control target such as a service robot to perform a normal function / operation. Further, the normal control application 102 includes an instruction code for causing the processor 10 to execute a result notification to the partition scheduler 21. Further, the normal control application 102 includes an instruction code for causing the processor 10 to execute generation of a log and a request for storing the log in the EEPROM 14 to the data write application 106. That is, the normal control application 102 is a non-safety related application.

  Further, the safety control application 103 includes an instruction code for causing the processor 10 to execute a control procedure determined to ensure functional safety in response to a case where some abnormality is detected. Further, the safety control application 103 includes an instruction code for causing the processor 10 to execute a result notification to the partition scheduler 21. Further, the safety control application 103 includes an instruction code for causing the processor 10 to execute generation of a log and a request for storing the log in the EEPROM 14 for the data write application 105. That is, the safety control application 103 is a safety-related application.

  The data write application 105 includes an instruction code for causing the processor 10 to store a log in the EEPROM 14 in response to a request from the safety-related applications 101 and 103.

  Further, the data write application 106 includes an instruction code for causing the processor 10 to store a log in the EEPROM 14 in response to a request from the non-safety related application 102.

  The reset circuit 15 resets the microcontroller 20 based on a signal from the OS 100. A transmission signal is periodically transmitted from the partition scheduler 21 to the reset circuit 15, and the reset circuit 15 resets the microcontroller 20 when the transmission signal from the partition scheduler 21 is interrupted for a predetermined time. That is, the reset circuit 15 functions as a watch dog timer. For example, as will be described later, the partition scheduler 21 transmits a transmission signal to the reset circuit 15 at a timing of operating every 1 tick. When the partition scheduler 21 detects an abnormality in the OS 100 or receives a result notification indicating an abnormality from any of the applications 101 to 103, the partition scheduler 21 stops transmission of a transmission signal to the reset circuit 15. Thus, the reset circuit 15 resets the microcontroller 20 after a predetermined time has elapsed.

  Further, when an abnormality is detected by the OS 100 or when a result notification indicating an abnormality is received from any of the applications 101 to 105, the partition scheduler 21 transmits a reset signal to the reset circuit 15, and accordingly Thus, the reset circuit 15 may reset the microcontroller 20. By doing in this way, when a malfunction occurs in the microcontroller 20, the microcontroller 20 can be reset and recovered.

  Subsequently, the relationship between the partition scheduler 21 and the tasks generated by the activation of the applications 101 to 105 will be described with reference to FIG. FIG. 4 is a diagram showing the relationship between the partition scheduler 21 and tasks 24, 26, 28, 29, and 30 that are activated in the multiprogramming environment provided by the OS 100.

  The microcontroller 20 includes a processor 10, an execution memory 11, an I / O port 12, a nonvolatile memory 13, and the like. 4 illustrates a configuration in which the reset circuit 15 is provided outside the microcontroller 20, but a configuration in which the reset circuit 15 is included in the microcontroller 20 may be employed.

  The microcontroller 20 is supplied with a clock signal from an external clock source, and the processor 10 and the like operate at a predetermined timer cycle based on this clock signal. In the present embodiment, the predetermined timer cycle is described as 1 Tick. For this reason, when the processor 10 executes the OS 100, the partition scheduler 21 operates every 1 Tick, and at each TP, the task schedulers 23, 25, 27 and tasks (safety monitoring task 24, normal control task 26, safety The control task 28 and the data write tasks 29 and 30) operate every 1 tick.

  The partition scheduler 21 operates every 1 tick and performs TP switching (partition scheduling). The partition scheduler 21 selects and determines which of TP1 to TP3 is activated during the next 1 Tick. Furthermore, the partition scheduler 21 starts the operation of the task scheduler related to the selected TP.

  More specifically, partition scheduling by the partition scheduler 21 refers to the scheduling table 22 and performs partition scheduling according to a scheduling pattern that defines TP settings.

  The scheduling table 22 holds a scheduling pattern that defines the TP switching order and timing. For example, the scheduling table 22 is stored in advance in the execution memory 11. The scheduling table 22 holds at least two different scheduling patterns. One is a scheduling pattern that is applied when abnormality detection by the safety monitoring task 24 is not performed (that is, during normal time). The other is a scheduling pattern applied when an abnormality is detected by the safety monitoring task 24. Hereinafter, the scheduling pattern applied in the normal time is referred to as “normal control scheduling pattern”. A scheduling pattern applied at the time of detecting an abnormality is called a “safe control scheduling pattern”.

  FIG. 5A shows a specific example of the normal control scheduling pattern. In FIG. 5A, TP2 to which the normal control task 26 belongs is assigned to the first half (T1) of one cycle time. In addition, TP1 to which the safety monitoring task 24 belongs is assigned to the second half (T2) of one cycle time. According to the scheduling pattern of FIG. 5A, the normal control task 26 and the safety monitoring task 24 are repeatedly scheduled.

  FIG. 5B shows a specific example of the safety control scheduling pattern. In FIG. 5B, TP3 to which the safety control task 28 belongs is assigned to the first half (T3) of one cycle time. In addition, TP1 to which the safety monitoring task 24 belongs is assigned to the second half (T4) of one cycle time. According to the scheduling pattern of FIG. 5B, the safety control task 28 and the safety monitoring task 24 are repeatedly scheduled.

  Returning to FIG. The task schedulers 23, 25, and 27 perform task scheduling in the TP to which each belongs. For scheduling tasks in each TP, general priority-based scheduling may be applied. In FIG. 4, TP1 is illustrated as including three tasks, and TP2 and TP3 are illustrated as including only one task, but other tasks may be included. For example, the normal control task A and the normal control task B may be included in the normal control TP2.

  The safety monitoring task 24 is a task generated when the safety monitoring application 101 is activated. In the example of FIG. 4, the safety monitoring task 24 is assigned to TP1 and RP1. The safety monitoring task 24 monitors the execution status of the normal control task 26 that is a non-safety related application, monitors the execution status of the safety control task 28 that is a safety related application, and monitors input / output data of the I / O port 12. To do. Furthermore, the safety monitoring task 24 notifies the partition scheduler 21 of the task execution status. Further, the safety monitoring task 24 generates a log corresponding to its own process, and requests the data write task 29 to store the generated log in the EEPROM 14. The safety monitoring task 24 performs calculations necessary for executing its own processing while using the resources of the execution memory 11 assigned to the RP1 to which the safety monitoring task 24 belongs.

  The normal control task 26 is a task generated when the normal control application 102 is activated. In the example of FIG. 4, the normal control task 26 is assigned to TP2 and RP2. The normal control task 26 performs control for causing a control target such as a service robot to perform a normal function / operation. Further, the normal control task 26 notifies the partition scheduler 21 of the task execution status. Further, the normal control task 26 generates a log corresponding to its own process, and requests the data write task 30 to store the generated log in the EEPROM 14. The normal control task 26 performs calculations necessary for executing its own processing while using the resources of the execution memory 11 assigned to the RP 2 to which the normal control task 26 belongs.

  The safety control task 28 is a task generated when the safety control application 103 is activated. In the example of FIG. 4, the safety control task 28 is assigned to TP3 and RP3. The safety control task 28 performs control determined to ensure functional safety in response to any abnormality being detected. Further, the safety control task 28 notifies the partition scheduler 21 of the task execution status. Further, the safety control task 28 generates a log corresponding to its own processing, and requests the data write task 29 to store the generated log in the EEPROM 14. The safety control task 28 performs calculations necessary for executing its own processing while using the resources of the execution memory 11 assigned to the RP 3 to which the safety control task 28 belongs.

  Various methods can be adopted as a specific configuration for notifying the result from each task to the partition scheduler 21. For example, a task can call a system call (service call) of the OS 100 and notify the partition scheduler 21 of the result via the OS 100. Also, for example, assuming that a flag related to the task execution status is stored in the execution memory 11, the task sets a flag value according to the execution status, and the partition scheduler 21 executes the task according to the flag set value. The situation can also be judged.

  As described above, the partition scheduler 21 operates every 1 Tick, and selects and determines which of TP1 to TP3 is activated. Further, the partition scheduler 21 starts the operation of the task scheduler related to the selected TP. Then, task scheduling is performed by the task schedulers 23, 25, and 27 starting operations, and the processor 10 executes the tasks in the TP according to the order scheduled by the task schedulers 23, 25, and 27. Go. As a result, the application assigned to the active TP is executed by the processor 10.

  The data write task 29 stores the logs generated by the safety-related tasks 24 and 28 in the EEPROM 14 in response to requests from the safety-related tasks 24 and 28. In the example of FIG. 4, the data write task 29 is assigned to TP1 and RP1. The data write task 29 performs calculations necessary for executing its own processing while using the resources of the execution memory 11 assigned to the RP1 to which the data write belongs.

  The data write task 30 stores the log generated by the non-safety related task 26 in the EEPROM 14 in response to a request from the non-safety related task 26. In the example of FIG. 4, the data write task 30 is assigned to TP1 and RP1. The data write task 29 performs calculations necessary for executing its own processing while using the resources of the execution memory 11 assigned to the RP1 to which the data write belongs.

  Here, the TP and RP to which the data write tasks 29 and 30 are assigned are not limited to the case illustrated in FIG. For example, it is not limited to safety-related TP1 and TP3, but may belong to non-safety-related TP2, and a data write TP to which only the data write tasks 29 and 30 belong is prepared and belong to it. Also good. In order to always allow log storage, the TP1 that is active in both the normal control scheduling pattern and the safety control scheduling pattern, such as TP1 illustrated in FIGS. 5A and 5B, operates. It is preferable to do so.

  Here, each of the tasks 24, 26, and 28 generates data having contents corresponding to each process as a log. The safety monitoring task 24 generates, as a log, data indicating the monitoring contents in the monitoring as described above, for example. That is, if any abnormality is detected as a result of monitoring, the safety monitoring task 24 generates data relating to the cause of the abnormality as a log. Specifically, the safety monitoring task 24 generates, as a log, a sensor value acquired from various sensors via the I / O port 12 and a value calculated based on the sensor value. For example, based on the output data value output to the control target from the normal control task 26 or the safety control task 28 via the I / O port 12, the image data acquired from the visual sensor, and the image data acquired from the visual sensor. The calculated distance to the obstacle, the value indicating the attitude of the controlled object acquired from the attitude sensor, the value indicating the state of the controlled actuator acquired from the rotation sensor, the current value of the circuit in the controlled object or the microcontroller 20, etc. It is data which shows. In addition, each of the normal control task 26 and the safety control task 28 generates, as a log, data indicating, for example, calculation contents of output data for the control target.

  Here, the investigation of the operation / control state of the safety control device 1 based on the log is mainly performed to identify the cause of the abnormality when any abnormality is detected in the safety control device 1. That is, the log collected by the safety monitoring task 24 has a higher priority to be stored in the EEPROM 14 than the other logs. As described above, the safety-related tasks 24 and 28 are tasks for executing processing for ensuring functional safety such as detection of abnormality and processing according to the detected abnormality. For this reason, the logs collected by the safety-related tasks 24 and 28 are logs that are more strongly related to the cause of the abnormality, and therefore, the priority stored in the EEPROM 14 is higher than the logs collected by the non-safety-related tasks 26. .

  Therefore, in this embodiment, the data write task 29 for storing the safety-related task log has priority to save the log over the data write task 30 for storing the non-safety-related task log. So that more important logs are collected.

  Next, the relationship between the safety-related tasks 24 and 28 and the non-safety-related tasks 26 and the data write tasks 29 and 30 according to the embodiment of the invention will be described with reference to FIG. FIG. 6 is a diagram showing the relationship between the safety-related tasks 24 and 28 and the non-safety-related tasks 26 and the data write tasks 29 and 30 according to the embodiment of the invention.

  As described above, the OS 100 provides an inter-task communication function for tasks that run on the OS 100. Specifically, the OS 100 provides a system call for performing inter-task communication for a task operating on the OS 100.

  When storing the log generated by itself in the EEPROM 14, the safety-related tasks 24 and 28 transmit log storage request data for requesting log storage to the data write task 29 by inter-task communication. This is performed by a safety-related task specifying a log storage request data as an argument and calling a system call provided by the OS 100. The log storage request data includes a log generated by the safety-related task and data indicating the address of the EEPROM 14 that stores the log.

  The OS 100 routine that operates by calling a system call stores log storage request data specified by a safety-related task in a data queue (DTQ) for requests. That is, the data queue functions as a “message queue”. The data queue is realized by using a partial area of the execution memory 11.

  The data write task 29 receives the log storage request data transmitted from the safety-related task by inter-task communication. This is performed when the data write task 29 calls a system call provided by the OS 100. The OS 100 routine that operates by calling the system call reads the log storage request data stored in the request data queue and passes it to the data write task 29. Specifically, the OS 100 routine transfers the log storage request data to the caller data write task 29 as a return value of the system call.

  The data write task 29 stores the log included in the log storage request data received by inter-task communication in the EEPROM 14. The data write task 29 stores the log at the address of the EEPROM 14 indicated by the log storage request data. Then, the data write task 29 transmits the result notification data for notifying the log storage result to the EEPROM 14 to the safety-related task that is the log storage request source by inter-task communication. As described above, this is performed by the data write task 29 calling a system call provided by the OS 100 using the result notification data as an argument. The OS 100 routine that operates by calling a system call stores the result notification data designated by the data write task 29 in the response data queue.

  The safety-related task receives the result notification data transmitted from the data write task 29 by inter-task communication. This is performed by a safety-related task calling a system call provided by the OS 100 as described above. The OS 100 routine that operates by calling a system call reads out the result notification data stored in the response data queue and passes it to the safety-related task. Specifically, the OS 100 routine transfers the result notification data to the safety-related task as a return value of the system call.

  Note that when the non-safety related task requests the data write task 30 to store the log, it is performed by inter-task communication in the same manner, and thus the description thereof is omitted.

  Next, partition scheduling by the partition scheduler 21 will be described with reference to FIG. FIG. 7 is a flowchart showing a specific example of the processing procedure of the partition scheduler 21 according to the first embodiment of the invention.

  In FIG. 7, a case where scheduling is executed according to a normal control scheduling pattern (for example, FIG. 5A) or a safety control scheduling pattern (for example, FIG. 5B) will be described as an example. That is, when the next TP following TP2 or TP3 is TP1, and when an abnormality in TP2 is detected in TP1, the next TP selected and determined based on the result from TP1 is TP3 Will be described as an example.

  The OS 100 starts the partition scheduler 21 every time one tick elapses (S11) (S12). The partition scheduler 21 refers to the scheduling pattern and determines whether or not it is TP switching timing (S13).

  If it is determined that it is not the TP switching timing (No in S13), the partition scheduler 21 continues the operation for the same TPX. For this reason, the processes of S11 to S13, S15, and S16 are repeated until the TP switching timing is reached. Here, the variable X indicates the number of TP, and X is any one of 1 to 3. That is, when partition scheduling is performed according to the normal control scheduling pattern, either TP2 or TP1 except for TP3 for safety control is operated.

  On the other hand, when it is determined that it is TP switching timing (Yes in S13), the partition scheduler 21 executes TP switching (S14). As described above, when the partition scheduler 21 changes the TP to be activated next (Yes in S13), the partition TP before switching is normal according to the notification result from the task belonging to the TP before switching. It is determined whether or not. If the TP before switching is abnormal as a result of the determination, the partition scheduler 21 selects and determines the TPX to be activated during the next 1 Tick from either TP1 or TP3 according to the safety control scheduling pattern. As a result of the determination, if it is normal, the partition scheduler 21 selects and determines one of TP1 and TP2 in accordance with the normal control scheduling pattern for TPX to be activated during the next 1 Tick.

  The partition scheduler 21 operates the task scheduler of the currently active TPX (S15). The task scheduler of TPX that started the operation in S15 executes the task in TPX according to the priority (S16).

  When 1 Tick elapses (S11), the partition scheduler 21 starts TP scheduling again (S12). That is, the partition scheduler 21 selects and determines which TP is to be activated during the next 1 Tick according to the scheduling pattern.

  A specific example of partition scheduling will be described with respect to the processing shown in FIG. First, according to the normal control scheduling pattern illustrated in FIG. 5A, the case where scheduling is started from the active state of TP2 in S15 will be described. In this case, TPX = TP2 is started in S15, and TPX = TP2 remains even in subsequent S16 and S11 to S13. And as long as No continues in S13, the state of TPX = TP2 is maintained. If S13 is Yes and TP2 is changed to TP1 in S14, TP1 remains in S15 to S16 and S11 to S13. As long as No continues in S13, the state of TPX = TP1 is maintained. When it is determined in S16 that the execution status (data input / output, etc.) related to TP2 is normal when TP1 is active, TPX = TP2 in the next S14 (that is, start from TP2). Normal control scheduling pattern continues.) On the other hand, if it is determined in S16 that the execution status (data input / output, etc.) relating to TP2 is abnormal, TPX = TP3 (that is, a safety control scheduling pattern starting from TP3) in the next S14. Switch to.)

  Further, a case will be described in which scheduling is started from the active state of TP3 in S15 according to the safety control scheduling pattern illustrated in FIG. 5B. In this case, TPX = TP3 is started in S15, and TPX = TP3 remains even in subsequent S16 and S11 to S13. And as long as No continues in S13, the state of TPX = TP3 is maintained. If the answer is Yes in S13 and the TP3 is changed to TP1 in S14, TP1 remains as it is in subsequent S15 to S16 and S11 to S13. As long as No continues in S13, the state of TPX = TP1 is maintained. When it is determined in S16 that the execution status (data input / output, etc.) relating to TP3 is normal when TP1 is active, TPX = TP2 is set in the next S14 (that is, starting from TP2). Switch to normal control scheduling pattern.) On the other hand, if it is determined in S16 that there is an abnormality in the execution status (data input / output, etc.) related to TP3, TPX = TP3 (that is, a safety control scheduling pattern starting from TP3) in the next S14. Will continue.)

  In the above-described example, a case where only three TPs (safety monitoring TP1, normal control TP2 and safety control TP3) are combined as a scheduling pattern has been described as an example. There may be a plurality of control partitions and safety control partitions such as TP3. For example, there are two TP2 and TP4 for normal control, TP1 for safety monitoring, and two TP3 and TP5 for safety control, and these five TPs (TP1 to TP5) are combined to form a scheduling pattern. It may be configured. In this case, in S14, the partition scheduler 21 determines the type of the abnormal state of the execution status (data input / output, etc.) related to TPX, and selects either TP3 or TP5 for safety control according to the abnormal type. That's fine. In S14, either TP2 or TP4 for normal control may be selected.

  As described above, in this embodiment, the OS 100 includes the partition scheduler 21 that selects and determines the partition to be activated next in response to a notification from the TP1 for safety monitoring or a notification from each TP. ing. The partition scheduler 21 operates at a predetermined timer period independently of the tasks executed in each TP.

  With the configuration in which the partition scheduler 21 that operates independently receives the result notification from all TPs, the partition scheduler 21 can centrally grasp the situation regarding all TPs. Therefore, for example, when the partition scheduler 21 decides and selects the next partition in response to the result notification from the safety monitoring TP1, the partition scheduler 21 considers the situation of each TP. The next partition can be determined and selected only from the TP in the normal state. According to this, there is an effect that more accurate partition scheduling can be realized.

  Next, a log storage processing procedure according to this embodiment will be described with reference to FIG. FIG. 8 is a flowchart showing a log storage processing procedure according to the present embodiment.

  It is determined whether or not the safety related task requests the data write task 29 to store the log in the EEPROM 14 (S21). Here, in the present embodiment, there are two cases where it is determined whether or not the safety-related task requests the storage of the log in the EEPROM 14.

  The first case is a case in which the data write task 29 is determined by the OS 100 when the data write task 29 is in a sleep state waiting by calling a system call provided by the OS 100. This system call causes the caller task to sleep, and when the data for the caller task is stored in the request data queue, the caller task is woken up and transitioned to the execution state.

  Therefore, when the safety-related task requests the data write task 29 to store the log in the EEPROM 14 (S21: Yes), the OS 100 causes the task scheduler 23 to wake up the data write task 29. , Transition to the execution state. The data write task 29 that has started operation by transitioning to the execution state calls the system call for receiving the log storage request data described above, and acquires the log storage request data (S24). Then, the data write task 29 performs processing (S26 to S30) for storing the log of the safety-related task based on the acquired log storage request data. On the other hand, when the safety-related task does not request the data write task 29 to store the log in the EEPROM 14 (S21: No), the OS 100 continues the wait state of the data write task 29 and the non-safety related task. It is determined whether or not the system task requests the data write task 30 to store the log in the EEPROM 14 (S22).

  The second case is a case where the data write task 29 is operating in an execution state, and a determination is made by calling a system call provided by the OS 100. This determination is performed, for example, when the data write task 29 calls a system call that receives the log storage request data described above. The data write task 29 stores the log storage request data in the request data queue, and if the log storage request data can be obtained by calling a system call, the safety related task is It is determined that log storage in the EEPROM 14 is requested (S21: Yes, S24). On the other hand, if the log write request data is not stored in the request data queue and the log write request data cannot be obtained by calling the system call, the data write task 29 is safety related. It is determined that the system task is not requesting storage of the log in the EEPROM 14 (S21: No). That is, in the second case, the data write task 29 determines whether or not the safety-related task requests log storage by polling.

  When the safety-related task is requesting storage of the log in the EEPROM 14 (S21: Yes), the data write task 29 stores the log of the safety-related task based on the acquired log storage request data. The process (S26-S30) to perform is performed. On the other hand, if the safety-related task does not request storage of the log in the EEPROM 14 (S21: No), the system call to sleep described above is called and the execution is terminated. As a result, control is transferred to the OS 100. Then, the OS 100 determines whether or not the non-safety related task requests the data write task 30 to store the log in the EEPROM 14 (S22).

  Here, in a case where it is determined whether or not the non-safety related task requests the storage of the log in the EEPROM 14, the data write task 30 calls the above-described sleep system call to set the waiting state. This is only the case when it is determined by the OS 100.

  When the non-safety related task requests the data write task 30 to store the log in the EEPROM 14 (S22: Yes), the OS 100 wakes up the data write task 30 by the task scheduler 23. Transition to the execution state. The data write task 30 that has started the operation after transitioning to the execution state calls the system call for receiving the log storage request data described above, and acquires the log storage request data (S25). Then, the data write task 30 performs processing (S26 to S30) for storing the log of the non-safety related task based on the acquired log storage request data. On the other hand, when the non-safety related task does not request the data write task 30 to store the log in the EEPROM 14 (S22: No), the OS 100 continues the waiting state of the data write task 30.

  In this way, the data write task 29 or the data write task 30 is waited until log storage is requested (S23). Thereafter, S21 and S22 are repeated, and the processing procedure of performing log storing processing (S26 to S30) is repeated in response to a log storage request.

  Further, as described above, a log storage request from a safety-related task is first determined, and then a log storage request from a non-safety-related task is determined. According to this, even when the safety-related log and the non-safety-related log are requested to be stored at the same time, the safety-related log having a high priority can be preferentially stored in the EEPROM 14. it can. This is because the data write task 29 is scheduled earlier than the data write task 30 in TP1 by setting the priority for executing the data write task 29 higher than the data write task 30. It is realized by making.

  The data write task requested to store the log determines whether the address storing the log specified by the log storage request data is within an allowable range (S26). Specifically, the data write task determines whether or not the designated address falls within the effective address of the EEPROM 14. Further, when the data write task for which log storage is requested is the data write task 30, it is determined whether or not the designated address designates a safety-related task area in the EEPROM 14. To do.

  That is, when the data write task for which log storage is requested is the data write task 29, the address is within the allowable range if the specified address is within the effective address of the EEPROM 14. (S27: Yes). On the other hand, when the designated address does not fit in the effective address of the EEPROM 14, it is determined that the address is not within the allowable range (S27: No).

  When the data write task for which log storage is requested is the data write task 30, the designated address is within the effective address of the EEPROM 14, and for the safety related task of the EEPROM 14. If it is not an area (or if it is an area for a non-safety related task in the EEPROM 14), it is determined that the address is within an allowable range (S27: Yes). On the other hand, when the designated address does not fit in the effective address of the EEPROM 14, or when it is an area for a safety related system task of the EEPROM 14 (or when it is not an area for a non-safety related system task of the EEPROM 14), It is determined that the address is not within the allowable range (S27: No).

  When it is determined that the address is not within the allowable range (S27: No), the data write task does not store the log in the EEPROM 14, and the result notification data for notifying the abnormality is transmitted by inter-task communication. It is transmitted to the task (S30).

  By doing so, it is possible to prevent the log of the safety-related task having a high priority stored in the area for the safety-related task from being overwritten with the log of the non-safety-related task. Further, according to this, the independence of the safety-related task log with respect to the non-safety-related task log can be ensured at low cost and in a small space. For example, two EEPROMs for storing safety-related task logs and non-safety-related task logs, and two processing routines (for example, drivers) for processing data storage for the respective EEPROMs are provided. A method of guaranteeing independence is also conceivable. However, in this case, since it is necessary to mount two EEPROMs and two processing routines, there is a problem that the cost is increased. Moreover, since two EEPROMs are mounted, there is also a problem that a mounting space is consumed. On the other hand, according to this embodiment, even if only one EEPROM 14 is used, it is possible to prevent overwriting of a log of a safety-related task having a high priority. Therefore, log independence can be ensured at low cost and space saving.

  In the above description, when the data write task for which log storage is requested is the data write task 29, the specified address specifies the area for the non-safety related task in the EEPROM 14. It is not determined whether or not there is. According to this, safety-related tasks have higher priority than non-safety-related tasks, so if there is no room for storing logs in the area for safety-related tasks, it is not safe. It is also possible to store safety-related task logs in the related task area.

  Conversely, even when the data write task for which log storage is requested is the data write task 29, the designated address is insecure in the EEPROM 14, as with the data write task 30. It may also be determined whether or not a related task area is designated. By doing so, higher independence may be ensured between the safety-related task log and the non-safety-related task log.

  The task that has received the result notification data for notifying the abnormality from the data write task executes processing according to the abnormality notification. For example, recovery may be attempted by resetting the microcontroller 20. Specifically, the task that has received the result notification data notifies the partition scheduler 21 of a result notification indicating an abnormality. In response to the notification, the partition scheduler 21 stops the transmission of the transmission signal to the reset circuit 15 and causes the reset circuit 15 to reset the microcontroller 20 as described above.

  At this time, before resetting the microcontroller 20, the partition scheduler 21 may stop the control target in order to ensure the safety of the control target. Specifically, when operating according to the normal control scheduling pattern shown in FIG. 5A, the partition scheduler 21 switches the scheduling pattern to the safe control scheduling pattern shown in FIG. 5B. Further, the partition scheduler 21 may forcibly switch TP to TP3 at the next operation timing. Then, after switching to TP3, for example, the control target is stopped by the safety control task 28. Further, the partition scheduler 21 may control the partition scheduler 21 to stop the control target when notified from the safety control task 28 that the task execution status is abnormal.

  If it is determined that the address is within the allowable range (S27: Yes), the data write task stores the log included in the log storage request data in the EEPROM 14 (S28). The data write task transmits result notification data for notification of success to the requesting task through inter-task communication (S29).

  At this time, if the data write task for which log storage is requested is the data write task 29, the data write task 29 requests the log storage by the safety-related task by polling as described above. It is determined whether or not (S21). On the other hand, if the data write task for which log storage is requested is the data write task 30, the data write task 30 waits by calling the sleep system call described above as described above. Transition to. As a result, the OS 100 determines whether or not the safety-related task is requesting log storage (S21).

  In the above description, the case where the log is stored in the EEPROM 14 is exemplified. However, when the safety-related task or the non-safety-related task reads the data stored in the EEPROM 14, the same processing is performed. May be. In this case, from the safety-related task and the non-safety-related task, the log write data requesting to read the log, in which the address where the log to be read is stored, is specified by the task 29 for data write by inter-task communication. 30 will be transmitted. Then, the processing described above is performed on the log read data instead of the log storage request data. In addition, the data write tasks 29 and 30 read the log from the address specified by the log read data instead of storing the log in S28, include the read log in the result notification data, and request it by inter-task communication. It is transmitted to the original task (S29).

  Next, a specific example of the log storage processing procedure according to the present embodiment will be described with reference to FIG. FIG. 9 is a sequence diagram illustrating a specific processing example according to the log storage processing procedure according to the present embodiment described with reference to FIG. 8.

  First, the data write task 29 is in an execution state, the mutex is locked (S41), and the data write task 30 is in an executable state. The data write task 29 checks whether or not the log storage request data from the data queue can be received by polling (S42).

  When the log write request data 29 cannot be received (S43: No), the data write task 29 unlocks the mutex (S44) and transitions to a wait state to wait for the log storage request data (S45). On the other hand, if the data write task 29 has received the log storage request data (S43: Yes), it executes the EEPROM control process (S49). That is, the log is stored in the EEPROM 14 (S26 to S29). Then, the data write task 29 confirms again whether or not the log storage request data from the data queue can be received by polling (S42). As a result, when there is a log storage request from the safety-related task, the storage of the safety-related task log corresponding to the request can be preferentially and continuously executed.

  After the data write task 29 transitions to the wait state (S45), the task scheduler 23 transitions the executable data write task 30 to the execution state. Here, it is assumed that the data write task 30 is in a state where storage of the log is finished, for example. The data write task 30 shifts to a wait state to wait for log storage request data (S46).

  When the log storage request data for the data write task 29 is stored in the request data queue by the safety related task, the task scheduler 23 shifts the data write task 29 to the execution state. The data write task 29 transitioned to the execution state receives the log storage request data from the data queue (S47). The data write task 29 locks the mutex (S48) and executes the EEPROM control process (S49). Then, the data write task 29 confirms again whether or not the log storage request data from the data queue can be received (S42).

  On the other hand, when the log storage request data for the data write task 30 is stored in the request data queue after the data write task 29 transitions to the wait state, the task scheduler 23 executes the data write task 30. Transition to. The data write task 30 that has transitioned to the execution state receives log storage request data from the data queue (S50). The data write task 30 locks the mutex (S51) and executes the EEPROM control process (S52). Then, the data write task 29 unlocks the mutex (S53), and transitions to a wait state to wait for log storage request data (S46).

  Next, a specific example of the log storage processing procedure according to the present embodiment will be described with reference to FIG. FIG. 10 is a sequence diagram illustrating a specific processing example according to the log storage processing procedure according to the present embodiment described with reference to FIG. 8. In FIG. 10, an example different from the processing example described with reference to FIG. 9 will be described.

  First, it is assumed that each of the data write task 29 and the data write task 30 is in a waiting state. When the log storage request data for the data write task 29 is stored in the request data queue, the task scheduler 23 changes the data write task 29 to the execution state. The data write task 29 transitioned to the execution state receives the log storage request data from the data queue (S61). The data write task 29 locks the mutex and starts the EEPROM control process (S63).

  Here, in the example shown in FIG. 10, it is assumed that the dispatch has occurred by performing processing that triggers dispatch such as the data write task 29 calling a system call. At this time, it is assumed that log storage request data for the data write task 30 is stored in the request data queue. In this case, the task scheduler 23 shifts the data write task 29 to an executable state (S64), and shifts the data write task 30 to an execution state.

  The data write task 30 transitioned to the execution state receives the log storage request data from the data queue (S65). The data write task 30 locks the mutex in order to execute the EEPROM control process according to the received log storage request (S66). However, since the mutex is already locked by the data write task 29 (S62), the data write task 30 waits for lock. For this reason, the task scheduler 23 shifts the data write task 30 to a waiting state (S67).

  As a result, the task scheduler 23 again transitions the data write task 29 that is in the executable state to the execution state (S67). The data write task 29 in the executable state continues the EEPROM control process that was previously interrupted. Then, when the data write task 29 finishes the EEPROM control process (S68), it checks whether or not the log storage request data can be received from the data queue by polling (S69).

  If the data write task 29 has received the log storage request data (S70: Yes), it executes the EEPROM control process (S71). The subsequent processing is the same as the processing after S49 described with reference to FIG.

  On the other hand, if the log write request data 29 cannot be received (S70: No), the data write task 29 unlocks the mutex (S72), and transitions to a wait state to wait for the log storage request data (S73). .

  After the data write task 29 transits to the wait state (S45), the mutex is unlocked by the data write task 29 (S72), so the task scheduler 23 executes the wait data write task 30 Transition to a state. The data write task 30 locks the mutex (S74) and executes the EEPROM control process (S75). Then, the data write task 30 unlocks the mutex (S76), and transitions to a wait state to wait for log storage request data (S77).

  According to the above description, the data write task 29 locks the EEPROM 14 before storing the log in the EEPROM 14, and unlocks the EEPROM 14 after storing the log in the EEPROM 14. According to this, even when a dispatch from the data write task 29 to the data write task 30 occurs during the storage process of the safety related log, priority can be given to the storage of the safety related log. That is, even if there is a request to save a non-safety-related log while saving a safety-related log, the safety-related log can be preferentially saved.

  Here, when the size of the log requesting storage to the data write tasks 29 and 30 from each task 24, 26 and 28 exceeds the size that can be transmitted at one time by inter-task communication, Each task 24, 26, 28 divides the log and transmits it by dividing it into a plurality of log storage request data. Hereinafter, the process at that time will be described with reference to FIGS.

  In this case, the data write task 30 receives a plurality of log storage request data in S50. This is performed by continuously calling system calls for receiving the log storage request data described above. Here, the number of times log storage request data is received can be specified by including in the first log storage request data information indicating how many times the log has been transmitted. Then, the data write task 30 locks the mutex when receiving the last log storage request data (S51). Then, EEPROM control processing (S52) is performed by combining the logs included in each of the received plurality of log storage request data as one log.

  On the other hand, when the log of the safety-related task is divided, the data write task 29 locks the mutex (S48) when the first log storage request data is received (S48), and the subsequent Log storage request data to be received. The data write task 29 also performs the EEPROM control process (S49) by combining the logs included in each of the received plurality of log storage request data as one log.

  By doing so, even if dispatch to the data write task 30 occurs before the data write task 29 receives all the log storage request data, it is shown in FIG. As described above, the data write task 30 waits for the mutex to be locked, and the control returns to the data write task 29 again. That is, even if there is a request to save a non-safety-related log while saving a safety-related log, the safety-related log can be preferentially saved.

  Also, if dispatch to the data write task 29 occurs before the data write task 30 receives all the log storage request data, the mutex is still locked by the data write task 30. Not. Therefore, the data write task 29 can lock the mutex and save the log. In other words, according to this, even when there is a request to save a safety-related log during the process of saving a non-safety-related log, it is possible to preferentially save the safety-related log. It becomes.

  In the above description, the case where a mutex is used as the mechanism for locking the EEPROM 14 is exemplified, but the present invention is not limited to this. As a mechanism for locking the EEPROM 14, an arbitrary lock mechanism such as a mutex, a semaphore, or a spin lock may be used.

  As described above, in the present embodiment, when a safety-related task log is stored and there is a data storage request from a safety-related task, the non-safety-related task Even when there is a data storage request, a log of the safety-related task is stored in the EEPROM 14 in response to the data storage request from the safety-related task. According to this, it is possible to preferentially store a safety-related task log having a high priority in the EEPROM 14. That is, data of a specific task can be preferentially saved.

  Here, if both data sent from safety-related tasks and data sent from non-safety-related tasks are stored in the data queue, the data sent first will be received first. Will be. In the data queue, it is not possible to wait for data received from safety-related tasks with high priority first. On the other hand, in the present embodiment, different data write tasks are prepared according to the priority of data, and the data write task for storing high priority data is preferentially operated. .

  According to this, it is possible to preferentially store safety-related task data with high priority at a low cost by using a data queue (intertask communication) and a multitask mechanism.

<Other embodiments of the invention>
In the present embodiment, the case where the tasks belonging to each of the TPs are the safety monitoring task 24, the normal control task 26, and the safety control task 28, respectively, is illustrated, but the types of tasks are not limited thereto. The present invention is not limited to the safety monitoring task 24, the normal control task 26, and the safety control task 28, and may have a task for executing an arbitrary process related to control of other control targets.

  For example, you may make it have the tasks 31-33 as shown in FIG. In this case, the safety control device needs to have an application corresponding to the tasks 31 to 33 in place of the applications 101 to 103. However, since this point is obvious, illustration and description are omitted. In FIG. 11, the data write tasks 29 and 30 are not shown.

  The supervisory control task 31 controls the control target. Specifically, the supervisory control task 31 controls the actuator to be controlled based on command values from the normal control task 32 and the safety control task 33. The normal control task 32 performs a control calculation for causing the control target to perform a normal function / operation. Specifically, the normal control task 32 calculates an actuator command value by performing control calculation of the actuator in normal control. The normal control task 32 outputs the calculated command value to the monitoring control task 31. The safety control task 33 performs a control calculation determined to ensure functional safety. Specifically, the safety control task 33 performs actuator control calculation in safety control to calculate an actuator command value. The safety control task 33 outputs the calculated command value to the monitoring control task 31. The supervisory control task 31 controls the actuator based on the command value output from the normal control task 32 or the safety control task 33.

  Furthermore, the monitoring control task 31 acquires a sensor value from the sensor to be controlled. The monitoring control task 31 outputs the acquired sensor value to the normal control task 32 and the safety control task 33. Each of the normal control task 32 and the safety control task 33 may perform actuator control calculation based on the sensor value output from the monitoring control task 31. The command value and the sensor value between the tasks 31 to 33 may be exchanged by inter-task communication, and an area provided in the execution memory 11 that can be shared and accessed by the tasks 31 to 33. Alternatively, this may be performed via a shared memory.

  In the example of FIG. 11, the monitoring control task 31 and the safety control task 33 perform processing related to ensuring the functional safety of the controlled object, such as monitoring of the controlled object and control calculation determined to ensure functional safety. A task to be executed. On the other hand, the normal control task 32 is a task that executes processing related to control of other control targets. Therefore, the supervisory control task 31 and the safety control task 33 are safety-related tasks, and the normal control task 32 is a non-safety-related task.

  In addition, for example, you may make it have the tasks 34-36 as shown in FIG. In this case, the safety control device needs to have applications corresponding to the tasks 34 to 36 instead of the applications 101 to 103. However, since this point is obvious, illustration and description are omitted. In FIG. 12, the illustration of the data write tasks 29 and 30 is omitted.

  The monitoring task 34 acquires a sensor value from the sensor to be controlled. This sensor includes a posture sensor for detecting the posture of the control target as described above. The example demonstrated here demonstrates the case where it applies to the traveling apparatus which a person can board as a control object. In this case, the movement of the center of gravity by the monitoring task 34 and the passenger can be detected by the posture sensor. The monitoring task 34 outputs the acquired sensor value to an HMI (Human Machine Interface) task 36.

  Based on the sensor value output from the monitoring task 34, the HMI task 36 performs control calculation of the actuator to be controlled, and calculates an actuator command value. The HMI task 36 outputs the calculated command value to the control task 35. The control task 35 controls the actuator based on the command value output from the HMI task 36. The command value and the sensor value between the tasks 34 to 36 may be exchanged by inter-task communication, and an area provided in the execution memory 11 that can be shared and accessed by the tasks 34 to 36. Alternatively, this may be performed via a shared memory.

  In the example of FIG. 12, the monitoring task 34, the HMI task 36, and the control task 35 monitor the control target, perform control calculation according to the control target, and control the control target based on the control calculation result. Execute processing related to ensuring functional safety. Therefore, each of the monitoring task 34, the HMI task 36, and the control task 35 is a safety-related task. In this case, a task that executes processing related to control of another control target belonging to a TP (not shown) other than TP1 to TP3 is a non-safety related task.

  Here, according to the configuration described with reference to FIG. 12, it is possible to realize an HMI in which a control target is controlled in accordance with a passenger's operation. For example, it is possible to perform control such that the control object moves back and forth when the passenger moves the center of gravity back and forth, and the control object turns left and right when the passenger moves the center of gravity left and right. The same can be said for the example described in the embodiment and FIG. Specifically, the normal control task 26 and the safety control task 28, or the normal control task 32 and the safety control task 33 perform the same control according to the sensor value acquired by the safety monitoring task 24 or the monitoring control task 31. Thus, HMI can be realized.

  In addition, as a traveling apparatus, it can also be set as the coaxial two-wheeled vehicle of standing up riding. In this case, the wheel rotates by controlling the actuator. Further, the safety control device itself may be mounted on the control target.

  Furthermore, the present invention is not limited to the above-described embodiments, and various modifications can be made without departing from the gist of the present invention described above.

  In the present embodiment, the case where the OS has TP1 to TP3 is illustrated, but the type and number of TPs are not limited to this. The scheduling pattern is not limited to that exemplified in the present embodiment.

  In the present embodiment, the case where the number of tasks is five is exemplified, but the number of tasks is not limited to this. For example, in the present embodiment, the case where there are three TPs, TP1 to TP3, is exemplified, but the number of TPs may be other than three and each TP may have an arbitrary number of tasks. Good.

  In the present embodiment, the multitask OS adopting time partitioning is exemplified, but the present invention is not limited to this. The present invention can also be applied to a multitasking OS that does not employ time partitioning.

  In this embodiment, the case of executing a non-safety related task storing a log and a safety related task storing a log having a higher priority than the log is illustrated, but the present invention is not limited thereto. I can't. Any information processing apparatus that executes a task for storing data and a task for storing data having a higher priority than the data can be applied in the same manner. That is, the target data in this embodiment is not limited to a log. Further, as long as tasks store data of different priorities, the classification is not limited to safety-related systems and non-safety-related systems.

1 Safety Control Device 10 Processor 11 Execution Memory 12 I / O Port 13 Nonvolatile Memory 14 EEPROM
15 Reset Circuit 20 Microcontroller 21 Partition Scheduler 22 Scheduling Tables 23, 25, 27 Task Scheduler 24 Safety Monitoring Tasks 26, 32 Normal Control Tasks 28, 33 Safety Control Tasks 29, 30 Data Write Task 31 Monitoring Control Task 34 Monitoring Task 35 Control task 36 HMI task 100 Operating system 101 Safety monitoring application 102 Normal control application 103 Safety control application 104, 105 Data Write application

Claims (10)

A storage unit for storing first data and second data having higher priority than the first data;
A task execution unit that schedules and executes a first task that stores the first data in the storage unit and a second task that stores the second data in the storage unit;
In response to a data storage request from the first task, the first data is stored in the storage unit instead of the first task, and in response to a data storage request from the second task, Data storage control for storing the second data in the storage unit instead of the second task,
The data storage control unit, when storing the second data, when there is a data storage request from the second task, there is a data storage request from the first task, In response to a data storage request from the second task, the second data is stored in the storage unit.
Information processing device. The task execution unit further includes a first data write task for storing the first data in the storage unit instead of the first task, and a data storage request from the second task, The second data writing task for storing the second data in the storage unit instead of the second task is scheduled and executed, thereby functioning as the data storage control unit,
When the first data write task stores the first data in the storage unit, regardless of whether there is a data storage request from the first task, the first data write task transitions to a wait state,
When the second data write task stores the second data in the storage unit and there is a data storage request from the second task, the second data write task does not transition to a wait state, In response to a storage request, the second data is stored in the storage unit.
The information processing apparatus according to claim 1. The data storage request is transmitted via a message queue,
When the second data write task stores the second data in the storage unit and can receive a data storage request from the second task from the message queue, the second data write task shifts to a wait state. Without storing the second data in the storage unit in response to the data storage request,
The information processing apparatus according to claim 2. The second data write task has a higher priority than the first data write task;
The information processing apparatus according to claim 2 or 3. The first data write task locks the storage unit before storing the first data in the storage unit, and stores the data from the first task when the first data is stored. Regardless of whether there is a request, the storage unit is unlocked,
The second data write task locks the storage unit before storing the second data in the storage unit, and stores the data from the second task when the second data is stored. Unlocking the storage when there is no request;
The information processing apparatus according to any one of claims 2 to 4. In the data storage request, the first task or the second task requests the first data write task or the second data write task to store the first data or the second data. Contains data,
When each of the first task and the second task cannot include the first data or the second data in one data storage request, the first data or the second task Are divided into a plurality of the data storage requests and transmitted,
The first data write task locks the storage unit when receiving the last data storage request among the plurality of data storage requests,
The second data write task locks the storage unit when receiving a first data storage request among the plurality of data storage requests.
The information processing apparatus according to claim 5. The task execution unit indicates scheduling contents of a plurality of time partitions including any of the first task, the second task, the first data write task, and the second data write task. Scheduling and executing the first task, the second task, the first data write task, and the second data write task according to scheduling information;
The first data write task and the second data write task are included in at least the same time partition;
The information processing apparatus according to claim 2. The storage unit includes an area in which the first data is stored and an area in which the second data is stored,
The data storage request includes information indicating an address for storing the first data or the second data in the storage unit,
The data storage control unit responds to the first data storage request when the address indicated by the data storage request from the first task is included in the area where the second data is stored. Deter storage of the first data;
The information processing apparatus according to any one of claims 1 to 7. The information processing apparatus is a control apparatus that controls a control target,
The second task stores a log relating to an abnormality detected in the information processing apparatus as the second data,
The first task executes processing related to control of the other control target, and stores a log related to the processing as the first data.
The information processing apparatus according to any one of claims 1 to 8. A first task for storing the first data in a storage unit storing first data and second data having a higher priority than the first data; and An execution start step for scheduling and starting execution of a second task for storing second data;
A first data storage step of storing the first data in the storage unit in place of the first task in response to a data storage request from the first task;
A second data storage step of storing the second data in the storage unit in place of the second task in response to a data storage request from the second task,
In the second data storage step, when there is a data storage request from the second task when the second data is stored, there is a data storage request from the first task. Even if there is, the second data is stored in the storage unit in response to a data storage request from the second task.
Data storage method.

Images