RU2486578C2 - Method to build system of messages of multi-level asymmetrical transport system - Google Patents

Abstract

FIELD: information technologies.

SUBSTANCE: virtual workplaces are given the capability to be dynamically configured in any number of units of a local network, forming a spatially independent information grid, formed by repeating structures, to provide for network interaction of program processes of the system, there are performed modules, forming a transport system in the form of an information grid, and performed modules are arranged in units of this grid, besides, links of the grid create repeating structures, all processes are autonomous and separated into zones, in every of which all processes are closed to a process dispatcher, performing only service functions, at the same time each process dispatcher has a client part for processing of commands that arrived from top of the transport system, and a server part for processing of commands that arrived from the bottom, both parts of the dispatcher determine in the receiver's address its name for further command transfer.

EFFECT: territorial independence of an automated workplace with unlimited expansion of a system via its repeating structures with building of a hierarchical transport system due to free migration of software inside a complex of AS technical facilities.

6 dwg

Description

The invention relates to automation systems based on the use of computers.

Modern opportunities are changing our ideas about the organization of the work process. The personal computer, which has become in recent decades an integral attribute of the office and a means of fulfilling most office tasks, ceases to keep pace with the growing needs of users. The real tool of the user is software that is only tied to a PC, making it an intermediate link in the corporate information system. As a result, cloud computing (cloud computing) is actively developing, when users have access to their own data, but do not manage and do not think about the infrastructure, operating system and the actual software with which they work.

However, with the growth of organizations, the use of custom PCs in the IT infrastructure causes a number of difficulties:

- high transaction costs to support the computer park;

- the complexity associated with managing desktop PCs;

- providing users with safe and reliable access to software and applications necessary for work;

- technical support for users;

- installation and updating of licenses for software and maintenance;

- backup, etc.

It is possible to get away from these difficulties and reduce the costs associated with their solution, thanks to the use of virtualization technology for employee jobs based on the virtual PC infrastructure. Such a system allows you to separate the user software from the hardware - a personal computer and access client applications through terminal devices.

One of the conditions characterizing ACS JV as a field of application of the developed product is the need to interact with various systems and subsystems at all levels of the hierarchy. Moreover, during the intended use as a result of reconfiguration of the system, the composition of the interacting systems, subsystems and objects can be rapidly changed. It should be noted that interacting systems, subsystems and objects can be built in various tool environments on various software and hardware platforms and function in various operating systems.

The problem of combining complexes into a single whole or into a network (for example, into a global one) that can be easily integrated from multiple subnets can be considered either as creating a comprehensive complex, or as integrating complexes based on combining "trusted" nodes without losing the control effect of each of the participants. The problem of reconfiguring the complex to the state of the environment (tasks to be solved) or for the purpose of functional recovery after damaging influences can also be considered as integration of trusted nodes without loss of control influence.

The construction of such networks already involves not just organizing support for network transport, but solving the problem of the next stage - merging software systems or scaling up - building a new software complex by including additional components endowed with certain functionality, or by freely transferring them to the software and hardware space, unlimited expandable through repeating structures of software systems.

The basis for this process is the virtualization of the software package. The complex, which has the property of virtualization, is like an accordion: it can be assembled within one PC or stretched to many machines. In the event that each node of the complex can reproduce its large functional units or functional blocks (according to a certain algorithm from processes) (this can also be done centrally), the problem of automatic configuration is solved.

The totality of functional blocks creates a larger unit, on the one hand, possessing aggregate functionality and not losing the main property of its constituent parts - virtualization. Such a large unit can be, for example, the functionality of a workstation, the functionality of a group, or complex.

The proposed technology develops a component programming model and is based on an architecture built on independent software entities - processes that represent the evolutionary development of modules.

The processes have the following main characteristics:

- independence;

- self-sufficiency;

- the ability to network.

1. Independence of processes. This implies, firstly, program independence, i.e. the possibility of separate compilation of processes and their subsequent dynamic linking; secondly, information independence, i.e. the ability of a process to hide its internal data and present it only through its interface part, and, thirdly, the ability of processes to work autonomously (no process crashes when dynamically loading or shutting down other processes).

2. The principle of self-sufficiency determines the functional completeness of the process, ie its ability to perform clearly defined and logically interconnected functions defined within the framework of one task (subtask) of the information system.

3. Networking. Since processes are parts of a large and distributed system, the ability of processes to interact through a network should be one of their main characteristics. Through it, the issue of the independence of processes from their location, i.e. their free portability (virtualization).

