Locomotive cab controller

Abstract

The invention discloses a locomotive cab controller, and relates to the field of control, the locomotive cab controller comprises a first inner core and a second inner core, the first inner core runs a general operation system, and the second inner core runs a real-time operation system; the first kernel processes low-real-time tasks in the cab, and the second kernel processes high-real-time tasks in the cab, so that different control requirements of real-time requirements in the cab are met through the multi-core controller; on the basis, the first core and the second core perform inter-core communication through the on-chip bus, so that the data interaction requirements among different cores are met, and a basis is provided for realizing a multi-core cooperative control task. The independent complex control function in the cab is integrated into a single controller, the number of controller hardware is reduced, the wiring complexity is lowered, the controller cost is saved, and the installation and space layout difficulty of the cab controller is lowered.

Description

Technical Field

[0001] The present application relates to the field of vehicle technology, and in particular to a locomotive cab controller. Background Art

[0002] Currently, in the rail transit industry, locomotive driver's cabs usually have separate controllers for different control response functions. A control subsystem consists of a single controller, related sensors, and related actuators to achieve independent control tasks for the controlled objects. In addition, some control subsystems need to work together, that is, a master controller needs to be set up in the driver's cab to connect with the above-mentioned controllers and conduct data communication to realize the overall function of the driver's cab.

[0003] With the continuous development of vehicle technology and intelligent technology, the number and types of equipment installed in the driver's cab continue to increase, and intelligent devices such as voice interaction equipment and human-computer interaction touch screens have been added. As a result, the driver's cab control system based on the existing driver's cab design method requires the installation of a large amount of controller hardware and complex inter-system wiring, which makes it difficult to meet the increasingly complex driver's cab control needs. Summary of the Invention

[0004] In view of the above problems, the present application provides a locomotive cab controller to achieve the integration of complex control equipment in the cab and reduce the controller hardware cost and wiring cost.

[0005] The specific plan is as follows:

[0006] The present application provides a locomotive cab controller, comprising: a first core and a second core;

[0007] The first core runs a general-purpose operating system and is provided with a first peripheral interface, wherein the first peripheral interface is used to connect to an intelligent auxiliary device and a storage device; the first core is used to process control response tasks with low real-time requirements in the driver's cab, and the first core is also used to control data storage in the driver's cab;

[0008] The second core runs a real-time operating system and is provided with a second peripheral interface, wherein the second peripheral interface is used to connect to a driver's cab environment control device; the second core is used to process control response tasks with high real-time requirements in the driver's cab;

[0009] The first core and the second core perform inter-core communication via an on-chip bus.

[0010] In a possible implementation, the first core and the second core perform inter-core communication through an on-chip bus, including:

[0011] The first core and the second core perform first data communication through an on-chip bus in a manner of combining a message queue with a hardware interrupt; the first data communication is data communication with a single frame data amount not greater than a preset data amount threshold.

[0012] In a possible implementation, a process in which the first core and the second core perform inter-core communication in a manner of combining a message queue with a hardware interrupt includes:

[0013] The sending-end core writes communication data to a message queue of the cab controller of the locomotive, and sends an interrupt instruction to a receiving-end core through interrupt control hardware of the cab controller of the locomotive, to instruct the receiving-end core to read data from the message queue after receiving the interrupt instruction; the first core and the second core are respectively the sending-end core and the receiving-end core.

[0014] In a possible implementation, a process in which the first core and the second core perform inter-core communication in a manner of combining a message queue with a hardware interrupt includes:

[0015] The OpenAMP module of the sending-end core sends an interrupt request to the IPCC module of the receiving-end core through the IPCC module of the sending-end core, to instruct the IPCC module of the receiving-end core to perform channel detection;

[0016] After detecting an idle channel, the IPCC module of the receiving-end core sends an acknowledgement instruction to the OpenAMP module of the sending-end core through the IPCC module of the sending-end core, to represent that the receiving-end core has received the interrupt request;

