Information processing apparatus and method for starting information processing apparatus

Abstract

To provide a robot control device, its starting method, and a robot system capable of starting even if a part of authentication processing cannot be performed, and capable of minimizing downtime.SOLUTION: A first control unit having a startup program execution function, a second control unit having a function of generating a trajectory of a robot arm, and a storage unit that stores a first program including a steady startup command and a limited startup command, and a second program for starting up the second control unit, the first control unit includes a program reading unit configured to read the first program and the second program from the storage unit, a program authentication unit configured to perform overall authentication processing of authenticating the first program and the second program and individual authentication processing of authenticating only the first program when the overall authentication cannot be performed, and a program execution unit configured to execute the limited activation command included in the first program authenticated in the individual authentication processing.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present invention relates to a robot controller, a method for starting a robot controller, and a robot system. [Background technology]

[0002] Patent Document 1 discloses an industrial robot equipped with a robot arm and a controller for controlling the robot arm. This industrial robot has a storage means for storing an initialization program required to start up a CPU (Central Processing Unit) equipped in the controller.

[0003] It is known that secure boot is generally performed when a CPU is started. Secure boot is a function that verifies that the program itself used to start the CPU has not been tampered with before executing the boot program. This type of secure boot is also required for industrial robot controllers. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Laid-Open No. 1999-099492 Summary of the Invention [Problem to be solved by the invention]

[0005] When performing a secure boot with the controller described in Patent Document 1, if part of the firmware held by the controller cannot be authenticated, a problem arises in that the CPU cannot be started even if there are no problems with the controller's communication functions or program execution functions. [Means for solving the problem]

[0006] A robot control device according to an application example of the present invention includes: A robot control device for controlling the operation of a robot having a robot arm, a first control unit having a boot program execution function; A second control unit having a function of generating a trajectory of the robot arm; a storage unit that stores a first program including a steady startup command for starting the first control unit in a steady startup mode and a limited startup command for starting the first control unit in a limited startup mode that limits the functions of the first control unit compared to the steady startup mode, and a second program for starting the second control unit; Equipped with The first control unit is a program reading unit that reads the first program and the second program from the storage unit; a program authentication unit that performs an overall authentication process to authenticate the first program and the second program read by the program reading unit, and an individual authentication process to authenticate only the first program when authentication cannot be performed in the overall authentication process; a program execution unit that, if authentication is successful in the overall authentication process, executes the steady startup command included in the first program to start up the first control unit, and, if authentication is not successful in the overall authentication process, executes the limited startup command included in the first program authenticated in the individual authentication process to start up the first control unit; The present invention is characterized by having the following.

[0007] A method for starting a robot control device according to an application example of the present invention includes: a first control unit having a boot program execution function; a second control unit having a function of generating a trajectory of the robot arm; a storage unit that stores a first program including a steady startup command for starting the first control unit in a steady startup mode and a limited startup command for starting the first control unit in a limited startup mode that limits the function of the first control unit compared to the steady startup mode, and a second program for starting the second control unit; A method for activating a robot controller comprising: reading the first program and the second program from the storage unit; performing an overall authentication process for authenticating the first program and the second program; a step of executing the steady start-up command included in the first program to start up the first control unit and executing the second program to start up the second control unit when authentication is successful in the overall authentication process; performing an individual authentication process for authenticating only the first program when authentication has not been successful in the overall authentication process; a step of starting up the first control unit by executing the restricted start-up command included in the first program authenticated in the individual authentication process; The present invention is characterized by having the following.

