WO2018146909A1 - 演算装置、制御装置および制御方法 - Google Patents

演算装置、制御装置および制御方法 Download PDF

Info

Publication number
WO2018146909A1
WO2018146909A1 PCT/JP2017/042373 JP2017042373W WO2018146909A1 WO 2018146909 A1 WO2018146909 A1 WO 2018146909A1 JP 2017042373 W JP2017042373 W JP 2017042373W WO 2018146909 A1 WO2018146909 A1 WO 2018146909A1
Authority
WO
WIPO (PCT)
Prior art keywords
event
request
event request
processing
communication
Prior art date
Application number
PCT/JP2017/042373
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 US16/478,473 priority Critical patent/US10785014B2/en
Priority to EP17895678.5A priority patent/EP3582038B1/en
Priority to CN201780083623.1A priority patent/CN110178097B/zh
Publication of WO2018146909A1 publication Critical patent/WO2018146909A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L7/00—Arrangements for synchronising receiver with transmitter
    • H04L7/0004—Initialisation of the receiver
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/05—Programmable logic controllers, e.g. simulating logic interconnections of signals according to ladder diagrams or function charts
    • G05B19/054—Input/output
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/1887—Scheduling and prioritising arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40143—Bus networks involving priority mechanisms
    • H04L12/4015—Bus networks involving priority mechanisms by scheduling the transmission of messages at the communication node
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/56—Allocation or scheduling criteria for wireless resources based on priority criteria
    • H04W72/566—Allocation or scheduling criteria for wireless resources based on priority criteria of the information or information source or recipient
    • H04W72/569—Allocation or scheduling criteria for wireless resources based on priority criteria of the information or information source or recipient of the traffic information
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/10—Plc systems
    • G05B2219/11—Plc I-O input output
    • G05B2219/1101—Remote I-O
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/10—Plc systems
    • G05B2219/12—Plc mp multi processor system
    • G05B2219/1208—Communication, exchange of control, I-O data between different plc
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/10—Plc systems
    • G05B2219/13—Plc programming
    • G05B2219/13063—Synchronization between modules
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/10—Plc systems
    • G05B2219/13—Plc programming
    • G05B2219/13087—Separate interrupt controller for modules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J3/00—Time-division multiplex systems
    • H04J3/02—Details
    • H04J3/06—Synchronising arrangements
    • H04J3/0635—Clock or time synchronisation in a network
    • H04J3/0638—Clock or time synchronisation among nodes; Internode synchronisation
    • H04J3/0652—Synchronisation among time division multiple access [TDMA] nodes, e.g. time triggered protocol [TTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/4026—Bus for use in automation systems

Definitions

  • the present invention relates to an arithmetic device that constitutes a control device including one or a plurality of functional units, and the control device.
  • control devices such as PLCs (programmable controllers) are prevalent.
  • PLCs programmable controllers
  • Such a control device may be composed of a CPU unit that executes various programs and one or a plurality of functional units that are connected to the CPU unit via a transmission path. In such a configuration, data is exchanged between the CPU unit and the functional unit via the transmission path.
  • Patent Document 1 discloses a method of clock synchronization, that is, time adjustment.
  • an IO Input Output
  • processing for the CPU unit to acquire input data collected by the functional unit and processing for outputting a control command calculated by the CPU unit to the functional unit Refresh is executed at predetermined intervals.
  • Data may be exchanged by message communication during a period other than the period when the IO refresh is executed.
  • Patent Document 1 discloses that a propagation delay time is obtained by actually transmitting and receiving a message between a master unit and a slave unit, and time correction is performed using the propagation delay time.
  • the message communication as described above may be used for, for example, a process for establishing a connection between the CPU unit and the functional unit and various activation processes. It is preferable that data transmitted by message communication used for such purposes is sent out as quickly as possible, but generally, the highest priority is set for IO refresh. Depending on the condition of the road, data may not be transmitted promptly by message communication.
  • An object of the present invention is to provide a new configuration for guaranteeing the arrival time at a transmission destination in message communication in a transmission path through which communication frames related to IO refresh and the like are transmitted at a predetermined cycle.
  • an arithmetic unit constituting a control device includes a communication interface for exchanging data with one or a plurality of functional units via a transmission line, and a predetermined cycle via the transmission line.
  • a first transmission control means for sending a first communication frame; and a second transmission for sending a second communication frame in response to an arbitrary event request during a period in which the first communication frame is not transmitted.
  • the priority management means Upon receiving the second event request issue request from the second event issuing means, the priority management means sends a second communication frame corresponding to the first event request currently being processed in the second transmission control means. Waiting for the completion of the sending process, the second event issuing means is allowed to issue a second event request. The second transmission control unit suspends the processing for the subsequent first event request subsequent to the first event request currently being processed until the processing for the second event request is completed.
  • the second transmission control means includes a first queue that sequentially stores the first event requests and a second queue that sequentially stores the second event requests.
  • the priority management unit when the priority management unit receives the second event request issuance request, the priority management unit notifies the second transmission control unit of the issuance request, and the second transmission control unit issues the second event request. After the notification of the request, when the processing for the first event request currently being processed is completed, the priority management means is notified that the second event request can be processed.
  • the second event request includes an instruction for a specific functional unit to establish synchronous communication with the arithmetic device via the transmission path.
  • each of the arithmetic device and the one or more functional units connected via the transmission line has a clock synchronized with each other, and the instruction for establishing synchronous communication is indicated by the clocks synchronized with each other Including timing.
  • the timing is set to a value associated with the transmission cycle of the first communication frame.
  • the control device includes an arithmetic device and one or a plurality of functional units connected to the arithmetic device and the transmission line so as to exchange data.
  • the arithmetic unit responds to an arbitrary event request in a period during which the first communication frame is not transmitted, and a first transmission control means for sending the first communication frame every predetermined cycle via the transmission path.
  • Second transmission control means for sending a second communication frame
  • first event issuing means for issuing a first event request according to processing
  • Second event issuing means for issuing an event request and priority management means for preferentially processing the second event request issued by the second event issuing means.
  • the priority management means Upon receiving the second event request issue request from the second event issuing means, the priority management means sends a second communication frame corresponding to the first event request currently being processed in the second transmission control means. Waiting for the completion of the sending process, the second event issuing means is allowed to issue a second event request. The second transmission control unit suspends the processing for the subsequent first event request subsequent to the first event request currently being processed until the processing for the second event request is completed.
  • a control method in a control device including an arithmetic device and one or a plurality of functional units connected to the arithmetic device and a transmission path so as to exchange data.
  • the control method includes a step of sending a first communication frame at predetermined intervals via a transmission line, a step of issuing a first event request according to processing, and a step having a higher priority than the first event request.
  • the present invention it is possible to guarantee the arrival time at the transmission destination in the message communication in the transmission path through which the communication frames related to IO refresh and the like are transmitted at a predetermined cycle.
  • a PLC plural controller
  • the technical idea disclosed in the present specification is not limited to the name of the PLC. Is applicable to any control device.
  • FIG. 1 is a schematic diagram showing a main configuration of a PLC according to the present embodiment.
  • PLC 1 includes a CPU unit 100 and one or a plurality of functional units 150 as a basic configuration.
  • the CPU unit 100 is an element constituting the PLC 1 and corresponds to an arithmetic device that controls the processing of the entire PLC 1.
  • the functional unit 150 provides various functions for realizing control of various machines and facilities by the PLC 1.
  • the CPU unit 100 and one or more functional units 150 are connected via a local bus 112 which is an example of a transmission path.
  • the CPU unit 100 can exchange data with any functional unit 150 via the local bus 112. Typically, the CPU unit 100 performs IO refreshing with one or more functional units 150 at predetermined intervals. In this IO refresh, input data collected by each functional unit 150 is transmitted to the CPU unit 100, and a control command calculated by the CPU unit 100 is transmitted to an arbitrary functional unit 150. In addition to such IO refresh, data transmission / reception by message communication is possible between the CPU unit 100 and the arbitrary functional unit 150 or between the arbitrary functional unit 150. Message communication is not limited to a one-to-one aspect, and a plurality of one-to-one aspects may be possible.
  • FIG. 1 shows a configuration in which a remote IO device is connected to the PLC 1 as an applied configuration. That is, one or a plurality of communication coupler units 200 are connected to the CPU unit 100 via a field network 114 which is another example of a transmission path. One or more functional units 250 are connected to each of the communication coupler units 200 via a local bus 212 which is an example of a transmission path.
  • the functional unit 150 and the functional unit 250 have substantially the same configuration, and only the reference numerals are different for convenience of explanation. However, some functions may be different between the functional unit 150 connected to the CPU unit 100 and the functional unit 250 connected to the communication coupler unit 200.
  • the CPU unit 100 can perform IO refresh and message communication with the functional unit 250 connected to the communication coupler unit 200. That is, the communication coupler unit 200 provides a function that mediates exchange of data between the CPU unit 100 and the functional unit 250. More specifically, data transmitted from the CPU unit 100 via the field network 114 is transferred onto the local bus 212 via the communication coupler unit 200 and delivered to the target functional unit 250. Conversely, data transmitted from any functional unit 250 via the local bus 212 is transferred onto the field network 114 via the communication coupler unit 200 and delivered to the CPU unit 100.
  • the CPU unit 100 includes a processor 102, a main memory 104, a storage 106, a bus communication circuit 108, and a network interface 110.
  • the processor 102 realizes processing in the PLC 1 by executing a system program and a user program.
  • a CPU Central Processing Unit
  • a GPU Graphics Processing Unit
  • the processor 102 may have a single-core and single-chip configuration, or may be a multi-core single chip, a single-core multi-chip, or a multi-core multi-chip.
  • the main memory 104 is composed of DRAM (Dynamic Random Access Memory), SRAM (Static Random Access Memory), and the like, and provides a work area necessary for executing a program in the processor 102.
  • DRAM Dynamic Random Access Memory
  • SRAM Static Random Access Memory
  • the storage 106 is composed of a semiconductor storage device such as a flash memory, and stores a system program for realizing the basic functions of the CPU unit 100, a user program arbitrarily created according to the control target, and the like.
  • the bus communication circuit 108 corresponds to a communication interface for exchanging data with one or a plurality of functional units 150 via a transmission line, and the local bus 112 (between the CPU unit 100 and each functional unit 150 ( Intermediary of data transmission via the transmission path). At least a part of the bus communication circuit 108 may be implemented by a hard wired circuit.
  • the bus communication circuit 108 may function as a “master” that manages data transmission on the local bus 112.
  • each of the functional units 150 connected to the local bus 112 may function as a “slave” that performs data transmission under the management of the bus communication circuit 108. Data transmission / reception processing between the CPU unit 100 and each functional unit 150 using the bus communication circuit 108 will be described later.
  • the network interface 110 mediates data transmission via the field network 114 between the CPU unit 100 and an arbitrary device including each communication coupler unit 200.
  • the network interface 110 may function as a “master” that manages data transmission on the field network 114.
  • each of the communication coupler unit 200 and other devices connected to the field network 114 may function as a “slave” that performs data transmission under the management of the network interface 110.
  • the field network 114 for example, a fixed-period network according to a known protocol such as EtherCAT (registered trademark), EtherNet / IP (registered trademark), DeviceNet (registered trademark), or CompoNet (registered trademark) may be adopted. Good.
  • the functional unit 150 can collect arbitrary functions such as collecting information necessary for the user program executed by the CPU unit 100, outputting a control command calculated by executing the user program, and executing special processing independent of the CPU unit 100. I will provide a.
  • the functional unit 150 may include an IO unit, a communication unit, a temperature adjustment unit, an ID (Identifier) sensor unit, and the like.
  • IO unit for example, a digital input (DI) unit, a digital output (DO) unit, an analog output (AI) unit, an analog output (AO) unit, a pulse catch input unit, and a composite in which a plurality of types are mixed Unit etc. are mentioned.
  • DI digital input
  • DO digital output
  • AI analog output
  • AO analog output
  • pulse catch input unit for example, a pulse catch input unit, a composite in which a plurality of types are mixed Unit etc.
  • the communication unit mediates exchange of data with other PLCs, other remote IO devices, other functional units, and the like.
  • EtherCAT registered trademark
  • EtherNet / IP registered trademark
  • DeviceNet registered trademark
  • CompoNet registered trademark
  • the temperature adjustment unit is a control device including an analog input function for acquiring a temperature measurement value, an analog output function for outputting a control command, and a PID (Proportional Integral Differential) control function.
  • the ID sensor unit is a device that reads data without contact from an RFID (Radio Frequency IDentifier) or the like.
  • each functional unit 150 includes a bus communication circuit 152, a communication controller 154, and a functional module 156.
  • the communication controller 154 processes data (typically a communication frame) transmitted through the local bus 112. Specifically, the communication controller 154 transmits the requested data via the local bus 112 and receives some data via the local bus 112 in accordance with management by the bus communication circuit 108 as a master. To 154.
  • data typically a communication frame
  • the communication controller 154 controls transmission / reception of data on the local bus 112 by executing a program or logic stored in advance.
  • the communication controller 154 can be implemented using a processor configured to execute predetermined software, a processing circuit incorporating predetermined logic, or the like.
  • the function module 156 performs various functions provided by each functional unit 150, for example, collects various information (input data) from the field, and outputs a control command to a control target (machine or facility) in the field.
  • the functional module 156 is in charge of executing processing unique to each functional unit 150 or providing a unique function, and the bus communication circuit 152 and the communication controller 154 are connected via the local bus 112. Responsible for data transmission.
  • the communication coupler unit 200 is responsible for data transmission with the functional unit 250 via the local bus 212 and is also responsible for data transmission with the CPU unit 100 via the field network 114. More specifically, the communication coupler unit 200 includes a controller 201, a network interface 210, and a bus communication circuit 208.
  • the controller 201 mainly controls the network interface 210 and the bus communication circuit 208.
  • the controller 201 includes a processor 202, a main memory 204, and a storage 206.
  • the processor 202 provides necessary processing and functions in the communication coupler unit 200 by expanding and executing a system program or the like stored in the storage 206 in the main memory 204. Note that at least a part of the controller 201 may be mounted with a hard-wired circuit.
  • the network interface 210 is in charge of data transmission via the field network 114.
  • the basic configuration is the same as that of the network interface 110 of the CPU unit 100 except that the network interface 210 functions as a slave in the field network 114.
  • the bus communication circuit 208 mediates data transmission via the local bus 212 between the communication coupler unit 200 and each functional unit 250, similarly to the bus communication circuit 108 of the CPU unit 100.
  • the functional unit 250 is substantially the same as the functional unit 150 described above except that it is connected to the communication coupler unit 200.
  • Each functional unit 250 includes a bus communication circuit 252, a communication controller 254, and a functional module 256. Since the details of these functions have been described with respect to the functional unit 150, detailed description thereof will not be repeated here.
  • FIG. 2 is a schematic diagram for explaining data transmission on the local bus of PLC 1 according to the present embodiment.
  • FIG. 2 shows an example in which arbitrary data is message-communicated in addition to IO refresh that is repeatedly executed at predetermined intervals.
  • a communication frame FL for performing an IO refresh is transmitted every predetermined system cycle Ts via the local bus 112 (transmission path).
  • the communication frame FL for performing the IO refresh is sent from the CPU unit 100 and sequentially transferred to the adjacent functional units 150.
  • Input data collected by each functional unit 150 and output data including instructions for each functional unit 150 may be transmitted using different communication frames FL, or may be transmitted using the same communication frame FL. It may be.
  • the message frame MSGFL may be transmitted from the CPU unit 100 to a specific functional unit 150, transferred in the opposite direction, or transmitted between arbitrary functional units 150. .
  • message frame MSGFL is generated and transmitted after transmission of communication frame FL is completed.
  • the message frame MSGFL starts to be sent after a delay time D1 after the message transmission request is given.
  • FIG. 2C it is assumed that a message transmission request is given immediately before transmission of the communication frame FL for performing the IO refresh.
  • the transmission period of the communication frame FL is approaching, the generation and transmission of the message frame MSGFL is prevented, and the message frame MSGFL is generated and transmitted after the transmission of the subsequent communication frame FL is completed.
  • the message frame MSGFL starts to be sent after a delay time D2 after the message transmission request is given.
  • FIGS. 2B and 2C do not consider anything other than IO refresh, but when a large number of message transmission requests are issued first, they are made first. A message frame transmission delay occurs depending on the number of transmission requests.
  • FIG. 3 is a schematic diagram showing an example of initialization processing according to the related art in PLC 1 according to the present embodiment.
  • the initialization process shown in FIG. 3 shows an example in which a start time for synchronizing data transmission via the local bus 112 is instructed from the CPU unit 100 functioning as a master to the functional unit 150 functioning as a slave.
  • This start time corresponds to an instruction for establishing synchronous communication, and includes timing indicated by mutually synchronized clocks.
  • CPU unit 100 functioning as a master and each of functional units 150-1 to 150-3 connected to CPU unit 100 via local bus 112 are synchronized with each other.
  • the bus communication circuit 108 of the CPU unit 100 has a master clock 109 that serves as a reference for data transmission on the local bus 112, and the bus communication circuit 152 of each functional unit 150 includes a master clock.
  • Ordinary clock 153 synchronized with 109.
  • the communication controller 154 of each functional unit 150 manages data transmission / reception based on the timing indicated by the ordinary clock 153 of the bus communication circuit 152. By such data transmission / reception timing management using mutually synchronized clocks, data transmission without collision on the local bus 112 can be realized.
  • FIG. 3A shows a state in which synchronous communication is established with the CPU unit 100 only for the functional units 150-1 and 150-2.
  • FIG. 3B shows an initialization process for newly establishing synchronous communication for the functional unit 150-3 in the state shown in FIG.
  • the ordinary clock 153 of the functional unit 150-3 is synchronized with the master clock 109 of the CPU unit 100, synchronous communication is started from the CPU unit 100 to the target functional unit 150-3.
  • the timing (start time) to be notified is notified.
  • the functional unit 150-3 starts transmitting or receiving data when the ordinary clock 153 indicates the notified start time.
  • the start time notified from the CPU unit 100 must be a future time, and if a past time is designated, it is processed as invalid. Such a notification of the start time is transmitted by message communication according to a procedure as shown below.
  • C2 First initialization procedure
  • the bus communication circuit 152 has a register (not shown), and when the clock value of its own ordinary clock 153 reaches the start time written in this register, it issues an interrupt command to the communication controller 154, Establish synchronization.
  • FIG. 4 is a schematic diagram showing a first initialization procedure between the CPU unit 100 and the functional unit 150. With reference to FIG. 4, the basic software structure of the CPU unit 100 will be described first.
  • the CPU unit 100 includes a scheduler 120, a plurality of tasks (IO refresh task 130 and system service task 140), a bus driver 113, and a field network driver 115. These components are realized by the processor 102 of the CPU unit 100 executing a system program and a user program.
  • the scheduler 120 controls the execution cycle and execution timing of a plurality of tasks registered in advance based on the priority set for each task. Among these tasks, the highest priority is set for the IO refresh task 130, and a process for sending a communication frame (see FIG. 2 and the like) for performing the IO refresh at every predetermined system cycle. Execute. On the other hand, the lowest priority is set for the system service task 140, and the system service task 140 is appropriately executed during a period in which other tasks such as the IO refresh task 130 are not executed.
  • the IO refresh task 130 provides at least a part of a function of sending a communication frame every predetermined cycle (system cycle Ts) via the local bus 112 (transmission path), and gives a request to the bus driver 113. Then, a communication frame for performing IO refresh is transmitted on the local bus 112. At the same time, the IO refresh task 130 transmits a communication frame or packet for performing an IO refresh on the field network 114 by giving a command to the field network driver 115.
  • the system service task 140 includes a message routing task 142, a slave state management task 144, and an event communication processing task 146.
  • the message routing task 142 interprets a message frame on the local bus 112 or the field network 114 and determines a route for transmitting the message frame.
  • the slave state management task 144 manages the state of the slave (functional unit 150) connected via the local bus 112.
  • the event communication processing task 146 provides at least a part of a function of sending another communication frame in response to an arbitrary event request in a period in which a communication frame for performing an IO refresh is not transmitted.
  • the event communication processing task 146 executes processing for transmitting a message frame in response to some event request.
  • the event communication processing task 146 manages a queue 148 that sequentially registers transmission requests.
  • registration (input) of some data to the queue is also referred to as queuing
  • deletion (output) of data from the queue is also referred to as dequeuing.
  • the slave state management task 144 executes a clock setting process. More specifically, the slave state management task 144 instructs each functional unit 150 to synchronize the ordinary clock 153 with the master clock 109.
  • the slave state management task 144 In a state where the clocks are synchronized, as a first procedure, the slave state management task 144 reads a clock value from the master clock 109 of the bus communication circuit 108 and calculates a start time to be set in the slave. Then, as a second procedure, the slave state management task 144 sends a transmission request for a register write frame for writing the calculated start time to the register to the specific slave (functional unit 150). Output to.
  • This register write frame transmission request is registered in the queue 148.
  • the event communication processing task 146 sequentially processes transmission requests registered in the queue 148. When the transmission request registered in the queue 148 is sequentially processed and the transmission request for the previously registered register write frame can be processed, the event communication processing task 146 performs the event frame transmission request as a third procedure. Is output to the bus driver 113. As a fourth procedure, the bus driver 113 activates communication of the bus communication circuit 108 in response to an event frame transmission request. Then, a register write frame is sent from the
  • the bus communication circuit 152 of the functional unit 150 sets the start time included in the received register write frame to the internal register. Write to. Then, the bus communication circuit 152 of the functional unit 150 starts the synchronization process when the start time when the ordinary clock 153 is written in the register is reached.
  • the initialization process for newly establishing the synchronous communication between the CPU unit 100 and the functional unit 150 is completed by the first to sixth procedures as described above.
  • FIG. 5 is a schematic diagram showing a second initialization procedure between the CPU unit 100 and the functional unit 150. First, the basic software structure of the functional unit 150 will be described with reference to FIG.
  • a message routing task 162 In the functional unit 150, a message routing task 162, a state management task 164, and a bus driver 166 are implemented. These components are provided by communication controller 154.
  • the message routing task 162 interprets a message frame on the local bus 112 and determines a route for transmitting the message frame.
  • the state management task 164 manages a state for connecting to the CPU unit 100 via the local bus 112.
  • the bus driver 113 performs transmission / reception management of data exchanged on the local bus 112 via the bus communication circuit 152.
  • the slave state management task 144 executes a clock setting process. More specifically, the slave state management task 144 instructs each functional unit 150 to synchronize the ordinary clock 153 with the master clock 109.
  • the slave state management task 144 In a state where the clocks are synchronized, as a first procedure, the slave state management task 144 reads a clock value from the master clock 109 of the bus communication circuit 108 and calculates a start time to be set in the slave. Then, as a second procedure, the slave state management task 144 outputs a message routing request for a communication frame including the calculated start time to the message routing task 142 to a specific slave (functional unit 150). As a third procedure, the message routing task 142 interprets the message routing request from the slave state management task 144 to identify a destination slave and sends a message frame transmission request for transmitting a message frame to the slave. Is output to the event communication processing task 146. This message frame transmission request is registered in the queue 148.
  • the event communication processing task 146 sequentially processes transmission requests registered in the queue 148.
  • the event communication processing task 146 buses the event frame transmission request.
  • the bus driver 113 activates communication of the bus communication circuit 108 in response to an event frame transmission request. Then, a message frame is transmitted from the bus communication circuit 108 onto the local bus 112.
  • the bus communication circuit 152 of the functional unit 150 issues an interrupt to the bus driver 166 when the message frame is received. Issue.
  • the bus driver 166 outputs the received message frame to the message routing task 162 and requests routing for the received message frame.
  • the message routing task 162 interprets that the content of the message frame from the bus driver 166 is a start time setting request to the bus communication circuit 152, and outputs a clock setting request to the state management task 164.
  • the state management task 164 writes the designated start time in the register of the bus communication circuit 152 in response to the clock setting request. Then, the bus communication circuit 152 of the functional unit 150 starts the synchronization process when the start time when the ordinary clock 153 is written in the register is reached.
  • the initialization process for newly establishing synchronous communication between the CPU unit 100 and the functional unit 150 is completed by the first to tenth procedures as described above.
  • a transmission request may be generated from another task, a message transmission request other than the register write frame transmission request or the message frame transmission request is already registered in the queue 148 of the event communication processing task 146. In some cases. For this reason, after issuing a register write frame transmission request or a message frame transmission request, when the frame transmission request is processed depends on the state of the transmission request previously registered in the queue 148.
  • FIG. 6 is a schematic diagram for explaining one problem in the initialization process according to the related art.
  • the frame transmission request is registered and processed (queue and dequeue) in the queue 148 of the event communication processing task 146 by FIFO (First In First Out).
  • FIFO First In First Out
  • FIG. 6 when a register write frame transmission request (or message frame transmission request) for executing the initialization process as described above is registered in the queue 148, two transmission requests are already registered in the queue 148. It shows the state. In such a state, it is impossible to accurately estimate when the two previously registered transmission requests are processed (dequeued).
  • the start time notified from the CPU unit 100 must be a future time. This is because the designated start time must be a future time when it arrives at the functional unit 150. On the other hand, as described above, there is an uncertain element regarding when the communication frame including the start time is transmitted.
  • the initialization process may be executed with an excessively large margin set at the indicated start time, or in the worst case, the initialization process may fail and the initialization process must be repeated. To do. That is, in the initialization process according to the related art as described above, it is not easy to complete the process early and reliably.
  • FIG. 7 is a schematic diagram showing a functional configuration in PLC 1 according to the present embodiment.
  • CPU unit 100 of PLC 1 according to the present embodiment has a high-priority event queue management task 136 added to the configuration shown in FIGS. 4 and 5, and event communication processing task 146.
  • a high priority event queue 149 is prepared.
  • the event communication processing task 146 includes a queue 148 that sequentially stores normal event requests and a queue 149 that sequentially stores high priority event requests.
  • the system service task 140 includes not only the message routing task 142 and the slave state management task 144 shown in FIG. 7, but also other system service tasks (system service group 141). Part or all of the system service group 141 generates an event processing client 145, and the event processing client 145 issues an event request according to the processing. These event requests are registered in the event communication processing task 146 and the like.
  • the event processing client 145 issues a normal event request in response to the processing, and the slave state management task 144 generates an event request related to the start of initialization processing with the functional unit 150. This corresponds to a high priority event request having a higher priority than a normal event request.
  • the high priority event request from the event processing client 145 includes an instruction for the specific functional unit 150 to establish synchronous communication with the CPU unit 100 via the local bus 112 (transmission path).
  • an “event request” refers to a request related to various processes (including data transmission by message communication) generated by an internal event when an internal event is issued due to the arrival of some condition or period.
  • “Normal” and “High priority” are terms indicating relative priority, meaning that “High priority” event requests are processed in preference to “Normal” event requests.
  • the "normal” and “high priority” designations are for convenience and the term should not be construed restrictively.
  • the high priority event queue management task 136 provides at least a part of a priority management function for preferentially processing a high priority event request issued by the slave state management task 144. Specifically, the high priority event queue management task 136 manages the high priority event queue 138 for controlling the output timing of the transmission request to the high priority event queue 149. As described later, a high priority event request is registered in the high priority event queue 138 from the slave state management task 144 as necessary. A processing procedure between the high priority event queue management task 136 and the event communication processing task 146 will be described later.
  • FIG. 8 is a schematic diagram for explaining exchanges between modules in the initialization process according to the present embodiment.
  • FIG. 9 is a sequence diagram showing a processing procedure in the initialization processing according to the present embodiment. Note that the numbers in parentheses shown in FIG. 8 correspond to the numbers in parentheses shown in FIG.
  • the slave state management task 144 executes a clock setting process. More specifically, the slave state management task 144 instructs each functional unit 150 to synchronize the ordinary clock 153 with the master clock 109. Each step shown in FIG. 9 is executed in a state where the clocks are synchronized.
  • step S1 when receiving an initialization processing request (step S1), slave state management task 144 issues a high priority event request to high priority event queue management task 136 (step S2). . Then, the high priority event queue management task 136 queues the issued high priority event request in the high priority event queue 138 (step S3). That is, a high priority event request is registered in the high priority event queue 138. The high priority event queue management task 136 notifies the event communication processing task 146 (the normal event queue 148 and the high priority event queue 149) that the high priority event request is registered (step S4).
  • the normal event request process during the transmission process is continued (step S5). More specifically, the event communication processing task 146 outputs the normal event request registered in the queue 148 to the bus driver 113 during transmission processing (step S51). The bus driver 113 starts communication of the bus communication circuit 108 according to the normal event request (step S52). Then, a communication frame or the like corresponding to the normal event request is transmitted from the bus communication circuit 108 onto the local bus 112. When the processing for the registered normal event request is completed, the event communication processing task 146 deletes (dequeues) the normal event request registered in the queue 148 (step S53).
  • the event communication processing task 146 When the event communication processing task 146 receives the notification that the high priority event request is registered, if there is a normal event request being transmitted, the normal event request processing during the transmission processing is completed.
  • the high priority process enabled notification is notified to the high priority event queue management task 136 (step S6). At this time, processing that has been registered in the queue 148 of the event communication processing task 146 but has not yet been processed is temporarily processed.
  • the high priority processing enable notification is displayed.
  • the priority event queue management task 136 is notified. That is, the high-priority processable notification is a notification indicating that a high-priority event request can be preferentially processed as will be described later.
  • the scheduler 120 periodically issues a trigger for instructing the start of processing to the high priority event queue management task 136 (step S7).
  • the scheduler 120 issues a trigger in step S7 at a timing that does not prevent the IO refresh task 130 from executing the IO refresh.
  • the thread related to the high priority event (priority is set higher than normal) is activated, and the event communication processing task If the high-priority process enable notification is received from 146, the slave state management task 144 is notified of the start of the high-priority event (step S8).
  • the thread related to the high priority event is set with a high priority that can guarantee realistic real-time performance, but is lower than the IO refresh priority.
  • steps S4 to S8 described above when a request for issuing a high priority event request (high priority event request shown in step S2) is received, transmission processing of the communication frame corresponding to the normal event request currently being processed is completed. After waiting, the issuance of a high priority event request is permitted (high priority processing possible notification is issued). At this time, the processing for the subsequent normal event request subsequent to the normal event request currently being processed is suspended until the processing for the high priority event request is completed.
  • the start of the high priority event notified to the slave state management task 144 corresponds to an affirmative response (callback) to the high priority event request (step S2) from the slave state management task 144, and initialization processing is performed by the start of the high priority event.
  • the process for determining the timing (start time) necessary for the start is started. More specifically, the slave state management task 144 inquires of the scheduler 120 about the start time to be set for the functional unit 150 to be initialized (step S9). In response to this inquiry, the scheduler 120 calculates a start time and responds to the slave state management task 144 (step S10). As this start time, a value managed by the ordinary clock 153 of each functional unit 150 synchronized with the master clock 109 of the bus communication circuit 108 is used.
  • a value associated with an IO refresh transmission cycle may be used as a start time to which the scheduler 120 responds.
  • a Tick time set before transmission of the IO refresh communication frame may be used.
  • FIG. 10 is a schematic diagram for explaining the start time to which the scheduler 120 of the PLC 1 according to the present embodiment responds.
  • a communication frame for performing IO refresh is transmitted every predetermined system cycle Ts.
  • Each functional unit 150 transmits input data collected in advance to the CPU unit 100 functioning as a master and is transmitted from the CPU unit 100 using one or a plurality of communication frames according to a predetermined communication procedure. Get output data.
  • the tick time is set a predetermined time ⁇ Tt before the communication frame for performing the IO refresh arrives at each functional unit 150, and each functional unit 150 starts collecting input data at the tick time. Therefore, if any tick time is designated as the start time, input data can be written to a communication frame that arrives immediately after the designated tick time. That is, synchronous communication with the CPU unit 100 can be established.
  • a tick time that is two (or more) ahead from the current time may be set as the start time.
  • the start time can be notified with the highest priority other than the IO refresh. Yes. For this reason, it is guaranteed that the start time is notified before at least two Tick times ahead.
  • the time Tick02 is set as the start time.
  • Tick 03 which is the Tick time
  • Tick 03 is set as the start time for the second IO refresh.
  • the slave state management task 144 requests the message routing task 142 to create a message routing header as necessary (step S11). Specifically, when the initialization procedure is realized by a method of transmitting a message frame from the CPU unit 100 to the functional unit 150 as in the second initialization procedure shown in FIG.
  • the management task 144 requests creation of a message routing header for transmitting a message frame to the functional unit 150 to be initialized.
  • the message routing task 142 creates a necessary header according to the position of the functional unit 150 to be initialized on the local bus 112, 212 and / or the field network 114, and responds to the slave state management task 144 (step). S12). As described above, the processes in steps S11 and S12 are optional processes.
  • the slave state management task 144 outputs data to be transmitted as a high priority event request to the event communication processing task 146 (step S13).
  • the data from the slave state management task 144 is queued in the high priority event queue 149 (step S14). That is, data to be transmitted as a high priority event request is registered in the queue 149 of the event communication processing task 146.
  • the data to be transmitted as the high priority event request includes the start time acquired in step S10.
  • the high priority event queue management task 136 notifies the event communication processing task 146 of the start of event communication (step S15).
  • the event communication processing task 146 starts generating a necessary message (communication frame or message) and starting communication with the bus communication circuit 108. That is, the event communication processing task 146 receives an event communication start notification from the high priority event queue management task 136, and outputs an event frame transmission request to the bus driver 113 (step S16).
  • the bus driver 113 activates communication of the bus communication circuit 108 (step S17). Then, the designated communication frame (register write frame or message frame) is sent from the bus communication circuit 108 onto the local bus 112 (step S18).
  • the communication frame corresponding to the high priority event request and the normal event request is sent during a period in which the IO refresh communication frame is not transmitted.
  • the high priority event queue management task 136 dequeues the high priority event request from the high priority event queue 138 (step S19). That is, the high priority event request is deleted from the high priority event queue 138.
  • the event communication processing task 146 dequeues the data to be processed from the high priority event queue 149 (step S20). That is, data necessary for the initialization process is deleted from the high priority event queue 149.
  • the initialization process for newly establishing synchronous communication between the CPU unit 100 and the functional unit 150 is completed by the processing procedure as described above.
  • FIG. 11 is a schematic diagram for explaining processing in normal event queue 148 and high priority event queue 149 of event communication processing task 146 of PLC 1 according to the present embodiment.
  • the high priority event queue management task 136 has a high priority. Assume a case where an event request registration notification is made. At this time, when the high priority event queue management task 136 receives a request for issuing a high priority event request from the slave state management task 144 (high priority event request shown in step S2 of FIG. 8), the event communication processing task 146 performs the current processing. Waiting for the completion of the transmission process of the communication frame corresponding to the normal event request in the middle, the issuance of the high priority event request is permitted to the slave state management task 144 (high priority processing possible notification shown in step S6 of FIG. 8). Issue).
  • the high-priority event queue management task 136 receives a request for issuing a high-priority event request from the slave state management task 144 (the high-priority event request shown in step S2 of FIG. 8).
  • the issue request is notified to the event communication processing task 146.
  • the event communication processing task 146 continues the transmission processing being executed for the normal event request A.
  • FIG. 11B when the transmission process for the normal event request A that has been executed previously is completed, the normal event request A is deleted from the queue 148 while being registered in the queue 148 next.
  • the transmission process for the normal event request B is temporarily stopped.
  • the event communication processing task 146 is notified that the high priority event request can be processed when the processing for the normal event request currently being processed is completed after being notified of the request for issuing the high priority event request.
  • a processable notification is notified to the high priority event queue management task 136.
  • a new normal event request is accepted even when execution of processing for a normal event request registered in the queue 148 is temporarily stopped. That is, when a new normal event request is issued, the normal event request is additionally registered in the queue 148. These normal event requests are sequentially executed after the processing for the high priority event request is completed.
  • the event communication processing task 146 suspends the processing for the subsequent normal event request subsequent to the normal event request currently being processed until the processing for the high priority event request is completed. That is, after processing only normal event requests previously registered in the queue 148, the subsequent processing of the normal event request is interrupted, and it is notified that high priority processing is possible. By adopting such processing, the communication frame corresponding to the requested high priority event request can be transmitted with the highest priority, and the necessary data corresponding to the queue 149 is registered.
  • the present invention is applicable to an arbitrary processing procedure realized by exchanging data between the units 250 by message communication.
  • the timing of message communication is determined according to low priority scheduling. Therefore, when an event requiring another message communication occurs, the request is made at any timing. It is difficult to predict whether a communication frame that has been transmitted can be transmitted.
  • transmission of a communication frame related to the initialization process can be a high priority event request, and a normal event request generated by another event processing client Processing is possible with higher priority.
  • the processing time for each event request is not guaranteed. Therefore, in order to keep the time constraint, it is necessary to execute communication processing assuming the worst arrival time with a margin.
  • the arrival time can be guaranteed, so it is easy to estimate the required processing time and the processing time itself can be shortened. In addition, usability can be improved.
  • 1 PLC 100 CPU unit, 102, 202 processor, 104, 204 main memory, 106, 206 storage, 108, 152, 208, 252 bus communication circuit, 109 master clock, 110, 210 network interface, 112, 212 local bus, 113,166 bus driver, 114 field network, 115 field network driver, 120 scheduler, 130 refresh task, 136 high priority event queue management task, 138 high priority event queue, 140 system service task, 141 system service group, 142, 162 message Routing task, 144 Slave state management task, 145 Event processing client, 1 6 Event communication processing task, 148, 149 queue, 150, 250 functional unit, 153 Ordinary clock, 154, 254 communication controller, 156, 256 functional module, 164 status management task, 200 communication coupler unit, 201 controller, FL communication frame, MSGFL message frame, Ts system cycle.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Programmable Controllers (AREA)

