RU2705421C1 - Method of transmitting data over a bus, a communication system for realizing said method and an automatic protection device for preventing an emergency situation at a control object - Google Patents

Abstract

FIELD: computer engineering.

SUBSTANCE: invention relates to computer engineering. Method comprises steps of: sequentially transmitting data across a bus between modules of a device for automatic control or protection of a control object, each of modules comprises a programmable computing device and an interface unit, wherein at least one of the interface units is configured to operate in the master mode and at least two interface units are configured to operate in the slave devices mode, after which data are exchanged between modules of the device in the form of a control packet consisting of service data or an information packet consisting of a control packet and a data packet, wherein each interface unit, configured for operation in the slave device mode, comprises a controller.

EFFECT: automatic prevention of an emergency situation on a control object.

7 cl, 17 dwg, 7 tbl

Description

The invention relates to the field of communication networks, namely to the TSI interface, designed for serial data transmission over the bus. In particular, the application describes the TSI protocol, a communication system designed to implement this protocol, and an emergency emergency protection device that uses a communication system and data transmission method.

The application describes a peripheral interface complex functional block (hereinafter referred to as SF block) developed for VLSIs of the “system on a chip” type (hereinafter referred to as SNK).

During the development of the SoC class of microprocessors or microcontrollers for use in industrial controllers, relay protection and automation terminals (RPA) and automated process control systems (APCS), the TSI_controller SF block was developed for software and hardware implementation protocol. Using the TSI_controller SF block, data is exchanged on the bus with devices external to the SoC that have the same SF block. The SF block described in the application, depending on the field of application, supports one of two protocols. The first TMV5000 protocol is described in the application for invention EA No. 201700029 A1, published on 02.28.2018 and in the application for invention RU No.2018111465, filed on 03.30.2018. The second TSI protocol is described in this application.

SoK with the claimed SF block is made according to the CMOS technology of 28 nm.

When describing the SF block and protocol, the terms used have the following meanings:

A “data exchange protocol” or “data transfer protocol” is a set of rules and conventions that define the content, format, time parameters, sequence and error checking in data packets exchanged between device modules.

“Master” means a device that sends data to other devices and / or requests data from other devices, i.e. is the initiator in the exchange of data with the slave device.

“Slave device” means a device that can exchange information only with the master device after a corresponding request is received from the master device.

"Bus" - a differential twisted pair of wires or a differential pair of conductors on a printed circuit board, which transmit data in the form of electrical signals from the sender to the receiver.

“Shared bus” or “trunk” is a type of communication line in which all modules of the device are connected to a common communication line. A common communication line is used by all modules in turn. All messages sent by individual modules are listened to by all other modules connected to the communication line, but the module selects only messages addressed to it from the message flow.

"Word" - a string of bits, considered as a single unit during their transmission, reception, switching, processing, display and storage.

A “packet” is a data block processed by network programs as a whole.

“Control packet” - a packet of data that plays the role of service information necessary for the implementation of the protocol.

“Information packet” - a packet consisting of service data and useful data that must be transmitted.

The general structure of a control or information package is determined by the composition of the package and its format.

“Composition” - various data types contained in a package.

“Field” is a specific data type, and the size of this data in bits is the length of the field.

"Format" - the size and placement of various types of data.

“Message” or “transaction” is a sequence of transmitted control and information packets, which is a completed operation of working with data, for example, a “read” operation or a “write” operation of data.

“Technological control object” - a control object that includes technological equipment and the technological process implemented in it.

The known interface described in the standard MIL-STD-1553B, dated 21 September 1978, "Department of defense interface standard for digital time division command / response multiplex data bus" (designation of the US military standard). In our country, it was approved as GOST 26765.52-87, which is replaced by GOST R 52070-2003 “Serial trunk system interface of electronic modules. General requirements". This standard describes a serial main interface with centralized control used in the electronic module system and establishes requirements for the organization of information exchange, the functions of interface devices and the control of information transfer, the characteristics of the information highway and the characteristics of interface devices. The interface operates asynchronously in command-response mode. Initiation of information exchange and transmission control is carried out only by the bus controller connected to the bus type "trunk". Remote terminals operating in accordance with the commands of the bus controller and a monitor that selects information transmitted via the bus are connected to the same bus. The standard defines the composition of words - command word, data word and response word. The size of each word is 20 digits. Words begin with a clock signal (three digits), then 16 information bits and a parity check bit (P) follow. All information on the highway is transmitted in the Manchester-2 code. The control word contains the field "address of the terminal device" and the category "receive / transmit". Additionally, the command word contains a field “terminal address of the terminal device” and a field “number of data words” or a field “control mode attribute code” and a “control command code” field. If the control word contains the field "control mode code" and the field "control command code", it is called a control command. The control command is used only for managing interface devices, but not for exchanging data with interface users. The control command should be applied without data words or with one data word. The response word contains the address of the terminal device and diagnostic data (field of bits of signs of the status of the terminal device or signs of reliability of the received command word). Their value gives the following information: error in the message, transmission of the response word, service request, standby bits, group command received, subscriber busy, subscriber malfunction, interface control accepted, terminal device malfunction and three standby discharges. The interface has the following disadvantages. The maximum message size that can be transmitted or received is no more than 32 data words. Full control of the reliability of the transmitted information is not provided. Addressed subscribers no more than 31.

