WO2018190015A1 - 情報処理装置及び情報処理方法、並びにコンピュータ・プログラム - Google Patents

情報処理装置及び情報処理方法、並びにコンピュータ・プログラム Download PDF

Info

Publication number
WO2018190015A1
WO2018190015A1 PCT/JP2018/007518 JP2018007518W WO2018190015A1 WO 2018190015 A1 WO2018190015 A1 WO 2018190015A1 JP 2018007518 W JP2018007518 W JP 2018007518W WO 2018190015 A1 WO2018190015 A1 WO 2018190015A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
container
guest
application
proxy
Prior art date
Application number
PCT/JP2018/007518
Other languages
English (en)
French (fr)
Inventor
健太 多田
正紘 田森
隆盛 山口
Original Assignee
ソニー株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ソニー株式会社 filed Critical ソニー株式会社
Priority to EP18784792.6A priority Critical patent/EP3611618A4/en
Priority to CN201880023183.5A priority patent/CN110476152A/zh
Priority to JP2019512373A priority patent/JP7074130B2/ja
Priority to US16/493,998 priority patent/US11218535B2/en
Publication of WO2018190015A1 publication Critical patent/WO2018190015A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1438—Restarting or rejuvenating
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/656—Updates while running
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications

Definitions

  • the technology disclosed in this specification relates to an information processing apparatus and information processing method for processing an application or a program included in the application, and a computer program.
  • a robot is composed of, for example, a plurality of links and joints connecting the links, and the robot operates by driving each joint using a joint driving actuator such as a motor.
  • the automatic traveling vehicle can detect information around the vehicle by a sensor and can avoid a collision or the like by autonomous determination.
  • a system such as a robot called autonomous type or adaptive control type performs behavior control autonomously or adaptively without waiting for an instruction from an operator or a master device. Specifically, by constantly verifying (or evaluating and monitoring) the external environment and internal state of the robot, etc., and sequentially starting actions that match the recognition result of the external environment or internal state to the predetermined transition conditions A behavior suitable for the current situation is realized (see, for example, Patent Document 1).
  • Patent Document 1 On the other hand, as the system becomes complicated, it is difficult for one developer to develop and manufacture, and therefore, it has become common to be developed by a plurality of developers. When developing one system by a plurality of developers, there are several problems as shown below.
  • a computer process (hereinafter also simply referred to as “process”) that runs on the processor is generated and managed by the OS.
  • a real-time OS (RTOS) designed so that each process can be executed at a scheduled time is used. You can also.
  • RTOS for example, a publisher / subscriber type communication model can be used for communication between individual processes generated and managed by an OS according to a plurality of application programs operating on the system. (See, for example, Patent Document 2).
  • An object of the technology disclosed in the present specification is to equip an OS having a communication method in which an application program can be easily added, and to change an application program (or a process generated from the application program) in a predetermined method.
  • Information processing apparatus and information processing method which can be managed separately from the application program (or process), and can solve the above-described problems by a communication method between the separately managed processes, And providing a computer program.
  • the technology disclosed in the present specification has been made in consideration of the above-mentioned problems, and the first aspect thereof is An activation unit that activates a second container separated from the first container in which the first node operates, and activates the second node in the second container; A proxy node that performs data communication based on a predetermined communication model with the first node in the first container and performs data communication based on the predetermined communication model with the second node in the second container A proxy manager that launches Is an information processing apparatus.
  • the first node is a node that operates by installing a first application that satisfies a predetermined condition in the first container.
  • the activation unit installs a second application that does not satisfy the predetermined condition in the second container to operate the second node.
  • the activation unit activates the second container having an address or name space that is logically separated from the first container by a virtual NIC.
  • the predetermined communication model is a publisher / subscriber type communication model, and the activation unit activates the proxy node by designating a topic name shared with the second container.
  • the first node transmits data of a first topic provided by the proxy node in the first container, and the proxy node is associated with the first topic.
  • a second topic is created in two containers and the data received from the first node is transmitted, and the second node receives data from the second topic.
  • the second node transmits data of a second topic provided by the proxy node in the second container, and the proxy node is associated with the second topic.
  • a first topic is created in one container and data received from the second node is transmitted, and the first node receives data from the first topic.
  • the second aspect of the technology disclosed in this specification is: An activation step of activating a second container separated from the first container in which the first node operates, and activating the second node in the second container; A proxy node that performs data communication based on a predetermined communication model with the first node in the first container and performs data communication based on the predetermined communication model with the second node in the second container Proxy management steps to launch Is an information processing method.
  • the third aspect of the technology disclosed in this specification is: An activation unit that activates a second container separated from the first container in which the first node operates, and activates the second node in the second container; A proxy node that performs data communication based on a predetermined communication model with the first node in the first container and performs data communication based on the predetermined communication model with the second node in the second container Proxy management unit that starts As a computer program written in a computer-readable format so that the computer functions.
  • the computer program according to the third aspect of the technology disclosed in the present specification defines a computer program written in a computer-readable format so as to realize predetermined processing on the computer.
  • a computer program according to the third aspect of the technology disclosed in this specification on a computer, a cooperative action is exhibited on the computer, and the information processing apparatus according to the first aspect Similar effects can be obtained.
  • an OS having a communication method that makes it easy to add or change an application program is provided, and the application program (or a process generated from the program)
  • Information processing apparatus, information processing method, and computer that can be managed separately from application programs (or processes) and can solve the above-described problems by a communication method between processes managed separately ⁇ Provide programs.
  • FIG. 1 is a diagram schematically illustrating an example of a control program development environment.
  • FIG. 2 is a diagram illustrating a distributed development environment for a control program via a network.
  • FIG. 3 is a diagram illustrating a development environment of a control program for developing a robot.
  • FIG. 4 is a diagram illustrating a development environment of a control program for developing an autonomous vehicle.
  • FIG. 5 is a diagram illustrating a development environment of a control program for developing an unmanned aerial vehicle (drone).
  • FIG. 6 is a diagram illustrating a configuration example of hardware and software architecture mounted on the actual device of the autonomous operation device 100.
  • FIG. 7 is a diagram for explaining a mechanism of publisher / subscriber type communication.
  • FIG. 1 is a diagram schematically illustrating an example of a control program development environment.
  • FIG. 2 is a diagram illustrating a distributed development environment for a control program via a network.
  • FIG. 3 is a diagram illustrating a development environment of a control program
  • FIG. 8 is a diagram illustrating the source code of an application program for which registration is applied.
  • FIG. 9 is a flowchart showing a processing procedure for starting a container / guest.
  • FIG. 10 is a diagram showing a state in which the container guest 1010 is activated in the container host 1000.
  • FIG. 11 is a diagram showing a processing sequence example when starting a container / guest.
  • FIG. 12 is a flowchart showing a processing procedure for transmitting data from the container host to the container guest.
  • FIG. 13 is a flowchart showing a processing procedure for transmitting data from the container / guest to the container / host.
  • FIG. 14 is a diagram showing an example of a processing sequence for performing data transmission from the container host to the container guest.
  • FIG. 15 is a diagram showing a configuration example of a container network.
  • FIG. 16 is a diagram for explaining a mechanism for changing a topic shared between containers for each container.
  • FIG. 17 is a diagram for explaining a mechanism for stopping and restarting an application that outputs an output that does not conform to the specifications.
  • FIG. 18 is a diagram illustrating an example of a processing sequence for stopping and restarting an application that outputs an output that does not conform to the specification.
  • FIG. 19 is a diagram schematically illustrating a mechanism for temporarily storing transmission / reception data related to a guest node whose application is being updated.
  • FIG. 20 is a diagram illustrating an example of a processing sequence in which transmission / reception data relating to a guest node whose application is being updated is temporarily stored and data transmission is resumed after the application is updated.
  • FIG. 21 is a diagram illustrating an example of a processing sequence in which transmission / reception data relating to a guest node whose application is being updated is temporarily stored and data transmission is resumed after the application is updated.
  • FIG. 22 is a diagram for explaining a mechanism of throttling based on topic traffic.
  • FIG. 23 is a diagram illustrating an example of a processing sequence for performing throttling based on topic traffic.
  • FIG. 24 is a diagram for explaining a mechanism for isolating applications that do not satisfy a predetermined condition by grouping using containers.
  • FIG. 25 is a diagram illustrating a configuration example of an application program of the autonomous operation device 100 assuming a robot.
  • FIG. 26 is a diagram illustrating a configuration example of an application program (an example using grouping using a container) of the autonomous operation device 100 assuming a robot.
  • FIG. 27 is a diagram illustrating a configuration example of an application program of the autonomous operation device 100 assuming an autonomous vehicle.
  • FIG. 28 is a diagram showing a configuration example of an application program (an example using grouping using a container) of the autonomous operation device 100 assuming an autonomous vehicle.
  • FIG. 1 schematically shows an example of a control program development environment. Under the development environment, an autonomous operation device (actual machine) 100 to be controlled by the control program and a development device 200 for creating a control program in the autonomous operation device 100 are arranged.
  • an autonomous operation device actual machine
  • a development device 200 for creating a control program in the autonomous operation device 100 are arranged.
  • the autonomous operation device 100 is a device that controls its own behavior by autonomous or adaptive control, and includes various forms such as a robot, an unmanned aerial vehicle, and an autonomous vehicle.
  • the autonomous operation device 100 includes a main body 110 that controls the overall operation of the system 100 and a plurality of module units 120-1 and 120-2. Although only three module parts are drawn in FIG. 1 for the sake of simplicity, an autonomous operation apparatus including four or more module parts and an autonomous operation apparatus including only two or less module parts are also assumed.
  • One module unit 120 includes an actuator 121, a processor 122, a memory 123, a sensor 124, and a communication modem 125. Although not shown for simplification, it is assumed that the units 121 to 125 in the module unit 120 are interconnected by an internal bus.
  • the actuator 121 is, for example, a motor for rotationally driving a joint, a driver for a speaker, or the like.
  • the sensor 124 is a sensor that detects an output state of an actuator such as a joint rotation angle or angular velocity, a speaker volume, or a sensor that detects an external force or other external environment.
  • the processor 122 controls the operation in the module unit 122 including the drive control (motor controller) of the actuator 121 and the recognition processing of the detection signal from the sensor 124.
  • the memory 123 is used by the processor 122 to store actuator control information, sensor detection values, and the like.
  • the communication modem 125 is hardware for performing mutual communication between the module unit 120 and the main body unit 110 or between the module unit 120 and another module unit, and may be either a wireless modem or a wired modem.
  • the processor 122 receives a command signal such as driving of the actuator 121 from the main body 110 via the communication modem 125, and transmits data detected by the sensor 124 to the main body 110.
  • the module unit 120 can also communicate with an external device such as the development device 200 via the communication modem 125.
  • the main body 110 includes a processor 111, a memory 112, a communication modem 113, a battery 114, a USB (Universal Serial Bus) port 115, and a GPS (Global Positioning System) 116. Although illustration is omitted for simplification, it is assumed that the units 111 to 116 in the main body 110 are interconnected by an internal bus.
  • the processor 111 controls the overall operation of the autonomous operation device 100 according to a program stored in the memory 112.
  • the battery 114 is a driving power source for the autonomous operation device 100 and supplies power to the main body 110 and each module unit 120.
  • the communication modem 113 is hardware for performing mutual communication between the main body unit 120 and each module unit 120, and may be either a wireless modem or a wired modem.
  • the processor 111 transmits a command signal such as driving of the actuator 121 to each module unit 120 via the communication modem 113 or receives a recognition result based on a detection value of the sensor 122 in each module unit 120.
  • the main body 110 can also communicate with an external device such as the development device 200 via the communication modem 113.
  • the USB port 115 is used for connecting an external device to the main body 110 using a USB bus (cable).
  • a USB bus (cable)
  • the development device 200 is connected to the main body 110 using the USB port 115.
  • a control program created on the development device 200 can be installed in the autonomous operation device 100 via the USB port 115.
  • USB is an example of an interface standard for connecting an external device to the autonomous operation device 100, and the external device can be configured to be connected according to another interface standard.
  • the development apparatus 200 is configured by, for example, a personal computer, and includes a computer main body 210, a display 220 such as a liquid crystal panel, and a user interface (UI) unit 230 including a mouse and a keyboard.
  • the computer main unit 210 includes a processor 211, a GPU (Graphic Processing Unit) 212, a memory 213, a USB port 214, and a communication modem 215.
  • a configuration example in which the function of the GPU 212 is included in the processor 211 is also conceivable.
  • the computer main unit 210 includes hardware components other than those shown in the drawing, and the respective units are interconnected by a bus.
  • the OS is running on the development device 200.
  • the processor 211 can load a desired application program into the memory 212 and execute the application program under an execution environment provided by the OS.
  • a development tool program for creating a control program for the autonomous device 100 is assumed as one of the application programs.
  • This development tool program is developed on the memory 213 of the development apparatus 200 together with data necessary for executing the program.
  • the development tool / program presents a GUI (Graphical User Interface) for program development on the screen of the display 220.
  • GUI Graphic User Interface
  • the program developer can input data and programs via the user interface 230 while confirming the contents of the GUI screen.
  • the development tool program has a compiler, debugger, simulation, and a function for checking the operation of the control program using 3D graphics / animation related to the created control program. It is possible to instruct execution of these functions.
  • the control program created using the development tool program includes a control program executed on the processor 111 of the main body 110 on the actual machine of the autonomous operation device 100, data such as parameters used by the control program,
  • the processor 122 of the module unit 120 includes a control program for controlling the driving of the actuator 121 and data such as parameters used by the control program.
  • the program part and the data may be collectively referred to as a “control program”.
  • control program created using the development tool program is stored in the memory 213. Further, the control program on the memory 213 can be transferred to the autonomous operation device 100 side via the USB port 214. Alternatively, the control program on the memory 213 can be transferred to the module unit 120 in the autonomous operation device 100 via the communication modem 215.
  • a control program created using a development tool / program on the development apparatus 200 can be used as a development tool / program or data using 3D graphics / animation (hereinafter referred to as “development of the development tool program and data together” It is also possible to verify operations and correct control data and programs using a tool program.
  • this type of development tool program has a function of generating 3D graphics animation of actual machine operation of the autonomous operation device 100 according to a control program, and the developer can display 3D graphics animation displayed on the display 220. Can be used to verify the operation of the control program developed by itself and to modify data and programs in parallel.
  • the development tool program has a function called a physics engine.
  • the physics engine is a computer program having a function of calculating a physical phenomenon based on the laws of physics based on the physical operation of the actual autonomous operation device 100.
  • the physical characteristics of the autonomous operation device 100 and a realistic external environment are also provided. Is taken into consideration, and an action similar to that in reality is generated and the result is displayed on the display 220.
  • the virtual machine (for 3D graphics / animation) is a virtual autonomous machine 100 that operates in the 3D graphics / animation space using a physical engine instead of the motor of the actual machine. Computer program and data).
  • the physical engine is a virtual model created by imitating the robot while taking into account the weights and moments of each link of the robot arm, the characteristics of the joint driving actuator, and the like.
  • calculate the physical action such as contact with the ground or collision with obstacles
  • the motion of the entire virtual machine is calculated as if the actuator of the robot is actually driven, and the 3D graphics animation that reproduces the realistic motion of the robot by the virtual machine is displayed on the display 220.
  • the virtual machine is a control program and data configured to operate on a development tool program including a physical engine and 3D graphics / animation, and is stored in the memory 213.
  • the control program and data are modularized in units that are operated by the processor 122 of each module unit 120 of the real machine 100.
  • a control program for the virtual machine has a function corresponding to the operation of the processor (for example, motor controller) 122 of the real machine 100 as a part of the program. As realized.
  • the virtual machine control program has a physical engine function that reproduces an operation corresponding to an actuator 121 (for example, a motor) for each module unit 120 of the real machine 100 by 3D graphics animation, an API (Application Programming Interface) or It is programmed to be called using a function.
  • an actuator 121 for example, a motor
  • API Application Programming Interface
  • data used for physical calculation in the physical engine are stored in the memory 213 together with the control program. Are read from the memory 213 and used in the control program.
  • the API or function for issuing an instruction to the program module for realizing the physical engine function is the same as that provided by the basic OS operating on the actual machine, that is, the autonomous operation device 100 side.
  • the program created by the development tool program can be directly operated by the OS on the actual machine.
  • a program developed using the development tool / program is directly uploaded to the autonomous operation device 100 via the USB port 214 and executed. The operation confirmed by the development tool / program can be realized on the actual machine.
  • control program for the autonomous operation device 100 it is possible to develop a control program for the autonomous operation device 100 by dividing it into module units by using a development tool program.
  • the control program can be uploaded to the autonomous operation device 100 in units of the module unit 120.
  • a developer who is in charge of developing hardware and a control program for only the module unit 120-1 connects his development device 200 to the corresponding module unit 120-1 of the autonomous operation device 100 via the communication modem 215.
  • the created program and data can be uploaded to the memory 123 in the module unit 120-1.
  • the development of the entire autonomous operation device 100 can be promoted in a distributed development environment by sharing the development of hardware and programs in units of the module unit 120 by a plurality of developers or a plurality of development vendors.
  • Fig. 2 illustrates a distributed development environment for control programs via a network.
  • development is entrusted to individual developers or development vendors for each module.
  • the module referred to in FIG. 2 may refer to a module of control software of the autonomous operation device 100 in addition to the module unit 120 that is a hardware component of the autonomous operation device 100 illustrated in FIG.
  • Each program developer entrusted with the development of a control program in units of the main body unit or module unit of the autonomous operation device 100 uses the module development computer, respectively, to control the control program for the main body unit 110 or the module unit 120 that he is in charge of create.
  • the development tool program described above is operating.
  • Each module development computer is connected to a network.
  • Each program developer can control the self-developed control in the shared storage on the cloud server, own storage (that is, main unit developer storage, module developer storage), or the storage provided in the dedicated server.
  • a program or the like may be provided.
  • a control program or the like may be shared by an administrator, a developer, a customer, or a user who has an account in a storage such as a server.
  • a developer who is responsible for or supervises the development of the control program for the entire real machine of the autonomous operation device 100 is provided with control programs for the main unit 110 and each module unit 120 via the network.
  • the actual program development computer used by the developers of the entire actual machine can be obtained by direct communication with the shared storage or developer storage on the cloud server, the dedicated server, or the module development computer of each developer.
  • Each control program is received.
  • the network that receives the provision of the control program may be configured by either wired or wireless.
  • the real machine program development computer used by the developers of the real machine corresponds to the development apparatus 200 shown in FIG. 1, performs calculations using the physical engine on the development tool program, and uses 3D graphics animation. It has a function that can display the operation of the virtual machine corresponding to the actual machine. Therefore, the computer for developing a real machine program operates the control program for the main body 110 and all the module parts 120 through the display of the 3D graphics animation of the virtual machine by using the physical engine function provided in the development tool program. Can be confirmed and verified.
  • each control program can be corrected in parallel with the execution of the developed control program. Therefore, the developer of the entire real machine 100 and the developer in charge of each module unit 120 can efficiently jointly develop a control program for the real machine 100 bodies. Further, it is possible to provide the control program modified on the actual program development computer again to the developer who is responsible for the module unit to complete the final program product. For example, collaborative development can proceed smoothly by managing the control program in units of module units 120 such as arranging storage dedicated to the main unit 110 and each module unit 120 on a cloud server.
  • a control program whose operation has been confirmed and verified (that is, completed) on an actual program development computer used by the developer of the entire actual machine 100 is transferred from the development device 200 to the autonomous operation device 100 of the actual machine via the USB port 214. Can be uploaded directly. Alternatively, a control program for the entire real machine 100 or for each module unit 120 can be uploaded to the real machine 100 via a wired or wireless network.
  • control program is uploaded from the dedicated server to the actual machine 100 is also assumed.
  • a control in which a user of an actual machine 100 logs in to a dedicated server using an account that the user has via the user interface (keyboard, mouse, touch panel, etc.) of the user terminal and further downloads or uploads to the actual machine 100 A program may be selected to be downloaded or uploaded.
  • FIG. 3 illustrates a development environment of a control program when a legged robot is a development target as a specific example of the autonomous operation device 100.
  • program development is performed using a single development device 200, but it is also possible to use a distributed development environment via a network as shown in FIG.
  • the legged robot 100 has a main body part 110 and a module part 120 corresponding to a head part and left and right leg parts. Although not shown, there is a data bus and a control bus for coupling between the main body 110 and hardware such as each module 120 such as the head and left and right legs.
  • the legged robot 100 may further include a module unit (not shown) such as an upper limb.
  • a module unit such as an upper limb.
  • functions such as a processor and a memory in at least a part of the module unit are integrated with the main unit and controlled by the processor of the main unit.
  • the main unit includes a processor, a memory, a wireless or wired communication modem, a battery, a USB port, and a GPS.
  • the left and right leg module sections 120-2 and 120-3 include a motor 121 for driving joints (or for walking) such as a hip joint, a knee joint, and an ankle as an actuator, and a motor for controlling the driving of the motor as a processor.
  • a controller 122 is provided.
  • the sensor 124 includes a torque sensor that detects an external force generated on the output side of the motor, an encoder that detects a rotation angle on the output side of the motor, and a ground sensor on the sole.
  • the head module unit 120-1 includes a head rotation motor 121 as an actuator and an image sensor 124 that images the surroundings as a sensor.
  • a control program for the main body 110 and each module unit 120 of the legged robot 100 is created, and further on the development tool program.
  • the operation of the operating physical engine can be used to check and verify the operation through the display of 3D graphics and animation of the virtual machine.
  • a control program created using the development apparatus 200 a control program for the entire real machine 100 developed in the development environment (or other development environment) as shown in FIG.
  • the data is uploaded to the memory 112 of the main unit 110 or the memory 123 of each module unit 120 by wired or wireless communication via the USB port 115 of the main unit 110 or the communication modem 125 of each module unit 120.
  • the uploaded program is appropriately operated when the legged robot 100 is activated.
  • FIG. 4 illustrates a development environment of a control program when an autonomous vehicle is a development target as another specific example of the autonomous operation device 100.
  • the self-driving vehicle 100 is an automobile (or an unmanned operation vehicle for work or transportation) in which automatic driving technology is introduced.
  • an automatic driving mode and a manual driving mode are switched. It includes vehicles that are traveling in the automatic driving mode of possible vehicles.
  • program development is performed using a single development device 200, but of course, it is also possible to use a distributed development environment via a network as shown in FIG. 2.
  • the automatic traveling vehicle 100 normally includes many module units (not shown) in addition to the transmission control module unit 120-2 and the indoor air conditioning control module unit 120-1, but they are omitted for simplification of description.
  • the main control unit 110 includes an ECU (Electronic Control Unit) 111 as a processor, a memory 112, a communication modem 113, an ECU interface 115, a GPS 116, and a battery 114.
  • the communication modem 113 assumes Wi-Fi (Wireless Fidelity), LTE (Long Term Evolution), short-range wireless communication, and the like.
  • the ECU interface 115 is assumed to be an interface to a CAN (Controller Area Network) bus (not shown), and is connected to the development device 200 side using a communication standard such as Ethernet (registered trademark).
  • the indoor air conditioning module unit 120-1 includes an air conditioner 121 as an actuator, an air conditioning control ECU 122 as a processor, a memory 123, an indoor temperature sensor 124 as a sensor, and a communication modem 125 such as Bluetooth (registered trademark) communication. ing. For example, it is assumed that an air conditioner is controlled by connecting to an information terminal (not shown) such as a smartphone carried by the passenger by Bluetooth (registered trademark) communication.
  • the transmission control module unit 120-2 includes a drive wheel motor 121 as an actuator, a transmission control ECU 122 as a processor, a memory 123, a speed / acceleration sensor 124, a steering angle sensor, and the like as sensors.
  • the ECU is arranged in the main control unit 110 and each module unit 120.
  • the ECU 111 in the main control unit 110 is configured to centrally manage all the module units 120. It is also possible.
  • the main control unit 110 As in FIG. 1, using the development tool program operating on the development apparatus 200, the main control unit 110, the indoor air conditioning control module unit 120-1, and the transmission control module unit 120-2 of the above-described autonomous vehicle 100 are used.
  • the control program can be created, and further, the physical engine function operating on the development tool program can be used to check and verify the operation through the display of 3D graphics and animation of the virtual machine.
  • a control program created using the development apparatus 200 a control program for the entire real machine 100 developed in the development environment (or other development environment) as shown in FIG.
  • the data is uploaded to the memory 112 of the main control unit 110 or the memory 123 of each module unit 120 by wired or wireless communication via the ECU interface 115 of the main control unit 110 or the communication modem of each module unit 120.
  • the uploaded program is appropriately operated when the automatic traveling vehicle 100 is activated.
  • FIG. 5 illustrates a development environment of a control program when an unmanned aerial vehicle (drone) is a development target as another specific example of the autonomous operation device 100.
  • the program development is performed using a single development device, but it is of course possible to use a distributed development environment via a network as shown in FIG.
  • the wireless aircraft 100 may incorporate a module unit other than the camera control module unit 120-1 and the propeller control module unit 120-2.
  • the main control unit 110 includes a processor 111, a memory 112, a communication modem 113, a USB port 115, a GPS 116, and a battery 114.
  • the communication modem 113 is assumed to be a wireless modem such as Wi-Fi, LTE, or short-range wireless communication, and communicates with a remote controller (not shown) operated by a pilot.
  • the development device 200 is connected using the USB port 115, and the developed control program is uploaded.
  • the camera control module unit 120-1 includes a camera unit (including an image sensor) 124 as a sensor, a camera unit rotation motor 121 as an actuator, a motor controller 122 as a processor, a memory 123, and a communication modem. 125 is provided.
  • the camera unit rotation motor 121 can be rotated, for example, in the range of 360 degrees in the horizontal direction, and further can be tilted.
  • the communication modem 125 is assumed to be a wireless modem such as Wi-Fi, LTE, or short-range wireless communication, and the camera unit 124 rotates according to commands from a remote controller or a smartphone (not shown) operated by the operator. And do photography.
  • the propeller control module unit 120-2 includes, for example, three propellers (including a rotation motor) 121 as an actuator, a processor 122 that controls the rotation motor of the propeller 121, a memory 123, and propeller rotation detection as a sensor.
  • a sensor 124 is provided.
  • the development tool program operating on the development apparatus 200 is used to control the main control unit 110, the camera control module unit 120-1, and the propeller control module unit 120-2 of the unmanned aircraft 100.
  • the program can be created, and the physical engine function operating on the development tool / program can be used to check and verify the operation through the display of 3D graphics / animation of the virtual machine.
  • a control program created using the development apparatus 200 a control program for the entire real machine 100 developed in the development environment (or other development environment) as shown in FIG.
  • the data is uploaded to the memory 112 of the main control unit 110 or the memory 123 of each module unit 120 by wired or wireless communication via the communication modem of the main control unit 110 or each module unit 120.
  • the uploaded program is appropriately operated when the unmanned aircraft 100 is activated.
  • FIG. 6 shows a configuration example of hardware and software architecture mounted on the actual machine of the autonomous operation device 100.
  • the hardware in the lowest layer is composed of a plurality of hardware modules such as a main body (or a main control unit 110 and a plurality of module units 120) incorporated in the casing of the actual machine 100.
  • Each hardware module There may also be an actual machine configured by dispersing and arranging in two or more housings.
  • the OS controls each hardware module directly.
  • the control program uploaded to the memory 123 in the module unit 120 instead of the OS directly controls the hardware module (specifically, the processor 122 executes the control program and the actuator 121 is controlled).
  • the main system unit 110 controls the entire system 100.
  • the main OS that operates is configured to directly or indirectly control the control program being executed in each module unit 120.
  • An application program developer can develop an application program using an API provided by a system (for example, middleware).
  • an application program developer can develop an application program including a program that instructs the OS using a system call.
  • the system call here is an interface for using a function related to system control. Examples of the system call include changing a parameter of a processor (for example, a motor controller) in a module unit and setting a network address in a communication modem.
  • the “recognition” application program is an application program that recognizes and processes sensor information acquired by a camera or other sensor included in the hardware layer.
  • the “situation understanding” application program is an application program that understands the situation where the actual machine is currently placed based on the recognition result by the “recognition” application program.
  • an image analysis application program that analyzes an image captured by a camera is an example of a “situation understanding” application program.
  • an application program that runs under an execution environment provided by the OS is managed on a memory as a “process” (or “thread”), and is executed by a processor (such as a CPU).
  • the “action plan” application program is an application program that is understood by the “situation understanding” application program and plans the action of the actual machine according to the situation where the actual machine is currently placed.
  • a route selection application program that selects a moving route of an actual machine according to a result of analyzing a surrounding image of the actual machine by the above image analysis application program is an example of an “action plan” application program.
  • the “behavior control” application program is an application program that controls the behavior or operation of hardware to realize the action plan drawn up by the “behavior plan” application program.
  • An application program that controls the driving of the drone propeller corresponds to the “behavior control” application program.
  • an application program developed in an autonomous vehicle an application program that requires high reliability such as drive system control (DSU, etc.), and infotainment related to services for users (audio equipment, Internet connection) Service applications, etc.) and in-vehicle environment control (air-conditioning control, etc.), which are broadly classified into two types of highly versatile application programs that are provided for the convenience of the user.
  • the latter application program can be provided by a third party.
  • a grouping method called a container is introduced and included in a constituent unit (application program, etc.) or constituent unit belonging to the container.
  • the following technology is proposed to limit communication within the container to which the software belongs. According to this technology, any grouping of software included in a configuration unit or a configuration unit is possible while maintaining independence in configuration unit development.
  • the information from the same source is processed after being processed according to the characteristics assigned to each constituent unit (for example, the information is degraded according to the security level of the constituent unit) and then transmitted. Technologies are also proposed below.
  • the transmission / reception data related to the configuration unit being updated is temporarily stored, and the connection unit is resumed from the transmission / reception data temporarily stored after the update, thereby safely updating the configuration unit and software included in the configuration unit.
  • the connection unit is resumed from the transmission / reception data temporarily stored after the update, thereby safely updating the configuration unit and software included in the configuration unit.
  • the amount of data transmitted / received by the configuration unit is limited at the physical level (packet amount) and logical level (number of topics used in publisher / subscriber communication), and multi-tenant
  • the technology for allocating equal network resources to each other is also proposed below.
  • a sending client that creates and transmits a message
  • a client that receives a message
  • the publisher does not consider who the message is sent to, and issues (publishes) a message to the server for the time being. Meanwhile, the subscriber subscribes to the server for a message subscription. Then, the message type and attributes transmitted from the publisher are referred to and delivered to the subscriber who wants the message. Publishers and subscribers do not need to be aware of each other, and subscribers can only receive messages that they need.
  • a form of performing asynchronous communication that designates a named logical channel called “topic” can be called topic-based publisher / subscriber type communication.
  • a message transmitted from a publisher is registered in a destination called a topic in the server (master).
  • the server matches the topic attached to the message sent by the publisher with the topic subscribed to by the subscriber, and subscribes to that topic (ie subscribed to) the subscriber.
  • Messages from one or more publishers can be registered in one topic.
  • one or more subscribers can register on the same topic. Subscribers can receive messages from multiple publishers from registered topics. Multiple subscribers registered on the same topic can receive the same message from that topic.
  • the container is an address or name space logically separated by a virtual NIC (network interface card), or a name space physically separated by each NIC.
  • a container can also be regarded as a management area of a system separated as a network segment.
  • a container host is a space where only trusted host nodes operate.
  • a container guest is a space in which only a guest node that needs to be separated from a host node operates. For example, it is necessary to separate application programs and library programs provided by a third party from the host node and operate them in a container guest (hereinafter referred to as “application program” and “library program”.
  • a node corresponds to an application or a process in which an application operates in a container (hereinafter referred to as an “application” as a program code and a “node” as a process executed by a processor of the system. ).
  • the node transmits a subscribe request or a publish request to a master of a container to which the node belongs by specifying a named logical channel called “topic”.
  • a connectable partner is found (specifically, when matching with a connection request partner is obtained in the master), the publisher / subscriber is obtained by acquiring ID information (process ID, etc.) of the communication partner.
  • ID information process ID, etc.
  • Type messaging and one-way communication by RPC Remote Procedure Call.
  • the node (application) publishes, as an API, an application name, a topic name provided by the application, or whether the application subscribes or publishes data to a new application developer.
  • Nodes can be classified into “host nodes” and “guest nodes”.
  • a host node is a process by which a trusted application or library runs within a container host.
  • the guest node is a process in which an application or library provided by a third party or an application or library whose reliability is not ensured operates in the container guest.
  • “container host” is used instead of “host node”
  • “container guest” may be described instead of “guest node”.
  • host node” and “guest node” perform communication processing as part of “container host” or “container guest” to which they belong. I want to be.
  • Proxy The proxy (proxy node) manages the mapping table of the following items (a) to (d). The basic function of the proxy follows the node. However, when communicating with the master of the container / guest, the address of the container / guest is designated to perform communication over the network.
  • Topic identifier that can be specified by a node (subscribe node, publish (advertise) node) in the container host (b) A node (subscribe node, publish (advertise) node) in the container guest Specifiable topic identifier (c) Container guest address (for example, IP address (generally, it may be a URI (URL))) (D) Authentication status (verification) of container / guest, security level, data transmitted / received during program update processing of subscriber
  • the master receives a subscribe request and a publish request from a node in the container, and manages a node correspondence (that is, a correspondence relationship between a subscribe node and a publish (advertise) node) for each topic.
  • a node correspondence that is, a correspondence relationship between a subscribe node and a publish (advertise) node
  • each master at least the publish (advertise) node that is the sending side) sends the other party (receiver side).
  • Subscriber node process ID, program name, communication destination (IP address, port, etc.), etc.
  • publisher / subscriber type messaging and RPC between nodes including between nodes and proxies
  • Masters can be classified into “Host Master” and “Guest Master”.
  • the host master is a master that operates in the container host
  • the guest master is a master that operates in the container guest.
  • a topic is a name or identifier (ID) such as the following that is used to create a data communication path with a common named logical channel at a node that subscribes or publishes (advertises) a message.
  • ID a name or identifier
  • the container guest name is created when registering the guest application.
  • a developer who has developed a new application that operates together with other applications that operate on the autonomous operation device 100 for a certain autonomous operation device 100 Register the application with the server. Then, the developed application can be installed in an isolated space consisting of an address or name space that is logically separated from the outside, called a container, and can be operated on the autonomous operation device 100.
  • a certain autonomous operation device 100 for example, a robot, an autonomous vehicle, an unmanned aerial vehicle (drone), etc.
  • the application installed in the container operates as a process called a node.
  • containers are classified into container hosts and container guests.
  • the container host is a space provided so that only reliable host nodes can operate. For example, an application that satisfies the following predetermined conditions is installed in the container host and operates as a host node.
  • the container guest is a space provided for operating a guest node that needs to be separated from the host node.
  • an application that does not satisfy the above-mentioned predetermined conditions as a host node but is grouped in a predetermined unit as shown below, for example, is installed in a container guest and separated from the host node (container Operates as a guest node (independent of the host) Independence in application development can be maintained by container grouping.
  • ⁇ Install group applications between coherent nodes by installing applications that satisfy the above-mentioned predetermined conditions on the container host and operating each as a host node. That is, data is transmitted and received between nodes in the container host using a publisher / subscriber type communication mechanism. As described above, in publisher / subscriber type communication, a node can communicate with other nodes via a process called a master. At this time, a predetermined topic name can be designated as a communication path for communication between nodes. Communication specifying a topic name corresponds to communication using a named communication path.
  • a data transmission / reception method using a publisher / subscriber type communication mechanism will be described with reference to FIG.
  • a node that becomes a publisher 701 and a subscriber 702 and a master 703 are operating in a container host 700.
  • the publisher 701 on the transmission side sends information “foo: 1234” including a combination of a topic name “bar” and a host name (foo) and a port number (1234) as its own ID to the master 703 as an advertisement.
  • Register (S710) the publisher 701 on the transmission side sends information “foo: 1234” including a combination of a topic name “bar” and a host name (foo) and a port number (1234) as its own ID to the master 703 as an advertisement.
  • Register S710
  • the subscriber 702 on the receiving side requests the information on the distribution source of the topic “bar” (XML / RPC URI) from the master 703 as a subscription (S711).
  • the master 703 Since the subscribe node and the publish node are prepared for the topic “bar”, the master 703 notifies the subscriber 702 of “foo: 1234” as information of the publisher 701 that is the distribution source (S712).
  • the subscriber 702 Upon receiving the notification from the master 703, the subscriber 702 transmits a subscription request (connect (“bar”, TCP)) for the topic name “bar” by TCP socket communication to the publisher 701 (S713).
  • the publisher 701 notifies the URI (foo: 2345) of the TCP server for subscription (S714).
  • connection (connect (foo: 2345)) for the subscription of the topic name “bar” to the TCP server for subscription (S715).
  • the topic with the topic name “bar” is distributed by TCP / IP from the subscription TCP server (foo: 2345) to the subscriber 702 (S716).
  • the topic distribution requires that communication to the master 703 for sharing the namespace of the topic and P2P communication between nodes (that is, the publisher 701 and the subscriber 702) for actual data transmission and reception are necessary. Please note that.
  • a first node having a function of providing data and a second node that performs processing using data are operating in the container host.
  • the first node is an application that provides a captured image of the camera
  • the second node is an application that generates a three-dimensional map.
  • the first node sends a request for data transmission (publish or advertise) to the master by designating the topic name “image”.
  • the second node transmits a request for data reception (subscription) to the master by designating the topic name “image”.
  • the publish (or advertisement) request and the subscribe request may be either first or simultaneously.
  • the master Since the master has both a subscribe node and a publish (advertise) node for the same topic name “image”, the master has the second node that is the subscribe node for the first node that is the publish node. The ID (or name or destination information) is notified, and the ID (or name or destination information) of the first node that is the publishing node is notified to the second node that is the subscribing node. To do. As a result, data of the topic name “image” can be transmitted and received between the first node and the second node.
  • a topic name such as “image” serves as a communication interface for each application installed in the system (or a host node operating in a container host). As shown in Table 1 below, if a topic name related to each application is defined and disclosed to the developer as interface information, a developer of a new application can transfer data to other applications. It becomes easy to develop an application that performs processing by receiving an application that is supposed to be provided or data provided by another application.
  • the information shown in Table 1 above can be managed, for example, in a database associated with a development tool / program for developers.
  • a database may be stored and managed in a storage under the management of a computer (for example, the development apparatus 200 in FIG. 1) on which the development tool program operates, as shown in FIG. It may be stored and managed in a computer or storage associated with a server existing on a simple network.
  • the development tool program can display a related topic name by selecting an application name for a user who is developing the application.
  • the information shown in Table 1 is managed as a database in the development tool program.
  • the development tool program recognizes the registered application name in the database, and the character string “camera image application” is underlined, for example
  • the highlight display can be made by a method such as coloring, reversing, or the like.
  • the registration application form must include at least the new application name and the host application name.
  • Other information that can be registered upon application includes, for example, the application developer name (manufacturer name), authentication information issued by a third party, security level, and description of the function of the developed application. However, it is not limited to these.
  • a description will be given assuming that a process called “proxy manager” operating on the server performs reception processing of this application application.
  • a new container name name of the new container guest
  • the proxy manager is registered with other registration information. Registered in the associated database.
  • the topic name assigned at the time of application acceptance can be used by the node corresponding to the application running on the container host and the application running on the container guest to send and receive data between the node corresponding to the other application. it can.
  • Table 2 illustrates information assigned to a new application and registered in the database.
  • the container name may be assigned in advance.
  • a developer may assign a container name in advance to a registered developer name (manufacturer name) by performing developer (manufacturer) registration in advance prior to application development. . If a container name has been assigned in advance, when applying the above application, enter the container name assigned in advance in the application form and associate it with the newly registered application in the database associated with the proxy manager. Can be managed.
  • the application developer builds the developed application program together with the registered information (see Table 2), thereby changing the “[registered topic name]” in the application source code to “[ By replacing with “container name] / [registered topic name]”, it is possible to generate code of an application program that operates in a predetermined container guest on the system.
  • the information associated with the application name is displayed at the nearest position from the input character string for development support.
  • development support can also be realized by making it possible to provide the program development environment with the database information in which the registration application information shown in Table 2 is registered.
  • the advertisement is a program procedure for requesting data transmission to another node by designating a topic of “[registered topic name]” as a node that performs data transmission. is there.
  • the application shown in FIG. 8 is a process corresponding to the application in which the information shown in Table 2 is registered and operates as a guest node in a container guest, the command on the 8th line is published (data transmission) ).
  • the other node in this case is a subscriber (data reception). Therefore, in the registration information shown in Table 2, the “recognition result” corresponding to the “subscriber (data reception) topic name” item is programmed as “[registered topic name]”. Therefore, by editing and constructing the program source code using the registration information shown in Table 2, the code on the eighth line is changed as follows ("[Registered Topic Name]” is changed to "/ proxy A / ”is rewritten as“ recognition result ”) to generate a program code.
  • topics registered in the proxy manager can be easily inserted into the source code of the application program to be newly registered. That is, the user (application developer) can construct an application program that operates on the container guest based on the registration application information without being aware of the list of registration application information.
  • a grouping method called a container is introduced to separate applications that do not satisfy a predetermined condition from host nodes operating on the container host. Make it work. As a result, even if incorrect data is output from an application program (not satisfying the prescribed conditions) provided by a third party (intentional or negligent by the third party), the entire system will not fail. Can be isolated.
  • the container host read from the memory is set on the system, and the predetermined condition (described above) is satisfied on the container host.
  • the application is installed and acts as a host node. In other words, in the initial state of the system, only the container host on which a reliable host node operates is set.
  • the startup of the container guest is executed by a management process having the role of an application launcher.
  • the application launcher also performs virtual network management for containers, such as assigning IP addresses to activated containers and guests.
  • the proxy manager actually sets the value of the IP address in the virtual NIC of the container, but the application launcher performs management of the IP address assigned to each container guest (similar to a DHCP server).
  • FIG. 9 shows a processing procedure for starting a container / guest in the form of a flowchart.
  • the container host has already been set up on the system, one or more host nodes have been started on the container host, and the proxy manager has been started. .
  • the application launcher checks whether a virtual network for the container guest is created (step S901).
  • step S902 If the container / guest has not yet been read and the network for the container / guest has not been created (No in step S901), the virtual process for the container / guest is performed by the following processes S902-1 to S902-2. A network is created (step S902).
  • S902-1 Create a virtual bridge (brctl addr command).
  • S902-2 Network setting such as an IP address is set in the virtual bridge (ip addr command).
  • step S903 a firewall that rejects all communications other than access to the IP address of the virtual bridge is set for the virtual bridge (iptables command) (step S903).
  • the container guest is made impossible to perform direct communication with another container (for example, a container host or another container guest).
  • Step S904 the IP address of the virtual NIC for the container guest is 192.168.91.0/24, and the IP address of the virtual NIC facing this on the container host side is 172.16.10.0/16 Suppose that
  • step S905 the network setting of the container / guest virtual NIC is performed (step S905) by the following processes S905-1 to S905-6.
  • S905-1) Create a virtual NIC for the container / guest and a virtual NIC facing the container / host (ip link command).
  • S905-2) Start the opposing virtual NIC on the container / host side (ip link command)
  • S905-3) The opposing virtual NIC on the container host side is allocated to the virtual bridge (ip link command).
  • step S906 the virtual NIC for container / guest is assigned to the container / guest (step S906), the topic name shared by the container host with the container guest is designated, and the proxy node is activated (step S907). This process is terminated.
  • Proxy manager starts proxy node by specifying arguments to proxy node program.
  • the arguments include the ID that uniquely identifies the proxy node from other proxy nodes, the IP address of the container host, the IP address of the host master on the container host side, the topic name on the container host side, and the container guest IP address, container.
  • the IP address of the guest master on the guest side, the topic name on the container guest side, the size of the queue of data transmitted / received by the proxy node, and the node that performs data transmission are specified.
  • Proxy manager starts proxy node using information registered in database in advance (refer to Application registration by developer). Information regarding the network segment and information at the time of application registration by the developer may be linked and managed in any database, but this can be realized without managing the database. However, it is not the process of each proxy node but the proxy manager or application launcher (software that starts an application) that manages the associated database.
  • FIG. 10 shows a state in which the container guest 1010 is activated in the container host 1000. Since at least one application is installed in the container host 1000, the host node 1004 is activated.
  • the container guest 1010 When installing an application that does not satisfy a predetermined condition in the system, the container guest 1010 is activated to operate separately from the host node 1004 that operates on the container host 1000 side.
  • the application is installed in the container guest 1010 and operates as a guest node 1012.
  • the application launcher 1001 performs virtual network management for a container such as activation of the container guest 1010 and assignment of an IP address to the container guest 1010 in accordance with the processing procedure shown in FIG.
  • the application launcher 1001 calls the proxy manager 1002 when starting the container guest 1010.
  • the proxy manager 1002 creates a proxy node 1005 when the container guest 1010 is activated.
  • a topic name shared between the container host 1000 and the container guest 1010 is specified for each of the host master 1003 on the container host 1000 side and the guest master 1011 on the container guest 1010 side To do.
  • the proxy manager 1002 is a management tool for the proxy node 1005, for example.
  • the application host node
  • the proxy manager 1002 specifies the topic name used by the container guest 1012 from the database information based on the registration information of the prior application.
  • the topic name used by the container guest may be specified by the user at the time of prior application.
  • the proxy node 1005 manages the mapping table of the following items (a) to (d) in a memory (including a cache) or a database in the secondary recording device (described above).
  • Topic identifier that can be specified by the host node 1004
  • Topic identifier that can be specified by the guest node 1012
  • Address of the container guest 1010 (d) Authentication state (verification) and security level of the container guest 1010 Sent / received during subscriber program update processing
  • the publisher registers a topic in the master, and the subscriber requests a topic from the master. Once taken (ie, when the name is resolved), topic distribution is performed between the publisher and subscriber.
  • the proxy node 1005 operates as a host node. Therefore, when one of the host node 1004 and the proxy node 1005 becomes a publisher and the other becomes a subscriber, and the host master 1003 has a correspondence relationship of topics, topic distribution from the host node 1004 to the proxy node 1005, or Topic distribution from the proxy node 1005 to the host node 1004 is performed.
  • the proxy node 1005 operates as a guest node. Therefore, when one of the guest node 1012 and the proxy node 1005 becomes a publisher and the other becomes a subscriber, and the topic correspondence is established in the guest master 1011, topic distribution from the guest node 1012 to the proxy node 1005, or Topic distribution from the proxy node 1005 to the guest node 1012 is performed.
  • the container host 1000 and the container guest 1010 are addresses or name spaces logically separated by a virtual NIC, and direct topic distribution cannot be performed between the host node 1004 and the guest node 1012. However, data can be indirectly transmitted between the host node 1004 and the guest node 1012 by starting the proxy node 1005 by specifying a topic name shared with the container guest 1010.
  • the proxy node 1005 When transmitting data from the host node 1004 to the guest node 1012, the proxy node 1005 sends a topic name to be distributed to the guest node 1012 on the container host 1000 side to the host master 1003. Request.
  • the host master 1003 On the container host 1000 side, when the host node 1004 registers as a publisher in the host master 1003 with the topic name requested by the guest node 1012, the host master 1003 has a correspondence relationship between the publisher and the subscriber ( The name is resolved) and topic distribution is performed from the host node 1004 to the proxy node 1005.
  • the proxy node 1005 registers a topic in the guest master 1011 as a publisher on the container guest 1010 side. Subscriber correspondence is established (names are resolved), and topic distribution is performed from the proxy node 1005 to the guest node 1012.
  • the proxy node 1005 uses the topic name registered by the guest node 1012 as the publisher in the guest master 1011. Request to the guest master 1011.
  • topic distribution is performed from the guest node 1012 to the proxy node 1005.
  • the proxy node 1005 registers a topic as a publisher with the same topic name as that requested to the guest master 1011 on the container host 1000 side. Assuming that the host node 1004 is registered as a subscriber with the same topic name, the correspondence between the publisher and the subscriber can be taken in the host master 1003 (because the name is resolved). Topic distribution is performed to the node 1003.
  • the host topic 1003 and the guest master 1011 can use the same topic name.
  • identification such as a prefix (for example, “/ host1”) that can identify the communication partner on the container host 1000 side
  • the communication partner of the topic can be identified also from the container guest 1010 side (the same applies to the container host 1000 side).
  • the proxy manager 1002 specifies, as a management tool for the proxy node 1005, the topic name used by the container guest 1012 from the database based on the registration information of the prior application from the user. For example, a prefix may be added to the topic name used on the container guest 1012 side according to the desire of the user who applies in advance.
  • FIG. 11 shows a processing sequence example when starting the container / guest.
  • the illustrated processing sequence is basically executed according to the flowchart shown in FIG.
  • the proxy manager which is a proxy node management tool, specifies the application (host node) used by the application and the required topic. Apply in advance (as described above).
  • the user requests the application launcher to start the container guest by specifying the topic name (S1101).
  • the user referred to here is, for example, a user who requests installation of an application that satisfies a predetermined condition.
  • the application launcher prepares virtual network information to be allocated to the container guest before starting the container guest, and notifies the proxy manager (S1102).
  • the proxy manager requests the system to set the virtual network for the container guest (S1103). On the other hand, when the system completes the setting of the virtual network for the container guest, the system notifies the proxy manager (S1104).
  • the proxy manager creates a specified number of proxy nodes so that the user can communicate with the container host by using the topic name registered in the database in advance by the user (S1105).
  • the proxy node When the proxy node is activated, it notifies the proxy manager (S1106).
  • the topic name shared with the container guest is also specified on the container host side.
  • the proxy manager notifies the application launcher that the setting of the virtual network of the container guest is completed and that the activation of the proxy node is completed (S1107).
  • the application launcher When the application launcher receives a notification from the proxy manager, it starts the container guest. Then, an application that does not satisfy the predetermined condition is installed in the container guest and operates as a guest node (S1108).
  • the proxy node operates as a host node.
  • One of the host node and the proxy node is a publisher and the other is a subscriber, and topic distribution from the host node to the proxy node or topic distribution from the proxy node to the host node is performed.
  • the proxy node operates as a guest node.
  • One of the guest node and the proxy node is a publisher and the other is a subscriber, and topic distribution from the guest node to the proxy node or topic distribution from the proxy node to the guest node is performed.
  • the container host and the container guest are addresses or name spaces logically separated by a virtual NIC, and direct topic distribution cannot be performed between the host node and the guest node.
  • data can be indirectly transmitted between the host node and the guest node by specifying the topic name shared with the container guest and starting the proxy node.
  • the proxy node requests the host master for a topic name “image” to be distributed to the guest node.
  • the host node corresponding to the “camera image application” registers as a publisher with the topic name “image” for the host master, the correspondence relationship between the publisher and the subscriber is obtained in the host master (the name is resolved).
  • Topic distribution is performed from the host node to the proxy node.
  • the guest node corresponding to the “image recognition application” is registered as a subscriber requesting the topic name “image” from the guest master.
  • the proxy node registers the topic “image” with the guest master as a publisher on the container guest side. Correspondence is established (name is resolved), and the topic “image” is distributed from the proxy node to the guest node.
  • the host master and guest master can use the same topic name. However, for example, by adding a prefix (for example, “/ host1”) that identifies the communication partner on the container host side to the topic name of the same topic as the container host in the container guest. Can be identified from the container / guest side (the same applies to the container / host side).
  • a prefix for example, “/ host1”
  • FIG. 12 shows a processing procedure for transmitting data from the host node of the container host to the guest node of the container guest in the form of a flowchart.
  • the host node of the container host connects to the "topic" on the container host side provided by the proxy node (that is, it registers as the publisher with the host master and the topic with respect to the subscriber of the registered topic) Can be transmitted) (step S1201).
  • the host node transmits (publishes) data to the topic on the container host side provided by the proxy node (step S1202).
  • the proxy node receives (subscribes) topic data on the container host side (host master) provided by itself (step S1203).
  • the proxy node also creates a corresponding topic on the virtual network linked to the container host, that is, the container guest side (guest master) (that is, registers as a topic publisher for the guest master, Data on the topic can be transmitted to subscribers of the registered topic (step S1204).
  • the container guest side that is, registers as a topic publisher for the guest master
  • the proxy node transmits (publishes) the data received from the host node on the container host side to the created topic (step S1205).
  • the guest node receives (subscribes) data from the topic created by the proxy node on the container guest side (guest master) (step S1206), and receives transmission data from the host node. be able to.
  • FIG. 13 shows a processing procedure for transmitting data from the guest node of the container guest to the host node of the container host in the form of a flowchart.
  • the guest node of the container guest connects to the "topic" on the container guest side provided by the proxy node (that is, it registers as a publisher with the guest master and the topic with respect to subscribers of the registered topic) Can be transmitted) (step S1301).
  • the guest node transmits (publishes) data to the topic on the container guest side provided by the proxy node (step S1302).
  • the proxy node receives (subscribes) topic data on the container guest side (guest master) provided by itself (step S1303).
  • the proxy node also creates a corresponding topic on the virtual network linked to the container guest, that is, the container host side (host master) (that is, registers as a topic publisher with the host master, Data on the topic can be transmitted to subscribers of the registered topic (step S1304).
  • the container host side that is, registers as a topic publisher with the host master
  • the proxy node transmits (publishes) the data received from the guest node on the container guest side to the created topic (step S1305).
  • the host node receives (subscribes) data from the topic created by the proxy node on the container host side (host master) (step S1306), and receives transmission data from the guest node. be able to.
  • FIG. 14 shows an example of a processing sequence for transmitting data from the container host side (not shown host node) to the container guest side (not shown guest node).
  • the proxy node registers its virtual network information in the guest master with the topic name on the container guest side pre-registered in the proxy manager (S1401).
  • the container host that is the publisher (the host node (not shown) that sends and receives data as an application process) is the topic name of the container host that is pre-registered with the proxy manager and uses its own virtual network. Information is registered in the host master (S1402).
  • the container guest that is a subscriber (the guest node (not shown) that sends and receives data as an application process) is registered in the guest master with the topic name of the container guest pre-registered in the proxy manager Wait until it is done.
  • the container guest can confirm that the desired topic name is registered in the guest master, the container guest acquires the virtual network information of the proxy node from the guest master (S1403).
  • the proxy node waits until the topic name on the container host side pre-registered with the proxy manager is registered with the host master.
  • the proxy node can confirm that the desired topic name is registered in the host master, the proxy node acquires the virtual network information of the container host serving as the publisher from the host master (S1404).
  • the container guest which is a subscriber, connects to the proxy node based on the virtual network information of the proxy node acquired from the guest master (S1405). As a result, a communication path between the proxy node and the container guest that is a subscriber is completed.
  • the proxy node connects to the container host based on the virtual network information of the host node acquired from the host master (S1406). As a result, the communication path between the container host that is the publisher and the proxy node is completed.
  • the container host that is the publisher transmits topic data to the proxy node (S1407).
  • topic data is transmitted from the proxy node to the container guest that is a subscriber (S1408).
  • processing sequence for transmitting data from the container guest side (guest node) to the container host side (host node) is not shown in the figure, but it should be understood that the same procedure can be used.
  • each application is logically separated by the virtual NIC according to the type (for example, according to whether or not a predetermined condition is satisfied, or according to a level that satisfies the condition).
  • a virtual network is created for each container, and each container (container / guest) is blocked from the outside (container / host).
  • a virtual NIC is assigned to each container, and an opposing virtual NIC is created on the container host side.
  • FIG. 15 shows a configuration example of a container network 1500 using a virtual NIC.
  • a plurality of container groups 1510 and 1520 are formed, and one or more containers (containers and guests) are activated in each of the container groups 1510 and 1520.
  • the container 1511 and the container 1512 are activated in the container group 1510, and the container 1521 is activated in the container group 1520.
  • the container is activated in accordance with the processing procedure shown in FIG. 9, for example.
  • Each container is assigned a virtual NIC and can communicate with the opposing virtual NIC on the container host side.
  • the virtual NIC 1511 ′ is allocated to the container 1511
  • the virtual NIC 1512 ′ is allocated to the container 1511.
  • the virtual NIC 1521 ′ is replaced with the container 1521.
  • a virtual NIC 1501 facing the virtual NIC of each container is created.
  • For each container in each container group are virtual bridges 1501-a, 1501-b created for each container group. Can be communicated through.
  • the container groups 1510, 1520,... are assigned, for example, for each application developer (software vendor). Therefore, one container group is composed of a set of containers for installing applications having the same conditions (developed by the same developer, etc.) and operating them as nodes.
  • the communication permission range is surrounded by a dotted line.
  • nodes operating in each container can communicate with each other via a virtual NIC assigned to each container.
  • a node operating in the container 1511 and a node operating in the container 1512 can communicate with each other by the virtual NICs 1511 ′ and 1512 ′ assigned thereto.
  • nodes operating in containers belonging to different container groups cannot communicate with each other because subnets are separated.
  • a node operating in the container 1512 and a node operating in the container 1521 cannot communicate with each other by the virtual NICs 1512 ′ and 1521 ′ assigned thereto.
  • the limit of the communication permission range as described above can be realized by using an iptables command for operating setting of packet filtering and network address translation (NAT) function.
  • NAT network address translation
  • information from the same source can be transmitted after being processed according to the characteristics assigned to each application. For example, information is degraded in accordance with the security level for each application that is a transmission destination. Specifically, it can be realized by changing the topic shared between containers for each container. An example of changing the shared topic for each container will be described with reference to FIG.
  • a camera image application (APP1) and an image recognition application (APP2) satisfying predetermined conditions are installed and operate as a node 1601 and a node 1602, respectively.
  • An authenticated image recognition application provided by a third party is installed in the container guest (authenticated container) 1610 and operates as a guest node (authenticated node) 1611.
  • the authenticated container 1610 shares the topic “image” with the node 1601 via the proxy node 1612.
  • an unauthenticated image recognition application (APP4) provided by another third party is installed in a container guest (unauthenticated container) 1620 and operates as a guest node (unauthenticated node) 1621. Yes. It is assumed that each of the containers / guests 1610 and 1620 is activated according to the processing procedure shown in FIG. 9, for example. The unauthenticated container 1621 shares the topic “image” with the node 1601 via the proxy node 1622.
  • the node 1602 operating on the container host 1600 is assumed to have a high security level. Therefore, the node 1601 in which the camera image application operates and the node 1602 in which the image recognition application operates share the topic “/ high resolution image”, and the node 1601 directly uses the high resolution image acquired by the camera image application as the node 1602. Send to.
  • the authenticated node 1611 operating in the authenticated container 1610 has a medium security level. Therefore, in accordance with the security level, the topic shared by the node 1601 and the authenticated node 1611 is changed from “/ high resolution image” to “/ medium resolution image”.
  • the proxy manager (not shown in FIG. 16) activates the proxy node 1612
  • the topic name shared between the container host 1600 and the authenticated container 1610 is designated as “/ medium resolution image”.
  • the node 1601 performs processing for reducing the resolution of the original high-resolution image, transmits the medium-resolution image in response to the topic request from the proxy node 1612, and transmits the medium-resolution image to the authenticated node 1611. Will arrive.
  • the authenticated node 1621 operating in the unauthenticated container 1620 has a low security level. Therefore, according to the security level, the topic shared by the node 1601 and the unauthenticated node 1621 is changed from “/ high resolution image” to “/ low resolution image”. For example, when the proxy manager (not shown in FIG. 16) activates the proxy node 1622, the topic name shared between the container host 1600 and the unauthenticated container 1620 is designated as “/ low resolution image”. As a result, the node 1601 performs processing for degrading the resolution of the original high-resolution image, transmits the low-resolution image in response to the topic request from the proxy node 1622, and transmits the low-resolution image to the unauthenticated node 1621. Will arrive.
  • publisher / subscriber type communication is performed on the host side and the proxy node on the topic shared with the container guest on the container host side, and the guest node and proxy node on the container guest side Implement publisher / subscriber type communication.
  • the proxy node detects an abnormal value in the data received from the guest node that operates by installing the updated or added application, for example, the proxy node does not transmit the data to the host node on the container host side, Instruct to stop the application.
  • FIG. 17 illustrates a mechanism for stopping and restarting an application that outputs an output that does not conform to the specifications by using a method of grouping applications using containers.
  • Container host 1710 and container guest 1720 are running in their respective execution environments.
  • a monitoring framework (FW) 1740 that monitors the operation of each container operates in the execution environment.
  • a proxy node 1712 that specifies a topic “Topic1” shared with the container guest 1720 side is activated.
  • the guest node 1721 publishes Topic1 data, and the proxy node 1712 subscribes. At this time, when the proxy node 1712 detects an abnormal value in the data received from the guest node 1721, the proxy node 1712 notifies the monitoring framework 1740 of the abnormality.
  • the monitoring framework 1740 When the monitoring framework 1740 detects an abnormality of the container / guest 1720 or an abnormality of the guest node 1721 operating in the container / guest 1720, the monitoring framework 1740 stops the guest node 1721 and operates on the other container / guest 1730 side. Switch to the guest node 1731 to be instantly switched.
  • the container guest 1730 is a container started in an execution environment different from the implementation of the container guest 1720, or the guest node 1731 has a stable version of an application older than the guest node 1721. It is a node that installs and operates.
  • FIG. 18 shows an example of a processing sequence for stopping and restarting an application that outputs not conforming to the specifications.
  • a container guest (a guest node (not shown) that transmits and receives data as an application process) transmits data to the proxy node as a publisher (S1801).
  • Proxy node checks whether the data sent from the container guest is within the specified output value specification range. When the proxy node detects that the output value is out of the specification range, the proxy node sends data to the monitoring framework as a container guest (application guest process (not shown) ) Is notified (S1802).
  • the monitoring framework instructs to stop the container guest (guest node) that is the publisher that caused the abnormality (S1803).
  • the monitoring framework starts the container / guest in a different execution environment from the container / guest where the error occurred, and the application of the container / guest where the error occurred is the same as the container / guest.
  • An application that is stable in the old version is installed, and the container guest is operated as a stabilizing publisher (S1804).
  • publisher / subscriber type communication is performed on the host side and the proxy node on the topic shared with the container guest on the container host side, and the guest node and proxy node on the container guest side
  • publisher / subscriber type communication For example, when updating an application related to a guest node that is transmitting data as a publisher, the proxy node temporarily saves transmission data from the publisher, and the guest node is a proxy node after the update is completed. Reconnect to and resume data transmission.
  • the proxy node when updating an application while transmitting data to a guest node connected as a subscriber, for example, the proxy node temporarily stores received data, and after the update is completed, the proxy node is the guest node. Resume data transmission to.
  • FIG. 19 schematically shows a mechanism for temporarily storing transmission / reception data related to a guest node whose application is being updated.
  • the proxy node 1902 is activated by specifying a topic name shared with the container guest 1910, and the proxy node 1902 receives the data transmitted by the host node 1901 as the publisher.
  • transfer is performed from the proxy node 1902 to the guest node 1911 as a subscriber.
  • the guest node 1911 before the update is updated to the guest node 1912 by updating or adding an application or a program included in the application.
  • Application updater 1903 is a management process having a role of managing application updates.
  • the application updater 1903 temporarily stores the data transmitted from the host node 1901 that is the publisher in a queue provided by the proxy node 1902 before updating the program related to the guest node 1911 that is the subscriber. Instruct the proxy node 1902 to do so. As a result, even if a state change such as termination of the subscriber occurs, data transmitted from the host node 1901 which is the publisher is held in the proxy node 1902.
  • the application updater 1903 updates a program related to the guest node 1911 as a subscriber. Then, when the update of the program is completed, the application updater 1903 notifies the proxy node 1902 of the completion of the program update.
  • the proxy node 1902 When the proxy node 1902 receives the notification of the completion of the program update from the application updater 1903, the proxy node 1902 starts from the beginning of the transmission data from the publisher (host node 1901) that has been temporarily stored, and the subscriber (updated guest). Restart data transmission to node 1912).
  • FIG. 20 shows an example of a processing sequence for temporarily storing transmission / reception data related to a container guest (including a guest node to be updated) whose application is being updated, and restarting data transmission after the application is updated.
  • this figure shows a processing sequence example when the container guest being updated (guest node to be updated) operates as a publisher.
  • the user requests an update of a program related to the container guest (guest node before update) operating as a publisher (S2001).
  • Application updater temporarily saves the communication connection to the container guest that is the publisher before the update (guest node to be updated) in response to the update request from the user.
  • An instruction is given (S2002).
  • the proxy node In response to an instruction from the application updater, the proxy node temporarily saves data transmitted (published) from the container guest (guest node to be updated).
  • the application updater updates the program related to the guest node to be updated in the container guest that is the publisher (S2003).
  • the program is stored for each version in a specific directory, and the actual update process refers to a process of starting a new program.
  • the application updater notifies the proxy node of the update completion (S2004).
  • the publisher (updated guest node in the container guest) reconnects to the proxy node and resumes data transfer (publishing) (S2005).
  • the proxy node resumes data transmission from the temporarily stored data to a host node (not shown) in the container host.
  • FIG. 21 shows another example of a processing sequence for temporarily storing transmission / reception data related to a container guest (including a guest node to be updated) whose application is being updated and for restarting data transmission after updating the application. Yes.
  • this figure shows an example of a processing sequence when the container guest being updated (guest node to be updated) operates as a subscriber.
  • the user requests an update of a program related to the container guest (guest node before update) operating as a subscriber (S2101).
  • the application updater sends the connection received to the proxy node to the container guest (guest node before update) and the data received during the update.
  • An instruction is given to temporarily save (S2102).
  • the proxy node should be sent (published) from the host node (not shown) in the container host and forwarded to the container guest (guest node to be updated) Save data temporarily.
  • the application updater updates the program related to the subscriber (update target guest node in the container guest) (S2103).
  • the program is stored for each version in a specific directory, and the actual update process refers to a process of starting a new program.
  • the application updater notifies the proxy node of the update completion (S2104).
  • the proxy node is the data from the data temporarily saved during the update of the subscriber (the guest node to be updated included in the container guest) to the subscriber (the updated guest node in the container guest). Transmission is resumed (S2105). The proxy node resumes data transfer from the temporarily stored data to the container guest (updated guest node).
  • publisher / subscriber type communication is performed on the host side and the proxy node on the topic shared with the container guest on the container host side, and the guest node and proxy node on the container guest side Implement publisher / subscriber type communication.
  • By controlling the traffic amount by the proxy node an even network resource can be allocated to each container.
  • the proxy manager when starting a proxy node, the proxy manager responds to the user requesting installation of the application (or the characteristics of the application to be installed in the started container guest, the attribute of the application developer, etc.) In response, a limit on the amount of communication imposed on the guest node (for example, the number of transmission topics or the amount of transmission packets within a certain time) is set in the proxy server.
  • a communication amount limit corresponding to the corresponding application is set in each proxy node.
  • Figure 22 illustrates the throttling mechanism based on topic traffic.
  • the proxy node 2202 limits the amount of data communication from the guest node 2211 (publisher) on the container guest 2210 side to the host node 2201 (subscriber) on the container host 2200 side.
  • FIG. 23 shows an example of a processing sequence for performing throttling based on topic traffic.
  • the container guest operating as a publisher transmits data to the proxy node (S2301).
  • the proxy node imposes a traffic limit on the number of topics to be transmitted or the amount of packets to be transmitted within a certain period of time, and when data communication is performed from a container guest exceeding the traffic limit, The node is notified (S2302).
  • an application for data transmission is installed and operates as a host node 2401 (publisher), and an application for data reception is installed and operates as a host node 2402. .
  • the guest master 2411 in the container guest 2410 receives the topic name of the proxy node 2403 (publisher) targeted for the host node 2401 for data transmission, and data reception
  • the topic name of the proxy node 2404 (subscriber) targeted for the host node 2402 is registered.
  • the started container guest 2410 is an address or name space that is logically separated by the virtual NIC.
  • an application that does not satisfy a predetermined condition, such as provided by a third party, is installed and operates as a guest node 2412.
  • the guest node 2412 is registered in the guest master 2411 as a subscriber with the same topic name as the proxy node 2403, and is registered in the guest master 2411 as a publisher with the same topic name as the proxy node 2404.
  • the container guest 2410 is an address or name space that is logically separated by the virtual NIC, and therefore the container guest 2410 is isolated from the container host 2400.
  • the guest node 2412 can transmit / receive data to / from the container guest 2410 via the topic on the container guest 2410 side registered in the guest master 2411, that is, the container host 2400 side.
  • the guest node 2412 can receive transmission data of the host node 2401 from the proxy node 2403 registered in the guest master 2411, but operates on the container host 2400 (registered in the guest master 2411). Data cannot be received from the host node 2405.
  • the guest node 2412 can transmit data to the host node 2402 via the proxy node 2404 by transmitting data to the proxy node 2404 registered in the guest master 2411. Data cannot be transmitted to a host node 2405 operating on the container host 2400 (not registered in the guest master 2411).
  • the proxy node 2404 activated for receiving data from the guest node 2412 checks whether the received data from the guest node 2412 is within the specification range of the output value defined in advance for the application. Then, as described in the fifth embodiment, when it is detected that the output value is out of the specification range, corresponding processing such as stopping the guest node 2412 or restarting the guest node from an old, stable version of the application To implement.
  • the autonomous operation device 100 such as a robot, an autonomous vehicle, or an unmanned aircraft
  • many of them are classified into “recognition”, “situation understanding”, “action plan”, and “action control”.
  • the application program runs.
  • FIG. 25 shows a configuration example of the application program of the autonomous operation device 100 assuming a robot.
  • data acquired from a recognition application is input to an image analysis application “Image Analyzer” having a unique algorithm via “Input Adapter” which is a situation understanding application.
  • FIG. 26 a grouping using containers is introduced. Specifically, the container guest indicated by reference numeral 2601 is activated, and “Image Analyzer” that does not satisfy a predetermined condition is installed in this container guest 2601 to operate as a node isolated from the outside.
  • proxy nodes indicated by reference numbers 2602 and 2603 are prepared on the input side and the output side of “Image Analyzer”, respectively, and the data transmitted and received to “Input Adapter” and “Path planner” is limited. Do not output inappropriate image analysis results to “Path planner”.
  • the proxy node 2603 uses the monitoring framework shown in the third embodiment (FIG. 17), You may make it stop the node of "Image Analyzer”. Further, the proxy node 2603 may switch the node of “Image Analyzer” to a container including another node having an equivalent function by using a monitoring framework.
  • FIG. 27 shows a configuration example of an application program of the autonomous operation device 100 assuming an autonomous vehicle.
  • data output from “traffic rules assigned to the venue” and “space / state” which are situation understanding applications are input to the “location determination application for possible traffic”.
  • the “Transportable Location Judgment Application” satisfies the specified conditions and is guaranteed to perform normal operation, the result of the determination of the appropriate traffic location is output to the behavior planning application “Behavior plan” and “Behavior” “plan” can create an appropriate operation plan for an autonomous vehicle.
  • the “Transportable Location Judgment Application” does not meet the prescribed conditions and outputs an inappropriate judgment result to “Behavior plan” due to malicious or some bugs in the program, “Behavior plan” is appropriate for autonomous vehicles. It becomes impossible to create a proper operation plan.
  • FIG. 28 grouping using containers is introduced. Specifically, the container / guest indicated by reference numeral 2801 is activated, and a “transportable place determination application” that does not satisfy a predetermined condition is installed in the container / guest 2601 to operate as a node isolated from the outside. . Also, proxy nodes indicated by reference numbers 2802, 2803, and 2804 are prepared on the input side and the output side of the “transportable place determination application”, respectively, and “traffic rules assigned to the place” and “space / state” ”And“ Behavior plan ”are restricted, so that the judgment result of inappropriate traffic location is not output to“ Behavior plan ”. The proxy node 2804 uses the monitoring framework shown in the third embodiment (FIG.
  • the proxy node 2804 may switch the node of the “transportable place determination application” to a container including another node having an equivalent function by using the monitoring framework.
  • a grouping method called a container is introduced, and a constituent unit (application or the like) belonging to the container is introduced.
  • communication can be restricted within the container to which the software included in the constituent unit belongs.
  • processing based on the characteristics assigned to each configuration unit for information from the same source using grouping using containers for example, security / security of the configuration unit. It can be transmitted after the information is degraded according to the level).
  • transmission / reception data related to the component unit being updated is temporarily stored using grouping using a container, and connection is resumed from the transmission / reception data temporarily stored after the update.
  • the configuration unit and the software included in the configuration unit can be safely updated and added.
  • the limitation on the amount of data transmitted / received by the configuration unit is used in the physical level (packet amount) and logical level (publisher / subscriber communication) using grouping using containers. Even in a multi-tenant (when a configuration unit is provided to a plurality of vendors), it is possible to allocate an equal network resource to each.
  • the technology disclosed in this specification can be applied to autonomous operation devices such as robots, autonomous vehicles, and unmanned aerial vehicles (drones) that operate by installing application programs that realize autonomous or adaptive behavior. it can. Also, not limited to autonomously operating devices, various types of information processing devices that install applications or software included in applications, and various types of information that perform interprocess communication based on publisher / subscriber type communication models. Similarly, the technique disclosed in this specification can be applied to the processing apparatus.
  • autonomous operation devices such as robots, autonomous vehicles, and unmanned aerial vehicles (drones) that operate by installing application programs that realize autonomous or adaptive behavior. it can. Also, not limited to autonomously operating devices, various types of information processing devices that install applications or software included in applications, and various types of information that perform interprocess communication based on publisher / subscriber type communication models.
  • the technique disclosed in this specification can be applied to the processing apparatus.
  • an activation unit that activates a second container separated from the first container in which the first node operates, and activates the second node in the second container;
  • a proxy node that performs data communication based on a predetermined communication model with the first node in the first container and performs data communication based on the predetermined communication model with the second node in the second container
  • a proxy manager that launches An information processing apparatus comprising: (2)
  • the activation unit activates the second container including an address or a name space that is logically separated from the first container by a virtual NIC.
  • the predetermined communication model is a publisher / subscriber type communication model
  • the activation unit activates the proxy node by specifying a topic name shared with the second container.
  • the first node transmits data of a first topic provided by the proxy node in the first container;
  • the proxy node creates a second topic in the second container associated with the first topic and sends data received from the first node;
  • the second node receives data from the second topic;
  • the information processing apparatus according to (3) above.
  • the second node transmits data of a second topic provided by the proxy node in the second container;
  • the proxy node creates a first topic in the first container associated with the second topic and sends data received from the second node;
  • the first node receives data from the first topic;
  • the information processing apparatus according to any one of (3) or (4) above.
  • the first node is a node that operates by installing a first application that satisfies a predetermined condition in the first container.
  • the activation unit installs a second application that does not satisfy the predetermined condition in the second container and operates the second node.
  • the information processing apparatus according to any one of (1) to (5) above.
  • the predetermined condition includes at least one of an application developer, an application security level, and application operation verification.
  • the information processing apparatus processes the data to be transmitted to the proxy node according to the characteristics of the application operating as the second node.
  • the first node processes the data to be transmitted to the proxy node according to a topic name shared between the first container and the second container.
  • the information processing apparatus according to any one of (1) to (7).
  • a monitoring unit that monitors the operation of the second node is further provided.
  • the information processing apparatus according to any one of (1) to (9) above.
  • the proxy node checks data received from the second node and notifies the monitoring unit when an abnormality is detected.
  • the monitoring unit stops the second node in which an abnormality is detected.
  • the information processing apparatus according to any one of (10) or (11) above. (13)
  • the monitoring unit restarts an application that is more stable than the second node and operates the third node.
  • An application update unit that updates an application that operates as the second node is further provided,
  • the application update unit stores the transmission / reception data with the second node while the proxy node is updating the application, and connects to the second node from the stored transmission / reception data after the update of the application.
  • Resume The information processing apparatus according to any one of (1) to (13) above.
  • the proxy node imposes a traffic limit from the second node.
  • the information processing apparatus according to any one of (1) to (14).
  • the proxy node notifies the second node when the second node performs data transmission exceeding the limit.
  • the information processing apparatus according to (15) above.
  • An information processing method comprising: (18) An activation unit that activates a second container that is separated from the first container in which the first node operates, and activates the second node in the second container;

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Stored Programmes (AREA)