Abstract

演算装置は、通信インターフェイスと、伝送路を介して所定周期毎に第１の通信フレームを送出する第１の伝送制御手段と、任意のイベント要求に応答して、第２の通信フレームを送出する第２の伝送制御手段と、優先度管理手段とを含む。優先度管理手段は、第２のイベント発行手段から第２のイベント要求の発行要求を受けると、第２の伝送制御手段において現在処理中の第１のイベント要求に対応する第２の通信フレームの送出処理の完了を待って、第２のイベント発行手段に対して第２のイベント要求の発行を許可する。第２の伝送制御手段は、現在処理中の第１のイベント要求に引き続く後続の第１のイベント要求に対する処理を、第２のイベント要求に対する処理の完了まで中断する。

Description

演算装置、制御装置および制御方法
　本発明は、１または複数の機能ユニットを含む制御装置を構成する演算装置およびその制御装置に関する。
　様々なＦＡ（Factory　Automation）を実現するための主たるコンポーネントとして、ＰＬＣ（プログラマブルコントローラ）などの制御装置が普及している。このような制御装置は、各種プログラムを実行するＣＰＵユニットと、ＣＰＵユニットと伝送路を介して接続される１または複数の機能ユニットとから構成されることがある。このような構成において、ＣＰＵユニットと機能ユニットとの間では、伝送路を介してデータが遣り取りされる。
　ところで、ＰＬＣなどの制御装置においては、入力値の取得および制御指令の出力を高精度に同期させたいという要求がある。このような要求に応えるために、伝送路を介して接続されているＣＰＵユニットおよび機能ユニットは、各々に内蔵されるクロック（典型的には、カウンタを用いて実装される）が互いに同期した状態に維持される。そして、ＣＰＵユニットおよび機能ユニットの各々は、互いに同期したクロックに基づいて、送信タイミングおよび受信タイミングを調整する。例えば、特開２０１１－２１６０８５（特許文献１）は、このようなクロックの同期、すなわち時刻合わせの一手法を開示する。
　このような時刻同期された構成において、機能ユニットが収集した入力データをＣＰＵユニットが取得する処理、および、ＣＰＵユニットにて算出された制御指令を機能ユニットへ出力する処理を含むＩＯ（Input　Output）リフレッシュが所定周期毎に実行される。ＩＯリフレッシュが実行される期間以外の期間に、メッセージ通信でデータが遣り取りされることもある。特許文献１においては、マスタユニットとスレーブユニットとの間で実際にメッセージを送受することで伝搬遅延時間を求めて、その伝搬遅延時間を用いて時刻補正を行うことが開示されている。
特開２０１１－２１６０８５号公報
　上述したようなメッセージ通信は、例えば、ＣＰＵユニットと機能ユニットとの間の接続を確立するための処理や各種の起動処理に利用されることもある。このような用途に使用されるメッセージ通信で伝送されるデータは、可能な限り速やかに送出されることが好ましいが、一般的には、ＩＯリフレッシュには最も高い優先度が設定されるので、伝送路の状況によっては、メッセージ通信でデータを速やかに伝送できない場合がある。
　本発明は、ＩＯリフレッシュなどに係る通信フレームが所定周期で伝送される伝送路において、メッセージ通信における送信先への到着時刻を保証するための新たな構成を提供することを目的とする。
　本発明のある局面に従う、制御装置を構成する演算装置は、伝送路を介して１または複数の機能ユニットとの間でデータを遣り取りするための通信インターフェイスと、伝送路を介して所定周期毎に第１の通信フレームを送出する第１の伝送制御手段と、第１の通信フレームが伝送されていない期間において、任意のイベント要求に応答して、第２の通信フレームを送出する第２の伝送制御手段と、処理に応じて第１のイベント要求を発行する第１のイベント発行手段と、第１のイベント要求より優先度の高い第２のイベント要求を発行する第２のイベント発行手段と、第２のイベント発行手段により発行される第２のイベント要求を優先的に処理するための優先度管理手段とを含む。優先度管理手段は、第２のイベント発行手段から第２のイベント要求の発行要求を受けると、第２の伝送制御手段において現在処理中の第１のイベント要求に対応する第２の通信フレームの送出処理の完了を待って、第２のイベント発行手段に対して第２のイベント要求の発行を許可する。第２の伝送制御手段は、現在処理中の第１のイベント要求に引き続く後続の第１のイベント要求に対する処理を、第２のイベント要求に対する処理の完了まで中断する。
　好ましくは、第２の伝送制御手段は、第１のイベント要求を順次格納する第１のキューと、第２のイベント要求を順次格納する第２のキューとを含む。
　好ましくは、優先度管理手段は、第２のイベント要求の発行要求を受けると、当該発行要求を第２の伝送制御手段へ通知し、第２の伝送制御手段は、第２のイベント要求の発行要求を通知された後、現在処理中の第１のイベント要求についての処理が完了すると、第２のイベント要求が処理可能である旨を優先度管理手段へ通知する。
　好ましくは、第２のイベント要求は、特定の機能ユニットが伝送路を介して演算装置との間で同期通信を確立するための指示を含む。
　好ましくは、伝送路を介して接続される演算装置および１または複数の機能ユニットの各々は、互いに同期したクロックを有しており、同期通信を確立するための指示は、互いに同期したクロックが示すタイミングを含む。
　好ましくは、タイミングは、第１の通信フレームの送出周期に関連付けられた値に設定される。
　本発明の別の局面に従う制御装置は、演算装置と、演算装置と伝送路を介してデータを遣り取り可能に接続された１または複数の機能ユニットとを含む。演算装置は、伝送路を介して所定周期毎に第１の通信フレームを送出する第１の伝送制御手段と、第１の通信フレームが伝送されていない期間において、任意のイベント要求に応答して、第２の通信フレームを送出する第２の伝送制御手段と、処理に応じて第１のイベント要求を発行する第１のイベント発行手段と、第１のイベント要求より優先度の高い第２のイベント要求を発行する第２のイベント発行手段と、第２のイベント発行手段により発行される第２のイベント要求を優先的に処理するための優先度管理手段とを含む。優先度管理手段は、第２のイベント発行手段から第２のイベント要求の発行要求を受けると、第２の伝送制御手段において現在処理中の第１のイベント要求に対応する第２の通信フレームの送出処理の完了を待って、第２のイベント発行手段に対して第２のイベント要求の発行を許可する。第２の伝送制御手段は、現在処理中の第１のイベント要求に引き続く後続の第１のイベント要求に対する処理を、第２のイベント要求に対する処理の完了まで中断する。
　本発明のさらに別の局面に従えば、演算装置と、演算装置と伝送路を介してデータを遣り取り可能に接続された１または複数の機能ユニットとを備えた制御装置における制御方法が提供される。制御方法は、伝送路を介して所定周期毎に第１の通信フレームを送出するステップと、処理に応じて第１のイベント要求を発行するステップと、第１のイベント要求より優先度の高い第２のイベント要求を発行するステップと、第１の通信フレームが伝送されていない期間において、第１のイベント要求または第２のイベント要求に応答して、第２の通信フレームを送出するステップと、第２のイベント要求の発行要求を受けると、現在処理中の第１のイベント要求に対応する第２の通信フレームの送出処理の完了を待って、第２のイベント要求の発行を許可するステップと、現在処理中の第１のイベント要求に引き続く後続の第１のイベント要求に対する処理を、第２のイベント要求に対する処理の完了まで中断するステップとを含む。
　本発明に従えば、ＩＯリフレッシュなどに係る通信フレームが所定周期で伝送される伝送路において、メッセージ通信における送信先への到着時刻を保証することができる。
本実施の形態に従うＰＬＣの要部構成を示す模式図である。 本実施の形態に従うＰＬＣのローカルバス上でのデータ伝送を説明するための模式図である。 本実施の形態に従うＰＬＣにおける関連技術に従う初期化処理の一例を示す模式図である。 ＣＰＵユニットと機能ユニットとの間の第１の初期化手順を示す模式図である。 ＣＰＵユニットと機能ユニットとの間の第２の初期化手順を示す模式図である。 関連技術に従う初期化処理における一つの課題を説明するための模式図である。 本実施の形態に従うＰＬＣにおける機能構成を示す模式図である。 本実施の形態に従う初期化処理におけるモジュール間の遣り取りを説明する模式図である。 本実施の形態に従う初期化処理における処理手順を示すシーケンス図である。 本実施の形態に従うＰＬＣのスケジューラが応答するスタートタイムを説明するための模式図である。 本実施の形態に従うＰＬＣのイベント通信処理タスクの通常イベントのキューおよび高優先イベントのキューにおける処理を説明するための模式図である。
　本発明の実施の形態について、図面を参照しながら詳細に説明する。なお、図中の同一または相当部分については、同一符号を付してその説明は繰返さない。
　以下の説明においては、「制御装置」の典型例として、ＰＬＣ（プラグラマブルコントローラ）を具体例として説明するが、ＰＬＣとの名称に限定されることなく、本明細書に開示された技術的思想は、任意の制御装置に対して適用可能である。
　＜Ａ．装置構成＞
　まず、本実施の形態に従うＰＬＣの装置構成について説明する。図１は、本実施の形態に従うＰＬＣの要部構成を示す模式図である。
　図１を参照して、本実施の形態に従うＰＬＣ１は、基本的な構成として、ＣＰＵユニット１００と、１または複数の機能ユニット１５０とからなる。ＣＰＵユニット１００は、ＰＬＣ１を構成する一要素であり、ＰＬＣ１全体の処理を制御する演算装置に相当する。機能ユニット１５０は、ＰＬＣ１による様々な機械や設備の制御を実現するための各種機能を提供する。ＣＰＵユニット１００と１または複数の機能ユニット１５０との間は、伝送路の一例であるローカルバス１１２を介して接続されている。
　ＣＰＵユニット１００は、ローカルバス１１２を介して、任意の機能ユニット１５０との間でデータを遣り取りすることができる。典型的には、ＣＰＵユニット１００は、１または複数の機能ユニット１５０との間で所定周期毎にＩＯリフレッシュが実行される。このＩＯリフレッシュにおいては、各機能ユニット１５０が収集している入力データがＣＰＵユニット１００へ送信されとともに、ＣＰＵユニット１００にて算出される制御指令が任意の機能ユニット１５０へ送信される。このようなＩＯリフレッシュに加えて、ＣＰＵユニット１００と任意の機能ユニット１５０との間、あるいは、任意の機能ユニット１５０の間で、メッセージ通信でのデータの送受信が可能になっている。メッセージ通信は、一対一の態様に限らず、一対複数の態様が可能であってもよい。
　図１には、応用的な構成として、ＰＬＣ１にリモートＩＯ装置が接続されている構成を示す。すなわち、ＣＰＵユニット１００には、伝送路の別の一例であるフィールドネットワーク１１４を介して、１または複数の通信カプラユニット２００が接続されている。通信カプラユニット２００の各々には、伝送路の一例であるローカルバス２１２を介して、１または複数の機能ユニット２５０が接続されている。
　なお、機能ユニット１５０と機能ユニット２５０とは実質的に同様の構成を有しており、説明の便宜上、符号を異ならせているだけである。但し、ＣＰＵユニット１００に接続される機能ユニット１５０と、通信カプラユニット２００に接続される機能ユニット２５０との間で、何らかの機能を異ならせるようにしてもよい。
　ＣＰＵユニット１００は、通信カプラユニット２００に接続されている機能ユニット２５０に対してもＩＯリフレッシュおよびメッセージ通信が可能になっている。すなわち、通信カプラユニット２００は、ＣＰＵユニット１００と機能ユニット２５０との間のデータの遣り取りを仲介する機能を提供する。より具体的には、ＣＰＵユニット１００からフィールドネットワーク１１４を介して送信されるデータは、通信カプラユニット２００を介してローカルバス２１２上に転送され、目的の機能ユニット２５０まで届けられる。逆に、任意の機能ユニット２５０からローカルバス２１２を介して送信されたデータは、通信カプラユニット２００を介してフィールドネットワーク１１４上に転送され、ＣＰＵユニット１００まで届けられる。
　より具体的には、ＣＰＵユニット１００は、プロセッサ１０２と、メインメモリ１０４と、ストレージ１０６と、バス通信回路１０８と、ネットワークインターフェイス１１０とを含む。
　プロセッサ１０２は、システムプログラムおよびユーザプログラムを実行することで、ＰＬＣ１での処理を実現する。プロセッサ１０２は、例えば、ＣＰＵ（Central　Processing　Unit）やＧＰＵ（Graphics　Processing　Unit）などを用いることができる。プロセッサ１０２としては、シングルコアかつシングルチップの構成であってもよいし、マルチコアのシングルチップ、シングルコアのマルチチップ、マルチコアのマルチチップのいずれであってもよい。
　メインメモリ１０４は、ＤＲＡＭ（Dynamic　Random　Access　Memory）やＳＲＡＭ（Static　Random　Access　Memory）などで構成され、プロセッサ１０２でのプログラムの実行に必要なワーク領域を提供する。
　ストレージ１０６は、フラッシュメモリなどの半導体記憶デバイスで構成され、ＣＰＵユニット１００の基本的な機能を実現するためのシステムプログラムや、制御対象に応じて任意に作成されるユーザプログラムなどを格納する。
　バス通信回路１０８は、伝送路を介して１または複数の機能ユニット１５０との間でデータを遣り取りするための通信インターフェイスに相当し、ＣＰＵユニット１００と各機能ユニット１５０との間のローカルバス１１２（伝送路）を介したデータ伝送を仲介する。バス通信回路１０８の少なくとも一部は、ハードワイヤードな回路で実装してもよい。バス通信回路１０８は、ローカルバス１１２上のデータ伝送を管理する「マスター」として機能してもよい。この場合、ローカルバス１１２に接続される機能ユニット１５０の各々は、バス通信回路１０８の管理下でデータ伝送を行う「スレーブ」として機能してもよい。バス通信回路１０８を用いた、ＣＰＵユニット１００と各機能ユニット１５０との間のデータ送受信の処理については、後述する。
　ネットワークインターフェイス１１０は、ＣＰＵユニット１００と各通信カプラユニット２００を含む任意のデバイスとの間のフィールドネットワーク１１４を介したデータ伝送を仲介する。ネットワークインターフェイス１１０は、フィールドネットワーク１１４上のデータ伝送を管理する「マスター」として機能してもよい。この場合、フィールドネットワーク１１４に接続される通信カプラユニット２００および他のデバイスの各々は、ネットワークインターフェイス１１０の管理下でデータ伝送を行う「スレーブ」として機能してもよい。なお、フィールドネットワーク１１４としては、例えば、ＥｔｈｅｒＣＡＴ（登録商標）、ＥｔｈｅｒＮｅｔ／ＩＰ（登録商標）、ＤｅｖｉｃｅＮｅｔ（登録商標）、ＣｏｍｐｏＮｅｔ（登録商標）などの公知のプロトコルに従う、定周期ネットワークを採用してもよい。
　機能ユニット１５０は、ＣＰＵユニット１００で実行されるユーザプログラムに必要な情報の収集、ユーザプログラムの実行により算出される制御指令の出力、ＣＰＵユニット１００とは独立した特殊処理の実行といった、任意の機能を提供する。典型的には、機能ユニット１５０は、ＩＯユニット、通信ユニット、温度調整ユニット、ＩＤ（Identifier）センサユニットなどを包含し得る。
　ＩＯユニットとしては、例えば、デジタル入力（ＤＩ）ユニット、デジタル出力（ＤＯ）ユニット、アナログ出力（ＡＩ）ユニット、アナログ出力（ＡＯ）ユニット、パルスキャッチ入力ユニット、および、複数の種類を混合させた複合ユニットなどが挙げられる。
　通信ユニットは、他のＰＬＣ、他のリモートＩＯ装置、他の機能ユニットなどとデータの遣り取りを仲介するものであり、例えば、ＥｔｈｅｒＣＡＴ（登録商標）、ＥｔｈｅｒＮｅｔ／ＩＰ（登録商標）、ＤｅｖｉｃｅＮｅｔ（登録商標）、ＣｏｍｐｏＮｅｔ（登録商標）などのプロトコルに係る通信装置などを包含し得る。
　温度調整ユニットは、温度計測値などを取得するアナログ入力機能と、制御指令などを出力するアナログ出力機能と、ＰＩＤ（Proportional　Integral　Differential）制御機能とを含む制御装置である。ＩＤセンサユニットは、ＲＦＩＤ（Radio　Frequency　IDentifier）などから非接触でデータを読出す装置である。
　より具体的には、機能ユニット１５０の各々は、バス通信回路１５２と、通信コントローラ１５４と、機能モジュール１５６とを含む。
　通信コントローラ１５４は、ローカルバス１１２を伝送されるデータ（典型的には、通信フレーム）を処理する。具体的には、通信コントローラ１５４は、マスターであるバス通信回路１０８による管理に従って、ローカルバス１１２を介して要求されたデータを送信するとともに、ローカルバス１１２を介して何らかのデータを受信すると、通信コントローラ１５４へ出力する。
　通信コントローラ１５４は、予め格納されたプログラムまたはロジックを実行することで、ローカルバス１１２上でのデータの送受信を制御する。通信コントローラ１５４は、所定のソフトウェアを実行するように構成されたプロセッサ、あるいは、所定のロジックが組み込まれた処理回路などを用いて実装することができる。
　機能モジュール１５６は、各機能ユニット１５０が提供する各種機能、例えば、フィールドからの各種情報（入力データ）の収集や、フィールドにある制御対象（機械や設備）への制御指令の出力などを行う。
　機能ユニット１５０においては、基本的には、機能モジュール１５６が各機能ユニット１５０に固有の処理の実行または固有の機能の提供を担当し、バス通信回路１５２および通信コントローラ１５４がローカルバス１１２を介したデータ伝送を担当する。
　通信カプラユニット２００は、ローカルバス２１２を介した機能ユニット２５０との間のデータ伝送を担当するとともに、フィールドネットワーク１１４を介したＣＰＵユニット１００との間のデータ伝送を担当する。より具体的には、通信カプラユニット２００は、コントローラ２０１と、ネットワークインターフェイス２１０と、バス通信回路２０８とを含む。
　コントローラ２０１は、主として、ネットワークインターフェイス２１０およびバス通信回路２０８を制御する。典型例とし、コントローラ２０１は、プロセッサ２０２と、メインメモリ２０４と、ストレージ２０６とを含む。プロセッサ２０２は、ストレージ２０６に格納されているシステムプログラムなどをメインメモリ２０４に展開して実行することで、通信カプラユニット２００において必要な処理および機能を提供する。なお、コントローラ２０１の少なくとも一部をハードワイヤードな回路で実装してもよい。
　ネットワークインターフェイス２１０は、フィールドネットワーク１１４を介したデータ伝送を担当する。ネットワークインターフェイス２１０は、フィールドネットワーク１１４においてスレーブとして機能する点を除いて、基本的な構成は、ＣＰＵユニット１００のネットワークインターフェイス１１０と同様である。
　バス通信回路２０８は、ＣＰＵユニット１００のバス通信回路１０８と同様に、通信カプラユニット２００と各機能ユニット２５０との間のローカルバス２１２を介したデータ伝送を仲介する。
　機能ユニット２５０は、通信カプラユニット２００に接続される点を除いて、上述の機能ユニット１５０と実質的に同一である。機能ユニット２５０の各々は、バス通信回路２５２と、通信コントローラ２５４と、機能モジュール２５６とを含む。これらの機能の詳細については、機能ユニット１５０に関して説明したので、ここでは詳細な説明は繰返さない。
　＜Ｂ．ローカルバス上のデータ伝送＞
　次に、ＣＰＵユニット１００と各機能ユニット１５０との間のローカルバス１１２を介したデータ伝送について説明する。なお、通信カプラユニット２００と各機能ユニット２５０との間のローカルバス２１２を介したデータ伝送についても同様である。
　図２は、本実施の形態に従うＰＬＣ１のローカルバス上でのデータ伝送を説明するための模式図である。図２には、所定周期毎に繰返し実行されるＩＯリフレッシュに加えて、任意のデータがメッセージ通信される例を示す。
　具体的には、図２（Ａ）に示すように、ローカルバス１１２（伝送路）を介して、所定のシステム周期Ｔｓ毎にＩＯリフレッシュを行うための通信フレームＦＬが送出される。典型的には、ＩＯリフレッシュを行うための通信フレームＦＬは、ＣＰＵユニット１００から送出されて、隣接する機能ユニット１５０に対して順次転送される。各機能ユニット１５０にて収集される入力データ、および、各機能ユニット１５０に対する指令を含む出力データを、互いに異なる通信フレームＦＬを用いて伝送してもよいし、同一の通信フレームＦＬで伝送するようにしてもよい。
　このような所定周期毎に繰返し伝送されるＩＯリフレッシュを行うための通信フレームＦＬが転送されていない期間にて、任意のメッセージ通信でデータを送信することもできる。このメッセージフレームＭＳＧＦＬについては、ＣＰＵユニット１００から特定の機能ユニット１５０に伝送される場合、もしくは、その逆方向に転送される場合、または、任意の機能ユニット１５０の間で伝送される場合などがある。
　但し、通信フレームＦＬとメッセージフレームＭＳＧＦＬとは同時に送出することができないので、メッセージフレームＭＳＧＦＬの送信要求などが発行されたとしても、ＩＯリフレッシュ中であれば、指定されたメッセージフレームＭＳＧＦＬの生成および送出は遅れることになる。
　例えば、図２（Ｂ）に示すように、ＩＯリフレッシュを行うための通信フレームＦＬの伝送中に、メッセージ送信要求が与えられたとする。この場合、通信フレームＦＬの伝送完了後に、メッセージフレームＭＳＧＦＬが生成および送出されることになる。図２（Ｂ）に示す例では、メッセージフレームＭＳＧＦＬは、メッセージ送信要求が与えられてから遅延時間Ｄ１後に送出が開始される。
　また、図２（Ｃ）に示すように、ＩＯリフレッシュを行うための通信フレームＦＬの伝送中直前に、メッセージ送信要求が与えられたとする。この場合、通信フレームＦＬの伝送期間が迫っているので、メッセージフレームＭＳＧＦＬの生成および送出は妨げられ、後続の通信フレームＦＬの伝送完了後に、メッセージフレームＭＳＧＦＬが生成および送出されることになる。図２（Ｃ）に示す例では、メッセージフレームＭＳＧＦＬは、メッセージ送信要求が与えられてから遅延時間Ｄ２後に送出が開始される。
　このように、ＩＯリフレッシュを行うための通信フレームＦＬが周期的に伝送されているローカルバスにおいては、メッセージ送信要求が与えられてから、実際に通信フレームＦＬが送出されるまでには、ある程度の伝送遅延が発生することになる。
　なお、説明の便宜上、図２（Ｂ）および（Ｃ）には、ＩＯリフレッシュ以外を考慮していないが、多数のメッセージ送信要求が先に発行されているような場合には、先になされている送信要求の数などに応じて、メッセージフレームの送信遅延が発生する。
　＜Ｃ．関連技術に従う初期化処理の一例＞
　次に、ローカルバス上をメッセージ通信される通信フレームを用いた、関連技術に従う初期化処理の一例について説明する。
　（ｃ１：初期化処理）
　図３は、本実施の形態に従うＰＬＣ１における関連技術に従う初期化処理の一例を示す模式図である。図３に示す初期化処理は、マスターとして機能するＣＰＵユニット１００からスレーブとして機能する機能ユニット１５０に対して、ローカルバス１１２を介したデータ伝送を同期するためのスタートタイムを指示する例を示す。このスタートタイムは、同期通信を確立するための指示に相当し、互いに同期したクロックが示すタイミングを含む。
　図３（Ａ）を参照して、マスターとして機能するＣＰＵユニット１００と、ローカルバス１１２を介してＣＰＵユニット１００に接続されるそれぞれの機能ユニット１５０－１～１５０－３との各々は、互いに同期したクロックを有している。より具体的には、ＣＰＵユニット１００のバス通信回路１０８は、ローカルバス１１２上でのデータ伝送の基準となるマスタークロック１０９を有しており、各機能ユニット１５０のバス通信回路１５２は、マスタークロック１０９と同期するオーディナリークロック１５３を有している。
　各機能ユニット１５０の通信コントローラ１５４は、バス通信回路１５２のオーディナリークロック１５３が示すタイミングを基準としてデータの送受信を管理する。このような互いに同期したクロックを用いたデータ送受信のタイミング管理によって、ローカルバス１１２上で衝突のないデータ伝送を実現できる。
　図３（Ａ）には、機能ユニット１５０－１，１５０－２についてのみＣＰＵユニット１００との間で同期通信が確立されている状態を示す。図３（Ｂ）には、図３（Ａ）に示す状態において、機能ユニット１５０－３についても新たに同期通信を確立させる初期化処理を示す。
　具体的には、機能ユニット１５０－３のオーディナリークロック１５３がＣＰＵユニット１００のマスタークロック１０９と同期している状態において、ＣＰＵユニット１００から対象の機能ユニット１５０－３に対して、同期通信を開始すべきタイミング（スタートタイム）を通知する。機能ユニット１５０－３は、オーディナリークロック１５３が通知されたスタートタイムを示すと、データの送信または受信を開始する。
　但し、ＣＰＵユニット１００から通知するスタートタイムは、未来の時刻でなければならず、過去の時刻が指定されると無効なものとして処理されることになる。このようなスタートタイムの通知は、以下のいずれかに示すような手順に従って、メッセージ通信にて送信される。
　（ｃ２：第１の初期化手順）
　第１の初期化手順として、スレーブとして機能する機能ユニット１５０のバス通信回路１５２のレジスタにスタートタイムを書込む方法を説明する。バス通信回路１５２は、図示しないレジスタを有しており、自己のオーディナリークロック１５３のクロック値がこのレジスタに書込まれたスタートタイムに到達すると、通信コントローラ１５４に対して割込み指令を発行して、同期を確立する。
　図４は、ＣＰＵユニット１００と機能ユニット１５０との間の第１の初期化手順を示す模式図である。図４を参照して、先に、ＣＰＵユニット１００の基本的なソフトウェア構造について説明する。
　ＣＰＵユニット１００においては、スケジューラ１２０と、複数のタスク（ＩＯリフレッシュタスク１３０およびシステムサービスタスク１４０）と、バスドライバ１１３と、フィールドネットワークドライバ１１５とを含む。これらのコンポーネントは、ＣＰＵユニット１００のプロセッサ１０２がシステムプログラムおよびユーザプログラムを実行することで実現される。
　スケジューラ１２０は、予め登録された複数のタスクについて、各タスクに設定される優先度などに基づいて、実行周期および実行タイミングを制御する。これらのタスクのうち、ＩＯリフレッシュタスク１３０については、最高の優先度が設定されており、所定のシステム周期毎にＩＯリフレッシュを行うための通信フレーム（図２など参照）などを送出するための処理を実行する。一方、システムサービスタスク１４０については、最低の優先度が設定されており、ＩＯリフレッシュタスク１３０などの他のタスクが実行されていない期間に適宜実行される。
　ＩＯリフレッシュタスク１３０は、ローカルバス１１２（伝送路）を介して所定周期（システム周期Ｔｓ）毎に通信フレームを送出する機能の少なくとも一部を提供するものであり、バスドライバ１１３に要求を与えることで、ローカルバス１１２上にＩＯリフレッシュを行うための通信フレームを伝送させる。併せて、ＩＯリフレッシュタスク１３０は、フィールドネットワークドライバ１１５に指令を与えることで、フィールドネットワーク１１４上にＩＯリフレッシュを行うための通信フレームまたはパケットを伝送させる。
　システムサービスタスク１４０は、メッセージルーチングタスク１４２と、スレーブ状態管理タスク１４４と、イベント通信処理タスク１４６とを含む。メッセージルーチングタスク１４２は、ローカルバス１１２上またはフィールドネットワーク１１４上のメッセージフレームを解釈し、そのメッセージフレームを伝送する際の経路を決定する。スレーブ状態管理タスク１４４は、ローカルバス１１２を介して接続されているスレーブ（機能ユニット１５０）の状態を管理する。
　イベント通信処理タスク１４６は、ＩＯリフレッシュを行うための通信フレームが伝送されていない期間において、任意のイベント要求に応答して、別の通信フレームを送出する機能の少なくとも一部を提供する、具体的には、イベント通信処理タスク１４６は、何らかのイベント要求に応答してメッセージフレームを送信する処理を実行する。イベント通信処理タスク１４６は、送信要求を順次登録するキュー１４８を管理している。
　以下の説明においては、キューへの何らかのデータの登録（入力）をキューイング（queuing）とも称し、キューからのデータの削除（出力）をデキューイング（dequeuing）とも称す。
　まず、ＣＰＵユニット１００が起動すると、あるいは、ローカルバス１１２上に新たな機能ユニット１５０が追加されると、スレーブ状態管理タスク１４４は、クロック設定処理を実行する。より具体的には、スレーブ状態管理タスク１４４は、機能ユニット１５０の各々に対して、オーディナリークロック１５３をマスタークロック１０９と同期させるように指示を与える。
　クロックが同期された状態において、第１の手順として、スレーブ状態管理タスク１４４は、バス通信回路１０８のマスタークロック１０９からクロック値を読出してスレーブに設定すべきスタートタイムを算出する。そして、第２の手順として、スレーブ状態管理タスク１４４は、特定のスレーブ（機能ユニット１５０）に対して、算出したスタートタイムをレジスタに書込むためのレジスタ書込みフレームの送信要求をイベント通信処理タスク１４６へ出力する。このレジスタ書込みフレームの送信要求は、キュー１４８に登録される。イベント通信処理タスク１４６は、キュー１４８に登録されている送信要求を順次処理する。キュー１４８に登録されている送信要求が順次処理されて、先に登録されたレジスタ書込みフレームの送信要求が処理できる状態になると、第３の手順として、イベント通信処理タスク１４６は、イベントフレーム送信要求をバスドライバ１１３へ出力する。第４の手順として、バスドライバ１１３は、イベントフレーム送信要求を受けてバス通信回路１０８の通信を起動する。すると、バス通信回路１０８からローカルバス１１２上にレジスタ書込みフレームが送出される。
　第５の手順として、機能ユニット１５０にてレジスタ書込みフレームが受信されると、第６の手順として、機能ユニット１５０のバス通信回路１５２は、受信したレジスタ書込みフレームに含まれるスタートタイムを内部のレジスタに書込む。そして、機能ユニット１５０のバス通信回路１５２は、オーディナリークロック１５３がレジスタに書込まれたスタートタイムに到達すると同期処理を開始する。
　以上のような第１～第６の手順によって、ＣＰＵユニット１００と機能ユニット１５０との間に新たに同期通信を確立させる初期化処理は完了する。
　（ｃ３：第２の初期化手順）
　次に、上述の第１の初期化手順とは異なる第２の初期化手順について説明する。第２の初期化手順として、ＣＰＵユニット１００から機能ユニット１５０にメッセージ通信されるメッセージフレームに応答して、通信コントローラ１５４がバス通信回路１５２のレジスタにスタートタイムを書込む方法について説明する。
　図５は、ＣＰＵユニット１００と機能ユニット１５０との間の第２の初期化手順を示す模式図である。図５を参照して、先に、機能ユニット１５０の基本的なソフトウェア構造について説明する。
　機能ユニット１５０においては、メッセージルーチングタスク１６２と、状態管理タスク１６４と、バスドライバ１６６とが実装される。これらのコンポーネントは、通信コントローラ１５４によって提供される。
　メッセージルーチングタスク１６２は、ローカルバス１１２上のメッセージフレームを解釈し、そのメッセージフレームを伝送する際の経路を決定する。状態管理タスク１６４は、ローカルバス１１２を介してＣＰＵユニット１００に接続するための状態を管理する。バスドライバ１１３は、バス通信回路１５２を介してローカルバス１１２上で遣り取りされるデータの送受信管理を行う。
　まず、ＣＰＵユニット１００が起動すると、あるいは、ローカルバス１１２上に新たな機能ユニット１５０が追加されると、スレーブ状態管理タスク１４４は、クロック設定処理を実行する。より具体的には、スレーブ状態管理タスク１４４は、機能ユニット１５０の各々に対して、オーディナリークロック１５３をマスタークロック１０９と同期させるように指示を与える。
　クロックが同期された状態において、第１の手順として、スレーブ状態管理タスク１４４は、バス通信回路１０８のマスタークロック１０９からクロック値を読出してスレーブに設定すべきスタートタイムを算出する。そして、第２の手順として、スレーブ状態管理タスク１４４は、特定のスレーブ（機能ユニット１５０）に対して、算出したスタートタイムを含む通信フレームについてのメッセージルーチング要求をメッセージルーチングタスク１４２へ出力する。第３の手順として、メッセージルーチングタスク１４２は、スレーブ状態管理タスク１４４からのメッセージルーチング要求を解釈して送信先のスレーブを特定するとともに、当該スレーブへのメッセージフレームを送信するためのメッセージフレーム送信要求をイベント通信処理タスク１４６へ出力する。このメッセージフレーム送信要求は、キュー１４８に登録される。イベント通信処理タスク１４６は、キュー１４８に登録されている送信要求を順次処理する。キュー１４８に登録されている送信要求が順次処理されて、先に登録されたメッセージフレーム送信要求が処理できる状態になると、第４の手順として、イベント通信処理タスク１４６は、イベントフレーム送信要求をバスドライバ１１３へ出力する。第５の手順として、バスドライバ１１３は、イベントフレーム送信要求を受けてバス通信回路１０８の通信を起動する。すると、バス通信回路１０８からローカルバス１１２上にメッセージフレームが送出される。
　第６の手順として、機能ユニット１５０にてメッセージフレームが受信されると、第７の手順として、機能ユニット１５０のバス通信回路１５２は、バスドライバ１６６に対して、メッセージフレームの受信に伴う割込みを発行する。第８の手順として、バスドライバ１６６は、受信したメッセージフレームをメッセージルーチングタスク１６２へ出力して、受信したメッセージフレームに対するルーチングを要求する。第９の手順として、メッセージルーチングタスク１６２は、バスドライバ１６６からのメッセージフレームの内容がバス通信回路１５２に対するスタートタイムの設定要求であると解釈し、クロック設定要求を状態管理タスク１６４へ出力する。
　第１０の手順として、状態管理タスク１６４は、クロック設定要求に応答して、指定されたスタートタイムをバス通信回路１５２のレジスタに書込む。そして、機能ユニット１５０のバス通信回路１５２は、オーディナリークロック１５３がレジスタに書込まれたスタートタイムに到達すると同期処理を開始する。
　以上のような第１～第１０の手順によって、ＣＰＵユニット１００と機能ユニット１５０との間に新たに同期通信を確立させる初期化処理は完了する。
　（ｃ４：課題）
　次に、図４および図５に示す初期化手順に生じ得る課題について説明する。図４および図５を参照して説明したように、ＣＰＵユニット１００からメッセージ通信される通信フレーム（レジスタ書込みフレームまたはメッセージフレーム）は、最低の優先度が設定されているシステムサービスタスク１４０において生成される送信要求に応じて送信される。
　また、送信要求は他のタスクからも生成されることもあるので、イベント通信処理タスク１４６のキュー１４８には、レジスタ書込みフレーム送信要求またはメッセージフレーム送信要求以外のメッセージ送信要求が既に登録されている場合もある。そのため、レジスタ書込みフレーム送信要求またはメッセージフレーム送信要求を発行した後、当該フレーム送信要求がいつ処理されるのかは、先にキュー１４８に登録されている送信要求の状態に依存することになる。
　図６は、関連技術に従う初期化処理における一つの課題を説明するための模式図である。図６を参照して、フレーム送信要求は、イベント通信処理タスク１４６のキュー１４８にＦＩＦＯ（First　In　First　Out）で登録および処理（キューおよびデキュー）されることになる。図６には、上述したような初期化処理を実行するためのレジスタ書込みフレーム送信要求（またはメッセージフレーム送信要求）がキュー１４８に登録された時点で、既に２つの送信要求がキュー１４８に登録されている状態を示す。このような状態において、先に登録されている２つの送信要求がいつ処理（デキュー）されるのかについては正確に見積もることができない。
　上述したように、ＣＰＵユニット１００から通知するスタートタイムは未来の時刻でなければならない。これは、機能ユニット１５０に到着した時点において、指定されたスタートタイムが未来の時刻である必要がある。一方で、上述したように、スタートタイムを含む通信フレームがいつのタイミングで送信されるのかについては不確定な要素が存在する。
　そこで、キュー１４８における通信フレームの送信に要する最悪の時間を見積もっておき、その見積もった時間に応じて、指定するスタートタイムに十分なマージンを持たせることにより、機能ユニット１５０に到着した時点において、当該スタートタイムが過去の時刻にならないように設計する必要がある。
　なお、通信カプラユニット２００のローカルバス２１２などにおいては、コントローラ２０１のリソースを多く使用できるため、スタートタイムに設定するマージンの見積もりおよびその正確性の担保が比較的容易である。一方、ＣＰＵユニット１００においては、複数のタスクが実行されるため、スタートタイムに設定すべきマージンが大きく変化し、その見積もりが容易ではない。さらに、図６に示すような、先行の送信要求の処理完了を待たざるを得ない場合がある。
　以上のような理由によって、指示するスタートタイムに設定されるマージンを過剰に大きくして初期化処理を実行したり、最悪の場合、初期化処理が失敗し、初期化処理をやり直す必要が生じたりする。つまり、上述したような関連技術に従う初期化処理では、処理を早期かつ確実に完了させることは容易ではなかった。
　＜Ｄ．本実施の形態に従う初期化処理に係る機能構成＞
　次に、本実施の形態に従う初期化処理に係る機能構成について説明する。図７は、本実施の形態に従うＰＬＣ１における機能構成を示す模式図である。図７を参照して、本実施の形態に従うＰＬＣ１のＣＰＵユニット１００は、図４および図５に示す構成に比較して、高優先イベントキュー管理タスク１３６が追加されるとともに、イベント通信処理タスク１４６においては、通常イベントのキュー１４８に加えて、高優先イベントのキュー１４９が用意されている。イベント通信処理タスク１４６は、通常イベント要求を順次格納するキュー１４８と、高優先イベント要求を順次格納するキュー１４９とを含む。
　システムサービスタスク１４０としては、図７に示すメッセージルーチングタスク１４２およびスレーブ状態管理タスク１４４だけではなく、他のシステムサービスタスク（システムサービス群１４１）が存在する。システムサービス群１４１の一部または全部はイベント処理クライエント１４５を生じさせ、イベント処理クライエント１４５は処理に応じてイベント要求を発行する。これらのイベント要求は、イベント通信処理タスク１４６などに登録されることになる。
　イベント処理クライエント１４５は、処理に応じて通常イベント要求を発行し、スレーブ状態管理タスク１４４は、機能ユニット１５０との間の初期化処理の開始に係るイベント要求を発生し、このイベント要求は、通常イベント要求より優先度の高い高優先イベント要求に相当する。イベント処理クライエント１４５からの高優先イベント要求は、特定の機能ユニット１５０がローカルバス１１２（伝送路）を介してＣＰＵユニット１００との間で同期通信を確立するための指示を含むことになる。
　本明細書において、「イベント要求」とは、何らかの条件または周期の到来によって内部イベントが発行され、その発行された内部イベントによって生成された各種処理（メッセージ通信によるデータ送信を含む）に係る要求を意味する。「通常」および「高優先」は、相対的な優先度の優劣を示す用語であり、「高優先」イベント要求は、「通常」イベント要求より優先して処理されることを意味する。この「通常」および「高優先」の呼称は便宜上のものであり、この用語を限定的に解釈すべきではない。
　高優先イベントキュー管理タスク１３６は、スレーブ状態管理タスク１４４により発行される高優先イベント要求を優先的に処理するための優先度管理機能の少なくとも一部を提供する。具体的には、高優先イベントキュー管理タスク１３６は、高優先イベントのキュー１４９への送信要求の出力タイミングなどを制御するための高優先イベントキュー１３８を管理する。高優先イベントキュー１３８には、後述するように、スレーブ状態管理タスク１４４から高優先イベント要求が必要に応じて登録される。高優先イベントキュー管理タスク１３６とイベント通信処理タスク１４６との間の処理手順については後述する。
　＜Ｅ．本実施の形態に従う初期化処理における処理手順＞
　次に、本実施の形態に従う初期化処理における処理手順について説明する。
　図８は、本実施の形態に従う初期化処理におけるモジュール間の遣り取りを説明する模式図である。図９は、本実施の形態に従う初期化処理における処理手順を示すシーケンス図である。なお、図８に示すカッコ内の番号と、図９に示すカッコ内の番号とは対応するものとなっている。
　まず、ＣＰＵユニット１００が起動すると、あるいは、ローカルバス１１２上に新たな機能ユニット１５０が追加されると、スレーブ状態管理タスク１４４は、クロック設定処理を実行する。より具体的には、スレーブ状態管理タスク１４４は、機能ユニット１５０の各々に対して、オーディナリークロック１５３をマスタークロック１０９と同期させるように指示を与える。図９に示す各ステップは、クロックが同期された状態において実行される。
　図８および図９を参照して、まず、スレーブ状態管理タスク１４４は、初期化処理要求を受けると（ステップＳ１）、高優先イベントキュー管理タスク１３６に高優先イベント要求を発行する（ステップＳ２）。すると、高優先イベントキュー管理タスク１３６では、発行された高優先イベント要求を高優先イベントキュー１３８にキューイングする（ステップＳ３）。つまり、高優先イベントキュー１３８に高優先イベント要求が登録される。そして、高優先イベントキュー管理タスク１３６は、高優先イベント要求が登録されていることをイベント通信処理タスク１４６（通常イベントのキュー１４８および高優先イベントのキュー１４９）へ通知する（ステップＳ４）。
　イベント通信処理タスク１４６では、通常イベントのキュー１４８に登録されている通常イベント要求のうち送信処理中のものがあれば、その送信処理中の通常イベント要求の処理が継続される（ステップＳ５）。より具体的には、イベント通信処理タスク１４６は、キュー１４８に登録されている通常イベント要求のうち送信処理中のものをバスドライバ１１３へ出力する（ステップＳ５１）。バスドライバ１１３は、通常イベント要求に従ってバス通信回路１０８の通信を起動する（ステップＳ５２）。すると、バス通信回路１０８からローカルバス１１２上に、当該通常イベント要求に応じた通信フレームなどが送出される。登録されている通常イベント要求についての処理が完了すると、イベント通信処理タスク１４６は、キュー１４８に登録されている通常イベント要求を削除（デキューイング）する（ステップＳ５３）。
　イベント通信処理タスク１４６は、高優先イベント要求が登録されていることの通知を受けたときに送信処理中の通常イベント要求が存在すれば、その送信処理中の通常イベント要求の処理が完了すると、高優先処理可能通知を高優先イベントキュー管理タスク１３６へ通知する（ステップＳ６）。このとき、イベント通信処理タスク１４６のキュー１４８に登録されているものの、未だ処理の対象になっていないものは、処理が一旦中段される。
　また、高優先イベントのキュー１４９に何らかの高優先イベント要求が先に登録されている場合には、その先に登録されている高優先イベント要求の処理が完了した後に、高優先処理可能通知が高優先イベントキュー管理タスク１３６へ通知される。つまり、高優先処理可能通知は、後述するような、高優先イベント要求を優先的に処理できる状態であることを示す通知である。
　その後、スケジューラ１２０は、高優先イベントキュー管理タスク１３６に対して、処理の開始を指示するトリガを周期的に発行する（ステップＳ７）。スケジューラ１２０は、ＩＯリフレッシュタスク１３０によるＩＯリフレッシュの実行を妨げないタイミングで、ステップＳ７のトリガを発行する。
　高優先イベントキュー管理タスク１３６は、スケジューラ１２０からのトリガを受信したときに、高優先イベントに係るスレッド（優先度は通常より高く設定されている）が起動しており、かつ、イベント通信処理タスク１４６から高優先処理可能通知を受信していれば、高優先イベント開始をスレーブ状態管理タスク１４４へ通知する（ステップＳ８）。高優先イベントに係るスレッドは、現実的なリアルタイム性を保証できる程度に高い優先度が設定されているが、ＩＯリフレッシュの優先度よりは低くなっている。
　上述のステップＳ４～Ｓ８に示すように、高優先イベント要求の発行要求（ステップＳ２に示す高優先イベント要求）を受けると、現在処理中の通常イベント要求に対応する通信フレームの送出処理の完了を待って、高優先イベント要求の発行が許可（高優先処理可能通知が発行）される。このとき、現在処理中の通常イベント要求に引き続く後続の通常イベント要求に対する処理は、高優先イベント要求に対する処理が完了するまで中断される。
　スレーブ状態管理タスク１４４へ通知される高優先イベント開始は、スレーブ状態管理タスク１４４からの高優先イベント要求（ステップＳ２）に対する肯定応答（コールバック）に相当し、高優先イベント開始によって、初期化処理に必要なタイミング（スタートタイム）などを決定する処理が開始される。より具体的には、スレーブ状態管理タスク１４４は、初期化処理の対象となる機能ユニット１５０に対して設定すべきスタートタイムをスケジューラ１２０に問い合わせる（ステップＳ９）。この問い合わせに応答して、スケジューラ１２０は、スタートタイムを算出してスレーブ状態管理タスク１４４へ応答する（ステップＳ１０）。このスタートタイムは、バス通信回路１０８のマスタークロック１０９と同期する、各機能ユニット１５０のオーディナリークロック１５３が管理する値が用いられる。
　一例として、スケジューラ１２０が応答するスタートタイムとして、ＩＯリフレッシュの送出周期（システム周期）に関連付けられた値が用いられてもよい。具体的には、ＩＯリフレッシュの通信フレームの送信前に設定されるＴｉｃｋタイムが用いられてもよい。図１０は、本実施の形態に従うＰＬＣ１のスケジューラ１２０が応答するスタートタイムを説明するための模式図である。図１０を参照して、所定のシステム周期Ｔｓ毎にＩＯリフレッシュを行うための通信フレームが伝送される。各機能ユニット１５０は、予め定められた通信手順に従って、１または複数の通信フレームを用いて、予め収集していた入力データをマスターとして機能するＣＰＵユニット１００へ伝送するとともに、ＣＰＵユニット１００から送信される出力データを取得する。
　Ｔｉｃｋタイムは、各機能ユニット１５０にＩＯリフレッシュを行うための通信フレームが到着する所定時間ΔＴｔだけ前に設定され、Ｔｉｃｋタイムにおいて、各機能ユニット１５０は入力データの収集を開始する。したがって、いずれかのＴｉｃｋタイムがスタートタイムとして指定されていれば、指定されたＴｉｃｋタイムの直後に到着する通信フレームに対する入力データの書込みなどを行うことができる。つまり、ＣＰＵユニット１００との間で同期通信を確立できる。
　本実施の形態に従うＰＬＣ１においては、現時点から２つ先（あるいは、それより先）のＴｉｃｋタイムをスタートタイムとして設定するようにしてもよい。上述したように、スレーブ状態管理タスク１４４からスケジューラ１２０に対してスタートタイムの問い合わせ（ステップＳ９）がなされたタイミングにおいて、ＩＯリフレッシュ以外の中では最も高い優先度でスタートタイムを通知できる状態になっている。そのため、少なくとも２つ先のＴｉｃｋタイムまでの間に、スタートタイムを通知することが保証されるからである。
　例えば、図１０（Ａ）に示すように、先行のＩＯリフレッシュ直後であって、後続のＩＯリフレッシュのＴｉｃｋタイムが到来する前に、スタートタイムの問い合わせを受けると、２つ先のＩＯリフレッシュにＴｉｃｋタイムであるＴｉｃｋ０２がスタートタイムとして設定される。
　あるいは、図１０（Ｂ）に示すように、あるＩＯリフレッシュの直前に、スタートタイムの問い合わせを受けると、２つ先のＩＯリフレッシュにＴｉｃｋタイムであるＴｉｃｋ０３がスタートタイムとして設定される。
　再度、図８および図９を参照して、スレーブ状態管理タスク１４４は、必要に応じてメッセージルーチングタスク１４２に、メッセージルーチング用ヘッダの作成を要求する（ステップＳ１１）。具体的には、上述の図５に示す第２の初期化手順のように、ＣＰＵユニット１００から機能ユニット１５０に対してメッセージフレームを送信する方法で初期化手順を実現する場合には、スレーブ状態管理タスク１４４は、メッセージフレームを初期化対象の機能ユニット１５０へ送信するための、メッセージルーチング用ヘッダの作成を要求する。メッセージルーチングタスク１４２は、初期化対象の機能ユニット１５０のローカルバス１１２，２１２および／またはフィールドネットワーク１１４上の位置に応じて、必要なヘッダを作成して、スレーブ状態管理タスク１４４へ応答する（ステップＳ１２）。上述したように、これらのステップＳ１１およびＳ１２の処理はオプションの処理である。
　そして、スレーブ状態管理タスク１４４は、高優先イベント要求として送信すべきデータをイベント通信処理タスク１４６へ出力する（ステップＳ１３）。イベント通信処理タスク１４６では、スレーブ状態管理タスク１４４からのデータを、高優先イベントのキュー１４９にキューイングする（ステップＳ１４）。つまり、高優先イベント要求として送信すべきデータがイベント通信処理タスク１４６のキュー１４９に登録される。高優先イベント要求として送信すべきデータは、ステップＳ１０において取得されるスタートタイムを含む。なお、上述の第１の初期化手順と同様の初期化手順が採用される場合には、スタートタイムに加えて、レジスタ書込みフレームの生成に必要な情報が含まれる。一方、上述の第２の初期化手順と同様の初期化処理が採用される場合には、スタートタイムに加えて、メッセージフレームの生成に必要な情報が含まれる。
　必要なデータがキュー１４９に登録された後、高優先イベントキュー管理タスク１３６は、イベント通信処理タスク１４６に対してイベント通信の開始を通知する（ステップＳ１５）。イベント通信の開始によって、イベント通信処理タスク１４６では、必要な電文（通信フレームまたはメッセージ）の生成、および、バス通信回路１０８に対する通信の起動が開始される。すなわち、イベント通信処理タスク１４６は、高優先イベントキュー管理タスク１３６からのイベント通信の開始の通知を受けて、イベントフレーム送信要求をバスドライバ１１３へ出力する（ステップＳ１６）。バスドライバ１１３は、イベントフレーム送信要求を受けてバス通信回路１０８の通信を起動する（ステップＳ１７）。すると、バス通信回路１０８からローカルバス１１２上に指定された通信フレーム（レジスタ書込みフレームまたはメッセージフレーム）が送出される（ステップＳ１８）。
　なお、高優先イベント要求および通常イベント要求に応じた通信フレームは、ＩＯリフレッシュの通信フレームが伝送されていない期間において送出される。
　イベント通信処理タスク１４６からバスドライバ１１３へのイベントフレーム送信要求の出力の後、高優先イベントキュー管理タスク１３６は、高優先イベントキュー１３８から高優先イベント要求をデキューイングする（ステップＳ１９）。つまり、高優先イベント要求が高優先イベントキュー１３８から削除される。併せて、イベント通信処理タスク１４６は、高優先イベントのキュー１４９から処理対象のデータをデキューイングする（ステップＳ２０）。つまり、初期化処理に必要なデータが高優先イベントのキュー１４９から削除される。
　その後、第１の初期化手順と同様の初期化手順が採用される場合には、機能ユニット１５０において、図４を参照して説明したのと同様の処理が実行される（図８の（１１）および（１２）参照）。あるいは、第２の初期化手順と同様の初期化手順が採用される場合には、機能ユニット１５０において、図５を参照して説明したのと同様の処理が実行される（図８の（１１’）～（１５’）参照）。
　以上のような処理手順によって、ＣＰＵユニット１００と機能ユニット１５０との間に新たに同期通信を確立させる初期化処理は完了する。
　ここで、高優先イベントキュー管理タスク１３６およびイベント通信処理タスク１４６における処理（図９に示すステップＳ４，Ｓ５，Ｓ１４，Ｓ１６など参照）についてより詳細に説明する。図１１は、本実施の形態に従うＰＬＣ１のイベント通信処理タスク１４６の通常イベントのキュー１４８および高優先イベントのキュー１４９における処理を説明するための模式図である。
　図１１（Ａ）を参照して、例えば、通常イベント要求ＡおよびＢがキュー１４８に登録されており、通常イベント要求Ａが送信処理中であるときに、高優先イベントキュー管理タスク１３６が高優先イベント要求の登録通知を行った場合を想定する。このとき、高優先イベントキュー管理タスク１３６は、スレーブ状態管理タスク１４４から高優先イベント要求の発行要求（図８のステップＳ２に示す高優先イベント要求）を受けると、イベント通信処理タスク１４６において現在処理中の通常イベント要求に対応する通信フレームの送出処理の完了を待って、スレーブ状態管理タスク１４４に対して高優先イベント要求の発行を許可する（図８のステップＳ６に示す高優先処理可能通知の発行）。
　具体的には、高優先イベントキュー管理タスク１３６は、スレーブ状態管理タスク１４４から高優先イベント要求の発行要求（図８のステップＳ２に示す高優先イベント要求）を受けると、その高優先イベント要求の発行要求をイベント通信処理タスク１４６へ通知する。すると、イベント通信処理タスク１４６は、通常イベント要求Ａに対して実行されている送信処理を継続する。そして、図１１（Ｂ）に示すように、先に実行されていた通常イベント要求Ａに対する送信処理が完了すると、通常イベント要求Ａをキュー１４８から削除する一方で、次にキュー１４８に登録されていた通常イベント要求Ｂに対する送信処理の実行は一旦停止される。そして、イベント通信処理タスク１４６は、高優先イベント要求の発行要求を通知された後、現在処理中の通常イベント要求についての処理が完了すると、高優先イベント要求が処理可能である旨である高優先処理可能通知を高優先イベントキュー管理タスク１３６へ通知する。
　すると、図１１（Ｃ）に示すように、高優先イベント要求に対応するデータがキュー１４９に登録される。そして、イベント通信の開始の通知を受けて、キュー１４９に登録されているデータがバスドライバ１１３へ出力される。
　なお、図１１（Ｂ）に示すように、キュー１４８に登録されている通常イベント要求に対する処理の実行が一旦停止されている状態であっても、新たな通常イベント要求は受け付けるようになっている。つまり、新たに通常イベント要求が発行されると、その通常イベント要求はキュー１４８に追加して登録されることになる。これらの通常イベント要求については、高優先イベント要求に対する処理が完了した後、順次実行されることになる。
　このように、イベント通信処理タスク１４６は、現在処理中の通常イベント要求に引き続く後続の通常イベント要求に対する処理を、高優先イベント要求に対する処理の完了まで中断する。すなわち、キュー１４８に先に登録されている通常イベント要求のうち処理中のものだけが処理された後に、その後の通常イベント要求の処理は中断された状態で、高優先処理可能が通知される。このような処理を採用することで、要求されている高優先イベント要求に対応する通信フレームを最優先で送信できるような状態になった上で、キュー１４９には対応する必要なデータが登録される。
　図１１に示すように、通常イベント要求と高優先イベント要求との調停処理を採用することで、例えば、初期化処理などに用いられる通信フレームの到着時刻を保証することができる。
　図７および図１１においては、通常イベントのキュー１４８および高優先イベントのキュー１４９がそれぞれ独立に配置される例を示すが、必ずしも独立に２つ配置する必要はなく、図１１に示すような処理方法に従って、通常イベント要求に比較して、高優先イベント要求を優先的に処理する構成であれば、どのような実装形態であってもよい。
　＜Ｆ．変形例＞
　上述の実施の形態においては、典型例として、ＣＰＵユニット１００とローカルバス１１２を介して接続される機能ユニット１５０との間の初期化処理に適用した場合について例示したが、これに限らず、本実施の形態に従う通信手順は任意の処理に適用可能である。同様の初期化処理については、例えば、通信カプラユニット２００とローカルバス２１２を介して接続される機能ユニット２５０との間の初期化処理に適用してもよいし、ＣＰＵユニット１００とフィールドネットワーク１１４を介して接続される任意のデバイス（通信カプラユニット２００を含み得る）との間の初期化処理に適用してもよい。
　さらに、ＣＰＵユニット１００と特定の１または複数の機能ユニット１５０との間、通信カプラユニット２００と特定の１または複数の機能ユニット２５０との間、複数の機能ユニット１５０の間、あるいは、複数の機能ユニット２５０の間で、メッセージ通信によってデータを遣り取りすることで実現される、任意の処理手続きに適用可能である。
　＜Ｇ．利点＞
　上述したような関連技術に従う初期化処理においては、メッセージ通信は、低優先度のスケジューリングに従ってタイミングが決定されるので、他のメッセージ通信を要求するイベントが発生した場合には、いずれのタイミングで要求した通信フレームを送出できるのかを予測することが難しい。
　これに対して、本実施の形態に従うＰＬＣ１の初期化処理においては、初期化処理に係る通信フレームの送出を高優先イベント要求とすることができ、他のイベント処理クライエントが発生する通常イベント要求よりも優先的に処理が可能になっている。
　また、先に発行された通常イベント要求が処理中である場合に、高優先イベント要求を発行すると、先に処理中の通常イベント要求の処理完了を待つ必要があるが、本実施の形態においては、先に処理中の通常イベント要求の処理が完了した後に、高優先イベント要求自体を発行するように制御する。このような制御方法を採用することで、通常イベント要求と高優先イベント要求との競合、つまり、通常イベント要求が完了しなければ、高優先イベント要求を処理できないといった事態を回避して、優先度に応じたイベント要求の処理を確実に行うことができる。
　上述したような関連技術に従う制御方法を採用すると、各イベント要求についての処理時間が保障されないため、時間制約を守るためには、余裕を持った最悪到達時間を想定して通信処理を実行する必要があったが、本実施の形態によれば、高優先イベントに係る通信処理については、到達時間を保証できるので、最悪到達時間などの想定は必要ない。
　また、上述したような関連技術に従う制御方法を採用すると、イベント要求の発行後、現実に通信フレームが送信先に到達するまでの最悪到達時間の想定が困難であり、安全サイドに最悪到達時間を想定すると、システム全体の処理遅延につながる可能性がある。これに対して、本実施の形態によれば、到達時間を保証できるので、必要な処理時間などの見積もりが容易になるとともに、その処理時間そのものを短縮化できるので、処理の起動時間などが短縮されて、ユーザビリティを向上させることもできる。
　今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明ではなく、請求の範囲によって示され、請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
　１　ＰＬＣ、１００　ＣＰＵユニット、１０２，２０２　プロセッサ、１０４，２０４　メインメモリ、１０６，２０６　ストレージ、１０８，１５２，２０８，２５２　バス通信回路、１０９　マスタークロック、１１０，２１０　ネットワークインターフェイス、１１２，２１２　ローカルバス、１１３，１６６　バスドライバ、１１４　フィールドネットワーク、１１５　フィールドネットワークドライバ、１２０　スケジューラ、１３０　リフレッシュタスク、１３６　高優先イベントキュー管理タスク、１３８　高優先イベントキュー、１４０　システムサービスタスク、１４１　システムサービス群、１４２，１６２　メッセージルーチングタスク、１４４　スレーブ状態管理タスク、１４５　イベント処理クライエント、１４６　イベント通信処理タスク、１４８，１４９　キュー、１５０，２５０　機能ユニット、１５３　オーディナリークロック、１５４，２５４　通信コントローラ、１５６，２５６　機能モジュール、１６４　状態管理タスク、２００　通信カプラユニット、２０１　コントローラ、ＦＬ　通信フレーム、ＭＳＧＦＬ　メッセージフレーム、Ｔｓ　システム周期。

