Development method and apparatus, software product, vehicle and storage medium

Abstract

A development method and apparatus, a software product, a vehicle and a storage medium, used for improving the development efficiency of application software. The development method comprises: acquiring first development information, the first development information comprising a first application program, and the first application program being an application program generated by a user on a development device; and running the first application program, and allocating a first communication configuration parameter to the first application program. Allocation of first communication configuration parameters to the first application programs during running of the first application programs enables developers to only need to configure service interface configuration items on development devices, without the need to configure configuration items of communication configuration parameters, which can reduce the number of required configuration items of developers, thus effectively improving the application software development efficiency of developers.

Description

Development method, software product, device, vehicle and storage medium

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of the People's Republic of China on March 8, 2024, with application number 202410272102.2 and invention name "A development method, software product, device, vehicle and storage medium", the entire contents of which are incorporated by reference into this application. Technical Field

[0003] The present application relates to the field of vehicle networking technology, and in particular to a development method, software product, device, vehicle, and storage medium. Background Art

[0004] With the continuous advancement of vehicle technology, people's demand for complete vehicle intelligence is increasing. Intelligent vehicles are typical high-tech vehicles that integrate a variety of auxiliary functions, including but not limited to perception, regulation and control, automatic cruise control, and autonomous driving. These auxiliary functions make vehicles increasingly intelligent and electronic, but also make the vehicle's software structure increasingly complex.

[0005] Currently, developers developing in-vehicle assistance applications, even for simple ones, often need to configure a large number of configuration items, including service interface configuration items and related runtime configuration parameters. This large number of configuration items significantly reduces application development efficiency and hinders the developer experience.

[0006] In summary, how to improve the development efficiency of application software is a technical problem that needs to be urgently solved in the current field of in-vehicle software development. Summary of the Invention

[0007] The present application provides a development method, software product, device, vehicle and storage medium for improving the development efficiency of application software.

[0008] In a first aspect, the present application provides a development method, which includes: first, obtaining first development information, the first development information including a first application, and the first application is an application generated by a user on a development device; then, running the first application and assigning first communication configuration parameters to the first application.

[0009] By adopting the above method, by assigning the first communication configuration parameters to the first application when running the first application, the developer can only generate the first application on the development device without configuring the communication configuration parameters of the first application. This can reduce the number of configuration items that the developer needs to configure and effectively improve the developer's development efficiency of the application software.

[0010] In one possible design, allocating a first communication configuration parameter to a first application includes: first, obtaining preset parameter configuration information, which includes an allocation range of a resource class parameter; then, determining an unoccupied parameter value of the resource class parameter in the allocation range of the resource class parameter, and allocating the unoccupied parameter value of the resource class parameter to the first application.

[0011] The above design ensures that the resource class parameters allocated to the first application are not occupied by other applications, thereby ensuring that the resource class parameters of each application do not conflict, ensuring the reliability and availability of parameter allocation, and reducing development and maintenance costs.

[0012] In one possible design, assigning a first communication configuration parameter to a first application includes: first, obtaining preset parameter configuration information, which includes default parameter values ​​for non-resource parameters; then, determining whether the first development information indicates a specified parameter value for the non-resource parameter; if so, assigning the specified parameter value for the non-resource parameter to the first application; if not, assigning the default parameter value for the non-resource parameter to the first application.

[0013] With the above design, specified non-resource parameters or default non-resource parameters can be assigned to the first application, so that it can be adapted to business scenarios with specified requirements or business scenarios without specified requirements, thereby achieving the universality of the development method.

[0014] In one possible design, after assigning the first communication configuration parameter to the first application, the method further includes: storing the first communication configuration parameter corresponding to the first application in parameter assignment information. The parameter assignment information includes communication configuration parameters corresponding to one or more applications. The communication configuration parameters corresponding to the one or more applications may be assigned to the application by the running device, may be modified by the user, or may be carried in development information.

[0015] The above design stores the communication configuration parameters corresponding to the application by setting parameter allocation information, which can provide a reference benchmark for subsequent application allocation operations. By updating the communication configuration parameters in the reference benchmark in real time, its comprehensiveness and accuracy can be ensured.

[0016] In a further possible design, after storing the first communication configuration parameter corresponding to the first application in the parameter allocation information, it also includes: marking the parameter value of the resource class parameter in the first communication configuration parameter as occupied.

[0017] By adopting the above design, by marking the occupied resource class parameters in the parameter allocation information, the unoccupied resource class parameters can be quickly located when allocating communication configuration parameters for the application, thereby improving the allocation efficiency of the unoccupied resource class parameters.

[0018] In one possible design, before allocating the first communication configuration parameter to the first application, the method further includes: determining that the second communication configuration parameter corresponding to the first application does not exist in the parameter allocation information.

[0019] With the above design, the first communication configuration parameters will be allocated to the first application only if the communication configuration parameters have not been allocated to the first application before. This can avoid the phenomenon of repeatedly allocating communication configuration parameters to the same application, save meaningless operation processes, and reduce resource overhead.

[0020] In a further possible design, if the parameter allocation information contains a second communication configuration parameter corresponding to the first application, a communication channel for the first application can be established based on the second communication configuration parameter.

[0021] With the above design, the communication configuration parameters included in the parameter allocation information can be directly used to establish a communication channel, thereby improving the startup efficiency of the application.

[0022] In one possible design, after assigning the first communication configuration parameters to the first application, the method further includes: exporting the first communication configuration parameters to a development device based on a first instruction, and obtaining third communication configuration parameters, where the third communication configuration parameters are obtained after a user modifies the first communication configuration parameters on the development device. The first instruction may be, for example, an update instruction, an export instruction, a copy instruction, or other instruction from a developer. If the first instruction is received, a communication channel may be established based on the third communication configuration parameters modified by the developer. If the first instruction is not received, a communication channel may be established directly based on the automatically assigned first communication configuration parameters.

[0023] With the above design, when the automatically assigned communication configuration parameters do not meet the actual scenario requirements, developers can also modify one or more configuration items in the automatically assigned communication configuration parameters so that the application can be started or run using the communication configuration parameters that meet the actual scenario requirements.

[0024] In a further possible design, after obtaining the third communication configuration parameter, the method further includes: updating the first communication configuration parameter corresponding to the first application in the parameter allocation information according to the third communication configuration parameter. The updating method may be modification, annotation, or overwriting.

[0025] With the above design, the communication configuration parameters stored in the parameter allocation information can be updated in real time to ensure their accuracy.

[0026] In a further possible design, the third communication configuration parameter can also be stored in the development device; the method also includes: obtaining second development information, the second development information includes the first application and the third communication configuration parameter, running the first application, and establishing a communication channel for the first application based on the third communication configuration parameter.

[0027] With the above design, the exported communication configuration parameters can also be stored as static communication configuration parameters in the development device. In this way, the next time you develop an application, you can directly obtain the static communication configuration parameters in the development device and directly perform the application operation test without having to allocate communication configuration parameters for the application, thereby improving the initialization speed of the application startup.

[0028] In a possible design, before allocating the first communication configuration parameter to the first application, the method further includes: determining that the first development information does not include the fourth communication configuration parameter of the first application.

[0029] With the above design, communication configuration parameters are dynamically allocated to the application only when static communication configuration parameters do not exist. This avoids unnecessary allocation processes and saves processing resources.

[0030] In a further possible design, if the first development information includes the fourth communication configuration parameter of the first application, a communication channel of the first application is established based on the fourth communication configuration parameter.

[0031] With the above design, when there are static communication configuration parameters, the application can be directly run using the static configuration parameters, which can improve the initialization speed of the application.

[0032] In a further possible design, when the first development information includes the fourth communication configuration parameter of the first application, the method also includes: obtaining parameter allocation information, and querying whether the second communication configuration parameter corresponding to the first application exists in the parameter allocation information; if the second communication configuration parameter corresponding to the first application exists in the parameter allocation information, but the second communication configuration parameter is different from the fourth communication configuration parameter, or if the second communication configuration parameter corresponding to other applications exists in the parameter allocation information, a first prompt message is generated, and the first prompt message is used to prompt that an error has occurred in the fourth communication configuration parameter.

[0033] With the above design, the static communication configuration parameters can be verified using the dynamically allocated communication configuration parameters in the parameter allocation information to detect parameter inconsistency errors or resource conflict errors, which can then prompt developers to modify erroneous communication configuration parameters in a timely manner, ensuring that the application is run using the correct communication configuration parameters and improving the accuracy of operation.

[0034] In a further possible design, when the fourth communication configuration parameter corresponding to the application does not exist in the parameter allocation information, the fourth communication configuration parameter corresponding to the first application can also be stored in the parameter allocation information.

[0035] With the above design, static communication configuration parameters can be used to complete the parameter allocation information to ensure the comprehensiveness of the parameter allocation information.

[0036] In one possible design, the first application may be a server application or a client application of the in-vehicle business type.

[0037] The above design can improve the development efficiency of developers for in-vehicle business software and meet the growing demand for in-vehicle business.

[0038] In a second aspect, the present application provides a software product, which includes: a communication middleware and a parameter server; the communication middleware is used to send a parameter request message to the parameter server when running a first application, the first application is included in the first development information, and the first application is an application generated by the user on the development device; the parameter server is used to allocate first communication configuration parameters to the first application according to the parameter request message, and send the first communication configuration parameters to the communication middleware.

[0039] By adopting the above solution, by setting up a parameter server outside the communication middleware, the parameter server can be used to flexibly manage and allocate the communication configuration parameters of each application. In other words, various operations related to the communication configuration parameters can be independently implemented through a separate software process.

[0040] In one possible design, the communication middleware is further used to establish a communication channel for the first application based on the first communication configuration parameters.

[0041] In one possible design, the parameter server is specifically used to: first, obtain preset parameter configuration information, which includes an allocation range of resource class parameters; then, determine the unoccupied parameter values ​​of the resource class parameters in the allocation range of the resource class parameters, and allocate the unoccupied parameter values ​​of the resource class parameters to the first application.

[0042] In one possible design, the parameter server is specifically used to: first, obtain preset parameter configuration information, which includes default parameter values ​​of non-resource parameters; then, determine whether the first development information also indicates specified parameter values ​​of non-resource parameters; if so, assign the specified parameter values ​​of non-resource parameters to the first application; if not, assign the default parameter values ​​of non-resource parameters to the first application.

[0043] In one possible design, after allocating the first communication configuration parameters to the first application, the parameter server is further configured to: store the first communication configuration parameters corresponding to the first application in parameter allocation information. The parameter allocation information includes communication configuration parameters corresponding to one or more applications, where the communication configuration parameters corresponding to the one or more applications are allocated to the one or more applications by the parameter server, modified by a user, or carried in development information.

[0044] In one possible design, before allocating the first communication configuration parameter to the first application, the parameter server is further used to: query the parameter allocation information according to the parameter request message, and determine that the second communication configuration parameter corresponding to the first application does not exist in the parameter allocation information.

[0045] In a further possible design, the parameter server is further used to: if the parameter allocation information contains a second communication configuration parameter corresponding to the first application, send the second communication configuration parameter to the communication middleware.

[0046] In a further possible design, the communication middleware is further used to establish a communication channel for the first application based on the second communication configuration parameters.

[0047] In one possible design, the parameter server is also used to: export the first communication configuration parameter to the development device based on the first instruction, and obtain the third communication configuration parameter imported by the development device, and then send the third communication parameter to the communication middleware, where the third communication configuration parameter is obtained after the user modifies the first communication configuration parameter on the development device.

[0048] In a further possible design, the communication middleware is further used to: establish a communication channel for the first application based on the third communication configuration parameter.

[0049] In a further possible design, after obtaining the third communication configuration parameters imported by the development device, the parameter server is also used to: update the first communication configuration parameters corresponding to the first application in the parameter allocation information according to the third communication configuration parameters.

[0050] In a further possible design, the third communication configuration parameters are also stored in the development device. In this case, the communication middleware is also used to: when the second development information includes the first application and the third communication configuration parameters, when running the first application in the second development information, establish a communication channel for the first application based on the third communication configuration parameters.

[0051] In a possible design, before allocating the first communication configuration parameter to the first application, the communication middleware is further configured to: determine that the first development information does not include a fourth communication configuration parameter of the first application.

[0052] In a further possible design, the communication middleware is further used to: if the first development information includes a fourth communication configuration parameter of the first application, then establish a communication channel for the first application based on the fourth communication configuration parameter.

[0053] In a further possible design, the communication middleware is also used to: send a parameter verification request to the parameter server, the parameter verification request includes the fourth communication configuration parameter; the parameter server is also used to: obtain parameter allocation information, if the parameter allocation information contains a second communication configuration parameter corresponding to the first application, but the second communication configuration parameter is different from the fourth communication configuration parameter, or if the parameter allocation information contains other applications corresponding to the fourth communication configuration parameter, then a response message indicating that the parameter verification failed is returned to the communication middleware; the communication middleware is also used to: generate a first prompt message based on the response message indicating that the parameter verification failed, and the first prompt message is used to prompt that an error has occurred in the fourth communication configuration parameter.

[0054] In a further possible design, the parameter server is further used to: if the fourth communication configuration parameter corresponding to the application does not exist in the parameter allocation information, then store the fourth communication configuration parameter corresponding to the first application in the parameter allocation information.

[0055] In a further possible design, the parameter server is also used to: if the parameter allocation information contains a second communication configuration parameter corresponding to the first application, but the second communication configuration parameter is different from the fourth communication configuration parameter, then return a response message of parameter verification inconsistency to the communication middleware; if the parameter allocation information contains other applications corresponding to the fourth communication configuration parameter, then return a response message of parameter resource conflict to the communication middleware.

