Rail transit vehicle air conditioner software architecture and software development method

Abstract

The invention discloses a rail transit vehicle air conditioner software architecture and a software development method, and relates to the field of software development, the framework comprises an application layer, a real-time operating system layer, a board-level firmware layer, a standard peripheral layer, a register layer and a physical layer, and a corresponding file structure is designed according to the software architecture; on the basis, the software development method comprises the following steps: configuring input and output points; initializing a unit; defining a unit working mode; analyzing a working mode; setting unit operation conditions and protection functions; executing a working mode; communication setting with an upper computer; the fault information setting is transmitted to the PTU; and setting network communication. According to the method, a software architecture and a file structure are designed according to a hierarchical structure, and universal programs and functional modules are written into the designed file structure. When a new project is developed, development is completed on the basis, the logic requirement of the new project can be met through modification, the workload of software programming is greatly reduced, and the working efficiency is improved.

Description

Technical Field

[0001] The present invention relates to the field of software development, and particularly to an air-conditioning software architecture for rail transit vehicles and a method for developing air-conditioning software for rail transit vehicles based on the software architecture. Background Art

[0002] The design of the air-conditioning software for rail vehicles is a complex process, involving multiple considerations, including hardware design, intelligent control, air purification, pressure protection, duct design, temperature and humidity control, and intelligent operation and maintenance, etc.

[0003] The traditional air-conditioning software for rail vehicles has no unified software architecture, and there is a very strong coupling relationship between the upper-layer application software and the operating system, board-level firmware library layer, and physical layer. The software design and modification involve a wide range, which also results in a very high software maintenance cost in the later stage.

[0004] In the current development method, the software has no inheritance, and it is necessary to develop layer by layer from the physical layer to the application layer, which greatly increases the workload of software designers and the development cycle. With the diversification of the design requirements of rail vehicle air conditioners, the scale of rail vehicle air-conditioning software is increasing day by day. There is an urgent need for an open, unified, and modular software architecture to reduce the workload of software programming, shorten the R & D cycle, and improve work efficiency. Summary of the Invention

[0005] The present invention aims to solve the above-mentioned defects and problems existing in the air-conditioning software for rail vehicles, and provides an air-conditioning software architecture for rail transit vehicles.

[0006] To achieve the purpose of the invention, on the one hand, the present invention proposes an air-conditioning software architecture for rail transit vehicles, including: An application layer, which is used to implement the functions of the air-conditioning software for rail transit vehicles; a real-time operating system layer, which is used to support the software system; a board-level firmware layer, which serves the application layer, and all the logics and operations of the application layer are realized by calling the functions of this layer; a standard peripheral layer, which serves the board-level firmware layer and stores the standard peripheral library; a register layer, which serves the standard peripheral layer and the real-time operating system layer, defines the device name definitions, address definitions, interrupt vectors, and helper functions of the peripheral registers used to access the kernel, and also defines an interface independent of the microcontroller for the real-time operating system. A physical layer, which serves the register layer and defines the hardware peripherals used by the air-conditioning system.

[0007] Further, a corresponding file structure is designed according to the software architecture, and the directory of the file structure includes: The app stores the application layer code; the bsp stores the source files of the board-level library; the doc stores the software description information; the includes stores the common header files of the standard library and the header file of the main function; the Libraries stores the files of the register layer; the Main stores the main function file; the Project stores the files generated by compilation and the header file of the software firmware number; the Rots stores the code files related to the real-time operating system.

[0008] On the other hand, the present invention also proposes a software development method for the air conditioner of rail transit vehicles based on the above software architecture, including the following steps: input / output point configuration; unit initialization; unit working mode definition; working mode analysis; unit operating conditions and protection function settings; working mode execution; communication setting with the upper computer; fault information setting transmitted to the PTU; network communication setting.

[0009] Beneficial effects: The present invention designs the software architecture according to the hierarchical structure, designs the file structure according to the levels and functions of the software architecture, and writes the general programs and functional modules into the designed file structure. When developing a new project, it is developed based on this, and after modification, it can meet the logical requirements of a new project, greatly reducing the workload of software programming and improving work efficiency. Description of the Drawings

[0010] Figure 1 is a schematic diagram of the composition of the software architecture of the air conditioner of rail transit vehicles; Figure 2 is a schematic diagram of the file structure. Detailed Embodiments

[0011] A software architecture for the air conditioner of rail transit vehicles, see Figure 1 , including: application layer, real-time operating system layer, board-level firmware layer, standard peripheral layer, register layer and physical layer.