[0017] After receiving the acknowledgement instruction, the OpenAMP module of the sending-end core writes communication data to a message queue based on shared memory, and the receiving-end core detects a state of a shared memory address corresponding to the message queue;

[0018] After detecting that the shared memory address corresponding to the message queue is idle, the receiving-end core performs data copying on the communication data in the message queue;

[0019] The first core and the second core are respectively the sending-end core and the receiving-end core.

[0020] In a possible implementation, the first core and the second core perform inter-core communication through an on-chip bus, including:

[0021] The first core and the second core perform second data communication through the on-chip bus in a manner of shared memory, and the second data communication is data communication with a data amount greater than a preset data amount threshold.

[0022] In a possible implementation, the process of performing inter-kernel communication between the first kernel and the second kernel using a shared memory manner includes:

[0023] The sending end core writes communication data to a preconfigured memory area for reading by the receiving end core; wherein the preconfigured memory area is a memory area in the locomotive cab controller that is pre-configured to be shared by the first core and the second core; the first core and the second core serve as the sending end core and the receiving end core respectively.

[0024] In a possible implementation, the second core is a Cortex-M core; and / or the first core is a Cortex-A core.

[0025] In a possible implementation, the real-time operating system is a FreeRTOS system; and / or the general operating system is a Linux system.

[0026] In a possible implementation, the first peripheral interface includes an Ethernet interface and a USB interface;

[0027] The Ethernet interface is used to connect to the intelligent auxiliary device;

[0028] The USB interface is used to connect to the storage device.

[0029] In a possible implementation, the second peripheral interface includes a CAN bus interface and an RS-485 bus interface.

[0030] By means of the above technical solution, the locomotive cab controller provided by this application includes a first core and a second core. The first core runs a general operating system, and the second core runs a real-time operating system. The first core handles low-real-time tasks in the driver's cab, and the second core handles high-real-time tasks in the driver's cab. Based on this, this application meets the control needs of the driver's cab with different real-time requirements by using a multi-core controller; on this basis, the first core and the second core communicate between the cores through the on-chip bus, meeting the data interaction requirements between different cores, and providing a basis for realizing multi-core collaborative control tasks. This application integrates the independent and complex control functions in the driver's cab into a single controller, reducing the number of controller hardware, reducing the wiring complexity, saving controller costs, and reducing the difficulty of installation and spatial layout of the driver's cab controller. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments with reference made to the accompanying drawings. The drawings are for purposes of illustration only and are not intended to be limiting in accordance with the present application. Like reference numerals have been used wherever possible throughout the drawings and the following detailed description to refer to similar components. In the drawings:

[0032] Figure 1 is a structural schematic diagram of a locomotive cab controller provided by the present application;

[0033] Figure 2 A data synchronization timing diagram based on a message queue between the first core and the second core is shown. DETAILED DESCRIPTION

[0034] The embodiments of the present application are described below with reference to the accompanying drawings. The terms used in the embodiments of the present application are only used to explain the specific embodiments of the present application, and are not intended to limit the present application. Those of ordinary skill in the art can know that, as technology develops and new scenarios appear, the technical solutions provided by the embodiments of the present application are also applicable to similar technical problems.

[0035] The applicant of the present application has found that, with the improvement of the overall intelligence level of the locomotive, the data related to the device control function realized by the locomotive cab controller involves high real-time data and high-bandwidth data coexisting, wherein the control function related to the locomotive control signal requires high real-time and high-reliability data transmission, and the control function related to the locomotive monitoring signal requires large-bandwidth, high-flow data transmission. In this case, the traditional cab control system design scheme based on multiple controllers to realize each control function needs complex data interaction between multiple controllers, increasing the complexity of the whole vehicle wiring and signal design.

[0036] To solve the above problems, the present application provides a locomotive cab controller to realize complex control functions in the cab, meet the communication requirements of high real-time signals and high-bandwidth flow coexisting, and reduce the hardware cost, wiring cost and communication design overhead of the locomotive cab control function implementation.