Known "Interface device MIL-STD-1553, working autonomously in all three modes" (US patent 5,490,254 A). The aim of the known invention was to create a single integrated circuit (hereinafter referred to as IC), which would implement the functions of all three devices defined by the MIL-STD-1553B standard, namely the functions of a bus controller, remote terminal and monitor. The IC is connected to the system host processor and has a common RAM with it.

The closest analogue to the proposed method for transmitting data on the bus is the application EA 201700029 A1, "Adaptive data transfer method in an industrial controller." A known method of data transmission is that between the master device and slave devices connected to a common bus type "trunk", carry out a serial data exchange. All information on the bus is transmitted in the Manchester-2 code. Serial data transfer between the master electronic device and the slave electronic device is carried out in the form of a control packet or an information packet consisting of a control packet and a data packet. A data packet (payload) consists of one or more 16 bit data words and a 16 bit checksum word. Each word in the data packet begins with a clock signal (3 bits) and ends with a parity bit (P). The control packet (service data) consists of two 16-bit control words and a 16-bit checksum word. Each word in the control packet starts with a clock signal and ends with a parity bit (P). The sync signal is designed to distinguish data words and checksum words from control words. The control words include the address of the requested slave device, the number of the internal address space of the requested slave device, the bit of the initiator of the current transmission, the bit of the write / read operation, the bit of the adaptive read useful information flag, the bit of validation of the received information packet, a field with a value equal to the number of words in data field. The number of devices connected to the bus can reach 128. The reliability of the transmitted packets is ensured by checking the parity bit (P) of each word and checking the checksums (CRC-16) of the transmitted packets. The control packet contains 6 reserved bits, which make it possible to expand the known protocol with additional features.

A common drawback of the protocols and interface devices described above is that they are designed for use in a device operating in normal (normal) mode. The described protocols and the interface device do not describe additional means or properties that could give the device in which they are used, additional opportunities for the implementation of its purpose during abnormal operation of the device caused by a failure of its functional units.

The purpose of automatic emergency protection systems (hereinafter referred to as PAZ systems) is to transfer the control facility, an accident which can lead to personal injury or death, destruction of the control facility or harm the environment, to a safe state when its technological parameters exceed the maximum permissible values. PAZ systems devices must not only control the technological parameters important for the safe state of the control object, but also must diagnose the safety of their own work. If the measured parameters go beyond the permissible values or when the PAZ device diagnoses its own unsafe operation, the PAZ system stops the actuators of the control object.

In reality, in order to avoid downtime of the control object that has to be stopped due to the unsafe operation of the PAZ system device, PAZ systems are designed with redundancy of their devices. Such systems are called fault tolerant and allow you to continue the process at the control object.

The closest analogue to a communication system for transmitting data on a bus is DE 19742716 A1, “Control and data transmission system and security-related data transmission method”. Known inventions relate to the field of automation (machines, robots) and are aimed at diagnosing the safe operation of a communication system. The control module and I / O modules are connected to the Interbus bus. For this, in the control module and in the input / output modules, in addition to the device intended for connection to the bus, there are safety circuits. In the I / O module in the security circuit there is a protective component in which the security protocol is implemented and which performs a regular self-test. The data associated with the process is transferred to the control module in a redundant and at the same time different form: once in unchanged form, second time in negative form and third time in the form of a checksum obtained from the process data. For this, the corresponding fields are provided in the data packet. When diagnosing a failure, the machine and the robot can be separated from the control system using switches located on the output line of the safety circuit of the I / O unit. The switches are controlled by a protective component according to the control information from the control module.

The closest analogue to the claimed protection device for preventing an emergency at the control object is US Pat. No. 7,715,932 B2, “Device and method for controlling a process critical to safety”. The known device is intended for monitoring and control of operations carried out in the field of factory equipment (press brake, robot). The monitoring and control device (hereinafter referred to as the device) is designed to stop the factory equipment in case technological parameters go beyond the set values or in case of failure of the functional units of the device. For this, the device implements solutions that allow it to diagnose its own safe operation. The device comprises a control unit and input / output units. I / O blocks contain programmable computing devices (microcontrollers). The I / O blocks are physically removed from the control unit and connected to it via a single-channel field bus for data transmission. Input blocks are used to receive signals from the emergency stop button, light curtain and sensors, i.e. to receive signals that are important for the safe condition of factory equipment. The output blocks contain switching elements, the closed or open state of which leads to the inclusion or deactivation of the contactor used to deactivate the drive mechanisms. The patent describes solutions that provide diagnostics of a failure of a computing device of a control unit or a failure of computing devices of I / O units. If the microcontroller fails, the output unit provides the option of supplying a signal to the switching elements via an "additional shutdown path" - an additional bus that connects the control unit and the output unit. In this case, the control of the switching elements is carried out by the control unit directly via an additional bus.

The closest analogs described above for a communication system and protection device contain additional means that allow responding to the unsafe operation of the protection device in order to ensure that it can fulfill its purpose, namely, to disable executive devices to put the control object in a safe state. However, well-known solutions do not use interface tools and properties for this.

The aim of the group of inventions is to use the properties and means of the interface, designed to exchange data between the modules of the automatic protection device, to prevent an emergency at the control object.

More specifically, the invention relates to the properties of the protocol and the means of interface units intended for the software and hardware implementation of the protocol, which allow the automatic protection device to respond to the failure of a programmable computing device (microcontroller, microprocessor, SoC cores) designed for data processing and data exchange process control in signal input or output modules, in order to prevent an emergency at the control object.