[0056] On the third aspect, the present application provides a development device, which can be a device or component that communicates using communication middleware. For example, when the development solution is applied to the field of intelligent driving, the development device can be a vehicle, an on-board device or an on-board component, or it can be an embedded device that is embedded in the vehicle and can control the vehicle, on-board device or on-board component to run the application in the vehicle's operating environment. Alternatively, it can be a device or component outside the vehicle, such as a device specifically used for testing, a development device or its component. These devices or components must also be encapsulated with the on-board communication middleware and the underlying operating environment in order to run the application smoothly.

[0057] The development device includes: an acquisition unit for acquiring first development information, the first development information including a first application, and the first application is an application generated by a user on a development device; an allocation unit for running the first application and allocating first communication configuration parameters to the first application.

[0058] In one possible design, the development device may further include a communication unit, where the communication unit is configured to establish a communication channel for the first application based on the first communication configuration parameters.

[0059] In one possible design, the first application may be a server application or a client application of the in-vehicle business type.

[0060] In one possible design, the allocation unit is specifically used to: first, obtain preset parameter configuration information, which includes the allocation range of resource class parameters; then, determine the unoccupied parameter values ​​of the resource class parameters in the allocation range of the resource class parameters; and then, allocate the unoccupied parameter values ​​of the resource class parameters to the first application.

[0061] In one possible design, the allocation unit is specifically used to: first, obtain preset parameter configuration information, which includes default parameter values ​​of non-resource parameters; then, if the first development information also indicates specified parameter values ​​of non-resource parameters, the specified parameter values ​​of non-resource parameters are allocated to the first application; or, if the first development information does not indicate specified parameter values ​​of non-resource parameters, the default parameter values ​​of non-resource parameters are allocated to the first application.

[0062] In one possible design, after allocating the first communication configuration parameters to the first application, the allocation unit is further configured to: store the first communication configuration parameters corresponding to the first application in parameter allocation information. The parameter allocation information includes communication configuration parameters corresponding to one or more applications, where the one or more communication configuration parameters corresponding to the application are allocated to the application by the running device, modified by the user, or carried in development information.

[0063] In a possible design, before allocating the first communication configuration parameter to the first application, the allocation unit is further configured to: determine that the second communication configuration parameter corresponding to the first application does not exist in the parameter allocation information.

[0064] In a further possible design, the allocation unit is further used to: if there is a second communication configuration parameter corresponding to the first application in the parameter allocation information, then establish a communication channel for the first application based on the second communication configuration parameter.

[0065] In one possible design, the allocation unit is further used to: export the first communication configuration parameter to the development device based on the first instruction; the acquisition unit is further used to: obtain a third communication configuration parameter, which is obtained after the user modifies the first communication configuration parameter on the development device.

[0066] In a further possible design, the development device may further include a communication unit, wherein the communication unit is configured to establish a communication channel for the first application based on the third communication configuration parameter.

[0067] In a further possible design, after the acquisition unit acquires the third communication configuration parameter, the allocation unit is further used to: update the first communication configuration parameter corresponding to the first application in the parameter allocation information according to the third communication configuration parameter.

[0068] In a further possible design, the third communication configuration parameter is also stored in the development device. In this case, the acquisition unit is also used to: obtain second development information, the second development information includes the first application and the third communication configuration parameter; the communication unit is also used to: run the first application and establish a communication channel for the first application based on the third communication configuration parameter.

[0069] In a possible design, before allocating the first communication configuration parameter to the first application, the allocating unit is further configured to: determine that the first development information does not include a fourth communication configuration parameter of the first application.

[0070] In a further possible design, the development device may also include a communication unit, and the allocation unit is further used to: if the first development information includes the fourth communication configuration parameter of the first application, instruct the communication unit to establish a communication channel for the first application based on the fourth communication configuration parameter.

[0071] In a further possible design, the acquisition unit is also used to: obtain parameter allocation information; the allocation unit is also used to: if the parameter allocation information contains a second communication configuration parameter corresponding to the first application, but the second communication configuration parameter is different from the fourth communication configuration parameter, or there is a fourth communication configuration parameter corresponding to other applications in the parameter allocation information, then a first prompt message is generated, and the first prompt message is used to prompt that an error has occurred in the fourth communication configuration parameter.

[0072] In a further possible design, the allocation unit is further used to: when the fourth communication configuration parameter corresponding to the application does not exist in the parameter allocation information, store the fourth communication configuration parameter corresponding to the first application in the parameter allocation information.

[0073] In a fourth aspect, the present application provides a development device, comprising a processor, the processor being coupled to a memory, the processor being used to execute a computer program or instruction stored in the memory, so that the development device executes a development method as in the first aspect or any one of the designs of the first aspect.

[0074] In a fifth aspect, the present application provides a vehicle comprising a unit or module for implementing a development method as in the first aspect or any one of the designs of the first aspect, for example, it may comprise a development device as in the third aspect or any one of the designs of the third aspect, or it may comprise a development device as in the fourth aspect.

[0075] In a sixth aspect, the present application provides a test device, wherein the test device includes an operating environment required by a first application program, and the test device can implement the development method described in the first aspect or any one of the designs of the first aspect. The test device may include a unit or module for implementing the development method described in the first aspect or any one of the designs of the first aspect, for example, it may include the development device described in the third aspect or any one of the designs of the third aspect, or it may include the development device described in the fourth aspect.

[0076] In a seventh aspect, the present application provides a computer-readable storage medium, which stores a program or instruction. When the program or instruction is executed, it implements the development method in the first aspect or any one of the designs of the first aspect.

[0077] In an eighth aspect, the present application provides a computer program product, which includes a computer program code. When the computer program code runs on a computer, the computer executes the development method in the first aspect or any one of the designs of the first aspect.

[0078] The technical effects that can be achieved in the second to eighth aspects mentioned above can refer to the description of the beneficial effects in the first aspect mentioned above, and will not be repeated here one by one. BRIEF DESCRIPTION OF THE DRAWINGS

[0079] FIG1 exemplarily shows a schematic diagram of a possible application scenario provided by the present application;

[0080] FIG2 exemplarily shows a software architecture diagram of an application development provided by the present application;

[0081] FIG3a exemplarily shows a schematic diagram of a configuration process of an AP CM;

[0082] FIG3 b exemplarily shows a flow chart of a development method provided by the industry;

[0083] FIG4 exemplarily shows a flow chart of a development method provided by the present application;

[0084] FIG5 exemplarily shows a flow chart of configuring an application in a development device provided by the present application;

[0085] FIG6 exemplarily shows a schematic diagram of the software architecture of an operating device provided by the present application;

[0086] FIG7 exemplarily shows a schematic diagram of a communication configuration parameter allocation process provided by the present application;

[0087] FIG8 exemplarily shows a flow chart for developing a server-side application provided by the present application;

[0088] FIG9 exemplarily shows a flow chart for developing a client application provided by the present application;

[0089] FIG10 exemplarily shows a flow chart of modifying a communication configuration parameter provided by the present application;

[0090] FIG11 exemplarily shows a flow chart of modifying communication configuration parameters in a development device provided by the present application;

[0091] FIG12 exemplarily shows a flow chart of running an application using modified communication configuration parameters provided by the present application;

[0092] FIG13 exemplarily shows a schematic diagram of a verification process of a communication configuration parameter provided by the present application;

[0093] FIG14 exemplarily shows a complete flow chart of a development method provided by the present application;

[0094] FIG15 exemplarily shows a schematic diagram of a parameter optimization interface provided by the present application;

[0095] FIG16 exemplarily shows a possible structural diagram of a development device provided by the present application;

[0096] FIG17 exemplarily shows a possible structural diagram of another development device provided in the present application. DETAILED DESCRIPTION

[0097] The embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0098] The following describes possible application scenarios of the present application. It should be noted that these descriptions are for the purpose of facilitating understanding by those skilled in the art and do not limit the scope of protection claimed by the present application.

[0099] Please refer to Figure 1, which shows a schematic diagram of a possible application scenario provided by this application, using the development solution applied to the Internet of Vehicles as an example. As shown in Figure 1, this application scenario includes a development device 100 and an operation device 200. The development device 100 refers to the device used by developers to develop software programs and related configuration files, and can specifically be a computer, laptop computer, or other user terminal. The operation device 200 refers to the device that runs the software programs developed by developers, and can specifically be a vehicle or a component in the vehicle, such as an on-board chip, on-board controller, on-board terminal, on-board module, on-board module, on-board component, on-board unit, or on-board sensor, or it can also be a device or component outside the vehicle, such as an embedded device, server, cloud server, laptop computer, mobile phone, wearable device, robot, and smart home device, or it can also be a development device, that is, the development device 100 and the operation device 200 are the same device. It should be noted that when the operation device 200 is a device or component outside the vehicle, these devices or components can also be configured with the operating environment information required for the software to be developed to run in an actual vehicle, so that the software to be developed can be tested on the actual vehicle instead of the actual vehicle.

[0100] As shown in Figure 1, development information can be transmitted between the development device 100 and the operation device 200. The development information includes the software program developed by the developer in the development device 100, or may also include related configuration files. There are many ways to transmit development information. For example, in one example, the development device 100 and the operation device 200 can be connected by wire or wirelessly. In this case, the development device 100 can automatically or under instruction triggering transmit the development information to the operation device 200. For example, in another example, the development device 100 and the operation device 200 may not be connected, but the developer can manually copy the development information between the two. For example, in yet another example, the development information can also be transmitted by means of a third-party device. And so on. There are many possible implementation methods, which are not listed here one by one.

[0101] It should be understood that the possible application scenarios listed above are merely examples, and the development solutions provided in this application can also be applied to other possible scenarios, not limited to the ones exemplified above. For example, they can also be applied to other modes of transportation, such as ships, airplanes, helicopters, trains, subways, and high-speed trains, to assist developers in developing relevant functional software and improve the intelligence of transportation. In another example, they can also be applied to other communication devices besides transportation, such as access network equipment, mobile terminals, walkie-talkies, mobile phones, fax machines, pagers, computers, radios, satellite phones, radios, digital televisions, and routers, to achieve efficient communication service development. In another example, they can also be applied to near-eye display (NED) devices, including but not limited to augmented reality (AR) glasses, AR helmets, and virtual reality (VR) glasses or VR helmets. By simplifying the application software development process in NED devices, they can help achieve a more intelligent display experience. In another example, they can also be applied to aircraft, smart home devices, smart medical devices, industrial equipment, and so on. These examples are not listed here one by one.

[0102] It should be noted that the application scenarios described in this application are intended to more clearly illustrate the technical solutions of this application and do not constitute a limitation on the technical solutions provided in this application.

[0103] Based on the application scenario shown in Figure 1, please refer to Figure 2, which shows a schematic diagram of the software architecture for application development provided by this application. As shown in Figure 2, in this software architecture, the development device 100 can be configured with a development tool. The development tool is a software toolkit that can present a visual configuration interface to the user, allowing the user to directly configure development information, such as the application code file and runtime configuration file, on the development device 100 through interface interaction. The runtime device 200 can include three layers from top to bottom: the business layer, the communication middleware, and the protocol layer. By abstracting the communication semantics, the communication middleware can support different communication protocol types at the lower (protocol layer) and provide a unified service interface at the upper (business layer). With the support of the communication middleware, developers can use a unified service interface to develop applications in the development device 100. After importing the same application into different runtime devices 200, through the communication middleware and the communication protocol configuration in the protocol layer, it can run in actual vehicle environments that support different communication protocols, different hardware, and different operating systems, achieving decoupling of the business code from the underlying communication protocols, hardware, and operating system. Through this software architecture design, developers can focus more on business-level development without having to worry about the differences in details such as the underlying operating system, hardware, and communication protocols, thereby improving their development efficiency.

[0104] Currently, a wide range of communication middleware has been developed in the smart car sector, including but not limited to: VSOMEIP (an implementation of scalable service-oriented middleware over IP), data distribution service (DDS), robot operating system (ROS), common application programming interface (commonAPI), and automotive open system architecture (AUTOSAR). AUTOSAR, as an automotive industry standard, has introduced an adaptive platform (AP) based on the existing classic platform (CP). The AP provides communication management (CM) as its communication module. Developed based on a service-oriented architecture (SOA) model, this module greatly facilitates communication interfaces, platform switching, and third-party interoperability, and has been widely adopted by major smart driving platforms.

[0105] Although AP CM provides a unified API, it has a very complex modeled configuration process. For example, referring to Figure 3a, even a very simple communication service still requires developers to configure multiple configurations on the development device 100, including networking configuration, node configuration, component configuration, service interface configuration, protocol configuration, and mapping of service instances to networks and processes. If network or communication security issues are considered, security configuration is also required. Among these configurations, networking configuration, node configuration, component configuration, protocol configuration, and mapping of service instances to networks and processes can be collectively referred to as communication configuration. However, whether it is communication configuration, service interface configuration, or security configuration, multiple configuration items are involved. For example, as shown in Table 1 below, in AP CM, service interface configuration includes approximately 30 configuration items; communication configuration includes approximately 170 configuration items, involving approximately 10 protocol-shared configuration items, approximately 60 DDS configuration items, and approximately 100 SOME / IP configuration items; security configuration includes approximately 50 configuration items, involving end-to-end (E2E) communication protection configuration, identity and access management (IAM) configuration, secure onboard communication (Secoc) configuration, and transport layer security (TLS) configuration.

[0106] Table 1

[0107] According to Table 1 above, AP CM contains approximately 250 configuration items. While a communication service may not utilize all of these configuration items, AP CM requires a certain number of them to be configured at any one time. For example, as shown in Table 2 below, while AP CM only contains 30 basic communication items (i.e., service interface configuration items), 70 of them are mandatory. This means that a relatively comprehensive communication service requires developers to configure at least 70 configuration items. This large number of configuration items inevitably affects developer efficiency and reduces the usability of the communication middleware.