[0037] Figure 1 is a structural schematic diagram of a locomotive cab controller according to an embodiment of the present application, and Figure 1 As shown in the figure, the locomotive cab controller 1 can include a first core 11 and a second core 12.

[0038] The controller 1 can be designed based on a multi-core heterogeneous platform, and specifically can include multiple ARM (Advanced RISC Machines, ARM) cores, which can run multiple operating systems at the same time to realize multiple control functions.

[0039] Next, the two kernels are described in turn.

[0040] The first kernel runs a general operating system and is provided with a first peripheral interface, where the first peripheral interface is used to connect an intelligent auxiliary device and a storage device.

[0041] Optionally, the first core can be a Cortex-A core. The Cortex-A core has the ability to run general operating systems such as Linux / Android, and can support complex protocol stacks and data transmission of large amounts of data. Based on this, the first core can be used to process complex tasks, especially control and response tasks of high-bandwidth and low-real-time data, such as intelligent human-computer interaction response tasks.

[0042] The first core can be used to process control response tasks with low real-time requirements in the driver's cab, and the first core can also be used to perform data storage control in the driver's cab.

[0043] Low real-time requirements are relative to high real-time requirements. High real-time requirements refer to high demands on the timeliness of control responses, while low real-time requirements can refer to less stringent demands on the timeliness of control responses. Furthermore, control response tasks with low real-time requirements often correspond to high-bandwidth data, especially data traffic that has surged with the development of intelligent technologies. Running a large, general-purpose operating system on the primary core (such as the Cortex-A core) can meet the stable transmission requirements of low-real-time, high-bandwidth data, such as video streams and diagnostic logs.

[0044] Optionally, the first peripheral interface may include an Ethernet interface and a USB interface, wherein the Ethernet interface may be used to connect to the intelligent auxiliary device, and the USB interface may be used to connect to a storage device, such as a solid-state disk (SSD), to store video and log data. In addition, the Ethernet interface may be connected to a gigabit PHY (Physical, PHY, port physical layer) chip (such as KSZ9031) via the Reduced Gigabit Media Independent Interface (RGMII), supporting the TCP / IP protocol stack.

[0045] In one possible implementation, the aforementioned intelligent assistant device may include a touch screen and / or a voice interaction component.

[0046] Exemplarily, the first core of the controller 1 can communicate with the touch screen via low-voltage differential signaling (LVDS), and the first core and the voice interaction component can communicate with each other via a universal asynchronous receiver / transmitter (UART).

[0047] In addition, the aforementioned intelligent auxiliary device may further include a Beidou satellite communication module, and the first core and the Beidou satellite communication module may communicate via UART.

[0048] Based on this, the first core can be used to implement at least one of the voice recognition control response and touch interaction control response in the driver's cab. This type of control response task usually involves high-bandwidth data, and the processing logic is also relatively complex. With the general operating system running on the first core, it can be used to implement complex applications such as human-computer interaction, voice control, positioning navigation, etc.

[0049] The aforementioned general operating system may be any one of Linux, Vxworks, QNX, etc. In order to have a wide community support, the general operating system may optionally be a Linux system.

[0050] The second kernel runs a real-time operating system and is provided with a second peripheral interface, where the second peripheral interface is used to connect to a driver's cab environment control device.

[0051] Optionally, the second core may be a Cortex-M core, which has the ability to run a real-time operating system or bare-metal programs; based on this, the second core can handle real-time tasks such as sensor signal acquisition and motor control. The environmental control device described in this application may include sensors and actuators related to environmental control.

[0052] The second core is used to process control response tasks with high real-time requirements in the driver's cab.

[0053] Control response tasks with high real-time requirements often correspond to low-bandwidth data. By running a real-time operating system on a secondary core (such as a Cortex-M core), the low-latency response requirements for high-real-time data, such as brake control commands, sensor data, and safety alerts, can be met.

