User guide

1. Introduction
1.1. Application area………………………………………………………………. 3
1.2. Short description opportunities……………………………………………………………..... 3
1.3. User level………………………………………………………... 3

2. Purpose and conditions of use of the automated process control system “VP”……………………………………. 4

3. Solution of the automated process control system “VP”………………………………………………………. 5

4. Starting the system………………………………………………………………..……… 6

1. Introduction.

1.1. Application area

The requirements of this document apply when:

· preliminary comprehensive tests;

· trial operation;

· acceptance tests;

· industrial operation.

1.2. Brief description of features

The “Weight Flow” software product is designed for analytical work, automation and optimization of document flow processes and interdepartmental logistics of various departments of the enterprise. The system also provides the ability to quickly monitor and adjust the operation of technical processes at enterprises associated with the use of weighing equipment in elevators, nave and gas storage facilities, railway freight stations and other industrial facilities.

Software and hardware - software package ACS TP "Weight Flow" have a modular structure.

When working with reporting, the following are often used: OLE 1C software with an online synchronization function (allows the initiation of weighing from the accounting system) and SAP RFC software with an online synchronization function (generates weighings into the accounting system), which provides the following:

· checking the possibility of vehicle passage to the territory of the enterprise;

· creating a document in 1C on the fact of vehicle weighing at the enterprise;

· return of data on the balance of funds in the counterparty’s account in the 1C system;

· search for a document by vehicle number and return the document number. If there are several documents, the output order is determined by the developer; the function always returns one document;

return information about the document; return directory element; entering the weight of the goods into the document; issuing a list of documents as of date.

1.3. User level

The user must have experience working with MS Windows OS (95/98/NT/2000/XP, XP-7), skill in working with MS Office, and also have the following knowledge:

· know the relevant subject area;

· know the operating principle of truck scales;

· be able to connect peripheral devices.

2. Purpose and conditions of use of the automated process control system "VP".

Dispatching of production, transport, roads, successfully applied in many areas of activity, from commercial roads and crossings, automatic parking, to automation of the gas production industry.

The software and hardware complex of the automated process control system "Weight Flow" is designed for automation of industrial weighing systems (vehicle scales, railcar scales, etc.) and document flow, configuration taking into account the industry of the enterprise and accounting features.

All systems have the ability to easily integrate into other systems, for example, accounting systems (1C, Turbobukhgalter, SAP, BAAN, etc.) The systems are also equipped with a remote/remote control option. All our projects include the most advanced and unique software and hardware solutions using RFID technologies (radio frequency identification), active and passive.

The automated process control system "Weight Flow" includes the installation of security and video surveillance systems, access control systems at industrial facilities for various purposes and any level of complexity, with their integration into the enterprise’s technological processes and document flow, as well as the use of modern RFID technologies (active/passive).

3. Solution of the automated process control system “VP”

Typical options for completing automated process control systems “Weight Flow”

Event identification options. “Event” is an important component that allows you to organize the operation of the system without a person, which eliminates the “risks” associated with the activities of dishonest employees.

1. Intelligent video analytics - recognition system for vehicles, vehicle numbers/wagons/containers;
2. RFID - radio frequency identification (active or passive);
3. Various sensors - induction, thermal sensors;
4. Human input of event data

Actuators: - any digital devices whose design includes connection ports (COM USB, RS 232/485, IP network, etc.);
- any analog devices with on/off functions (traffic lights / engines / light bulbs / barriers / dampers, etc.);
- digital sensors / analyzers, electronic and with dry contacts.

Software components of automated process control system "VP"
We have several APCS modules - their functionality is described briefly in the specification, in more detail in the manual. Below are the main software components of the “Weight Flow” Process Control System. Each module has certain basic functions:

1. Server - APCS software "Weight Flow"
Central north of scales (WEB, SQL, URDB)

2. Weighing program - automated process control system "Weight Flow" Auto weighing/railway weighing module
3.Usage various devices- ACS TP "Weight Flow" Controller module +
in system

4. Adjustments, visible/invisible - automated process control system “VP” Module Laboratory

5. Additional workplace- ACS TP “VP” Module additional workplace
(possibility of connecting remotely or via network to the automated control workstation)

4. System startup

https://pandia.ru/text/80/223/images/image002_125.jpg" width="672 height=361" height="361">

Rice. 2. Interface of automated process control system “Weight flow”

Interface consists of the following elements:

1.Navigation menu. Serves to configure and manage the system.

2.Buttons for switching between scales. Serve to switch the display of the status of different scales and indicate the currently active scales if more than one scale is connected to the system.

3.Operator menu. Serves to manage weighing, documents and access control system. Switches the appearance and functions of the operator panel.

4.Operator panel. Serves to manage weighing, documents and access control system. Appearance and functions depend on the currently selected tab in the operator menu (position 3). When the system starts, the scale control panel is displayed (as in Fig. 2).