The technical result in the first invention is achieved by the fact that the method of transmitting data on the bus is that serial data is transmitted on the bus between the modules of the device designed for automatic control or protection of the control object. Each of the modules contains a programmable computing device and an interface unit. At least one of the interface units is configured to operate in master mode, and at least two interface units are configured to operate in slave mode. Each interface unit, configured to work in slave mode, contains a controller, the main area of local memory, which is used during the normal operation of the module for data exchange between the controller and the programmable computing device, and an additional area of local memory, which is used when fixing abnormal operation of the module, caused by the failure of its programmable computing device, for data exchange between the controller and the bus, designed to input or output a signal from the module, for whereby the controller is connected to the main area of local memory and to the additional area of local memory by separate bus groups. Then, data is exchanged between the device modules in the form of a control packet consisting of overhead data or an information packet consisting of a control packet and a data packet. And when transmitting a packet from an interface unit configured for operation in the master mode, a code is entered into the service data defining which of the local memory areas of the interface unit configured for operation in the mode of the slave device data is transmitted.

The technical result in the second invention is achieved by the fact that the communication system for transmitting data on the bus contains interface units connected to the bus. One of the interface units is configured to operate in master mode and at least two interface units are configured to operate in slave mode. The interface unit configured to operate in the master mode contains a descriptor list handler, a DMA controller, a controller, and local memory for storing descriptors, according to which a descriptor list handler manages the DMA controller and controller, and is designed to temporarily store useful data exchanged between interface units. And each interface unit configured to operate in slave mode contains a controller, the main area of local memory and an additional area of local memory, while the inputs / outputs of the controller are connected by the first group of buses to the inputs / outputs of the main local memory and connected by the second group of buses to the inputs - outputs of additional local memory.

The technical result in the third invention is achieved in that the automatic protection device comprises modules connected to a common bus of the trunk type. Each module contains a programmable computing device and an interface unit. At least one of the modules comprises an interface unit configured to operate in master mode, and at least two modules comprise interface units configured to operate in slave mode. Each interface unit, configured to work in slave mode, contains a controller, the main area of local memory, which is used during the normal operation of the module for data exchange between the controller and the programmable computing device, and an additional area of local memory, which is used when fixing abnormal operation of the module, caused by the failure of its programmable computing device, for data exchange between the controller and the bus, designed to input or output a signal from the module, for whereby the controller is connected to the main area of local memory and to the additional area of local memory by separate bus groups.

For the subsequent description of the possibility of implementing the inventive method of data transfer, communication systems and automatic protection devices, the following drawings are given:

FIG. 1 is a block diagram of a device whose modules exchange data;

FIG. 2 is a block diagram of the functional blocks of an integrated circuit of the type SoC;

FIG. 3 is a general block diagram of an SF block designed to operate in three modes: “Lead” mode, “Slave” mode, and “Monitor” mode;

FIG. 4 is a block diagram of an SF block in the “Lead” mode, on which lines show data transmission streams (control signals are not shown);

FIG. 5 is a structural diagram of an SF block in the “Slave” mode, in which lines indicate data flows (control signals are not shown);

FIG. 6 - transmission of logical zero and one in the code "Manchester-2";

FIG. 7 - the clock signal of the data packet and the clock signal of the control packet;

FIG. 8 - data packet structure (DATA);

FIG. 9 is a control packet structure (CTRL);

FIG. 10 - structure of the information package (CTRL + DATA);

FIG. 11 shows the structure of the Control word field of a control packet (CTRL) for a write request or a request for reading data;

FIG. 12 shows the structure of the “Control word” field of a control packet (CTRL) in response to a write request or a data read request;

FIG. 13 - message format "data recording in the slave device";

FIG. 14 - message format "broadcast message";

FIG. 15 - message format "reading data from the slave device";

FIG. 16 - message format “inability of the slave device to issue the requested data”;

FIG. 17 is a simplified structural diagram of an industrial controller designed for emergency automatic protection of the control object.

In FIG. 1 shows a device 1 in which modules 2, 3, 4 (eng. Module CPU, module I / O) are connected to a common communication line (hereinafter bus 5) of the “trunk” type. In order for data to be exchanged between the modules on bus 5, each of them must contain an interface block 6, 7, 8 (Eng. Interface block), designed for software and hardware implementation of the data exchange protocol. Moreover, it is sufficient that at least one of the modules contains an interface unit 6 operating in the “Lead” mode (hereinafter the master device) (eng. Master), and at least two modules contain interface units 7 operating in the “ Slave ”(hereinafter referred to as slave) (eng. Slave). The device 1 also contains a module 9 with an interface unit 10 operating in the “Monitor” mode (eng. Monitor), designed to “listen” for traffic on the bus 5. In an industrial controller, such a module can be a backup CPU module. But only one of the two redundant CPU modules can be active at a time. When a CPU module with an interface unit operating in the "Lead" mode fails, another CPU module with an interface unit operating in the "Monitor" mode takes over the initiation of data exchange via the bus.

As the interface unit 6, 7, 8, 10, the peripheral interface interface SF block 11 SoC 12 described below, or the peripheral interface unit in the integrated circuit, or a separate device on the board, can be used.

For data exchange, M-LVDS can be used - the technology of low-voltage differential transmission of low-voltage signals described in the international industrial standard TIA / EIA-899-2002 (Electrical Characteristics of Multipoint-Low-Voltage Differential Signaling (M-LVDS) Interface Circuitsfor Multipoint Data Interchange). The Multipoint LVDS standard (abbreviated M-LVDS) is designed for multi-point bidirectional information exchange. To do this, carry out half-duplex data transfer on one bus 5.