[0012] The application layer is the topmost code, used to implement the software functions of the air conditioner of rail transit vehicles, developed according to the project requirements, and is also the part with the largest changes in a new project. Software developers mainly modify the application layer.

[0013] The real-time operating system layer ported the operating system kernel code of FreeRTOS into the project through code transplantation to support the software system.

[0014] The board-level firmware layer stores the board-level firmware library, and the functions therein are realized through independent development when establishing the software framework, serving the application layer, and all the logics and operations of the application layer are realized by calling the functions of this layer.

[0015] The standard peripheral layer, through code transplantation, adds the standard peripheral library to the project, facilitating the invocation of various peripherals of the chip and serving the board-level firmware layer.

[0016] The library functions are stored in the board-level firmware layer and the standard peripheral layer.

[0017] The register layer (CMSIS layer), originating from the CMSIS standard definition, serves the standard peripheral layer and the real-time operating system layer. It defines the device name definitions, address definitions, interrupt vectors, and helper functions for accessing the peripheral registers of the kernel. At the same time, it also defines an interface independent of the microcontroller for the real-time operating system.

[0018] CMSIS (Cortex Microcontroller Software Interface Standard) is a set of standards defined by ARM in cooperation with multiple different chip and software vendors, aiming to provide a consistent software interface for microcontrollers based on ARM Cortex processors. The main objectives of CMSIS are to simplify software reuse, reduce the learning curve for microcontroller developers, shorten the time to market for new devices, and reduce software development costs.

[0019] CMSIS can be divided into multiple software levels, mainly including the following parts: CMSIS-Core (Cortex-M kernel): This is the most important part of the CMSIS standard. It includes the kernel function layer, which contains the name and address definitions for accessing the kernel registers, mainly provided by ARM.

[0020] CMSIS-RTOS: Provides the general API for real-time operating systems and a reference implementation based on RTX, encapsulating and unifying the kernel operation interfaces of various real-time operating systems, mainly provided by ARM.

[0021] CMSIS-DSP library: Provides a set of optimized digital signal processing libraries, including common mathematical functions, filter functions, vector operations, etc. These functions are optimized and can be executed efficiently on the Cortex-M kernel.

[0022] CMSIS-Driver interface: Provides interfaces for many microcontroller families.

[0023] CMSIS-Pack: Defines the structure of software packages containing software components.

[0024] CMSIS-SVD file: Enables a detailed view of the device peripherals and the current register status.

[0025] CMSIS-DAP: Standardizes the interface of the Cortex Debug Access Port (DAP).

[0026] CMSIS-NN: Provides a series of efficient neural network kernels.

[0027] CMSIS-View: Provides visibility into the internal operations of applications and software components.

[0028] CMSIS-Compiler: Redirects the I / O functions of the standard C runtime library.

[0029] CMSIS-Toolbox: Provides a set of command-line tools for processing software packages.

[0030] CMSIS-Stream: Provides tools and methods for optimizing the data flow of DSP / ML blocks.

[0031] CMSIS-Zone: Defines methods for describing system resources and partitioning them.

[0032] CMSIS enables developers to more easily perform software development and transplantation on different microcontroller platforms by providing a common interface between the kernel and peripherals, real-time operating systems, and middleware devices.

[0033] The physical layer, which serves the register layer, defines the hardware peripherals used by the air-conditioning system. The physical layer is a completely hardware concept that defines the hardware at the chip level, and ultimately operates on the I / O pin resources of the CPU through the above software.

[0034] The physical layer includes the definition of the Cortex CPU (microcontroller), SysTick real-time kernel timer, NVIC nested vector interrupt register, debug / trace interface, and other peripherals.

[0035] The above logically determines the software architecture of the rail transit vehicle air conditioner.

[0036] After years of research and development, the composition of the air-conditioning system of rail vehicles has been basically finalized. For example, the operating system basically does not change, and the board-level libraries of the independently developed board-level firmware can be made universal.

[0037] For the convenience of implementation, the present invention proposes to design a corresponding file structure according to the software architecture. See Figure 2 , with the root directory being Source, and the directories of the file structure including: app, bsp, doc, includes, Libraries, Main, Project, Rots.

[0038] There is a partial correspondence between the software architecture and the file structure. The correspondence relationship is as follows from top to bottom: The application layer corresponds to app; the real-time operating system layer corresponds to rtos; the board-level firmware library corresponds to bsp; the standard peripheral library corresponds to library; there is no corresponding file structure content for the registers and microcontroller (physical layer), which is the physical layer representation of the CPU, and the other files in other directories are other supporting files required for the project.