Claims (8)

  1. 　制御装置を構成する演算装置であって、
    　伝送路を介して１または複数の機能ユニットとの間でデータを遣り取りするための通信インターフェイスと、
    　前記伝送路を介して所定周期毎に第１の通信フレームを送出する第１の伝送制御手段と、
    　前記第１の通信フレームが伝送されていない期間において、任意のイベント要求に応答して、第２の通信フレームを送出する第２の伝送制御手段と、
    　処理に応じて第１のイベント要求を発行する第１のイベント発行手段と、
    　前記第１のイベント要求より優先度の高い第２のイベント要求を発行する第２のイベント発行手段と、
    　前記第２のイベント発行手段により発行される前記第２のイベント要求を優先的に処理するための優先度管理手段とを備え、
    　前記優先度管理手段は、前記第２のイベント発行手段から前記第２のイベント要求の発行要求を受けると、前記第２の伝送制御手段において現在処理中の第１のイベント要求に対応する第２の通信フレームの送出処理の完了を待って、前記第２のイベント発行手段に対して前記第２のイベント要求の発行を許可し、
    　前記第２の伝送制御手段は、前記現在処理中の第１のイベント要求に引き続く後続の第１のイベント要求に対する処理を、前記第２のイベント要求に対する処理の完了まで中断する、演算装置。
  2. 　前記第２の伝送制御手段は、
    　　前記第１のイベント要求を順次格納する第１のキューと、
    　　前記第２のイベント要求を順次格納する第２のキューとを含む、請求項１に記載の演算装置。
  3. 　前記優先度管理手段は、前記第２のイベント要求の発行要求を受けると、当該発行要求を前記第２の伝送制御手段へ通知し、
    　前記第２の伝送制御手段は、前記第２のイベント要求の発行要求を通知された後、前記現在処理中の第１のイベント要求についての処理が完了すると、前記第２のイベント要求が処理可能である旨を前記優先度管理手段へ通知する、請求項２に記載の演算装置。
  4. 　前記第２のイベント要求は、特定の機能ユニットが前記伝送路を介して前記演算装置との間で同期通信を確立するための指示を含む、請求項１～３のいずれか１項に記載の演算装置。
  5. 　前記伝送路を介して接続される前記演算装置および前記１または複数の機能ユニットの各々は、互いに同期したクロックを有しており、
    　前記同期通信を確立するための指示は、前記互いに同期したクロックが示すタイミングを含む、請求項４に記載の演算装置。
  6. 　前記タイミングは、前記第１の通信フレームの送出周期に関連付けられた値に設定される、請求項５に記載の演算装置。
  7. 　制御装置であって、
    　演算装置と、
    　前記演算装置と伝送路を介してデータを遣り取り可能に接続された１または複数の機能ユニットとを備え、
    　前記演算装置は、
    　　前記伝送路を介して所定周期毎に第１の通信フレームを送出する第１の伝送制御手段と、
    　　前記第１の通信フレームが伝送されていない期間において、任意のイベント要求に応答して、第２の通信フレームを送出する第２の伝送制御手段と、
    　　処理に応じて第１のイベント要求を発行する第１のイベント発行手段と、
    　　前記第１のイベント要求より優先度の高い第２のイベント要求を発行する第２のイベント発行手段と、
    　　前記第２のイベント発行手段により発行される前記第２のイベント要求を優先的に処理するための優先度管理手段とを備え、
    　前記優先度管理手段は、前記第２のイベント発行手段から前記第２のイベント要求の発行要求を受けると、前記第２の伝送制御手段において現在処理中の第１のイベント要求に対応する第２の通信フレームの送出処理の完了を待って、前記第２のイベント発行手段に対して前記第２のイベント要求の発行を許可し、
    　前記第２の伝送制御手段は、前記現在処理中の第１のイベント要求に引き続く後続の第１のイベント要求に対する処理を、前記第２のイベント要求に対する処理の完了まで中断する、制御装置。
  8. 　演算装置と、前記演算装置と伝送路を介してデータを遣り取り可能に接続された１または複数の機能ユニットとを備えた制御装置における制御方法であって、
    　前記伝送路を介して所定周期毎に第１の通信フレームを送出するステップと、
    　処理に応じて第１のイベント要求を発行するステップと、
    　前記第１のイベント要求より優先度の高い第２のイベント要求を発行するステップと、
    　前記第１の通信フレームが伝送されていない期間において、前記第１のイベント要求または前記第２のイベント要求に応答して、第２の通信フレームを送出するステップと、
    　前記第２のイベント要求の発行要求を受けると、現在処理中の第１のイベント要求に対応する第２の通信フレームの送出処理の完了を待って、前記第２のイベント要求の発行を許可するステップと、
    　前記現在処理中の第１のイベント要求に引き続く後続の第１のイベント要求に対する処理を、前記第２のイベント要求に対する処理の完了まで中断するステップとを備える、制御方法。