Addressed on the bus 5 to 255 modules (and one address for broadcast exchanges). Position 13 shows transceivers.

The composition of SoC varies depending on its functional purpose. Typically, SoC 12 (Fig. 2) contains the following main functional blocks: one or more central cores 14 (eng. CPU core) (hereinafter CPU), system random access memory 15 (hereinafter RAM) (eng. RAM), peripheral interface units 11 ( Interface blocks), a memory controller 16 (eng. MS), designed to control the input of configuration data and program code from external flash memory 17 (eng. Flash memory). The main functional blocks of the SoC are interconnected by a block (s) of 18 interconnects (eng. INTERCONNECT UNIT (S)).

CPU 14 is a programmable computing device designed to process data and to control the overall operation of SoC. Work SoK 12 is supported by system software.

The SF block (Fig. 3, 4, 5) provides data transfer in accordance with the protocol described in the application.

The hardware and software design of the interface unit depends on the protocol for which it is intended and the special requirements for it. One of the problems faced by developers of interface units is to automate the process of exchanging data between device modules as much as possible and, thereby, free up CPU resources for other work. To do this, the interface devices are equipped with additional devices that could take the load from the CPU to control the bus and execute a programmed sequence of messages on the bus. Another problem facing front-end device developers is the provision of deterministic data access time to the bus.

The SF block described below uses solutions that solve the problems described above.

The SF unit 11 can operate in one of three modes: “Lead”, “Slave”, “Monitor”.

SF block 11 (Fig. 3) contains:

- handler 19 of the list of descriptors (hereinafter OSD);

- DMA controller 20;

- an array of control and status registers 21;

- controller 22;

- module 23 converting a serial code into a parallel one and vice versa (in the figures, a code conversion module);

- the main area of local memory 24, in particular RAM;

- an additional area of local memory 25, in particular RAM.

The structure of the SF block includes multiplexers (not indicated by the position). The control registers contain the settings of the SF block. Status registers contain status flags of the SF block and error codes of operations on the SoC system bus. DMA controller 20 is designed to exchange data between the main area 24 of the local memory of the SF unit and the system RAM of the SoC. The data exchange of the SF block with the main functional blocks of the SoC is carried out on the system buses AXI 26 (in the “Lead” mode) or ARV 27 in (the mode “Slave”). The system bus ARV 27 is used to initialize the SF block, regardless of its operating mode. In FIG. 3, 4, 5, a tire 5 is shown, which in FIG. 1 shows how the bus to which the modules of device 1 are connected. The SF unit can work with one bus 5 (shown in the figures), and supports working with duplicated buses 5.

To clearly identify the main area of local memory 24 (hereinafter referred to as main memory) and the additional area of local memory 25 (hereinafter referred to as additional memory), the following should be considered:

- Each of the memory areas has its own functional purpose. The main memory 24 is used for data exchange during normal (regular) operation of the modules of the emergency automatic protection device (hereinafter referred to as the protection device). Such data exchange is intended to be performed by the protection device for its direct purpose - to collect signals from sensors in order to control technological parameters important for the safe state of the control object, process these data according to programmed algorithms and, if the process parameters exceed the maximum permissible values, transfer the control object to safe condition.

Additional memory 25 is used during abnormal operation of the protection device, in which the inoperative state of the input module or output module is recorded.

- The operation of reading or writing data from the primary (Primary memory space) and secondary (Secondary memory space) memories is performed on their individual (different from other) buses. So the controller 22 can redirect the data stream from the bus 5 both to the main memory 24 and to the additional memory 25. For this, the inputs / outputs of the controller 22 are connected by the first group of buses 28 and 29 with the inputs and outputs of the main memory 24, and the inputs and outputs of the controller 22 are connected by a second group of buses 30 and 31 to the inputs / outputs of the additional memory 25. The bus 32 is used to input or output a signal from the SoC, for which the bus 32 connects the inputs and outputs of the additional memory 25 with the physical conclusions of the SoC. The bus 32 can connect the inputs and outputs of the additional memory 25 and with other functional blocks of the SoC, which in turn are designed to input or output a signal from the SoC.

The spatial arrangement of the primary and secondary memories relative to each other can be any.

Main memory 24 has a capacity of 8 KB with an organization of 2048 × 32. Depending on the operating mode of the SF block, the main memory has a different organization.

In the "Lead" mode (Fig. 4), a table 33 of descriptors and a buffer 34 for data are located in the main memory 24. The data buffer 34 is intended for temporary storage of data to be transmitted via bus 5 and received from bus 5. The descriptor determines the execution of each transaction on bus 5 and the initiation of periodic data exchanges between the main memory 24 and the system random access memory.

Table 33 descriptors contains:

- control information for forming a transaction on the bus;

- address of the data buffer in the system memory;

- result of the transaction (updated after the transaction).

In the descriptor table, the system software writes such data as slave addresses, address space numbers, address space sizes, the polling period of a specific address space of a particular slave device, operation (read / write), local memory area (main memory or additional memory), interrupt mask by the end of the bus data exchange from the current descriptor and the period of the exchange cycle.

* Reserve (hereinafter in the text) is a sign of reserved bits, the logical value of which the developer can set independently.

* ADP (hereinafter referred to as the text) is a bit of the sign of adaptive reading of useful information. Changing the value of this bit is possible in the message type “reading data from the slave device”. The value of this bit sets the slave in the response information packet, if the actual size of the useful data in the local memory is less than the master requested.