Abstract

アプリケーション又はアプリケーションに含まれるプログラムを処理する情報処理装置及び情報処理方法、並びにコンピュータ・プログラムを提供する。　情報処理装置は、第１のノードが動作する第１のコンテナとは分離された第２のコンテナを起動して、前記第２のコンテナで第２のノードを起動する起動部と、前記第１のコンテナにおいて前記第１のノードと所定の通信モデルに基づくデータ通信を行なうとともに、前記第２のコンテナにおいて前記第２のノードと前記所定の通信モデルに基づくデータ通信を行なうプロキシ・ノードを起動させるプロキシ管理部を具備する。

Description

情報処理装置及び情報処理方法、並びにコンピュータ・プログラム
　本明細書で開示する技術は、アプリケーション又はアプリケーションに含まれるプログラムを処理する情報処理装置及び情報処理方法、並びにコンピュータ・プログラムに関する。
　近年の人工知能（ＡＩ）や自動化技術の進歩は目覚ましく、さまざまな産業分野の作業現場に広く浸透してきている。例えば、ロボットは、例えば複数のリンクとリンク間を接続する関節で構成され、モータなどの関節駆動用のアクチュエータを用いて各関節を駆動することによってロボットは動作する。また、自動走行車は、センサにより車両周辺の情報を検出し、自律的な判断で衝突などを回避することができる。
　自律型若しくは適応制御型と呼ばれるロボットなどのシステムは、オペレータやマスタ装置からの指示を待つことなく、自律的若しくは適応的に行動制御を行なう。具体的には、ロボットなどの外部環境や内部状態を常時検証（あるいは、評価、モニタリング）し、外部環境又は内部状態の認識結果が所定の遷移条件に適合する動作を順次起動していくことで、現在置かれている状況に適した振舞いを実現する（例えば、特許文献１を参照のこと）。一方で、システムが複雑化することに伴い、１人の開発者によって開発・製造することが困難なため、複数の開発者によって開発されることが一般的になってきている。複数の開発者によって１つのシステムを開発する際には、以下に示すような幾つかの課題がある。
（１）さまざまな機能を持つセンサなどからの入力を受け、さまざまな態様で使用されるシステムの動作を管理するシステムについて、あらゆる事象を考慮して、事前にテストを行なうことが困難になってきている。
（２）複数の開発者の一部は、Ｌｉｎｕｘ（登録商標）オペレーティング・システム（ＯＳ）に代表されるようにオープンソースにおいて長期間にわたって開発されてきたライブラリなどを組み込んでいることがあり、ソフトウェアの品質管理が困難になってきている。
（３）システムの一部は、開発工程・製品動作確認テストの管理や基準などが異なる開発者によって開発される場合もあり得る。このため、万一、動作確認などが異なることに依拠して、製品動作時に動作不良、誤作動、又はセキュリティ上の課題が見つかった場合に、迅速且つ適切に対処することが以前よりも増して求められるようになってきている。
　一方、コンピュータ・システムがアプリケーション・プログラムを実行するとき、プロセッサ上で動作するコンピュータ・プロセス（以下、単に「プロセス」とも呼ぶ）が生成され、ＯＳによって管理される。ロボットのように実時間処理の反応速度の性能が重視される複雑なシステムを開発する目的では、スケジュールされた時間に各プロセスを実行することができるように設計されたリアルタイムＯＳ（ＲＴＯＳ）を使うこともできる。近年のＲＴＯＳにおいては、システム上で動作する複数のアプリケーション・プログラムに応じてＯＳが生成し、管理する個々のプロセス間の通信のために、例えばパブリッシャ／サブスクライバ型の通信モデルを利用することができる（例えば、特許文献２を参照のこと）。
　このような通信モデルを用いたＯＳでは、それぞれのアプリケーション・プログラムに応じて生成されるプロセスが、事前に特定の相手側アプリケーション・プログラムに応じて生成されるプロセスを知ることなく通信することが可能である。したがって、システムに新しいアプリケーション・プログラムを追加したり、実行時にアプリケーション・プログラムの一部を変更したりすることが比較的容易である。しかしながら、新しく追加され、実行時に変更されるアプリケーション・プログラムについて、あらかじめ実行性能やセキュリティ上の課題についてテストすることが難しくなるという課題もある。
特開２００３－３３４７８５号公報 特表２０１１－５１４０８７号公報
　本明細書で開示する技術の目的は、アプリケーション・プログラムを追加することが容易な通信方法を持つＯＳを装備し、アプリケーション・プログラム（又はアプリケーション・プログラムから生成されるプロセス）を所定の方法で他のアプリケーション・プログラム（又はプロセス）と分離して管理することができ、分離して管理されたプロセス間の通信方法により、上述した課題を解決することが可能となる情報処理装置及び情報処理方法、並びにコンピュータ・プログラムを提供することにある。
　本明細書で開示する技術は、上記課題を参酌してなされたものであり、その第１の側面は、
　第１のノードが動作する第１のコンテナとは分離された第２のコンテナを起動して、前記第２のコンテナで第２のノードを起動する起動部と、
　前記第１のコンテナにおいて前記第１のノードと所定の通信モデルに基づくデータ通信を行なうとともに、前記第２のコンテナにおいて前記第２のノードと前記所定の通信モデルに基づくデータ通信を行なうプロキシ・ノードを起動させるプロキシ管理部と、
を具備する情報処理装置である。ここで、前記第１のノードは所定の条件を満たす第１のアプリケーションを前記第１のコンテナにインストールして動作するノードである。前記起動部は、前記所定の条件を満たさない第２のアプリケーションを前記第２のコンテナにインストールして前記第２のノードを動作させる。
　前記起動部は、仮想ＮＩＣによって前記第１のコンテナとは論理的に分離されるアドレス又は名前空間からなる前記第２のコンテナを起動する。また、前記所定の通信モデルは、パブリッシャ／サブスクライバ型の通信モデルであり、前記起動部は、前記第２のコンテナと共有するトピック名を指定して前記プロキシ・ノードを起動する。
　そして、前記第１のノードが、前記プロキシ・ノードが前記第１のコンテナで提供する第１のトピックのデータを送信し、前記プロキシ・ノードが、前記第１のトピックに紐付けられた前記第２のコンテナに第２のトピックを作成して、前記第１のノードから受信したデータを送信し、前記第２のノードが、前記第２のトピックからデータを受信する。
　また、前記第２のノードが、前記プロキシ・ノードが前記第２のコンテナで提供する第２のトピックのデータを送信し、前記プロキシ・ノードが、前記第２のトピックに紐付けられた前記第１のコンテナに第１のトピックを作成して、前記第２のノードから受信したデータを送信し、前記第１のノードが、前記第１のトピックからデータを受信する。
　また、本明細書で開示する技術の第２の側面は、
　第１のノードが動作する第１のコンテナとは分離された第２のコンテナを起動して、前記第２のコンテナで第２のノードを起動する起動ステップと、
　前記第１のコンテナにおいて前記第１のノードと所定の通信モデルに基づくデータ通信を行なうとともに、前記第２のコンテナにおいて前記第２のノードと前記所定の通信モデルに基づくデータ通信を行なうプロキシ・ノードを起動させるプロキシ管理ステップと、
を有する情報処理方法である。
　また、本明細書で開示する技術の第３の側面は、
　第１のノードが動作する第１のコンテナとは分離された第２のコンテナを起動して、前記第２のコンテナで第２のノードを起動する起動部、
　前記第１のコンテナにおいて前記第１のノードと所定の通信モデルに基づくデータ通信を行なうとともに、前記第２のコンテナにおいて前記第２のノードと前記所定の通信モデルに基づくデータ通信を行なうプロキシ・ノードを起動させるプロキシ管理部、
としてコンピュータを機能させるようにコンピュータ可読形式で記述されたコンピュータ・プログラムである。
　本明細書で開示する技術の第３の側面に係るコンピュータ・プログラムは、コンピュータ上で所定の処理を実現するようにコンピュータ可読形式で記述されたコンピュータ・プログラムを定義したものである。換言すれば、本明細書で開示する技術の第３の側面に係るコンピュータ・プログラムをコンピュータにインストールすることによって、コンピュータ上では協働的作用が発揮され、第１の側面に係る情報処理装置と同様の作用効果を得ることができる。
　本明細書で開示する技術によれば、アプリケーション・プログラムの新規追加や変更が容易な通信方法を持つＯＳを装備し、アプリケーション・プログラム（又はプログラムから生成されるプロセス）を所定の方法で他のアプリケーション・プログラム（又はプロセス）と分離して管理することができ、分離して管理されたプロセス間の通信方法により、上述した課題を解決することが可能な情報処理装置及び情報処理方法、並びにコンピュータ・プログラムを提供することができる。
　なお、本明細書に記載された効果は、あくまでも例示であり、本発明の効果はこれに限定されるものではない。また、本発明が、上記の効果以外に、さらに付加的な効果を奏する場合もある。
　本明細書で開示する技術のさらに他の目的、特徴や利点は、後述する実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
図１は、制御プログラムの開発環境の一例を模式的に示した図である。 図２は、ネットワークを介した制御プログラムの分散開発環境を例示した図である。 図３は、ロボットを開発対象とする制御プログラムの開発環境を例示した図である。 図４は、自動走行車を開発対象とする制御プログラムの開発環境を例示した図である。 図５は、無人航空機（ドローン）を開発対象とする制御プログラムの開発環境を例示した図である。 図６は、自律動作装置１００の実機に搭載されるハードウェア並びにソフトウェアのアーキテクチャーの構成例を示した図である。 図７は、パブリッシャ／サブスクライバ型通信の仕組みを説明するための図である。 図８は、登録申請するアプリケーション・プログラムのソースコードを例示した図である。 図９は、コンテナ・ゲストを起動させるための処理手順を示したフローチャートである。 図１０は、コンテナ・ホスト１０００内にコンテナ・ゲスト１０１０が起動している様子を示した図である。 図１１は、コンテナ・ゲストを起動する際の処理シーケンス例を示した図である。 図１２は、コンテナ・ホストからコンテナ・ゲストへデータ送信を行なうための処理手順を示したフローチャートである。 図１３は、コンテナ・ゲストからコンテナ・ホストへデータ送信を行なうための処理手順を示したフローチャートである。 図１４は、コンテナ・ホストからコンテナ・ゲストへデータ送信を行なうための処理シーケンス例を示した図である。 図１５は、コンテナ・ネットワークの構成例を示した図である。 図１６は、コンテナ間で共有するトピックをコンテナ毎に変更する仕組みを説明するための図である。 図１７は、仕様に適合しない出力をするアプリケーションの停止と再起動を行なう仕組みを説明するための図である。 図１８は、仕様に適合しない出力をするアプリケーションの停止と再起動を行なうための処理シーケンス例を示した図である。 図１９は、アプリケーションを更新中のゲスト・ノードに関連する送受信データを一時的に保存する仕組みを模式的に示した図である。 図２０は、アプリケーションを更新中のゲスト・ノードに関連する送受信データの一時保存とアプリケーション更新後にデータ送信を再開する処理シーケンス例を示した図である。 図２１は、アプリケーションを更新中のゲスト・ノードに関連する送受信データの一時保存とアプリケーション更新後にデータ送信を再開する処理シーケンス例を示した図である。 図２２は、トピック通信量によるスロットリングの仕組みを説明するための図である。 図２３は、トピック通信量によるスロットリングを行なう処理シーケンス例を示した図である。 図２４は、コンテナを用いたグルーピングにより所定の条件を満たさないアプリケーションを隔離する仕組みを説明するための図である。 図２５は、ロボットを想定した自律動作装置１００のアプリケーション・プログラムの構成例を示した図である。 図２６は、ロボットを想定した自律動作装置１００のアプリケーション・プログラムの構成例（コンテナを用いたグルーピングを利用した例）を示した図である。 図２７は、自動走行車を想定した自律動作装置１００のアプリケーション・プログラムの構成例を示した図である。 図２８は、自動走行車を想定した自律動作装置１００のアプリケーション・プログラムの構成例（コンテナを用いたグルーピングを利用した例）を示した図である。
　以下、図面を参照しながら本明細書で開示する技術の実施形態について詳細に説明する。
　図１には、制御プログラムの開発環境の一例を模式的に示している。開発環境下には、制御プログラムによる制御対象となる自律動作装置（実機）１００と、この自律動作装置１００における制御プログラムを作成する開発装置２００が配置されている。
　ここで、自律動作装置１００は、自律的若しくは適応制御により自らの行動を制御する装置であり、ロボット、無人航空機、自律運転する自動車などさまざまな形態を含むものとする。
　自律動作装置１００は、当該システム１００全体の動作を統括的にコントロールする本体部１１０と、複数のモジュール部１２０－１、１２０－２などで構成される。図１では簡素化のため、３つのモジュール部しか描いていないが、４以上のモジュール部で構成される自律動作装置や、２以下のモジュール部しか備えていない自律動作装置も想定される。
　１つのモジュール部１２０は、アクチュエータ１２１と、プロセッサ１２２と、メモリ１２３と、センサ１２４と、通信モデム１２５を含んでいる。なお、簡素化のため図示を省略しているが、モジュール部１２０内の各部１２１～１２５は、内部バスにより相互接続されているものとする。
　アクチュエータ１２１は、例えば、関節を回転駆動するためのモータや、スピーカ用のドライバなどである。センサ１２４は、関節回転角度や角速度、スピーカの音量などのアクチュエータの出力状態を検出するセンサや、外力やその他の外部環境を検出するセンサなどである。
　プロセッサ１２２は、アクチュエータ１２１の駆動制御（モータ・コントローラ）やセンサ１２４からの検出信号の認識処理を始めとするモジュール部１２２内の動作を制御する。メモリ１２３は、アクチュエータの制御情報やセンサの検出値などを格納するためにプロセッサ１２２が使用する。
　通信モデム１２５は、当該モジュール部１２０と本体部１１０、又は当該モジュール部１２０と他のモジュール部の間で相互通信を行なうためのハードウェアであり、無線モデム又は有線モデムのいずれでもよい。例えばプロセッサ１２２は、通信モデム１２５を介して、本体部１１０からアクチュエータ１２１の駆動などの命令信号を受信したり、センサ１２４による検出データを本体部１１０に送信したりする。また、モジュール部１２０は、通信モデム１２５を介して、開発装置２００などの外部装置とも通信を行なうことができる。
　本体部１１０は、プロセッサ１１１と、メモリ１１２と、通信モデム１１３と、バッテリー１１４と、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ　Ｓｅｒｉａｌ　Ｂｕｓ）ポート１１５と、ＧＰＳ（Ｇｌｏｂａｌ　Ｐｏｓｉｔｉｏｎｉｎｇ　Ｓｙｓｔｅｍ）１１６を含んでいる。なお、簡素化のため図示を省略しているが、本体部１１０内の各部１１１～１１６は、内部バスにより相互接続されているものとする。
　プロセッサ１１１は、メモリ１１２に格納されているプログラムに従って、自律動作装置１００全体の動作を統括的にコントロールする。また、バッテリー１１４は、自律動作装置１００の駆動電源であり、本体部１１０並びに各モジュール部１２０に電源を供給する。
　通信モデム１１３は、本体部１２０と各モジュール部１２０の間で相互通信を行なうためのハードウェアであり、無線モデム又は有線モデムのいずれでもよい。例えばプロセッサ１１１は、通信モデム１１３を介して、各モジュール部１２０に対してアクチュエータ１２１の駆動などの命令信号を送信したり、各モジュール部１２０内でのセンサ１２２の検出値に基づく認識結果を受信したりする。また、本体部１１０は、通信モデム１１３を介して、開発装置２００などの外部装置とも通信を行なうことができる。
　ＵＳＢポート１１５は、ＵＳＢバス（ケーブル）を使って本体部１１０に外部機器を接続するために使用される。本実施形態では、ＵＳＢポート１１５を使って本体部１１０に開発装置２００を接続することを想定している。例えば、開発装置２００上で作成した制御プログラムを、ＵＳＢポート１１５を介して自律動作装置１００にインストールすることができる。なお、ＵＳＢは自律動作装置１００に外部装置を接続するインターフェース規格の一例であり、他のインターフェース規格に則って外部装置を接続するように構成することもできる。
　なお、図示を省略したが、本体部１１０と各モジュール部１２０などのハードウェア間を結合するデータ・バス並びに制御バスが存在する。
　開発装置２００は、例えばパーソナル・コンピュータで構成され、コンピュータ本体部２１０と、液晶パネルなどのディスプレイ２２０と、マウスやキーボードなどからなるユーザ・インターフェース（ＵＩ）部２３０を備えている。また、コンピュータ本体部２１０は、プロセッサ２１１、ＧＰＵ（Ｇｒａｐｈｉｃ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）２１２と、メモリ２１３と、ＵＳＢポート２１４と、通信モデム２１５を備えている。但し、ＧＰＵ２１２の機能がプロセッサ２１１内に含まれている構成例も考え得る。また、コンピュータ本体部２１０は、図示した以外のハードウェア構成要素を備えており、各部はバスにより相互接続されている。
　開発装置２００上では、ＯＳが動作している。プロセッサ２１１は、所望のアプリケーション・プログラムをメモリ２１２にロードして、ＯＳによって提供される実行環境下でアプリケーション・プログラムを実行することができる。
　本実施形態では、アプリケーション・プログラムの１つとして、自律動作装置１００の制御用プログラムを作成するための開発ツール・プログラムを想定している。この開発ツール・プログラムは、当該プログラムの実行に必要なデータとともに開発装置２００のメモリ２１３上に展開されている。
　開発ツール・プログラムは、ディスプレイ２２０の画面にプログラム開発用のＧＵＩ（Ｇｒａｐｈｉｃａｌ　Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ）を提示する。プログラムの開発者は、このＧＵＩ画面の内容を確認しながら、ユーザ・インターフェース２３０を介してデータやプログラムの入力を行なうことができる。また、開発ツール・プログラムは、作成した制御プログラムに関するコンパイラ、デバッガ、シミュレーション、３Ｄグラフィックス・アニメーションを用いた制御プログラムの動作確認のための機能などを備えているが、開発者はＧＵＩ画面上でこれらの機能の実行指示を行なうことができる。
　開発ツール・プログラムを用いて作成される制御プログラムは、自律動作装置１００の実機上の本体部１１０のプロセッサ１１１上で実行されるコントロール・プログラム並びにコントロール・プログラムが使用するパラメータなどのデータと、各モジュール部１２０のプロセッサ１２２においてアクチュエータ１２１の駆動を制御するためのコントロール・プログラム並びにコントロール・プログラムが使用するパラメータなどのデータで構成される。本明細書ではプログラム部分とデータを併せて「制御（コントロール）プログラム」と呼ぶこともある。
　開発ツール・プログラムを使って作成された制御プログラムは、メモリ２１３に格納される。また、メモリ２１３上の制御プログラムを、ＵＳＢポート２１４を介して自律動作装置１００側に転送することができる。あるいは、メモリ２１３上の制御プログラムを、通信モデム２１５を介して自律動作装置１００内のモジュール部１２０に転送することができる。
　また、開発装置２００上で開発ツール・プログラムを使って作成された制御プログラムを、３Ｄグラフィックス・アニメーションを用いた開発ツール・プログラムやデータ（以下、開発ツール用のプログラムとデータを併せて「開発ツール・プログラム」とも呼ぶ）を利用して、動作の検証や、制御用のデータやプログラムの修正を行なうことができる。一般に、この種の開発ツール・プログラムは、制御プログラムに従って自律動作装置１００の実機動作の３Ｄグラフィックス・アニメーションを生成する機能を備えており、開発者はディスプレイ２２０に表示される３Ｄグラフィックス・アニメーションを利用して、自身が開発した制御プログラムの動作の検証や、データやプログラムの修正を並行して行なうことができる。
　本実施形態では、開発ツール・プログラムが物理エンジンと呼ばれる機能を備えていることを想定している。物理エンジンは、現実の自律動作装置１００の動作を物理法則に基づいて物理現象を演算する機能を持つコンピュータ・プログラムであり、自律動作装置１００が持つ物理的な特性やさらには現実的な外部環境を考慮することによって、現実と同様の動作を生成して、その結果をディスプレイ２２０上に表示する。自律動作装置１００の実機に対し、実機のモータなどの代わりに物理エンジンを使って３Ｄグラフィックス・アニメーション空間中で動作する仮想的な自律動作装置１００のことを仮想機械（３Ｄグラフィックス・アニメーション用のデータを含むコンピュータ・プログラム及びデータ）とも呼ぶ。
　例えば、自律動作装置１００がロボットであれば、物理エンジンは、ロボットのアームの各リンクや関節の重量やモーメント、関節駆動用のアクチュエータの特性を考慮しつつ、ロボットを模して造られた仮想機械の制御プログラムの動作において、開発ツール・プログラム上で表現された仮想的な物理環境と仮想機械との物理作用（地面との接地や障害物との衝突など）を物理法則に基づいて計算することによって、あたかもロボットのアクチュエータが実際に駆動しているかのように、仮想機械全体の動作を計算し、ロボットの現実的な動作を仮想機械によって再現した３Ｄグラフィックス・アニメーションをディスプレイ２２０上に表示する。
　仮想機械は、物理エンジンと３Ｄグラフィックス・アニメーションを含む開発ツール・プログラム上で動作するようにされた制御プログラム及びデータであり、メモリ２１３に格納されている。望ましくは、実機１００の各モジュール部１２０のプロセッサ１２２で動作する単位で、制御プログラム及びデータがモジュール化されている。仮想機械をあたかも実機のように３Ｄグラフィックス空間上で動作させるために、仮想機械の制御プログラムは、実機１００のプロセッサ（例えば、モータ・コントローラ）１２２の動作に相当する機能を、プログラムの一部として実現する。また、この仮想機械の制御プログラムは、実機１００のモジュール部１２０毎のアクチュエータ１２１（例えば、モータ）に相当する動作を３Ｄグラフィックス・アニメーションで再現する物理エンジン機能を、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍｍｉｎｇ　Ｉｎｔｅｒｆａｃｅ）あるいは関数を使って呼び出すようにプログラムされている。さらに物理エンジンにおいて物理計算の際に使用されるデータ（アクチュエータに設定される制御パラメータや、リンクの重量、イナーシャなど）は、制御プログラムとともにメモリ２１３中に格納されており、制御プログラムの実行に伴って、メモリ２１３から読み出され、制御プログラム中で利用される。
　また、物理エンジン機能を実現するためのプログラム・モジュールに対して指示を出すためのＡＰＩあるいは関数を、実機すなわち自律動作装置１００側で動作している基本ＯＳが提供するものと同じものとすることにより、開発ツール・プログラムで作成したプログラムを、そのまま実機上のＯＳで動作させることができる。さらに、物理エンジン機能によって実際の物理現象を再現することができるので、開発ツール・プログラムを用いて開発したプログラムを、そのままＵＳＢポート２１４などを介して自律動作装置１００にアップロードして実行させることにより、開発ツール・プログラムで確認した動作を実機上でも実現することができる。
　また、開発ツール・プログラムを使って、モジュール部単位に分割して自律動作装置１００の制御プログラムを開発することもできる。この場合も同様に、モジュール部１２０単位で制御プログラムを自律動作装置１００にアップロードすることができる。例えば、モジュール部１２０－１のみハードウェア及び制御プログラムの開発を担当している開発者は、自分の開発装置２００を通信モデム２１５経由で自律動作装置１００の対応するモジュール部１２０－１に接続して、作成したプログラムやデータをモジュール部１２０－１内のメモリ１２３にアップロードすることもできる。
　モジュール部１２０単位でハードウェア及びプログラムの開発を複数の開発者又は複数の開発ベンダーで分担することで、分散開発環境下で自律動作装置１００全体の開発を進めることができる。
　図２には、ネットワークを介した制御プログラムの分散開発環境を例示している。図２に示す分散開発環境下では、モジュール毎に個別の開発者又は開発ベンダーに開発が委ねられている。但し、図２で言うモジュールは、図１に示した自律動作装置１００のハードウェア構成要素であるモジュール部１２０の他に、自律動作装置１００の制御ソフトウェアのモジュールを指す場合もある。
　自律動作装置１００の本体部又はモジュール部単位で制御プログラムの開発を任された各プログラム開発者は、それぞれモジュール開発用コンピュータを用いて、自分が担当する本体部１１０又はモジュール部１２０の制御プログラムを作成する。モジュール開発用コンピュータ上では、例えば上述した開発ツール・プログラムが動作している。各モジュール開発用コンピュータは、ネットワークに接続されている。そして、各プログラム開発者は、それぞれクラウド・サーバ上の共有ストレージ、自分専用のストレージ（すなわち、本体部開発者ストレージ、モジュール部開発者ストレージ）、あるいは専用サーバが備えるストレージにおいて、自己が開発した制御プログラムなどを提供してもよい。また、サーバなどのストレージにアカウントを有する管理者、開発者、顧客、あるいはユーザによって制御プログラムなどが共有されるようにしてもよい。
　自律動作装置１００の実機全体の制御プログラム開発を担当若しくは統括する開発者は、ネットワーク経由で本体部１１０及び各モジュール部１２０の制御プログラムの提供を受ける。具体的には、実機全体の開発者が使用する実機プログラム開発用コンピュータは、クラウド・サーバ上の共有ストレージ又は開発者ストレージ、専用サーバ、あるいは各開発者のモジュール開発用コンピュータとの直接通信によって、各々の制御プログラムを受信する。但し、制御プログラムの提供を受けるネットワークは、有線又は無線のいずれで構成されていてもよい。
　実機全体の開発者が使用する実機プログラム開発用コンピュータは、図１に示した開発装置２００に相当し、開発ツール・プログラム上で物理エンジンを用いた演算を行ない、且つ、３Ｄグラフィックス・アニメーションにより実機に相当する仮想機械の動作を表示できる機能を備えている。したがって、実機プログラム開発用コンピュータは、本体部１１０及びすべてのモジュール部１２０の制御プログラムを、開発ツール・プログラムが備える物理エンジン機能を利用して、仮想機械の３Ｄグラフィックス・アニメーションの表示などを通じて動作の確認・検証を行なうことができる。
　さらに、実機プログラム開発用コンピュータ上では、開発された制御プログラムの実行と並行して、各々の制御プログラムの修正を行なうことができる。したがって、実機１００全体の開発者と各モジュール部１２０を担当する開発者とで、実機１００体の制御プログラムを効率的に共同開発することにもなる。また、実機プログラム開発用コンピュータ上で修正した制御プログラムを、そのモジュール部を担当する開発者に再度提供して、最終的なプログラム製品を完成してもらうことが可能である。例えばクラウド・サーバ上に本体部１１０並びに各モジュール部１２０専用のストレージを配置するなどモジュール部１２０単位で制御プログラムを管理するようにすることで、共同開発を円滑に進めることができる。
　実機１００全体の開発者が使用する実機プログラム開発用コンピュータ上で動作が確認・検証された（すなわち、完成した）制御プログラムは、ＵＳＢポート２１４を介して開発装置２００から実機の自律動作装置１００に直接アップロードすることができる。あるいは、有線又は無線で構成されるネットワーク経由で、実機１００全体又はモジュール部１２０毎の制御プログラムを実機１００にアップロードすることもできる。
　また、制御プログラムを専用サーバから実機１００へアップロードするという形態も想定される。例えば、ある実機１００のユーザが自分のユーザ端末のユーザ・インターフェース（キーボード、マウス、タッチパネルなど）を介して自分が持つアカウントを用いて専用サーバにログインして、さらに実機１００にダウンロード又はアップロードする制御プログラムを選択して、ダウンロード又はアップロードを実施するようにしてもよい。
　図３には、自律動作装置１００の具体例として脚式のロボットを開発対象とする場合の制御プログラムの開発環境を例示している。図３では、単一の開発装置２００を用いてプログラム開発が行なわれるが、勿論、図２に示したようなネットワークを介した分散開発環境を利用することも可能である。
　脚式ロボット１００は、本体部１１０と、頭部や左右の脚部に相当するモジュール部１２０を有している。図示を省略するが、本体部１１０と、頭部や左右の脚部などの各モジュール部１２０などのハードウェア間を結合するデータ・バス並びに制御バスが存在する。
　なお、脚式ロボット１００は、上肢など図示しないモジュール部をさらに有していてもよい。また、少なくとも一部のモジュール部内のプロセッサやメモリなど機能が本体部と一体となって、本体部のプロセッサによってコントロールされるという実機構成の変形例も考えられる。
　本体部は、プロセッサと、メモリと、無線又は有線の通信モデムと、バッテリーと、ＵＳＢポートと、ＧＰＳを備えている。
　左右の脚のモジュール部１２０－２及び１２０－３は、アクチュエータとして、股関節や膝関節、足首などの関節駆動用（若しくは、歩行用）のモータ１２１を備え、プロセッサとしてモータの駆動を制御するモータ・コントローラ１２２を備えている。また、センサ１２４として、モータの出力側に発生する外力を検知するトルク・センサや、モータの出力側の回転角度を検出するエンコーダー、足裏部の接地センサなどを備えている。また、頭部のモジュール部１２０－１は、アクチュエータとしての頭部回転用のモータ１２１と、センサとしての周囲を撮像するイメージ・センサ１２４を備えている。
　図１と同様に、開発装置２００上で動作する開発ツール・プログラムを用いて、上記の脚式ロボット１００の本体部１１０並びに各モジュール部１２０の制御プログラムを作成し、さらに開発ツール・プログラム上で動作する物理エンジンの演算を利用し、仮想機械の３Ｄグラフィックス・アニメーションの表示などを通じて動作の確認・検証を行なうことができる。
　また、開発装置２００を用いて作成された制御プログラム、あるいは図２に示したような開発環境（あるいはその他の開発環境）において開発された実機１００全体の制御プログラムやモジュール部１２０毎の制御プログラムは、本体部１１０のＵＳＢポート１１５や各モジュール部１２０の通信モデム１２５を介した有線又は無線の通信によって、本体部１１０のメモリ１１２又は各モジュール部１２０のメモリ１２３にアップロードされる。そして、アップロードされたプログラムは、脚式ロボット１００の起動時などに適宜動作するようになっている。
　図４には、自律動作装置１００の他の具体例として自動走行車を開発対象とする場合の制御プログラムの開発環境を例示している。自動走行車１００は、自動運転技術が導入された自動車（あるいは、作業用又は輸送用などの無人運転車両）のことであるが、完全自動運転車の他、自動運転モードと手動運転モードを切り替え可能な自動車における自動運転モードで走行中の自動車も含むものとする。図４では、単一の開発装置２００を用いてプログラム開発が行なわれるが、勿論、図２に示したようなネットワークを介した分散開発環境を利用することも可能である。
　図４に示す自動走行車１００は、主制御部１１０と、モジュール部としてのトランスミッション制御モジュール部１２０－２並びに室内空調制御モジュール部１２０－１を有している。図示を省略するが、主制御部１１０と各モジュール部１２０などのハードウェア間を結合するデータ・バス並びに制御バス（ＣＡＮバスなど）が存在する。また、自動走行車１００は、通常、トランスミッション制御モジュール部１２０－２、室内空調制御モジュール部１２０－１以外にも図示しない多くのモジュール部を備えているが、説明の簡素化のため省略する。
　主制御部１１０は、プロセッサとしてのＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ：電子制御装置）１１１と、メモリ１１２と、通信モデム１１３と、ＥＣＵインターフェース１１５と、ＧＰＳ１１６と、バッテリー１１４を備えている。通信モデム１１３は、Ｗｉ－Ｆｉ（Ｗｉｒｅｌｅｓｓ　Ｆｉｄｅｌｉｔｙ）、ＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）、近距離無線通信などを想定している。また、ＥＣＵインターフェース１１５は、ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）バス（図示しない）へのインターフェースを想定しており、開発装置２００側とはイーサネット（登録商標）などの通信規格を利用して接続される。
　室内空調モジュール部１２０－１は、アクチュエータとしての空調１２１と、プロセッサとしての空調制御ＥＣＵ１２２と、メモリ１２３と、センサとしての室内温度センサ１２４と、Ｂｌｕｅｔｏｏｔｈ（登録商標）通信などの通信モデム１２５を備えている。例えば搭乗者が携帯するスマートフォンなどの情報端末（図示しない）とＢｌｕｅｔｏｏｔｈ（登録商標）通信により接続して、空調を制御することを想定している。
　トランスミッション制御モジュール部１２０－２は、アクチュエータとしての駆動輪用モータ１２１と、プロセッサとしてのトランスミッション制御ＥＣＵ１２２と、メモリ１２３と、センサとして速度・加速度センサ１２４や操舵角センサなどを備えている。
　なお、図４に示した構成例では、主制御部１１０並びに各モジュール部１２０にＥＣＵが配置されているが、主制御部１１０内のＥＣＵ１１１ですべてのモジュール部１２０を集中管理するように構成することも可能である。
　図１と同様に、開発装置２００上で動作する開発ツール・プログラムを用いて、上記の自動走行車１００の主制御部１１０、室内空調制御モジュール部１２０－１、並びにトランスミッション制御モジュール部１２０－２の制御プログラムを作成し、さらに開発ツール・プログラム上で動作する物理エンジン機能を利用し、仮想機械の３Ｄグラフィックス・アニメーションの表示などを通じて動作の確認・検証を行なうことができる。
　また、開発装置２００を用いて作成された制御プログラム、あるいは図２に示したような開発環境（あるいはその他の開発環境）において開発された実機１００全体の制御プログラムやモジュール部１２０毎の制御プログラムは、主制御部１１０のＥＣＵインターフェース１１５や各モジュール部１２０の通信モデムを介した有線又は無線の通信によって、主制御部１１０のメモリ１１２又は各モジュール部１２０のメモリ１２３にアップロードされる。そして、アップロードされたプログラムは、自動走行車１００の起動時などに適宜動作するようになっている。
　図５には、自律動作装置１００の他の具体例として無人航空機（ドローン）を開発対象とする場合の制御プログラムの開発環境を例示している。図５では、単一の開発装置を用いてプログラム開発が行なわれるが、勿論、図２に示したようなネットワークを介した分散開発環境を利用することも可能である。
　図５に示す無人航空機１００は、主制御部１１０と、モジュール部としてのカメラ制御モジュール部１２０－１並びにプロペラ制御モジュール部１２０－２を有している。図示を省略するが、主制御部１１０と各モジュール部１２０などのハードウェア間を結合するデータ・バス並びに制御バスが存在する。また、無線航空機１００には、カメラ制御モジュール部１２０－１並びにプロペラ制御モジュール部１２０－２以外のモジュール部が組み込まれていてもよい。
　主制御部１１０は、プロセッサ１１１と、メモリ１１２と、通信モデム１１３と、ＵＳＢポート１１５と、ＧＰＳ１１６と、バッテリー１１４を備えている。通信モデム１１３は、Ｗｉ－Ｆｉ、ＬＴＥ、近距離無線通信などの無線モデムを想定しており、操縦者が操作するリモート・コントローラ（図示しない）と通信を行なうようになっている。また、開発装置２００側とはＵＳＢポート１１５を利用して接続され、開発された制御プログラムのアップロードが行なわれる。
　カメラ制御モジュール部１２０－１は、センサとしてのカメラ部（イメージ・センサを含む）１２４と、アクチュエータとしてのカメラ部回転用モータ１２１と、プロセッサとしてのモータ・コントローラ１２２と、メモリ１２３と、通信モデム１２５を備えている。カメラ部回転用モータ１２１は、例えば水平方向に３６０度の範囲で回転が可能であり、さらにチルト回転が可能であってもよい。また、通信モデム１２５は、Ｗｉ－Ｆｉ、ＬＴＥ、近距離無線通信などの無線モデムを想定しており、操縦者が操作するリモート・コントローラやスマートフォン（図示しない）からのコマンドに従ってカメラ部１２４の回転や撮影を行なう。
　プロペラ制御モジュール部１２０－２は、アクチュエータとして例えば３つのプロペラ（回転用モータを含む）１２１と、プロペラ１２１の回転用モータの制御などを行なうプロセッサ１２２と、メモリ１２３と、センサとしてのプロペラ回転検出センサ１２４を備えている。
　図１と同様に、開発装置２００上で動作する開発ツール・プログラムを用いて、上記の無人航空機１００の主制御部１１０、カメラ制御モジュール部１２０－１、並びにプロペラ制御モジュール部１２０－２の制御プログラムを作成し、さらに開発ツール・プログラム上で動作する物理エンジン機能を利用し、仮想機械の３Ｄグラフィックス・アニメーションの表示などを通じて動作の確認・検証を行なうことができる。
　また、開発装置２００を用いて作成された制御プログラム、あるいは図２に示したような開発環境（あるいはその他の開発環境）において開発された実機１００全体の制御プログラムやモジュール部１２０毎の制御プログラムは、主制御部１１０や各モジュール部１２０の通信モデムを介した有線又は無線の通信によって、主制御部１１０のメモリ１１２又は各モジュール部１２０のメモリ１２３にアップロードされる。そして、アップロードされたプログラムは、無人航空機１００の起動時などに適宜動作するようになっている。
　図６には、自律動作装置１００の実機に搭載されるハードウェア並びにソフトウェアのアーキテクチャーの構成例を示している。
　最下層のハードウェアは、実機１００の筐体内に組み込まれている、本体部（若しくは主制御部１１０と複数のモジュール部１２０などの複数のハードウェア・モジュールからなる。また、各ハードウェア・モジュールを２以上の筐体に分散して配置して構成される実機も存在し得る。
　ＯＳは、各ハードウェア・モジュールを直接的に制御する。なお、ＯＳではなく、モジュール部１２０内のメモリ１２３にアップロードされた制御プログラムがハードウェア・モジュールを直接的に制御する場合もある（具体的には、プロセッサ１２２が制御プログラムを実行して、アクチュエータ１２１の駆動を制御する）。
　図１などに示したように、本体部１１０と複数のモジュール部１２０でハードウェア・アーキテクチャーが構成される自律動作装置１００においては、本体部１１０（のプロセッサ１１１）において当該システム１００全体を制御するメインのＯＳが動作して、各モジュール部１２０内で実行中の制御プログラムを直接的又は間接的に制御するように構成される。
　アプリケーション・プログラムの開発者は、システム（例えば、ミドルウェア）が提供するＡＰＩを用いてアプリケーション・プログラムを開発することができる。また、アプリケーション・プログラムの開発者は、システム・コールを利用してＯＳに対して指示を行なうようなプログラムを含めてアプリケーション・プログラムを開発することができる。ここで言うシステム・コールは、システム制御に関わる機能を利用するためのインターフェースである。システム・コールの例として、モジュール部内のプロセッサ（例えば、モータ・コントローラ）のパラメータを変更する、通信モデムにおけるネットワーク・アドレスの設定を行なう、といったものを挙げることができる。
　ロボットや自動走行車、無人航空機といった自律動作装置１００上では「認識」、「状況理解」、「行動計画」、「行動制御」に分類される多数のアプリケーション・プログラムが動作することが想定される。
　「認識」アプリケーション・プログラムは、ハードウェア層に含まれるカメラやその他のセンサで取得されるセンサ情報を認識処理するアプリケーション・プログラムである。「状況理解」アプリケーション・プログラムは、「認識」アプリケーション・プログラムによる認識結果に基づいて実機が現在置かれている状況を理解するアプリケーション・プログラムである。例えば、カメラで撮像した画像を分析する画像分析アプリケーション・プログラムは、「状況理解」アプリケーション・プログラムの一例である。なお、ＯＳが提供する実行環境下で動作するアプリケーション・プログラムは「プロセス」（あるいは「スレッド」）としてメモリ上で管理され、プロセッサ（ＣＰＵなど）において実行される。
　「行動計画」アプリケーション・プログラムは、「状況理解」アプリケーション・プログラムによって理解される、実機が現在置かれている状況に応じて、実機の行動を計画するアプリケーション・プログラムである。例えば、上記の画像分析アプリケーション・プログラムにより実機の周囲画像を分析した結果に応じて実機の移動経路を選択する経路選択アプリケーション・プログラムは、「行動計画」アプリケーション・プログラムの一例である。
　また、「行動制御」アプリケーション・プログラムは、「行動計画」アプリケーション・プログラムによって立案された行動計画を実現するための、ハードウェアの行動若しくは動作をコントロールするアプリケーション・プログラムである。例えば、経路選択アプリケーション・プログラムによって逐次選択される経路に従って、実機の進行方向や進行速度をコントロールするアプリケーション・プログラムや、進行方向や進行速度に応じて、ロボットの脚部や自動走行車の駆動輪、ドローンのプロペラの駆動をコントロールするアプリケーション・プログラムなどが「行動制御」アプリケーション・プログラムに相当する。
　ロボットや自動走行車、無人航空機といった自律動作装置１００上で行動又は動作を実現する際には、「認識」、「状況理解」、「行動計画」、「行動制御」に分類されるアプリケーション・プログラム間、若しくはプロセス間でデータ通信を行なう必要がある。
　他方、自律動作装置１００上で動作する多数のアプリケーション・プログラムを、装置の開発者、又はその開発者から委託を受けた単一のソフトウェア・ベンダーがすべて開発するのは困難であり、少なくとも一部のアプリケーション・プログラムは第三者からの提供を受けるというのが現実的である。また、図２に示したような分散開発環境下で、これら多数のアプリケーション・プログラムが開発されることが想定される。例えば、自動走行車において開発されるアプリケーション・プログラムを、駆動系制御（ＤＳＵなど）のように高い信頼性が要求されるアプリケーション・プログラムと、ユーザに対するサービスに関わるインフォテインメント（オーディオ機器、インターネット接続サービスなど）や車内環境制御（空調制御など）のようにユーザの利便性のために提供される汎用性の高いアプリケーション・プログラムの２種類に大別すると、前者のアプリケーション・プログラムを自社開発する一方、後者のアプリケーション・プログラムは第三者から提供を受けるようにすることができる。
　ところが、「認識」、「状況理解」、「行動計画」、「行動制御」という一連のフローの中で、第三者から提供されたアプリケーション・プログラムが、第三者の故意又は過失により誤ったデータを出力すると、システム全体で障害を発生することが懸念される。
　そこで、本明細書では、パブリッシャ／サブスクライバ型の非同期通信モデルを用いたシステムにおいて、コンテナと称されるグルーピング方法を導入して、コンテナに所属する構成ユニット（アプリケーション・プログラムなど）又は構成ユニットに含まれるソフトウェアの所属するコンテナ内に通信を制限する技術について、以下で提案する。この技術によれば、構成ユニット開発における独立性を維持しつつ、構成ユニット又は構成ユニットに含まれるソフトウェアの任意のグルーピングが可能である。
　また、本明細書では、同一のソースからの情報に対し、構成ユニット毎に割り当てる特性に応じた加工（例えば、構成ユニットのセキュリティ・レベルに合わせて情報を劣化する）を施した上で送信する技術についても、以下で併せて提案する。
　また、本明細書では、更新・追加された構成ユニットに含まれるソフトウェアがシステム動作中に誤作動を起こした場合には、その誤作動を検出し、システム動作を継続させながら、誤作動を起こしたソフトウェアを更新・追加する前に動作が保証されていたソフトウェアの動作に切り替える技術についても、以下で併せて提案する。
　また、本明細書では、更新中の構成ユニットに関連する送受信データを一時保存し、更新後に一時保存した送受信データから接続を再開することで、構成ユニットや構成ユニットに含まれるソフトウェアを安全に更新・追加する技術についても、以下で併せて提案する。
　また、本明細書では、構成ユニットが送受信するデータ量の制限を、物理レベル（パケット量）及び論理レベル（パブリッシャ／サブスクライバ通信で使用するトピック数）で実現し、マルチテナント（構成ユニットを複数の業者に提供する場合）においても、各々に均等なネットワーク・リソースを配分する技術についても、以下で併せて提案する。
　本実施形態において適用される、パブリッシャ／サブスクライバ型の通信モデルでは、メッセージを作成して送信する送信側のクライアント（プロデューサー）をパブリッシャと呼び、メッセージを受信する側のクライアント（コンシューマー）をサブスクライバと呼ぶ。パブリッシャは、誰に対して送るかは考えず、取り敢えずサーバに対してメッセージを発行する（パブリッシュする）。一方、サブスクライバは、サーバに対してメッセージ購読を申し込む（サブスクライブする）。そして、パブリッシャから送信されたメッセージの種類や属性を参照して、そのメッセージを欲しがっているサブスクライバに対して配信される。パブリッシャとサブスクライバはお互いを意識する必要がなく、また、サブスクライバは自分が必要とするメッセージのみを受け取ることができる。
　また、「トピック」と呼ばれる名前付きの論理チャネルを指定する非同期通信を行なう形態を、トピック・ベースのパブリッシャ／サブスクライバ型通信と呼ぶこともできる。パブリッシャから送信されたメッセージは、サーバ（マスタ）内で、トピックという送信先に登録される。そして、サーバは、パブリッシャが送信したメッセージに付与されているトピックと、サブスクライバによって受信登録されているトピックとのマッチングを行ない、そのトピックに対して配信を申し込んだ（すなわち、サブスクライブした）サブスクライバに配信する。なお、１又は複数のパブリッシャからのメッセージを、１つのトピックに登録することができる。また、１又は複数のサブスクライバが同じトピックに登録することができる。サブスクライバは、登録したトピックから、複数のパブリッシャのメッセージを受信することができる。同じトピックに登録した複数のサブスクライバが、そのトピックから同じメッセージを受信することができる。
　ここで、本明細書で使用する各用語「コンテナ」、「ノード」、「プロキシ」、「マスタ」、及び「トピック」について説明しておく。
コンテナ：
　コンテナは、仮想ＮＩＣ（ネットワーク・インターフェース・カード）によって論理的に分離されるアドレス又は名前空間、あるいは、それぞれのＮＩＣなどによって物理的に分離される名前空間である。コンテナは、ネットワーク・セグメントとして分離されるシステムの管理領域と捉えることもできる。コンテナには、「コンテナ・ホスト」と「コンテナ・ゲスト」の２種類がある。コンテナ・ホストは、信頼性のあるホスト・ノードのみが動作する空間である。一方、コンテナ・ゲストは、ホスト・ノードと分離しておく必要のあるゲスト・ノードのみが動作する空間である。例えば、第三者から提供されるアプリケーション・プログラムやライブラリ・プログラムをホスト・ノードから分離する必要があり、コンテナ・ゲストで動作させる（以下では、「アプリケーション・プログラム」及び「ライブラリ・・プログラム」をそれぞれ単に「アプリケーション」、「ライブラリ」と表記する）。また、動作保証や認証などにおいて信頼性が確保されていないアプリケーションやライブラリをホスト・ノードから分離する必要があり、コンテナ・ゲストで動作させる。なお、本明細書中では、２つのものが各々から独立して存在するという意味で「分離」という用語を主に使うが、「隔離」という用語を使うこともあり、「分離」の意味は「隔離」を含むものとする。
ノード：
　ノードは、アプリケーション、若しくは、コンテナ内でアプリケーションが動作するプロセスに相当する（以下、プログラム・コードとしては「アプリケーション」と呼び、システムのプロセッサによって実行されるプロセスとしては「ノード」と呼ぶことにする）。ノードは、自分が帰属するコンテナのマスタに対して、「トピック」と呼ばれる名前付き論理チャネルを指定してサブスクライブ要求又はパブリッシュ要求を送信する。そして、接続可能な相手が見つかる場合（具体的には、マスタにおいて、接続希望相手とのマッチングがとれる場合）には、通信相手のＩＤ情報（プロセスＩＤなど）を取得することにより、パブリッシャ／サブスクライバ型のメッセージング、及び、ＲＰＣ（Ｒｅｍｏｔｅ　Ｐｒｏｃｅｄｕｒｅ　Ｃａｌｌ）による一方向通信を行なうことができる。ノード（アプリケーション）は、新たなアプリケーションの開発者向けに、アプリケーション名と、アプリケーションが提供するトピック名、あるいはアプリケーションがデータをサブスクライブ又はパブリッシュのいずれを行なうのか、という情報をＡＰＩとして公開する。
　ノードは、「ホスト・ノード」と「ゲスト・ノード」に分類することができる。ホスト・ノードは、信頼性があるアプリケーション又はライブラリが、コンテナ・ホスト内で動作するプロセスである。一方、ゲスト・ノードは、第三者から提供されるアプリケーションやライブラリ、あるいは信頼性が確保されていないアプリケーションやライブラリなどが、コンテナ・ゲスト内で動作するプロセスである。以下では、処理フローの説明などにおいて「ホスト・ノード」と言う代わりに「コンテナ・ホスト」を使用し、「ゲスト・ノード」と言う代わりに「コンテナ・ゲスト」と記載することもある。この場合には、処理フローにおいて、「ホスト・ノード」と「ゲスト・ノード」が、それぞれの属する「コンテナ・ホスト」又は「コンテナ・ゲスト」の一部として通信処理などを行っていることに留意されたい。
プロキシ：
　プロキシ（プロキシ・ノード）は、以下の項目（ａ）～（ｄ）のマッピング・テーブルを管理する。プロキシの基本機能はノードに順ずるが、コンテナ・ゲストのマスタと通信する場合には、コンテナ・ゲストのアドレスを指定してネットワーク越しの通信を行なう。
（ａ）コンテナ・ホスト内のノード（サブスクライブ・ノード、パブリッシュ（アドバタイズ）・ノード）が指定できるトピック識別子
（ｂ）コンテナ・ゲスト内のノード（サブスクライブ・ノード、パブリッシュ（アドバタイズ）・ノード）が指定できるトピック識別子
（ｃ）コンテナ・ゲストのアドレス（例えば、ＩＰアドレス（一般的には、ＵＲＩ（ＵＲＬ）でもよい））
（ｄ）コンテナ・ゲストの認証状態（ｖｅｒｉｆｉｃａｔｉｏｎ）やセキュリティ・レベル、サブスクライバのプログラム更新処理を行なう間に送受信されるデータ
マスタ：
　マスタは、コンテナ内のノードからのサブスクライブ要求並びにパブリッシュ要求を受信し、トピック毎にノードの対応関係（すなわち、サブスクライブ・ノードとパブリッシュ（アドバタイズ）・ノードとの対応関係）を管理する。そして、マスタは、同じトピックに関してサブスクライブ・ノードとパブリッシュ（アドバタイズ）・ノードが揃った場合は、それぞれのノード（少なくとも、送信側であるパブリッシュ（アドバタイズ）・ノード）に対して、相手（受信側であるサブスクライブ・ノード）のＩＤ（プロセスＩＤ、プログラム名、通信先（ＩＰアドレス、ポートなど）など）を伝え、ノード間（ノードとプロキシ間を含む）のパブリッシャ／サブスクライバ型のメッセージング及びＲＰＣを開始させる。
　マスタは、「ホスト・マスタ」と「ゲスト・マスタ」に分類することができる。ホスト・マスタはコンテナ・ホスト内で動作するマスタであり、ゲスト・マスタはコンテナ・ゲスト内で動作するマスタである。
トピック：
　トピックは、メッセージをサブスクライブあるいはパブリッシュ（アドバタイズ）するノードで共通の名前付き論理チャネルを持ったデータ用の通信経路を作るために使われる、以下のような名前若しくは識別子（ＩＤ）である。ここで、コンテナ・ゲスト名は、ゲスト・アプリケーションの登録時に作成される。
トピック名（ＩＤ）＝“／”＋名前付き論理チャネル名
コンテナ・ゲスト用のトピック名＝“／”＋コンテナ・ゲスト名＋“／”＋名前付き論理チャネル名
アプリケーション動作環境としてのコンテナの利用
　次に、アプリケーションの動作環境としてコンテナを利用する場合について説明する。
　ある自律動作装置１００（例えば、ロボットや自動走行車、無人航空機（ドローン）など）向けに、自律動作装置１００上で動作する他のアプリケーションとともに動作する新たなアプリケーションを開発した開発者は、開発したアプリケーションをサーバに登録する。そして、開発したアプリケーションをコンテナと呼ばれる外部から論理的に分離されるアドレス又は名前空間からなる隔離された空間にインストールして、自律動作装置１００上で動作させることができる。
　コンテナにインストールされたアプリケーションは、ノードと呼ばれるプロセスとして動作する。上述したように、コンテナは、コンテナ・ホストとコンテナ・ゲストに分類される。
　コンテナ・ホストは、信頼性のあるホスト・ノードのみが動作するように設けられた空間である。例えば、以下に示すような所定の条件を満たすアプリケーションがコンテナ・ホストにインストールされ、ホスト・ノードとして動作する。
・自律動作装置１００本体の開発者によって開発されたアプリケーション
・一定以上のセキュリティ・レベルを持つアプリケーション
・動作検証済みのアプリケーション
　また、コンテナ・ゲストは、ホスト・ノードと分離しておく必要があるゲスト・ノードが動作するように設けられた空間である。例えば、上記のホスト・ノードとしての所定の条件を満たさないが、例えば以下に示すような所定の単位でグループ化されたアプリケーションが、コンテナ・ゲストにインストールされ、ホスト・ノードと分離して（コンテナ・ホストから独立して）、ゲスト・ノードとして動作する。コンテナによるグルーピング方法によって、アプリケーション開発における独立性を維持することができる。
・製造委託をしているソフトウェア会社単位のグループ
・第三者が製造したアプリケーション単位のグループ
・セキュリティ・レベルが一定以下のアプリケーションのグループ
・動作未検証のアプリケーションのグループ
　上記の所定の条件を満たすアプリケーションをコンテナ・ホストにインストールし、各々がホスト・ノードとして動作することで、まとまりのあるノード間のグループ通信が実現する。すなわち、コンテナ・ホスト内のノード間では、パブリッシャ／サブスクライバ型通信の仕組みを利用してデータの送受信が行なわれる。上述したように、パブリッシャ／サブスクライバ型通信では、ノードは、マスタと呼ばれるプロセスを介して、他のノードと通信することができる。この際、ノード間で通信するための通信経路として、所定のトピック名を指定することができる。トピック名を指定した通信は、名前の付いた通信路を用いた通信に相当する。
　パブリッシャ／サブスクライバ型通信の仕組みを利用したデータの送受信方法について、図７を参照しながら説明する。同図において、コンテナ・ホスト７００内に、パブリッシャ７０１及びサブスクライバ７０２となる各ノードと、マスタ７０３が動作している。
　まず、送信側であるパブリッシャ７０１は、アドバタイズとして、トピック名“ｂａｒ”と、自分のＩＤとしてホスト名（ｆｏｏ）とポート番号（１２３４）の組み合わせからなる情報“ｆｏｏ：１２３４”を、マスタ７０３に登録する（Ｓ７１０）。
　また、受信側であるサブスクライバ７０２は、サブスクライブとして、マスタ７０３に対して、トピック“ｂａｒ”の配信元の情報（ＸＭＬ／ＲＰＣ　ＵＲＩ）を要求する（Ｓ７１１）。
　マスタ７０３は、トピック“ｂａｒ”に関してサブスクライブ・ノードとパブリッシュ・ノードが揃ったので、サブスクライバ７０２に対して、配信元であるパブリッシャ７０１の情報として、“ｆｏｏ：１２３４”を通知する（Ｓ７１２）。
　サブスクライバ７０２は、マスタ７０３からの通知を受けると、パブリッシャ７０１に対して、ＴＣＰソケット通信によるトピック名“ｂａｒ”の購読要求（ｃｏｎｎｅｃｔ（“ｂａｒ”，ＴＣＰ））を送信する（Ｓ７１３）。
　これに対し、パブリッシャ７０１は、購読用のＴＣＰサーバのＵＲＩ（ｆｏｏ：２３４５）を通知する（Ｓ７１４）。
　そして、サブスクライバ７０２は、購読用のＴＣＰサーバに対して、トピック名“ｂａｒ”の購読のための接続を要求（ｃｏｎｎｅｃｔ（ｆｏｏ：２３４５））する（Ｓ７１５）。
　これに応答して、購読用のＴＣＰサーバ（ｆｏｏ：２３４５）からサブスクライバ７０２へ、トピック名“ｂａｒ”のトピックのＴＣＰ／ＩＰによる配信が行なわれる（Ｓ７１６）。
　トピック配信には、トピックの名前空間を共有するためのマスタ７０３への通信と、実際のデータ送受信のためのノード（すなわち、パブリッシャ７０１とサブスクライバ７０２）間のＰ２Ｐ通信を通す必要がある、という点に留意されたい。
　例えば、コンテナ・ホスト内に、データを提供する機能を持つ第１のノードと、データを利用して処理を行なう第２のノードが動作しているとする。具体的には、第１のノードはカメラの撮像画像を提供するアプリケーションであり、第２のノードは３次元マップを生成するアプリケーションである。
　第１のノードは、マスタに対して、「画像」というトピック名を指定して、データ送信（パブリッシュ又はアドバタイズ）の要求を送信する。一方、第２のノードは、マスタに対して、「画像」というトピック名を指定して、データ受信（サブスクライブ）の要求を送信する。ここで、パブリッシュ（又は、アドバタイズ）の要求とサブスクライブの要求は、どちらが先でもよく、また同時でも構わない。
　マスタは、同じトピック名「画像」に関してサブスクライブ・ノードとパブリッシュ（アドバタイズ）・ノードが揃ったので、パブリッシュ・ノードである第１のノードに対してはサブスクライブ・ノードである第２のノードのＩＤ（又は、名前あるいは送信先情報）を通知し、サブスクライブ・ノードである第２のノードに対してはパブリッシュ・ノードである第１のノードのＩＤ（又は、名前あるいは送信先情報）を通知する。これによって、第１のノードと第２のノードの間では、トピック名「画像」のデータの送受信を行なうことができるようになる。
　「画像」のようなトピック名は、システムにインストールされる各アプリケーション（若しくは、コンテナ・ホスト内で動作するホスト・ノード）にとっては、通信用インターフェースの役割を果たす。以下の表１に示すように、アプリケーション毎に関連するトピック名を定義して、言わばインターフェース情報として開発者向けに開示するようにすれば、新たなアプリケーションの開発者は、他のアプリケーションにデータを提供することを前提としたアプリケーションや、他のアプリケーションが提供するデータを受信することで処理を行なうようなアプリケーションの開発が容易になる。
Figure JPOXMLDOC01-appb-T000001
　上記の表１のような情報は、例えば、開発者向けの開発ツール・プログラムに関連付けられたデータベースにおいて管理するようにすることができる。このようなデータベースは、開発ツール・プログラムが動作するコンピュータ（例えば、図１中の開発装置２００）の管理下にあるストレージに格納して管理するようにしてもよいし、図２に示したようなネットワーク上に存在するサーバに関連付けられたコンピュータあるいはストレージに格納して管理するようにしてもよい。開発ツール・プログラムは、アプリケーションの開発中のユーザに対して、アプリケーション名を選択することで、関連するトピック名を表示するようにすることができる。
　開発ツール・プログラムに関連付けられたデータベースにおいて、アプリケーションで使われるトピック名を管理することにより、アプリケーション用のプログラム開発を効率化することができる。
　一例として、プログラムの開発者がプログラム開発環境で、プログラム編集画面上において、キーボードから、以下の文字列を入力しているとする（プログラムの入力途中であるため、「閉じ括弧“）”」が意図的に記載されていないことに留意されたい）。
　Ｒｅｇｉｓｔｅｒ＿Ｉｍａｇｅ　（“カメラ画像アプリケーション”
　開発ツール・プログラムには、表１に示したような情報がデータベース化して管理されている。ここで、「カメラ画像アプリケーション」というアプリケーション名がプログラム編集画面上で入力されているときに、開発ツール・プログラムがデータベースの登録アプリケーション名を認識し、「カメラ画像アプリケーション」という文字列を、例えば下線や色付け、反転するなどの方法によってハイライト表示するようにすることができる。
　ここで、ユーザがハイライト表示された「カメラ画像アプリケーション」という文字列を、例えばマウスのようなポインティング・デバイスを用いてクリック（選択）操作したことに応答して、そのアプリケーション名に対して関連付けられた「パブリッシャ（データ送信）用トピック名：画像」などの情報を、文字列「カメラ画像アプリケーション」から至近の位置に表示する。さらに、ユーザがトピック名「画像」が表示された場所を、再度マウスのようなポインティング・デバイスで選択すると、オート・コンプリーションの機能によって、下記のように入力することができ、開発効率を向上させることができる。
　Ｒｅｇｉｓｔｅｒ＿Ｉｍａｇｅ　（“カメラ画像アプリケーション”、“画像”
開発者によるアプリケーションの登録
　次に、コンテナ・ゲストを例として、新規アプリケーション開発者によるアプリケーションの事前登録申請について説明する。
　アプリケーションの事前登録申請に際して、まず、所定の事項を記載した登録申請用フォームを、登録申請処理用サーバに送信することにより、登録を完了する必要がある。登録申請用フォームには、少なくとも、新規アプリケーション名とホスト・アプリケーション名を記載する必要がある。他に申請により登録することができる情報としては、例えば、アプリケーションの開発者名（製造者名）、第三者機関が発行する認証情報、セキュリティ・レベル、開発されたアプリケーションの機能説明などが挙げられるが、これらに限定されるものではない。
　次に、アプリケーション申請用サーバに対して、開発したアプリケーションの登録申請を行なう。本実施形態では、サーバ上で動作する「プロキシ・マネージャ」というプロセスが、このアプリケーション申請の受信処理を行なうものとして説明する。プロキシ・マネージャへの申請が受理されると、新しいアプリケーションに対して、新規コンテナ名（新規のコンテナ・ゲストの名前）と、公開されたトピック名が割り当てられ、他の登録情報とともにプロキシ・マネージャに関連付けられたデータベースに登録される。申請受理時に割り当てられるトピック名は、コンテナ・ホスト中のアプリケーションとコンテナ・ゲストで動作するアプリケーションに対応するノードが他のアプリケーションに対応したノードとの間でデータ送受信を行なうために、利用することができる。以下の表２には、新しいアプリケーションに対して割り当てられ、データベースに登録される情報を例示している。
Figure JPOXMLDOC01-appb-T000002
　コンテナ名は、アプリケーションの申請時にプロキシ・マネージャによって割り当てられるという実施例の他に、コンテナ名を事前に割り当てるようにしてもよい。例えば、開発者が、アプリケーションの開発に先立ち、事前に開発者（製造者）登録を行なうことで、登録された開発者名（製造者名）に対してあらかじめコンテナ名を割り当てるようにしてもよい。コンテナ名が事前に割り当てられている場合には、上記のアプリケーション申請時に、事前に割り当てられたコンテナ名を申請用フォームに記載し、新規登録したアプリケーションとともに関連付けてプロキシ・マネージャに関連付けられたデータベースで管理するようにすることができる。
　アプリケーションの開発者は、開発済みのアプリケーション・プログラムを、登録された情報（表２を参照のこと）とともに構築することによって、アプリケーションのソースコード中にある“［登録トピック名］”を、“［コンテナ名］／［登録トピック名］”で置き換えることによって、システム上の所定のコンテナ・ゲストで動作するアプリケーション・プログラムのコードを生成することができる。なお、プログラム開発環境におけるプログラム編集画面上において、キーボードから文字列を入力している際に、開発支援のために、アプリケーション名に対して関連付けられた情報を、入力文字列から至近の位置に表示する例を示したが、このような開発支援も、表２のような登録申請情報が登録されたデータベースの情報を、プログラム開発環境に提供可能にすることによって実現できる。
　例えば、図８に示す、登録申請するアプリケーション・プログラムのソースコード中の８行目には、以下のようなコードがある。
Figure JPOXMLDOC01-appb-M000003
　ここで、ａｄｖｅｒｔｉｓｅは、このコードが、データ送信を行なうノードとして、“［登録トピック名］”のトピックを指定して、他のノードに対してデータ送信を要求するプログラム上の手続（ｐｒｏｃｅｄｕｒｅ）である。図８に示すアプリケーションが、表２に示す情報が登録されたアプリケーションに対応するプロセスであり、コンテナ・ゲストでゲスト・ノードとして動作する場合、８行目の命令は、このノードがパブリッシュ（データ送信）を行なうことを示している。
　この場合の他のノードはサブスクライバ（データ受信）である。よって、表２に示した登録情報のうち、「サブスクライバ（データ受信）用トピック名の項目に対応する、「認識結果」が、“［登録トピック名］”としてプログラムされていることになる。したがって、表２に示した登録情報を用いてプログラムのソースコードを編集し、構築することにより、８行目のコードは以下のように変更されて（“［登録トピック名］”が“／プロキシＡ／に認識結果”に書き換えられて）、プログラム・コードを生成する。
Figure JPOXMLDOC01-appb-M000004
　このようにして、プロキシ・マネージャに登録したトピックを、新規登録するアプリケーション・プログラムのソースコード中に容易に挿入することができる。すなわち、ユーザ（アプリケーションの開発者）が、登録申請情報の一覧を意識することなく、登録申請情報に基づいて、コンテナ・ゲスト上で動作するアプリケーション・プログラムを構築することができる。
　パブリッシャ／サブスクライバ型の非同期通信モデルを用いたシステムにおいて、コンテナと称されるグルーピング方法を導入して、所定の条件を満たさないアプリケーションを、コンテナ・ホスト上で動作するホスト・ノードとは分離して動作させる。これによって、第三者から提供されたような（所定の条件を満たさない）アプリケーション・プログラムから、第三者の故意又は過失により誤ったデータが出力されても、システム全体で障害が発生しないように隔離することができる。
コンテナ・ゲストとプロキシの起動処理
　システム（若しくは、ＯＳ）のブート処理では、システム上にはメモリから読み込まれたコンテナ・ホストが設定され、コンテナ・ホスト上には、所定の条件（前述）を満たすアプリケーションがインストールされ、ホスト・ノードとして動作する。言い換えれば、システムの初期状態では、信頼性のあるホスト・ノードが動作するコンテナ・ホストのみが設定されている。
　所定の条件を満たさないアプリケーションを、コンテナ・ホスト上で動作するホスト・ノードとは分離して動作させるためには、このようなアプリケーションをインストールするためのコンテナ・ゲストを起動する必要がある。
　コンテナ・ゲストの起動は、アプリケーション・ランチャ（Ａｐｐｌｉｃａｔｉｏｎ　Ｌａｕｎｃｈｅｒ）という役割を持った管理プロセスが実行する。アプリケーション・ランチャは、起動したコンテナ・ゲストへのＩＰアドレスの割り当てなど、コンテナ用の仮想ネットワーク管理も行なう。実際にコンテナの仮想ＮＩＣにＩＰアドレスの値を設定するのはプロキシ・マネージャであるが、各コンテナ・ゲストに割り当てるＩＰアドレスの管理（ＤＨＣＰサーバに類似する処理）はアプリケーション・ランチャが行なう。
　図９には、コンテナ・ゲストを起動させるための処理手順をフローチャートの形式で示している。ここでは、システム上には、既にコンテナ・ホストの設定が完了し、コンテナ・ホスト上で１以上のホスト・ノードが起動しており、さらにプロキシ・マネージャが起動していることを想定している。
　ユーザ（アプリケーションの開発者など）からコンテナ・ゲストの起動が要求されると、まず、アプリケーション・ランチャは、コンテナ・ゲスト用の仮想ネットワークが作成されているかどうかをチェックする（ステップＳ９０１）。
　まだコンテナ・ゲストが読み込まれておらず、コンテナ・ゲスト用のネットワークが作成されていない場合には（ステップＳ９０１のＮｏ）、以下の処理Ｓ９０２－１～Ｓ９０２－２により、コンテナ・ゲスト用の仮想ネットワークを作成する（ステップＳ９０２）。
Ｓ９０２－１）仮想ブリッジを作成する（ｂｒｃｔｌ　ａｄｄｒコマンド）。
Ｓ９０２－２）仮想ブリッジにＩＰアドレスなどのネットワーク設定をする（ｉｐ　ａｄｄｒコマンド）。
　続いて、仮想ブリッジに対して、仮想ブリッジのＩＰアドレスへのアクセス以外の全通信を拒否するファイアウォールを設定する（ｉｐｔａｂｌｅｓコマンド）（ステップＳ９０３）。ステップＳ９０２及びＳ９０３の処理により、コンテナ・ゲストは、他のコンテナ（例えば、コンテナ・ホストや、他のコンテナ・ゲスト）との間で、直接的な通信を行なうことを不可能にさせられる。
　コンテナ・ゲスト用の仮想ネットワークが既に作成されている場合（ステップＳ９０１のＹｅｓ）、あるいは、コンテナ・ゲスト用の仮想ネットワークが作成されていない場合であって（ステップＳ９０１のＮｏ）、上記ステップＳ９０２及びＳ９０３の処理を経てコンテナ・ゲスト用の仮想ネットワークが作成された後に、コンテナ・ゲスト用の仮想ＮＩＣを作成するとともに、コンテナ・ホスト側でもコンテナ・ゲスト用の仮想ＮＩＣと対向する仮想ＮＩＣを作成する（ステップＳ９０４）。例えば、コンテナ・ゲスト用の仮想ＮＩＣのＩＰアドレスは、１９２．１６８．９１．０／２４であり、コンテナ・ホスト側でこれに対向する仮想ＮＩＣのＩＰアドレスは１７２．１６．１０．０／１６であるとする。
　次いで、以下の処理Ｓ９０５－１～Ｓ９０５－６により、コンテナ・ゲスト用仮想ＮＩＣのネットワーク設定（ステップＳ９０５）を行なう。
Ｓ９０５－１）コンテナ・ゲスト用の仮想ＮＩＣと、コンテナ・ホスト側の対向する仮想ＮＩＣを作成する（ｉｐ　ｌｉｎｋコマンド）。
Ｓ９０５－２）コンテナ・ホスト側の対向する仮想ＮＩＣを起動する（ｉｐ　ｌｉｎｋコマンド）
Ｓ９０５－３）コンテナ・ホスト側の対向する仮想ＮＩＣを仮想ブリッジに割り当てる（ｉｐ　ｌｉｎｋコマンド）。
Ｓ９０５－４）コンテナ・ゲストのネットワーク名前管理ファイルを直接操作するために、コンテナ・ゲストの初期プロセスのネットワーク名前管理ファイルに対して、ｉｐ　ｎｅｔｎｓコマンドの操作用ディレクトリにシンボリック・リンクを貼る（ｌｎ　－ｓ／ｐｒｏｃ／［コンテナ・ゲスト初期プロセスＩＤ］／ｎｓ／ｎｅｔ　／ｖａｒ／ｒｕｎ／ｎｅｔｎｓ／［コンテナ・ゲスト初期プロセスＩＤ］）。なお、この処理で、コンテナ・ゲストへの仮想ＮＩＣの割り当てが完了する。
Ｓ９０５－５）上記Ｓ９０５－４で作成したシンボリック・リンクに対して、仮想ブリッジを割り当てる（ｉｐ　ｌｉｎｋコマンド）。
Ｓ９０５－６）上記Ｓ９０５－４で作成したシンボリック・リンクに対して、ネットワークを設定する（ｉｐ　ｎｅｔｎｓコマンド）。
　そして、コンテナ・ゲスト用仮想ＮＩＣのコンテナ・ゲストへの割り当てを行ない（ステップＳ９０６）、コンテナ・ホストがコンテナ・ゲストと共有するトピック名を指定して、プロキシ・ノードを起動して（ステップＳ９０７）、本処理を終了する。
　プロキシ・マネージャは、プロキシ・ノードのプログラムに引数を指定して、プロキシ・ノードを起動する。引数には、プロキシ・ノードを他のプロキシ・ノードから一意に識別するＩＤ、コンテナ・ホストのＩＰアドレス、コンテナ・ホスト側のホスト・マスタのＩＰアドレス、コンテナ・ホスト側のトピック名、コンテナ・ゲストのＩＰアドレス、コンテナ。ゲスト側のゲスト・マスタのＩＰアドレス、コンテナ・ゲスト側のトピック名、プロキシ・ノードが送受信するデータのキューのサイズ、データ送信を行なうノードを指定する。
　プロキシ・マネージャは、事前にデータベースに登録された情報（開発者によるアプリケーションの登録を参照）を使って、プロキシ・ノードを起動する。ネットワーク・セグメントに関する情報と開発者によるアプリケーションの登録時の情報をいずれかのデータベースで紐付けして管理してもよいが、データベース管理しなくても実現できる。但し、この紐付けしたデータベースを管理するのは、各プロキシ・ノードのプロセスではなく、プロキシ・マネージャ又はアプリケーション・ランチャ（アプリケーションを起動するソフトウェア）などである。
　図１０には、コンテナ・ホスト１０００内にコンテナ・ゲスト１０１０が起動している様子を示している。コンテナ・ホスト１０００には少なくとも１つのアプリケーションがインストールされたことにより、ホスト・ノード１００４が起動している。
　所定の条件を満たさないアプリケーションをシステムにインストールする際、コンテナ・ホスト１０００側で動作するホスト・ノード１００４とは分離して動作させるために、コンテナ・ゲスト１０１０を起動する。そして、アプリケーションはコンテナ・ゲスト１０１０にインストールされ、ゲスト・ノード１０１２として動作する。
　アプリケーション・ランチャ１００１は、図９に示した処理手順に従って、コンテナ・ゲスト１０１０の起動と、コンテナ・ゲスト１０１０へのＩＰアドレスの割り当てなどコンテナ用の仮想ネットワーク管理を行なう。また、アプリケーション・ランチャ１００１は、コンテナ・ゲスト１０１０を起動時に、プロキシ・マネージャ１００２を呼び出す。
　プロキシ・マネージャ１００２は、コンテナ・ゲスト１０１０の起動時に、プロキシ・ノード１００５を作成する。プロキシ・ノード１００５の起動時に、コンテナ・ホスト１０００側のホスト・マスタ１００３並びにコンテナ・ゲスト１０１０側のゲスト・マスタ１０１１の各々に、コンテナ・ホスト１０００とコンテナ・ゲスト１０１０間で共有するトピック名を指定する。
　プロキシ・マネージャ１００２は、例えばプロキシ・ノード１００５の管理ツールである。ユーザは、所定の条件を満たさないアプリケーションをシステムにインストールしたいときに、管理ツールのコンソール画面などを通じて、プロキシ・マネージャ１００２に対して、そのアプリケーションが使用するアプリケーション（ホスト・ノード）と必要なトピックを事前申請する。事前申請によるデータベースの登録情報の一例を、以下の表３に示しておく。これに対し、プロキシ・マネージャ１００２は、事前申請の登録情報に基づいて、コンテナ・ゲスト１０１２が利用するトピック名をデータベース情報から特定する。但し、コンテナ・ゲストが利用するトピック名を、ユーザ自身が事前申請時に指定できるようにしてもよい。
Figure JPOXMLDOC01-appb-T000005
　プロキシ・ノード１００５は、以下の項目（ａ）～（ｄ）のマッピング・テーブルをメモリ（キャッシュを含む）あるいは２次記録装置内のデータベースにおいて管理する（前述）。
（ａ）ホスト・ノード１００４が指定できるトピック識別子
（ｂ）ゲスト・ノード１０１２が指定できるトピック識別子
（ｃ）コンテナ・ゲスト１０１０のアドレス
（ｄ）コンテナ・ゲスト１０１０の認証状態（ｖｅｒｉｆｉｃａｔｉｏｎ）やセキュリティ・レベル、サブスクライバのプログラム更新処理を行なう間に送受信されるデータ
　図７を参照しながら説明したように、パブリッシャ／サブスクライバ型の通信モデルでは、パブリッシャがマスタにトピックを登録するとともに、サブスクライバがマスタに対してトピックを要求し、マスタにおいてパブリッシャとサブスクライバの対応関係がとれると（すなわち、名前が解決すると）、パブリッシャとサブスクライバ間でのトピック配信が実施される。
　図１０に示す仮想ネットワーク空間において、コンテナ・ホスト１０００側では、プロキシ・ノード１００５は、ホスト・ノードとして動作する。したがって、ホスト・ノード１００４とプロキシ・ノード１００５の一方がパブリッシャとなり他方がサブスクライバとなり、ホスト・マスタ１００３においてトピックの対応関係がとれると、ホスト・ノード１００４からプロキシ・ノード１００５へのトピック配信、又は、プロキシ・ノード１００５からホスト・ノード１００４へのトピック配信が実施される。
　一方、コンテナ・ゲスト１０１０側では、プロキシ・ノード１００５は、ゲスト・ノードとして動作する。したがって、ゲスト・ノード１０１２とプロキシ・ノード１００５の一方がパブリッシャとなり他方がサブスクライバとなり、ゲスト・マスタ１０１１においてトピックの対応関係がとれると、ゲスト・ノード１０１２からプロキシ・ノード１００５へのトピック配信、又は、プロキシ・ノード１００５からゲスト・ノード１０１２へのトピック配信が実施される。
　コンテナ・ホスト１０００とコンテナ・ゲスト１０１０は、仮想ＮＩＣによって論理的に分離したアドレス又は名前空間であり、ホスト・ノード１００４とゲスト・ノード１０１２間で直接的なトピック配信を行なうことはできない。但し、コンテナ・ゲスト１０１０と共有するトピック名を指定してプロキシ・ノード１００５を起動することにより、ホスト・ノード１００４とゲスト・ノード１０１２間で間接的にデータを送信することができる。
　ホスト・ノード１００４からゲスト・ノード１０１２へデータを送信する場合、プロキシ・ノード１００５は、コンテナ・ホスト１０００側では、ゲスト・ノード１０１２に対して配信すべきトピック名を、ホスト・マスタ１００３に対して要求する。そして、コンテナ・ホスト１０００側で、ホスト・ノード１００４が、ゲスト・ノード１０１２が要求するトピック名で、ホスト・マスタ１００３にパブリッシャとして登録すると、ホスト・マスタ１００３においてパブリッシャとサブスクライバの対応関係がとれ（名前が解決され）、ホスト・ノード１００４からプロキシ・ノード１００５へトピック配信が実施される。
　続いて、プロキシ・ノード１００５は、ホスト・ノード１００４からトピックを受信したことに応答して、コンテナ・ゲスト１０１０側では、パブリッシャとしてゲスト・マスタ１０１１にトピックを登録すると、ゲスト・マスタ１０１１においてパブリッシャとサブスクライバの対応関係がとれ（名前が解決され）、プロキシ・ノード１００５からゲスト・ノード１０１２へトピック配信が実施される。
　一方、ゲスト・ノード１０１２からホスト・ノード１００４へデータを送信する場合には、プロキシ・ノード１００５は、コンテナ・ゲスト１０１０側では、ゲスト・ノード１０１２がゲスト・マスタ１０１１にパブリッシャとして登録したトピック名を、ゲスト・マスタ１０１１に対して要求する。そして、ゲスト・マスタ１０１１においてパブリッシャとサブスクライバの対応関係がとれると（名前が解決されると）、ゲスト・ノード１０１２からプロキシ・ノード１００５へトピック配信が実施される。
　また、プロキシ・ノード１００５は、コンテナ・ホスト１０００側では、ゲスト・マスタ１０１１に対して要求したものと同じトピック名で、ホスト・マスタ１００３に対してパブリッシャとしてトピックを登録する。そして、ホスト・ノード１００４が同じトピック名でサブスクライバとして登録しているとすると、ホスト・マスタ１００３においてパブリッシャとサブスクライバの対応関係がとれるので（名前が解決されるので）、プロキシ・ノード１００５からホスト・ノード１００３へトピック配信が実施される。
　なお、コンテナ・ホスト１０００とコンテナ・ゲスト１０１０の名前空間は分離されているので、ホスト・マスタ１００３とゲスト・マスタ１０１１は同じトピック名を使用することができる。但し、例えばコンテナ・ゲスト１０１０内で、コンテナ・ホスト１０００と同じトピックのトピック名に対して、コンテナ・ホスト１０００側の通信相手を識別できるようなプレフィックス（例えば、“／ｈｏｓｔ１”など）などの識別情報を付けることで、トピックの通信相手をコンテナ・ゲスト１０１０側からも識別できるようにすることができる（コンテナ・ホスト１０００側でも同様である）。
　プロキシ・マネージャ１００２は、プロキシ・ノード１００５の管理ツールとして、ユーザからの事前申請の登録情報に基づいて、コンテナ・ゲスト１０１２が利用するトピック名をデータベースから特定する。例えば、事前申請するユーザの希望に応じて、コンテナ・ゲスト１０１２側で使用するトピック名にプレフィックスを付けるようにしてもよい。
　図１１には、コンテナ・ゲストを起動する際の処理シーケンス例を示している。図示の処理シーケンスは、基本的には、図９に示したフローチャートに従って実行される。
　ユーザは、所定の条件を満たさないアプリケーションをシステムにインストールしようとする際、プロキシ・ノードの管理ツールであるプロキシ・マネージャに対して、そのアプリケーションが使用するアプリケーション（ホスト・ノード）と必要なトピックを事前申請する（前述）。
　そして、ユーザは、アプリケーション・ランチャに対して、トピック名を指定して、コンテナ・ゲストの起動を要求する（Ｓ１１０１）。ここで言うユーザは、例えば、所定の条件を満たすアプリケーションのインストールを要求するユーザである。
　アプリケーション・ランチャは、コンテナ・ゲストを起動する前に、コンテナ・ゲストに割り当てる仮想ネットワークの情報を準備して、プロキシ・マネージャに通知する（Ｓ１１０２）。
　プロキシ・マネージャは、システムに対し、コンテナ・ゲスト用の仮想ネットワークの設定を依頼する（Ｓ１１０３）。これに対し、システムは、コンテナ・ゲスト用の仮想ネットワークの設定を完了すると、プロキシ・マネージャに通知する（Ｓ１１０４）。
　次いで、プロキシ・マネージャは、ユーザが事前申請してデータベースに情報登録されたトピック名でコンテナ・ホスト側と通信可能となるように、プロキシ・ノードを指定された個数分だけ作成する（Ｓ１１０５）。図１１では、簡素化のため、プロキシ・ノードを１個だけ描いている。そして、プロキシ・ノードは、起動すると、プロキシ・マネージャに通知する（Ｓ１１０６）。プロキシ・ノードを起動する際、コンテナ・ゲストと共有するトピック名を、コンテナ・ホスト側でも指定する。
　プロキシ・マネージャは、アプリケーション・ランチャに、コンテナ・ゲストの仮想ネットワークの設定が完了したこと、及び、プロキシ・ノードの起動が完了したことを、アプリケーション・ランチャに通知する（Ｓ１１０７）。
　アプリケーション・ランチャは、プロキシ・マネージャから通知を受け取ると、コンテナ・ゲストを起動する。そして、所定の条件を満たさないアプリケーションがコンテナ・ゲストにインストールされ、ゲスト・ノードとして動作する（Ｓ１１０８）。
　コンテナ・ホスト側では、プロキシ・ノードは、ホスト・ノードとして動作する。ホスト・ノードとプロキシ・ノードの一方がパブリッシャとなり他方がサブスクライバとなり、ホスト・ノードからプロキシ・ノードへのトピック配信、又は、プロキシ・ノードからホスト・ノードへのトピック配信が実施される。
　一方、コンテナ・ゲスト側では、プロキシ・ノードは、ゲスト・ノードとして動作する。ゲスト・ノードとプロキシ・ノードの一方がパブリッシャとなり他方がサブスクライバとなり、ゲスト・ノードからプロキシ・ノードへのトピック配信、又は、プロキシ・ノードからゲスト・ノードへのトピック配信が実施される。
　コンテナ・ホストとコンテナ・ゲストは、仮想ＮＩＣによって論理的に分離したアドレス又は名前空間であり、ホスト・ノードとゲスト・ノード間で直接的なトピック配信を行なうことはできない。但し、コンテナ・ゲストと共有するトピック名を指定してプロキシ・ノードを起動することにより、ホスト・ノードとゲスト・ノード間で間接的にデータを送信することができる。
　例えば、コンテナ・ホスト側で動作する「カメラ画像アプリケーション」に対応するホスト・ノードから、コンテナ・ゲスト側で動作する「画像認識アプリケーション」に対応するゲスト・ノードに対して、画像データを送りたい場合がある。プロキシ・ノードは、コンテナ・ホスト側では、ゲスト・ノードに対して配信すべきトピック名「画像」を、ホスト・マスタに対して要求する。そして、「カメラ画像アプリケーション」に対応するホスト・ノードが、ホスト・マスタに対し、トピック名「画像」でパブリッシャとして登録すると、ホスト・マスタにおいてパブリッシャとサブスクライバの対応関係がとれ（名前が解決され）、ホスト・ノードからプロキシ・ノードへトピック配信が実施される。
　コンテナ・ゲスト側では、「画像認識アプリケーション」に対応するゲスト・ノードが、ゲスト・マスタに対し、トピック名「画像」を要求するサブスクライバとして登録している。プロキシ・ノードは、ホスト・ノードからトピック「画像」を受信したことに応答して、コンテナ・ゲスト側では、パブリッシャとしてゲスト・マスタにトピック「画像」を登録すると、ゲスト・マスタにおいてパブリッシャとサブスクライバの対応関係がとれ（名前が解決され）、プロキシ・ノードからゲスト・ノードへトピック「画像」の配信が実施される。
　なお、上記では、便宜上、コンテナ・ホスト側でのトピック配信、コンテナ・ゲスト側でのトピック配信の順で説明したが、コンテナ・ホストとコンテナ・ゲストは並列して動作しているので、ホスト・ノードとゲスト・ノード間のデータ通信がどこから始まるかは任意である。
　また、コンテナ・ホストとコンテナ・ゲストの名前空間は分離されているので、ホスト・マスタとゲスト・マスタは同じトピック名を使用することができる。但し、例えばコンテナ・ゲスト内で、コンテナ・ホストと同じトピックのトピック名に対して、コンテナ・ホスト側の通信相手を識別できるようなプレフィックス（例えば、“／ｈｏｓｔ１”など）を付けることで、トピックの通信相手をコンテナ・ゲスト側からも識別できるようにすることができる（コンテナ・ホスト側でも同様である）。
　図１２には、コンテナ・ホストのホスト・ノードからコンテナ・ゲストのゲスト・ノードへデータ送信を行なうための処理手順をフローチャートの形式で示している。
　コンテナ・ホストのホスト・ノードは、プロキシ・ノードが提供するコンテナ・ホスト側の「トピック」に接続する（すなわち、ホスト・マスタに対してパブリッシャとして登録し、登録したトピックのサブスクライバに対して、トピックに対するデータを送信できるようにする）（ステップＳ１２０１）。
　そして、ホスト・ノードは、プロキシ・ノードが提供するコンテナ・ホスト側のトピックにデータを送信（パブリッシュ）する（ステップＳ１２０２）。
　これに対し、プロキシ・ノードは、自分が提供するコンテナ・ホスト側（ホスト・マスタ）のトピックのデータを受信（サブスクライブ）する（ステップＳ１２０３）。
　プロキシ・ノードは、コンテナ・ホストに紐付けられた仮想ネットワーク、すなわちコンテナ・ゲスト側（ゲスト・マスタ）でも、対応するトピックを作成する（すなわち、ゲスト・マスタに対してトピックのパブリッシャとして登録し、登録したトピックのサブスクライバに対して、トピックに対するデータを送信できるようにする）（ステップＳ１２０４）。
　そして、プロキシ・ノードは、作成したトピックに、コンテナ・ホスト側でホスト・ノードから受信したデータを送信（パブリッシュ）する（ステップＳ１２０５）。
　これに対し、ゲスト・ノードは、コンテナ・ゲスト側（ゲスト・マスタ）でプロキシ・ノードが作成したトピックからデータを受信（サブスクライブ）して（ステップＳ１２０６）、ホスト・ノードからの送信データを受け取ることができる。
　また、図１３には、コンテナ・ゲストのゲスト・ノードからコンテナ・ホストのホスト・ノードへデータ送信を行なうための処理手順をフローチャートの形式で示している。
　コンテナ・ゲストのゲスト・ノードは、プロキシ・ノードが提供するコンテナ・ゲスト側の「トピック」に接続する（すなわち、ゲスト・マスタに対してパブリッシャとして登録し、登録したトピックのサブスクライバに対して、トピックに対するデータを送信できるようにする）（ステップＳ１３０１）。
　そして、ゲスト・ノードは、プロキシ・ノードが提供するコンテナ・ゲスト側のトピックにデータを送信（パブリッシュ）する（ステップＳ１３０２）。
　これに対し、プロキシ・ノードは、自分が提供するコンテナ・ゲスト側（ゲスト・マスタ）のトピックのデータを受信（サブスクライブ）する（ステップＳ１３０３）。
　プロキシ・ノードは、コンテナ・ゲストに紐付けられた仮想ネットワーク、すなわちコンテナ・ホスト側（ホスト・マスタ）でも、対応するトピックを作成する（すなわち、ホスト・マスタに対してトピックのパブリッシャとして登録し、登録したトピックのサブスクライバに対して、トピックに対するデータを送信できるようにする）（ステップＳ１３０４）。
　そして、プロキシ・ノードは、作成したトピックに、コンテナ・ゲスト側でゲスト・ノードから受信したデータを送信（パブリッシュ）する（ステップＳ１３０５）。
　これに対し、ホスト・ノードは、コンテナ・ホスト側（ホスト・マスタ）でプロキシ・ノードが作成したトピックからデータを受信（サブスクライブ）して（ステップＳ１３０６）、ゲスト・ノードからの送信データを受け取ることができる。
　図１４には、コンテナ・ホスト側（図示しないホスト・ノード）からコンテナ・ゲスト側（図示しないゲスト・ノード）へデータ送信を行なうための処理シーケンス例を示している。
　プロキシ・ノードは、プロキシ・マネージャに事前登録されたコンテナ・ゲスト側のトピック名で、自分の仮想ネットワーク情報をゲスト・マスタに登録する（Ｓ１４０１）。
　また、パブリッシャであるコンテナ・ホスト（アプリケーションのプロセスとしてデータの送受信を行なうのは、図示しないホスト・ノード）は、プロキシ・マネージャに事前登録されたコンテナ・ホスト側のトピック名で、自分の仮想ネットワーク情報をホスト・マスタに登録する（Ｓ１４０２）。
　一方、サブスクライバであるコンテナ・ゲスト（アプリケーションのプロセスとしてデータの送受信を行なうのは、図示しないゲスト・ノード）は、プロキシ・マネージャに事前登録されたコンテナ・ゲスト側のトピック名がゲスト・マスタに登録されるまで、待機する。そして、コンテナ・ゲストは、ゲスト・マスタに所望のトピック名が登録されたことを確認できると、プロキシ・ノードの仮想ネットワーク情報を、ゲスト・マスタから取得する（Ｓ１４０３）。
　また、プロキシ・ノードは、プロキシ・マネージャに事前登録されたコンテナ・ホスト側のトピック名がホスト・マスタに登録されるまで、待機する。そして、プロキシ・ノードは、ホスト・マスタに所望のトピック名が登録されたことを確認できると、パブリッシャとなるコンテナ・ホストの仮想ネットワーク情報を、ホスト・マスタから取得する（Ｓ１４０４）。
　そして、サブスクライバであるコンテナ・ゲストは、ゲスト・マスタから取得したプロキシ・ノードの仮想ネットワーク情報に基づいて、プロキシ・ノードへ接続する（Ｓ１４０５）。この結果、プロキシ・ノードと、サブスクライバであるコンテナ・ゲストとの通信路が完成する。
　続いて、プロキシ・ノードは、ホスト・マスタから取得したホスト・ノードの仮想ネットワーク情報に基づいて、コンテナ・ホストへ接続する（Ｓ１４０６）。この結果、パブリッシャであるコンテナ・ホストとプロキシ・ノードとの通信路が完成する。
　コンテナ・ホスト側では、パブリッシャであるコンテナ・ホストが、プロキシ・ノードへ、トピックのデータを送信する（Ｓ１４０７）。
　また、コンテナ・ゲスト側では、プロキシ・ノードから、サブスクライバであるコンテナ・ゲストへ、トピックのデータを送信する（Ｓ１４０８）。
　なお、コンテナ・ゲスト側（ゲスト・ノード）からコンテナ・ホスト側（ホスト・ノード）へデータ送信を行なう処理シーケンスについては図示を省略するが、同様の手順により実施できることを理解されたい。
　ここまで説明してきたように、各アプリケーションを、種別に応じて（例えば、所定の条件を満たすか否かに応じて、あるいは、条件を適合するレベルに応じて）、仮想ＮＩＣによって論理的に分離されるコンテナを用いてグルーピングすることができる。コンテナ毎に仮想ネットワークが作成され、各コンテナ（コンテナ・ゲスト）は外部（コンテナ・ホスト）から遮断される。また、各コンテナには仮想ＮＩＣが割り当てられ、コンテナ・ホスト側には対向する仮想ＮＩＣが作成される。
　図１５には、仮想ＮＩＣを用いたコンテナ・ネットワーク１５００の構成例を示している。図示のコンテナ・ネットワーク１５００には、複数のコンテナ・グループ１５１０、１５２０などが形成され、各コンテナ・グループ１５１０、１５２０などの内には１以上のコンテナ（コンテナ・ゲスト）が起動している。例えば、コンテナ・グループ１５１０内ではコンテナ１５１１及びコンテナ１５１２が起動し、コンテナ・グループ１５２０内ではコンテナ１５２１が起動している。コンテナは、例えば図９に示した処理手順に従って起動されるものとする。
　各コンテナには仮想ＮＩＣが割り当てられ、コンテナ・ホスト側の対向する仮想ＮＩＣと通信することができる。図１５に示す例では、コンテナ・グループ１５１０内では、コンテナ１５１１には仮想ＮＩＣ１５１１´が割り当てられるとともに、コンテナ１５１１には仮想ＮＩＣ１５１２´が割り当てられる。また、コンテナ・グループ１５２０内では、コンテナ１５２１に仮想ＮＩＣ１５２１´替わりらてられる。また、コンテナ・ホスト側には、各コンテナの仮想ＮＩＣと対向する仮想ＮＩＣ１５０１が作成されている。コンテナ・ホスト側の仮想ＮＩＣ１５０１と各コンテナ・グループ内のコンテナ毎の仮想ＮＩＣ１５１１´、１５１２´、１５２１´、…とは、コンテナ・グループ毎に作成された仮想ブリッジ１５０１－ａ、１５０１－ｂなどを介して通信することができる。
　コンテナ・グループ１５１０、１５２０、…は、例えばアプリケーションの開発者（ソフトウェア・ベンダ）毎に割り当てられる。したがって、１つのコンテナ・グループは、（同一の開発者により開発されるなど）条件が揃ったアプリケーションをインストールして、ノードとして動作させるためのコンテナの集合からなる。
　図１５中、通信許可範囲を点線で囲って示している。コンテナ・グループ内では、各コンテナで動作するノード間は、互いのコンテナに割り当てられた仮想ＮＩＣによって通信することができる。例えば、コンテナ１５１１で動作するノードとコンテナ１５１２で動作するノードは、各々に割り当てられた仮想ＮＩＣ１５１１´及び１５１２´によって通信可能である。他方、別のコンテナ・グループに属するコンテナで動作するノード間は、サブネットが分かれているため、通信することができない。例えば、コンテナ１５１２で動作するノードと、コンテナ１５２１で動作するノード間は、各々に割り当てられた仮想ＮＩＣ１５１２´及び１５２１´で通信することは不可能である。
　例えば、パケット・フィルタリング及びネットワーク・アドレス変換 （ＮＡＴ） 機能の設定を操作するｉｐｔａｂｌｅｓコマンドなどを利用して、上記のような通信許可範囲の制限を実現することができる。
　各アプリケーションを仮想ＮＩＣによって論理的に分離されるコンテナを用いてグルーピングするシステムでは、同一のソースからの情報に対し、アプリケーション毎に割り当てる特性に応じた加工を施した上で送信することができる。例えば、送信先となるアプリケーション毎のセキュリティ・レベルに併せて情報を劣化させる。具体的には、コンテナ間で共有するトピックをコンテナ毎に変更することにより、実現することができる。コンテナ毎に共有トピックを変更する例について、図１６を参照しながら説明する。
　図１６では、カメラ画像アプリケーションから画像認識アプリケーションへ画像を配信することを想定しており、共有するトピック名を「画像」とする。
　コンテナ・ホスト１６００側には、所定の条件を満たすカメラ画像アプリケーション（ＡＰＰ１）及び画像認識アプリケーション（ＡＰＰ２）がインストールされて、それぞれノード１６０１及びノード１６０２として動作している。
　また、第三者から提供された、認証済みの画像認識アプリケーション（ＡＰＰ３）が、コンテナ・ゲスト（認証済みコンテナ）１６１０にインストールされて、ゲスト・ノード（認証済みノード）１６１１として動作している。認証済みコンテナ１６１０は、プロキシ・ノード１６１２を介して、ノード１６０１とトピック「画像」を共有している。
　さらに、他の第三者から提供された、未認証の画像認識アプリケーション（ＡＰＰ４）が、コンテナ・ゲスト（未認証コンテナ）１６２０にインストールされて、ゲスト・ノード（未認証ノード）１６２１として動作している。なお、各コンテナ・ゲスト１６１０、１６２０は、例えば図９に示した処理手順に従って起動されているものとする。未認証コンテナ１６２１は、プロキシ・ノード１６２２を介して、ノード１６０１とトピック「画像」を共有している。
　コンテナ・ホスト１６００で動作するノード１６０２は、セキュリティ・レベルが高いことが想定される。そこで、カメラ画像アプリケーションが動作するノード１６０１と、画像認識アプリケーションが動作する１６０２とはトピック「／高解像度画像」を共有し、ノード１６０１は、カメラ画像アプリケーションが取得した高解像度の画像をそのままノード１６０２に送信する。
　一方、認証済みコンテナ１６１０で動作する認証済みノード１６１１は、中程度のセキュリティ・レベルである。そこで、セキュリティ・レベルに合わせて、ノード１６０１と認証済みノード１６１１で共有するトピックを「／高解像度画像」から「／中解像度画像」に変更する。例えば、プロキシ・マネージャ（図１６では図示しない）がプロキシ・ノード１６１２を起動するときに、コンテナ・ホスト１６００と認証済みコンテナ１６１０間で共有するトピック名を「／中解像度画像」に指定する。その結果、ノード１６０１は、元の高解像度画像の解像度を低下する加工を施して、プロキシ・ノード１６１２からのトピックの要求に対して中解像度画像を送信し、認証済みノード１６１１には中解像度画像が届くことになる。
　また、未認証コンテナ１６２０で動作する認証済みノード１６２１は、セキュリティ・レベルが低い。そこで、セキュリティ・レベルに合わせて、ノード１６０１と未認証ノード１６２１で共有するトピックを「／高解像度画像」から「／低解像度画像」に変更する。例えば、プロキシ・マネージャ（図１６では図示しない）がプロキシ・ノード１６２２を起動するときに、コンテナ・ホスト１６００と未認証コンテナ１６２０間で共有するトピック名を「／低解像度画像」に指定する。その結果、ノード１６０１は、元の高解像度画像の解像度を劣化する加工を施して、プロキシ・ノード１６２２からのトピックの要求に対して低解像度画像を送信し、未認証ノード１６２１には低解像度画像が届くことになる。
　図１６に示した、コンテナのセキュリティ・レベルに応じた共有トピックの変形例を、以下の表４にまとめておく。
Figure JPOXMLDOC01-appb-T000006
　各アプリケーションを仮想ＮＩＣによって論理的に分離されるコンテナを用いてグルーピングするシステムでは、更新又は追加されたアプリケーションがシステム動作中に誤動作を起こした場合に、その誤動作を検出して、そのアプリケーションの停止と再起動を行なうことができる。
　想定するシステムでは、コンテナ・ホスト側では、コンテナ・ゲストと共有するトピックに関して、ホスト・ノードとプロキシ・ノードでパブリッシャ／サブスクライバ型通信を実施し、コンテナ・ゲスト側では、ゲスト・ノードとプロキシ・ノードでパブリッシャ／サブスクライバ型通信を実施する。そして、プロキシ・ノードは、例えば更新又は追加されたアプリケーションをインストールして動作するゲスト・ノードから受信したデータに異常値を検出すると、コンテナ・ホスト側でホスト・ノードにはデータを送信せず、アプリケーションの停止を指示する。
　図１７には、コンテナを用いてアプリケーションをグルーピングする方法を利用して、仕様に適合しない出力をするアプリケーションの停止と再起動を行なう仕組みを図解している。
　コンテナ・ホスト１７１０と、コンテナ・ゲスト１７２０がそれぞれの実行環境で起動している。また、各コンテナの動作を監視する監視フレームワーク（ＦＷ）１７４０が、その実行環境で動作している。
　コンテナ・ホスト１７１０側では、所定の条件を満たすアプリケーションをインストールして、ホスト・ノード１７１１が動作している。一方、コンテナ・ゲスト１７２０側では、所定の条件を満たさないアプリケーションをインストールして、ゲスト・ノード１７２１が動作している。また、コンテナ・ホスト１７１０側では、コンテナ・ゲスト１７２０側と共有するトピック“Ｔｏｐｉｃ１”を指定するプロキシ・ノード１７１２が起動している。
　コンテナ・ゲスト１７２０側で、ゲスト・ノード１７２１がＴｏｐｉｃ１のデータをパブリッシュするとともに、プロキシ・ノード１７１２がサブスクライブする。このとき、プロキシ・ノード１７１２は、ゲスト・ノード１７２１から受信したデータに異常値を検出すると、監視フレームワーク１７４０に異常を通知する。
　監視フレームワーク１７４０は、コンテナ・ゲスト１７２０の異常、又は、コンテナ・ゲスト１７２０で動作するゲスト・ノード１７２１の異常を検知すると、ゲスト・ノード１７２１を停止させるとともに、他のコンテナ・ゲスト１７３０側で動作するゲスト・ノード１７３１に瞬時に切り替える。
　コンテナ・ゲスト１７３０は、コンテナ・ゲスト１７２０とは実装が異なる実行環境で起動したコンテナであり、又は、ゲスト・ノード１７３１は、ゲスト・ノード１７２１よりも古い、安定したバージョンのアプリケーションをコンテナ・ゲスト１７３０にインストールして動作するノードである。
　図１８には、仕様に適合しない出力をするアプリケーションの停止と再起動を行なうための処理シーケンス例を示している。
　まず、コンテナ・ゲスト（アプリケーションのプロセスとしてデータの送受信を行なうのは、図示しないゲスト・ノード）が、パブリッシャとして、プロキシ・ノードへデータ送信する（Ｓ１８０１）。
　プロキシ・ノードは、コンテナ・ゲストから送信されたデータが、あらかじめ規定された出力値の仕様範囲内かどうかをチェックする。そして、出力値の仕様範囲外であることを検知すると、プロキシ・ノードは、監視フレームワークに対し、パブリッシャであるコンテナ・ゲスト（アプリケーションのプロセスとしてデータの送受信を行なうのは、図示しないゲスト・ノード）の異常を通知する（Ｓ１８０２）。
　監視フレームワークは、プロキシ・ノードからの異常通知に応答して、異常を起こしたパブリッシャであるコンテナ・ゲスト（ゲスト・ノード）の停止を指示する（Ｓ１８０３）。
　また、監視フレームワークは、異常を起こしたコンテナ・ゲストとは異なる実行環境でコンテナ・ゲストを起動し、そのコンテナ・ゲスト内に、異常を起こしたコンテナ・ゲストのアプリケーションとは同じであるが、古いバージョンで安定したアプリケーションをインストールして、コンテナ・ゲストを安定化パブリッシャとして動作させる（Ｓ１８０４）。
　各アプリケーションを仮想ＮＩＣによって論理的に分離されるコンテナを用いてグルーピングするシステムでは、更新中のアプリケーションに関連する送受信データを一時的に保存し、更新後に一時保存した送受信データから接続を再開することで、アプリケーションやアプリケーションに含まれるプログラムを安全に更新又は追加することができる。
　想定するシステムでは、コンテナ・ホスト側では、コンテナ・ゲストと共有するトピックに関して、ホスト・ノードとプロキシ・ノードでパブリッシャ／サブスクライバ型通信を実施し、コンテナ・ゲスト側では、ゲスト・ノードとプロキシ・ノードでパブリッシャ／サブスクライバ型通信を実施する。プロキシ・ノードは、例えば、パブリッシャとしてデータを送信中のゲスト・ノードに関連するアプリケーションを更新する際には、パブリッシャからの送信データを一時的に保存し、更新完了後にゲスト・ノードはプロキシ・ノードに再接続して、データ送信を再開する。また、プロキシ・ノードは、例えばサブスクライバとして接続しているゲスト・ノードにデータを送信中にアプリケーションを更新する際には、受信データを一時的に保存し、更新完了後にプロキシ・ノードはゲスト・ノードへのデータ送信を再開する。
　図１９には、アプリケーションを更新中のゲスト・ノードに関連する送受信データを一時的に保存する仕組みを模式的に示している。同図では、コンテナ・ホスト１９００側では、コンテナ・ゲスト１９１０と共有するトピック名を指定してプロキシ・ノード１９０２が起動され、パブリッシャとしてのホスト・ノード１９０１が送信したデータをプロキシ・ノード１９０２が受信し、コンテナ・ゲスト１９１０側ではプロキシ・ノード１９０２からサブスクライバとしてのゲスト・ノード１９１１に転送することを想定している。また、アプリケーションやアプリケーションに含まれるプログラムを更新又は追加することにより、更新前のゲスト・ノード１９１１は、ゲスト・ノード１９１２に更新されるものとする。
　アプリケーション・アップデータ１９０３は、アプリケーションのアップデートを管理する役割を持つ管理プロセスである。アプリケーション・アップデータ１９０３は、サブスクライバであるゲスト・ノード１９１１に関連するプログラムを更新する前に、プロキシ・ノード１９０２が提供するキューに、パブリッシャであるホスト・ノード１９０１から送信されたデータを一時的に保存するように、プロキシ・ノード１９０２に指示を出す。これによって、サブスクライバが終了するなどの状態変化が発生しても、パブリッシャであるホスト・ノード１９０１から送信されたデータはプロキシ・ノード１９０２に保持される。
　続いて、アプリケーション・アップデータ１９０３は、サブスクライバであるゲスト・ノード１９１１に関連するプログラムを更新する。そして、アプリケーション・アップデータ１９０３は、プログラムの更新が完了すると、プロキシ・ノード１９０２に対してプログラム更新完了を通知する。
　プロキシ・ノード１９０２は、アプリケーション・アップデータ１９０３からプログラムの更新完了の通知を受け取ると、一時的に保存しておいたパブリッシャ（ホスト・ノード１９０１）からの送信データの最初から、サブスクライバ（更新後のゲスト・ノード１９１２）へのデータ送信を再開する。
　図２０には、アプリケーションを更新中のコンテナ・ゲスト（更新対象のゲスト・ノードを含む）に関連する送受信データの一時保存とアプリケーション更新後にデータ送信を再開する処理シーケンス例を示している。但し、同図は、更新中のコンテナ・ゲスト（更新対象のゲスト・ノード）がパブリッシャとして動作する場合の処理シーケンス例を示している。
　ユーザが、パブリッシャとして動作中のコンテナ・ゲスト（更新前のゲスト・ノード）に関連するプログラムの更新を要求する（Ｓ２００１）。
　アプリケーション・アップデータは、ユーザからの更新要求に応答して、プロキシ・ノードに対し、更新前のパブリッシャであるコンテナ・ゲスト（更新対象のゲスト・ノード）への通信接続を一時的に保存するように指示する（Ｓ２００２）。プロキシ・ノードは、アプリケーション・アップデータからの指示に応答して、コンテナ・ゲスト（更新対象のゲスト・ノード）から送信（パブリッシュ）されるデータを一時的に保存する。
　その後、アプリケーション・アップデータは、パブリッシャであるコンテナ・ゲスト内の更新対象のゲスト・ノードに関連するプログラムの更新を実施する（Ｓ２００３）。ここで、プログラムは、特定のディレクトリにバージョン毎に保存され、実際の更新処理は、新しいプログラムを起動するだけの処理を指すものとする。
　そして、パブリッシャであるコンテナ・ゲストに関連するプログラム（更新されるゲスト・ノードに対応する）の更新処理が完了すると、アプリケーション・アップデータは、プロキシ・ノードに対して更新完了を通知する（Ｓ２００４）。
　パブリッシャ（コンテナ・ゲスト内の更新後のゲスト・ノード）は、プロキシ・ノードへ再接続し、データの転送（パブリッシュ）を再開する（Ｓ２００５）。また、プロキシ・ノードは、一時的に保存しておいたデータから、コンテナ・ホスト内のホスト・ノード（図示しない）へのデータ送信を再開する。
　また、図２１には、アプリケーションを更新中のコンテナ・ゲスト（更新対象のゲスト・ノードを含む）に関連する送受信データの一時保存とアプリケーション更新後にデータ送信を再開する他の処理シーケンス例を示している。但し、同図は、更新中のコンテナ・ゲスト（更新対象のゲスト・ノード）がサブスクライバとして動作する場合の処理シーケンス例を示している。
　ユーザが、サブスクライバとして動作中のコンテナ・ゲスト（更新前のゲスト・ノード）に関連するプログラムの更新を要求する（Ｓ２１０１）。
　アプリケーション・アップデータは、ユーザからの更新要求に応答して、プロキシ・ノードに対し、更新前のサブスクライバであるコンテナ・ゲスト（更新前のゲスト・ノード）への通信接続及び更新中に受信したデータを一時的に保存するように指示する（Ｓ２１０２）。プロキシ・ノードは、アプリケーション・アップデータからの指示に応答して、コンテナ・ホスト内のホスト・ノード（図示しない）から送信（パブリッシュ）され、コンテナ・ゲスト（更新対象のゲスト・ノード）に転送すべきデータを一時的に保存する。
　その後、アプリケーション・アップデータは、サブスクライバ（コンテナ・ゲスト内の更新対象のゲスト・ノード）に関連するプログラムの更新を実施する（Ｓ２１０３）。ここで、プログラムは、特定のディレクトリにバージョン毎に保存され、実際の更新処理は、新しいプログラムを起動するだけの処理を指すものとする。
　そして、サブスクライバ（コンテナ・ゲスト（ゲスト・ノード））に関連するプログラムの更新処理が完了すると、アプリケーション・アップデータは、プロキシ・ノードに対して更新完了を通知する（Ｓ２１０４）。
　プロキシ・ノードは、サブスクライバ（コンテナ・ゲストに含まれる更新対象となるゲスト・ノード）の更新中に一時的に保存したデータから、サブスクライバ（コンテナ・ゲスト内の更新後のゲスト・ノード）へのデータ送信を再開する（Ｓ２１０５）。また、プロキシ・ノードは、一時的に保存しておいたデータから、コンテナ・ゲスト（更新後のゲスト・ノード）へのデータ転送を再開する。
　各アプリケーションを仮想ＮＩＣによって論理的に分離されるコンテナを用いてグルーピングするシステムでは、コンテナ間で送受信するデータ量の制限を、物理レベル（パケット量）及び論理レベル（パブリッシャ／サブスクライバ通信で使用するトピック数）で実現することができる。
　想定するシステムでは、コンテナ・ホスト側では、コンテナ・ゲストと共有するトピックに関して、ホスト・ノードとプロキシ・ノードでパブリッシャ／サブスクライバ型通信を実施し、コンテナ・ゲスト側では、ゲスト・ノードとプロキシ・ノードでパブリッシャ／サブスクライバ型通信を実施する。プロキシ・ノードが通信量を制御することによって、各コンテナに対して均等なネットワーク・リソースを割り当てることができる。
　コンテナ環境の複数業者での利用時（マルチテナント）に、ネットワーク流量制限（ネットワーク層レベルの制限）に加えて、トピック数での論理レベルの流量制限（アプリケーション層レベルの制限）を実現することができる。
　また、各コンテナのアプリケーション特性に合わせたトピック数での制限を実現することができる。例えば、プロキシ・マネージャは、プロキシ・ノードを起動する際に、アプリケーションのインストールを要求するユーザに応じて（若しくは、起動したコンテナ・ゲストにインストールするアプリケーションの特性や、アプリケーションの開発者の属性などに応じて）、ゲスト・ノードに対して課す通信量の制限（例えば、一定時間内で送信トピック数又は送信パケット量など）を、プロキシ・サーバに設定する。複数業者のアプリケーションをインストールするために、複数のプロキシ・ノード及び複数のコンテナ・ゲストを起動する際には、各プロキシ・ノードには対応するアプリケーションに応じた通信量の制限を設定する。
　図２２には、トピック通信量によるスロットリングの仕組みを図解している。同図において、コンテナ・ゲスト２２１０側のゲスト・ノード２２１１（パブリッシャ）から、コンテナ・ホスト２２００側のホスト・ノード２２０１（サブスクライバ）へのデータ通信量を、プロキシ・ノード２２０２において制限している。
　また、図２３には、トピック通信量によるスロットリングを行なう処理シーケンス例を示している。
　パブリッシャとして動作するコンテナ・ゲストは、プロキシ・ノードへ，データを送信する（Ｓ２３０１）。
　プロキシ・ノードは、一定時間内で送信トピック数又は送信パケット量に対する通信量の制限を課しており、通信量制限を超えてコンテナ・ゲストからデータ通信が行なわれたときには、送信元のゲスト・ノードに通知する（Ｓ２３０２）。
　コンテナを用いたグルーピングにより、所定の条件を満たさないアプリケーションを隔離する仕組みについて、図２４を参照しながら詳細に説明する。
　図２４において、コンテナ・ホスト２４００側では、データ送信用のアプリケーションがインストールされ、ホスト・ノード２４０１（パブリッシャ）として動作するとともに、データ受信用のアプリケーションがインストールされ、ホスト・ノード２４０２として動作している。
　コンテナ・ゲスト２４１０を起動する前の処理として、コンテナ・ゲスト２４１０内のゲスト・マスタ２４１１に、データ送信用のホスト・ノード２４０１を対象とするプロキシ・ノード２４０３（パブリッシャ）のトピック名と、データ受信用のホスト・ノード２４０２を対象とするプロキシ・ノード２４０４（サブスクライバ）のトピック名を、登録する。
　起動したコンテナ・ゲスト２４１０は、仮想ＮＩＣによって論理的に分離されるアドレス又は名前空間である。コンテナ・ゲスト２４１０内には、第三者から提供されたような、所定の条件を満たさないアプリケーションがインストールされ、ゲスト・ノード２４１２として動作している。ここでは、ゲスト・ノード２４１２は、プロキシ・ノード２４０３と同じトピック名でサブスクライバとしてゲスト・マスタ２４１１に登録されるとともに、プロキシ・ノード２４０４と同じトピック名でパブリッシャとしてゲスト・マスタ２４１１に登録されているものとする。
　コンテナ・ゲスト２４１０は仮想ＮＩＣによって論理的に分離されるアドレス又は名前空間であり、したがって、コンテナ・ゲスト２４１０は、コンテナ・ホスト２４００から隔離されている。ゲスト・ノード２４１２は、ゲスト・マスタ２４１１に登録したコンテナ・ゲスト２４１０側のトピックを経由して、コンテナ・ゲスト２４１０外、すなわちコンテナ・ホスト２４００側とデータを送受信することができる。
　ゲスト・ノード２４１２は、ゲスト・マスタ２４１１に登録されたプロキシ・ノード２４０３から、ホスト・ノード２４０１の送信データを受信することはできるが、コンテナ・ホスト２４００で動作する（ゲスト・マスタ２４１１に登録されていない）ホスト・ノード２４０５からデータを受信することはできない。
　また、ゲスト・ノード２４１２は、ゲスト・マスタ２４１１に登録されたプロキシ・ノード２４０４に対してデータを送信することによって、プロキシ・ノード２４０４を介してホスト・ノード２４０２にデータを送信することはできるが、コンテナ・ホスト２４００で動作する（ゲスト・マスタ２４１１に登録されていない）ホスト・ノード２４０５へデータを送信することはできない。
　また、ゲスト・ノード２４１２からのデータ受信用に起動されたプロキシ・ノード２４０４は、ゲスト・ノード２４１２からの受信データが、アプリケーションにあらかじめ規定された出力値の仕様範囲内かどうかをチェックする。そして、実施例５で説明したように、出力値の仕様範囲外であることを検知すると、ゲスト・ノード２４１２の停止や、古い、安定したバージョンのアプリケーションからゲスト・ノードを再起動するといった対応処理を実施する。
　図６を参照しながら既に説明したように、ロボットや自動走行車、無人航空機といった自律動作装置１００上では「認識」、「状況理解」、「行動計画」、「行動制御」に分類される多数のアプリケーション・プログラムが動作する。
　図２５には、ロボットを想定した自律動作装置１００のアプリケーション・プログラムの構成例を示している。同図において、認識系アプリケーションから取得したデータを、状況理解系アプリケーションである「Ｉｎｐｕｔ　Ａｄａｐｔｅｒ」経由で、独自のアルゴリズムを持つ画像分析アプリケーション「Ｉｍａｇｅ　Ａｎａｌｙｚｅｒ」に入力する。
　「Ｉｍａｇｅ　Ａｎａｌｙｚｅｒ」が所定の条件を満たし、正常な動作を行なうことが保証されていれば、適切な画像解析結果を行動計画系のアプリケーション「Ｐａｔｈ　ｐｌａｎｎｅｒ」に出力し、「Ｐａｔｈ　ｐｌａｎｎｅｒ」はロボットが稼働する経路を適切に選択することができる。ところが、「Ｉｍａｇｅ　Ａｎａｌｙｚｅｒ」が所定の条件を満たさず、プログラムの悪意若しくは何らかのバグによって不適切な画像解析結果を「Ｐａｔｈ　ｐｌａｎｎｅｒ」に出力した場合には、「Ｐａｔｈ　ｐｌａｎｎｅｒ」はロボットが稼働する経路を適切に選択することができなくなる。
　そこで、図２６に示すように、コンテナを用いたグルーピングを導入する。具体的には、参照番号２６０１で示すコンテナ・ゲストを起動し、所定の条件を満たさない「Ｉｍａｇｅ　Ａｎａｌｙｚｅｒ」をこのコンテナ・ゲスト２６０１内にインストールして、外部から隔離したノードとして動作させる。また、「Ｉｍａｇｅ　Ａｎａｌｙｚｅｒ」の入力側と出力側には、それぞれ参照番号２６０２、２６０３で示すプロキシ・ノードを準備して、「Ｉｎｐｕｔ　Ａｄａｐｔｅｒ」と「Ｐａｔｈ　ｐｌａｎｎｅｒ」に送受信されるデータを制限することにより、不適切な画像解析結果を「Ｐａｔｈ　ｐｌａｎｎｅｒ」に出力しないようにする。プロキシ・ノード２６０３は、「Ｉｍａｇｅ　Ａｎａｌｙｚｅｒ」から受信したデータがあらかじめ規定された出力値の仕様範囲外である場合には、実施例３（図１７）で示した監視フレームワークを利用して、「Ｉｍａｇｅ　Ａｎａｌｙｚｅｒ」のノードを停止させるようにしてもよい。また、プロキシ・ノード２６０３は、監視フレームワークを利用して、「Ｉｍａｇｅ　Ａｎａｌｙｚｅｒ」のノードを、同等の機能を持つ別のノードを含むコンテナに切り替えるようにしてもよい。
　図２７には、自動走行車を想定した自律動作装置１００のアプリケーション・プログラムの構成例を示している。同図において、状況理解系アプリケーションである「場に付与された交通ルール」と「空間・状態」が出力するデータを、「交通可能場所判断アプリケーション」に入力する。
　「交通可能場所判断アプリケーション」が所定の条件を満たし、正常な動作を行なうことが保証されていれば、適切な交通場所の判断結果を行動計画系のアプリケーション「Ｂｅｈａｖｉｏｒ　ｐｌａｎ」に出力し、「Ｂｅｈａｖｉｏｒ　ｐｌａｎ」は自動走行車への適切な動作計画を作成することができる。ところが、「交通可能場所判断アプリケーション」が所定の条件を満たさず、プログラムの悪意若しくは何らかのバグによって不適切な判断結果を「Ｂｅｈａｖｉｏｒ　ｐｌａｎ」に出力した場合、「Ｂｅｈａｖｉｏｒ　ｐｌａｎ」は自動運転車への適切な動作計画を作成することができなくなる。
　そこで、図２８に示すように、コンテナを用いたグルーピングを導入する。具体的には、参照番号２８０１で示すコンテナ・ゲストを起動し、所定の条件を満たさない「交通可能場所判断アプリケーション」をこのコンテナ・ゲスト２６０１内にインストールして、外部から隔離したノードとして動作させる。また、「交通可能場所判断アプリケーション」の入力側と出力側には、それぞれ参照番号２８０２、２８０３、２８０４で示すプロキシ・ノードを準備して、「場に付与された交通ルール」と「空間・状態」と「Ｂｅｈａｖｉｏｒ　ｐｌａｎ」に送受信されるデータを制限することにより、不適切な交通可能場所の判断結果を「Ｂｅｈａｖｉｏｒ　ｐｌａｎ」に出力しないようにする。プロキシ・ノード２８０４は、実施例３（図１７）で示した監視フレームワークを利用して、「交通可能場所判断アプリケーション」から受信したデータがあらかじめ規定された出力値の仕様範囲外である場合には、「交通可能場所判断アプリケーション」のノードを停止させるようにしてもよい。また、プロキシ・ノード２８０４は、監視フレームワークを利用して、「交通可能場所判断アプリケーション」のノードを、同等の機能を持つ別のノードを含むコンテナに切り替えるようにしてもよい。
　このように、本明細書で開示する技術によれば、パブリッシャ／サブスクライバ型の非同期通信モデルを用いたシステムにおいて、コンテナと称されるグルーピング方法を導入して、コンテナに所属する構成ユニット（アプリケーションなど）又は構成ユニットに含まれるソフトウェアの所属するコンテナ内に通信を制限することができる。この技術によれば、構成ユニット開発における独立性を維持しつつ、構成ユニット又は構成ユニットに含まれるソフトウェアの任意のグルーピングが可能である。
　また、本明細書で開示する技術によれば、コンテナを用いたグルーピングを利用して、同一のソースからの情報に対し、構成ユニット毎に割り当てる特性に応じた加工（例えば、構成ユニットのセキュリティ・レベルに合わせて情報を劣化する）を施した上で送信することができる。
　また、本明細書で開示する技術によれば、コンテナを用いたグルーピングを利用して、更新・追加された構成ユニットに含まれるソフトウェアがシステム動作中に誤作動などを起こした場合には、その誤作動を検出し、システム動作を継続させながら、誤作動などを起こしたソフトウェアを更新・追加する前に動作が保証されていたソフトウェアの動作に切り替えることができる。
　また、本明細書で開示する技術によれば、コンテナを用いたグルーピングを利用して、更新中の構成ユニットに関連する送受信データを一時保存し、更新後に一時保存した送受信データから接続を再開することで、構成ユニットや構成ユニットに含まれるソフトウェアを安全に更新・追加することができる。
　また、本明細書で開示する技術によれば、コンテナを用いたグルーピングを利用して、構成ユニットが送受信するデータ量の制限を、物理レベル（パケット量）及び論理レベル（パブリッシャ／サブスクライバ通信で使用するトピック数）で実現し、マルチテナント（構成ユニットを複数の業者に提供する場合）においても、各々に均等なネットワーク・リソースを配分することができる。
　以上、特定の実施形態を参照しながら、本明細書で開示する技術について詳細に説明してきた。しかしながら、本明細書で開示する技術の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
　本明細書で開示する技術は、自律的若しくは適応的な行動を実現するアプリケーション・プログラムをインストールして動作する、ロボットや自動走行車、無人航空機（ドローン）などの自律動作装置に適用することができる。また、自律動作装置には限定されず、アプリケーション又はアプリケーションに含まれるソフトウェアをインストールするさまざまなタイプの情報処理装置や、パブリッシャ／サブスクライバ型の通信モデルに基づいてプロセス間通信を実施するさまざまタイプの情報処理装置に対しても、同様に本明細書で開示する技術を適用することができる。
　要するに、例示という形態により本明細書で開示する技術について説明してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本明細書で開示する技術の要旨を判断するためには、特許請求の範囲を参酌すべきである。
　なお、本明細書の開示の技術は、以下のような構成をとることも可能である。
（１）第１のノードが動作する第１のコンテナとは分離された第２のコンテナを起動して、前記第２のコンテナで第２のノードを起動する起動部と、
　前記第１のコンテナにおいて前記第１のノードと所定の通信モデルに基づくデータ通信を行なうとともに、前記第２のコンテナにおいて前記第２のノードと前記所定の通信モデルに基づくデータ通信を行なうプロキシ・ノードを起動させるプロキシ管理部と、
を具備する情報処理装置。
（２）前記起動部は、仮想ＮＩＣによって前記第１のコンテナとは論理的に分離されるアドレス又は名前空間からなる前記第２のコンテナを起動する、
上記（１）に記載の情報処理装置。
（３）前記所定の通信モデルは、パブリッシャ／サブスクライバ型の通信モデルであり、
　前記起動部は、前記第２のコンテナと共有するトピック名を指定して前記プロキシ・ノードを起動する、
上記（２）に記載の情報処理装置。
（４）前記第１のノードが、前記プロキシ・ノードが前記第１のコンテナで提供する第１のトピックのデータを送信し、
　前記プロキシ・ノードが、前記第１のトピックに紐付けられた前記第２のコンテナに第２のトピックを作成して、前記第１のノードから受信したデータを送信し、
　前記第２のノードが、前記第２のトピックからデータを受信する、
上記（３）に記載の情報処理装置。
（５）前記第２のノードが、前記プロキシ・ノードが前記第２のコンテナで提供する第２のトピックのデータを送信し、
　前記プロキシ・ノードが、前記第２のトピックに紐付けられた前記第１のコンテナに第１のトピックを作成して、前記第２のノードから受信したデータを送信し、
　前記第１のノードが、前記第１のトピックからデータを受信する、
上記（３）又は（４）のいずれかに記載の情報処理装置。
（６）前記第１のノードは所定の条件を満たす第１のアプリケーションを前記第１のコンテナにインストールして動作するノードであり、
　前記起動部は、前記所定の条件を満たさない第２のアプリケーションを前記第２のコンテナにインストールして前記第２のノードを動作させる、
上記（１）乃至（５）のいずれかに記載の情報処理装置。
（７）前記所定の条件は、アプリケーションの開発者、アプリケーションのセキュリティ・レベル、アプリケーションの動作検証のうち少なくとも１つを含む、
上記（６）に記載の情報処理装置。
（８）前記第１のノードは、前記プロキシ・ノードに送信するデータに対して、前記第２のノードとして動作するアプリケーションの特性に応じた加工を行なう、
上記（１）乃至（７）のいずれかに記載の情報処理装置。
（９）前記第１のノードは、前記プロキシ・ノードに送信するデータに対して、前記第１のコンテナと前記第２のコンテナ間で共有するトピック名に応じた加工を行なう、
上記（１）乃至（７）のいずれかに記載の情報処理装置。
（１０）前記第２のノードの動作を監視する監視部をさらに備える、
上記（１）乃至（９）のいずれかに記載の情報処理装置。
（１１）前記プロキシ・ノードは、前記第２のノードから受信したデータをチェックし、異常を検出したときに前記監視部に通知する、
上記（１０）に記載の情報処理装置。
（１２）前記監視部は、異常が検出された前記第２のノードを停止させる、
上記（１０）又は（１１）のいずれかに記載の情報処理装置。
（１３）前記監視部は、前記第２のノードよりも安定したアプリケーションを再起動して第３ノードを動作させる、
上記（１２）に記載の情報処理装置。
（１４）前記第２のノードとして動作するアプリケーションの更新を行なうアプリケーション更新部をさらに備え、
　前記アプリケーション更新部は、前記プロキシ・ノードは、前記アプリケーションを更新中に前記第２のノードとの送受信データを保存し、前記アプリケーションの更新後に前記保存した送受信データから前記第２のノードとの接続を再開する、
上記（１）乃至（１３）のいずれかに記載の情報処理装置。
（１５）前記プロキシ・ノードは、前記第２のノードからの通信量の制限を課す、
上記（１）乃至（１４）のいずれかに記載の情報処理装置。
（１６）前記プロキシ・ノードは、前記第２のノードが前記制限を超えたデータ送信を行なったときには、前記第２のノードに通知する、
上記（１５）に記載の情報処理装置。
（１７）第１のノードが動作する第１のコンテナとは分離された第２のコンテナを起動して、前記第２のコンテナで第２のノードを起動する起動ステップと、
　前記第１のコンテナにおいて前記第１のノードと所定の通信モデルに基づくデータ通信を行なうとともに、前記第２のコンテナにおいて前記第２のノードと前記所定の通信モデルに基づくデータ通信を行なうプロキシ・ノードを起動させるプロキシ管理ステップと、
を有する情報処理方法。
（１８）第１のノードが動作する第１のコンテナとは分離された第２のコンテナを起動して、前記第２のコンテナで第２のノードを起動する起動部、
　前記第１のコンテナにおいて前記第１のノードと所定の通信モデルに基づくデータ通信を行なうとともに、前記第２のコンテナにおいて前記第２のノードと前記所定の通信モデルに基づくデータ通信を行なうプロキシ・ノードを起動させるプロキシ管理部、
としてコンピュータを機能させるようにコンピュータ可読形式で記述されたコンピュータ・プログラム。
　１００…自律動作装置（実機）
　１１０…本体部
　１１１…プロセッサ、１１２…メモリ、１１３…通信モデム
　１１４…バッテリー、１１５…ＵＳＢポート、１１６…ＧＰＳ
　１２０…モジュール部
　１２１…アクチュエータ、１２２…プロセッサ
　１２３…メモリ、１２４…センサ、１２５…通信モデム
　２００…開発装置、２１０…コンピュータ本体部
　２１１…プロセッサ、２１２…ＧＰＵ
　２１３…メモリ、２１４…ＵＳＢポート、２１５…通信モデム
　２２０…ディスプレイ、２３０…ユーザ・インターフェース