[0039] The app folder contains two sub-folders, namely Inc and src, and the contents of the folders are the header files and source files of the application layer code.

[0040] The embodiments are as follows: The contents of the bsp folder are the source files and header files of the board-level library.

[0041] The following table is an embodiment: The doc folder does not contain sub-folders, only an About.txt file, and the content is some explanatory information about the software.

[0042] The includes folder does not contain sub-folders. This folder contains some general header files in the standard library, as well as the main function header (version information) file and the header file that includes other header files.

[0043] The standard library refers to the official driver library provided by the chip manufacturer.

[0044] Libraries stores the files of the register layer, including the CMSIS folder and the STM32F10x_StdPeriph_Driver folder.

[0045] The Main folder does not contain sub-folders and stores the main function file.

[0046] The Project folder does not contain sub-folders and mainly contains the files generated by compilation and the firmware number header file of the software.

[0047] The Rtos folder mainly contains the code files related to the operating system.

[0048] The above structure defines all the basic functional files and call relationships, and can support the configuration and logical requirements of different projects. If new hardware is used, only the supporting files need to be added.

[0049] On the basis above, the present invention also provides an embodiment of a software development method based on the software architecture of a rail transit vehicle air conditioner.

[0050] When developing a new project, first, according to the design requirements, the library functions are improved on the software architecture, mainly for the board-level firmware layer, that is, adding and deleting files in the bsp folder. Generally speaking, after the board-level hardware R & D is completed, its source files need to be immediately added to the bsp. The source files of the board-level hardware not used in the project stored in the bsp folder do not affect the execution of the project, and deletion is not necessary.

[0051] The main work in the development of a new project is to configure and modify the application layer.

[0052] In this embodiment, the software development method includes steps such as input / output point configuration, unit initialization, unit working mode definition, working mode analysis, unit operating condition and protection function setting, working mode execution, communication setting with the upper computer, fault information setting transmitted to the PTU, network communication setting, etc.

[0053] The above modifications are all carried out in the application layer, and the corresponding folder is app.

[0054] The following steps do not have a strict order, and the order here is only for convenience of description.

[0055] 1. Input / output point configuration.

[0056] Input / output point configuration includes corresponding the I / O points of the CPU to the devices of the unit through the input / output points of the control panel. This process is mainly developed based on the electrical control circuit schematic diagram. This step is the basis for realizing software functions. For the controller, the input / output points are the I / O points of the CPU, and signals are input and output through the input / output circuit of the controller to control the devices on the control panel; for the control panel, the input / output points are contactors, such as the input / output points of intermediate relays, circuit breakers, air switches, knob switches, etc., and the unit is controlled through the input / output points on the control panel; for the unit, the input / output points are the points that can control the power on and off of the unit devices and can receive the unit status signals.

[0057] The purpose of input / output point configuration is to correspond the I / O points of the CPU to the devices of the unit.

[0058] The digital input and output points are mainly configured in the Define.c file, and the analog input points are mainly configured in the TempApp.c file. The following is a simple example of the configuration of the input and output points.

[0059] Configuration of the contactor input and output points.

[0060] CONTACTOR_Init(&Contactor[CttVTL],IN_XS6_B1,OUT_XS3_A3); CONTACTOR_Init(&Contactor[CttVTLC],IN_XS6_B4,OUT_XS3_D3); The above is the configuration of the fan contactor. This configuration is made in the Define.c file, where CttVTL and CttVTLC represent the fan contactor and the condenser fan contactor respectively, and IN_SX6_B1, OUT_XS3_A3, IN_SX6_B1, and OUT_XS3_A3 are the corresponding input and output points of the fan and the condenser fan that can be found from the electrical control circuit schematic diagram.

[0061] Configuration of the input points of the rotary switch.

[0062] FunctionSwitch.PinNum = 6; FunctionSwitch.InputPin[5] = IN_XS12_A2; FunctionSwitch.InputPin[4] = IN_XS13_D2; FunctionSwitch.InputPin[3] = IN_XS13_B1; FunctionSwitch.InputPin[2] = IN_XS13_A3; FunctionSwitch.InputPin[1] = IN_XS13_A2; FunctionSwitch.InputPin[0] = IN_XS7_D2; The above is the configuration of the input points of the rotary switch. This configuration is made in the Define.c file, where FunctionSwitch.PinNum represents the number of input points of the rotary switch, and FunctionSwitch.InputPin is the input point number that can be found on the electrical control schematic diagram.

[0063] Configuration of the input points for unit protection.

