Middleware Design Method and Architecture Supporting Dual Redundancy and Triple Modular Redundancy Platforms

Abstract

The present invention discloses a middleware design method and architecture for supporting the two-out-of-two and two-out-of-three platforms, belonging to the field of signal control, including the steps of: S1, adding in the ATP application module design: an application middleware adaptation layer, and extracting and adding the underlying application modules / applications encapsulated Lib library files on which the ATP application depends to the middleware adaptation layer; S2, for the scheduling and information interaction call process between the upper-layer ATP application and the safety computer platform, applying the first API provided by the middleware adaptation layer in step S1, and the first API then calls the underlying application modules / applications encapsulated Lib library files. The present invention is flexible, cross-platform, and easy to expand. Without changing the respective system architectures and function allocations of the in-vehicle products on different existing platforms, it can support the respective system architectures and function allocations of the in-vehicle two-out-of-two platform and two-out-of-three platform, reducing the maintenance cost of signal system products.

Description

Technical Field

[0001] The present invention relates to the field of signal control, and more specifically, to a middleware design method and architecture supporting the two-out-of-two and three-out-of-two platforms. Background Art

[0002] There are differences in the hardware and platforms used by existing two-out-of-two in-vehicle products and three-out-of-two in-vehicle products. The two-out-of-two in-vehicle products are implemented using a two-out-of-two platform architecture, and the three-out-of-two in-vehicle products are implemented using a three-out-of-two platform architecture. The functions of the three-out-of-two vehicle ATP are basically the same as those of the two-out-of-two vehicle ATP. The differences lie in the use of different safety computer platforms, drivers, and hardware. The interfaces between the ATP application and the safety computer platform, hardware driver, and underlying application modules are incompatible. When implementing the same functional requirements, two application layer software need to be developed, resulting in a waste of R & D resources. Those skilled in the art urgently need to solve the above technical problems. Summary of the Invention

[0003] The purpose of the present invention is to overcome the deficiencies of the prior art and provide a middleware design method and architecture supporting the two-out-of-two and three-out-of-two platforms, which is flexible to use, cross-platform, and easy to expand. Without changing the respective system architectures and function allocations of the existing in-vehicle products on different platforms, it can support the system architectures and function allocations of the two-out-of-two platform and the three-out-of-two platform in-vehicle respectively. It can not only ensure the maximum code reuse of some existing underlying modules and upper-layer applications of the two in-vehicle products, but also avoid the security problems caused by code tampering between the upper and lower layers after application merging, and reduce the maintenance cost of signal system products.

[0004] The purpose of the present invention is achieved through the following solutions:

[0005] A design method for an application middleware supporting the two-out-of-two and three-out-of-two platforms, which improves the design of the in-vehicle ATP software architecture; the in-vehicle ATP software architecture includes an ATP application module, a safety computer platform module, and a hardware driver module. The improvement design of the in-vehicle ATP software architecture specifically includes the following steps:

[0006] S1, add in the ATP application module design: an application middleware adaptation layer, and extract and add the underlying application modules / applications encapsulated Lib library files on which the ATP application depends to the middleware adaptation layer;

[0007] S2, for the scheduling and information interaction call process between the upper-layer ATP application and the safety computer platform, apply the first API provided by the middleware adaptation layer in step S1, and the first API then calls the underlying application modules / applications encapsulated Lib library files;

[0008] For the information interaction and call process between the upper-layer application and the hardware driver, the second API provided by the application middleware adaptation layer is used, and this second API then calls the Lib library file encapsulated by the underlying functional module / application;

[0009] For the internal network information sending and receiving process, the third API provided by the application middleware adaptation layer is called, and the upper-layer application can implement the information interaction between ATP and other in-vehicle subsystems by inputting the destination ID of the corresponding internal network communication device;

[0010] For the external network information sending and receiving process, the fourth API provided by the application middleware adaptation layer is called, and the upper-layer application can implement the information interaction between ATP and the external network communication device by inputting the destination ID of the corresponding external network communication device.

[0011] Further, in step S1, it includes sub-steps: The middleware adaptation layer also sets up an application layer common module and an application adaptation layer common module;

[0012] The application layer common module provides the in-vehicle ATP application functions and business logics to ensure maximum code reuse;

[0013] The application adaptation layer common module provides the required interface information for applications on different in-vehicle platforms, and the application layer realizes the interaction of various service information on different in-vehicle platforms by calling the unified API provided by the application middleware adaptation layer.

[0014] Further, the underlying application module / Lib library file on which the ATP application depends is a lower-level API library required by the application middleware adaptation layer for connecting the safety computer platform and the hardware driver. By extracting and adding the in-vehicle ATP underlying application module / Lib library file, the information input by the in-vehicle ATP platform layer is converted into a form recognizable by the application middleware adaptation layer, or the information output by the application middleware adaptation layer is converted into a form recognizable by the in-vehicle ATP platform; the application layer common module, the application adaptation layer common module, and the underlying application module / Lib library file form the application middleware.