[0054] Optionally, the second peripheral interface may include a CAN (Controller Area Network) bus interface and a serial communication standard RS-485 bus interface. The CAN bus can be connected to the locomotive braking system, sensors, etc. via an embedded network architecture FlexCAN module. The RS-485 bus can use an isolated transceiver (such as the ADM2587E) to connect to instrumentation and supports the industrial communication protocol Modbus.

[0055] In one possible implementation, the driver's cab environment control device may include at least one of the driver's cab dimming glass, heater, ceiling light, wiper, electric curtain, reading light, air conditioner, etc.; based on this, the second core can be used to control at least one of the environment control devices among the dimming glass, heater, ceiling light, wiper, electric curtain, reading light and air conditioner set in the driver's cab.

[0056] Optionally, the second core in the controller 1 can communicate with the reading light / ceiling light via PWM signals, the second core can communicate with the electric curtains / heater / wiper / dimming glass via IO signals, and the second core can communicate with the air conditioner via Ethernet signals.

[0057] The aforementioned real-time operating system can be any one of FreeRTOS, uC / OS-II, RT-Thread, etc. Optionally, the real-time operating system can be FreeRTOS, which has advantages over other real-time operating systems such as small memory usage and a rich community ecosystem.

[0058] Based on the above, this application configures a multi-core heterogeneous controller based on the organization of cab control functions and communication information. It also categorizes cab control functions according to their response time requirements, assigning tasks requiring high real-time performance to the second core and other tasks to the first core, thus meeting the varying real-time requirements of different control functions. Furthermore, by centralizing the functions of multiple existing control devices into a single controller, the number of controllers is significantly reduced, thereby lowering the hardware cost of implementing cab control tasks.

[0059] The multiple peripheral interfaces provided by the first and second cores enable compatibility with a variety of industrial communication protocols. Furthermore, standardized interfaces are reserved on both the first and second cores to facilitate the integration of new devices and support functional upgrades, thus meeting the long-term needs of vehicle intelligence development.

[0060] It should be noted that the locomotive cab control system includes a variety of data acquisition sensors and actuators. With the development of intelligent technology, driver control methods have expanded from conventional button control to intelligent control methods such as touch control and voice command control. Data acquisition, processing, and communication tasks related to the locomotive cab control system are all implemented by controller 1. Although control functions are independently executed by different cores to meet real-time response requirements, complex logical dependencies often exist between different control functions, necessitating data communication between these cores.

[0061] The first core 11 and the second core 12 perform inter-core communication via an on-chip bus.

[0062] Optionally, the on-chip bus can be an AXI (Advanced eXtensible Interface) bus. Based on the above, controller 1 physically connects different cores to each other via an internal bus. Using an on-chip bus such as the AXI bus, high-speed data exchange between cores can be achieved, thereby meeting the requirements for multi-core collaborative control. This application utilizes a dual-core architecture and inter-core communication mechanism to reduce the difficulty of designing the driver's cab communication topology.

[0063] Based on the above content, the locomotive driver's cab controller provided by this application includes a first core and a second core. The first core runs a general operating system, and the second core runs a real-time operating system. The first core handles low real-time tasks in the driver's cab, and the second core handles high real-time tasks in the driver's cab. Based on this, this application uses a multi-core structure to isolate complex tasks and high real-time tasks and run them in different cores, meeting the control requirements with different real-time requirements in the driver's cab; on this basis, the first core and the second core communicate between cores through the on-chip bus, meeting the data interaction requirements between different cores, realizing data fusion between different cores, and providing a basis for realizing multi-core collaborative control tasks.

[0064] In addition, this application integrates independent complex control functions in the driver's cab into a single controller, reducing the number of controller hardware, reducing wiring complexity, saving controller costs, and reducing the difficulty of installation and spatial layout of the driver's cab controller; this application uses a heterogeneous dual-core structure to solve the problem of insufficient real-time performance or limited bandwidth of traditional single-core controllers or homogeneous multi-core controllers when facing multiple control tasks.