[0064] PRESSUREHigh_Init(&PressureHigh[0],IN_XS12_C4,&Contactor[CttCPS1]); CPSOVERLOAD_Init(&CPSOverLoad[0],IN_XS5_D2,&Contactor[CttCPS1]); The above is the configuration of the input points for the compressor high-pressure protection and the compressor overload protection. This configuration is made in the Define.c file. Among them, PRESSUREHigh_Init is the configuration of the input points for the compressor high-pressure protection: &PressureHigh[0] represents high-pressure protection 1, IN_XS12_C4 is the number of the high-pressure pressure switch input point that can be found on the electrical control circuit schematic diagram, and &Contactor[CttCPS1] represents the contactor corresponding to compressor 1. When a high-pressure fault occurs in compressor 1, its contactor will be disconnected; CPSOVERLOAD_Init is the configuration of the input points for the compressor overload protection: &CPSOverLoad[0] represents compressor overload protection 1, IN_XS5_D2 is the number of the compressor overload protection input point that can be found on the electrical control circuit schematic diagram, and &Contactor[CttCPS1] represents the contactor corresponding to compressor 1. After the compressor overload protection, the controller will control the contactor of the corresponding compressor to disconnect.

[0065] The above is only an example of the design of the input point configuration for unit protection. The configuration methods for other protections are similar and will not be elaborated here.

[0066] Configuration of temperature sensor input points.

[0067] TEMPERATURE TempReturn11={NTC_XS9_A1}; TEMPERATURE TempSend11={NTC_XS9_A2}; TEMPERATURE TempNew11={NTC_XS9_A3}; The above is the configuration of the temperature sensor input points. This configuration is made in the TempAPP.c file. Among them, TEMPERATURE represents the definition of a temperature sensor, TempReturn11 represents the return air temperature sensor, NTC_XS9_A1 is the input point number of the return air temperature sensor that can be found in the electrical control circuit schematic diagram, TempSend11 represents the supply air temperature sensor, NTC_XS9_A2 is the input point number of the supply air temperature sensor that can be found on the electrical control circuit schematic diagram, TempNew11 represents the fresh air temperature sensor, and NTC_XS9_A3 is the input point number of the fresh air temperature sensor that can be found on the electrical control circuit schematic diagram.

[0068] 2. Unit initialization.

[0069] The above work has corresponded the devices of the unit with the input and output points of the control panel controller. However, in some cases, one controller controls two units, and one unit often has to be divided into two refrigeration systems.

[0070] The initialization of the unit is to group the already corresponding input and output points according to the situation of the unit. The unit initialization is also carried out in the Define.c file.

[0071] Example of unit initialization.

[0072] COMPRESSORInit.Contactor=&Contactor[CttCPS1]; COMPRESSORInit.Group=0; COMPRESSORInit.MinRunTime=SYS_Time(3,0,0); COMPRESSORInit.MinStartTimeSelf=SYS_Time(0,30,0); COMPRESSORInit.LiquidValvePin=OUT_PINNONE; COMPRESSORInit.BypassValvePin=OUT_PINNONE; COMPRESSORInit.CapValvePin=OUT_PINNNOE; COMPRESSOR_Init(&CompressorG[0].CDev[0], COMPRESSORInit); COMPRESSORInit.Group=1; COMPRESSORInit.Contactor=&Comtactoe[CttCPS2]; COMPRESSOR_Init(&CompressorG[0].CDev[1], COMPRESSORInit); COMPRESSORGInit.TotalCout=2; COMPRESSORGInit.NeedAverageFirst=1; COMPRESSORGInit.MinStartTimeOther=SYS_Time(0,5,0); COMPRESSORGInit.MinStopTimeOther=SYS_Time(0,5,0); COMPRESSORG_Init(&Compressorg[0], COMPRESSORGInit); From the initialization of the unit compressors above, it can be seen that this system has one unit and two refrigeration systems. Among them, Compressorg[0] represents one unit, and COMPRESSORInit.Group = 0 and COMPRESSORInit.Group = 1 under one unit divide the unit into two refrigeration systems. If there are two units in the system, an additional Compressorg[1] will be defined to represent Unit 2.

[0073] The above is the initialization of the compressor. The initialization of the unit's ventilator, condenser fan, electric heating, exhaust fan, etc. is similar and will not be elaborated here.

[0074] 3. Definition of unit working modes.

[0075] In general projects, units usually have different working modes: ventilation, refrigeration, heating, emergency ventilation, shutdown, etc. For different working modes, different devices in the unit need to work, and the software needs to schedule the corresponding input and output points to control the unit according to these working modes. Defining the unit working modes is the basis for the software to control the unit to work under different working conditions. Only with these working mode definitions can the requirements of the air conditioner working modes in specific projects be met.