[0108] In addition to AP CM, other communication middleware also suffer from the problem of a large number of configuration items. For example, referring to Table 2, while the basic communication items for SOME / IP, commonAPI or VSOMEIP, only have 20, the number of mandatory items is as high as 100. This means that a relatively comprehensive communication service requires developers to configure at least 100 configuration items. Clearly, these two types of communication middleware require even more configuration items than AP CM, resulting in lower development efficiency and poorer usability.

[0109] Table 2

[0110] In summary, existing communication middleware has the problem of too many configuration items, which is mainly caused by the existing development and testing process. For example, please refer to Figure 3b, which shows a flowchart of a development method provided by the industry. The method mainly includes the following steps:

[0111] In step 301 , a developer configures service interface configuration items and operation parameter configuration items in the development device 100 .

[0112] As shown in Figure 3b, in the development device 100, the development tools may include a communication configuration tool, a code generation tool, and a configuration generation tool. The communication configuration tool connects to the developer and can present a visual interface to the developer. The developer can start the software configuration process by selecting service interface configuration items (such as the data type and communication form used for communication) and operating parameter configuration items (such as IP address, IP port, SOME / IP, EventID, DDS Topic, etc.) in the visual interface and clicking Finish.

[0113] Step 302 : The developer compiles and generates an application corresponding to the service interface on the development device 100 .

[0114] Here, the communication configuration tool first generates a standard communication configuration file based on the service interface configuration items and operational parameter configuration items selected by the user. It then invokes the code generation tool to generate service interface code based on the service interface configuration items in the standard communication configuration file. This service interface code contains the application programming interface (API) required for service development. Developers can use this service interface code to add the corresponding business logic, thereby compiling and generating the application corresponding to the service interface.

[0115] Step 303: The development device 100 generates an operation configuration file according to the operation parameter configuration items.

[0116] Here, the communication configuration tool may call the configuration generation tool to generate an application-related running configuration file according to the running parameter configuration item information in the standard communication configuration file.

[0117] It should be noted that the operations of the communication configuration tool, code generation tool, and configuration generation tool are internal to development device 100, or more specifically, the development tools, and are not visible to developers. In other words, developers only need to configure service interface configuration items and runtime parameter configuration items on development device 100 and perform the corresponding compilation operations to directly obtain the corresponding application and runtime configuration files.

[0118] In step 304 , the development device 100 exports the application program and the execution configuration file to the execution device 200 .

[0119] Here, referring to Figure 2 , after receiving the application and the runtime configuration file, runtime device 200 can launch the application. After the application is launched, the business layer of runtime device 200 calls the corresponding interface of the communication middleware. The communication middleware reads the runtime configuration file and sets the read runtime configuration information to the protocol layer. The communication middleware then calls the relevant interface in the protocol layer, establishes a communication channel for the application, and executes the corresponding communication logic based on this communication channel.

[0120] Using the aforementioned development solution provided by the industry, developers need to configure not only service interface configuration items on the development device 100, but also operational parameter configuration items. As shown in Tables 1 and 2 above, while the number of service interface configuration items is relatively small, the number of operational parameter configuration items (i.e., mandatory configuration items other than service interface configuration items) is considerable. For example, AP CM has only 30 service interface configuration items, but 70 mandatory items. Similarly, SOME / IP-based commonAPI or VSOMEIP has only 20 service interface configuration items, but 100 mandatory items. Clearly, configuring both service interface configuration items and operational parameter configuration items simultaneously requires developers to configure a significant number of configuration items on the development device 100, which is a major factor in reducing development efficiency.

[0121] In view of this, the present application provides a development method, which allocates communication configuration parameters to the application by running the device, so that developers only need to configure the service interface configuration items on the development device without having to configure the running parameter configuration items, thereby effectively reducing the number of configuration items that developers need to configure and improving the development efficiency of the application.

[0122] The development plan proposed in this application is described in detail below with reference to the specific drawings.

[0123] In the various embodiments of the present application, unless otherwise specified or there is any logical conflict, the terms and / or descriptions between different embodiments are consistent and can be referenced by each other. The technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.

[0124] Please refer to Figure 4, which is a flow chart of a development method provided by this application. The method is applicable to an operating device, such as the operating device 200 shown in Figure 1 or Figure 2. As shown in Figure 4, the method includes:

[0125] Step 401: The operating device obtains first development information, where the first development information includes a first application, which is an application generated by a user on the development device.

[0126] Here, the user can be understood as a developer. The first application can be understood as a computer program file of application software, such as a binary file.

[0127] Alternatively, the first application can be a program file generated by a developer using a development tool in the development device 100 after writing or compiling. For example, referring to FIG5 , when it is necessary to develop application software, the developer can start the communication configuration tool in the development device 100 and configure the service interface configuration items in the visual interface provided by the communication configuration tool, including the data type used for communication, the communication form, and other information related to the interface. The communication configuration tool generates a standard communication configuration file based on the service interface configuration items, such as an ARXML file for Autosar, an IDL file for DDS, a FIDL file or an FDEPL file for CommonAPI, etc. Afterwards, the communication configuration tool can call a code generation tool to generate the service interface code of the application software based on the service interface configuration item information in the standard communication configuration file. The developer then adds the corresponding business logic to the service interface code to compile and generate the first application.

[0128] Furthermore, optionally, after generating the first application, the developer may export the first application from the development device 100 to the execution device 200. For example, the developer may manually copy the first application to the execution device 200 via a storage device. Alternatively, the developer may trigger the development device 100 to automatically send the first application to the execution device 200 via a command. The triggering method of the command may include, but is not limited to, voice commands, interface commands, key commands, gesture commands, brainwave commands, etc. Alternatively, the development device 100 may automatically send the first application to the execution device 200 after determining that it has been generated. This is not a specific limitation.

[0129] Through the above configuration method, developers can simply configure service interface configuration items on the development device 100 and compile the corresponding application to run the application, without having to configure the runtime parameter configuration items. For example, referring to Table 2, developers can configure only approximately 30 service interface configuration items in the AP CM development tool, without having to configure 70 mandatory items. Alternatively, developers can configure only approximately 20 service interface configuration items in the commonAPI (SOME / IP) or VSOMEIP development tool, without having to configure 100 mandatory items. This can significantly reduce the number of configuration items and significantly improve developer efficiency.

[0130] Step 402: The running device runs a first application and allocates first communication configuration parameters to the first application.

[0131] Here, after the running device 200 receives the first application, it can store the first application in the local storage space.

[0132] Afterwards, if the execution device 200 receives a startup instruction from the developer, it can run the locally stored first application (or, it can automatically run without receiving an instruction) and simultaneously obtain the communication configuration parameters corresponding to the first application locally. However, since the development device 100 only sends the first application to the execution device 200, the execution device 200 cannot obtain the communication configuration parameters. In other words, there are no static communication configuration parameters. In this case, the execution device 200 can dynamically allocate the first communication configuration parameters for the first application.

[0133] Optionally, in one possible allocation method, preset parameter configuration information is stored in the operating device 200, and the preset parameter configuration information includes the allocation range of resource class parameters and / or the default parameter values ​​of non-resource class parameters. Among them, resource class parameters refer to parameters that cannot be repeatedly allocated, such as but not limited to: service identification (identity document, ID), service port, communication entity ID and process ID. Non-resource class parameters refer to parameters that can be repeatedly allocated, such as but not limited to: IP address and communication protocol. When it is necessary to allocate the first communication configuration parameters for the first application, the operating device 200 can first obtain the preset parameter configuration information, and then:

[0134] If the preset parameter configuration information includes a resource parameter allocation range, the operating device 200 may first determine unoccupied resource parameter values ​​within the resource parameter allocation range based on the assigned communication configuration parameters, and then allocate resource parameter values ​​to the first application based on the unoccupied parameter values. This ensures that resource parameters assigned to various applications are not duplicated, thus avoiding resource parameter conflicts and ensuring the reliability and availability of the assigned resource parameters.

[0135] If the preset parameter configuration information includes a default value for a non-resource parameter, the operating device 200 may first determine whether the first development information indicates a specified parameter value for the non-resource parameter. If so, the specified parameter value for the non-resource parameter is assigned to the first application. Otherwise, the default value for the non-resource parameter (if multiple default values ​​exist, one of the default values ​​may be selected) is assigned to the first application. In this way, the allocation method can be adapted to business scenarios with or without specified non-resource parameter requirements, achieving universal applicability.

[0136] It should be understood that this application is not limited to the above-mentioned allocation method. For example, in another possible allocation method, preset parameter configuration information can also be managed by a third-party device. When the operating device 200 needs to allocate the first communication configuration parameter for the first application, it can directly send a parameter request message to the third-party device. The third-party device retrieves the corresponding communication configuration parameter from the preset parameter configuration information based on the parameter request message and returns it to the operating device 200. Alternatively, in another possible allocation method, the operating device 200 can obtain the preset parameter configuration information from the third-party device and then allocate the first communication configuration parameter on its own, and so on. There are many other possible allocation methods, which are not listed here one by one.

[0137] Optionally, after assigning the first communication configuration parameters to the first application, the operating device 200 may also establish a communication channel for the first application based on the first communication configuration parameters. The communication channel may be a communication channel used for testing or a communication channel in an actual use scenario, without limitation.

[0138] For example, taking the communication channel used for testing as an example, in the specific implementation, the operating device 200 can start the first application. At this time, the business layer in the operating device 200 will call the corresponding interface in the communication middleware. The communication middleware obtains the dynamically allocated first communication configuration parameters and configures them to the bottom protocol layer. After that, the relevant interface is called from the protocol layer to establish the communication channel of the first application, and the relevant communication logic is executed based on the communication channel, such as communication interaction with virtual components. Afterwards, if the communication logic result shows that the communication channel can communicate normally, it means that the first application and the first communication configuration parameters are correct. Therefore, the developer can apply the first application and the first communication configuration parameters to the actual vehicle environment. If the communication logic result shows that the communication channel cannot communicate normally, it means that the development process is wrong. In this case, the developer needs to correct the first application or the first communication configuration parameters according to the abnormal information before applying it to the actual vehicle environment.

[0139] For example, taking the communication channel in an actual usage scenario as an example, in a specific implementation, the operating device 200 may be a real vehicle or a component in a real vehicle. The real vehicle or a component in a real vehicle may establish a communication channel for the first application through the business layer and the communication middleware, combined with the first communication configuration parameters and the relevant interfaces in the bottom protocol layer, and realize communication with other components in the vehicle based on the communication channel to realize vehicle functions.

[0140] By adopting the above development method, the communication configuration parameters are assigned to the application by running the device while the application is running, so that the developer can only configure the service interface configuration items in the development device without having to configure the running parameter configuration items. This can significantly reduce the number of configuration items required to develop the application, effectively improve the development efficiency of the developer, and thus improve the ease of use of the development method.

[0141] In one possible implementation, to flexibly manage the communication configuration parameters of one or more applications, a parameter server can be set up in the operating device 200, as shown in Figure 6. This parameter server can be understood as a software process in the operating device 200. This software process can be set up outside the software process where the communication middleware resides, or it can be set up within the software process where the communication middleware resides, existing as a service interface. To facilitate understanding of the solution, the following description uses the example of a parameter server set up outside the communication middleware.

[0142] Based on the software architecture shown in FIG6 , please refer to FIG7 , which is a schematic diagram of a communication configuration parameter allocation process provided by this application. The process includes the following steps:

[0143] Step 701: The parameter server is started.

[0144] Here, after receiving the developer's instruction to start the first application, the running device 200 may first start the parameter server, for example, by triggering the instruction to start the parameter server, so that the subsequent communication middleware can successfully interact with the parameter server.

[0145] Step 702: The communication middleware runs the first application.

[0146] Here, after starting the parameter server, the operating device 200 can call the corresponding interface in the communication middleware through the business layer to run the communication function in the first application.

[0147] Alternatively, the communication middleware, along with its upper-layer business layer and lower-layer protocol layer, can be understood as another software process within the operating device 200. In other words, the communication middleware and parameter server belong to different software processes. The communication middleware is primarily responsible for running the communication functions within the application, while the parameter server is primarily responsible for managing and distributing the application's communication configuration parameters. This decoupling of application execution from distributing communication configuration parameters can be achieved through the communication middleware and parameter server, enabling separate maintenance and management of operations related to the communication configuration parameters.

[0148] Step 703: The communication middleware sends a parameter request message to the parameter server.

[0149] Here, the communication middleware can first obtain the communication configuration parameters corresponding to the first application locally, but because the user only configured the service interface configuration items but not the operation parameter configuration items, the communication middleware cannot obtain the communication configuration parameters. That is, the first application does not have static communication configuration parameters. In this case, the communication middleware can send a parameter request message to the parameter server.

[0150] Optionally, the parameter request message may include a parameter identifier requested by the first application, or may also include other information, such as a specified parameter value of a non-resource parameter.

[0151] Step 704: The parameter server allocates first communication configuration parameters to the first application according to preset parameter configuration information.

[0152] Here, the preset parameter configuration information can be stored in a certain storage space of the operating device 200, and the address information of the storage space is known to the parameter server. In other words, the parameter server can obtain the preset parameter configuration information. In this way, the parameter server can dynamically allocate the first communication configuration parameter to the first application according to the preset parameter configuration information, such as allocating the unoccupied parameter value of the resource class parameter to the first application, and the specified parameter value of the non-resource class parameter indicated by the first request message or the default parameter value of the non-resource class parameter contained in the preset parameter configuration information. The specific allocation process can be found in the above step 402, which will not be repeated here.