[0015] Further, after step S2, it includes step S3: Configure the current in-vehicle ATP platform type by including the header file where the platform type macro definition is located in the ATP version number private configuration file.

[0016] Further, the content of realizing the interaction of various service information on different in-vehicle platforms includes speed measurement information, transponder BTM message, status information of the hardware driver, IO input / output information, Nvram read / write information, and internal and external network sending and receiving information.

[0017] Further, after step S2, it includes the verification method steps based on the application middleware adaptation layer:

[0018] Verify using the two-out-of-two and three-out-of-two vehicle-mounted test environments, test data matching the data structure of the vehicle-mounted VOBC subsystem, and the target files generated after integrating and compiling the vehicle-mounted ATP application software containing application middleware with two vehicle-mounted platforms and the underlying module software respectively. The test content includes all APIs in the application middleware, all application functions and safety-side guidance related to calling the APIs, the application execution time consumption of the vehicle-mounted ATP, and the basic function use case set of the vehicle-mounted ATP subsystem related to change impact analysis.

[0019] In the vehicle-mounted ATP application software, the white-box and product function content that has no direct association with the application middleware and the underlying modules only needs to be tested once in the three-out-of-two platform vehicle-mounted products, and the two-out-of-two platform vehicle-mounted products can cross-accept it. Other content needs to be tested separately in the vehicle-mounted products of these two platforms.

[0020] Furthermore, after step S2, it includes the method steps of formulating a management strategy for the vehicle-mounted ATP application software containing application middleware:

[0021] Application adaptation layer common module: When the vehicle-mounted ATP products of the two-out-of-two platform and the three-out-of-two platform are making system version changes, when it comes to modifications directly related to the application middleware and the underlying modules, synchronize the changes in the application adaptation layer common module, and update the APIs called in the application layer common module. The vehicle-mounted ATP products of the two-out-of-two platform and the three-out-of-two platform integrate and reference them.

[0022] Application layer common module: When the vehicle-mounted ATP of the vehicle-mounted ATP products of the two-out-of-two platform and the three-out-of-two platform are making system version changes, make changes in the application layer common module. The vehicle-mounted ATP products of the two-out-of-two platform and the three-out-of-two platform integrate and reference them.

[0023] Underlying application modules / Lib library files on which the application depends: When the underlying application modules / Lib library files are changed, when it comes to interface definition, new or reduced interface changes, synchronize the changes in the application adaptation layer common module, and update the APIs called in the application layer common module. The vehicle-mounted ATP products of the two-out-of-two platform and the three-out-of-two platform integrate and reference them.

[0024] Safety computer platform module: When the safety computer platform module is changed, when it comes to interface definition, new or reduced interface changes, synchronize the changes in the application adaptation layer common module, and update the APIs called in the application layer common module. The vehicle-mounted ATP products of the two-out-of-two platform and the three-out-of-two platform integrate and reference them.

[0025] Hardware driver module: When the driver module is changed and involves interface definition, addition or reduction of interfaces, the changes are synchronized in the common module of the application adaptation layer, and the APIs called in the common module of the application layer are updated. The on-vehicle ATP products of the two-out-of-two and three-out-of-two platforms are integrated and referenced.

[0026] Further, the application middleware is on-vehicle ATP application middleware.

[0027] An on-vehicle ATP software architecture includes an application middleware obtained by using the design method of any one of the above-mentioned application middleware that supports the two-out-of-two and three-out-of-two platforms, and also includes an ATP configuration file, a common function module, and a common module of the secure communication protocol layer. The application middleware collaborates and interacts with the ATP configuration file, the common function module, the common module of the secure communication protocol layer, the secure computer platform, and the hardware driver; among them, the application middleware collaborates and interacts with the secure computer platform and the hardware driver according to the corresponding processes in step S2.

[0028] Further, it includes a processor and a memory on which the program depends. When the processor loads the program stored in the memory, it executes the design method of the application middleware that supports the two-out-of-two and three-out-of-two platforms as described in any one of claims 1 to 8; and it also includes an internal network information sending and receiving module and an external network information sending and receiving module;

[0029] The internal network information sending and receiving module is used to call the third API provided by the application middleware adaptation layer, and the upper-layer application inputs the corresponding internal network communication device destination ID to enable information interaction between ATP and other on-vehicle subsystems;

[0030] The external network information sending and receiving module is used to call the fourth API provided by the application middleware adaptation layer, and the upper-layer application inputs the corresponding external network communication device destination ID to enable information interaction between ATP and the external network communication device.

[0031] The beneficial effects of the present invention include:

[0032] In the design method of the present invention, the application middleware adapts to the functions of on-vehicle systems of different platforms / hardware by designing simple and general upper and lower layer communication interfaces and optimizing and adjusting the on-vehicle ATP software architecture, and is flexible to use, cross-platform, and easy to expand.

[0033] In the design method of the present invention, the application middleware can support the system architectures and function allocations of the two-out-of-two and three-out-of-two platform vehicles respectively. The internal and external network communication interfaces use the same interface protocol, and adding the application middleware does not change the system architectures and function allocations of the existing on-vehicle products of different platforms.

