Development of control systems and safety devices for solving the problems of digital transformation of the transport complex

The article considers the challenges facing the transport complex, in particular, at the stage of digital transformation. The directions of development of the transport complex are defined, including the creation of a highly effective "trusted environment". The reasons why the transition to a new paradigm of building transport control systems and safety devices of a new generation is extremely necessary are identified and analyzed. The basic principles and architecture of the basic platform for advanced control systems, safety and diagnostics of traction rolling stock are formulated and

The transport strategy of the Russian Federation for the period up to 2030, sets large-scale goals for carriers: x formation of a unified transport space of Russia on the basis of balanced advanced development of effective infrastructure; x ensuring the availability and quality of transport and logistics services in the field of cargo transportation at the level of the needs of the country's economic development; x ensuring the accessibility and quality of transport services for the population in accordance with social standards; x integration into the global transport space, realization of the country's transit potential; x improving the security of the transport system; x reducing the negative impact of the transport system on the environment.
The implementation of development initiatives is impossible without the digital transformation of transport companies, vehicle developers and rethinking approaches to the creation of on-board microprocessor control, safety and diagnostic systems (MCS) [1,2,3].
The digital platform, taking into account current needs and future perspectives, should provide: x converged: data collection, processing, storage and analysis [5]; x formation of predictive production models and planning of all types of resources to ensure the technological process of transportation by vehicle; x storage and provision of data to the participants of the transport complex at all stages of the vehicle life cycle; x completeness, relevance and reliability of the information necessary for the interaction of participants in the transport process, including in the interests of ensuring the validity and effectiveness of decision-making for building a quality management system in transport systems; x creating a highly efficient and transparent information environment by unifying and simplifying data exchange between the participants of the transport complex, for effective management of the vehicle fleet and reducing operating costs.
It is advisable to consider the process of transformation of heterogeneous on-board systems and devices into a single ecosystem of MCS using the example of railway transport.
The solution of the tasks facing the Russian Railways holding company at the present stage of the development of the railway complex and with a view to the future cannot be achieved without changing the paradigm of the development of new on-board MCS.
The current global trend in the development of advanced industrial automation technologies [6,7,8] is formed in the conditions of high competition and increased business requirements for cost reduction. It is obvious that there is a need to combine at the hardware level, used on a single control object, but disparate devices and systems, into a single system that controls the entire object, with the separation of functions at the software level (SIBAS, MEN TCS, Artesyn, Hitachi, etc.) [9].
For example, the development of locomotive devices was mainly based on the strategy of improving or modernizing existing control and safety systems with increasing functions in certain areas [11,12]. A person acts as the core of the control system, which is a set of devices for controlling a vehicle. There were exceptions to this development, which now seem revolutionary.
Security devices are a revolutionary result of the development of technical thought, which saw the removal of control devices from human control and isolation him from control, even if only partially, corresponding to the ideas and possibilities of the time.
Following the chosen path, the existing set of locomotive safety devices assigns the locomotive driver the role of executing numerous instructions that grow in the process of dangerous events. At the same time, the locomotive driver remains, on the one hand, the chief controller, on the other -he is the object of control.
Operating locomotive systems and control devices are a collection of disparate independent devices that were not the result of any system concept, but appeared as individual solutions and were used in various versions as devices for controlling the locomotive driver.
The continuation of the policy of releasing fragmented devices is an obstacle to development, and generates additional costs, expanding the staff of maintenance personnel and the amount of equipment installed on board the vehicle. In the current situation, a healthy competitive environment cannot develop, as a result of which the developers of existing security devices and control systems are unique and are not interested in development, since their product is already in demand on the market [4]. Therefore, for the future development of the transport complex, it is extremely important at the present time to create conditions for full-fledged competition of developers, indicating the general line of development of onboard MCS.
The cardinal solution when building a new structure of the MCS is to separate a secure element from the general system: simple and independent, not scalable and not updated. A system without a secure element consists of intelligent, updatable, scalable elements. With this approach, the intelligence of the system will not be subject to obstruction due to the requirements of functional security and will avoid a lengthy security proof procedure (also necessary for any software modification and update), with the final decision being made on the "human factor", insensitive to failures "for a common reason".
Thus, it is proposed to remove the obstacle that significantly and for a long time hindered the development, and provide a basis for the subsequent transition to unmanned locomotive control. This will also reduce the cost of repair and maintenance of the MCS [13,15].
It is obvious that, following the intended goal, it is necessary to abandon the traditional shifting of the issues of the software and hardware area to the person. Thus, the use of wearable parts (the registration cassette of the integrated locomotive safety device (ILSD), the cartridge of the unified system of automated train driving (USATD), the wearable part of the telemechanical system for monitoring the driver's wakefulness (TSMDW), the warning form, the brake certificate, the consignor list of train), the information from which is transferred from the locomotive and then processed by decoding technicians, does not meet the current level of technology development, therefore entails additional costs for the maintenance of a staff of qualified specialists and for the purchase, repair and maintenance of the wearable parts themselves, including the replacement of failed ones. Moreover, the transition to unmanned control creates a requirement for high-quality, reliable and secure wireless communication of the locomotive with the infrastructure.
The functions of diagnostics, determining the pre-failure conditions of the vehicle equipment in the standard MCS are practically not implemented (failures of technical means on the line are a significant amount), and predictive diagnostics are completely absent. These functions are required for reasons that go beyond the requirements of the MCS architecture. Moreover, this is not a result, but a direction in which conditions for systematic development are necessary and the architecture of the system should allow this to be done without becoming an obstacle.
To create the prerequisites for the transition to unmanned control, when introducing new monitoring and diagnostic functions, the general approaches should be adjusted. It requires the necessary hardware that can be scaled to assess the technical condition of the locomotive and the entire train, especially the serviceability of the running gear and braking means.
The recursive complexity of the equipment is due to the fact that the control of the input equipment, in general, requires additional equipment. In the future, the MCS should avoid such recursivity, and therefore the receipt of a signal with data on the movement and condition of the locomotive equipment should be transmitted to the system through digital unified performance interfaces capable of passing real-time data accompanied by metadata. With this approach, the processing, replacement of equipment will not require any accompanying hardware changes to the system. All this in the future will serve as a qualitative basis for the creation and development of a highly effective transparent information environment -a "trust environment".
Events that are considered safe under the current binary approach should be re-evaluated accordingly in the new MCS. An unscheduled stop of the train on the stage is not dangerous, and is even considered a safe condition [14]. However, such a train stop can create the prerequisites for a chain of potentially dangerous events. Overcoming these shortcomings will be ensured by a continuous assessment of the technical condition of the locomotive and the entire train, starting with an assessment of the serviceability of the running gear and braking means. Timely detection of a pre-failure condition or malfunction, and the causes of its occurrence, directly affects traffic safety, especially when implementing unmanned control. In addition to the direct consequence, continuous automatic diagnostics allows you to reduce the cost of maintenance, diagnostics and repair of the MCS.
In the future, the requirements for the MCS in terms of information support will only increase. To implement technologies that do not require any actions from a person, technical vision systems, predictive technology algorithms and others should be used. The issue is not only a significant increase in computing power, which is not rational to provide locally, but also that the information about the rolling stock in relation to the movement process and management is not complete and often unreliable, since most of the information is entered by the operator "manually". When processing information, there is a need for qualification, segmentation, and a hierarchical approach to data processing: part of the information is sent to data processing centers and decision-making on them. This approach is provided by a hyper-converged infrastructure.
A prospective MCS should consist of blocks, the number of which is sufficient to implement the required functions, taking into account the use on all types of traction rolling stock (Figure 1). The specific execution of the MCS blocks may be different depending on the requirements for the functions, but the core of the system is the block of central computing (BCC). That is, the MCS should be able to scale and reconfigure depending on the specific functional load. At the same time, the structural blocks must support a standard interface for interaction. Reconfiguration of the hardware and logging of the operation of the MCS should be performed by the controller of the block of life cycle (BLC) of the MCS. The MCS should be reconfigured automatically depending on the blocks included in the set, and the software updates of the blocks should be performed depending on the current configuration of the MCS.
The hardware level is separated from the software level, and the hardware part is designed to be as unified as possible [10]. This is one of the basic differences of advanced systems, which reduces the cost of operating the MCS, due to the availability of the ability to separately, independently expand the software and improve the hardware. The software is maximally abstracted from the equipment by applying an additional software layer that manages the loading of operating systems and is an in-house development of the department "Traction Rolling Stock".
Given the prospects for" communication " of devices, it is advisable to choose a single network hardware interface for the interaction of blocks and modules of the MCS, that is, an interface that will allow for the exchange of information in networks, as well as between the infrastructure and the MCS. This is especially important in terms of scaling the system on rolling stock.
BIMM -the block of the interface "man-machine"; BTF -the block of traffic safety; BCC -the block of the central computer; BC -the block of commutators; BWC -the block of wireless communications; BLC -the block of the life cycle. To ensure development, the interface must be satisfactory not only for the known requirements for the creation of the MCS, but also for the non-created, proposed infrastructure, within reasonable limits, which are determined by known technologies and needs. For automatic control systems, real-time operation is required -that is, a predictable delay of the control signal and signals from primary information sources. At the same time, when using computer vision (video cameras, lidars, radars, etc.), it is necessary to ensure a high transmission speed. Interaction with the infrastructure requires the ability to work in a wide area network, etc.
The use of a network interface creates the prerequisites for a hardware-level network model. Each block becomes a separate structural unit. The BLC acts as an analog of the life cycle controller in servers and hyperconverged systems that provide configuration and reconfiguration of the MCS, taking into account the type of installed equipment and the characteristics of the traction rolling stock. Also, the BLC must ensure the joint operation of several MCS in the presence of two or more locomotives in the train.
The traffic safety unit performs the main functions that ensure traffic safety, taking into account the requirements of functional safety. Thus, a two-level hierarchical two-component model is created: BTF -BCC, in which, if the security function implemented in the BCC fails, the BTF becomes the security controller. If the BTF fails, the MCS is configured to operate without a traffic safety unit. It can be proved that integrally, this approach provides a given level of security. With this order of reconfiguration of the MCS, its survivability increases, and the probability of dangerous failure decreases, which together increases traffic safety.
Depending on the type of traction rolling stock and the functions of a particular MCS, different types of BCC can be developed. This will reduce the cost of the MCS and fully meet the technical requirements for advanced management systems.
To demonstrate the practical implementation of the proposed architecture, the Department of Traction Rolling Stock of the Russian University of Transport (MIIT) developed a prototype of the MCS using general-purpose components. The structure of the prototype is shown in Figure 2. A special feature is the use of two different types of computing blocks: BCC1, BCC2, which are built on processors with different architectures. A prototype of the switching unit is also used, which combines the communication functions between the modules and the I/O functions. Basically, to implement the required functionality, standard Raspberry Pi3 model B microprocessor devices are used, but in the future it is planned to completely switch to the domestic component base, so a computer based on the Elbrus 8C processor can be used as part of the prototype of the MCS. The prototype allows us to implement a number of typical and frequent scenarios that occur in real operation, for example, system reconfiguration in case of component failure, updating the system without the need to interrupt operation, and software abstraction mode.
The implementation of software abstraction is a key stage for creating a unified MCS. The structure of abstraction is shown in Figure 3.
As a result, it is possible to formulate the basic principles that are laid down when designing promising and building new MCS: x Isolation of the software part of different software developers within a single hardware platform; x Openness and standardization of the interface; x The secure element allocated in the MCS; x The minimum number of physical blocks; x Modular, scalable architecture; x Reconfiguration of the MCS for a specific type of traction rolling stock.