[0076] Example of defining unit working modes.

[0077] Void SYSMODE_L1Cool(void) { SYSTEM_NeedStart.VTL_NeedStart = 2; SYSTEM_NeedStart.VTLFP_NeedStar = 2; SYSTEM_NeedStart.VTLC_NeedStar = 1; SYSTEM_NeedStart.CPS_NeedStar = 1; } The definition of the unit working mode is carried out in the Task_WorkMode.c file. The above is the definition of the first-stage refrigeration of the air-conditioning unit. VTL_NeedStart represents the number of ventilators that need to be started, VTLFP_NeedStart represents the number of exhaust fans that need to be started, VTLC_NeedStart represents the number of condensing fans that need to be started, and CPS_NeedStart represents the number of compressors that need to be started. Therefore, through the definition of this function, it is defined that for the first-stage refrigeration of the unit, 2 ventilators, 2 exhaust fans, 1 condensing fan, and 1 compressor need to be started.

[0078] The definitions of other working modes of the unit are similar and will not be elaborated here.

[0079] 4. Working mode analysis.

[0080] The air-conditioning unit needs to work in different working modes according to the "environment" status. The software needs to analyze the "environment" data and control the unit to work in different working modes.

[0081] The "environment" factors that determine the working mode of the air conditioner are: knob switch position, vehicle network data, and ambient temperature status. The software will comprehensively analyze these factors to determine the working mode that the current air conditioner should be in.

[0082] Example of working mode analysis.

[0083] if (FunctionSwitchValve == FUNCTION_MODEEMVTL) { SYSTEM_SetWorkMode(SYSMODE_EMVTL); } else if (NET_Cmd_Get(Cmd_ACC_Force_ventilation)) { SYSTEM_SetWorkMode(SYSMODE_VTL); } else { WorkModeGet = WORKMODE_AnalyOnlyTemp(); SYSTEM_SetWorkMode(WorkModeGet); } The analysis of the working mode is carried out in the WorkModeAnaly.c file. For the convenience of illustration above, the content of the working mode analysis of a normal project is streamlined. The content after if is the working mode of the unit determined by the gear of the knob switch, the content after else if is the working mode of the unit determined by the network signal, and the content after else is the working mode of the unit determined by the ambient temperature. Since the program is executed sequentially, the software gives priority to the gear of the knob switch during the mode analysis process, then the network signal, and finally the data of the ambient temperature. Based on these data, the software will finally analyze a working mode and then control the unit to execute the corresponding working mode.

[0084] For different projects, the code for this part of the mode analysis will be very different. The specific process of mode analysis and the data sources for mode analysis also depend on different projects. It needs to be flexibly mastered in application.

[0085] 5. Unit operating conditions and protection function settings.

[0086] To ensure the safety of the air-conditioning unit, the air-conditioning unit has several protection functions, such as: power failure, ventilator overload, condenser overload, compressor overload, compressor high and low pressure failure, contactor failure, etc. These protection functions also need to be effectively controlled by software. At the same time, to enable the unit to operate as safely as possible, the software has also added some operating conditions for the operation of the unit components. To enable the unit to recover more quickly after a failure, specific logic has also been added to the failure recovery process after the unit's fault protection.

[0087] Example 1 of the establishment of unit operating conditions and protection functions.

[0088] U8 CDT_VTL5S(void* data) { if(VENTILATOR_GetRunningTime((VENTILATOR*)data) < SYS_Time(0, 5, 0)) return CONDITION_WAIT; return CINDITION_OK; } U8 CDT_VTLC15S(void* data) { If(VTLCONDENSE_GetRunningTime((VTLCONDENSE*)data)>SYS_Time(0, 15, 0)) return CONDITION_WAIT; return CONDITION_OK; } U8 PRESSUREHign_GetCondition(void* PressureHigh) { PRESSUREHIGH* p = (PRESSUREHIGH*)PressureHigh; if (p->State == PRESSUREHigh_State_Lock) return CONDITION_ERROR; else if (P->State == PRESSUREHigh_State_Normal) return CONDITION_OK; else return CONDITION_WAIT; } The settings of the unit operation conditions and protection functions are distributed in many files. For example, the overload protection of the ventilator is in the VTLOverLoade.c file, the high-pressure protection of the compressor is in the Pressurehigh.c file, the low-pressure protection of the compressor is in the Pressurelow.c file, and the restrictions on some start-up conditions of the unit devices are in the Define.c file, etc. The above are some typical conditions and protections.

