JP2007172255A - Inter-component communication equipment - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To reduce the overheads of inter-component communication when software components are present as distributed objects over processes or CPUs. <P>SOLUTION: Whether response data from a communicating party attended by inter-CPU communication are fixed data or variable data is judged, they are paired with a request parameter and stored when they are the fixed data, and the stored response data are returned without performing the inter-CPU communication at the time of request to the fixed data thereafter. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to an inter-component communication method, and more particularly to an inter-component communication apparatus when a software component exists as a distributed object that spans processes and CPUs.

  In order to support various products and device configurations, software can conceal differences between hardware and OS, and software components can be made into components so that components can be selectively used according to the device. To do. In this way, in order to increase the reusability of software assets and to cope with complex equipment configurations, a mechanism in which components are distributed and arranged on multiple CPUs, each of which communicates with each other and operates cooperatively The need for is getting very high.

In order to solve these problems, distributed object technologies such as Java (registered trademark) RMI and CORBA are used.
RMI allows objects to be moved freely from one machine to another in a distributed application framework.

  Also, there is almost no need to change the code. Whereas Java® RMI relies on Java® language, CORBA does not limit the supported language and defines how distributed objects communicate over a network. is there.

  An ORB (Object Request Broker) in CORBA has the following functions. In other words, it searches for an object on the remote machine, creates a stub object for accessing it, statically calls a remote method using the downloaded stub, converts parameters, and ensures security. The ORB is a component that acts as a communication medium for objects to communicate.

  Using the Java (registered trademark) RMI and CORBA mechanisms, even when software components are distributed, it is possible to design components without any particular consideration. However, since RMI and CORBA are general-purpose networks and frameworks for inter-application communication, there are the following problems when trying to use the frameworks in embedded devices.

  For example, a problem occurs when a component that is a data source exists on the first CPU side and a plurality of components that want to acquire the same information of the data source exist on the second CPU side. At this time, in the current mechanism, communication occurs between the first CPU and the second CPU by the number of requesting components of the second CPU.

In general, communication between CPUs significantly reduces the communication speed compared to communication within the same CPU, causing a decrease in system performance.
In particular, at the time of starting the system, each component generates data necessary for initialization in a short period of time. At this time, if more inter-CPU communication occurs, the startup time of the system will be delayed accordingly.

  Here, when trying to reduce these communication overheads by negotiation between components, the component itself becomes a dedicated part, and the portability of the component is lost.

  It is desired to reduce the communication overhead when the contents of an object to be communicated such as an embedded device can be imagined to some extent while maintaining the independence of components.

  The present invention has been made in view of the above problems, and software components mounted on communication do not need to be aware of where they are placed, that is, while maintaining the portability of the components. A component that reduces the overhead of inter-component communication and improves system performance by making each fixed data communication repeated between CPUs only once between the software component and the communication means. An object is to provide an intercommunication device.

  The inter-component communication apparatus of the present invention is an inter-component communication apparatus when a software component exists as a distributed object that spans processes and CPUs, and a data request destination is a component of the same CPU or a component of another CPU A communication partner determination means for determining whether or not the communication partner determination means determines that the communication partner is the other CPU, and a storage means for temporarily storing a request parameter for the communication partner; Fixed data determination means for determining whether the response data is fixed data or variable data, fixed data storage means for storing the data determined as the fixed data by the fixed data determination means in association with the request parameter, and the communication If it is determined by the partner determination means that the request destination is the different CPU, it is actually necessary. Before issuing, if the received data is present in the fixed data storage means without performing the request, and means for returning the data stored in the fixed data storage means.

  According to the present invention, the software component mounted on the communication does not need to be aware of where the software component is placed, that is, between the software component and the communication means while maintaining the portability of the component. By making each fixed data communication repeatedly performed between CPUs only once, it is possible to reduce the overhead of communication between components and improve the performance of the system.

  FIG. 2 is a diagram showing a conventional method. In FIG. 2, the system is composed of two CPUs, CPU1 and CPU2. There are two software components, Component1 and Component2, on the CPU1 side, and two software components, Component3 and Component4, on the CPU2 side.

Component1 has a database, and components 2, 3, and 4 need to communicate with Component1 in order to refer to the component1 database.
Since Component1 and Component2 operate on the same CPU, data can be transmitted and received by high-speed internal communication without external communication.

Requests from Component3 and Component4 to Component1 require inter-CPU transfer from CPU2 to CPU1. CPU transfer generally takes much longer than CPU internal transfer.
For example, in the example of FIG. 2, Component 3 and Component 4 communicate with Component 1 using inter-CPU transfer.

  By the way, if Component3 and Component4 request exactly the same data from Component1, and the data is invariant fixed data, repeating slow CPU transfers is a bottleneck in processing speed.

  Therefore, in the present invention, an STUB as shown in FIG. 3 is inserted between the communication means and the software component, thereby realizing an efficient communication process in the case of fixed data. FIG. 1 shows the STUB in FIG. 3 in detail.