[0153] Step 705: The parameter server sends the first communication configuration parameter to the communication middleware.

[0154] Here, after the communication middleware receives the first communication configuration parameter from the parameter server, it can add the first communication configuration parameter to the bottom protocol layer, and then call the relevant interface in the bottom protocol layer to establish a communication channel for the first application.

[0155] In one possible implementation, after assigning the first communication configuration parameters to the first application, the parameter server may also synchronously store the first communication configuration parameters corresponding to the first application locally. For example, the parameter server may also store parameter allocation information, which includes communication configuration parameters corresponding to one or more applications. The communication configuration parameters corresponding to any application may be assigned to the application by the parameter server, or may be modified or optimized by the developer, or may be carried in the development information, such as generated by the developer after synchronously configuring the running parameter configuration items when developing the application on the development device. After assigning the first communication configuration parameters to the first application, the parameter server may also add the first communication configuration parameters corresponding to the first application to the parameter allocation information. In this way, the next time the communication middleware requests the communication configuration parameters of the first application, the parameter server can directly query the corresponding first communication configuration parameters from the parameter allocation information and return them to the communication middleware without having to re-execute the allocation process, thereby improving the initialization speed of the first application.

[0156] Optionally, the parameter allocation information can be stored in any storage form, such as a table, image, database, stack or formula. Taking table storage as an example, please refer to Table 3.1 and Table 3.2, which show a schematic diagram of a parameter allocation table provided by this application. This schematic takes the parameter allocation table as an example, including multiple sub-tables, where Table 3.1 can be understood as a sub-table based on the service name, and Table 3.2 can be understood as a sub-table based on the process name. That is, Table 3.1 shows the parameters related to the service name, and Table 3.2 shows the parameters of different services related to the process name. Of course, the actual parameter allocation table can also include other sub-tables, such as a sub-table based on the communication entity name, a sub-table based on the application name, etc., or the actual parameter allocation table can also be presented as a complete table, which is not specifically limited in this application.

[0157] Table 3.1

[0158] Table 3.2

[0159] As shown in Tables 3.1 and 3.2 above, a parameter allocation table may include parameter names and values ​​for one or more parameters corresponding to one or more services. For example, in the subtable shown in Table 3.1, the Radar service may have different service instances, such as Service Instance 1 and Service Instance 2. Both service instances support the DDS communication protocol, have a service ID of 1, and a communication entity name of Event 1. The E2E DataID for Service Instance 1 is 1, while the E2E DataID for Service Instance 2 is 2. In the subtable shown in Table 3.2, a single Process1 process may correspond to different services and service parameters. Different service instances of any service may have different service ports. For example, the service port for Service Instance 1 of the Radar service is 33641, the service port for Service Instance 1 of the Camera service is 33641, the service port for Service Instance 2 of the Camera service is 33642, and the service port for Service Instance 3 of the Lidar service is 33641. It should be understood that Tables 3.1 and 3.2 are merely examples. Actual subtables may contain other parameter names and values, which are not listed here.

[0160] Furthermore, the parameters in the parameter allocation table may optionally include resource-related parameters. Resource-related parameters may include, but are not limited to, the service instance name, service ID, communication entity name, and E2E DataID in Table 3.1, and the service port in Table 3.2. The parameter values ​​for the resource-related parameters in the parameter allocation table are all occupied parameter values. For example, in the subtables shown in Tables 3.1 and 3.2, E2EDataID1 and service port 33641 for the Radar service are already occupied by service instance 1, and E2E DataID2 for the Radar service is already occupied by service instance 1. Therefore, if the parameter server subsequently receives a parameter request message for the Radar service, it will need to allocate service instance names other than service instance name 1 and service instance name 2, such as service instance name 3; E2E DataIDs other than E2E DataID 1 and E2E DataID 2, such as E2E DataID 3; and service ports other than service port 33641, such as service port 33642.

[0161] Furthermore, optionally, to implement categorized management of occupied and unoccupied parameter values ​​for resource parameters, the parameter server may also mark the parameter values ​​of resource parameters in the parameter allocation table as occupied. For example, after storing the first communication configuration parameters corresponding to the first application in the parameter allocation table, the parameter server may also mark the parameter values ​​of the resource parameters contained in the first communication configuration parameters as occupied. There are many ways to mark these values, including software-based marking, such as setting occupied parameter values ​​of resource parameters to 1 and unoccupied parameter values ​​of resource parameters to 0 within the software program. Alternatively, marking may be performed in a table, such as color marking, text marking, line marking, or shape marking within the parameter allocation table, without limitation. Alternatively, marking may be performed within pre-set parameter configuration information, such as deleting occupied parameter values ​​within the allocated range of resource parameters in the pre-set parameter configuration information, or adding colors or annotations to occupied parameter values ​​within the allocated range of resource parameters in the pre-set parameter configuration information, and so on. There are many other possible marking methods, which are not listed here.

[0162] Furthermore, optionally, the parameters in the parameter allocation table may also include non-resource parameters, which may include, but are not limited to, the service names and communication protocols in Table 3.1. The parameter values ​​of the non-resource parameters in the parameter allocation table may be the parameter values ​​specified in the parameter request message, or may be the default parameter values ​​of the non-resource parameters in the preset parameter configuration information. The parameter values ​​of the non-resource parameters corresponding to different applications may be repeated. For example, in the parameter allocation table shown in Table 3.1, the communication protocols supported by service instance 1 and service instance 2 of the Radar service are both DDS. If the parameter server subsequently receives a parameter request message, and the service specified in the parameter request message is Radar, the parameter server can still assign the service name Radar to the Radar service. If the default communication protocol in the preset parameter configuration information is DDS, the parameter server can still assign the communication protocol DDS to the Radar service.

[0163] In one possible implementation, the first application can be a server application or a client application for an in-vehicle service. A server refers to a terminal that provides communication services, and a client refers to a terminal that uses the communication services provided by a server. During operation, the server application can directly establish a communication channel, or it can first establish a communication service and then establish a communication channel. Similarly, during operation, the client application can directly establish a communication channel with the server, or it can first discover the server's communication service and then establish a communication channel with the server. The parameters of the communication service and the communication channel are different. Communication service parameters may include, for example, the service name, communication protocol, service ID, service instance, and other service parameters listed in Table 3.1 above, while communication channel parameters may include the communication entity parameters listed in Table 3.1 above, the E2E DataID listed in Table 3.2, and other channel parameters. In the communication process between the server and the client, in addition to the service parameters, successful data communication between the two parties requires that the server and the client configure consistent channel parameters (also called communication entity parameters). These channel parameters may be requested together with the service parameters, or they may be requested separately from the service parameters in two separate requests, without limitation.

[0164] To further introduce the specific parameter allocation process, the following describes in detail the implementation process of applying for all parameters at once and applying for different parameters twice through implementation method one and implementation method two respectively.

[0165] Implementation method 1

[0166] Please refer to Figure 8, which shows a flow chart for developing a server application provided by this application. The figure takes the server application directly establishing a communication channel as an example. The process includes the following steps:

[0167] Step 801: The parameter server is started.

[0168] Step 802: The communication middleware runs the first application.

[0169] Here, after the operating device 200 receives the service request sent by the developer, it first starts the parameter server according to the service request, and then calls the corresponding interface in the communication middleware through the business layer to run the communication function in the first application.

[0170] Step 803: The communication middleware sends a parameter request message to the parameter server. The parameter request message is used to request service parameters and channel parameters.

[0171] Here, assuming that the running device 200 only receives the first application sent by the development device 100, the communication middleware cannot query the static communication configuration parameters corresponding to the first application locally. Therefore, the communication middleware can send a parameter request message to the parameter server to request the communication configuration parameters corresponding to the first application.

[0172] Optionally, the parameter request message may carry parameter name information for each service parameter and each channel parameter requested by the first application. Service parameter parameter name information may include, but is not limited to, the service name, service instance name, and process information (such as the process name). Channel parameter parameter name information may include, but is not limited to, a communication entity identifier (such as the communication entity name) and attribute information of the communication entity. This attribute information may include, for example, the names of the AP CM's event, method, and field, and field notifier, setter, and getter setting information.

[0173] Step 804: The parameter server allocates first communication configuration parameters to the first application according to preset parameter configuration information. The first communication configuration parameters include parameter values ​​of service parameters and parameter values ​​of channel parameters.

[0174] Step 805: The parameter server sends a parameter response message to the communication middleware, which carries the first communication configuration parameter.

[0175] In steps 804 and 805 above, after receiving the parameter request message, the parameter server may first query the parameter allocation information (such as the parameter allocation tables shown in Table 3.1 and Table 3.2), and determine whether the second communication configuration parameters corresponding to the first application are stored in the parameter allocation information:

[0176] If the second communication configuration parameters are already stored in the parameter allocation information, and the second communication configuration parameters include both all service parameters and all channel parameters, the parameter server may directly generate a parameter response message based on the second communication configuration parameters and return it to the communication middleware;

[0177] If the second communication configuration parameters are already stored in the parameter allocation information, but the second communication configuration parameters only include part of the service parameters and / or channel parameters, such as only the service parameters or part thereof, or only the channel parameters or part thereof, or all the service parameters and part of the channel parameters, or all the channel parameters and part of the service parameters, or part of the channel parameters and part of the service parameters, then the parameter server may obtain the preset parameter configuration information again, and may allocate parameter values ​​for the channel parameters and / or service parameters not included in the second communication configuration parameters based on the unoccupied parameter values ​​of the resource class parameters and the default parameter values ​​of the non-resource class parameters in the preset parameter configuration information. Afterwards, the parameter server may store the parameter values ​​of the parameters allocated this time in the parameter allocation information, and may mark the parameter values ​​of the resource class parameters therein as occupied. Furthermore, the parameter server may also generate a parameter response message based on the parameter values ​​of the parameters allocated this time and the parameter values ​​of the parameters stored in the second communication configuration parameters, and return it to the communication middleware;

[0178] If the second communication configuration parameters are not stored in the parameter allocation information, the parameter server may retrieve the preset parameter configuration information and dynamically allocate first communication configuration parameters for the first application based on the unused parameter values ​​of resource parameters and the default parameter values ​​of non-resource parameters in the preset parameter configuration information. The first communication configuration parameters include all service parameters and all channel parameters. The parameter server may then store the first communication configuration parameters corresponding to the first application in the parameter allocation information and mark the parameter values ​​of the resource parameters therein as used. Furthermore, the parameter server may generate a parameter response message based on the dynamically allocated first communication configuration parameters and return it to the communication middleware.

[0179] Step 806: The communication middleware creates a communication service according to the parameter values ​​of the service parameters in the first communication configuration parameters, and establishes a communication channel according to the parameter values ​​of the channel parameters in the first communication configuration parameters.

[0180] Here, after the communication middleware receives the parameter response message returned by the parameter server, it can add the communication configuration parameters (including service parameters and channel parameters) carried therein to the bottom protocol layer, and then call the relevant interface in the bottom protocol layer to establish a communication channel for the first application to initiate the service provision process.

[0181] By adopting the above allocation process, service parameters and channel parameters can be directly allocated through a single communication between the parameter server and the communication middleware, so that the communication middleware can directly execute the channel logic based on these two types of parameters obtained from the parameter server, thereby reducing communication overhead and improving the operating efficiency of the application.

[0182] Implementation method 2

[0183] Please refer to Figure 9, which shows a development flow chart of a client application provided by this application. The client can be started before the server or after the server. When the client is started before the server, since the server is started irregularly, if the client obtains the channel parameters first when the server is not started, it will occupy some resources, but there will be no communication between the client and the server, so the client's channel parameters are not used, which will cause a waste of resources. At the same time, there will be channel redundancy when creating a channel, which will affect the operating noise. Therefore, in order to save resources and reduce the operating noise, the client's startup method can be divided into two stages, namely first discovering the communication service of the server and then establishing a communication channel. As shown in Figure 9, the process may specifically include the following steps:

[0184] Step 901: The parameter server is started.

[0185] Step 902: The communication middleware runs the first application.

[0186] Step 903: The communication middleware sends a service parameter request message to the parameter server, where the service parameter request message is used to request service parameters.

[0187] Here, the message of the service parameter request message may carry parameter name information of each service parameter requested by the first application, such as the service name, service instance name, and process name.

[0188] Step 904: The parameter server allocates service configuration parameters to the first application according to preset parameter configuration information. The service configuration parameters include parameter values ​​of the service parameters.

[0189] Step 905: The parameter server sends a service parameter response message to the communication middleware, which carries the service configuration parameters.

[0190] In the above steps 904 and 905, after receiving the service parameter request message, the parameter server may first query the parameter allocation information (such as the parameter allocation table shown in Table 3.1 and Table 3.2):

[0191] If the server application already provides a corresponding communication service, the server application has already requested service parameters and channel parameters when establishing the communication service. Therefore, the parameter allocation information will store the parameter values ​​of the service parameters and channel parameters corresponding to the first application. Therefore, the parameter server can query the parameter values ​​of the service parameters corresponding to the first application from the parameter allocation information. The parameter server can directly generate a service parameter response message based on the parameter values ​​of the service parameters and return it directly to the communication middleware.

[0192] On the contrary, when the server application has not yet provided the corresponding communication service, or the communication service provided by the server application is different from the communication service requested by the client application, the parameter allocation information may not store the parameter values ​​of all service parameters corresponding to the first application. In this case, the parameter server can query the preset parameter configuration information again, and then allocate the parameter values ​​of the service parameters not included in the parameter allocation information to the first application based on the unoccupied parameter values ​​of the resource class parameters and the default parameter values ​​of the non-resource class parameters. The parameter server can also generate service configuration parameters based on the parameter values ​​of the service parameters allocated this time and the parameter values ​​of the service parameters already included in the parameter allocation information, and then carry the service configuration parameters in the service parameter response message and return it to the communication middleware. In addition, the parameter server can also store the parameter values ​​of the service parameters allocated this time in the parameter allocation information, and mark the parameter values ​​of the resource class parameters therein as occupied.