[0065] In one or more embodiments provided in this application, the first core and the second core perform inter-core communication via an on-chip bus, which may include:

[0066] The first core and the second core perform first data communication via an on-chip bus by combining a message queue with a hardware interrupt;

[0067] The first data communication is data communication in which the data volume of a single frame is not greater than a preset data volume threshold.

[0068] Optionally, the data volume threshold may be 1 kB; that is, communication data with a single frame of data not larger than 1 kB may be defined as small blocks of data, and inter-core communication may be performed using a combination of message queues and hardware interrupts.

[0069] In one possible implementation, the message queue described in this application may adopt the following message format: message header + data payload, wherein the message header may include 2B of message type and 2B of message length information, and the data payload may include a maximum of 256B of data.

[0070] In addition, the message queue described in this application can support a heartbeat packet mechanism. Exemplarily, the health status of the queue can be detected according to a preset heartbeat period (such as 100ms).

[0071] In one or more embodiments provided herein, a process in which the first core and the second core communicate with each other using a combination of message queues and hardware interrupts may include:

[0072] The sending end core writes communication data (i.e., small blocks of data) to the message queue of the locomotive cab controller, and sends an interrupt instruction to the receiving end core through the interrupt control hardware of the locomotive cab controller to instruct the receiving end core to read data from the message queue after receiving the interrupt instruction.

[0073] The first core and the second core serve as the sending end core and the receiving end core respectively, that is, when the first core serves as the sending end core, the second core serves as the receiving end core; when the second core serves as the sending end core, the first core serves as the receiving end core.

[0074] For example, the second kernel running the real-time operating system FreeRTOS can send an emergency event to the first kernel running the Linux system through the inter-process communication IPC interrupt controller. After the first kernel responds to the interrupt, it calls a kernel module, such as a custom IRQ Handler, to process the alarm data.

[0075] Based on the above content, this application implements the data synchronization task of small blocks of data between cores by using the message queue communication method triggered by hardware interrupts.

[0076] In one or more embodiments provided herein, a process in which the first core and the second core communicate with each other using a combination of message queues and hardware interrupts may include:

[0077] The OpenAMP module of the sending end core sends an interrupt request to the IPCC module of the receiving end core through the IPCC module of the sending end core, so as to instruct the IPCC module of the receiving end core to perform channel detection;

[0078] After detecting an idle channel, the IPCC module of the receiving end core sends a confirmation instruction to the OpenAMP module of the sending end core through the IPCC module of the sending end core, to indicate that the receiving end core has received the interrupt request;

[0079] The OpenAMP module of the sending end kernel writes the communication data to the message queue based on the shared memory after receiving the confirmation instruction, and the receiving end kernel detects the state of the shared memory address corresponding to the message queue;

[0080] After detecting that the shared memory address corresponding to the message queue is idle, the receiving end kernel copies the communication data in the message queue.

[0081] The first core and the second core serve as the sending end core and the receiving end core respectively.

[0082] Figure 2 Taking the example of a second kernel (i.e., the FreeTTOS kernel) sending communication data to a first kernel (i.e., the Linux kernel), a message queue-based data synchronization sequence diagram between the first and second kernels is shown. Data synchronization sequence refers to the implementation method of data synchronization, which includes periodic data synchronization and event-triggered data synchronization. Periodic data synchronization involves multiple sequence times, while event-triggered data synchronization involves a single sequence time. Furthermore, different kernels share a hardware RTC clock for time synchronization. Specifically, the synchronization messages sent by the kernels can carry timestamp information to ensure the timing correctness of each inter-core communication.