[0034] In the design method of the present invention, on the premise of not changing the functional business logic of the existing on-vehicle VOBC subsystem product, the interfaces or type definition methods that are strongly related between the original on-vehicle ATP application software and the safety computer platform, hardware drivers, and underlying functional modules unique to different products are changed to a general and platform-agnostic way for on-vehicle applications. Taking this as the principle, middleware is used to encapsulate and extend the interfaces between the application and the safety computer platform, hardware drivers, and underlying application modules / Lib library files according to abstract commonalities. This can not only ensure the maximum code reuse of some existing underlying modules and upper-layer applications of the two on-vehicle products, but also avoid security issues caused by code tampering between the upper and lower layers after application merging, reducing the maintenance cost of the signal system product. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0036] Figure 1 It is a flowchart of the on-vehicle ATP software architecture applying the embodiment of the present invention;

[0037] Figure 2 It is a schematic diagram of the application layer common module implemented by the present invention;

[0038] Figure 3 It is a schematic diagram of the application adaptation layer common module implemented by the present invention;

[0039] Figure 4 It is a schematic diagram of the underlying functional modules / Lib library files relied on by the application implemented by the present invention;

[0040] Figure 5 It is a schematic diagram of the ATP private configuration file implemented by the present invention;

[0041] Figure 6 It is a schematic diagram of the COMMONCODE common functions and common function configuration files implemented by the present invention;

[0042] Figure 7 It is a schematic diagram of the basic query function common module implemented by the present invention;

[0043] Figure 8 It is a schematic diagram of the security communication protocol layer common module implemented by the present invention;

[0044] Figure 9 It is a schematic diagram of the safety computer platform module implemented by the present invention;

[0045] Figure 10 Schematic diagram of the hardware driver module for the implementation of the present invention;

[0046] Figure 11 Flowchart of the mode conversion involved in the present invention. Detailed implementation manners

[0047] All features disclosed in all embodiments in this specification, or all steps in the methods or processes implicitly disclosed, except for mutually exclusive features and / or steps, can be combined and / or extended and replaced in any manner.

[0048] In order to reduce the maintenance cost of the later-stage signal system products and avoid the problem of duplicate implementation of the same on-vehicle ATP application functions in on-vehicle products of two different platforms, after creative thinking, the inventors of the present invention considered combining and reusing the application functions of on-vehicle ATP on the two-out-of-two platform and the two-out-of-three platform.

[0049] In the specific implementation process, in order to solve the incompatibility problem in the upper-layer application development in different on-vehicle platforms, as the second inventive concept of the technical solution of the embodiment of the present invention, a solution of adding an application middleware between the underlying application module / Lib library file and the application layer is proposed. Only by developing the application middleware to support a unified function call interface provided by different platforms can the function adaptation of the same set of on-vehicle ATP application software to different on-vehicle safety computer platforms and hardware drivers be realized. Subsequently, for the on-vehicle ATP products of these two different safety computer platforms, only one copy of the application software and the application middleware software needs to be maintained to achieve basically the same ATP functions.

[0050] In the specific implementation process, the inventive concept of the present invention further includes: the application middleware adapts to the on-vehicle system functions of different platforms / hardware by designing simple and general upper and lower layer communication interfaces and optimizing and adjusting the on-vehicle ATP software architecture, making it flexible to use, cross-platform, and easy to expand.

[0051] In the specific implementation process, the inventive concept of the present invention further includes: the application middleware can support the respective system architectures and function allocations of the two-out-of-two platform and the two-out-of-three platform on-vehicles. The internal and external network communication interfaces use the same interface protocol, and adding the application middleware does not change the respective system architectures and function allocations of the existing on-vehicle products of different platforms.

[0052] In the specific implementation process, the inventive concept of the present invention further includes: on the premise of not changing the functional service logic of the existing on-vehicle VOBC subsystem product, changing the interfaces or type definition methods that are strongly related between the original on-vehicle ATP application software and the safety computer platform, hardware drivers, and underlying functional modules unique to different products into a general and platform-agnostic way for on-vehicle applications. The middleware encapsulates and extends the interfaces between the application and the safety computer platform, hardware drivers, and underlying application modules / Lib library files according to abstract commonalities. In this way, it can not only ensure the maximum code reuse of some existing underlying modules and upper-layer applications of the two on-vehicle products, but also avoid security issues caused by code tampering between the upper and lower layers after application merging.

[0053] Based on the above inventive concept, an embodiment of the present invention further provides a middleware design method for supporting the dual modular redundancy (DMR) and triple modular redundancy (TMR) platforms and an on-vehicle ATP software architecture improved by using this design method. Among them, a middleware design method for supporting the DMR and TMR platforms includes the following steps:

[0054] 1) On-vehicle ATP software architecture design: The main improvement of the present invention to the original on-vehicle ATP software architecture is to add or extract the underlying functional modules / Lib library files on which the application depends, and add a middleware adaptation layer between the upper-layer application and the underlying functional modules / Lib library files on which the application depends are set in the middleware adaptation layer, such as Figure 1 , Figure 3 and Figure 4 shown. The on-vehicle ATP software architecture includes an application layer common module, and the application layer common module is as Figure 2 shown. The remaining components of the on-vehicle ATP subsystem architecture after adding the middleware adaptation layer in the present invention are basically the same as those of the on-vehicle ATP product, such as Figure 1 shown.

[0055] 2) Interface design between the application layer and the safety computer platform: The scheduling and information interaction between the upper-layer application and the safety computer platform call the API provided by the middleware adaptation layer of the embodiment of the present invention, and this API then calls the underlying application module / Lib library file encapsulated by the application. In addition, the safety computer platform of the on-vehicle ATP after adding the application middleware adaptation layer provided by the design method of the present invention is basically the same as the safety computer platforms used by the original on-vehicle ATP products respectively.

[0056] (3) Interface design between the application layer and the hardware driver: The information interaction and call between the upper-layer application and the hardware driver apply the API provided by the application middleware adaptation layer in this embodiment of the present invention. This API then calls the Lib library file encapsulated by the underlying application module / application. In addition, the on-vehicle ATP hardware driver after adding the application middleware adaptation layer provided by the design method of the present invention is basically the same as the hardware drivers used by the previous on-vehicle ATP products respectively.

[0057] (4) Intranet communication interface design: The sending and receiving of intranet information apply the unified API provided by the middleware adaptation layer in this embodiment of the present invention. The upper-layer application can achieve the information interaction between ATP and other on-vehicle subsystems by inputting the destination ID of the corresponding intranet communication device. In addition, the on-vehicle ATP intranet communication logic interface after adding the application adaptation layer provided by the design method of the present invention is consistent with the previous on-vehicle ATP products, and the intranet communication logic interface definitions of the on-vehicle VOBC subsystems of the two products on the two-out-of-two-take-two platform and the triple modular redundant platform are the same.

[0058] (5) Extranet communication interface design: The sending and receiving of extranet information apply the unified API provided by the application middleware adaptation layer in this embodiment of the present invention. The upper-layer application can achieve the information interaction between ATP and the extranet communication device by inputting the destination ID of the corresponding extranet communication device. In addition, the on-vehicle ATP extranet communication logic interface after adding the application middleware adaptation layer provided by the design method of the present invention is consistent with the previous products, and the extranet communication logic interface definitions of the on-vehicle VOBC subsystems of the two products on the two-out-of-two-take-two platform and the triple modular redundant platform are consistent.

[0059] (6) Interface design between the upper-layer functional application and the underlying application module: The overall design of the on-vehicle ATP application merged on the two-out-of-two-take-two platform and the triple modular redundant platform provided in this embodiment of the present invention is generally divided into three layers: the application layer common module, the application adaptation layer common module, and the underlying application module / Lib library file on which the application depends.

[0060] In the solution of the present invention, the application layer common module mainly provides on-vehicle ATP application functions and business logics to ensure maximum code reuse; the application adaptation layer common module mainly provides some interface information required for applications on different on-vehicle platforms. The application layer realizes the interaction of various service information on different on-vehicle platforms by calling the unified APIs provided by the application middleware adaptation layer, such as speed measurement information, transponder BTM messages, some status information of hardware drivers, IO input / output information, Nvram read / write information, internal and external network transceiver information, etc.; the underlying application modules / Lib library files relied on by the upper-layer applications are lower-layer API libraries required by the application middleware adaptation layer for connecting the safety computer platform and hardware drivers. By extracting and adding on-vehicle ATP common application function modules / Lib library files, the information input by the on-vehicle ATP platform layer is converted into a form recognizable by the application middleware adaptation layer, or the information output by the application middleware adaptation layer is converted into a form recognizable by the on-vehicle ATP platform.

[0061] (7) Design of the platform type identification method used by on-vehicle ATP. By including the header file where the platform type macro definition is located in the existing ATP version number private configuration file, the current on-vehicle ATP platform type is configured.

[0062] Based on the above inventive concept, an embodiment of the present invention further provides a verification method based on the application middleware adaptation layer: Use the existing two-out-of-two true on-vehicle test environment and two-out-of-three true on-vehicle test environment, test data matching the data structure of the on-vehicle VOBC subsystem, and the on-vehicle ATP public application software (including application middleware software) to verify with the target files generated after integrated compilation with the underlying module software such as two on-vehicle platforms and drivers. Verify in the on-vehicle environments of the two platforms respectively. The test contents include all APIs in the application middleware, all application functions and safety-side guidance related to calling the application middleware APIs, the application execution time consumption of on-vehicle ATP, and the basic function use case set of the on-vehicle ATP subsystem related to change impact analysis. In the on-vehicle ATP public application software, the white-box and product function contents that have no direct association with the application middleware and underlying modules (safety computer platform, hardware driver, underlying function module) only need to be tested once in the two-out-of-three platform on-vehicle products, and the two-out-of-two platform on-vehicle products can cross-accept them. Other contents need to be tested separately in the on-vehicle products of these two platforms.