In FIG. 1, the client side communication port is connected to the client side of the software component (1-2).
In FIG. 3, the client side is Component2, Component3, Componet4. The server side communication port is connected to a software component on the data source side.

In FIG. 3, it becomes Component1. Each component can only be one of them, and can have both server and client functions.
On the side connected to the communication port on the server side, STUB does nothing through data communication with the communication means (1-3).

  On the other hand, on the side connected to the client side, STUB has communication partner determination means (1-4) for determining whether the data request destination is a component of the same CPU or a component of another CPU. In addition, when the communication partner is a different CPU by the communication partner determination unit, a storage unit (1-6) is provided for temporarily storing a request parameter for the communication partner. Also, fixed data determination means (1-7) for determining whether the response data from the communication partner is fixed data or variable data. Further, it has fixed data storage means (1-8) for storing data determined as fixed data by the fixed data determination means in association with the request parameter. Also, if the communication partner determination means determines that the request destination is a different CPU, the request (communication) will not be made if there is already received data in the fixed data storage means before the request is actually issued. There is a fixed data management means (1-5) for returning data stored in the data storage means.

FIG. 6 is a flowchart showing processing on the client side in the diagram of FIG.
Accept the request from the client in S6-1. In S6-2, it is determined whether the communication partner is the same CPU or another CPU, and if it is determined that it is the same CPU, the process proceeds to S6-11, and if it is determined that it is a different CPU, the process proceeds to S6-4 (S6- 3).

Since the same CPU is used in S6-11, normal communication processing is performed, and if there is a response, response data is returned to the request source in S6-10.
In S6-4, the request parameter is compared with the request parameter of the data stored in the fixed data storage means (1-8). If response data for the same request is stored, the process proceeds to S6-12.

  In S6-12, response data is extracted from the stored data, and in S6-10, the data is returned to finish the process. If the response data is not stored in S6-4, the process proceeds to S6-5, the request parameters are temporarily stored, and the process proceeds to S6-6.

In S6-6, the communication means 1-9 is requested to perform communication, wait for a response, and if the response returns, proceed to S6-7.
In S6-7, it is determined whether the data returned in the response is fixed data or variable data. If it is fixed data, the process proceeds to S6-8. If it is variable data, the process proceeds to S6-9.
In S6-8, the response data is stored in the fixed data storage means 1-8 as a set with the request parameter temporarily stored in S6-5.

  Next, in S6-9, the request parameter temporarily stored in S6-5 is discarded, and in S6-10, data is returned to the request source and the process is terminated.

FIG. 4 is a flowchart for establishing a communication path between the server and the client using the communication means 1-9.
First, in 4-1, the server side registers the server port in communication means 1-9 with a unique "Port Name" on the server side. Next, in 4-2, the client uses the server's “Port Name” to obtain the identifier of the server component (Component ID).

When 4-2 is executed before 4-1, the communication means 1-9 holds the request of 4-2, and resumes the process of 4-2 after the server port is registered.
Once the “Component ID” is obtained, the client can connect (request) to the server using the “Component ID” (4-3).

The communication means 1-9 holds internal data as shown in FIG. 5 and manages “Component ID” and “Port Name” as a pair.
“Component ID” includes a field (5-1) indicating to which CPU the component belongs, and a value (5-2) that is unique in the system. The “Component ID” is further registered from the server and stored in association with “Port Name” used for searching the server port from the client.

FIG. 10 shows an example of request parameters from the client to the server.
First, “Component ID” indicating the destination of the request, “Request ID” indicating the contents, and “Reply Port” indicating the response destination (self) are stored.
Next, if there are additional arguments, the size (size) and argument data entity (arg) are stored.

FIG. 11 shows an example of response data from the server to the client.
First, in order to indicate which request the response is for, the same “Component ID” and “Request ID” as those requested by the client are stored. Next, the response status (status) for the request is stored, and if there is additional information, the size (size), flags indicating the type of information (flags), and the entity (arg) of the additional information are stored. The
A flag indicating whether the data is fixed data or variable data is also stored in the flag indicating the type of information.

FIG. 7 is an example of data communicated between components in the inkjet printer.
The “shipment information” holds parameters set at the time of factory shipment.
This information is unchanged after it is shipped from the factory. “User information” is information that can be customized by the user, and can be changed by the user's operation.

The “ink information” holds the remaining amount of ink, and the content changes depending on printing, cleaning, ink replacement, and the like. “Power information” holds the remaining battery level in the case of AC drive, DC drive, or DC drive, and the contents can always change.
In “error information”, warning and error information is updated one by one according to the state of the device.

Next, the component configuration of the ink jet printer is shown in FIG.
The CPU1 side is responsible for the functions of the single function printer, and the CPU2 side is equipped with functional components for camera direct printing without PC and maintenance of equipment, and hardware that expands the functions of the single function printer on the CPU1 side. It is.

The CPU 1 side in FIG. 8 has a component called a status manager (STM) that manages various statuses of the device, and centrally manages various types of information as shown in FIG.
It also has a printer function (PCPrint) and a component that prints print data from a host such as a PC.

  The CPU2 side in Fig. 8 is equipped with a component (DirectPrint) that connects the digital camera and prints the images inside the camera, and a component (Mainte) that allows the maintenance and setting of the device without a PC. is doing.