5.Calendar. Serves to select weighing results displayed on the weighing protocol panel (position 7) by date and display the current date.

6.Button “Record document”. Used to create a new document.

7.Weighing protocol panel. Serves to display weighing results for a specific date selected in the calendar (position 5).

8. Video panel. Displays video broadcast from CCTV cameras.

Navigation menu(Fig. 3) is located in the upper left corner of the monitor and consists of the following sections: “File”, “Configuration”, “Modules”, “Windows”, “About the program”.

https://pandia.ru/text/80/223/images/image004_81.jpg" align="left" width="120" height="76">

Rice. 4. Menu "File".

Menu "Configuration" (Fig. 5)

Provides access to system service parameters

"Print plate designer" - serves for registration of document layouts

"System settings" - serves to configure the system in accordance with the required parameters

https://pandia.ru/text/80/223/images/image006_48.jpg" align="left" width="171" height="92 src=">

Rice. 6. Menu "Modules".

Menu "Window" (Fig. 7)

Displays a list of open windows and allows you to switch between them

https://pandia.ru/text/80/223/images/image008_40.jpg" width="675 height=356" height="356">

The exchange of information between devices that are part of an automated system (computers, controllers, sensors, actuators) generally occurs through industrial network(Fieldbus, "field bus") [Cucej].

• LAN(Local Area Network) - networks located in a limited area (in a workshop, office, within a plant);
• MAN(Metropolitan Area Networks) - networks of cities;
• WAN(Wide Area Network) - a global network covering several cities or continents. Typically, Internet technology is used for this.

Currently, there are more than 50 types of industrial networks (Modbus, Profibus, DeviceNet, CANopen, LonWorks, ControlNet, SDS, Seriplex, ArcNet, BACnet, FDDI, FIP, FF, ASI, Ethernet, WorldFIP, Foundation Fieldbus, Interbus, BitBus, etc. .). However, only some of them are widespread. In Russia, the vast majority of automated process control systems use Modbus and Profibus networks. In recent years, interest in networks based on CANopen and DeviceNet has increased. The prevalence of one or another industrial network in Russia is connected, first of all, with the preferences and activity of Russian companies selling imported equipment.

2.1. General information about industrial networks

Industrial network called a set of equipment and software, which provide information exchange (communication) between several devices. Industrial network is the basis for building distributed data collection and control systems.

Since in industrial automation network interfaces can be an integral part of the connected devices, and the OSI model application layer network software is executed on the main processor of the industrial controller, it is sometimes physically impossible to separate the network part from the devices being networked. On the other hand, changing from one network to another can often be accomplished by changing the network software and network adapter or introducing an interface converter, so often the same type of PLC can be used in different types of networks.

The connection of an industrial network with its components (devices, network nodes) is carried out using interfaces. A network interface is a logical and (or) physical boundary between a device and the information transmission medium. Typically this boundary is a set of electronic components and associated software. With significant modifications to the internal structure of the device or software, the interface remains unchanged, which is one of the features that makes it possible to distinguish the interface as part of the equipment.

The most important parameters of the interface are the bandwidth and the maximum length of the connected cable. Industrial interfaces usually provide galvanic isolation between the connected devices. The most common serial interfaces in industrial automation are RS-485, RS-232, RS-422, Ethernet, CAN, HART, AS-interface.

To exchange information, interacting devices must have the same exchange protocol. IN simplest form A protocol is a set of rules that govern the exchange of information. It defines message syntax and semantics, control operations, synchronization, and communication states. The protocol can be implemented in hardware, software, or firmware. The name of the network usually coincides with the name of the protocol, which is explained by its decisive role in the creation of the network. In Russia, network protocols are used, described in a series of standards [GOST - GOST].

Typically, a network uses several protocols that make up protocol stack- a set of related communication protocols that operate together and use some or all of the seven layers of the OSI model [Guide]. For most networks, the protocol stack is implemented using specialized network chips or built into a general-purpose microprocessor.

The interaction of devices in industrial networks is carried out in accordance with the models client-server or publisher-subscriber (producer-consumer) [Thomesse]. In the client-server model, two objects interact. A server is an object that provides a service, i.e., that performs some actions upon a client's request. A network can contain several servers and several clients. Each client can send requests to multiple servers, and each server can respond to requests from multiple clients. This model is useful for transmitting data that occurs periodically or at predetermined times, such as temperature values ​​in a batch process. However, this model is inconvenient for transmitting randomly occurring events, for example, an event consisting of a random activation of a level sensor, since to receive this event the client must periodically, with a high frequency, request the status of the sensor and analyze it, overloading the network with useless traffic.