In master mode, additional memory 25 is not used.

In the “Slave” mode, local memory contains lines for the description of address spaces and the address spaces themselves, in which useful data is stored.

OSD 19 performs word processing from the descriptor table, controls the operation of the DMA controller 20 and the operation of the controller 22.

The controller 22 implements the logic of the modes of operation "Master", "Slave" or "Monitor". The controller 22 transmits data between the code conversion unit 23 and the main memory 24 or additional memory 25, generates control packets, and updates statistics registers.

The operation of the SF block 11 in the "Lead" mode (Fig. 4): the system software generates a table of 33 descriptors in the main memory 24 and configures the SF block. Upon launching the OSD 19, it sequentially subtracts and processes the descriptors from the descriptor table 33. According to the "Control Information" from the descriptor, the OSD 19 gives the appropriate commands to the DMA controller 20. In parallel with this, the OSD 19 gives the appropriate commands to the controller 22 to generate transactions for writing or reading data to the slave. Upon receipt of such a command, the controller 22 performs a sequence of actions corresponding to the type of request.

In the case of writing data to the slave, the following actions are performed: using the DMA controller 20, the data received on the AXI 26 system bus is loaded into the buffer 34 of the main memory 24. The controller 22 reads the data from the buffer 34 and transfers them to the bus 5. Upon completion the controller 22 informs the OSD 19 of the data transmission and enters the standby mode of the new command. After the processing of the "Control Information" descriptor is completed, OSD 19 updates the "Transaction Result" descriptor and proceeds to processing the next descriptor. Thus, the following data flow can be traced: system bus - DMA controller - main memory buffer - bus controller - bus.

In the case of reading data from the slave, the following actions are performed: the controller 22 reads the data from the bus 5 and transfers it to the buffer 34 of the main memory 24, from where, using the DMA controller 20, the data are transferred to the AXI 26 system bus. After the processing of the “Control information” descriptor is completed "OSD 19 updates the descriptor" Transaction Result "and proceeds to processing the next descriptor. Thus, the following data flow can be traced: bus - bus controller - local memory buffer - DMA controller - system bus.

Thus, the system software at the beginning of operation once initializes the SF block, after which the SF block without the intervention of the system software performs each cycle of data exchange on the bus, transferring the received data to the SoC system memory. Thus, it is possible to automate the operation of the SF block and, thereby, unload (release) the resources of the central processor of the SoC for other work.

When the SF block is operating as the master device, the OSD 19 access to the descriptors takes 1 clock cycle. This provides a deterministic time for receiving a task (control information), which is of great importance for real-time systems.

After the processing of the descriptor table is completed, an interrupt may be generated, after which it is possible to update the descriptor table data with system software.

The operation of the SF block 11 in the “Slave” mode (Fig. 5): The SF block in the “Slave” mode implements the logic of access to its address spaces by means of requests via the bus. The system software at the beginning of operation once initializes the SF block, after which the write or read transactions are carried out automatically without the participation of the system software. Access to the main memory 24 is possible only through the system bus ARV 27. In the slave mode, the OSD 19 is not active and data exchange via the DMA controller 20 is not available. Upon start-up, the controller 22 awaits the signals for receiving the control / information packet from the code conversion module 23, after which it processes the packet and accesses the main 24 (Primary memory space) or additional (Secondary memory space) 25 memory at the address from the control packet. The memory space contains a description of the requested address space intended for useful data. One of the "Memory address" description fields is the address of the first data word in the address space of the memory. If the request was for recording, then the incoming data is recorded at this address. If the request was for reading, then data is read from this address. After the processing of the request is completed, an interrupt can be caused by which data is updated by the system software.

Operation of the SF block in the "Monitor" mode: The SF block in the "Monitor" mode performs the function of writing to the system memory all traffic going on the bus 5. Control packets and data packets are recorded. Each packet coming from bus 5 is supplemented with a special descriptor coming in front of the data and is written to system memory. In this case, only information words are recorded, the words CRC are discarded. Only those packets are recorded in the memory when receiving which there were no errors. If errors occur during the reception process, the received packet is discarded and the corresponding flag will be set. Work in the "Monitor" mode is similar to work in the "Lead" mode using extraordinary descriptors.

In the "Monitor" mode, the OSD 19 has the same functionality as in the "Lead" mode.

In the SF block, it is possible to change the CRC length (register of CRC length of the polynomial), the initial value of CRC (register of the initial value of CRC) and the polynomial CRC (register of CRC value of the polynomial) in the mode described in the TSI protocol application.

All information on the bus is transmitted in the Manchester-2 code (Fig. 6). This bipolar phase-shifted code has a zero constant component, which is very important in applications with a high transmission rate. The coding of 0 and 1 is performed not by the level, but by the signal front in the middle of the clock interval (Fig. 6), which allows for bit-wise synchronization of the transmitter and receiver according to the transmitted information in a wide range of carrier frequency deviations. Two types of clock signal are defined (Fig. 7), which allow hardware, therefore, to quickly determine and distinguish the beginning of the data packet from the control packet.

A data packet (DATA) (Fig. 8) has the format of one or more 32 bit data words, which ends with a 32 bit control word. In front of them is a clock signal, the polarity of the first half of which is negative, and the second half is positive. Data words (useful information) - actually the data exchanged between the modules and for the transfer of which a data packet is used. The CRC-32 checksum word is intended to verify the integrity of all data transmitted in a packet. The calculation of CRC-32 is used.