[0063] Based on the above inventive concept, the present invention further provides a software management method for on-vehicle ATP system software: As Figures 5 to 10 shown, according to the module division of the on-vehicle ATP software architecture and the requirements design of the middleware in the technical solution of the embodiment of the present invention, the following software management strategies can also be formulated:

[0064] Application Adaptation Layer Module: When the in-vehicle ATP products of the dual modular redundancy platform and the triple modular redundancy platform each change their system versions, and when it comes to modifications directly related to the application middleware and underlying modules (safety computer platform, hardware driver, underlying function module), it is necessary to synchronize the changes in the application adaptation layer common module (middleware) of the common library, and update the middleware APIs called in the application layer common module. The in-vehicle ATP products of the dual modular redundancy platform and the triple modular redundancy platform are integrated and referenced.

[0065] Application Layer Common Module: When the in-vehicle ATP of the in-vehicle ATP products of the dual modular redundancy platform and the triple modular redundancy platform each changes its system version, the changes are made in the application layer common module. The in-vehicle ATP products of the dual modular redundancy platform and the triple modular redundancy platform are integrated and referenced.

[0066] Underlying Application Modules / Lib Library Files Dependent on the Application: When the underlying application modules / Lib library files change, and when it comes to interface definition, addition, or reduction of interface changes, it is necessary to synchronize the changes in the application adaptation layer common module of the common library, and update the middleware APIs called in the application layer common module. The in-vehicle ATP products of the dual modular redundancy platform and the triple modular redundancy platform are integrated and referenced.

[0067] Safety Computer Platform Module: When the platform module changes, and when it comes to interface definition, addition, or reduction of interface changes, it is necessary to synchronize the changes in the application adaptation layer common module of the R & D common library, and update the middleware APIs called in the application layer common module. The in-vehicle ATP products of the dual modular redundancy platform and the triple modular redundancy platform are integrated and referenced.

[0068] Hardware Driver Module: When the driver module changes, and when it comes to interface definition, addition, or reduction of interface changes, it is necessary to synchronize the changes in the application adaptation layer common module of the R & D common library, and update the middleware APIs called in the application layer common module. The in-vehicle ATP products of the dual modular redundancy platform and the triple modular redundancy platform are integrated and referenced.

[0069] Common Module of the Secure Communication Protocol Layer, Common Module of Basic Query Functions: It does not involve middleware adaptation, and is consistent with the existing change analysis and management strategy after the changes in the product integration common library's security protocol and basic query functions.

[0070] COMMONCODE Common Functions, Common Function Configuration Files: It does not involve middleware adaptation, and is consistent with the existing change analysis and management strategy after the changes in the product integration common functions and common function configuration files.

[0071] ATP Private Configuration File: When the on-vehicle products of the two-out-of-two platform and the two-out-of-three platform for on-vehicle ATP perform system version changes, only the on-vehicle ATP version numbers of their respective platforms need to be incremented, and the other contents in the file do not need to be modified, which has no impact on system functions.

[0072] In other specific embodiments, Figure 1 A flowchart of a solution for an on-vehicle ATP application middleware that supports the two-out-of-two platform and the two-out-of-three platform according to an embodiment of the present invention is shown. Figure 11 A timing diagram for an on-vehicle VOBC to control a train to switch between different driving modes in a solution for an on-vehicle ATP application middleware that supports the two-out-of-two platform and the two-out-of-three platform provided by an embodiment of the present invention is shown.

[0073] Based on the premise of not changing the existing on-vehicle system architecture and equipment, the embodiments of the present invention can reduce the maintenance cost of signal system products in the later stage and avoid the problem of duplicate implementation of the same on-vehicle ATP application function in on-vehicle products of two different platforms. In the simulation test environment, the technical solutions and effects of the present invention have been verified through theoretical verification and actual tests. Through the solution of the present invention, the same set of on-vehicle ATP application software can be adapted to different on-vehicle safety computer platforms and hardware drivers, reducing the maintenance cost of signal system products.

[0074] Embodiment 1

[0075] A design method for an application middleware that supports the two-out-of-two and two-out-of-three platforms, which improves the design of the on-vehicle ATP software architecture; the on-vehicle ATP software architecture includes an ATP application module, a safety computer platform module, and a hardware driver module, and the improvement design of the on-vehicle ATP software architecture specifically includes the following steps:

[0076] S1. In the ATP application module design, add: an application middleware adaptation layer, and extract and add the underlying application modules / applications encapsulated Lib library files on which the ATP application depends to the middleware adaptation layer;

[0077] S2. For the scheduling and information interaction call process between the upper-layer ATP application and the safety computer platform, use the first API provided by the middleware adaptation layer in step S1, and this first API then calls the underlying application modules / applications encapsulated Lib library files;

[0078] For the information interaction call process between the upper-layer application and the hardware driver, use the second API provided by the middleware adaptation layer, and this second API then calls the underlying function modules / applications encapsulated Lib library files;