[0089] The U8 CDT_VTL5S(void* data) function is used to limit the condition that the condensation fan can start only after the ventilator has started for 5S. The U8 CDT_VTLC15S(void* data) function is used to limit the condition that the compressor can start only after the condensation fan has started for 15S. The U8 PRESSUREHign_GetCondition(void* PressureHigh) function is the high-pressure protection condition of the compressor.

[0090] Example 2 of the establishment of unit operation conditions and protection functions.

[0091] VTLCONDENSE_AddRunCondition(&VTLCondenseG[0].CDev[0], CDT_VTL5S, &VentilatorG[0].CDev[0], 0x01, CONDITION_AND); COMPRESSOR_AddRunCondition(&COMPRESSORG[0].CDev[0], CDT_VTL5S, &VTLCondenseG [0].CDev[0], 0x01, CONDITION_AND); COMPRESSOR_AddRunCondition(&COMPRESSORG[0].CDev[0], PRESSUREHigh_GetCondition, &Pressurehigh[0], 0x01, CONDITION_AND); The addition of the unit operation conditions and protection functions is carried out in the Define.c file. Only some conditions and protections of the unit were established before, but these protections were not added to the devices of the unit. Therefore, in the above examples, the protections and conditions established before were added to the corresponding unit devices, making the protection functions effective. Among them, VTLCONDENSE_AddRunCondition is a function to add conditions to the condensing fan, and COMPRESSOR_AddRunCondition is a function to add conditions to the compressor. The first input parameter in the function is the device to which the conditions are added, the second input parameter is the condition to be added, the third parameter is the input parameter involved in the condition, the fourth input parameter is the condition priority, and the fifth parameter represents whether the condition is an AND condition or an OR condition.

[0092] The above examples are only a part of all the condition protections, and the detailed logic of these protections is not shown in the above examples. The logic details of these condition protections are similar according to the requirements of different projects, and will not be elaborated here.

[0093] 6. Execution of working mode.

[0094] After the above work is completed, the software has the ability to analyze the "environment" data, determine the working mode of the unit, and control the operation of the unit when the unit operation conditions are met. The execution of the working mode is to control the devices of the unit to operate in the corresponding working mode.

[0095] Design example of working mode execution.

[0096] VENTILATOR_NeedStartApp(&VentilatorG[0], SYSTEM_NeedStart.VTL_NeedStart); VTLCONDENSEG_NeedStartApp(&VTLCondenseG[0], SYSTEM_NeedStart.VTLC_NeedStart) COMPRESSORG_NeedStartApp(&CompressureG[0], SYSTEM_NeedStart.CPS_NeedStart); AIRDAMPER_Open(&AIRDAMPER[SYS_ADPNEW], AirDamperNewOpen); AIRDAMPER_Open(&AIRDAMPER[SYS_ADPRETURN], AirDamperReturnOpen); AIRDAMPER_Open(&AIRDAMPER[SYS_ADPFP], AirDamperFPOpen); The execution of the unit working mode is written in the Task_WorkMode.c file. Among them, the VENTILATOR_NeedStartApp function is the function for executing the working mode of the unit ventilator, the VTLCONDENSEG_NeedStartApp function is the function for executing the working mode of the unit condensing fan, and the COMPRESSORG_NeedStartApp function is the function for executing the working mode of the unit compressor. These three functions can not only specify the number of unit devices that should be started according to the working mode, but also ensure that the pre-stage device cannot stop running when the post-stage device has not stopped running. The AIRDAMPER_Open function is the function for controlling the opening angle of the air valve according to the working mode.

[0097] 7. Communication settings with the host computer.

[0098] In order to more conveniently and clearly monitor the operating status of the air-conditioning unit and facilitate the debugging work of the lower computer software, a host computer for monitoring and debugging is specially set up. The monitoring and debugging functions of the host computer are realized by sending and receiving data through the UART interface. The most important thing for communication with the host computer is to send data related to the unit status and parse the data received from the host computer.

[0099] Design example of communication with the host computer.

[0100] In order to complete the project more efficiently, this embodiment stipulates a relatively complete UART communication protocol, and the specific content is shown in the following table: Baud rate: 57600, start bit: 1, data bit: 8, stop bit: 1, no parity check.

[0101] The protocol transmission mode is master-slave response transmission, and each master frame corresponds to a slave frame.

[0102] The minimum time interval from the end of the previous master frame to the start of the next master frame is 5 ms, and the time interval from the end of the master frame to the start of the slave frame is less than 2 ms, that is, the minimum length of the master frame transmission time interval is the frame transmission time plus 5 ms.