[0193] Using the above example, even if the client application is started before the server application is started, the server application can obtain the service configuration parameters assigned when the client application is started from the parameter allocation information when it is started, thereby maintaining the consistency of the service parameters of the server and client, facilitating successful communication between the two service parties.

[0194] Step 906: The communication middleware performs service discovery according to the service configuration parameters.

[0195] Step 907: If the communication middleware finds that the server has provided the corresponding service, it sends a channel parameter request message to the parameter server. The channel parameter request message is used to request channel parameters.

[0196] Here, the communication middleware can add service configuration parameters to the bottom protocol layer and call the relevant interfaces in the bottom protocol layer to perform service discovery. If the service discovery result shows that the server has provided the corresponding communication service, a client entity must be established to communicate with the server. Therefore, the communication middleware can also send a channel parameter request message to the parameter server. The message of this channel parameter request message can carry parameter name information of each channel parameter requested by the first application, such as a communication entity identifier (such as the communication entity name), and attribute information of the communication entity, such as the names of the AP CM's event, method, and field, and the field's notifier, setter, and getter settings. Conversely, if the service discovery result shows that the server has not yet provided the corresponding service, the client can wait until the server provides the service (for example, after the server starts, it sends a notification message to the client) before sending the above channel parameter request message to the parameter server.

[0197] Step 908: The parameter server allocates channel configuration parameters to the first application according to the preset parameter configuration information. The channel configuration parameters include parameter values ​​of the channel parameters.

[0198] Step 909: The parameter server sends a channel parameter response message to the communication middleware, which carries the channel configuration parameters.

[0199] In the above steps 908 and 909, after receiving the channel parameter request message, the parameter server may first query the parameter allocation information (such as the parameter allocation table shown in Table 3.1 and Table 3.2):

[0200] In the case where the server application has already provided the corresponding communication service, the server application has already requested the service parameters and channel parameters when establishing the communication service. Therefore, the parameter allocation information will store the parameter values ​​of the service parameters and channel parameters corresponding to the first application. Therefore, the parameter server can query the parameter values ​​of the channel parameters corresponding to the first application from the parameter allocation information. The parameter server can directly generate a service parameter response message based on the parameter values ​​of the channel parameters and directly return it to the communication middleware.

[0201] On the contrary, when the server application has not yet provided the corresponding communication service, or the communication service provided by the server application is different from the communication service requested by the client application, the parameter allocation information may not store the parameter values ​​of all the channel parameters corresponding to the first application. In this case, the parameter server can query the preset parameter configuration information again, and then allocate the parameter values ​​of the channel parameters that do not exist in the parameter allocation information to the first application based on the unoccupied parameter values ​​of the resource class parameters and the default parameter values ​​of the non-resource class parameters. The parameter server can also generate channel configuration parameters based on the parameter values ​​of the channel parameters allocated this time and the parameter values ​​of the channel parameters that already exist in the parameter allocation information, and then carry the channel configuration parameters in the channel parameter response message and return it to the communication middleware. In addition, the parameter server can also store the parameter values ​​of the channel parameters allocated this time in the parameter allocation information, and mark the parameter values ​​of the resource class parameters therein as occupied.

[0202] Step 910: The communication middleware establishes a communication channel according to the channel configuration parameters.

[0203] Here, after the communication middleware receives the channel configuration parameters returned by the parameter server, it can add the channel configuration parameters to the bottom protocol layer, call the relevant interface of the bottom protocol layer, establish a communication channel on the communication service sent previously, and conduct communication interaction with the server application.

[0204] By adopting the above allocation process, the service parameters and channel parameters corresponding to the client application can be obtained respectively through two communications between the parameter server and the communication middleware, so as to perform service discovery and channel establishment in sequence. This ensures that the client applies for channel parameters only after the server is started, thereby avoiding resource occupation caused by the client applying for channel parameters in advance when the server is not started for a long time, and the operation noise caused by the client establishing the communication channel in advance.

[0205] In some special scenarios, the communication configuration parameters automatically assigned by the parameter server may not meet the requirements of the specific scenario. For example, in one possible scenario, the parameter server defaults to disabling the aggregation attribute of the SOME / IP Event (that is, sending the message immediately) and to unicasting the data transmission mode of the SOME / IP Event. However, in scenarios with limited network resources and low service latency requirements, such as high-performance communication scenarios, to reduce network traffic, it is usually necessary to set the aggregation attribute of the SOME / IP Event of certain communication entities to aggregation and multicast communication. For example, in another possible scenario, the parameter server defaults to assigning a certain service ID, port, or other parameter value to the client and server. However, in a third-party communication scenario, the third party has explicitly defined a different service ID, port, or parameter value for the client and server. In these situations, the communication configuration parameters automatically assigned by the parameter server may not match the actual application scenario requirements.

[0206] To solve the above problem, in one possible implementation, the operating device 200 can also support exporting the communication configuration parameters stored in the parameter allocation information to the development device 100 for modification. For example, refer to Figure 10, which shows a schematic diagram of a communication configuration parameter modification process provided by this application, which includes the following steps:

[0207] Step 1001: The operating device allocates first communication configuration parameters to a first application.

[0208] Here, the first communication configuration parameter may include communication protocol configuration information related to the first application, belonging process information, communication topology information, and environment configuration information, etc., or may also include other parameter information.

[0209] Here, the first communication configuration parameter may be stored in the parameter allocation information of the running device 200. The first communication configuration parameter may be previously allocated to the first application by a parameter server, may be previously allocated to the first application by a parameter server and then modified by a user, or may be generated by a user after configuring a running parameter configuration item on a development device, without limitation.

[0210] Step 1002: The operating device sends a first communication configuration parameter to the development device based on the first instruction.

[0211] Here, the parameter server may support exporting communication configuration parameters in the parameter allocation information.

[0212] In one example, the first instruction can be an update instruction, export instruction, copy instruction, or other instruction from a developer. For example, if the developer determines that the first communication configuration parameters need to be optimized and adjusted, the developer can manually copy the first communication configuration parameters from the parameter allocation information of the operating device 200 to the development device 100 via a storage device, or can instruct the parameter server in the operating device 200 to automatically send the first communication configuration parameters to the development device 100 through voice instructions, text instructions, or gesture instructions.

[0213] Alternatively, in another example, when the development device 100 exports the first application to the running device 200, it can also synchronously carry the first instruction. Therefore, after the parameter server in the running device 200 allocates the first communication configuration parameters to the first application, it can directly send the first communication configuration parameters to the development device 100.

[0214] Of course, other export methods are also possible and are not specifically limited.

[0215] Step 1003: The development device displays the first communication configuration parameter to the developer.

[0216] Step 1004: The development device obtains a third communication configuration parameter, where the third communication configuration parameter is obtained by the developer modifying the first communication configuration parameter on the development device.

[0217] Optionally, referring to Figure 11 , in steps 1003 and 1004 above, after obtaining the first communication configuration parameters, the development device 100 may invoke a communication configuration tool to convert the format of the first communication configuration parameters. The communication configuration tool may automatically generate a standard communication configuration file, such as an Autosar ARXML file, based on the parameter-related information in the first communication configuration parameters. The standard communication configuration file is a visual interface file. The communication configuration tool may display a corresponding configuration interface on the display screen of the development device 100 based on the standard communication configuration file, allowing developers to directly modify relevant configuration details on the configuration interface, such as changing the communication entity designation to packet aggregation or multicast communication, or modifying the parameter values ​​of the service ID, service port, or other parameters to those specified by a third party. The communication configuration tool may then send the developer's modified standard communication configuration file to the configuration generation tool, which then generates third communication configuration parameters based on the modified standard communication configuration file.

[0218] The format of the third communication configuration parameters can be the same as or different from the standard communication configuration file. For example, in one example, the format of the third communication configuration parameters is different from the standard communication configuration file, but the same as the format of the first communication configuration parameters. In this way, the third communication configuration parameters can serve as a running configuration file to directly support the running test of the first application.

[0219] Step 1005: The development device sends the third communication configuration parameter to the operation device.

[0220] Here, the developer can use a storage device to manually copy the third communication configuration parameters from the development device 100 to the running device 200, or instruct the development device 100 to automatically send the third communication configuration parameters to the running device 200 through instructions, or the development device 100 can directly send the third communication configuration parameters to the development device 200 after detecting that the third communication configuration parameters have been generated. There is no specific limitation.

[0221] Step 1006: The operating device establishes a communication channel for the first application based on the third communication configuration parameters.

[0222] Here, after receiving the third communication configuration parameters, the parameter server in the operating device 200 may update the communication configuration parameters corresponding to the first application stored in the parameter allocation information according to the third communication configuration parameters. The updating method may, for example, modify the first communication configuration parameters corresponding to the first application to the third communication configuration parameters, overwrite the original first communication configuration parameters with the third communication configuration parameters, or annotate the original first communication configuration parameters with text, etc. In this way, when the communication middleware subsequently requests the communication configuration parameters of the first application from the parameter server again, the parameter server can directly return the user-modified third communication configuration parameters to the communication middleware by querying the parameter allocation information, so that the communication middleware can establish a communication channel for the first application based on the user-modified third communication configuration parameters, thereby implementing communication testing for special scenarios.

[0223] The above method allows developers to modify or optimize communication configuration parameters for certain scenarios. Although developers still need to use development tools to configure communication configuration parameters, the complete communication configuration parameters have been automatically generated by the parameter server before configuration. Developers only need to modify one or several parameter configurations (such as packet aggregation and multicast configuration) (also known as single-point configuration optimization) in a targeted manner, without having to configure all operating parameter configuration items as in existing technologies. Therefore, the modified communication configuration parameters can better meet the needs of actual scenarios while significantly reducing the number of configuration items.

[0224] It should be noted that after the parameter server assigns the first communication configuration parameters to the first application, if the first instruction described above is present, the server may wait for the development device to return the modified third communication configuration parameters before establishing a communication channel based on the modified third communication configuration parameters. If the first instruction described above is absent, the server may directly establish a communication channel based on the first communication configuration parameters assigned by the parameter server. This makes the development method compatible with both special scenarios requiring communication configuration parameter modification and general scenarios not requiring modification, thus achieving universal applicability.

[0225] In the above development method, since a dynamic parameter allocation process is added before the application actually runs, the startup speed of the application may be slowed down. Therefore, the above development method may not be suitable for some scenarios that require fast startup.

[0226] To solve this problem, in one possible implementation, the development device 100 can also store the first communication configuration parameters exported by the running device 200 (corresponding to the scenario where the communication configuration parameters do not need to be modified) or the third communication configuration parameters modified by the developer (corresponding to the scenario where the communication configuration parameters need to be modified) locally as a static running configuration file. Taking the third communication configuration parameters as an example, please refer to Figure 12. When the developer subsequently develops the first application again, he can still only configure the service interface configuration item on the development device 100. The service interface configuration item is compiled by the communication configuration tool, code generation tool and user in the development device 100 to generate the first application. Since the third communication configuration parameters corresponding to the first application are statically stored locally on the development device 100, the developer can also directly obtain the static third communication configuration parameters from the local development device 100, and export the first application and the static third communication configuration parameters together as the second development information to the running device 200. In this way, since the second development information contains both the first application and the static third communication configuration parameters, after starting the first application, the running device 200 can directly obtain the static third communication configuration parameters to establish a communication channel for the first application without having to reallocate the communication configuration parameters for the first application. This saves the dynamic parameter allocation process before starting the first application and effectively improves the initialization speed of the first application.

[0227] Furthermore, optionally, to ensure consistency between the static communication configuration parameters stored on the development device 100 and the communication configuration parameters managed on the operation device 200, upon receiving a static third communication configuration parameter, the operation device 200 may also verify the static third communication configuration parameter based on the communication configuration parameter managed on the operation device 200. For example, referring to FIG13 , a schematic diagram of a communication configuration parameter verification process provided by the present application is shown. The process is applicable to the communication middleware and parameter server in the operation device 200 and mainly includes the following steps:

[0228] Step 1301: The communication middleware runs the first application in the second development information.

[0229] Step 1302: The communication middleware establishes a communication channel for the first application based on the third communication configuration parameter in the second development information.

[0230] Here, when the communication middleware obtains the static third communication configuration parameters, it can directly establish a communication channel corresponding to the first application based on the third communication configuration parameters and execute subsequent communication logic to improve the initialization speed of the first application.

[0231] Step 1303: The communication middleware sends a parameter verification request to the parameter server. The parameter verification request carries the third communication configuration parameter corresponding to the first application.

[0232] Optionally, the parameter verification request may include some or all parameter information in the third communication configuration parameter. For example, it may include at least parameter value information of a resource parameter, which can be used to determine conflicts with occupied resource parameters managed by the parameter server.

[0233] Further, optionally, the parameter verification request may be initiated in the service provision process of the server application, or the service discovery process of the client application, or the communication instance creation process of the client application. If it is initiated in the service provision process, the parameter verification request may include parameter value information of resource class parameters in the two types of parameters, namely service parameters and channel parameters. If it is initiated in the service discovery process, the parameter verification request may include parameter value information of resource class parameters in the service parameters, but not include relevant information of channel parameters. If it is initiated in the communication instance creation process, the parameter verification request may include parameter value information of resource class parameters in the channel parameters, but not include relevant information of service parameters.

[0234] In step 1304 , the parameter server determines whether the parameter allocation information contains the fifth communication configuration parameter corresponding to the first application. If so, step 1305 is executed; otherwise, step 1308 is executed.