[0079] For the intranet information sending and receiving process, call the third API provided by the application middleware adaptation layer. The upper-layer application can input the destination ID of the corresponding intranet communication device to achieve the information interaction between ATP and other in-vehicle subsystems;

[0080] For the extranet information sending and receiving process, call the fourth API provided by the application middleware adaptation layer. The upper-layer application can input the destination ID of the corresponding extranet communication device to achieve the information interaction between ATP and the extranet communication device.

[0081] Embodiment 2

[0082] Based on Embodiment 1, in step S1, it includes sub-steps: The middleware adaptation layer also sets an application layer common module and an application adaptation layer common module;

[0083] The application layer common module provides the in-vehicle ATP application functions and business logics to ensure the maximization of code reuse;

[0084] The application adaptation layer common module provides the required interface information for the applications of different in-vehicle platforms. The application layer realizes the interaction of various service information in different in-vehicle platforms by calling the unified API provided by the application middleware adaptation layer.

[0085] Embodiment 3

[0086] Based on Embodiment 2, the underlying application module / Lib library file on which the ATP application depends is a lower-level API library required by the application middleware adaptation layer for connecting the safety computer platform and the hardware driver. By extracting and adding the in-vehicle ATP underlying application module / Lib library file, the information input by the in-vehicle ATP platform layer is converted into a form recognizable by the application middleware adaptation layer, or the information output by the application middleware adaptation layer is converted into a form recognizable by the in-vehicle ATP platform; The application layer common module, the application adaptation layer common module, and the underlying application module / Lib library file form the application middleware.

[0087] Embodiment 4

[0088] Based on Embodiment 1, after step S2, it includes step S3: Configure the current in-vehicle ATP platform type by including the header file where the platform type macro definition is located in the ATP version number private configuration file.

[0089] Embodiment 5

[0090] Based on Embodiment 2, the content of realizing the interaction of various service information in different in-vehicle platforms includes speed measurement information, transponder BTM message, status information of the hardware driver, IO input and output information, Nvram read and write information, and intranet and extranet sending and receiving information.

[0091] Embodiment 6

[0092] Based on Embodiment 3, after step S2, it includes the verification method steps based on the application middleware adaptation layer:

[0093] Use the two-out-of-two vehicle-mounted test environment and the two-out-of-three vehicle-mounted test environment, test data matching the data structure of the vehicle-mounted VOBC subsystem, and the vehicle-mounted ATP application software containing the application middleware to verify the target files generated after being integrated and compiled with two vehicle-mounted platforms and the underlying module software respectively. The test contents include all APIs in the application middleware, all application functions and security-side guidance related to calling the APIs, the application execution time-consuming situation of the vehicle-mounted ATP, and the basic function use case set of the vehicle-mounted ATP subsystem related to the change impact analysis;

[0094] In the vehicle-mounted ATP application software, the white-box and product function contents that have no direct association with the application middleware and the underlying modules only need to be tested once in the vehicle-mounted products of the two-out-of-three platform, and the vehicle-mounted products of the two-out-of-two platform can cross-accept them. Other contents need to be tested separately in the vehicle-mounted products of these two platforms.

[0095] Embodiment 7

[0096] Based on Embodiment 3, after step S2, it includes the method steps of formulating a management strategy for the vehicle-mounted ATP application software containing the application middleware:

[0097] For the public module of the application adaptation layer: When the vehicle-mounted ATP products of the two-out-of-two platform and the two-out-of-three platform perform system version changes and involve modifications directly related to the application middleware and the underlying modules, synchronize the changes in the public module of the application adaptation layer, and update the APIs called in the public module of the application layer. The vehicle-mounted ATP products of the two-out-of-two platform and the two-out-of-three platform integrate and reference them;

[0098] Public module of the application layer: When the vehicle-mounted ATP of the vehicle-mounted ATP products of the two-out-of-two platform and the two-out-of-three platform performs system version changes, make changes in the public module of the application layer. The vehicle-mounted ATP products of the two-out-of-two platform and the two-out-of-three platform integrate and reference them;

[0099] Underlying application module / Lib library file on which the application depends: When the underlying application module / Lib library file changes and involves interface definition, addition or reduction of interface changes, synchronize the changes in the public module of the application adaptation layer, and update the APIs called in the public module of the application layer. The vehicle-mounted ATP products of the two-out-of-two platform and the two-out-of-three platform integrate and reference them;

[0100] Safety computer platform module: When the safety computer platform module changes, and when there are changes in interface definitions, addition or reduction of interfaces, the changes are synchronized in the common module of the application adaptation layer, and the APIs called in the common module of the application layer are updated. It is integrated and referenced in the on-vehicle ATP products of the two-out-of-two and two-out-of-three platforms.

[0101] Hardware driver module: When the driver module changes, and when there are changes in interface definitions, addition or reduction of interfaces, the changes are synchronized in the common module of the application adaptation layer, and the APIs called in the common module of the application layer are updated. It is integrated and referenced in the on-vehicle ATP products of the two-out-of-two and two-out-of-three platforms.