PCT/JP2017/042373 2017-02-07 2017-11-27 演算装置、制御装置および制御方法 WO2018146909A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US16/478,473 US10785014B2 (en) 2017-02-07 2017-11-27 Computation device, control device and control method
EP17895678.5A EP3582038B1 (en) 2017-02-07 2017-11-27 Control device and control method
CN201780083623.1A CN110178097B (zh) 2017-02-07 2017-11-27 运算装置、控制装置以及控制方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2017020409A JP6428805B2 (ja) 2017-02-07 2017-02-07 演算装置、制御装置および制御方法
JP2017-020409 2017-02-07

Publications (1)

Publication Number Publication Date
WO2018146909A1 true WO2018146909A1 (ja) 2018-08-16

Family

ID=63107374

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/042373 WO2018146909A1 (ja) 2017-02-07 2017-11-27 演算装置、制御装置および制御方法

Country Status (5)

Country Link
US (1) US10785014B2 (ja)
EP (1) EP3582038B1 (ja)
JP (1) JP6428805B2 (ja)
CN (1) CN110178097B (ja)
WO (1) WO2018146909A1 (ja)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6428805B2 (ja) * 2017-02-07 2018-11-28 オムロン株式会社 演算装置、制御装置および制御方法
US11212432B2 (en) * 2018-01-04 2021-12-28 Sony Group Corporation Data transmission systems and data transmission methods
JP7110911B2 (ja) * 2018-10-29 2022-08-02 オムロン株式会社 コントローラおよびコントローラの備える通信制御部の制御方法
JP7003952B2 (ja) 2019-03-14 2022-01-21 オムロン株式会社 制御システム、サポート装置およびサポート装置用のプログラム
JP6903093B2 (ja) * 2019-04-26 2021-07-14 株式会社安川電機 通信システム、通信方法、及びプログラム
JP6923038B2 (ja) * 2019-04-26 2021-08-18 株式会社安川電機 通信システム、通信方法、及びプログラム
JP7251402B2 (ja) * 2019-08-20 2023-04-04 オムロン株式会社 制御システム、制御装置およびプログラム
CN113542090B (zh) * 2020-04-14 2023-07-14 宁波弘讯科技股份有限公司 一种EtherCAT主从站一体网桥控制器及控制方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0916221A (ja) * 1995-06-29 1997-01-17 Yazaki Corp 多重伝送システム
JP2011216085A (ja) 2010-03-15 2011-10-27 Omron Corp プログラマブルコントローラ
WO2016009477A1 (ja) * 2014-07-14 2016-01-21 三菱電機株式会社 制御装置

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4796232A (en) * 1987-10-20 1989-01-03 Contel Corporation Dual port memory controller
US4991133A (en) * 1988-10-07 1991-02-05 International Business Machines Corp. Specialized communications processor for layered protocols
DE69631304T2 (de) * 1995-06-29 2004-06-24 Yazaki Corp. Multiplex-Uebertragungssystem
US5802560A (en) * 1995-08-30 1998-09-01 Ramton International Corporation Multibus cached memory system
US5881247A (en) * 1995-11-30 1999-03-09 Allen-Bradley Company Llc System having a plurality of frame bytes capable of identifying addressed recipients and assert a busy signal onto the backplane bus to forthrightly abort the message transfer
US7024495B2 (en) * 2001-03-30 2006-04-04 Omron Corporation Programmable controller
KR101203464B1 (ko) * 2006-02-14 2012-11-21 삼성전자주식회사 무선 통신 시스템에서 하향 링크 프레임의 전송 지연을줄이는 방법 및 장치
KR101233915B1 (ko) * 2008-12-25 2013-02-15 미쓰비시덴키 가부시키가이샤 통신 관리 장치, 통신 장치 및 통신 방법
JP2010198600A (ja) * 2009-02-02 2010-09-09 Omron Corp 産業用コントローラ
JP6263836B2 (ja) * 2013-01-15 2018-01-24 オムロン株式会社 制御装置および制御方法
WO2015162734A1 (ja) * 2014-04-23 2015-10-29 三菱電機株式会社 中継装置およびデータ転送方法
JP6477161B2 (ja) * 2015-03-31 2019-03-06 オムロン株式会社 情報処理装置、情報処理プログラムおよび情報処理方法
JP6394561B2 (ja) * 2015-10-20 2018-09-26 トヨタ自動車株式会社 車載記録システム及び車載制御装置
JP6428805B2 (ja) * 2017-02-07 2018-11-28 オムロン株式会社 演算装置、制御装置および制御方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0916221A (ja) * 1995-06-29 1997-01-17 Yazaki Corp 多重伝送システム
JP2011216085A (ja) 2010-03-15 2011-10-27 Omron Corp プログラマブルコントローラ
WO2016009477A1 (ja) * 2014-07-14 2016-01-21 三菱電機株式会社 制御装置

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
EP3582038A4 (en) 2021-03-17
CN110178097B (zh) 2022-08-19
JP2018128780A (ja) 2018-08-16
US10785014B2 (en) 2020-09-22
US20190372746A1 (en) 2019-12-05
JP6428805B2 (ja) 2018-11-28
EP3582038A1 (en) 2019-12-18
CN110178097A (zh) 2019-08-27
EP3582038B1 (en) 2023-04-26