Claims (18)

  1. 　第１のノードが動作する第１のコンテナとは分離された第２のコンテナを起動して、前記第２のコンテナで第２のノードを起動する起動部と、
    　前記第１のコンテナにおいて前記第１のノードと所定の通信モデルに基づくデータ通信を行なうとともに、前記第２のコンテナにおいて前記第２のノードと前記所定の通信モデルに基づくデータ通信を行なうプロキシ・ノードを起動させるプロキシ管理部と、
    を具備する情報処理装置。
  2. 　前記起動部は、仮想ＮＩＣによって前記第１のコンテナとは論理的に分離されるアドレス又は名前空間からなる前記第２のコンテナを起動する、
    請求項１に記載の情報処理装置。
  3. 　前記所定の通信モデルは、パブリッシャ／サブスクライバ型の通信モデルであり、
    　前記起動部は、前記第２のコンテナと共有するトピック名を指定して前記プロキシ・ノードを起動する、
    請求項２に記載の情報処理装置。
  4. 　前記第１のノードが、前記プロキシ・ノードが前記第１のコンテナで提供する第１のトピックのデータを送信し、
    　前記プロキシ・ノードが、前記第１のトピックに紐付けられた前記第２のコンテナに第２のトピックを作成して、前記第１のノードから受信したデータを送信し、
    　前記第２のノードが、前記第２のトピックからデータを受信する、
    請求項３に記載の情報処理装置。
  5. 　前記第２のノードが、前記プロキシ・ノードが前記第２のコンテナで提供する第２のトピックのデータを送信し、
    　前記プロキシ・ノードが、前記第２のトピックに紐付けられた前記第１のコンテナに第１のトピックを作成して、前記第２のノードから受信したデータを送信し、
    　前記第１のノードが、前記第１のトピックからデータを受信する、
    請求項３に記載の情報処理装置。
  6. 　前記第１のノードは所定の条件を満たす第１のアプリケーションを前記第１のコンテナにインストールして動作するノードであり、
    　前記起動部は、前記所定の条件を満たさない第２のアプリケーションを前記第２のコンテナにインストールして前記第２のノードを動作させる、
    請求項１に記載の情報処理装置。
  7. 　前記所定の条件は、アプリケーションの開発者、アプリケーションのセキュリティ・レベル、アプリケーションの動作検証のうち少なくとも１つを含む、
    請求項６に記載の情報処理装置。
  8. 　前記第１のノードは、前記プロキシ・ノードに送信するデータに対して、前記第２のノードとして動作するアプリケーションの特性に応じた加工を行なう、
    請求項１に記載の情報処理装置。
  9. 　前記第１のノードは、前記プロキシ・ノードに送信するデータに対して、前記第１のコンテナと前記第２のコンテナ間で共有するトピック名に応じた加工を行なう、
    請求項１に記載の情報処理装置。
  10. 　前記第２のノードの動作を監視する監視部をさらに備える、
    請求項１に記載の情報処理装置。
  11. 　前記プロキシ・ノードは、前記第２のノードから受信したデータをチェックし、異常を検出したときに前記監視部に通知する、
    請求項１０に記載の情報処理装置。
  12. 　前記監視部は、異常が検出された前記第２のノードを停止させる、
    請求項１０に記載の情報処理装置。
  13. 　前記監視部は、前記第２のノードよりも安定したアプリケーションを再起動して第３ノードを動作させる、
    請求項１２に記載の情報処理装置。
  14. 　前記第２のノードとして動作するアプリケーションの更新を行なうアプリケーション更新部をさらに備え、
    　前記アプリケーション更新部は、前記プロキシ・ノードは、前記アプリケーションを更新中に前記第２のノードとの送受信データを保存し、前記アプリケーションの更新後に前記保存した送受信データから前記第２のノードとの接続を再開する、
    請求項１に記載の情報処理装置。
  15. 　前記プロキシ・ノードは、前記第２のノードからの通信量の制限を課す、
    請求項１に記載の情報処理装置。
  16. 　前記プロキシ・ノードは、前記第２のノードが前記制限を超えたデータ送信を行なったときには、前記第２のノードに通知する、
    請求項１５に記載の情報処理装置。
  17. 　第１のノードが動作する第１のコンテナとは分離された第２のコンテナを起動して、前記第２のコンテナで第２のノードを起動する起動ステップと、
    　前記第１のコンテナにおいて前記第１のノードと所定の通信モデルに基づくデータ通信を行なうとともに、前記第２のコンテナにおいて前記第２のノードと前記所定の通信モデルに基づくデータ通信を行なうプロキシ・ノードを起動させるプロキシ管理ステップと、
    を有する情報処理方法。
  18. 　第１のノードが動作する第１のコンテナとは分離された第２のコンテナを起動して、前記第２のコンテナで第２のノードを起動する起動部、
    　前記第１のコンテナにおいて前記第１のノードと所定の通信モデルに基づくデータ通信を行なうとともに、前記第２のコンテナにおいて前記第２のノードと前記所定の通信モデルに基づくデータ通信を行なうプロキシ・ノードを起動させるプロキシ管理部、
    としてコンピュータを機能させるようにコンピュータ可読形式で記述されたコンピュータ・プログラム。