The main provisions of building a software package based on process architecture:

1. The software package is a combination of isolated programs (processes) interacting with each other.

2. At the network level, programs interact using the TCP / IP protocol.

3. Communication between programs is organized through teams.

4. Delivery of the team is carried out at the address specified in the address part of the team.

5. In the process of their promotion, a return address is formed in the team. Thus, the receiver of the command can generate a response to the sender of the command.

6. Some of the programs (processes) that are responsible for the delivery of commands are called dispatchers. Other programs are processes.

7. Processes can only be connected to dispatchers. Dispatchers are also connected only to dispatchers.

8. Among the dispatchers, the Central dispatcher stands out. It closes all the dispatchers of the system.

9. Central controllers can also connect to each other. Thus, you can increase the complex indefinitely.

10. The central dispatcher, not connected to another Central dispatcher, is the top of the complex. Each complex has only one peak.

11. The function of dispatchers is to advance the team among themselves and, ultimately, transfer it to the process.

12. Addressing uses the names of dispatchers and processes. Each process and dispatcher has its own name.

13. The process or dispatcher reports its name when connecting to another dispatcher. This process is called registration.

14. The process is based on the Model Process.

15. A typical process carries out all the work of connecting, registering, receiving and transmitting commands to dispatchers. The interface part is open for him, allowing you to use the functions of receiving / transmitting commands.

16. A typical process includes a command buffer and a shell.

17. The user process extends the generic process and uses its interface.

Increasing demands necessitate processes that must be operated with the highest degree of efficiency, reliability and safety. Therefore, it is known that from the moment of design it is necessary to fully automate production processes through the flow of information using a computer.

The systems used for this are already known from the method of constructing a system of access to data transmission networks, in particular IP networks, including the creation of a system on a cellular basis and the organization of subscribers of a base station (cell) wireless access to network resources through a group hub, while data from a group concentrator is transmitted to subscribers through several directional base transmitters, signals are received from subscribers by individual or microgroup (cluster) receivers, transmission signals from subscribers are conducted by individual or cluster subscriber transmitters, and signals from subscribers are received by basic group receivers with coverage areas, which are determined based on the conditions for the base group receiver in the line of sight of the respective subscriber transmitters, and data from the base receivers is sent to the group hub, for data transmission between the base station and subscribers use the electromagnetic radiation of the optical range, as the base transmitters use transmitting optical devices in an amount corresponding to the number of subscriber receivers, with which they establish their optical connection, while using the same optical carrier to transmit data from all subscriber transmitters within the group, RF patent 2196387.

To implement the known method requires special transmission paths, which significantly reduces the functionality of the built-in system.

The technical result of the proposed method is to create an automated system with geographically independent workstations with unlimited expansion of the system through its repeating structures with the construction of a hierarchical transport system.

This technical result is achieved by the fact that in the method of constructing a multilevel asymmetric transport system message system, virtual workstations are given the opportunity to dynamically be configured on any number of nodes on a local network combining computers of a set of technical means of an automated system, forming a spatially independent information lattice formed by repeating structures, this to ensure the network interaction of the software processes of the system I have executable modules are formed that form the transport system in the form of an information lattice, and executable modules are located in the nodes of this lattice, and the links of the lattice create repeating structures, all processes are autonomous and divided into zones, in each of which all processes are closed to a process manager, which is a system an element that performs only service functions, and each dispatcher process has a client part for processing commands received from above the transport system, and a server part for processing commands, drinking from the bottom, both parts of the dispatcher determine in the recipient address his name for further forwarding of the command.

The invention is illustrated by drawings, which depict:

figure 1, 2 is a diagram of the union of two transport systems (TS);

figure 3 is a combination of the launch of the transport system on intermediate variants of the number of computers;

figure 4 - connection diagram of processes to the dispatcher.

5 is a diagram of the addressing of processes in the transport system of the complex.

6 is a diagram of the route from sender to recipient.

The implementation of the invention.

Workplace virtualization.

A workplace is a hardware-software complex that solves the tasks of one NPP official.

The independence of jobs from their territorial location is defined as the free migration of software within the complex of technical equipment of nuclear power plants. In this case, the option is possible when all the jobs are collected within the same workstation (the minimum option). The ideal option is one workstation - one workstation. In the event of a surplus of technical equipment, several workstations can occupy jobs.