Similar Documents

Publication Publication Date Title
JP6428805B2 (ja) 演算装置、制御装置および制御方法
Tovar et al. Real-time fieldbus communications using Profibus networks
JPH09231183A (ja) リアルタイム分散処理システム
JP5829890B2 (ja) 半導体データ処理装置、タイムトリガ通信システム及び通信システム
JP7396393B2 (ja) 制御システム、装置および制御方法
JP2022537607A (ja) データパケットを送信する方法、及びこの方法を実施する装置
JP3551905B2 (ja) 管理局及びネットワークシステム並びにネットワークシステムにおける通信方法
US11036205B2 (en) Control device and communication device
JP4961589B2 (ja) ネットワークシステムおよびスレーブ同期方法
JP7089842B2 (ja) 演算装置および制御装置
JP2007249357A (ja) 情報処理装置、分散処理システム及びタスク管理方法
WO2019171845A1 (ja) 制御装置および制御システム
US11068423B2 (en) Control device and communication device
WO2022185586A1 (ja) 通信方法、通信システムおよびネットワークコントローラ
WO2012117445A1 (ja) 情報処理システム
JP2022048289A (ja) 制御装置および制御システム
Bhatia et al. Network Control Systems RTAI framework A Review

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: 17895678

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017895678

Country of ref document: EP

Effective date: 20190909