[0235] Here, the parameter server may query the parameter allocation information according to the service name, service instance ID, and process information of the third communication configuration parameter to determine whether there is a fifth communication configuration parameter corresponding to the first application.

[0236] In step 1305 , the parameter server determines whether the fifth communication configuration parameter is the same as the third communication configuration parameter. If not, step 1306 is executed. If so, step 1307 is executed.

[0237] Step 1306: The parameter server sends a parameter verification inconsistent response message to the communication middleware.

[0238] Here, if the parameter allocation information already stores the fifth communication configuration parameters corresponding to the first application, but the fifth communication configuration parameters differ from the third communication configuration parameters carried in the second development information, this indicates that the static third communication configuration parameters stored in the development device 100 and the fifth communication configuration parameters managed by the execution device 200 are inconsistent, and the first application has a communication configuration parameter inconsistency error. In this case, the parameter server can return a parameter verification inconsistency response message to the communication middleware, so that the communication middleware can notify the developer of this response message and prompt the developer to correct the error.

[0239] Step 1307: The parameter server returns a response message indicating successful parameter verification to the communication middleware.

[0240] Here, if the parameter allocation information already stores the fifth communication configuration parameters corresponding to the first application, and the fifth communication configuration parameters are identical to the third communication configuration parameters carried in the second development information, then this indicates that the static third communication configuration parameters stored in development device 100 are consistent with the fifth communication configuration parameters managed in runtime device 200, and the third communication configuration parameters carried in the second development information are correct. In this case, the parameter server may not perform any operation, or may return a response message indicating successful parameter verification to the communication middleware, so that the communication middleware can notify the developer of the parameter verification result.

[0241] In step 1308 , the parameter server determines whether there are other applications corresponding to the third communication configuration parameters in the parameter allocation information. If so, step 1309 is executed; if not, step 1310 is executed.

[0242] Step 1309: The parameter server returns a parameter verification conflict response message to the communication middleware.

[0243] Here, if the parameter allocation information does not store the communication configuration parameters corresponding to the first application, but does store the third communication configuration parameters corresponding to another application, especially if the other application has already occupied the parameter value of a resource parameter in the third communication configuration parameters, then it indicates that there is a resource conflict between the third communication configuration parameters corresponding to the first application and the communication configuration parameters of the other application. In this case, the parameter server can return a parameter verification conflict response message to the communication middleware, so that the communication middleware can prompt the developer with this response message, reminding the developer to resolve the resource conflict between the first application and the other application.

[0244] Step 1310: The parameter server stores the third communication configuration parameter corresponding to the first application in the parameter allocation information.

[0245] Here, if the parameter allocation information does not store the third communication configuration parameters corresponding to an application, and in particular, if no other application occupies the parameter value of the resource-related parameters in the third communication configuration parameters, then the resource-related parameters in the third communication configuration parameters have not been occupied and can be allocated to the first application. In this case, the parameter server can add the third communication configuration parameters corresponding to the first application to the parameter allocation information. This allows the parameter server to directly return the third communication configuration parameters in the parameter allocation information to the communication middleware the next time it requests the communication configuration parameters corresponding to the first application, thereby speeding up the allocation of communication configuration parameters.

[0246] By using the above method, in a scenario where the development information includes static communication configuration parameters, by performing parameter verification on the static communication configuration parameters, incorrect communication configuration parameters can be located, thereby promptly locating communication problems and ensuring that the application is run using the correct communication configuration parameters to improve the accuracy of operation.

[0247] It should be noted that the parameter verification operation can be performed before or after the channel establishment operation, or both can be performed in parallel. For example, in one example, step 1302 can be performed before step 1303. This means that the communication middleware first executes the application's communication functions based on the static communication configuration parameters, and then performs parameter verification on the static communication configuration parameters, prioritizing the initialization speed of the application. In another example, step 1302 can be performed after step 1307 or step 1310. This means that the static communication configuration parameters are first verified to be correct, and then the application's communication functions are executed using the static communication configuration parameters, prioritizing the accuracy of the application's operation. In another example, two processes can be used to respectively execute step 1302 and steps 1303 to 1310. If an error in the static communication configuration parameters is detected, the application's operation is immediately stopped, thereby ensuring the initialization speed of the application while minimizing the accuracy of the application's operation.

[0248] Based on the various implementation solutions described above, the complete development process is further explained below using the first development information as an example.

[0249] Please refer to FIG14 , which shows a complete flow chart of a development method provided by this application, which includes:

[0250] Step 1401: A development device sends first development information to a running device, where the first development information includes a first application.

[0251] Here, the first application may be generated by a developer configuring a service interface configuration item in a development tool of the development device 100 and then compiling the configuration item. For details, see the above content.

[0252] In step 1402 , the operating device determines whether the first development information includes the fourth communication configuration parameter corresponding to the first application. If so, step 1403 is executed; if not, step 1407 is executed.

[0253] Here, the fourth communication configuration parameter can be a static communication configuration parameter stored in the development device 100. The static communication configuration parameter can be assigned to the first application before the running device 200, or it can be modified by the developer after being assigned to the first application before the running device 200. Of course, it can also be generated by the developer configuring the running parameter configuration item in the development tool of the development device 100, and there is no specific limitation.

[0254] Step 1403: The operating device establishes a communication channel for the first application based on the fourth communication configuration parameters.

[0255] Here, the operating device 200 may directly establish a communication channel based on the static fourth communication configuration parameter to increase the initialization speed of the application program, thereby improving the efficiency of the communication test.

[0256] Step 1404 : The operating device verifies the fourth communication configuration parameter using the parameter allocation information. If the verification fails, step 1405 is executed. If the verification succeeds, step 1406 is executed.

[0257] Here, when it is necessary to verify the fourth communication configuration parameter in the first development information, the operating device 200 can obtain parameter allocation information, which includes communication configuration parameters corresponding to one or more applications. Afterwards, the operating device 200 can search for the second communication configuration parameter corresponding to the first application from the parameter allocation information. If the second communication configuration parameter corresponding to the first application does not exist in the parameter allocation information, and there is no fourth communication configuration parameter corresponding to other applications, or if the second communication configuration parameter corresponding to the first application exists in the parameter allocation information, and the second communication configuration parameter is consistent with the fourth communication configuration parameter, then the operating device 200 determines that the fourth communication parameter verification is successful. Otherwise, it determines that the fourth communication parameter verification has failed. For the specific implementation of the verification process, please refer to Figure 13 and the related text description above, which will not be repeated here.

[0258] Step 1405: The operating device sends a first prompt message to the developer, where the first prompt message is used to prompt that an error occurs in the fourth communication configuration parameter.

[0259] Here, if the cause of the verification error is that the parameter allocation information contains a fourth communication configuration parameter corresponding to another application, the first prompt information may prompt the first application that a resource conflict error has occurred. If the cause of the verification error is that the second communication configuration parameter corresponding to the first application in the parameter allocation information is inconsistent with the fourth communication configuration parameter in the first development information, the first prompt information may prompt the first application that a parameter inconsistency error has occurred.

[0260] Step 1406: Run the device to complete verification.

[0261] Here, the operating device 200 may further send a second prompt message to the developer, where the second prompt message is used to prompt that the fourth communication configuration parameter is correct, so that the developer can promptly understand the execution progress of the verification process.

[0262] Step 1407 , the operating device determines whether the parameter allocation information contains the second communication configuration parameter corresponding to the first application. If so, execute step 1408 ; if not, execute step 1409 .

[0263] Step 1408: The operating device establishes a communication channel for the first application based on the second communication configuration parameters.

[0264] Here, the operating device 200 manages parameter allocation information. If the parameter allocation information already stores the second communication configuration parameters corresponding to the first application, the operating device 200 can directly obtain the second communication configuration parameters to operate the first application, thereby improving the operating efficiency of the first application.

[0265] Step 1409: The running device allocates first communication configuration parameters to the first application and adds the parameters to the parameter allocation information.

[0266] Here, the operating device 200 can obtain preset parameter configuration information, and allocate parameter values ​​of unoccupied resource class parameters to the first application according to the allocation range of resource class parameters and the default parameter values ​​of non-resource class parameters in the preset parameter configuration information, as well as allocate specified parameter values ​​of non-resource class parameters indicated by the first development information or default parameter values ​​of non-resource class parameters.

[0267] Here, after the operating device 200 assigns the first communication configuration parameters to the first application, it can also add the first communication configuration parameters corresponding to the first application in the parameter allocation information, so that when the first application is developed next time, the first communication configuration parameters in the parameter allocation information can be directly obtained to run the first application, thereby improving the operating efficiency of the first application.

[0268] Furthermore, the operating device 200 may also mark the parameter value of the resource class parameter in the first communication configuration parameter as occupied in the parameter allocation information, so that it can more conveniently refer to the occupied mark to allocate an unoccupied parameter value of the resource class parameter to the next application.

[0269] Step 1410: If the operating device does not receive the first instruction, a communication channel for the first application is established based on the first communication configuration parameters.

[0270] Step 1411: When the operating device receives the first instruction, the operating device sends the first communication configuration parameter to the development device based on the first instruction.

[0271] Here, after allocating the first communication configuration parameters, if a first instruction from a developer is received, it indicates that the first communication configuration parameters may not be suitable for the current scenario and need to be modified or optimized. In this case, the operating device 200 may export the first communication configuration parameters to the development device 100, for example, according to the first instruction from the developer. Conversely, if the first instruction from the developer is not received, it indicates that the first communication configuration parameters are relatively suitable for the current scenario and do not need to be modified. In this case, the operating device 200 may directly establish the communication channel for the first application based on the first communication configuration parameters.

[0272] Step 1412: The development device obtains the third communication configuration parameter obtained by the developer modifying the first communication configuration parameter, and uses the third communication configuration parameter as a local static configuration file.

[0273] Here, the development device 100 can display various configuration items of the first communication configuration parameter to the developer in an interactive interface based on the development tool, so that the developer can specifically adjust one or more configuration items to obtain the third communication configuration parameter.

[0274] Here, the development device 100 can store the modified or optimized third communication configuration parameters locally, so that when developing the first application next time, the local third communication configuration parameters can be directly obtained and sent to the running device, thereby avoiding the process of reallocating the communication configuration parameters and improving the initialization running speed of the application.

[0275] Step 1413: The development device sends the third communication configuration parameter to the operation device.

[0276] Step 1414: The operating device establishes a communication channel for the first application based on the third communication configuration parameters.

[0277] Here, after receiving the third communication configuration parameters, the operating device can also update the second communication configuration parameters corresponding to the first application in the parameter allocation information based on the third communication configuration parameters to maintain the accuracy of the parameter allocation information. This allows the operating device to directly retrieve the user-modified or optimized third communication configuration parameters from the parameter allocation information when developing the first application the next time, meeting the needs of specific scenarios.

[0278] Based on the above development process, the following is another specific example to illustrate the details of this development process in an actual application scenario.

[0279] Assume that you want to assign communication configuration parameters based on AP CM communication to an application, optimize the assigned communication configuration parameters, and then convert them into a static running configuration file on the development device. The entire application development and commissioning process includes the following five steps:

[0280] In step 1, developers simply configure the service interface information shown in Table 4 below in the communication configuration tool on the development device, including the service name, communication entity type, communication entity name, communication data type, field attributes, and whether the method is FireAndForget. The code generation tool then generates the service interface files required for AP-CM communication, such as xxx_skeleton.h and xxx_proxy.h, where xxx represents the service name. Users can then add the corresponding business logic to these service interface files to compile and generate the corresponding application. This application can then be exported to the running device for development and testing.

[0281] Table 4

[0282] Step 2: After receiving the application, the running device must first start the process where the parameter server is located before running the application. After the process where the parameter server is located is started, it will first read the preset parameter configuration file (i.e., the preset parameter configuration information mentioned above). The preset parameter configuration file contains the default parameter information of non-resource parameters and the allocation range information of resource parameters, such as the default protocol is SOME / IP, the allocation range of the service port of SOME / IP, the allocation range of the service ID of SOME / IP, etc. Then, the parameter server will also read the service parameter list (i.e., the parameter allocation information mentioned above), which contains the communication configuration parameters corresponding to each application that has been assigned parameters. The parameter server marks the parameter value information of the resource parameters of the assigned communication configuration parameters in the service parameter list as occupied.

[0283] After the parameter server process is started on the device, you can run the application. If the application is a server application, proceed to step 3 (A). If the application is a client application, proceed to step 3 (B).

[0284] In step three (A), after the server application is started, it will call the OfferService interface in the AP CM through the business layer to provide services. Taking the Radar service and service instance 2 as an example, during the process of providing services through the OfferService interface, the AP CM will first detect whether a static parameter configuration file already exists for the Radar service and service instance 2 (that is, whether there are communication configuration parameters sent from the development device side along with the service interface file). If a static parameter configuration file exists, the AP CM can directly add the static parameter configuration file to the protocol layer, call the relevant interface in the protocol layer to establish a communication channel, and create a service instance to increase the speed of service instance creation. The AP CM can also perform parameter verification as described in step four below. Afterwards, if the parameter verification is successful, the verification can be terminated. If the parameter verification is unsuccessful, the developer can wait for the incorrect parameters to be corrected before restarting the development process. On the contrary, if there is no static parameter configuration file, the AP CM may send a parameter query request (i.e., the aforementioned parameter request message) to the parameter server. The parameter query request includes request information for service discovery parameters (i.e., the aforementioned service parameters), such as service name, service instance ID, and process name, etc., and also includes request information for communication entity parameters (i.e., the aforementioned channel parameters), such as Event name, Method name, Field name, and Field type (Notifier, Getter, Setter), etc.