The technical solution is based on the implementation of significant independence of software modules (processes) and the openness of their interfaces.

In addition, the interaction of these modules (processes) is based on a special platform of executable modules that form the transport system. These modules can form arbitrary configurations, located on arbitrary nodes of the data network.

Isomorphic scaling.

The essence of the AC built on this technology is to create an information grid, in the nodes of which the elements of the transport system are located. Several links of this lattice create repeating structures that can be propagated an undetermined number of times. Those. AS complex can expand (or decrease) due to duplicated information structures.

Duplication of information structures can be performed by the complex itself, or as such, structures of similar complexes that have entered into interaction with the data can be used. By a similar complex we mean a complex assembled according to the presented technology.

In principle, the expansion of the NPP under consideration is possible not only due to similar information structures, the main thing is that “building materials” of this technology are used as building elements of architecture.

Another property follows from this - the interaction of speakers due to the merger of architectures made on this technology.

One of the applications of this type of speaker is as follows. Imagine the existence of some territorial limited speakers with good performance (base speakers) and several mobile speakers with extremely low technical resources. If all the considered speakers are implemented using this technology, then these mobile speakers from time to time can interact with the base speaker and at the same time use its potential to carry out their calculations and adjust their tasks, i.e. at some point, there is always an extended speaker (base + one or more mobile), which is holistic and can solve the problems available for such an architecture.

The principles of building an automated system based on independent software components implemented by separate executable modules - processes.

The idea of such an architecture is to maximize the independence of processes, that is, in their ability to boot and function autonomously. In this case, any computer on the network can become a process runtime, and the process itself does not care about the place of its physical loading.

Each process processes the information arriving to it and gives it to other processes. There is a kind of conveyor on which processes perform their operations, and at the output we get a ready-made result.

The principle of independence (autonomy) of processes allows us to solve the issue of grouping dynamically, that is, during the operation of the AU without interrupting its operation. Moreover, the same principle allows reconfiguration of the entire system also without rebooting.

The total process space is divided into separate zones. These zones, as well as processes, can be physically located within the speakers in an arbitrary order, but with the condition that they do not intersect each other. All processes of one zone are closed to a special process - the dispatcher, which performs only service functions, that is, it is a system element of the AU. Processes and dispatchers are linked into a single structure thanks to a typical process. It defines the basis of other processes and dispatchers of the system, that is, other processes and dispatchers are the heirs of the class "typical process". The task of a typical process is, firstly, to establish communication with dispatchers and, secondly, to receive and transmit information messages. The heir class uses ready-made implementations of the above properties of a typical process and provides the developer with calls to the functions of these implementations.

The architecture of the hierarchical system of network interaction of software components of the system.

To ensure network interaction in the complex, special processes are involved - dispatchers, the totality of which forms a single environment for the functioning of the complex, into which other processes are immersed. Many processes connected to one dispatcher form an AWP.

The transport system of the complex performs two main tasks:

- provides network interaction of processes;

- composes the workstation of the complex.

The transport system (TS) is built hierarchically. Each client has only one dispatcher above itself, which acts for him as a server that provides transport services. However, any dispatcher can act as a client in relation to a superior dispatcher, and as such for a superior, he is no different from the ordinary application process. Since any dispatcher can have one and only one host server as a client, the transport system is a hierarchical system with a single vertex. In other words, there is always one and only one dispatcher in the system, which is not any client.