FIG. 9 shows each piece of information managed by the STM with the name of the component that references the information.
The information enclosed in parentheses is information necessary when the function is executed specifically (for example, if "PCPrint", print data is sent from the PC and printing is started). Information that is not enclosed in brackets is information that is required when the component is initialized.

Requests for “STM” from each component are made in units of information blocks.
For example, even when only “language” information in “shipping information” is desired, “shipping information” is acquired and information on “language” in the information is referred to.

Next, a specific processing flow will be described. As a premise, it is assumed that no data is stored in the fixed data storage means 1-8 yet.
First, the process when “shipment information” is requested from “PCPrint” to “STM” is shown.
A request is passed in S6-1. Next, in S6-2, it is determined from “CPU ID” (5-1) of “Component ID” used for connection whether the request destination is the same CPU or another CPU.

Since “PCPrint” and “STM” belong to the same CPU, the process proceeds to S6-11, and the request is transferred to the communication means 1-9.
Then, the returned data is returned to the client and the process is terminated.

Next, a process when “shipment information” is requested from “DirectPrint” to “STM” is shown.
A request is passed in S6-1.
Next, in S6-2, it is determined whether the request destination is the same CPU or another CPU.
Since “CPU ID” of “Component ID” is different from its own “CPU ID”, the process proceeds to S6-4.
In S6-4, since there is still no data relating to “shipment information” in the fixed data storage means 1-8, the process proceeds to S6-5 to temporarily store the request parameter.

Here, the entire request parameter shown in FIG. 10 is stored.
Next, in S6-6, the request is transferred to the communication means 1-8, and a response is waited for.
When there is a response, check whether there is additional information in the response data. If there is additional information, refer to the flag indicating whether it is fixed data or variable data from the flags indicating the information type stored there. It is then determined whether it is fixed data (S6-7).

If it is fixed data, the request parameter and response data (FIG. 11) stored in S6-5 are paired and stored in the fixed data storage means (1-8) (S6-8).
Then, the request parameter stored in S6-5 is discarded, data is returned to the client component, and the process is terminated.

Next, a process when a “shipment information” request is made from “Mainte” to “STM” in a state where a response of “shipment information” from “DirectPrint” to “STM” is received.
The processing up to S6-3 is the same as the processing described above, and is omitted. In S6-4, since response data associated with the same request parameter as the current request parameter is already stored in the fixed data storage means (1-8), the process proceeds to S6-12. In S6-12, the response data associated with the request parameter is retrieved from the fixed data storage means, returned to the client component, and the process is terminated.

As described above, the present invention is more effective when requests for the same data are repeatedly generated in communication between modules.
For example, when a device is started, many modules need to initialize their respective operation modes according to configuration parameters.

The contents of the “user information” in FIGS. 7 and 9 change depending on the user setting.
However, if the user cannot perform operations such as during system startup, the data can be temporarily handled as fixed data.

  Therefore, if data that can be handled as fixed data only during system startup is further stored in the fixed data storage means, it is possible to further reduce the overhead of inter-module communication.

It is a figure which shows one Embodiment of this invention. It is a figure which shows the conventional communication form. It is a figure which shows the communication form after application of this invention. It is a figure which shows the flow of communication path establishment. It is a figure which shows the management method of a communication port. It is a flowchart which shows the Example of this invention. It is a figure which shows the example of the data communicated. It is a figure which shows the example of the software component in a printer. It is a figure which shows the example of which data a software component uses. It is a figure which shows the example of a request parameter. It is a figure which shows the example of response data.

Explanation of symbols

1-4 Communication partner judgment method
1-5 Fixed data management means
1-6 Storage means
1-7 Fixed data judgment method
1-8 Fixed data storage means

Claims (4)

A communication device between components when a software component exists as a distributed object across processes and CPUs,
A communication partner determination means for determining whether the data request destination is a component of the same CPU or a component of another CPU;
Storage means for temporarily storing a request parameter to the communication partner when the communication partner determination unit determines that the communication partner is the another CPU;
Fixed data determination means for determining whether the response data from the communication partner is fixed data or variable data;
Fixed data storage means for storing the data determined as the fixed data by the fixed data determination means in association with the request parameter;
If the communication partner determining means determines that the request destination is the other CPU, the request is not made if the received data exists in the fixed data storage means before the request is actually issued, and the fixed destination is not fixed. An inter-component communication apparatus comprising: means for returning data stored in the data storage means.   The server side component that requested the data stores in advance that the data to be managed is the fixed data or the variable data, and adds information on whether the data is the fixed data or the variable data to the response data to the request side. The inter-component communication apparatus according to claim 1, wherein the inter-component communication apparatus responds. Means for determining data to be fixed data in a specific phase period;
The inter-component communication apparatus according to claim 1, wherein the data is held as the fixed data only during the specific phase.   The inter-component communication apparatus according to claim 3, wherein the specific phase is a system startup time.

Images