[0285] After receiving the parameter query request, the parameter server checks whether all configuration parameters for the Radar service and service instance 2, including the requested service discovery parameters and communication entity parameters, already exist in the service parameter list. If so, the parameter server has previously allocated configuration parameters for the Radar service and service instance 2. Therefore, the parameter server can directly return information about the allocated configuration parameters to the AP CM. If only some configuration parameters exist—for example, the Radar service's service ID has been allocated, but the communication entity's EventID and MethodID have not been allocated—this indicates that the parameter server has previously allocated only some of the configuration parameters for the Radar service and service instance 2, resulting in an incomplete configuration. In this case, the parameter server needs to allocate the unallocated configuration parameters and, after completing the allocation, return information about the existing configuration parameters and the newly allocated configuration parameters to the AP CM. Alternatively, if no configuration parameters exist, the parameter server has not yet allocated configuration parameters for the Radar service and service instance 2. In this case, the parameter server can allocate all the requested configuration parameters and, after completing the allocation, return information about all the allocated configuration parameters to the AP CM.

[0286] Taking the configuration parameters for a non-existent Radar service and service instance 2 as an example, Table 5 shows a schematic diagram of service ID allocation based on the service interface information shown in Table 4. Since the application in Table 4 is for the Radar service, as shown in Table 5, the Radar service uses the SOME / IP protocol by default. The SOME / IP protocol has already assigned service ID 1 to the Camera service. Therefore, the parameter server can assign the Radar service to the unused service ID 2 within the SOME / IP protocol. Of course, other unused service IDs can also be assigned, such as service ID 3, service ID 4, and so on. There is no specific order in which these IDs are assigned, and there is no specific limitation.

[0287] Table 5

[0288] Table 6 shows a schematic diagram of service port allocation based on the service interface information shown in Table 4. Service ports can be allocated based on process name information. For example, as shown in Table 6, assuming that a Radar service instance ID 1 already exists and that service instance ID 1 uses service port 33641, the Radar service requested in Table 4 can be allocated service instance ID 2, and service instance ID 2 can be allocated service port 33642.

[0289] Table 6

[0290] Based on the service interface information shown in Table 4, Table 7 shows a schematic table for allocating communication entity parameters. Assuming that the allocation range of EventID is 0 to 32767 and the allocation range of MethodID is 32768 to 65535, then, as shown in Table 7, the parameter server can allocate EventID, MethodID, Field Notifier ID, Field SetterID, and Field Getter ID in the order of the number of Events, Methods, and Fields in the Radar service. In addition, Field Notifier can be allocated together with Event, and Field Setter and Field Getter can be allocated together with Method. For example, as shown in Table 4, this Radar service requests two communication entities, Event1 and Event2. Therefore, as shown in Table 7, EventID=0 can be assigned to the RadarEvent1 communication entity, EventID=1 can be assigned to the Radar Event2 communication entity, EventID=2 can be assigned to the Radar Field1 Notifier communication entity, MethodID=32768 can be assigned to the Radar Method1 communication entity, MethodID=32769 can be assigned to the RadarField1 Setter communication entity, and MethodID=32770 can be assigned to the RadarField1 Getter communication entity.

[0291] Table 7

[0292] Based on the communication entity parameters assigned in Table 7, Table 8 shows a schematic diagram of the allocation of E2E DataID. The E2EDataID of each communication entity is unique within the scope of the protocol. In other words, a unique E2E DataID can be assigned to each communication instance within the scope of the protocol. For example, taking sequential allocation as an example, as shown in Table 8, assuming that the most recent Camera Event1 communication entity is assigned E2E DataID 90, then for each communication entity of the Radar service in Table 7, E2E DataID = 91 can be assigned to the Radar Event1 communication entity, E2E DataID = 92 can be assigned to the Radar Event2 communication entity, E2E DataID = 93 can be assigned to the Radar Field1 Notifier communication entity, E2E DataID = 94 can be assigned to the Radar Method1 communication entity, E2E DataID = 95 can be assigned to the Radar Field1 Setter communication entity, and E2E DataID = 96 can be assigned to the Radar Field1 Getter communication entity.

[0293] Table 8

[0294] After the parameter server has assigned the configuration parameters of the Radar service and service instance 2 in the above manner, it can store the correspondence between the Radar service, service instance 2, and the configuration parameters in the service parameter list and return it to the AP CM. The AP CM then starts the service discovery and communication entity creation process on the server side based on the obtained configuration parameters and establishes the communication channel corresponding to the server-side application.

[0295] In step 3 (B), after the client application starts, it discovers services by calling the StartFindService / FindService interface in the AP CM through the business layer. For example, using the Radar service and service instance 2 as an example, the AP CM first checks whether a static parameter configuration file already exists for the Radar service and service instance 2. If so, it directly adds the static parameter configuration file to the protocol layer, calling the relevant protocol layer interface to create the service instance. The AP CM also performs parameter verification as described in step 4 below. If the parameter verification succeeds, verification ends. If the parameter verification fails, the developer can wait for the incorrect parameters to be corrected before restarting the development process. Conversely, if the static parameter configuration file does not exist, the AP CM sends a service parameter query request (the aforementioned service parameter request message) to the parameter server. This service parameter query request contains request information for service discovery parameters, such as the service name, service instance ID, and process name. After receiving the service parameter query request, the parameter server performs the service discovery parameter query and allocation process and returns the queried or allocated service discovery parameters to the AP CM. This process is the same as the service discovery parameter query process in step 3 (A) above after the parameter server receives the parameter query request from the server OfferService.

[0296] After receiving the service parameters returned by the parameter server, the AP CM can use them to initiate service discovery. After discovering the service, the client application's communication entity must be created. At this point, a communication entity parameter query request (i.e., the aforementioned channel parameter request message) must be sent to the parameter server. This communication entity parameter query request contains request information for communication entity parameters, such as the event name, method name, field name, and field type (e.g., Notifier, Getter, Setter, etc.). After receiving the communication entity parameter query request, the parameter server performs the communication entity parameter query and allocation process, and returns the queried or allocated communication entity parameters to the AP CM. This process is similar to the communication entity parameter query process after the parameter server receives the parameter query request from the server's OfferService in step 3 (A). After receiving the communication entity parameters returned by the parameter server, the AP CM adds them to the protocol layer, calls the relevant interfaces in the protocol layer, creates the client application's communication entity, establishes the corresponding communication channel for the client application, and then communicates with the server application's corresponding communication channel through this communication channel.

[0297] Step 4. In step 3 (A) or step 3 (B) above, after the server application or the client application is started, if a static parameter configuration file already exists, the server can send the static parameter configuration file to the parameter server through a parameter verification request during the OfferService, or the client can send the static parameter configuration file to the parameter server through a parameter verification request during the StartFindService / FindService process to start parameter verification.

[0298] The parameter server checks whether the static parameter configuration file is consistent with the configuration parameters of the same server or client in the service parameter list, and checks whether the static parameter configuration file conflicts with resource information in the configuration parameters of other servers or clients in the service parameter list. For example, taking the Radar service and service instance 2 as an example, if the Radar service and service instance 2 already exist in the service parameter list, the server checks whether the service ID assigned to the Radar service and service instance 2, as well as the EventID and MethodID of the event and method, in the service parameter list are consistent with the static parameter configuration file. It also checks whether the ports of each service instance of the Radar service and service instance 2 in the static parameter configuration file are the same as those used by other processes in the service parameter list, thereby causing port conflicts. If the check finds that the parameters are consistent or there are no resource conflicts, the parameter server can terminate the verification or return a response message indicating that the parameter verification is successful to the server or client. If the check finds that the parameters are inconsistent or there is a resource conflict, the parameter server can return a response message indicating that the parameter verification is unsuccessful to the server or client. Based on this response message, the server or client can notify the developer of the error message and instruct the developer to manually correct the parameter error.

[0299] Step 5: To optimize one or more configuration parameters, the configuration parameters dynamically assigned by the parameter server can also be exported. For example, still using the Radar service and service instance 2 as an example, the following content shows the contents of a configuration parameter file exported by the parameter server. This content includes parameter value information for automatically assigned resource parameters and parameter value information for non-resource parameters, such as process information and operating environment information for the server or client of the Radar service and service instance 2:

[0300] Furthermore, the configuration parameter file can be exported to the AP CM configuration tool. The AP CM configuration tool is pre-installed on the development device and includes the communication configuration tool and configuration generation tool mentioned above. The configuration parameter file can be a file in Manifest format. After the communication configuration tool reads the content of the imported configuration parameter file, it can convert it into a standardized configuration file in ARXML format, such as converting the process name information into Process / ProcessDesign configuration, converting the service ID, instance ID, EventID, MethodID and other information into SomeipServiceInterface-Deployment and ProvidedSomeipServiceInstance / RequiredSomeipServiceInstance configuration, converting IP and other network information into EthernetCommunicationConnector configuration, and converting the association information between the service and the process and network into SomeipServiceInstanceTo-MachineMapping and ServiceInstanceToPortPrototypeMapping configuration. The standardized configuration file in ARXML format can be displayed to the developer with the help of the interface configuration tool so that the developer can optimize the configuration of one or more communication parameters. For example, please refer to Figure 15, which shows a schematic diagram of a parameter optimization interface provided by the present application. Developers can modify some configuration items on this parameter optimization interface, such as modifying the packet aggregation configuration, multicast configuration, etc., so that the modified configuration parameters can meet the needs of special scenarios.

[0301] In addition, the optimized standardized configuration file is still in ARXML format, and the standardized configuration file can also be converted into a static parameter configuration file through the configuration generation tool. Among them, the static parameter configuration file and the dynamically allocated parameter configuration file in the parameter allocation information can be files of the same type or different types. For example, it can be converted into a parameter configuration file with the same format as the parameter configuration file exported by the parameter server, such as a file in Manifest format, and then stored locally on the development device. In this way, the next time the application is started, the local static parameter configuration file can be directly obtained for running tests, without the need to reallocate parameters or convert formats, thereby improving the initialization speed of application startup.

[0302] Based on the above development method, by providing a parameter server process and using the parameter server process to implement the dynamic allocation function of configuration parameters, the import function of static parameter configuration files, and the parameter verification function of static parameter configuration files and dynamically allocated configuration parameters, it is possible to optimize the complex communication configuration process while ensuring the reliability of resource allocation, improve the efficiency of application development and debugging, and solve the problems of complex configuration, poor usability and low development efficiency in the development and debugging of applications based on communication middleware such as AP CM or SOME / IP in the existing technology.

[0303] It should be noted that the above development method involves not only improvements to the newly added parameter server process, but also improvements to the communication middleware, such as improvements to the communication middleware's interaction process. Specifically, existing communication middleware only obtains static parameter configuration files and directly returns an error message if it cannot obtain them. However, when the improved communication middleware in this application cannot obtain a static parameter configuration file, it will also interact with the parameter server process to obtain configuration parameters dynamically allocated by the parameter server. Furthermore, when the improved communication middleware in this application obtains a static parameter configuration file, it will also interact with the parameter server process to perform parameter verification on the static parameter configuration file through the parameter server. In other words, regardless of whether a static parameter configuration file exists or not, the subsequent execution process of the communication middleware in this application is different from that of existing communication middleware.

[0304] In addition, the above development method can be applied in the field of smart cars. For example, it can be integrated into hardware for implementation, or it can exist in the form of a software product, which can then be loaded into the hardware for direct application. The hardware can be, for example, a vehicle, an on-board device, or an on-board component, or it can be a device or component outside the vehicle, such as an electronic device, a development device, or its component. The device or component outside the vehicle also needs to be configured with the same operating environment as the vehicle so that the development and testing of the application can be achieved using the operating environment. Alternatively, it can be an embedded device that can be embedded in the vehicle as an external controller to control the components inside the vehicle to develop and test the application in the vehicle's operating environment.

[0305] Of course, the above development method can be extended to any device or system that requires development efficiency. For example, it can be applied to any mobile device, including but not limited to ships, airplanes, high-speed trains, trains, helicopters, lawn mowers, mobile robots, etc. Alternatively, it can be applied to any communication device with communication capabilities, such as base stations, access network equipment, terminal equipment, printers, smart home devices, smart industrial equipment, and so on.

[0306] Furthermore, with the evolution of system architecture and the emergence of new scenarios, the development solution provided in this application is also applicable to similar technical problems, and this application does not make specific limitations on this.

[0307] Based on the development method described above, the present application may also provide a development device, which may be used to execute the above development method. For related features, please refer to the above method embodiment and will not be described in detail here.

[0308] In one possible implementation, please refer to FIG16 , which shows a possible structural diagram of a development device. The development device 1600 can be a chip or circuit, such as a chip or circuit that can be set in a vehicle or an on-board device, or a chip or circuit set in an electronic device outside the vehicle. The development device 1600 can correspond to the operating device in the above method, such as the operating device 200. The development device 1600 can implement the steps performed by the operating device, or the communication middleware and parameter server in the operating device, in any of the methods shown in FIG4 , 7-10 , 13 , and 14 above.

[0309] As shown in Figure 16, the development device 1600 may include an acquisition unit 1610 and an allocation unit 1620. When the development device 1600 executes the development method shown in Figure 4 above, the acquisition unit 1610 is used to acquire first development information, where the first development information includes a first application, which is an application generated by a user on a development device; and the allocation unit 1620 is used to run the first application and allocate first communication configuration parameters to the first application.

[0310] For the concepts, explanations, detailed descriptions and other steps involved in the development device 1600 and related to the technical solutions provided in the embodiments of the present application, please refer to the descriptions of these contents in the aforementioned methods or other embodiments, which will not be repeated here.