[0103] Among them, frame header: 0xAA, fixed and unique; serial number: 0x00 - 0xFF (0 - 255), frame serial number, used to distinguish between two adjacent frames to prevent repeated processing of the same data frame in some cases; address: 0x00 - 0xFF, the master device has no address, and the slave device will set the highest bit of the slave device address sent by the master device as the address data of the slave device's response frame, and the master device uses this to determine whether this frame is the frame sent out or the frame received from the slave device; command word: 0x00 - 0xFF, used to represent the operation that the master device hopes to perform; data length: represents the byte length of the data in the data field, used to judge the correctness of the frame and receive the frame; data: the data that this frame needs to transmit, with no special requirements, and the length is limited within 100 bytes; check word: used to judge whether the transmitted command and data are correct, to prevent the error of the controller control output caused by the transmission error of the frame data, and two check methods of BCC and CRC16 are adopted. Double check is used to reduce the probability of error data and prevent the misoperation of the controller caused by error data. The calculation method of the check word is all the data from the frame header to the check word, and CRC16 is transmitted in little-endian mode; frame tail: 0x55, indicating the end of a data frame.

[0104] For software development engineers, different projects only need to modify the data segment in the frame, fill the data to be transmitted to the upper computer into the corresponding data segment, and parse the data to be obtained from the upper computer from the data frame.

[0105] 8. Setting of the fault information transmitted to the PTU.

[0106] The Portable Test Unit (PTU) refers to the "Portable Test Unit", which is a device for testing and detection, featuring portability, ease of carrying and operation. The PTU is usually designed to be lightweight and compact, facilitating use in different scenarios, including on-site testing, field trials, etc.; depending on the application scenario, the PTU can integrate multiple test functions, such as signal acquisition, data analysis, fault diagnosis, etc.; the PTU supports multiple interfaces and communication protocols, can adapt to different test requirements, and through the combination of software and hardware, the PTU can quickly complete test tasks and generate test reports.

[0107] For the traction, braking, network, air conditioning, safety detection, etc. installed in rail transit vehicles (such as the Fuxinghao CR400BF EMU), there are their own unique PTUs and service software.

[0108] During the long-term operation of the air conditioner, it will inevitably have some faults due to reasons such as the aging of air conditioner components. In order to better record and track the fault information generated by the air conditioner, it is necessary to transmit the fault information of the air conditioner to the PTU so that maintenance personnel can view and download the fault information of the air conditioner, facilitating air conditioner maintenance.

[0109] Example design of the fault information transmitted to the PTU.

[0110] The fault information adopts the communication protocol and frame format in the above communication settings with the upper computer. All data transmitted from the lower computer to the PTU is placed in the data segment of the frame. Similarly, the fault information of the PTU is also placed in the data segment of the frame and transmitted to the PTU.

[0111] Temp = CPSOVERLOAD_GetCondition((CPSOVERLOAD*)&CPSOverLoad[0]); if (CPSOVERLOAD_ReadPin((CPSOVERLOAD*)&CPSOverLoad[0]) == CPSOVERLOAD_YES) { SysError->E[ERROR_OLDCps1] = ERROR_OLDCps1 | ERROE_LEVELA; } The above is the judgment of the compressor overload fault. If the compressor is overloaded, a certain position in the array recording the real-time faults of the air conditioner will be set to 1, and this array will be sent to the PTU. In this way, the fault information of the air conditioner is transmitted to the PTU. The same principle applies to other faults of the air conditioner.

[0112] 9. Network communication settings.

[0113] After completing the above work, the unit can operate normally under the control of the software and can meet more than 80% of the requirements. The air conditioners installed on the vehicle are all connected to the vehicle network and are generally under the unified control of the vehicle network. Therefore, the software must also complete this part of the function.

[0114] In addition to the different communication protocols between projects, the communication methods of different projects will also be different. The commonly used vehicle communication networks now include: MVB, RS485, current loop, Ethernet, etc. Here, only the MVB network communication, which is the most widely used in vehicle networks, will be discussed.

[0115] MVB (Multifunction Vehicle Bus) is an important part of the Train Communication Network (TCN), mainly used to connect devices within the same carriage or different carriages to realize functions such as vehicle control, status detection, and fault diagnosis.

[0116] Example of network communication design.

[0117] For the code modules of the existing MVB network communication part, software engineers need to perform basic MVB network configuration and data filling.

[0118] The parameters that need to be configured for the MVB network include: physical address, port address, port size, port type, period, transmission direction, timeout.