[0008] A robot system according to an application example of the present invention includes: A robot control device according to an application example of the present invention; the robot having the robot arm; The present invention is characterized by comprising: [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a conceptual diagram illustrating a robot system according to an embodiment. [Figure 2] FIG. 2 is a block diagram showing a hardware configuration of the control device shown in FIG. [Figure 3] 3 is a functional block diagram showing functions of the control device shown in FIG. 2. FIG. [Figure 4] 3 is a diagram showing the file structure of the entire firmware stored in the memory card of FIG. 2. FIG. [Figure 5] This is a memory map showing the programs and the like stored in the main memory and non-volatile memory after the entire firmware shown in FIG. 4 is copied to the main memory and then expanded. [Figure 6] 10 is a flowchart illustrating a method for starting up a robot control device according to an embodiment. [Figure 7] FIG. 10 is a diagram showing the file structure of the entire firmware stored in a memory card included in a control device according to a first modified example. [Figure 8] FIG. 10 is a block diagram showing the hardware configuration of a control device included in a robot system according to a second modified example. DETAILED DESCRIPTION OF THE INVENTION

[0010] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS A robot control device, a method for starting a robot control device, and a robot system according to the present invention will be described in detail below with reference to preferred embodiments shown in the accompanying drawings.

[0011] 1.Robot System First, a robot system according to an embodiment will be described. FIG. 1 is a conceptual diagram showing a robot system 1 according to an embodiment.

[0012] The robot system 1 shown in FIG. 1 includes a robot 100, a control device 200 (a robot control device according to the embodiment), a teaching pendant 300, a personal computer 350, and a display unit 360.

[0013] 1.1.Robots The robot 100 shown in FIG. 1 includes a base 120 and a robot arm 130. The robot arm 130 includes six arms connected in order from the base 120 side, and six joints J1 to J6 that connect the base 120 to the arms and between the arms themselves. Of the six joints J1 to J6 shown in FIG. 1, three joints J2, J3, and J5 are bending joints, and the other three joints J1, J4, and J6 are torsion joints. Each of the joints J1 to J6 includes a motor as a driving source and an encoder for detecting the amount of rotation of the motor, i.e., the position information of the motor, although not shown. In this specification, the motor and the encoder are collectively referred to as a servo motor. A control point that indicates the position of the robot arm 130 and is the object of control is provided at the tip of the robot arm 130.

[0014] In this embodiment, a six-axis vertical articulated robot is exemplified as the robot 100, but the number of axes is not particularly limited and may be more or less than six. Furthermore, the robot 100 may be a horizontal articulated robot, a dual-arm robot, or a robot of another type.

[0015] An arm end 132 is provided at the tip of the robot arm 130, i.e., the end of the robot arm 130 opposite the base 120. A force sensor 150 and an end effector 160 are attached to the arm end 132 in this order. The force sensor 150 is a sensor that detects the force applied to the end effector 160. Examples of the force sensor 150 include sensors that detect the magnitude of a force parallel to three mutually perpendicular detection axes and the magnitude of a torque around the three detection axes. The end effector 160 is detachably attached. Examples of the end effector 160 include a hand that grips a workpiece and a suction tool that sucks a workpiece.

[0016] 1.2.Control Device FIG. 2 is a block diagram showing the hardware configuration of the control device 200 shown in FIG. The control device 200 (robot control device) shown in Fig. 2 includes a main board 220 (first control unit), a first sub-board 240 (second control unit), and a second sub-board 260. These boards are capable of communicating with each other via a communication interface 280. The communication interface is a transmission path for transmitting data, and is, for example, a serial communication interface such as PCI Express (registered trademark). The control device 200 also includes a storage unit 290 that stores a startup program.

[0017] 1.2.1.Main board The main board 220 shown in FIG. 2 includes a printed wiring board 221, a processor 222, a system bus 226, a main memory 228, a nonvolatile memory 230, an input / output port 232, and a memory card interface 234.

[0018] The printed wiring board 221 includes an insulating substrate and wiring, and electrically connects the attached electronic components to each other.

[0019] The processor 222 executes a program loaded in the main memory 228 to realize various functions of the main board 220. Examples of the processor 222 include a microprocessor and a processor circuit including the core 223 and cache memory 224 shown in FIG. 2. Examples of the microprocessor and core include a CPU (Central Processing Unit) and a DSP (Digital Signal Processor). Examples of the processor circuit include an SoC (System on a Chip) and an SiP (System in a Package). In this embodiment, the hardware configuration of the processor 222 is an SoC. This allows for miniaturization, power saving, and cost reduction of the processor 222. Furthermore, the processor 222 is easier to manufacture.

[0020] The system bus 226 is a transmission path that connects and enables data communication between the processor 222, the main memory 228, and the non-volatile memory 230.

[0021] The main memory 228 temporarily stores programs to be executed by the processor 222, data to be read, etc. The main memory 228 may be, for example, a volatile memory such as a DRAM (Dynamic Random Access Memory).

[0022] The nonvolatile memory 230 stores programs to be executed by the processor 222, data to be read, etc. Examples of the nonvolatile memory 230 include an EEPROM (Electrically Erasable Programmable Read-Only Memory) and a ROM (Read-Only Memory). Note that the nonvolatile memory 230 may be an external memory.

[0023] The input / output port 232 is an interface for communication between the main board 220 and other devices. Examples of the input / output port 232 include a digital input / output port such as a USB (Universal Serial Bus), an Ethernet (registered trademark) port, and a video output port.

[0024] The memory card interface 234 is an interface that allows a memory card 236 (storage medium) to be attached and detached. The memory card interface 234 can read data stored in the attached memory card 236 and write data to the attached memory card 236. The memory card 236 stores the entire firmware 400, which will be described later. Examples of the memory card 236 include various storage media such as an SD card and a USB memory. Preferably, this storage medium is rewritable and nonvolatile. This allows the memory card 236 to be easily replaced with one storing the correct entire firmware 400, thereby quickly resolving problems such as when the entire firmware 400 on the memory card 236 cannot be read or when the entire firmware 400 can be read but is corrupted. In particular, if the entire firmware 400 is stored on the main board 220 or the first sub-board, replacement is difficult and time-consuming due to the complex installation and handling. However, the memory card 236 is detachable and can be quickly replaced, minimizing downtime of the robot system 1.

[0025] The memory card 236 inserted into the memory card interface 234 constitutes the aforementioned storage unit 290. The storage unit 290 does not have to be removable as in this embodiment. The storage unit 290 may be mounted on the main board 220 or provided externally.

[0026] 1.2.2. First sub-board The first sub-board 240 shown in FIG. 2 includes a printed wiring board 241, a processor 242, a system bus 246, and a main memory 248.

[0027] The printed wiring board 241 includes an insulating substrate and wiring, and electrically connects the attached electronic components to each other.

[0028] The processor 242 executes a program deployed in the main memory 248 to realize various functions of the first sub-board 240. Examples of the processor 242 include a microprocessor and a processor circuit including a core 243 and a cache memory 244 shown in FIG. 2. In this embodiment, the hardware configuration of the processor 242 is an SoC. This allows for miniaturization, power saving, and cost reduction of the processor 242. Furthermore, the processor 242 is easier to manufacture.

[0029] The system bus 246 enables communication between the processor 242 and the main memory 248. The main memory 248 temporarily stores programs to be executed by the processor 242, data to be read, and the like.

[0030] 1.2.3. Second sub-board The second sub-board 260 shown in FIG. 2 includes a printed wiring board 261, a processor 262, a system bus 266, and a main memory 268.

[0031] The printed wiring board 261 includes an insulating substrate and wiring, and electrically connects the attached electronic components to each other.

[0032] The processor 262 executes a program loaded in the main memory 268 to realize various functions of the second sub-board 260. The processor 262 may be, for example, a microprocessor or a processor circuit including the core 263 and FPGA 264 shown in FIG. 2. The FPGA is a Field Programmable Gate Array. In this embodiment, the hardware configuration of the processor 262 is an SoC. This allows the processor 262 to be made smaller, consume less power, and cost less. Furthermore, the processor 262 can be manufactured more easily.

[0033] The system bus 266 enables communication between the processor 262 and the main memory 268. The main memory 268 temporarily stores programs to be executed by the processor 262, data to be read, and the like.

[0034] Although an example of the hardware configuration of the control device 200 has been described above, the hardware configuration is not limited to this. For example, the second sub-board 260 may be omitted, or another sub-board may be added.

[0035] 1.2.4. Functional Section FIG. 3 is a functional block diagram showing the functions of the control device 200 shown in FIG. 3 has, as functional units, an interface control unit 312, a language analysis unit 314, an input / output control unit 316, an interrupt control unit 318, a startup processing unit 320, and a display control unit 331. Each of these functional units is realized by hardware including a processor 222.

[0036] The interface control unit 312 (I / F control unit) controls communication between the main board 220, the first sub-board 240, and the second sub-board 260, for example.

[0037] The language analysis unit 314 reads and analyzes the robot language that describes the operation of the robot 100. The language analysis unit 314 receives the program for the robot 100 from the personal computer 350 via the input / output control unit 316 (described later), analyzes this program, and acquires target position information for the robot arm 130. The target position information is information about the target position P1, which is the target point to which the control point of the robot arm 130 is to be moved, and is, for example, data indicating the coordinates of the target position P1. In addition to this, information such as the distance that the control point of the robot arm 130 moves from the current position to the target position P1 may also be used.

[0038] The input / output control unit 316 (I / O control unit) controls connections with the teaching pendant 300, personal computer 350, and other peripheral devices connected to the main board 220.

[0039] The interrupt control unit 318 controls processing (interrupt processing) for branching from a currently running program to another program.

[0040] The startup processing unit 320 has a function of reading and executing a startup program stored in the storage unit 290. Execution of the startup program starts up the main board 220. The startup processing unit 320 has a program reading unit 322, a program authentication unit 324, a program expansion unit 326, a program execution unit 328, and a program update unit 330 (communication unit).

[0041] Fig. 4 is a diagram showing the file structure of the entire firmware 400 stored in the memory card 236 of Fig. 2. The program reading unit 322 reads out the entire firmware 400 (startup program) stored in the memory card 236. The program reading unit 322 then copies the read entire firmware 400 to a temporary storage area in the main memory 228.

[0042] 5 is a memory map showing the programs and the like stored in the main memory 228 and the non-volatile memory 230 after the entire firmware 400 shown in FIG. 4 is copied to the main memory 228 and then expanded. The entire firmware 400 is usually in binary format, but may also be in text format.

[0043] The entire firmware 400 shown in Figure 4 includes an overall header 401, a header 411 for the main board, firmware 412 for the main board (first program), a header 421 for the first sub-board, firmware 422 for the first sub-board (second program), a header 431 for the second sub-board, and firmware 432 for the second sub-board.

[0044] The overall header 401 includes information regarding the firmware for the main board 412, the firmware for the first sub-board 422, and the firmware for the second sub-board 432 as a whole, specifically, the header for the main board 411, the header for the first sub-board 421, and the header for the second sub-board 431.

[0045] 4 shows an example of the configuration of the main board header 411. The main board header 411 includes a size 414 and an authentication code 415. The size 414 is the data size of the main board firmware 412. The authentication code 415 is a code for verifying the authenticity of the main board firmware 412. Based on this information, the program authentication unit 324 (described later) performs authentication processing.

[0046] The firmware 412 for the main board is a boot program that starts up the main board 220. The firmware 422 for the first sub-board is a boot program that starts up the first sub-board 240. The firmware 432 for the second sub-board is a boot program that starts up the second sub-board 260.

[0047] The program authentication unit 324 authenticates the entire main board firmware 412, the first sub-board firmware 422, and the second sub-board firmware 432 read by the program reading unit 322 based on the overall header 401. This type of authentication process is referred to as "overall authentication process" in this specification.

[0048] Furthermore, if for some reason the entire firmware cannot be authenticated in the overall authentication process, the program authentication unit 324 authenticates only the main board firmware 412. This type of authentication process is referred to as "individual authentication process" in this specification.

[0049] Note that authentication refers to the program authentication unit 324 verifying the authenticity of each piece of firmware 412, 422, and 432 based on the information contained in the overall header 401 and each header 411, 421, and 431. In this specification, the result of this verification is said to be "authenticated."

[0050] Furthermore, the nonvolatile memory 230 shown in FIG. 5 stores spare firmware 506 for the main board (third program).

[0051] The program expansion unit 326 expands the portion of the entire firmware 400 that corresponds to the authenticated main board firmware 412 into an executable area of ​​the main memory 228 provided in the main board 220. In addition, the program expansion unit 326 expands the portion of the entire firmware 400 that corresponds to the authenticated first sub-board firmware 422 into the main memory 248 provided in the first sub-board 240, and expands the portion that corresponds to the authenticated second sub-board firmware 432 into the main memory 268 provided in the second sub-board 260.

[0052] The program execution unit 328 executes the main board firmware 412 that has been authenticated in the individual authentication process, thereby starting up the main board 220.

[0053] The program update unit 330 (communication unit) has a communication function and acquires a replacement program from an external device. Then, the replacement program is used to update at least a portion of the entire firmware 400 stored in the memory card 236. An example of the update source is a personal computer 350.

[0054] The display control unit 331 controls the operation of the display unit 360. This allows text, images, and the like to be displayed on the display unit 360 to notify the user.

[0055] These functional units of the main board 220 are merely examples, and some may be omitted, some may be on other boards, or other functional units may be added.

[0056] 3 has, as functional units, a trajectory generation unit 332 and a startup processing unit 336. Each of these functional units is realized by hardware including a processor 242.

[0057] The trajectory generation unit 332 generates a trajectory for when the robot arm 130 is driven based on the target position information received from the main board 221 .

[0058] The startup processing unit 336 executes the authenticated first sub-board firmware 422. This causes the first sub-board 240 to start up.

[0059] These functional units of the first sub-substrate 240 are merely examples, and some may be omitted, or other functional units may be added.

[0060] 3 has, as functional units, a servo processing unit 342 and a startup processing unit 346. Each of these functional units is realized by hardware including a processor 262. The servo processing unit 342 controls the operation of the servo motors provided in the robot 100 .

[0061] The startup processing unit 346 executes the authenticated second sub-board firmware 432. This causes the second sub-board 260 to start up.

[0062] These functional parts of the second sub-substrate 260 are just an example, and some may be omitted, or other functional parts may be added.

[0063] 1.3.How to start the control device Next, a method for starting up the robot control device according to the embodiment will be described. 6 is a flowchart for explaining a method for starting up the robot control device according to the embodiment. In the following explanation, a method for starting up the control device 200 described above will be explained as an example.

[0064] The startup method of the robot control device shown in FIG. 6 includes steps S102 to S118. After the control device 200 is powered on, the process proceeds to step S102. In step S102, the program reading unit 322 of the startup processing unit 320 performs a process of reading the entire firmware 400 stored in the memory card 236. As shown in FIG. 4, the entire firmware 400 includes an entire header 401, a main board header 411, main board firmware 412 (first program), a first sub-board header 421, first sub-board firmware 422 (second program), a second sub-board header 431, and second sub-board firmware 432.

[0065] In step S104, the program reading unit 322 determines whether or not the entire firmware 400 was able to be read. If it was able to be read, the process proceeds to step S106. If it was not able to be read, the process proceeds to step S118. If it was not able to be read, the program reading unit 322 writes the result, that is, the processing result indicating that it was not able to be read, for example, text information such as "failure(1)", to the main memory 228. Note that the recording method is not limited to this.

[0066] In step S106, the program reading unit 322 copies the read entire firmware 400 to a temporary storage area in the main memory 228 of the main board 220. The program authentication unit 324 then attempts the overall authentication process and determines whether authentication is successful. In the overall authentication process, the authenticity of the read firmware for the main board 412, firmware for the first sub-board 422, and firmware for the second sub-board 432 is verified based on the overall header 401. The overall header 401 contains information necessary for this verification. If authentication is successful, the process proceeds to step S108. If authentication is unsuccessful, the process proceeds to step S112. If authentication is unsuccessful, the program authentication unit 324 writes the result, i.e., the processing result indicating that authentication was unsuccessful in the overall authentication process, for example, text information such as "failure(2)", to the main memory 228. Note that the recording method is not limited to this.

[0067] In step S106, instead of authenticating the entire firmware 400, at least one of the first sub-board firmware 422 and the second sub-board firmware 432 may be authenticated.

[0068] In step S108, the program deployment unit 326 deploys the authenticated firmware 412 for the main board in the main memory 228 provided in the main board 220. The program deployment unit 326 also deploys the authenticated firmware 422 for the first sub-board in the main memory 248 provided in the first sub-board 240. The program deployment unit 326 also deploys the authenticated firmware 432 for the second sub-board in the main memory 268 provided in the second sub-board 260.

[0069] In step S110, the program execution unit 328 of the startup processing unit 320 executes the authenticated firmware 412 for the main substrate. This causes the main substrate 220 to start up. Furthermore, the startup processing unit 336 of the first sub-substrate 240 executes the authenticated firmware 422 for the first sub-substrate. This causes the first sub-substrate 240 to start up. Furthermore, the startup processing unit 346 of the second sub-substrate 260 executes the authenticated firmware 432 for the second sub-substrate. This causes the second sub-substrate 260 to start up. Through step S110 as described above, the control device 200 starts up normally, as shown in FIG. 6.

[0070] 4 includes a steady startup command 413a for starting the main board 220 in steady startup mode, and a restricted startup command 413b for starting the main board 220 in restricted startup mode (update mode). In step S110, the program execution unit 328 checks whether or not text information "failure(1)" or "failure(2)" exists in the main memory 228. In step S110, this text information does not exist, so the program execution unit 328 executes the steady startup command 413a and starts the main board 220 in steady startup mode.

[0071] The restricted startup mode is a startup mode that, compared to the steady startup mode, restricts some of the functions of the control device 200. Specifically, the functions are restricted to updating at least a portion of the entire firmware 400 (described later) and displaying specific information on the display unit 360.

[0072] In step S112, the program authentication unit 324 attempts individual authentication processing only for the main board firmware 412 and determines whether authentication is successful. In the individual authentication processing, the authenticity of the main board firmware 412 is verified based on the main board header 411. The main board header 411 contains the above-mentioned size 414 and authentication code 415, etc., as information necessary for this verification. If authentication is successful, the process proceeds to step S114. If authentication is unsuccessful, the process proceeds to step S118. Note that if authentication is unsuccessful, the program authentication unit 324 may also write the result, i.e., the processing result indicating that authentication was unsuccessful in the individual authentication processing, to the main memory 228.

[0073] In step S114, the program loading unit 326 loads the authenticated main board firmware 412 into the main memory 228.

[0074] In step S116, the program execution unit 328 executes the authenticated main board firmware 412. This starts up the main board 220. Note that in step S116, the program execution unit 328 also checks whether or not the main memory 228 contains text information such as "failure (1)" or "failure (2)." In step S116, since this text information exists, the program execution unit 328 executes the restricted startup command 413b, and starts up the main board 220 in restricted startup mode. By performing step S116 in this manner, the control device 200 starts up in update mode, as shown in FIG. 6.

[0075] In step S118, the program reading unit 322 reads out spare main board firmware 506 stored in the nonvolatile memory 230 shown in Fig. 5. The spare main board firmware 506 is equivalent to the main board firmware 412 described above, and includes a steady startup command 507a similar to the steady startup command 413a described above, and a restricted startup command 507b similar to the restricted startup command 413b described above. The program deploying unit 326 then deploys the read spare main board firmware 506 into the main memory 228. After that, the process proceeds to step S116.

[0076] Step S118 is executed when the entire firmware 400 cannot be read in step S104 or when authentication cannot be performed by the individual authentication process in step S112. The former case may occur due to damage or tampering with the entire firmware 400. The latter case may occur due to damage or tampering with the main board header 411 or the main board firmware 412.

[0077] As described above, the control device 200 starts up in normal startup or update mode. According to this flow, even if normal startup is not possible, the control device 200 can start up in update mode. Therefore, for example, even if the first sub-board firmware 422 or the second sub-board firmware 432 of the entire firmware 400 is damaged or tampered with, the control device 200 can start up. This allows the user to quickly identify the cause of the malfunction after startup or start work such as updating the firmware. As a result, downtime of the robot system 1 can be kept to a minimum.

[0078] Furthermore, even in update mode, the control device 200 can be started, which enables the start-up processing unit 320 to operate, and therefore the success or failure of authentication in the authentication process can be recorded. This makes it easy to identify the cause of the malfunction, thereby preventing unnecessary repair work, etc. For example, by reading the text information "failure(1)" or "failure(2)" written to the main memory 228, the user can understand whether there was a read error from the memory card 236 or whether authentication was not successful in the overall authentication process.

[0079] When the control device 200 is started in update mode, the control device 200 may have a function to display the result on the display unit 360 as information to inform the user. For example, when the text information "failure (1)" is written to the main memory 228, the display unit 360 may display a message indicating that a read error from the storage unit 290 has occurred. When the text information "failure (2)" is written to the main memory 228, the display unit 360 may display a message indicating that authentication has failed in the overall authentication process. This allows the user to accurately understand that there is a problem with the control device 200. As a result, the user can promptly begin work to resolve the problem.

[0080] Furthermore, even in update mode, the control device 200 can be started, which enables the startup processing unit 320 to operate, allowing at least a portion of the entire firmware 400 stored in the memory card 236 to be updated as necessary. In other words, when started in update mode, the control device 200 makes at least a portion of the entire firmware 400 stored in the memory card 236 available for update. The update is performed, for example, by replacing a file stored in the memory card 236 with a replacement program stored in the personal computer 350. This makes it possible to quickly resolve problems such as the inability to read the entire firmware 400 or the corruption of the entire firmware 400. As a result, downtime of the robot system 1 can be minimized.

[0081] In this specification, "update" includes not only replacing a file with a newer version, but also replacing a file with an older version.

[0082] Furthermore, when the above update is executed, the display unit 360 may display a message to that effect.

[0083] Furthermore, if the program reading unit 322 is unable to read the entire firmware 400 in step S104, there is a possibility that some kind of malfunction has occurred in the memory card 236. Therefore, if the program execution unit 328 confirms text information such as "failure(1)" in the main memory 228, the display unit 360 may be configured to display information recommending that the memory card 236 be replaced.

[0084] In the above cases, the information may be recorded in a log file in addition to or instead of being displayed on the display unit 360. The log file may be created in the storage unit 290, for example.

[0085] 1.4. Effects of the embodiment As described above, the control device 200 (robot control device according to the embodiment) is a device that controls the operation of the robot 100 equipped with the robot arm 130, and includes at least a main board 220 (first control unit), a first sub-board 240 (second control unit), and a memory unit 290. The main board 220 has a communication function and a startup program execution function. The first sub-board 240 has a function of generating a trajectory of the robot arm 130. The memory unit 290 stores main board firmware 412, which includes a steady startup command 413a and a limited startup command 413b, and first sub-board firmware 422. The steady startup command 413a is a command to start the main board 220 in steady startup mode. The limited startup command 413b is a command to start the main board 220 in a limited startup mode (update mode), which limits the functions of the main board 220 compared to the steady startup mode.

[0086] The main board 220 has a program reading unit 322, a program authentication unit 324, and a program execution unit 328. The program reading unit 322 reads the entire firmware 400, including main board firmware 412 (first program) and first sub-board firmware 422 (second program), from the storage unit 290. The program authentication unit 324 performs an overall authentication process to authenticate the entire firmware 400 read by the program reading unit 322, and an individual authentication process to authenticate only the main board firmware 412 if the entire firmware 400 cannot be authenticated. If authentication is successful in the overall authentication process, the program execution unit 328 executes a steady startup command 413a included in the main board firmware 412 to start up the main board 220. If authentication is not successful in the overall authentication process, the program execution unit 328 executes a limited startup command 413b included in the main board firmware 412 authenticated in the individual authentication process to start up the main board 220.

[0087] With this configuration, for example, even if the first sub-board firmware 422 is damaged and authentication fails in the overall authentication process, the control device 200 can be started in update mode. That is, secure boot of the control device 200 is possible even in such a case. This allows the user to quickly begin work such as identifying the cause of the malfunction or updating the firmware after startup. As a result, downtime of the robot system 1 can be minimized. Furthermore, by recording whether authentication was successful in the authentication process, the cause of the malfunction can be easily identified, thereby preventing unnecessary repair work. That is, it is possible to reduce the amount of unnecessary work required to identify the cause of the malfunction or perform repairs.

[0088] The processing performance of the processor 242 provided on the first sub-board 240 and the processor 262 provided on the second sub-board 260 may be equal to or greater than the processing performance of the processor 222 provided on the main board 220, or may be less than the same. In this embodiment, even in the latter case, the overall authentication process is executed on the main board 220, so the processing speed of the overall authentication process is not affected by the processing performance of the processors 242, 262. This makes it possible to reduce the cost of the control device 200 while shortening the startup time of the control device 200.

[0089] In this embodiment, the control device 200 also includes a nonvolatile memory 230. The nonvolatile memory 230 stores spare main board firmware 506 (third program). The spare main board firmware 506 includes a steady startup command 507a that starts the main board 220 in steady startup mode, and a restricted startup command 507b that starts the main board 220 in restricted startup mode (update mode).

[0090] In the control device 200, if the main board firmware 412 (first program) cannot be authenticated in the individual authentication process, the program reading unit 322 reads the spare main board firmware 506, and the program execution unit 328 executes the restricted startup command 507b contained in the spare main board firmware 506 to start up the main board 220.

[0091] With this configuration, even if the main board firmware 412 is damaged or the like and authentication fails in the individual authentication process, the control device 200 can be started by reading the spare main board firmware 506. This allows the user to quickly begin work to identify the cause of the malfunction or update the firmware after startup. As a result, downtime of the robot system 1 can be minimized. Furthermore, by recording whether authentication was successful in the authentication process, the cause of the malfunction can be easily identified, thereby preventing unnecessary repair work, etc.

[0092] Furthermore, in this embodiment, in the control device 200, if the program reading unit 322 is unable to read the main board firmware 412 (first program), the program reading unit 322 reads the spare main board firmware 506 (third program) stored in the non-volatile memory 230, and the program execution unit 328 executes the restricted startup command 507b included in the spare main board firmware 506 to start up the main board 220.

[0093] With this configuration, even if the program reading unit 322 is unable to read the entire firmware 400, the control device 200 can be started by reading the spare main board firmware 506. This allows the user to quickly begin work such as identifying the cause of a malfunction or updating the firmware after startup. As a result, downtime of the robot system 1 can be minimized. Note that the program reading unit 322 may read only a portion of the spare main board firmware 506.

[0094] Moreover, the storage unit 290 is preferably a storage medium that is detachable from the main board 220 (first control unit), for example, a memory card 236 that is attached to the memory card interface 234.

[0095] This allows the memory card 236 to be easily replaced with one that stores the normal entire firmware 400, thereby quickly resolving problems such as when the entire firmware 400 on the memory card 236 cannot be read or can be read but is corrupted. As a result, downtime of the robot system 1 can be kept to a minimum.

[0096] Furthermore, in this embodiment, the main board 220 (first control unit) has a program update unit 330 (communication unit). When the main board 220 is started up in the restricted startup mode, the program update unit 330 acquires a replacement program from the outside and rewrites the entire firmware 400 stored in the storage unit 290. The rewriting may be the entire firmware 400, or may be a part of the entire firmware 400, for example, at least one of the main board firmware 412 (first program) and the first sub-board firmware 422 (second program).

[0097] This configuration makes it possible to quickly resolve problems such as not being able to read the entire firmware 400 or being able to read it but finding it corrupted. As a result, downtime of the robot system 1 can be kept to a minimum.

[0098] In this embodiment, the main substrate 220 (first control unit) has a display control unit 331 that controls the operation of the display unit 360. When the main substrate 220 is started up in the restricted start-up mode, the display control unit 331 causes the display unit 360 to display the result as information.

[0099] With this configuration, the user can accurately recognize that there is some kind of problem with the control device 200. As a result, the user can quickly start work to resolve the problem.

[0100] Furthermore, the startup method for the robot control device according to this embodiment includes steps S102, S106, S110, S112, and S116. In step S102, the entire firmware 400, including the main board firmware 412 (first program) and the first sub-board firmware 422 (second program), is read from the storage unit 290. In step S106, an overall authentication process is performed to authenticate the entire firmware 400. In step S110, if authentication is successful in the overall authentication process, the steady startup command 413a included in the main board firmware 412 is executed to start up the main board 220, and the first sub-board firmware 422 is executed to start up the first sub-board 240. In step S112, if authentication is not successful in the overall authentication process, an individual authentication process is performed to authenticate only the main board firmware 412. In step S116, the main board 220 starts up by executing the restricted startup command 413b contained in the main board firmware 412 authenticated in the individual authentication process.

[0101] With this configuration, even if the first sub-board firmware 422 is damaged or the like and authentication fails in the overall authentication process, the control device 200 can be started in update mode. That is, secure boot of the control device 200 is possible even in such a case. This allows the user to quickly begin work to identify the cause of the malfunction or update the firmware after startup. As a result, downtime of the robot system 1 can be minimized. Furthermore, by recording whether authentication was successful in the authentication process, the cause of the malfunction can be easily identified, thereby preventing unnecessary repair work, etc.

[0102] The robot system 1 according to this embodiment also includes a robot 100 equipped with a robot arm 130, and a control device 200 (robot control device according to this embodiment).

[0103] This configuration makes it possible to realize a robot system 1 that can enjoy the effects of the control device 200 and minimize downtime related to firmware authentication. Also, it is possible to realize a robot system 1 that can easily identify the cause of a malfunction related to firmware authentication and is less likely to require unnecessary repair work.

[0104] 1.5. First Modification Next, a control device according to a first modification will be described. FIG. 7 is a diagram showing the file structure of the entire firmware 400A stored in the memory card 236 provided in the control device according to the first modification.

[0105] The first modification will be described below, focusing on the differences from the previous embodiment, and omitting the description of the similarities. Note that in Fig. 7, the same reference numerals are used to designate the same components as those in the previous embodiment.

[0106] The file structure of the entire firmware 400A shown in Fig. 7 is a structure including a plurality of data sets 440 of update headers 441 and update firmware 442 (update programs). Specifically, in the example of the file structure shown in Fig. 7, data sets 440 are arranged between the entire header 401 and the main board header 411, between the main board firmware 412 and the first sub-board header 421, and between the first sub-board firmware 422 and the second sub-board header 431.

[0107] Update header 441 is a header for updating main board header 411, and may be the same as or different from main board header 411. Update firmware 442 is an update program for updating main board firmware 412, and may be the same as or different from main board firmware 412, for example.

[0108] In this first modified example, the storage unit 290 stores a plurality of update firmware 442 (update programs) for updating the main board firmware 412 (first program), as shown in Fig. 7. If the main board firmware 412 cannot be authenticated in the individual authentication process of step S112 described above, the program reading unit 322 reads one of the plurality of update firmware 442.

[0109] With this configuration, even if the main board firmware 412 is damaged or the like and authentication cannot be performed in the individual authentication process as a result, the update firmware 442 can be quickly read out. This makes it possible to update the main board firmware 412 deployed in the main memory 228 with the update firmware 442. As a result, the control device 200 can be started up without reading out the spare main board firmware 506 stored in the non-volatile memory 230.

[0110] 7, the data sets 440 are distributed across various locations within the file. This reduces the probability that even if one data set 440 is damaged, other data sets 440 will also be damaged. As a result, the probability that a normal data set 440 can be read out can be increased, thereby realizing a robust control device 200.

[0111] Unlike the spare main board firmware 506 stored in the non-volatile memory 230, the update firmware 442 can be upgraded as needed. Therefore, this modified example is useful in that even when the control device 200 is started in update mode, it can be started based on the latest main board firmware 412. In the first modified example as described above, the same effects as those of the above embodiment can be obtained.

[0112] 1.6. Second Variant Next, a robot system according to a second modification will be described. FIG. 8 is a block diagram showing the hardware configuration of a control device 200B included in a robot system according to the second modification.

[0113] The second modification will be described below, focusing on the differences from the previous embodiment, and omitting the description of the similarities. Note that in Fig. 8, the same reference numerals are used to designate the same components as those in the previous embodiment.

[0114] The robot system 1B shown in FIG. 8 is similar to the robot system 1 shown in FIG. 2, except that the processors 222, 242, and 262 included in the control device 200B are processor circuits including multi-cores 223B, 243B, and 263B.

[0115] 8, the processor 222 includes a multi-core 223B. The multi-core 223B includes a first core 611 and a second core 612. The first core 611 includes, for example, the language analysis unit 314 shown in FIG. 3, and the second core 612 includes, for example, the interface control unit 312, the input / output control unit 316, the interrupt control unit 318, the startup processing unit 320, and the display control unit 331 shown in FIG. 3.

[0116] 8, the processor 242 includes a multi-core 243B. The multi-core 243B includes a first core 621 and a second core 622. The first core 621 includes, for example, the trajectory generation unit 332 shown in FIG. 3, and the second core 622 includes, for example, the startup processing unit 336 shown in FIG. 3.

[0117] 8, the processor 262 includes a multi-core 263B. The multi-core 263B includes a first core 631 and a second core 632. The first core 631 includes, for example, the servo processing unit 342 shown in FIG. 3, and the second core 632 includes, for example, the startup processing unit 346 shown in FIG. 3.

[0118] The processors 222, 242, 262 are provided with multi-cores 223B, 243B, 263B, which allows the processors 222, 242, 262 to execute multiple processes in parallel, thereby improving the performance of the control device 200B while reducing power consumption and heat generation.

[0119] The number of cores included in each of the multi-cores 223B, 243B, and 263B is not particularly limited. The allocation pattern of the functional units to each core is not limited to the above example, and any pattern may be used. In the second modified example as described above, the same effects as those of the above embodiment can be obtained.

[0120] The robot control device, the activation method for the robot control device, and the robot system of the present invention have been described above based on the illustrated embodiments, but the present invention is not limited to these.

[0121] For example, the robot control device and robot system of the present invention may be such that the configuration of each part of the above-described embodiment and each of the above-described modified examples is replaced with any configuration having a similar function, or any other components may be added.

[0122] Furthermore, the method for starting up a robot control device of the present invention may be such that any desired process is added to the above-described embodiment. [Explanation of symbols]

[0123] 1...Robot system, 1B...Robot system, 100...Robot, 120...Base, 130...Robot arm, 132...Arm end, 150...Force sensor, 160...End effector, 200...Control device, 200B...Control device, 220...Main board, 221...Printed wiring board, 222...Processor, 223...Core, 223B...Multi-core, 224...Cache memory, 226...System bus, 228...Main memory, 230...Non-volatile memory, 232...Input / output port, 234...Memory card interface, 236...Memory card, 2 40...first sub-board, 241...printed wiring board, 242...processor, 243...core, 243B...multi-core, 244...cache memory, 246...system bus, 248...main memory, 260...second sub-board, 261...printed wiring board, 262...processor, 263...core, 263B...multi-core, 264...FPGA, 266...system bus, 268...main memory, 280...communication interface, 290...storage unit, 300...teaching pendant, 312...interface control unit, 314...language analysis unit, 316...input / output control unit, 31 8...Interrupt control unit, 320...Startup processing unit, 322...Program reading unit, 324...Program authentication unit, 326...Program development unit, 328...Program execution unit, 330...Program update unit, 331...Display control unit, 332...Trajectory generation unit, 336...Startup processing unit, 342...Servo processing unit, 346...Startup processing unit, 350...Personal computer, 360...Display unit, 400...Overall firmware, 400A...Overall firmware, 401...Overall header, 411...Main board header, 412...Main board firmware, 413a...Steady startup command, 413b ...Limited startup command, 414...Size, 415...Authentication code, 421...Header for first sub-board, 422...Firmware for first sub-board, 431...Header for second sub-board, 432...Firmware for second sub-board, 440...Data set, 441...Header for update, 442...Firmware for update, 506...Firmware for spare main board, 507a...Steady startup command, 507b...Limited startup command, 611...First core, 612...Second core, 621...First core, 622...Second core, 631...First core, 632...Second core, J1...Joint, J2...Joint, J3...Joint,J4... joint, J5... joint, J6... joint, S102... process, S104... process, S106... process, S108... process, S110... process, S112... process, S114... process, S116... process, S118... process,

Claims

1. A robot control device for controlling the operation of a robot having a robot arm, a first control unit having a boot program execution function; a second control unit having a function of generating a trajectory of the robot arm; a storage unit that stores a first program including a steady startup command for starting the first control unit in a steady startup mode and a limited startup command for starting the first control unit in a limited startup mode that limits functions of the first control unit compared to the steady startup mode, and a second program for starting the second control unit; Equipped with The first control unit a program reading unit that reads the first program and the second program from the storage unit; a program authentication unit that performs an overall authentication process to authenticate the first program and the second program read by the program reading unit, and an individual authentication process to authenticate only the first program when authentication cannot be performed in the overall authentication process; a program execution unit that, if authentication is successful in the overall authentication process, executes the steady startup command included in the first program to start up the first control unit, and, if authentication is not successful in the overall authentication process, executes the limited startup command included in the first program authenticated in the individual authentication process to start up the first control unit; A robot control device comprising:

2. a nonvolatile memory for storing a third program including the steady startup command and the limited startup command; If the first program cannot be authenticated in the individual authentication process, the program reading unit reads the third program, The robot control device according to claim 1 , wherein the program execution unit executes the restricted activation command included in the third program to activate the first control unit.

3. a nonvolatile memory for storing a third program including the steady startup command and the limited startup command; If the program reading unit cannot read the first program, the program reading unit reads the third program, The robot control device according to claim 1 , wherein the program execution unit executes the restricted activation command included in the third program to activate the first control unit.

4. the storage unit stores a plurality of update programs for updating the first program; The robot control device according to claim 1 , wherein the program reading unit reads one of the plurality of update programs when the first program cannot be authenticated in the individual authentication process.

5. The robot control device according to claim 1 , wherein the storage unit is a storage medium that is detachable from the first control unit.

6. the first control unit has a communication unit, 6. A robot control device as described in any one of claims 1 to 5, wherein when the first control unit is started up in the restricted start-up mode, the communication unit acquires a replacement program from the outside and rewrites at least one of the first program and the second program stored in the memory unit.

7. the first control unit has a display control unit that controls an operation of a display unit that displays information; The robot control device according to claim 1 , wherein when the first control unit is started up in the restricted start-up mode, the display control unit causes the display unit to display the result as the information.

8. a first control unit having a boot program execution function; a second control unit having a function of generating a trajectory of the robot arm; a storage unit that stores a first program including a steady startup command for starting the first control unit in a steady startup mode and a limited startup command for starting the first control unit in a limited startup mode that limits functions of the first control unit compared to the steady startup mode, and a second program for starting the second control unit; A method for activating a robot controller comprising: reading the first program and the second program from the storage unit; performing an overall authentication process for authenticating the first program and the second program; a step of executing the steady startup command included in the first program to start up the first control unit and executing the second program to start up the second control unit when authentication is successful in the overall authentication process; performing an individual authentication process for authenticating only the first program when authentication has not been successful in the overall authentication process; a step of starting up the first control unit by executing the restricted start-up command included in the first program authenticated in the individual authentication process; A method for starting a robot control device, comprising:

9. The robot control device according to any one of claims 1 to 7, the robot having the robot arm; A robot system comprising:

Images