PCT/JP2018/007518 2017-04-12 2018-02-28 情報処理装置及び情報処理方法、並びにコンピュータ・プログラム WO2018190015A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP18784792.6A EP3611618A4 (en) 2017-04-12 2018-02-28 INFORMATION PROCESSING DEVICE, INFORMATION PROCESSING METHOD AND COMPUTER PROGRAM
CN201880023183.5A CN110476152A (zh) 2017-04-12 2018-02-28 信息处理设备、信息处理方法和计算机程序
JP2019512373A JP7074130B2 (ja) 2017-04-12 2018-02-28 情報処理装置及び情報処理方法、並びにコンピュータ・プログラム
US16/493,998 US11218535B2 (en) 2017-04-12 2018-02-28 Information processing apparatus, information processing method, and computer program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2017-079298 2017-04-12
JP2017079298 2017-04-12

Publications (1)

Publication Number Publication Date
WO2018190015A1 true WO2018190015A1 (ja) 2018-10-18

Family

ID=63792421

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2018/007518 WO2018190015A1 (ja) 2017-04-12 2018-02-28 情報処理装置及び情報処理方法、並びにコンピュータ・プログラム

Country Status (5)

Country Link
US (1) US11218535B2 (ja)
EP (1) EP3611618A4 (ja)
JP (1) JP7074130B2 (ja)
CN (1) CN110476152A (ja)
WO (1) WO2018190015A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020108161A1 (zh) * 2018-11-30 2020-06-04 中国人民解放军陆军工程大学 一种基于ros主从节点管理器的通信方法和系统
JP2022530959A (ja) * 2019-04-30 2022-07-05 奥特酷智能科技(南京)有限公司 分散集中型自動運転システム
WO2022254521A1 (ja) * 2021-05-31 2022-12-08 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 監視システム、監視方法、監視装置および機能制限装置
WO2024057408A1 (ja) * 2022-09-13 2024-03-21 日本電信電話株式会社 制御装置、制御方法、及びプログラム

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11042398B2 (en) * 2018-07-09 2021-06-22 Samsung Electronics Co., Ltd. System and method for guest operating system using containers
JP7342443B2 (ja) * 2019-06-18 2023-09-12 株式会社リコー 情報処理装置、方法、およびプログラム
CN110955399B (zh) * 2019-11-29 2024-03-01 东软集团股份有限公司 车载显示系统、图像显示方法、存储介质和主机
CN111708644A (zh) * 2020-05-29 2020-09-25 北京百度网讯科技有限公司 用于自动驾驶仿真的虚拟世界管理方法和系统
US20230297448A1 (en) * 2022-03-17 2023-09-21 OpenFin Inc. Initiating operations for applications via communication bridges
US20240098143A1 (en) * 2022-06-29 2024-03-21 Amazon Technologies, Inc. Plug-in orchestrator for vehicle data stream subscription system

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003334785A (ja) 2002-03-15 2003-11-25 Sony Corp ロボットの行動制御システム及び行動制御方法、並びにロボット装置
JP2010514028A (ja) * 2006-12-22 2010-04-30 バーチャルロジックス エスエイ 単一データ処理を共有するために複数の実行環境を有効化するシステム
JP2011514087A (ja) 2008-03-05 2011-04-28 インターナショナル・ビジネス・マシーンズ・コーポレーション ｐｕｂｌｉｓｈ／ｓｕｂｓｃｒｉｂｅメッセージ・ブローカ
JP2013041445A (ja) * 2011-08-17 2013-02-28 Fujitsu Ltd 情報処理装置、情報処理方法及び情報処理プログラム
JP2016515267A (ja) * 2013-03-15 2016-05-26 ブラケット コンピューティング インコーポレイテッドＢｒａｃｋｅｔ Ｃｏｍｐｕｔｉｎｇ， Ｉｎｃ． 仮想データセンタゲストへのサービスの拡大

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7228539B2 (en) * 2003-06-16 2007-06-05 Lucent Technologies Inc. Method and apparatus for updating inter-server communication software
CN104247333B (zh) * 2011-12-27 2017-08-11 思科技术公司 用于基于网络的服务的管理的系统和方法
US9471775B1 (en) * 2015-02-04 2016-10-18 Amazon Technologies, Inc. Security protocols for low latency execution of program code

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003334785A (ja) 2002-03-15 2003-11-25 Sony Corp ロボットの行動制御システム及び行動制御方法、並びにロボット装置
JP2010514028A (ja) * 2006-12-22 2010-04-30 バーチャルロジックス エスエイ 単一データ処理を共有するために複数の実行環境を有効化するシステム
JP2011514087A (ja) 2008-03-05 2011-04-28 インターナショナル・ビジネス・マシーンズ・コーポレーション ｐｕｂｌｉｓｈ／ｓｕｂｓｃｒｉｂｅメッセージ・ブローカ
JP2013041445A (ja) * 2011-08-17 2013-02-28 Fujitsu Ltd 情報処理装置、情報処理方法及び情報処理プログラム
JP2016515267A (ja) * 2013-03-15 2016-05-26 ブラケット コンピューティング インコーポレイテッドＢｒａｃｋｅｔ Ｃｏｍｐｕｔｉｎｇ， Ｉｎｃ． 仮想データセンタゲストへのサービスの拡大

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3611618A4

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020108161A1 (zh) * 2018-11-30 2020-06-04 中国人民解放军陆军工程大学 一种基于ros主从节点管理器的通信方法和系统
JP2022530959A (ja) * 2019-04-30 2022-07-05 奥特酷智能科技(南京)有限公司 分散集中型自動運転システム
JP7228857B2 (ja) 2019-04-30 2023-02-27 奥特酷智能科技(南京)有限公司 分散集中型自動運転システム
WO2022254521A1 (ja) * 2021-05-31 2022-12-08 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 監視システム、監視方法、監視装置および機能制限装置
WO2024057408A1 (ja) * 2022-09-13 2024-03-21 日本電信電話株式会社 制御装置、制御方法、及びプログラム