[0083] It should be noted that message queues require shared memory to store data, but unlike the multi-core communication method based on shared memory, the multi-core communication method based on message queues uses a hardware interrupt mechanism and has higher real-time data reading and writing performance, but it is difficult to apply to inter-core communication with large amounts of data. In other words, Figure 2 The shared memory mentioned in the description refers to the shared memory related to the message queue, not the shared memory involved in the multi-core communication method based on shared memory.

[0084] Combine Figure 2As shown, the second core sends data through the OpenAMP protocol. The OpenAMP protocol first notifies the underlying hardware HAL_IPCC of the second core to generate a hardware interrupt message and sends a Tx An interrupt request (also known as a message request) is sent to the IPCC hardware module of the first core. After receiving the interrupt request, the IPCC hardware module of the first core checks whether the channel is available. If it is available, it replies with a confirmation message (for example, Confirm = 1) to indicate that the first core has received the interrupt request. After receiving the confirmation message (for example, Confirm = 1), the HAL_IPCC of the second core notifies the OpenAMP protocol to start writing data to the shared memory corresponding to the message queue of the second core. After sending the confirmation message (for example, Confirm = 1), the first core instructs the driver of the first core (included in the general operating system running on the first core) to check whether the shared memory address of the corresponding channel is busy to determine whether the second core has completed the data write. When the shared memory address is not busy, that is, the data write is complete, the written data can be read by the first core. The shared memory (i.e., the driver within the general operating system that manages the system memory) reads the data and copies it to the Mailbox driver (i.e., the driver within the general operating system that manages the mailbox hardware). Finally, it is delivered to the application (i.e., the user program that runs on the general operating system and implements specific functions by calling the driver in the operating system) through the Linux embedded component RPMsg, completing the data communication process between the first and second cores.

[0085] It should be noted that no matter which multi-core communication method is adopted, when shared memory is involved, the core as the receiving end needs to perform a busy check to detect whether the core as the sending end has completed writing data, and then the receiving end can read the data after the sending end completes writing data.

[0086] In one or more embodiments provided in this application, the first core and the second core perform inter-core communication via an on-chip bus, which may include:

[0087] The first core and the second core perform second data communication via an on-chip bus in a shared memory manner.

[0088] The second data communication is data communication with a data volume greater than a preset data volume threshold. Optionally, the data volume threshold may be 1kB; that is, communication data with a single frame data greater than 1kB may be defined as large block data, and inter-core communication may be performed using shared memory.

[0089] In one or more embodiments provided in the present application, a process of performing inter-core communication between the first core and the second core using a shared memory manner may include:

[0090] The sending core writes the communication data to a preconfigured memory area for the receiving core to read.

[0091] The preconfigured memory area is a memory area in the locomotive cab controller that is preconfigured to be shared by the first core and the second core.

[0092] Optionally, the memory area can be divided, with a portion of the memory area set as a shared memory area between the first and second cores. For example, the area can be larger than 10 MB. Furthermore, permissions for the shared memory area can be configured using the Memory Management Unit (MMU), such as configuring different read and write permissions for the first and second cores.

[0093] The first core and the second core serve as the sending end core and the receiving end core respectively.

[0094] Based on the above content, this application realizes the data sharing task of large blocks of data between cores through shared memory management.

[0095] In addition, data blocks can be divided into data categories. For example, a 12MB data block 1 can be allocated to store video streams and log files. Optionally, data block 1 can be managed using a ring buffer. A 4MB data block 2 can be allocated to store real-time command status. Optionally, data block 2 can be defined as a bit field structure.

[0096] This application meets the inter-core data communication tasks with large differences in data volume involved in the locomotive driver's cab controller by using the large-block data inter-core communication method of shared memory and the small-block data inter-core communication method of message queue-hardware interrupt, and further improves the inter-core communication efficiency by using hardware interrupts, realizing efficient and reliable inter-core communication tasks, and providing a basis for improving the reliability of control function implementation.

[0097] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or device comprising the element.

[0098] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referenced to each other.