From the foregoing it follows that the transport system in the general case is multi-level and asymmetric, with an unlimited number of levels. The closest analogues to the TS are the Linux file system and the MS Windows logical disk file system. The dispatcher is an analog of the directory (folder) of the file system, the client is an analog of the file. However, there is one fundamental difference - the TS does not have a fixed vertex (an analog of the root folder), since the TS is dynamically expandable both down from the top (like a file one) and up. That is, the top is always unique at any moment, but it, unlike the root folder ("\" in MS Windows or "/" in Linux), can at any time give way to another status (however external to that TS , which was made by the peak losing its status). The situation of vertex change will occur in the case when the vertex (central) server of some autonomously working TS will connect to any of the dispatchers of another TS. In this case, two private vehicles will merge into one, and the central dispatcher of the second vehicle will become the common peak of the combined vehicle.

The scheme for combining two vehicles is presented in figures 1 and 2.

The flexibility of constructing the TS illustrated above is achieved, first of all, due to the fact that a dispatcher module, uniform from the point of view of program code, functions at any level in it. Essentially, concepts like “the main dispatcher”, “central dispatcher” disappear here. The rank of the dispatcher can be changed quickly, either by connecting to another server on his own or by connecting another dispatcher as a client to it.

For application programmers developing processes embedded in the system, the dispatcher is a separate independent software module, the internal filling of which is not available to them. The method of communication with the dispatcher does not depend on the development environment of the application process, including the operating system and the programming language, and is determined only by its interface.

The transport system is a system of executable modules loaded before the start of the speaker. This is a fairly independent and self-sufficient education. For TS, the functional implementation of AS is indifferent. The TS executable modules can be downloaded both on one computer on the network, or on several, based on one dispatcher - one computer. A combination of starting the vehicle on intermediate variants of the number of computers is possible (Fig. 3).

It is understood that each AWP is deployed on a separate computer. This is quite logical when you consider that the operator controls the AWP, which is difficult to share, for example, equipment such as a keyboard with another user of the same kind. However, a number of processes can only perform service functions, without any operator intervention. In this case, the dispatcher and processes connected to it can migrate to the computers of the speakers - their location is not important. In fact, a combination is possible in which the dispatcher and part of the processes connected to it are located on one computer, and the other part on another (Fig. 4). This option is also possible for processes in the workstation.

This figure shows the migration of the processes that form AWP_3, within the automated system, to other computers that support the work of AWP_1 and AWP_2.

As already mentioned above, the components of the transport system (TS) are: dispatchers, forming the basis of the information interaction of the system, and processes - users of the system.

The interaction of components in the TS is carried out through commands. All teams have a single internal structure, in which the system (transport) and application levels are clearly distinguished. Currently, the team structure includes six fields. The first two comprise the address part: the address of the command recipient indicated by the sender, and the address of the sender itself, which is generated automatically and should provide a reverse flow of response to command requests sent to any point on the vehicle. The ability to automatically generate a return address is provided by introducing the concept of "registration name", which by default coincides with the name of the software module, but, if necessary, can be changed, however, only when the module is launched. A typical process should block the possibility of changing the registration name after the client joins the system. The third field is the command index, it is used for those teams whose format requires sending a response command from the recipient. The fourth field is the transport operation code. On the application layer, it is possible to use only a strictly fixed number of TS operations, namely: SAY - sending a message that does not require a response, ASK - a command requiring a response (request), REP - a response command to ASK, ERR - an error in the request (the user process can send an error message only in the syntax of the two fields described below, this code is similar to raising an exception in the program code and should signal to the application process developer about the inadequacy of its program code, end-user errors They can be brought to his workplace by sending ordinary messages (answers)). At the system level of the TS, other commands that are not available at the application level are also used (first of all, REG is the command to register the process with the dispatcher, and BYE is the server’s request for the client to disconnect, KILL is the server’s request for the client to shut down; other commands may appear in the future) . All of these commands must be handled by a typical process. As mentioned earlier, at the application level, the field of the transport operation code should not be available when filling out a command (this is achieved by providing its own standard method for sending a command by a class of a typical process for each type of operation). However, for received commands, the application-level incoming message processor is able to analyze the transport operation code. The fifth field is the application level command code. This TS field does not analyze; it is assigned to the application layer. The sixth is the operand field (the actual message). It is a string containing key parameters separated by spaces, each of which has the format: operand code, equal sign (spaces around the equal sign are not allowed), value: Operand1 = 3value1 Operand2 = 3value2. A typical process should provide service functions for processing a string of operands, but does not interfere with their contents. A special key parameter that has an empty operand code is specially processed (i.e., the operand begins immediately with an equal sign followed by a value). The value of such an operand is the entire “tail” of the string from the equal sign (in this case, the rule about quotation marks and spaces can be ignored).

Figure 5 shows a diagram of the addressing of processes in the transport system of the complex. The names of the dispatchers are designated as D1, D2. The names of the processes are P1, P2, P3. The names of the central dispatchers are CD1, CD2.

In accordance with the above diagram, we obtain a simple addressing system based on a hierarchy of dispatcher names, which is displayed in the address part of the command. In fact, the address is a chain of dispatcher names and the name of the process sending the command. Figure 6 presents different options for addressing teams, depending on the location of the recipient of the command:

- the sender and receiver are connected to the same dispatcher;

- the sender and receiver are connected to different dispatchers of the same central dispatcher;

- The sender and receiver are connected to different dispatchers from different central dispatchers.

The recipient address (AP) is set at the application level. Processing it (team routing) is carried out by the dispatchers of the vehicle. The processing algorithm is independent of the hierarchy level at which the dispatcher operates. AP format: [[[Disp1.] Disp2.] DispN.] Process Recipient. This format is similar to the format for setting the path in file systems, only the dot character is used as a separator for the names of dispatchers (playing the role of folders in the FS). The list of dispatcher names before the name of the recipient process sets the path to this process from the inflection point on the route from the sender to the recipient. In a particular case, it can be a regular dispatcher for special teams requesting data that is available from him.

So, to send a message from the leftmost one in the diagram (Fig. 6) of the process P1 to its neighbor, the process P2 can be specified as an AP in the form D1.P2, or simply in the form of P2.

The algorithm for processing the AP by the dispatcher is as follows. A command can be sent to the dispatcher both from above and from below. The command received by the dispatcher from above is analyzed by the client part of the dispatcher. In the AP, it must also contain his name. If this is not the case, it will return an error message. If his name is the last in the AP name chain, then this is a command directly to him, and he interprets it himself. If there is anything else behind his own name, then he searches for that name in the list of names of the clients registered with him (ignoring all the names that follow him in the AP chain). When a client with that name is found, it sends a command to it (ie, down), otherwise it must return to the sender (up) the message “destination was not found”. The message “destination not found” is returned to the sender application process only when the latter sends the command with the transport operation code ASK.

The command received from the dispatcher from below is analyzed by the server part of the dispatcher. In AP, it does not necessarily contain his name. However, if his name is the first in the AP name chain, then the dispatcher is at the inflection point on the command route (or this is the command addressed directly to him, but then his name is the only one in the AP). If his name is not there, then he checks the first name in the chain for a match with the names of his registered customers. If a match is found, the command is sent to this client (down, i.e. inflection: from the bottom came - down went). The second name in the AP chain is analyzed in the same way when the first name is the name of the dispatcher itself. If the chain does not start with the name of the dispatcher itself, and the second name is not found in the list of clients, then the dispatcher assumes that the command is intended to go up, and he looks for the first name in his list of upstream servers (if there is such a list, i.e. if this dispatcher itself is not the top of the vehicle). If such a name is found, the command is sent to the first of the higher servers, and the command will repeat the analysis of the AP. Otherwise, he must return to the sender (down) the message “destination not found”).