Checksum (CTRL) (Fig. 9) has a format of 32 bit information word and 32 bit checksum word. In front of them is a clock signal, the polarity of the first half of which is positive, and the second half is negative. The control packet may perform the function of beginning and end of a communication session, acknowledging the receipt of an information packet or requesting an information packet.

A packet (FIG. 10) including a control packet and a data packet is called an information packet (CTRL + DATA).

When the master device requests to read or write data to the slave, a control or information packet is sent, the service information of which contains the "Primary / Secondary memory space" field - a field with the identifier code of the used main or additional memory (Fig. 11).

Upon the request of the master device for reading or writing data, the slave device sends a response control or information packet, the service information of which contains the field "Validity of a received message" - a field of signs of reliability of the received packet or status signs of the slave device (Fig. 12), which makes it possible obtaining various diagnostic information.

Consider the possible message formats exchanged between the master and slave devices by transmitting control and information packets to each other:

- Format 1 "data recording in the slave device" (Fig. 13).

- Format 2 "broadcast message" (Fig. 14).

- Format 3 "reading data from the slave device" (Fig. 15).

- Format 4 "the inability of the slave to issue the requested data when reading data from the slave" (Fig. 16).

Consider the message formats (Fig. 13-16) between the master and slave electronic devices.

Format 1 is intended for data transmission from the master to the slave - "data recording in the slave" (Fig. 13). The master transmits an information packet (CTRL + DATA). The slave device receives the information packet, calculates the checksums (CRC-32) of the 32-bit service information word and the 32-bit data word (words) (useful information) and compares their values with the checksums received from the master. Depending on the result of the checksum comparison, the slave device either ignores the write request or accepts it for execution. In any case, the slave device transmits the response control packet (CTRL) to the master, in which the [2: 0] bits of the “control word” (table 7) have values corresponding to the reliability characteristics of the received packet.

Format 2 is designed to transmit data from the master device to all slave devices - "broadcast message" (Fig. 14). The master device transmits an information packet (CTRL + DATA) (in the "Terminal address" field 0xFF is the broadcast address), and the slave devices receive the information packet, calculate the checksums (CRC-32) of the 32-bit service word and the 32-bit word ( words) of data (useful information) and compare their values with the values of the checksums received from the master. Depending on the result of the checksum comparison, the slaves either ignore the write request or accept for execution. In this message format, the master does not expect a “response packet” from the slaves after transmitting the information packet.

Format 3 is intended for receiving data from the slave device by the master device - “reading data from the slave device” (Fig. 15). The master sends the control packet (CTRL) to the slave and frees the bus. The addressed slave device receives the control packet, calculates the CRC-32 checksum of the 32-bit overhead word and compares its value with the checksum value received from the master. Depending on the result of the checksum comparison, the slave device either ignores the read request or accepts it for execution. Upon successful comparison, the slave device captures the bus and transmits the response information packet (CTRL + DATA) to the master. The master device receives a response information packet from the slave device and calculates CRC-32 checksums of the 32-bit service information word and data (useful information) words (words) and compares their values with the checksums received from the slave device. Upon successful comparison of checksums, the information packet is considered accepted - the reading of data from the slave is completed.

Format 4 "it is impossible to issue the requested data" (Fig. 16) is a special case of format 3, in which "reading data from the slave device" occurs. The master sends a control packet (CTRL) to the slave. The slave device receives the checksum, calculates its checksum and compares its value with the value of the checksum received from the master. If the checksums do not match, the slave device ignores the read request and transmits the response control packet (CTRL) to the master, in which the [2: 0] "control word" bits (table 7) have values corresponding to the reliability signs of the received packet.

An example of the use of inventions

The use of the tools and methods of the proposed interface is proposed to be considered on the example of the operation of the controller with programmable logic 35 (hereinafter PLC) (eng. PLC), which is used as an emergency automatic protection device (Fig. 17).

It should be understood that the embodiment described here is used only to explain the present invention and is not used to limit the scope and scope of the invention, which can be used in robotics, medicine, automobile or rail transport.

The interface tools described in the application, including the TSI protocol, can be used in the PLC to exchange data on the internal bus and to enable the control signal to be switched off at the PLC output when diagnosing a failure of a programmable computing device (microcontroller, microprocessor, SoC cores) in the output module signals in order to prevent an emergency (dangerous) situation at the control object.

PLC 35 contains a central processor module 36 (hereinafter referred to as the CPU module) (eng. Module CPU) and input / output modules 37 (eng. I / O modules), designed to work with various types of signals: input signals of thermocouples and resistance thermocouples; input and output of unified analog signals of the middle level; input and output of discrete signals. In FIG. 17 also shows the equipment of control object 38: instrumentation — sensor 39 and actuators — engine 40 and valve 41.

When describing the operation of the PLC, the following concepts and conditions used in this application should be stipulated:

- This application describes the operation of a PLC that does not have redundant and duplicated elements. Therefore, in case of malfunctioning of the elements, measures must be taken to disable the control signal at the output of the PLC. This will lead to the fact that the contacts of the contactor 42, through which power is supplied to the actuators, are opened. This, in turn, will lead to the fact that the control or shut-off valve 41 will occupy a safe position for the process, and the engine 40 will be stopped.

- The process of emergency protection of the control object requires continuous measurement of technological parameters. One iteration, including the measurement of a technological parameter, its calculation and the generation of effects on actuators, is called the PLC duty cycle. The operation of the PLC consists of constantly repeating the sequence of actions included in the duty cycle.