[0102] Embodiment 8

[0103] Based on Embodiment 1, the application middleware is on-vehicle ATP application middleware.

[0104] Embodiment 9

[0105] An on-vehicle ATP software architecture includes an application middleware obtained by using the design method of the application middleware that supports the two-out-of-two and two-out-of-three platforms as described in any one of Embodiments 1 to 8, and also includes an ATP configuration file, a common function module, and a common module of the secure communication protocol layer. The application middleware collaborates and interacts with the ATP configuration file, the common function module, the common module of the secure communication protocol layer, the safety computer platform, and the hardware driver; among them, the application middleware collaborates and interacts with the safety computer platform and the hardware driver according to the corresponding processes in Step S2.

[0106] Embodiment 10

[0107] Based on Embodiment 9, it includes a processor and a memory on which the program depends. When the processor loads the program stored in the memory, it executes the design method of the application middleware that supports the two-out-of-two and two-out-of-three platforms as described in any one of Claims 1 to 8; and, it also includes an internal network information sending and receiving module and an external network information sending and receiving module;

[0108] The internal network information sending and receiving module is used to call the third API provided by the application middleware adaptation layer, and the upper-layer application can realize the information interaction between ATP and other on-vehicle subsystems by inputting the destination ID of the corresponding internal network communication device;

[0109] The external network information sending and receiving module is used to call the fourth API provided by the application middleware adaptation layer, and the upper-layer application can realize the information interaction between ATP and the external network communication device by inputting the destination ID of the corresponding external network communication device.

[0110] The units involved in the embodiments of the present invention can be implemented in software or in hardware, and the described units can also be provided in a processor. Among them, the names of these units do not constitute a limitation to the unit itself in certain cases.

[0111] According to one aspect of the present application, there is provided a computer program product or a computer program. The computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the methods provided in the above various alternative implementations.

[0112] As another aspect, the present application also provides a computer-readable medium. The computer-readable medium can be included in the electronic device described in the above embodiments; or it can exist alone without being assembled into the electronic device. The above computer-readable medium carries one or more programs. When the above one or more programs are executed by an electronic device, the electronic device implements the methods described in the above embodiments.

[0113] Parts not involved in the present invention are the same as the prior art or can be implemented using the prior art.

[0114] The above technical solutions are only one implementation manner of the present invention. For those skilled in the art, based on the application methods and principles disclosed in the present invention, it is very easy to make various types of improvements or modifications, not limited to the methods described in the above specific implementation manners of the present invention. Therefore, the above-described manner is only preferred and does not have a limiting meaning.

[0115] Except for the above examples, those skilled in the art can obtain inspirations according to the above disclosure or make modifications using the knowledge or technologies in related fields to obtain other embodiments. The features of each embodiment can be interchanged or replaced. As long as the modifications and changes made by those skilled in the art do not depart from the spirit and scope of the present invention, they should all be within the protection scope of the claims appended to the present invention.

Claims

1. A middleware design method for supporting the two-out-of-two and two-out-of-three platforms, which improves the design of the on-vehicle ATP software architecture; the on-vehicle ATP software architecture includes an ATP application module, a safety computer platform module, and a hardware driver module, and is characterized in that, The improved design for the in-vehicle ATP software architecture specifically includes the following steps: S1. In the design of the ATP application module, add an application middleware adaptation layer, and extract and add the underlying application modules / Lib library files encapsulated by the applications on which the ATP application depends to the middleware adaptation layer; S2. For the scheduling and information interaction call process between the upper-layer ATP application and the safety computer platform, use the first API provided by the middleware adaptation layer in step S1, and this first API then calls the underlying application modules / Lib library files encapsulated by the applications; For the information interaction call process between the upper-layer application and the hardware driver, use the second API provided by the middleware adaptation layer, and this second API then calls the underlying functional modules / Lib library files encapsulated by the applications; For the internal network information sending and receiving process, call the third API provided by the application middleware adaptation layer, and the upper-layer application can achieve information interaction between ATP and other in-vehicle subsystems by inputting the destination ID of the corresponding internal network communication device; For the external network information sending and receiving process, call the fourth API provided by the application middleware adaptation layer, and the upper-layer application can achieve information interaction between ATP and the external network communication device by inputting the destination ID of the corresponding external network communication device; In step S1, it includes sub-steps: The middleware adaptation layer also sets an application layer common module and an application adaptation layer common module; The application layer common module provides the in-vehicle ATP application functions and business logics to ensure the maximum code reuse; The application adaptation layer common module provides the required interface information for the applications of different in-vehicle platforms, and the application layer realizes the interaction of various service information in different in-vehicle platforms by calling the unified API provided by the application middleware adaptation layer; The underlying application modules / Lib library files on which the ATP application depends are the lower-layer API libraries required by the application middleware adaptation layer for connecting the safety computer platform and the hardware driver. By extracting and adding the in-vehicle ATP underlying application modules / Lib library files, the information input by the in-vehicle ATP platform layer is converted into a form recognizable by the application middleware adaptation layer, or the information output by the application middleware adaptation layer is converted into a form recognizable by the in-vehicle ATP platform; The application layer common module, the application adaptation layer common module, and the underlying application modules / Lib library files form the application middleware.