[0119] MVB_PDPORT MVB_PDPort[] = { {0x710, 32, MVBDATAPORTVAR, 1, 0, 512, 0xffff, &PortData1[2]}, {0x711, 16, MVBDATAPORTVAR, 0, 0, 512, 2048, &PortData2[2]}, } MVB_DEVICE MVB_Device = { MVBCARDTYPE_NONE, 0, MVBCONFIG_STATE_NO, 0, 0, Sizeof(MVB_PDPort) / sizeof(MVB_PDPORT), 0, 0x71, 0xffffffff, NETDATA_Process, MVB_PDPort, } The configuration of the above MVB parameters is carried out in the Task_VehicleComm.c file. Among them, the first parameter in MVB_PDPORT MVB_PDPort[] is the MVB port address, the second parameter is the size of the MVB port, the third parameter is the type of the port, the fourth parameter is the data transmission direction, the sixth parameter is the period, the seventh parameter is the timeout time, the eighth parameter is the MVB data buffer address, and MVB_DEVICE MVB_Device is the configuration of the MVB physical address, where 0x71 is the MVB physical address.

[0120] The above is only the most basic configuration of the MVB network. It is also necessary to dynamically configure the MVB parameters according to different vehicle numbers. After the configuration is completed, fill in and parse the application of the data according to the network data stream file. After completion, the air conditioning control system can communicate with the vehicle network normally.

[0121] The above embodiments give the development and design process of a new project under a given framework. When developing a new project, modify the above files according to the requirements of the new project to generate the required software. The mature code can be reused, reducing the complexity of the new project development and maintaining the consistency of the software in each project.

Claims

1. A rail transit vehicle air conditioning software architecture, characterized in that: include: The application layer is used to implement the air conditioning software functions of rail transit vehicles. Real-time operating system layer, used to support software systems, The board-level firmware layer serves the application layer. All logic and operations of the application layer are implemented by calling functions of this layer. The standard peripheral layer serves the board-level firmware layer and stores the standard peripheral library. The register layer serves the standard peripheral layer and the real-time operating system layer, defines the peripheral register device name definition, address definition, interrupt vector and helper function used to access the kernel, and also defines an interface independent of the microcontroller for the real-time operating system. The physical layer, serves the register layer and defines the hardware peripherals used by the air conditioning system.

2. The software framework according to claim 1, characterized in that: Design a corresponding file structure according to the software architecture, and the directory of the file structure includes: app, which stores application layer code; bsp, stores the source files of the board-level library; doc, to store software description information; includes, stores common header files of the standard library and header files of the main function; Libraries, which stores files at the register layer; Main, stores the main function file; Project, which stores the firmware header files including the compiled files and software; Rots, stores code files related to the real-time operating system.

3. A rail transit vehicle air conditioning software development method, based on the rail transit vehicle air conditioning software architecture, characterized in that: The following steps are involved: Input and output point configuration; Unit initialization; Definition of unit working mode; Work pattern analysis; Unit operating conditions and protection function settings; Work mode execution; Communication settings with the host computer; Fault information settings sent to PTU; Network communication settings.

4. The software development method according to claim 3, characterized in that: The input / output point configuration includes matching the I / O points of the CPU with the components of the unit through the input / output points of the control panel.

5. The software development method according to claim 4, characterized in that: The unit initialization includes grouping the configured input and output points according to the conditions of the unit.

6. The software development method according to claim 3, characterized in that: In the working mode analysis, the factors affecting the working mode are environmental data, and the environmental data include knob switch position, vehicle network data and ambient temperature status.

7. The software development method according to claim 3, characterized in that: The unit operating conditions and protection function settings include establishing unit operating conditions and protection functions according to power failure, fan overload, condenser overload, compressor overload, compressor high and low pressure failure and contactor failure.

8. The software development method according to claim 3, characterized in that: In the definition of the unit working mode, the unit working modes include ventilation, cooling, heating, emergency ventilation and shutdown; the working mode execution includes determining the unit working mode, and when the unit operating conditions are met, controlling the unit's devices to operate in the corresponding working mode.

9. The software development method according to claim 3, characterized in that: The communication setting with the host computer includes: Set the serial port communication protocol; The protocol transmission mode is master-slave response transmission, and each master frame corresponds to a slave frame; The minimum time interval from the end of the previous main frame to the beginning of the next main frame is 5ms, and the time interval from the end of the main frame to the beginning of the slave frame is less than 2ms.

10. The software development method according to claim 3, characterized in that: In the network communication setting, the network includes MVB, RS485, current loop and Ethernet.

Images