- Industrial PLCs are real-time systems. The correct functioning of real-time systems is determined not only by the correctness of the calculations, but also by the time for which the desired result is obtained - the reaction time. If the calculations are performed incorrectly or the time requirements are not met, then it is considered that a failure has occurred.

The CPU module 36 contains the following functional blocks: an interface unit 43 operating in the “Lead” mode (Eng. Interface block MASTER), RAM 44 (Eng. RAM), a programmable computing device 45 (Eng. CPU) (hereinafter referred to as the CPU) and flash memory 46 (eng. Flash).

Input module 47 contains the following functional blocks: an interface unit 48 operating in the “Slave” mode (eng. Interface block SLAVE), programmable computing device 49 (eng. CPU) (hereinafter CPU), RAM 50 (eng. RAM), input unit - output 51 (eng. I / O block) and flash memory 52 (eng. Flash). In FIG. 17 schematically shows only the elements of the PLC and interface unit 48 necessary for the disclosure of inventions, namely, the controller 53 and the main memory 54. The input-output unit 51 is designed to input signals via the measuring bus 55 from sensors 39 that control parameters important for the safe state of the control object.

Output module 56 contains the following functional blocks: an interface unit 57 operating in the “Slave” mode (eng. Interface block SLAVE), programmable computing device 58 (eng. CPU) (hereinafter CPU), RAM 59 (eng. RAM), input unit -Output 60 (eng. I / O block) and flash memory 61 (eng. Flash). In FIG. 17 schematically shows only the devices of the interface unit 57 necessary for the disclosure of inventions, namely, the controller 62, the main memory 63 and the additional memory 64. The output module 56 may contain a logical element And 65 and a key 66 in the power circuit 67.

The contactor 42 is controlled via relay 68. The voltage (24 V) is supplied to relay 68 with the switch 66 closed in the power supply circuit 67. Key 66 is controlled via control bus 69.

It should be noted that the interface blocks 43, 48, 57, CPU 44, 49, 58, RAM 44, 50, 59 and I / O blocks 51, 60 can be either functional blocks of SoC 12, or separate devices on the board.

Communication system operation during initialization

During the initialization process, a set of parameter values is determined that determines the operation of interface units (SF blocks of SoC). For each of the three operating modes of the interface unit, the initialization is different.

The information necessary for initialization is determined by the user during the design process and is loaded into the flash memory during the configuration process. When the power is turned on, the contents (program code and initialization data) of the flash memory are automatically loaded into the RAM memory associated with the CPU. During initialization, the system software once determines the operation of the interface unit in the “Lead” mode, or in the “Slave” mode, or in the “Monitor” mode, for which the control registers of the block are loaded, in which the necessary interrupts, timings and bus cycle time are set taking into account the clock unit operation frequencies. At the same time, a descriptor table is written to the interface unit, which will operate in the “Lead” mode, in the main memory. After this, the operation of reading or writing data on the bus can be carried out automatically without the participation of system software.

The standard mode of operation of the protection device

Before starting the PLC, all PLC modules are configured (setting up network interfaces, input / output systems, diagnostic services, setting the system time and its synchronization mode, as well as some other parameters and system services). After a PLC reboot, its modules start working in normal (normal) mode.

Before describing the operation of the PLC in the normal (normal) mode, it is necessary to describe the operation of the And 65 logic element. When the And 65 logic element is input via the main bus 70 of the signal B ₁ = 1 (high level) and through the additional bus 71 of the signal B ₂ = 1 (high level), at the output of AND gate 65, a signal B ₃ = 1 (high level) will be issued on the control bus 69. Before the PLC starts to perform cyclic work, an information packet is sent to the output module 56 from the CPU module 36 to the output module, in the service data of which an additional memory (Secondary memory space) 64 of the interface unit 57 of the output module 56 is indicated. This is done so that from the additional memory 64 via the additional bus 71, which directly connects the additional memory 64 and the logical element AND 65, send the signal В ₂ = 1 (high level) to the logical element And 65. The presence of such a signal at the input of the AND gate 65 allows when applying on the main bus B ₁ signal 70 = 1 (high level) to receive on the control bus 69 signal V ₃ = 1 (high level), which closes the switch 66.

During normal operation, the sensor 39 receives a signal through the measuring bus 55 to the input-output unit 51, where it is converted to a digital format and digitally transmitted to the input of the CPU 49, from where the data are transferred to the main memory 54 of the interface unit 48. To obtain data from input module 47, the interface unit 43 of the CPU module 36 transmits to the bus 5 a control packet with the address of the input module 47, with the main memory 54 and a request for reading data. The interface unit 48 receives a control packet, checks it for the accuracy of the information received, and then transmits a response information packet to the CPU module 36. The received response information packet in the interface block 43 of the CPU module 36 is checked for validity of the received information, after which the useful data is written to the local memory buffer of the interface block 43. The CPU 45 of the CPU 36 module continuously receives the executable code of the application program, which is an arithmetic or logical operation, from RAM 44 and extracts the current data transferred to RAM 44 from the local memory buffer of the interface unit 43. The result of data operations is again transmitted from the CPU 45 to RAM 44, from where it is transmitted to the local memory buffer of the interface unit 43. Then an information packet is generated, the service data of which contains the address of the output module 56 and an indication that the data should be recorded in the main memory (63). The interface unit 43 of the CPU 36 transmits an information packet to the bus 5. The interface unit 57 of the output module 56 receives the information packet and checks it for the reliability of the information received, after which the data is recorded in the main memory 63, and the response control packet is sent to the CPU module 36. Data from the main memory 63 is transmitted by the CPU 58 to the input-output block 60, from where the signal is sent to the AND gate 65 via the main bus 70. In the case when the value of the parameter measured by the sensor 39 corresponds to the normal values of the technological process, an information module will be sent to the output module 56 a packet with data, the conversion of which will give a signal B ₁ = 1 (high level) on the main bus 70, which will lead to the closing of the key.