Modern methods for designing the activities of automated control system users have developed within the framework of a systems engineering concept of design, due to which taking into account the human factor is limited to solving the problems of coordinating the “inputs” and “outputs” of a person and a machine. At the same time, when analyzing the dissatisfaction of automated control system users, it is possible to reveal that it is often explained by the lack of a unified, integrated approach to the design of interaction systems, presented as a comprehensive, interconnected, proportional consideration of all factors, ways and methods of solving the complex multifactorial and multivariate task of designing an interaction interface. This refers to functional, psychological, social and even aesthetic factors.

At present, it can be considered proven that the main task of designing a user interface is not to rationally “fit” a person into the control loop, but to, based on the tasks of object control, develop a system of interaction between two equal partners (human operator and ACS hardware and software complex), rationally managing the control object. The human operator is the closing link of the control system, i.e. subject of management. APK (hardware-software complex) ACS is implementation tool his (operator's) management (operational) activities, i.e. control object. According to V.F. Venda’s definition, an automated control system is a hybrid intelligence in which the operational (managerial) staff and the agro-industrial complex of the automated control system are equal partners in solving complex management problems. The interface of human interaction with the technical means of the automated control system can be structurally depicted (see Fig. 1.).

Rice. 1. Information and logical diagram of the interaction interface

The rational organization of work of automated control system operators is one of the most important factors determining the effective functioning of the system as a whole. In the overwhelming majority of cases, management work is an indirect human activity, since in the conditions of an automated control system he manages without “seeing” the real object. Between the real control object and the human operator there is object information model(means of displaying information). Therefore, the problem arises of designing not only means of displaying information, but also means of interaction between the human operator and the technical means of the automated control system, i.e. system design problem, which we should call user interface.

It consists of APK and interaction protocols. The hardware and software complex provides the following functions:

transformation of data circulating in the automated control system into information models displayed on monitors (SOI - information display tools);

regeneration of information models (IM);

ensuring dialogue interaction between a person and the automated control system;

transformation of influences coming from the PO (human operator) into data used by the control system;

physical implementation of interaction protocols (harmonization of data formats, error control, etc.).

The purpose of the protocols is to provide a mechanism for the reliable and reliable delivery of messages between the human operator and the SOI, and, consequently, between the PO and the control system. Protocol- this is a rule that defines interaction, a set of procedures for exchanging information between parallel processes in real time. These processes (the functioning of the agro-industrial complex of the automated control system and the operational activities of the control subject) are characterized, firstly, by the absence of fixed time relationships between the occurrence of events and, secondly, by the absence of interdependence between events and actions upon their occurrence.

The functions of the protocol are related to the exchange of messages between these processes. The format and content of these messages form the logical characteristics of the protocol. The rules for executing procedures determine the actions performed by processes that jointly participate in the implementation of the protocol. The set of these rules is the procedural characteristic of the protocol. Using these concepts, we can now formally define a protocol as a set of logical and procedural characteristics of a communication mechanism between processes. The logical definition makes up the syntax, and the procedural definition makes up the semantics of the protocol.

Generating an image using APC allows you to obtain not only two-dimensional images projected onto a plane, but also to implement three-dimensional graphics using planes and second-order surfaces with the transfer of the texture of the image surface.

When creating complex automated control systems, software development is of great importance, because It is software that creates the intelligence of a computer that solves complex scientific problems and controls the most complex technological processes. Currently, when creating such systems, the role of the human factor and, consequently, the ergonomic support of the system is significantly increasing. The main task of ergonomic support is to optimize the interaction between man and machine, not only during operation, but also during the manufacture and disposal of technical components. Thus, when systematizing the approach to user interface design, we can give some basic functional tasks and design principles that the system should solve.

Minimum working force principle software developer and user, which has two aspects:

minimizing resource costs on the part of the software developer, which is achieved by creating a certain methodology and creation technology characteristic of conventional production processes;

minimizing resource costs on the part of the user, i.e. The PO should perform only the work that is necessary and cannot be performed by the system, there should be no repetition of work already done, etc.

The task of maximum mutual understanding the user and the agro-industrial complex represented by the software developer. Those. The PO should not engage, for example, in searching for information, or the information displayed on the video control device should not require recoding or additional interpretation by the user.

The user must remember as little information as possible, since this reduces the ability of the private enterprise to make operational decisions.

Principle of maximum concentration user on the problem being solved and localization of error messages.

The principle of accounting for professional skills human operator. This means that when developing a system, based on some initial data about the possible contingent of candidates specified in the technical specifications, a “human component” is designed taking into account the requirements and characteristics of the entire system and its subsystems. The formation of a conceptual model of interaction between a person and technical means of an automated control system means awareness and mastery of the algorithms for the functioning of the “human - technical means” subsystem and mastery of professional skills in interacting with a computer.

Key for creating effective interface is in a fast, as much as possible, operator's presentation of a simple conceptual model of the interface. Shared User Access accomplishes this through consistency. The concept of consistency is that when working with a computer, the user develops a system of expecting the same reactions to the same actions, which constantly reinforces the user's model of the interface. Consistency, by enabling dialogue between the computer and the human operator, can reduce the amount of time required by the user both to learn the interface and to use it to perform a job.

Consistency is a property of an interface to enhance user perceptions. Another component of the interface is the property of its concreteness and clarity. This is done by applying a panel plan, using colors and other expressive techniques. Ideas and concepts are then given physical expression on a screen that the user interacts with directly.

In practice, high-level user interface design precedes initial design, which allows us to identify the required functionality of the application being created, as well as the characteristics of its potential users. The specified information can be obtained by analyzing the technical specifications for an automated control system (ACS) and the operating manual (OM) for the control object, as well as information received from users. For this purpose, a survey of potential operators and operators working at a non-automated control object is carried out.

After determining the goals and objectives facing them, they move on to the next design stage. This stage is associated with the creation of user scenarios. A scenario is a description of the actions performed by the user to solve a specific problem on the way to achieving his goal. It is obvious that a certain goal can be achieved by solving a number of problems. The user can solve each of them in several ways; therefore, several scenarios must be generated. The more of them there are, the lower the likelihood that some key objects and operations will be missed.

At the same time, the developer has the information necessary to formalize the functionality of the application. And after the scenarios are generated, the list of individual functions becomes known. In an application, a function is represented by a function block with corresponding screen form(s). It is possible that several functions are combined into one function block. Thus, at this stage the required number of screen forms is established. It is important to define the navigation relationships of the functional blocks. In practice, the most appropriate number of connections for one block is set to three. Sometimes, when the sequence of functions is strictly defined, a procedural connection can be established between the corresponding functional blocks. In this case, their screen forms are called sequentially from one another. Such cases do not always occur, so navigation links are formed either based on the logic of processing the data with which the application works, or based on user perceptions (card sorting). Navigation connections between individual functional blocks are displayed on the navigation system diagram. Navigation capabilities in the application are conveyed through various navigation elements.

The main navigation element of the application is the main menu. The role of the main menu is also great because it carries out interactive interaction in the user-application system. In addition, the menu indirectly performs the function of training the user to work with the application.

Menu creation begins with an analysis of the application's functions. To do this, within each of them, separate elements are distinguished: operations performed by users and objects on which these operations are performed. Consequently, it is known which functional blocks should allow the user to perform which operations on which objects. It is convenient to select operations and objects based on user scenarios and application functionality. Selected elements are grouped into common sections of the main menu. The grouping of individual elements occurs in accordance with ideas about their logical connection. Thus, the main menu can have cascading menus, drop-down when selecting any section. The cascade menu matches the list of subsections to the primary section.

One of the requirements for menus is their standardization, the purpose of which is to create a stable user model for working with the application. There are requirements put forward from the standpoint of standardization that relate to the placement of section headings, the content of sections often used in different applications, the form of headings, the organization of cascading menus, etc. The most general standardization recommendations are as follows:

groups of functionally related sections are separated by separators (bar or empty space);

do not use phrases in section titles (preferably no more than 2 words);

Section names begin with a capital letter;

the names of menu sections associated with calling dialog boxes end with an ellipsis;

the names of the menu sections that include cascading menus end with an arrow;

use keys quick access to individual menu sections. They are highlighted by underlining;

allow the use of " Hotkeys", the corresponding key combinations are displayed in the headings of the menu sections;

allow the inclusion of icons in the menu;

changed colors indicate the inaccessibility of some menu sections while working with the application;

allow you to make inaccessible sections invisible.

Some menu sections are unavailable due to the following. The main menu is static and is present on the screen during the entire time you work with the application. Thus, when working with different screen forms (interacting with different functional blocks), not all menu sections make sense. Such sections are generally inaccessible. Therefore, depending on the context of the tasks the user is solving (sometimes on the context of the user himself), the main menu of the application looks different. It is customary to speak of such differing external menu representations as different menu states. Unlike the navigation system diagram drawn up earlier and needed mainly by the developer, the user directly interacts with the menu. The menu determines the number of windows and their type. The entire interface is accompanied by warning windows, hint windows, and wizard windows that specify the sequence of user actions when performing certain necessary operations.

Download document

STATE STANDARD OF THE USSR UNION

INTERFACE
FOR AUTOMATED
CONTROL SYSTEMS
DISTRIBUTED OBJECTS

GENERAL REQUIREMENTS

K.I. Didenko, Ph.D. tech. sciences; Yu.V. Rosen; K.G. Karnaukh; M.D. Gafanovich, Ph.D. tech. sciences; K.M. Usenko; Zh.A. Guseva; L.S. Lanina; S.N. Kiiko

INTRODUCED by the Ministry of Instrumentation, Automation and Control Systems

Member of the Board N.I. Gorelikov

APPROVED AND ENTERED INTO EFFECT by Resolution of the USSR State Committee on Standards dated March 30, 1984 No. 1145

STATE STANDARD OF THE USSR UNION

until 01/01/90

Failure to comply with the standard is punishable by law

This standard applies to the interface that regulates the general rules for organizing the interaction of local subsystems within automated systems management of dispersed objects using the backbone communication structure (hereinafter referred to as the interface).

In terms of physical implementation, the standard applies to interfaces of aggregates that use electrical signals to transmit messages.

1. PURPOSE AND SCOPE OF APPLICATION

1.1. The interface is designed to organize communication and exchange of information between local subsystems as part of automated control systems for technological processes, machines and equipment in various industries and non-industrial areas.

interface with operational and technological personnel;

interface with upper-tier control computer complexes in hierarchical systems.

2. MAIN CHARACTERISTICS

2.1. The interface implements a bit-serial synchronous method of transmitting digital data signals over a two-wire trunk channel.

2.2. The total attenuation of the signal between the output of the transmitting and the input of the receiving station should be no more than 24 dB, while the attenuation introduced by the communication line (main channel and taps) should be no more than 18 dB, contributed by each communication device with the line - no more than 0, 1 dB.

Note. When using cable type RK-75-4-12, the maximum length of the communication line (including the length of branches) is 3 km.

(New edition, Amendment No. 1).

2.5. To represent the signals, two-phase modulation with phase-difference coding must be used.

2.6. For code protection of transmitted messages, a cyclic code with a generating polynomial must be used X 16 + X 12 + X 5 + 1.

2.7. In order to eliminate random errors, it must be possible to retransmit messages between the same local subsystems.

2.8. The transmission of messages between local subsystems must be carried out using a limited set of function bytes, the sequence of which is established by the message format. The interface establishes two types of message formats (Figure 1).

Format 1 has a fixed length and is intended for the transmission of interface messages only.

Format 2 includes a variable-length information part intended for data transmission.

Format 2, depending on the transmission speed (low-speed or high-speed range), should look like 2.1 or 2.2, respectively.

Types of message formats

Format 1

2.9. Message formats shall include the following function bytes:

synchronizing CH;

address of the called local AB subsystem;

code of the performed function CF;

own address of the local subsystem of the AS;

number of data bytes in the information part of DS, DS1 or DS2;

information bytes DN1 - DNp;

control code bytes KB1 and KB2.

2.8, 2.9.

2.9.1. The synchronization byte CH serves to indicate the beginning and end of a message. The synchronization byte is assigned the code?111111?.

2.9.2. The AB subsystem address byte identifies the local subsystem to which the message is routed.

2.9.3. The CF function performed byte determines the operation that is performed in a given communication cycle. The purpose of the bits inside the CF byte is shown in Fig. 2.

KF byte structure

2.9.4. CF codes and the corresponding operations performed are indicated in the table.

Byte designation	Function code								Operation to be performed
									Multicast (general addressing)
									Write-read
									Centralized polling of controllers
									Transfer of control of the main channel
									Return control of the trunk channel. Message with general address was not accepted
									Return control of the trunk channel. Message with general address accepted
									Decentralized polling of controllers. No request to seize the channel. Message with general address was not accepted
									Request to seize the main channel. Message with general address was not accepted
									Request to seize the main channel. Message with general address accepted
									Passing a token
									Message confirmation
									Confirmation of message issuance
									Confirmation of receipt and subsequent issuance of a message. Responses to a centralized survey
									No request to seize the channel. Message with general address was not accepted
									No request to seize the channel. Message with general address accepted
									Request to seize a channel. Message with general address was not accepted
									Request to seize a channel. Message with general address accepted

The zero bit determines the type of message (challenge-response) transmitted over the trunk channel.

Bit 1 takes on a single value when the subsystem is busy (for example, forming a data buffer).

Bit 2 takes on a single value if a message of format 2 is transmitted in this cycle.

Bit 3 takes the value of one in a re-sent message to the same local subsystem if an error is detected or there is no response.

(Changed edition, Amendment No. 1).

2.9.5. The own address of the local subsystem that generates the AC message is issued in order to inform the called subsystem of the response address and verify the correctness of its choice.

2.9.6. The DS byte determines the length of the information part in 2.1 format, while the value of the binary code of the DS byte determines the number of DN bytes. The exception is the code ?????????, which means that 256 information bytes are transmitted.

Bytes DS1, DS2 determine the length of the information part in 2.2 format.

(Changed edition, Amendment No. 1).

2.9.7. DN data bytes represent the information part of a format 2 message. Data encoding must be established by regulatory documents for the associated local subsystems.

2.9.8. Control bytes KB1, KB2 form the control part and are used to determine the reliability of transmitted messages.

3. INTERFACE STRUCTURE

3.1. The interface provides the ability to build distributed systems with a backbone communication structure (Fig. 3).

Structure of connection of local subsystems

LC1 - LCn- local subsystems; MK- main channel; PC- matching resistor

3.2. All interfaced local subsystems must be connected to the main channel through which information is exchanged.

3.3. To interface local subsystems with the main channel, they must include communication controllers. Communication controllers must:

converting information from the presentation form accepted in the local subsystem into the form required for transmission over the main channel;

adding and highlighting synchronization signs;

recognition and reception of messages addressed to this local subsystem;

generation and comparison of control codes to determine the reliability of received messages.

3.4. Message exchange between local subsystems must be organized in the form of cycles. A cycle is understood as the procedure for transmitting one message of format 1 or 2 to the main channel. Several interconnected cycles form the transmission process.

3.5. The transmission process must be organized according to the asynchronous principle: the local subsystem must receive responses to calls sent to the main channel (with the exception of group operations).

4. INTERFACE FUNCTIONS

4.1. The interface establishes the following types of functions, differing in control levels, which occupy local subsystems in the process of messaging:

passive reception;

reception and response;

decentralized management of the main canal;

request to seize the main channel;

centralized control of the main channel.

(Changed edition, Amendment No. 1).

4.2. The composition of the interface functions implemented by the local subsystem is determined by the composition of the problem solved by this subsystem and its functional characteristics.

4.3. The type of local subsystem is determined by the highest level function among those provided. The local subsystem is considered active relative to the function it performs in the current cycle.

4.4. In accordance with the composition of the implemented interface functions, the following types of local subsystems are distinguished:

passive controlled subsystem;

controlled subsystem;

control subsystem;

proactive control subsystem;

leading subsystem.

4.4.1. The passive controlled subsystem performs only identification and reception of messages addressed to it.

4.4.2. The controlled subsystem receives messages addressed to it and generates a response message in accordance with the received function code.

4.4.3. The control subsystem must have the ability to:

accept control of exchange over the main channel in centralized and decentralized modes;

generate and transmit messages over the main channel;

receive and analyze response messages;

return or transfer control of the trunk channel after the end of the transfer process.

(Changed edition, Amendment No. 1).

4.4.4. The proactive control subsystem, in addition to the function according to clause 4.4.3, must have the ability to generate a request signal to seize the main channel, receive and send corresponding messages when performing the search procedure for the requesting subsystem.

4.4.5. The leading subsystem coordinates the work of all local subsystems in the mode of centralized control of the main channel. She carries out:

arbitration and transfer of control of the main channel to one of the control local subsystems;

central control of all local subsystems;

monitoring the operation of the active control local subsystem;

transmission of messages with a common address for all (or several) local subsystems.

Only one subsystem that has an active master function can be connected to the main channel.

(Changed edition, Amendment No. 1).

5. MESSAGE EXCHANGE PROCEDURE

5.1. Each cycle of message transmission over the main channel must begin with the synchronization of all subsystems connected via the interface.

5.1.1. To perform synchronization, the master or active control subsystem must transmit the synchronizing byte CH to the main channel. It is possible to transmit several synchronization bytes sequentially. Additional synchronization bytes are not included in the message format.

5.1.2. Once all subsystems have synchronized, the master or active control subsystem sends a format 1 or 2 message to the trunk link, including their own CH bytes.

5.1.3. All bytes, with the exception of control KB1 and KB2, are transmitted to the main channel, starting from the least significant bit.

Bytes KB1, KB2 are transmitted from the most significant bit.

5.1.4. To exclude from the message transmitted to the main channel a sequence of bits that coincide with the code of the CH byte, each message must be converted in such a way that after 5 consecutive “1” characters one additional “0” character must be included. The receiving subsystem must accordingly exclude this character from the message.

5.1.5. After transmitting the message, including the CH end byte, the sending subsystem must transmit at least 2 more CH bytes to complete the receive operations, after which the transmission cycle ends.

5.2. The trunk channel control procedure determines the sequence of operations for activating one of the control subsystems to carry out the message transmission process. Subsystems connected via an interface can operate in the mode of centralized control of the main channel.

5.2.1. The procedure for centralized control of the main channel provides for the presence of a leading subsystem, which coordinates the interaction of subsystems by managing the transfer of control of the main channel.

5.2, 5.2.1. (New edition, Amendment No. 1).

5.2.2. When transferring control of the trunk link, the master subsystem designates the active control subsystem to carry out the message transfer process. To do this, the leading subsystem must send a format 1 message with the function code KF6 to the selected control subsystem.

5.2.3. After receiving a message with function code KF6, the control subsystem must become active and can perform several message exchange cycles in one transmission process. The number of exchange cycles must be controlled and limited by the master subsystem.

5.2.4. After transferring control of the main channel, the leading subsystem must activate the passive reception function and turn on the control timing. If within the set time (the response waiting time should not be more than 1 ms) the designated active subsystem does not begin transmitting messages over the trunk channel, the leading subsystem re-sends a message of format 1 with the function code KF6 and the retransmission sign to the control subsystem.

5.2.5. If, upon repeated access, the control subsystem does not begin transmitting messages (does not become active), the leading subsystem determines it as faulty and implements the procedures provided for such a situation.

5.2.6. At the end of the transfer process, the active control subsystem must perform the function of returning control of the trunk channel. To do this, it must send a message to the leading subsystem with the function code KF7 or KF8.

5.2.7. The procedure for decentralized control of the main channel provides for the sequential transfer of the active function to other control subsystems by passing a token. The subsystem that accepted the token is active.

5.2.8. For initial token capture, all subsystems connected via the trunk channel must include interval timers, and the values ​​of time intervals must be different for all subsystems. The subsystem with a higher priority should be assigned a smaller time interval.

5.2.9. If, after the subsystem's own time interval has expired, the trunk channel is free, this subsystem must consider itself the owner of the token and begin the transmission process as the active control subsystem.

5.2.10. After completing the transfer process, the active control subsystem must transfer control of the main channel to the next control subsystem with the address AB = AC + 1, for which it must issue a marker, activate the passive reception function in itself and turn on the control timing.

A message of format 1 (Fig. 1) with function code KF13 and address AB is used as a marker.

If within the specified time the subsystem that received the token does not begin the transmission process, the subsystem that sent it must attempt to transmit the token to subsystems with the following addresses AB = AC + 2, AB = AC + 3, etc. until the token is accepted. The address of the subsystem that received the token must be remembered by this subsystem as a subsequent one until the initial acquisition is repeated.

5.2.11. Any active subsystem that detects an unauthorized exit to the communication channel must perform the actions in clause 5.2.8.

5.2.12. In the mode of decentralized control of the main channel, all subsystems must have an active passive reception function. In the event of a token loss (for example, if the active control subsystem fails), the initial token capture mechanism must be triggered (clauses 5.2.8, 5.2.9) and operation must be restored.

5.2.13. Any subsystem that owns a token and has received an active master function can seize centralized control of the trunk channel and maintain it until the active master function assigned to it is canceled.

5.2.7 - 5.2.13. (Introduced additionally, Amendment No. 1).

5.3. In the centralized control mode, transfer of control of the main channel can be organized based on requests from proactive control subsystems.

5.3.1. Subsystems must have an active trunk channel capture request function to organize transfer of control upon requests.

5.3.2. There are two possible ways to organize the search for a subsystem requesting access to the main channel - centralized and decentralized.

5.3, 5.3.1, 5.3.2. (New edition, Amendment No. 1).

5.3.3. With centralized polling, the leading subsystem must sequentially poll all proactive control subsystems connected to the main channel. The leading subsystem must send a format 1 message with the function code KF5 to each proactive control subsystem.

The initiating control subsystem must send a response message to the leading subsystem with one of the function codes KF21 - KF24, depending on its internal state. The sequence of operations in the centralized survey procedure is shown in Fig. 4.

5.3.4. Decentralized polling provides a quick process for identifying proactive control subsystems that have established a request for access to the backbone channel. The leading subsystem must contact only the first in turn proactive control subsystem with a message of format 1 and function code KF9.

Each proactive control subsystem must receive a message addressed to it and send its own message addressed to the next subsystem in turn to the main channel. The generated message must contain one of the function codes KF9 - KF12, which characterizes the state of this subsystem. The decentralized survey procedure is illustrated in Fig. 5.

5.3.5. The leading subsystem, after starting the decentralized poll, activates the passive reception function and receives all messages sent by the proactive control subsystems. This allows the leading subsystem, after the end of the decentralized poll, to have information about requests for access to the main channel from all proactive control subsystems.

Process of centralized subsystem polling

Decentralized subsystem polling process

The last initiative control subsystem in the chain of decentralized polling must address its message to the leading subsystem, which means the end of the decentralized polling procedure.

5.3.6. If any subsystem does not send messages to the main channel after accessing it, the leading subsystem must wake up and send it a repeat message identical to the previous one. If there is no response (or errors) to a repeated call, the leading subsystem launches a decentralized poll from the next subsystem in turn, and this subsystem is excluded from the poll.

5.4. The data transfer procedure can be performed in the form of one of the following processes:

group recording;

write-read.

5.4.1. Group recording must be performed by the master subsystem. When performing a group recording, the master subsystem issues a message of format 2 to the main channel, in which code 11111111 (255) and function code KF1 are written as the AB address.

5.4.2. All subsystems responding to the multicast address must accept the message from the trunk link and register a state indicating that the public address message has been accepted. Response messages during group recording are not issued by the receiving subsystems.

5.4.3. Confirmation of receipt of a group message is carried out in the process of centralized or decentralized polling, as well as when returning control of the main channel, for which the corresponding status bit is included in the function codes KF7, KF8, KF9 - KF12 and KF21 - KF24.

5.4.4. During the recording process, the master subsystem or the active control subsystem sends a format 2 message with the function code KF2 to the main channel, intended for reception by a specific controlled subsystem, the address of which is indicated in the AB byte. After issuing a message, the active control subsystem turns on the control countdown and waits for a response message.

5.4.5. The addressed subsystem recognizes its address and receives the message sent to it. If the message is received without error, the receiving subsystem must issue a response to the main channel in the form of a message of format 1 with function code KF18.

5.4.6. If an error is detected in a received message, the receiving subsystem should not issue a response.

5.4.7. The active control subsystem, if there is no response during the control time interval, must retransmit the same message.

5.4.8. If there is no response to a repeated message, this subsystem is considered faulty and the active control subsystem must perform the procedure prescribed for such a situation (turning on the alarm, removing the subsystem from use, turning on the reserve, etc.).

5.4.9. In the mode of centralized control of the main channel, the dialogue between the control and controlled subsystems must be constantly monitored by the leading subsystem, which at this time performs the function of passively receiving messages.

(New edition, Amendment No. 1).

5.4.10. The reading process must begin by sending a message of format 1 with the function code KF3 by the active control subsystem.

5.4.11. The subsystem to which this message is addressed, if it is received correctly, must issue a response message of format 2 with function code KF19.

5.4.12. If the called subsystem cannot issue data within the specified waiting time, then after receiving the message with the reading function, it must record the sign that the subsystem is busy and begin forming an array of data for issue.

5.4.13. This managed subsystem must remember the address of the active control subsystem that addressed it (for which data is being prepared) and set the busy sign in response messages to other control subsystems.

5.4.14. To read the prepared data, the active control subsystem must again contact the controlled subsystem with a message in format 1 with function code KF3. If the data is prepared by this time, then the controlled subsystem must issue a response message of format 2 with function code KF19.

The subsystem busy sign should be cleared only after the transmission of a response message of format 2.

5.4.15. If the response message is received by the active control subsystem without an error, then the reading process ends.

5.4.16. If an error is detected or there is no response, the active control subsystem repeats the call and then takes measures similar to those given in paragraphs. 5.4.7, 5.4.8.

5.4.17. Write-read is a combination of processes according to paragraphs. 5.4.4 - 5.4.15.

5.4.18. The active control subsystem sends a format 2 message with function code KF4 to the main channel.

5.4.19. The addressed subsystem must accept the message sent to it and generate a response.

5.4.20. The response message in this process must be in format 2 (contain read data) and have the function code KF20.

5.4.21. Monitoring the reliability of transmitted messages and the actions taken by the active control subsystem should be similar to those given for the writing and reading processes.

6. PHYSICAL IMPLEMENTATION

6.1. Physically, the interface is implemented in the form of communication lines that form a backbone channel, and communication controllers that provide direct connection to the communication lines.

6.2. Communication controllers must be implemented in the form of functional units that are part of the subsystem, or in the form of structurally separate devices.

6.3. The rules for pairing and interaction of communication controllers with the functional part of the subsystem are not regulated by this standard.

6.4. For trunk communication lines, a coaxial cable with a characteristic impedance of 75 Ohms should be used.

6.5. The coaxial cable must be loaded at both ends with matching resistors with a resistance of (75 ± 3.75) Ohms. The power of the matching resistors must be at least 0.25 W.

Termination resistors must be connected to the ends of the communication lines using RF connectors.

Grounding or connecting communication lines to device housings in mating subsystems is not permitted.

6.6. The attenuation along the main channel communication line should be no more than 18 dB for a speed of 500 kbit/s.

6.7. The total attenuation introduced by each branch from the main channel communication line should not exceed 0.1 dB, including attenuation determined by the quality of the junction point, attenuation on the branch and attenuation depending on the input-output parameters of the matching circuits.

6.8. Branches from the main channel communication line must be made with a coaxial cable with a characteristic impedance of 75 Ohms. The length of each branch is no more than 3 m. The total length of all branches is included in the total length of the main canal. Connection to the communication line must be made using RF connectors. Disabling any of the subsystems should not lead to a break in the communication line.

6.9. Communication controllers must contain transceiver amplifiers that provide:

reception sensitivity, no worse................................................... ............. 240 mV

output signal level .................................................... ........................... 4 to 5 V

output impedance........................................................ ........................... (37.50 ± 1.88) Ohm

6.10. The formation of electrical signals for transmission to the main channel is carried out by modulating the clock frequency with the signals of the transmitted message. Each bit of the transmitted message corresponds to a full period of the clock frequency, and the leading and falling edges of the transmitted signal must coincide with the transition through zero of the clock frequency (Fig. 6). The correspondence of symbols received from the main channel to meaningful states is established as follows:

the symbol “0” corresponds to the opposite phase relative to the previous symbol,