2. The middleware design method for supporting the two-out-of-two and two-out-of-three platforms according to claim 1, and is characterized in that, After step S2, it includes step S3: Configure the current in-vehicle ATP platform type by including the header file where the platform type macro definition is located in the ATP version number private configuration file.

3. The middleware design method for supporting the two-out-of-two and two-out-of-three platforms according to claim 1, and is characterized in that, The content of realizing the interaction of various service information in different in-vehicle platforms includes speed measurement information, transponder BTM messages, status information of the hardware driver, IO input / output information, Nvram read / write information, and internal and external network sending and receiving information.

4. The middleware design method for supporting the two-out-of-two and two-out-of-three platforms according to claim 1, and is characterized in that, After step S2, it includes the verification method steps based on the application middleware adaptation layer: Verify the target files generated after integrating and compiling the on-vehicle ATP application software containing application middleware with two on-vehicle platforms and underlying module software respectively using the 2oo2 on-vehicle test environment and the 3oo2 on-vehicle test environment, test data matching the data structure of the on-vehicle VOBC subsystem. The test content includes all APIs in the application middleware, all application functions and safety-side guidance related to calling the APIs, the application execution time-consuming situation of on-vehicle ATP, and the basic function use case set of the on-vehicle ATP subsystem related to change impact analysis; In the on-vehicle ATP application software, the white-box and product function content that has no direct association with the application middleware and underlying modules only needs to be tested once in the 3oo2 platform on-vehicle product, and the 2oo2 platform on-vehicle product can accept it crosswise. Other content needs to be tested separately in the on-vehicle products of these two platforms.

5. The middleware design method for supporting the two-out-of-two and two-out-of-three platforms according to claim 1, and is characterized in that, After step S2, it includes the method steps of formulating a management strategy for the on-vehicle ATP application software containing application middleware: Application adaptation layer common module: When the on-vehicle ATP products of the 2oo2 platform and the 3oo2 platform each perform a system version change and it involves modifications directly related to the application middleware and underlying modules, synchronously change in the application adaptation layer common module and update the APIs called in the application layer common module. The on-vehicle ATP products of the 2oo2 platform and the 3oo2 platform integrate and reference it; Application layer common module: When the on-vehicle ATP of the on-vehicle ATP products of the 2oo2 platform and the 3oo2 platform each performs a system version change, change in the application layer common module. The on-vehicle ATP products of the 2oo2 platform and the 3oo2 platform integrate and reference it; Underlying application module / Lib library file on which the application depends: When the underlying application module / Lib library file is changed and it involves interface definition, addition or reduction of interface changes, synchronously change in the application adaptation layer common module and update the APIs called in the application layer common module. The on-vehicle ATP products of the 2oo2 platform and the 3oo2 platform integrate and reference it; Safety computer platform module: When the safety computer platform module is changed and it involves interface definition, addition or reduction of interface changes, synchronously change in the application adaptation layer common module and update the APIs called in the application layer common module. The on-vehicle ATP products of the 2oo2 platform and the 3oo2 platform integrate and reference it; Hardware driver module: When the driver module is changed and it involves interface definition, addition or reduction of interface changes, synchronously change in the application adaptation layer common module and update the APIs called in the application layer common module. The on-vehicle ATP products of the 2oo2 platform and the 3oo2 platform integrate and reference it.

6. The middleware design method for supporting the two-out-of-two and two-out-of-three platforms according to claim 1, and is characterized in that, The application middleware is the on-vehicle ATP application middleware.

7. An on-vehicle ATP software architecture system, and is characterized in that, It includes an application middleware obtained by using the middleware design method for supporting the two-out-of-two and two-out-of-three platforms as described in any one of claims 1 to 6, and also includes an ATP configuration file, a common function module, and a common module for the secure communication protocol layer. The application middleware collaborates and interacts with the ATP configuration file, the common function module, the common module for the secure communication protocol layer, the secure computer platform, and the hardware driver; among them, the application middleware collaborates and interacts with the secure computer platform and the hardware driver according to the corresponding processes in step S2.

8. The on-vehicle ATP software architecture system according to claim 7, and is characterized in that, It includes a processor and a memory on which the program depends, and also includes an internal network information sending and receiving module and an external network information sending and receiving module; The internal network information sending and receiving module is used to call the third API provided by the application middleware adaptation layer, and the upper-layer application can input the destination ID of the corresponding internal network communication device to realize the information interaction between the ATP and other in-vehicle subsystems; The external network information sending and receiving module is used to call the fourth API provided by the application middleware adaptation layer, and the upper-layer application can input the destination ID of the corresponding external network communication device to realize the information interaction between the ATP and the external network communication device.

Images