In the case when the value of the measured parameter exceeded the maximum permissible value, an information packet with data will be sent to the output module 56, the conversion of which will give a signal B ₁ = 0 (low level) on the main bus 70, which will lead to the opening of the key.

Abnormal operation mode of the protection device

Abnormal operation of the protection device can be caused by a large number of factors. Next, an abnormal operation mode caused by a failure of the CPU 58 of the output module 56 will be described. If we consider the above-described regular operation of the output module 56, in which the CPU 58 transferred data from the main memory 63 to the input-output block 60, then the “hung” or faulty CPU 58 It will not transmit the next data that would allow changing the signal level in the main bus 70. The CPU 58 is signaled by the CPU activity counter (eng. Life bit counter), the value of which increases by one, in case of successful data transfer by the CPU 58. Data counters and they are transmitted in a response control packet, which allows the CPU module 36 to judge the operational state of the CPU 58 of the output module 56. If the counter has not changed, which indicates a failure of the CPU 58, the CPU module 36 detects a failure of the CPU 58 in the output module 56 and forms an information package, which contains an instruction to write data to the additional memory 64 of the output module 56. Writing data to the additional memory 64 will allow you to change the signal level in the additional bus 71. So, if we assume that before starting the PLC cycle in addition tion bus signal was a ₂ = 1 (high level), it should be changed to a signal V ₂ = 0 (low level). This will lead to a change in the signal B ₃ = 0 on the control bus 69 and the opening of the key 66, regardless of the state of the signal B ₁

An additional bus 71 can be output to the physical output of the microcircuit, and, for example, send a signal to the key in the power circuit of the alarm lamp, which will signal a failure of the computing device of the output module.

Also, additional memory in the interface unit can be used in the event of a CPU 49 failure in input module 47 to remove a signal from a discrete sensor.

Claims (7)

1. A method of transmitting data via a bus, which consists in sequentially transmitting data on a bus between the modules of a device for automatically controlling or protecting a control object, each of the modules contains a programmable computing device and an interface unit, at least one of interface units are configured for operation in master mode and at least two interface units are configured for operation in slave mode, after which they exchange yes between the device modules in the form of a control packet consisting of overhead data or an information packet consisting of a control packet and a data packet, characterized in that each interface unit configured to operate in slave mode contains a controller, the main area of local memory, which is used during standard operation of the module for data exchange between the controller and the programmable computing device, and an additional area of local memory, which is used when fixing non-standard the operation of the module caused by the failure of the programmable computing device for data exchange between the controller and the bus, designed to input or output a signal from the module, for which the controller is connected to the main area of local memory and to the additional area of local memory by separate bus groups, and when transmitting a packet from the interface unit configured for operation in the host mode, a code is entered into the service data defining which of the local memory areas of the interface unit configured for To operate in slave mode, data is transmitted. 2. A communication system for transmitting data via a bus, comprising interface units connected to the bus, wherein one of the interface units is configured to operate in a master device mode and at least two interface units are configured to operate in a slave mode, characterized in that the interface unit configured to operate in master mode contains a descriptor list handler, a DMA controller, a controller and local memory for storing the descriptors, according to which the list handler descriptors controls the DMA controller and the controller, and is designed to store useful data, and each interface unit configured to operate in slave mode contains a controller, the main area of local memory and an additional area of local memory, while the inputs and outputs of the controller are connected first a group of buses with inputs and outputs of the main area of local memory and are connected by a second group of buses with inputs and outputs of an additional area of local memory. 3. A communication system for transmitting data on a bus according to claim 2, characterized in that in addition one of the interface blocks of the communication system is configured to operate in monitor mode and contains a descriptor list handler, a DMA controller, a controller and local memory for storing descriptors , according to which the descriptor list handler manages the DMA controller and the controller, and is designed to store data. 4. An automatic protection device containing modules connected to a common bus of the "trunk" type, each of which contains a programmable computing device and an interface unit, while at least one of the modules contains an interface unit configured to operate in the master device mode, and at least two modules contain interface units configured to operate in slave mode, characterized in that each interface unit configured to operate in slave mode contains a control er, the main area of local memory, which is used during regular operation of the module for data exchange between the controller and the programmable computing device, and the additional area of local memory, which is used when fixing abnormal operation of the module caused by a failure of the programmable computing device, for data exchange between the controller and the bus designed to input or output a signal from the module, for which the controller is connected to the main area of local memory and to the additional area locally memory in separate bus groups. 5. The automatic protection device according to claim 4, characterized in that the interface unit can be made in the form of an interface unit of an integrated circuit or a separate device on the board. 6. The automatic protection device according to claim 5, characterized in that the interface unit, designed to operate in the master device mode, contains a descriptor list handler, a DMA controller, a controller, and local memory for storing the descriptors, according to which the list handler descriptors controls the DMA controller and the controller, and is designed to store data. 7. The automatic protection device according to claim 4, characterized in that the programmable computing device is made in the form of a microprocessor (processor) or microcontroller or in the form of one or more cores of an integrated circuit of the system-on-chip type.

Images