Also Published As

Publication number Publication date
EP3611618A1 (en) 2020-02-19
CN110476152A (zh) 2019-11-19
US11218535B2 (en) 2022-01-04
US20200036774A1 (en) 2020-01-30
JP7074130B2 (ja) 2022-05-24
JPWO2018190015A1 (ja) 2020-02-27
EP3611618A4 (en) 2020-04-22

Similar Documents

Publication Publication Date Title
JP7074130B2 (ja) 情報処理装置及び情報処理方法、並びにコンピュータ・プログラム
US10114618B2 (en) Autonomous mobile sensor movement path simulation with an integrated developer environment
US9292319B2 (en) Global computing interface
JP6574895B2 (ja) マルチセッションプラットフォーム上でのデバイス管理サービスの仮想化
JP6572330B2 (ja) ロボットアプリケーション管理装置、システム、方法及びプログラム
US20160357522A1 (en) Physical space map overlay and interaction for an internet of things integrated developer environment
JP2018129021A (ja) インダストリアル・インターネットオペレーティングシステムに基づくフィールドデバイス制御管理方法と装置
US20130138818A1 (en) Method for accessing an automation system and system operating according to the method
US20080256225A1 (en) Osgi-Based Dynamic Service Management Method for Context-Aware Systems
JP6201917B2 (ja) フィールドデバイスを設定するためのシステムおよび方法
Šišlák et al. A-globe: Agent development platform with inaccessibility and mobility support
US20200403822A1 (en) Methods for operator control unit and payload communication
CN103858102B (zh) 用于分布式虚拟桌面基础设施的系统和方法
Cardoso et al. An interface for programming verifiable autonomous agents in ROS
US10748057B1 (en) Neural network modules
JP6250166B2 (ja) 可動物体のアプリケーション開発を支援する方法、システム及びコンピュータ読取り可能媒体
Williams et al. Utilizing ROS 1 and the turtlebot3 in a multi-robot system
US20130339871A1 (en) Software Application Abstraction System and Method
US20210360075A1 (en) Service provider managed applications in secured networks
US11108735B2 (en) Mapping subnets in different virtual networks using private address space
KR102016810B1 (ko) 사물을 제어하는 다수 IoT 플랫폼을 생성하는 액추에이터 컴포지션 시스템
CN108701426B (zh) 发送指导者操作站(ios)过滤信息的方法和便携式计算设备
Joo et al. A study on VAL platform for 5G network for large-capacity data transmission
US11695632B1 (en) Management and control across heterogeneous edge devices of a client network using device abstractions
US11829791B2 (en) Providing device abstractions to applications inside a virtual machine

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18784792

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019512373

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2018784792

Country of ref document: EP

Effective date: 20191112