[0311] It should be understood that the above division of the units of development device 1600 is merely a division of logical functions. In actual implementation, all or part of the units may be integrated into a single physical entity, or they may be physically separated. This application does not impose any specific limitations on this. The functions of the various units in the above development device 1600 can be referred to the implementation of the corresponding method embodiment and will not be further described here.

[0312] In another possible implementation, please refer to Figure 17, which shows another possible structural diagram of a development device. The development device 1700 can be a chip or a chip system. Optionally, the chip system can be composed of chips, or can include chips and other discrete devices. As shown in Figure 17, the development device 1700 can include at least one processor 1710 and a memory 1720. At least one processor 1710 is coupled to the memory 1720, and the memory 1720 can be located within the development device 1700 or outside the development device 1700. The memory 1720 stores the computer program or instructions necessary to implement any of the above method embodiments. At least one processor 1710 completes the development method in any of the above method embodiments by executing the computer program or instructions stored in the memory 1720.

[0313] The development device 1700 may also include a communication interface 1730, through which the development device 1700 can exchange information with other devices. The communication interface 1730 can be a circuit, a bus, a transceiver, or any other device that can be used for information exchange, or can be called a signal transceiver unit. When the development device 1700 is a chip-type device or circuit, the communication interface 1730 in the development device 1700 can also be an input-output circuit that can input data (or receive data) and output data (or send data). The at least one processor 1710 is an integrated processor, a microprocessor, or an integrated circuit, and the at least one processor 1710 can determine output data based on the input data.

[0314] In the development device 1700, at least one processor 1710 can obtain a computer program or instruction stored in the memory 1720 to execute the steps in any of the above method embodiments, or to implement the steps performed by the operating device, or the communication middleware and parameter server in the operating device, in any of the methods shown in Figures 4, 7-10, 13, and 14. For example, when implementing the steps shown in Figure 4 above, the at least one processor 1710 can obtain first development information through the communication interface 1730, where the first development information includes a first application, which is an application generated by a user on the development device; the at least one processor 1710 can run the first application and assign first communication configuration parameters to the first application.

[0315] The processor 1710 can be a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, and can implement or execute the methods, steps, and logic block diagrams disclosed herein. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed herein can be directly implemented and executed by a hardware processor, or by a combination of hardware and software modules within the processor.

[0316] The above-mentioned memory 1720 can be a non-volatile memory, such as a hard disk drive (HDD) or a solid-state drive (SSD), or a volatile memory (volatile memory), such as a random-access memory (RAM). The memory can also be any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited to this. The memory 1720 in this application can also be a circuit or any other device that can implement a storage function, for storing computer programs, computer programs or instructions and / or data.

[0317] For the concepts, explanations, detailed descriptions and other steps involved in the development device 1700 and related to the technical solutions provided in the embodiments of this application, please refer to the descriptions of these contents in the aforementioned methods or other embodiments, which will not be repeated here.

[0318] Based on the development method described above, the present application may also provide a software product that may include the communication middleware and parameter server described above. The communication middleware and parameter server may belong to different software processes or may belong to the same software process, without limitation.

[0319] Based on the development method described above, the present application can also provide a vehicle, which may include units or modules for implementing the above development method, such as a development device as shown in Figure 16 or Figure 17 above, which will not be repeated here.

[0320] For example, the vehicle may be a car, truck, motorcycle, bus, recreational vehicle, amusement park vehicle, construction equipment, tram, toy car, golf cart, train, etc., and this application does not impose any particular limitation. In addition, the vehicle may be a new energy vehicle, including an electric vehicle, such as a two-wheel drive electric vehicle or a four-wheel drive electric vehicle, or a fuel vehicle, and this application does not impose any particular limitation.

[0321] Based on the development method described above, the present application may also provide an electronic device that may store an operating environment related to the application to be tested, such as various underlying protocols, operating systems, and hardware in a vehicle. The electronic device may include units or modules for implementing the above development method, such as the development device shown in Figures 16 or 17 above.

[0322] Based on the development method described above, the present application also provides a computer-readable storage medium, which stores a program or instruction. When the program or instruction is run on a development device, the development device executes the method shown in any of the embodiments in Figures 4, 7-10, 13, and 14 above.

[0323] Based on the development method described above, the present application can also provide a computer program product, which includes: computer program code, which, when running on a computer, enables the computer to execute the method shown in any of the embodiments in Figures 4, 7-10, 13, and 14 above.

[0324] In this application, "multiple" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. "At least one item" or similar expressions refer to any combination of these, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple. In addition, in this application, the word "optionally" or "exemplarily" is used to indicate an example, illustration or description. Any embodiment or design scheme described as "example" or "optional" in this application should not be interpreted as being more preferred or more advantageous than other embodiments or design schemes. Alternatively, it can be understood that the use of an example or optional word is intended to present concepts in a specific way and does not constitute a limitation on this application.

[0325] It will be appreciated that the various numerical numbers involved in this application are merely for the purpose of describing the distinctions made, and are not intended to limit the scope of the embodiments of the present application. The size of the sequence numbers of the above-mentioned processes does not imply the order of execution, and the order of execution of each process should be determined by its function and inherent logic. Terms such as "first", "second", "third", "fourth" and similar expressions are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. In addition, the terms "comprise" and "have" and any of their variations are intended to cover non-exclusive inclusions, for example, comprising a series of steps or units. Methods, systems, products or devices are not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

Claims

1. A development method, characterized in that: The method comprises: Acquire first development information, where the first development information includes a first application, where the first application is an application generated by a user on a development device; The first application is run, and first communication configuration parameters are allocated to the first application.

2. The method according to claim 1, wherein The allocating the first communication configuration parameter to the first application comprises: Obtaining preset parameter configuration information, wherein the preset parameter configuration information includes an allocation range of resource class parameters; Determining an unoccupied parameter value of the resource class parameter in an allocation range of the resource class parameter; Allocate the unoccupied parameter value of the resource class parameter to the first application.

3. The method according to claim 1 or 2, wherein: The allocating the first communication configuration parameter to the first application comprises: Obtaining preset parameter configuration information, wherein the preset parameter configuration information includes default parameter values ​​of non-resource parameters; If the first development information also indicates a specified parameter value for a non-resource parameter, the specified parameter value for the non-resource parameter is assigned to the first application; if the first development information does not indicate a specified parameter value for a non-resource parameter, the default parameter value for the non-resource parameter is assigned to the first application.

4. The method according to any one of claims 1 to 3, characterized in that After allocating the first communication configuration parameter to the first application, the method further includes: Storing the first communication configuration parameter corresponding to the first application in parameter allocation information; The parameter allocation information includes communication configuration parameters corresponding to one or more applications, and the communication configuration parameters corresponding to the one or more applications are allocated to the one or more applications by the running device, or are modified by the user, or are carried in the development information.

5. The method according to any one of claims 1 to 4, characterized in that Before allocating the first communication configuration parameter to the first application, the method further includes: It is determined that the second communication configuration parameter corresponding to the first application does not exist in the parameter allocation information.

6. The method according to claim 5, wherein The method further comprises: If the parameter allocation information contains second communication configuration parameters corresponding to the first application, a communication channel for the first application is established based on the second communication configuration parameters.

7. The method according to any one of claims 1 to 6, characterized in that The method further comprises: exporting the first communication configuration parameter to the development device based on a first instruction; Acquire a third communication configuration parameter, where the third communication configuration parameter is obtained after the user modifies the first communication configuration parameter on the development device.

8. The method according to claim 7, wherein After obtaining the third communication configuration parameter, the method further includes: The first communication configuration parameter corresponding to the first application in the parameter allocation information is updated according to the third communication configuration parameter.

9. The method according to claim 7 or 8, wherein The third communication configuration parameter is also stored in the development device; the method further includes: Acquire second development information, where the second development information includes the first application and the third communication configuration parameter; Run the first application and establish a communication channel for the first application based on the third communication configuration parameters.

10. The method according to any one of claims 1 to 9, characterized in that Before allocating the first communication configuration parameter to the first application, the method further includes: It is determined that the first development information does not include a fourth communication configuration parameter of the first application.

11. The method according to claim 10, wherein The method further comprises: If the first development information includes the fourth communication configuration parameter of the first application, a communication channel of the first application is established based on the fourth communication configuration parameter.

12. The method according to claim 11, wherein The method further comprises: If the parameter allocation information contains a second communication configuration parameter corresponding to the first application, but the second communication configuration parameter is different from the fourth communication configuration parameter, or if the parameter allocation information contains other applications corresponding to the fourth communication configuration parameter, a first prompt message is generated, and the first prompt message is used to prompt that an error has occurred in the fourth communication configuration parameter.

13. The method according to claim 11 or 12, wherein: The method further comprises: When the fourth communication configuration parameter corresponding to the application does not exist in the parameter allocation information, the fourth communication configuration parameter corresponding to the first application is stored in the parameter allocation information.

14. The method according to any one of claims 1 to 13, characterized in that The first application is a server application or a client application of the vehicle-mounted business type.

15. A software product, characterized in that include: Communication middleware and parameter server; The communication middleware is configured to send a parameter request message to the parameter server when running the first application, where the first application is included in the first development information and is an application generated by a user on a development device; The parameter server is configured to allocate a first communication configuration parameter to the first application according to the parameter request message, and send the first communication configuration parameter to the communication middleware.

16. The software product according to claim 15, wherein: The parameter server is specifically used for: Obtaining preset parameter configuration information, wherein the preset parameter configuration information includes an allocation range of resource class parameters; Determining an unoccupied parameter value of the resource class parameter in an allocation range of the resource class parameter; Allocate the unoccupied parameter value of the resource class parameter to the first application.

17. The software product according to claim 15 or 16, wherein: The parameter server is specifically used for: Obtaining preset parameter configuration information, wherein the preset parameter configuration information includes default parameter values ​​of non-resource parameters; If the first development information also indicates a specified parameter value for a non-resource parameter, the specified parameter value for the non-resource parameter is assigned to the first application; if the first development information does not indicate a specified parameter value for a non-resource parameter, the default parameter value for the non-resource parameter is assigned to the first application.

18. The software product according to any one of claims 15 to 17, characterized in that After allocating the first communication configuration parameter to the first application, the parameter server is further configured to: Storing the first communication configuration parameter corresponding to the first application in parameter allocation information; Among them, the parameter allocation information includes communication configuration parameters corresponding to one or more applications, and the communication configuration parameters corresponding to the one or more applications are allocated to the one or more applications by the parameter server, or are modified by the user, or are carried in the development information.

19. The software product according to any one of claims 15 to 18, characterized in that Before allocating the first communication configuration parameter to the first application, the parameter server is further configured to: querying parameter allocation information according to the parameter request message; Determine that a second communication configuration parameter corresponding to the first application does not exist in the parameter allocation information.

20. The software product of claim 19, wherein: The parameter server is also used to: If the parameter allocation information contains the second communication configuration parameter corresponding to the first application, the second communication configuration parameter is sent to the communication middleware.

21. The software product according to any one of claims 15 to 20, characterized in that The parameter server is further used to: export the first communication configuration parameter to the development device based on the first instruction, obtain the third communication configuration parameter imported by the development device, and send the third communication parameter to the communication middleware; the third communication configuration parameter is obtained after the user modifies the first communication configuration parameter on the development device.

22. The software product of claim 21, wherein: After acquiring the third communication configuration parameter imported by the development device, the parameter server is further configured to: The first communication configuration parameter corresponding to the first application in the parameter allocation information is updated according to the third communication configuration parameter.

23. The software product according to claim 21 or 22, wherein: The third communication configuration parameter is also stored in the development device; The communication middleware is further used to: when the second development information includes the first application and the third communication configuration parameters, when running the first application in the second development information, establish a communication channel for the first application based on the third communication configuration parameters.

24. The software product according to any one of claims 15 to 23, wherein: Before allocating the first communication configuration parameter to the first application, the communication middleware is further configured to: It is determined that the first development information does not include a fourth communication configuration parameter of the first application.

25. The software product of claim 24, wherein: The communication middleware is further used for: If the first development information includes the fourth communication configuration parameter of the first application, a communication channel of the first application is established based on the fourth communication configuration parameter.

26. The software product according to claim 24 or 25, wherein: The communication middleware is further configured to: send a parameter verification request to the parameter server, wherein the parameter verification request includes the fourth communication configuration parameter; The parameter server is further configured to: obtain parameter allocation information, and if the parameter allocation information contains a second communication configuration parameter corresponding to the first application, but the second communication configuration parameter is different from the fourth communication configuration parameter, or if the parameter allocation information contains another application corresponding to the fourth communication configuration parameter, return a response message indicating a parameter verification failure to the communication middleware; The communication middleware is further configured to generate a first prompt message according to the response message indicating that the parameter verification has failed, wherein the first prompt message is configured to prompt that an error has occurred in the fourth communication configuration parameter.

27. The software product according to claim 25 or 26, wherein: The parameter server is also used to: If the fourth communication configuration parameter corresponding to the application does not exist in the parameter allocation information, the fourth communication configuration parameter corresponding to the first application is stored in the parameter allocation information.

28. A development device, characterized in that The method comprises a unit / module for implementing the method according to any one of claims 1 to 14.

29. A development device, characterized in that comprising a processor coupled to a memory; The processor is configured to execute the computer program or instructions stored in the memory, so as to enable the development device to perform the method according to any one of claims 1 to 14.

30. A vehicle, characterized in that: Comprising a development device as claimed in claim 28 or 29.

31. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a program or instruction, and when the program or instruction is executed, the method according to any one of claims 1 to 14 is implemented.

32. A computer program product, characterized in that The method comprises a computer program code, which, when run on a computer, causes the computer to perform the method according to any one of claims 1 to 14.

Images