[0099] The above description of the disclosed embodiments is intended to enable one skilled in the art to implement or use the present application. Various modifications to these embodiments will be readily apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application is not limited to the embodiments shown herein, but is intended to conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A locomotive cab controller, characterized in that: include: a first core and a second core; The first core runs a general-purpose operating system and is provided with a first peripheral interface, wherein the first peripheral interface is used to connect to an intelligent auxiliary device and a storage device; the first core is used to process control response tasks with low real-time requirements in the driver's cab, and the first core is also used to control data storage in the driver's cab; The second core runs a real-time operating system and is provided with a second peripheral interface, wherein the second peripheral interface is used to connect to a driver's cab environment control device; the second core is used to process control response tasks with high real-time requirements in the driver's cab; The first core and the second core perform inter-core communication via an on-chip bus.

2. The locomotive cab controller according to claim 1, characterized in that: The first core and the second core perform inter-core communication via an on-chip bus, including: The first core and the second core perform first data communication via an on-chip bus by combining a message queue with a hardware interrupt; the first data communication is data communication in which the amount of data in a single frame is not greater than a preset data amount threshold.

3. The locomotive cab controller according to claim 2, characterized in that: The process of performing inter-core communication between the first core and the second core by combining a message queue with a hardware interrupt includes: The sending end core writes communication data to the message queue of the locomotive cab controller, and sends an interrupt instruction to the receiving end core through the interrupt control hardware of the locomotive cab controller to instruct the receiving end core to read data from the message queue after receiving the interrupt instruction; the first core and the second core serve as the sending end core and the receiving end core respectively.

4. The locomotive cab controller according to claim 2, characterized in that: The process of performing inter-core communication between the first core and the second core by combining a message queue with a hardware interrupt includes: The OpenAMP module of the sending end core sends an interrupt request to the IPCC module of the receiving end core through the IPCC module of the sending end core, so as to instruct the IPCC module of the receiving end core to perform channel detection; After detecting an idle channel, the IPCC module of the receiving end core sends a confirmation instruction to the OpenAMP module of the sending end core through the IPCC module of the sending end core, to indicate that the receiving end core has received the interrupt request; The OpenAMP module of the sending end kernel writes the communication data to the message queue based on the shared memory after receiving the confirmation instruction, and the receiving end kernel detects the state of the shared memory address corresponding to the message queue; After detecting that the shared memory address corresponding to the message queue is idle, the receiving end kernel copies the communication data in the message queue; The first core and the second core serve as the sending end core and the receiving end core respectively.

5. The locomotive cab controller according to claim 1, characterized in that: The first core and the second core perform inter-core communication via an on-chip bus, including: The first core and the second core perform second data communication via an on-chip bus in a shared memory manner, and the second data communication is data communication with a data volume greater than a preset data volume threshold.

6. The locomotive cab controller according to claim 5, characterized in that: The process of performing inter-core communication between the first core and the second core using a shared memory method includes: The sending end core writes communication data to a preconfigured memory area for reading by the receiving end core; wherein the preconfigured memory area is a memory area in the locomotive cab controller that is pre-configured to be shared by the first core and the second core; the first core and the second core serve as the sending end core and the receiving end core respectively.

7. The locomotive cab controller according to any one of claims 1 to 6, characterized in that: The second core is a Cortex-M core; and / or the first core is a Cortex-A core.

8. The locomotive cab controller according to any one of claims 1 to 6, characterized in that: The real-time operating system is a FreeRTOS system; and / or the general operating system is a Linux system.

9. The locomotive cab controller according to any one of claims 1 to 6, characterized in that: The first peripheral interface includes an Ethernet interface and a USB interface; The Ethernet interface is used to connect to the intelligent auxiliary device; The USB interface is used to connect to the storage device.

10. The locomotive cab controller according to any one of claims 1 to 6, characterized in that: The second peripheral interface includes a CAN bus interface and an RS-485 bus interface.

Images