In other words, when passing the command from the bottom up, the inflection point is always sought, from which it changes the direction of movement. That is why the AP filled in by the sender must contain the address “from the inflection point”. This clearly guarantees that the transport system will deliver the command to the addressee.

To ensure unambiguous addressing during the registration process on the server, the registration name of the joined client is checked for uniqueness not only in the list of its (server) clients, but also in the list of higher-level dispatchers (with respect to the server).

In the AP in any link of the address chain, except the very first one, a special symbol “*” (asterisk) can be indicated instead of a specific name, which means a broadcast message. For example, a single “*” symbol means sending a command to all processes located at the same level as the sending one (however, it will not go to lower levels, that is, if process P1 (Fig. 6) sends such a message, then it will reach process P2, but the address D1.D2, having received this, will not be forwarded to its clients.The AP specified as D. *. P2 will deliver the command from process P1 to D.D1.P2 and D.D2.P2 . etc.

The sender address, as already mentioned, is affixed automatically. A typical process places the registration name of the process in AO. Each dispatcher, when passing the command up through him, adds his name to the beginning of the AO, and this continues until the inflection point.

Claims (1)

A method of constructing a message system of a multi-level asymmetric transport system in which the independence of virtual workstations from their territorial location is achieved by free migration of software within the complex of technical means of an automated system (AS), for which virtual workstations are given the opportunity to dynamically configure on any number of nodes on the local network, combining computers of a complex of technical means of an automated system, forming a space an essentially independent information lattice formed by repeating structures, while to ensure the network interaction of the program processes of the system, there are executable modules forming the transport system in the form of an information lattice, and executable modules are located in the nodes of this lattice, while the lattice links create repeating structures, all processes are autonomous and divided into zones, in each of which all processes are closed by a dispatcher process, which is a system element that performs only service functions In this case, each dispatcher process has a client part for processing commands received from above the transport system, and a server part for processing commands received from below, both parts of the dispatcher determine its name in the recipient address for further transfer of the command.