Vehicle software development method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention discloses a vehicle software development method and device, electronic equipment and a storage medium, and the method comprises the steps: managing a service demand through a demand management tool, and creating a service description table corresponding to the service demand in a service design document of the demand management tool; establishing an association relationship between each vehicle service and a corresponding service demand in the service description table, and exporting the service description table as a target format table to obtain a software architecture design document; generating a design version of a vehicle architecture description file through an architecture development tool based on the software architecture design document; and constructing vehicle software for realizing each service demand based on the design version of the vehicle architecture description file. According to the embodiment of the invention, various service requirements related to vehicle software development and service interface information of corresponding services can be accurately and correspondingly managed.

Description

Technical Field

[0001] The present invention relates to the technical field of vehicle electronic systems, and in particular to a vehicle software development method, device, electronic equipment and storage medium. Background Art

[0002] With the improvement of automotive-grade chip performance, the introduction of the software-defined vehicle concept, and the gradual application of service-oriented architecture (SOA) in the automotive field, high personalization and differentiation of vehicle functions as well as rapid updates and upgrades have become possible. Due to the high complexity of vehicle software, different models, configurations, and user needs vary. In order to achieve high personalization and differentiation of vehicle functions as well as rapid updates and upgrades, it is necessary to accurately match and manage various requirements and corresponding services during vehicle software development. The existing technology based on tables cannot uniformly manage service interface information, making it difficult to ensure that all requirements can be implemented. Therefore, there is an urgent need for a vehicle software development method that can accurately match and manage various requirements and services. Summary of the Invention

[0003] Embodiments of the present invention provide a vehicle software development method, device, electronic device, and storage medium, which can accurately manage the corresponding service requirements involved in vehicle software development and the service interface information of the corresponding services.

[0004] In a first aspect, an embodiment of the present invention provides a vehicle software development method, comprising:

[0005] Managing service requirements using a requirements management tool, and creating a service description table corresponding to the service requirements in a service design document of the requirements management tool, wherein the service requirements include at least one functional requirement or non-functional requirement managed by the requirements management tool, and the service description table includes service interface information of the vehicle service corresponding to each service requirement;

[0006] Establishing an association relationship between each vehicle service and a corresponding service requirement in the service description table, and exporting the service description table into a target format table to obtain a software architecture design document;

[0007] Generating a design version of a vehicle architecture description file using an architecture development tool based on the software architecture design document; and

[0008] The vehicle software that implements the various service requirements is constructed based on the design version of the vehicle architecture description file.

[0009] In a second aspect, an embodiment of the present invention provides a vehicle software development device, comprising:

[0010] a service description table acquisition module, configured to manage service requirements using a requirements management tool and create a service description table corresponding to the service requirements in a service design document of the requirements management tool, wherein the service requirements include at least one functional requirement or non-functional requirement managed by the requirements management tool, and the service description table includes service interface information of the vehicle service corresponding to each service requirement;

[0011] a software architecture design document acquisition module, configured to establish an association between each vehicle service and a corresponding service requirement in the service description table, and to export the service description table into a target format table to obtain a software architecture design document;

[0012] a vehicle architecture description file acquisition module, configured to generate a design version of a vehicle architecture description file using an architecture development tool based on the software architecture design document; and

[0013] A software construction module is used to construct vehicle software that implements the various service requirements based on the design version of the vehicle architecture description file.

[0014] In a third aspect, an embodiment of the present invention further provides an electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, a vehicle software development method as described in any one of the embodiments of the present invention is implemented.

[0015] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the vehicle software development method as described in any one of the embodiments of the present invention.

[0016] The embodiments of the present invention provide a vehicle software development method, device, electronic device and storage medium. By utilizing a requirement management tool to manage service requirements, and creating a service description table corresponding to the service requirements in the service design document of the requirement management tool, and then establishing an association relationship between each vehicle service and the corresponding service requirement in the service description table, the various service requirements involved in vehicle software development and the service interface information of the corresponding service can be accurately managed, and the service requirements and vehicle services can be accurately matched to ensure that all requirements can be implemented, so as to facilitate the design of highly personalized and differentiated services and the rapid update and upgrade of each service, thereby improving user experience. In addition, it can also facilitate version management of vehicle services. The embodiments of the present invention further exports the service description table into a software architecture design document in a fixed format, and generates vehicle software that implements each service requirement based on the software architecture design document through an architecture development tool and constructs a design version based on the vehicle architecture description file. This can reduce the time required for vehicle software development and thus improve the development efficiency of vehicle software development. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solution of the present invention, the following is a brief introduction to the drawings required for use in the embodiments. It should be understood that the following drawings only illustrate certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without paying any creative work.

[0018] Figure 1 This is a flow chart of a vehicle software development method provided by an embodiment of the present invention;

[0019] Figure 2 is another flowchart of the vehicle software development method provided by an embodiment of the present invention;

[0020] Figure 3 is another flowchart of the vehicle software development method provided by an embodiment of the present invention;

[0021] Figure 4 is another flowchart of the vehicle software development method provided by an embodiment of the present invention;

[0022] Figure 5 is another flowchart of the vehicle software development method provided by an embodiment of the present invention;

[0023] Figure 6 This is a schematic structural diagram of a vehicle software development device provided by an embodiment of the present invention;

[0024] Figure 7 It is a structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0025] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0026] It should be noted that the terms "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is 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.

[0027] With the improvement of automotive-grade chip performance, the introduction of the software-defined vehicle concept, and the gradual application of service-oriented architecture (SOA) in the automotive field, highly personalized and differentiated vehicle functions, as well as rapid updates and upgrades, have become possible. Unlike traditional signal-oriented vehicle electronic system architectures, SOA, with its standardized service interfaces, highly cohesive and loosely coupled service design mechanisms, and composable and extensible service features, combined with high-performance computing platforms, has become the ultimate trend in vehicle software architecture design. However, existing technologies are not yet able to achieve precise management of service requirements and corresponding services during the development of vehicle software in the SOA service architecture. Existing technologies, based on tables, cannot uniformly manage service interface information, making it difficult to ensure that all requirements can be implemented.

[0028] The embodiments of the present invention provide a vehicle software development method, device, electronic device and storage medium. By utilizing a requirement management tool to manage service requirements, and creating a service description table corresponding to the service requirements in the service design document of the requirement management tool, and then establishing an association relationship between each vehicle service and the corresponding service requirement in the service description table, the various service requirements involved in vehicle software development and the service interface information of the corresponding service can be accurately managed, and the service requirements and vehicle services can be accurately matched to ensure that all requirements can be implemented, so as to facilitate the design of highly personalized and differentiated services and facilitate the rapid update and upgrade of each service, thereby improving the user experience; the embodiments of the present invention further exports the service description table into a software architecture design document in a fixed format, and generates vehicle software that implements each service requirement based on the software architecture design document through an architecture development tool and a design version based on the vehicle architecture description file. This can reduce the frequency of errors in the process of vehicle software development, reduce the time required for vehicle software development, and thus accurately improve the development efficiency of vehicle software development.

[0029] Figure 1This is a flow chart of a vehicle software development method provided by an embodiment of the present invention. This embodiment is applicable to scenarios involving the development of vehicle software within a SOA service architecture. This method can be executed by a vehicle software development device provided by an embodiment of the present invention, which can be implemented using software and / or hardware. In one specific embodiment, the device can be integrated into an electronic device, such as a computer or server. The following embodiments will be described using the device integrated into an electronic device as an example.

[0030] refer to Figure 1 , the method may specifically include the following steps:

[0031] Step 101: Manage service requirements using a requirements management tool and create a corresponding service description table within the service design document within the requirements management tool. A service requirement includes at least one functional requirement or non-functional requirement managed by the requirements management tool. The service description table includes service interface information for the vehicle service corresponding to each service requirement. This step facilitates precise management of service requirements and corresponding vehicle services based on the service description table during vehicle software development.

[0032] Specifically, the requirement management tool may be any software tool in the prior art for collecting, organizing, analyzing, tracking and managing requirements, for example, WindChill RV&S.

[0033] Specifically, the above service requirements can be understood as the need to design corresponding vehicle services during the vehicle software development process.

[0034] Specifically, the functional requirements of the above-mentioned vehicles mainly describe the specific functions and behaviors that the vehicle software needs to implement. For example, the functional requirements of the automatic parking system are to be able to identify parking spaces, control the vehicle to enter the parking space, etc.

[0035] Specifically, the non-functional requirements of the above-mentioned vehicles focus on describing the characteristics and quality requirements of the system or software in terms of performance, reliability, safety, ease of use, etc. The above-mentioned non-functional requirements include non-functional requirements related to performance, such as the vehicle's electronic control unit (ECU) needs to meet the requirements of stable operation under various harsh environmental conditions such as high temperature and low temperature.

[0036] Specifically, the above service interface information can be understood as the specification and description of the interaction and communication between various vehicle services. It defines the service input, output, operation mode, and related protocols and constraints.

[0037] Optionally, the service interface information includes: service name, service interface name, interface parameters, and parameter data types.

[0038] Optionally, the above-mentioned process of managing service requirements using a requirements management tool includes: for each service requirement, automatically saving the file version after each modification, supporting the generation of version numbers in chronological order (such as V1.0, V2.0), and recording the time, operator and change summary of each modification, and associating key metadata with each version, including the person who modified it, the time of operation, the associated task number and the scope of the change, to form a complete version chain.

[0039] Optionally, the above process of managing service requirements using the requirements management tool includes: providing users with historical version retrieval and content difference comparison operation functions.

[0040] Optionally, the above process of managing service requirements using the requirements management tool includes: automatically generating an audit tracking log to record in detail the user's addition, deletion, modification and query behavior on files, including operation time, account information and specific actions.

[0041] Optionally, the process of creating a service description table corresponding to the service requirement in the service design document of the requirement management tool includes:

[0042] Based on the service and service interface design principles, vehicle services and service interfaces corresponding to the service requirements are created in the service design document, and the above service description table is created using the created vehicle services and service interfaces.

[0043] Specifically, the service name of each vehicle service may be generated based on a pre-set service naming rule.

[0044] Specifically, the above-mentioned service design principles include the service layered design principle, which divides each vehicle service into an application layer, a combination layer, and an atomic layer: the application layer is suitable for scenario services that require the combination of multiple functions; the combination layer is suitable for services that process and integrate basic logic, and undertake information from actuators and sensors, which contains service interfaces that need to be frequently called and subscribed; the atomic layer is suitable for basic services provided to actuators, sensors, etc.

[0045] Specifically, the service interface design principles include: interface design principles based on the SOME / IP (Scalable service-oriented middleware over IP) protocol.

[0046] Optionally, the above process of creating a service description table corresponding to the service requirements in the service design document of the demand management tool includes: creating a service description table corresponding to the service requirements based on the service and service interface design principles according to the relevant information of vehicle services, service interfaces, interface parameters and parameter data types input by the user.

[0047] Step 102: Establishing relationships between each vehicle service and its corresponding service requirements in the service description table and exporting the service description table to a target format to generate a software architecture design document. This step facilitates efficient generation of a design version of the vehicle architecture description file based on the software architecture design document using architecture development tools.

[0048] Optionally, the process of establishing the association relationship between each vehicle service and the corresponding service demand in the service description table includes: linking each vehicle service and the corresponding service demand.

[0049] It can be understood that after the corresponding association relationship is established, each vehicle service can be traced back to the source of demand so that each service demand can be realized through the corresponding service and service interface.

[0050] Specifically, the target format table may be a table of any table software in the prior art in the target format, for example, an Excel table in the target format. The format of the target format table may be predetermined.

[0051] Optionally, the process of exporting the service description table into a target format table to obtain the software architecture design document includes: exporting the service description table from the requirement management tool, and adjusting the service description table into a target format table to obtain the software architecture design document.

[0052] Specifically, a software architecture document export plug-in of a pre-set requirement management tool may be used to directly export the software architecture design document in the target format according to the service description table.

[0053] Step 103: Generate a design version of the vehicle architecture description file using an architecture development tool based on the software architecture design document. This step efficiently generates the design version of the vehicle architecture description file, facilitating efficient construction of vehicle software that implements the aforementioned service requirements based on the design version of the vehicle architecture description file.

[0054] Specifically, the above-mentioned architecture development tool can be a tool in a class of software tools used in the prior art to assist developers in designing, modeling, analyzing and documenting vehicle software architecture, and can be, for example, PREEVision.

[0055] Optionally, the above-mentioned process of generating a design version of a vehicle architecture description file based on the software architecture design document through an architecture development tool includes: extracting key information from the software architecture design document, selecting a suitable architecture development tool, using the selected architecture development tool to create a vehicle software architecture model based on the key information, verifying the vehicle software architecture model, and converting the verified vehicle software architecture model into a design version of the vehicle architecture description file and exporting it.

[0056] Step 104: Build vehicle software that implements each service requirement based on the designed version of the vehicle architecture description file. Building on steps 101 through 103, this step accurately manages the various service requirements involved in vehicle software development and the service interface information of the corresponding services. This ensures that service requirements are precisely aligned with vehicle services, ensuring that all requirements can be implemented. This facilitates the design of highly personalized and differentiated services and facilitates the rapid updating and upgrading of various services, thereby improving the user experience. Furthermore, building on steps 101 through 103, this step can reduce the time required for vehicle software development, thereby improving development efficiency.

[0057] Optionally, the process of constructing the vehicle software that implements various service requirements based on the design version of the vehicle architecture description file includes: constructing the vehicle software through a software modeling tool based on the design version of the vehicle architecture description file.

[0058] Specifically, the software modeling tool may be any software modeling tool in the prior art, such as Matlab.

[0059] Optionally, the above-mentioned process of building vehicle software that implements various service requirements based on the design version of the vehicle architecture description file includes: determining the differentiated configuration parameters of the vehicle based on the differentiated characteristics of the vehicle and building the vehicle software based on the differentiated configuration parameters and the design version of the vehicle architecture description file.

[0060] Optionally, the differentiated features of the above-mentioned vehicles include: different features of vehicles of different models, different features of vehicles with different configurations, different features of vehicles under different operating conditions, different features of vehicles that meet different regulations and standards, and / or sensor data collected by sensor equipment during vehicle operation, and the different features of the above-mentioned vehicles with the same configuration, such as the different features between high-end and low-end vehicles.

[0061] Specifically, the above-mentioned differentiated configuration parameters may include calibration parameters and observation parameters.

[0062] The vehicle software development method provided by the embodiment of the present invention is further described below. Figure 2 As shown, Figure 1 Step 102 in the embodiment may include the following steps:

[0063] Step 1021: Export the service name, service interface name, and interface parameters in the service description table to the first form, the second form, and the third form respectively.

[0064] Specifically, the first form, the second form, and the third form may be created in advance, or may be created when exporting corresponding form data.

[0065] Step 1022: Export the parameter data types in the service description table to a third table, and make each parameter data type correspond to the position of the corresponding interface parameter.

[0066] Specifically, the above parameter data types may be exported simultaneously with the interface parameters, or may be exported before or after the interface parameters are exported.

[0067] Step 1023: Construct a software architecture design document using the first form, the second form, and the third form.

[0068] Specifically, the first form, the second form, and the third form may be combined into the software architecture design document.

[0069] The format of the software architecture design document obtained by the embodiment of the present invention enables accurate generation of software architecture design documents corresponding to various vehicle services through architecture development tools based on the software architecture design document.

[0070] The vehicle software development method provided by the embodiment of the present invention is further described below. Figure 3 As shown, Figure 1 Step 103 in the embodiment may include the following steps:

[0071] Step 1031: normalize the software architecture design document to obtain a standardized version of the software architecture design document.

[0072] Step 1032 : Based on the specification version of the software architecture design document, obtain the automotive open system architecture elements corresponding to each vehicle service through the architecture import plug-in of the architecture development tool.

[0073] Specifically, the above-mentioned automotive open system architecture elements can be understood as the components of the automotive open system architecture (Automotive Open System Architecture, AUTOSAR).

[0074] Optionally, the process of obtaining the automotive open system architecture elements corresponding to each vehicle service through the architecture import plug-in of the architecture development tool based on the specification version of the software architecture design document includes:

[0075] The various automotive open system architecture elements in the specification version of the software architecture design document are parsed through the architecture import plug-in; the various automotive open system architecture elements are serialized to obtain architecture element sequence data; and the architecture element sequence data corresponding to each vehicle service is obtained to obtain the automotive open system architecture element corresponding to each vehicle service.

[0076] Optionally, the above-mentioned process of standardizing the software architecture design document to obtain the standard version of the software architecture design document includes: standardizing the software architecture design document based on the architecture design document specification corresponding to the architecture import plug-in to obtain the standard version of the software architecture design document.

[0077] Specifically, the architecture design document specification can be determined based on the performance characteristics of the architecture import plug-in when parsing the architecture design document. For example, when the architecture import plug-in parses the architecture design document, an error message is generated if there are duplicate defined data types in the architecture design document. Therefore, the architecture design document specification is determined to not include duplicate defined data types.

[0078] Specifically, in actual applications, the error portion can be corrected after the architecture import plug-in reports an error.

[0079] Step 1033 , using an architecture development tool to generate software components corresponding to each vehicle service based on the corresponding automotive open system architecture elements, and generating an architecture description file corresponding to each software component to obtain a design version of the vehicle architecture description file.

[0080] The embodiments of the present invention can facilitate further efficient generation of design versions of vehicle architecture description files by standardizing the processing of software architecture design documents.

[0081] Optional, such as Figure 4 As shown, Figure 3 Step 1031 in the embodiment may include the following steps:

[0082] Step 1031A: Use a data processing tool to check whether the service interface information in the software architecture design document contains duplication or errors.

[0083] Specifically, the data processing tool can be any data processing tool in the prior art that can check whether there are duplications or errors in the data in the table, for example, it can be a VBA (Visual Basic for Applications, a universal symbolic instruction code language for beginners of application visualization) program.

[0084] Optionally, the above process of checking whether the service interface information in the software architecture design document contains duplication or errors includes: checking whether there are duplicate service names, service interface names, and parameter data types.

[0085] Optionally, the above process of checking whether there are duplications or errors in the service interface information in the software architecture design document includes: checking whether there are mapping errors between the service interface and the data type, and checking whether there are spelling errors in the service name, service interface name, interface parameters and parameter data types.

[0086] It is understandable that in actual application scenarios, multiple developers usually develop the same vehicle software at the same time, so it is inevitable that the service interface information of the vehicle service will be repeated. In addition, since the service interface information of the vehicle service is usually determined based on the relevant information input manually, errors are inevitable. Therefore, it is necessary to check whether there is duplication or error in the service interface information in the software architecture design document.

[0087] Step 1031B, when there are duplicate or erroneous service interface information in the software architecture design document, a corrected version of the service description table is generated in the service design document based on the historical version of the service description table and the duplicate or erroneous service interface information, and the various versions of the service description table are retained and managed using the requirements management tool.

[0088] Optionally, the process of retaining and managing various versions of the service description table includes using a requirement management tool to perform the same management on various versions of the service description table in the service design document as the aforementioned service requirements.

[0089] Step 1031C: Export the corrected version of the service description table into a target format table to obtain a corrected version of the software architecture design document, and retain and manage various versions of the software architecture design document.

[0090] Step 1031D: sort and classify the service interface information in the corrected version of the software architecture design document to obtain the standard version of the software architecture design document.

[0091] Optionally, the process of sorting and classifying the service interface information in the corrected version of the software architecture design document to obtain the standard version of the software architecture design document includes:

[0092] Classify and sort the service names in the specification version of the software architecture design document based on the initials or based on the service type, and classify and sort the service interface names, interface parameters and parameter data types based on the category and sequence number of the service name.

[0093] It is understandable that historical version management of service description tables and software architecture design documents can facilitate subsequent operation and maintenance, optimization, backtracking and responsibility division.

[0094] The embodiment of the present invention can centrally check the rationality of services and service interfaces, quickly add, delete, check and modify service interfaces, and can further facilitate the efficient generation of design versions of vehicle architecture description files; in addition, the embodiment of the present invention can facilitate historical version management of service description tables in demand management tools, and can facilitate version updates and upgrades of vehicle software, subsequent operation and maintenance, optimization, backtracking, and division of responsibilities when problems arise in the operation of vehicle software.

[0095] The vehicle software development method provided by the embodiment of the present invention is further described below. Figure 5 As shown, the following steps may be included:

[0096] Step 501: Manage service requirements using a requirements management tool, and create a service description table corresponding to the service requirements in a service design document of the requirements management tool.

[0097] Step 502 : Establish an association relationship between each vehicle service and the corresponding service requirement in the service description table, and export the service description table into a target format table to obtain a software architecture design document.

[0098] Step 503 : Generate a design version of the vehicle architecture description file using an architecture development tool based on the software architecture design document.

[0099] Step 504 : determining differentiated configuration parameters of the vehicle based on the differentiated features of the vehicle and building vehicle software based on the differentiated configuration parameters and the design version of the vehicle architecture description file.

[0100] Step 505 : Obtain an architecture description file corresponding to the vehicle software to obtain a release version of the vehicle architecture description file.

[0101] Optionally, the above process of obtaining the architecture description file corresponding to the vehicle software to obtain the released version of the vehicle architecture description file includes: exporting the architecture description file corresponding to the vehicle software from a modeling tool to obtain the released version of the vehicle architecture description file.

[0102] In step 506 , a release version of the software architecture design document is generated by an architecture development tool based on the release version of the vehicle architecture description file, and each version of the software architecture design document is retained and managed.

[0103] Optionally, the process of generating a release version of the software architecture design document using an architecture development tool based on the release version of the vehicle architecture description file includes:

[0104] Import the release version of the above-mentioned vehicle architecture description file into the architecture development tool, parse the service interface information in the release version of the vehicle architecture description file through the architecture development tool, and export the service interface information into a target format table to obtain the release version of the above-mentioned software architecture design document.

[0105] Specifically, the service interface data obtained by parsing can be stored in an internal data structure based on an architecture design document template in a target format stored in the architecture development tool, and then directly exported to obtain a release version of the above software architecture design document.

[0106] Step 507: Generate a release version of the service description table in the service design document based on the release version of the software architecture design document, and use a requirement management tool to retain and manage various versions of the service description table.

[0107] The embodiments of the present invention can facilitate historical version management of the service description table in the service design document in the demand management tool, and facilitate historical version management of the software architecture design document, thereby facilitating subsequent version updates, maintenance, optimization, backtracking and responsibility division.

[0108] Figure 6 This is a structural diagram of a vehicle software development device provided by an embodiment of the present invention, which is suitable for executing the vehicle software development method provided by an embodiment of the present invention. Figure 6 As shown, the device may specifically include:

[0109] The service description table acquisition module 601 is used to manage service requirements using a requirements management tool and create a corresponding service description table within the service design document of the requirements management tool. A service requirement includes at least one vehicle functional requirement or performance-related vehicle non-functional requirement managed by the requirements management tool. The service description table includes service interface information for the vehicle service corresponding to each service requirement. This module facilitates precise management of service requirements and corresponding vehicle services based on the service description table during vehicle software development.

[0110] Optionally, the service interface information includes: service name, service interface name, interface parameters, and parameter data types.

[0111] The software architecture design document acquisition module 602 is used to establish a relationship between each vehicle service and the corresponding service requirement in the service description table and export the service description table into a target format to obtain the software architecture design document. This module facilitates the efficient generation of a design version of the vehicle architecture description file based on the software architecture design document using architecture development tools.

[0112] Optionally, the above-mentioned software architecture design document acquisition module 602 can be specifically used to export the service name, service interface name and interface parameters in the service description table to the first form, the second form and the third form respectively; export the parameter data type in the service description table to the third form, and make each parameter data type correspond to the position of the corresponding interface parameter; and use the first form, the second form and the third form to construct the software architecture design document.

[0113] The vehicle architecture description file acquisition module 603 is used to generate a design version of the vehicle architecture description file using an architecture development tool based on the software architecture design document. This module can efficiently generate a design version of the vehicle architecture description file, thereby facilitating the efficient construction of vehicle software that implements the aforementioned service requirements based on the design version of the vehicle architecture description file.

[0114] Optionally, the above-mentioned vehicle architecture description file acquisition module 603 can be specifically used to standardize the software architecture design document to obtain a standard version of the software architecture design document; based on the standard version of the software architecture design document, obtain the automotive open system architecture elements corresponding to each vehicle service through the architecture import plug-in of the architecture development tool; generate the software components corresponding to each vehicle service based on the corresponding automotive open system architecture elements through the architecture development tool, and generate the architecture description file corresponding to each software component to obtain the design version of the vehicle architecture description file.

[0115] Optionally, the above-mentioned vehicle architecture description file acquisition module 603 can be specifically used to parse each automotive open system architecture element in the standard version of the software architecture design document through the architecture import plug-in; serialize each automotive open system architecture element to obtain architecture element sequence data; and obtain the architecture element sequence data corresponding to each vehicle service to obtain the automotive open system architecture element corresponding to each vehicle service.

[0116] Optionally, the above-mentioned vehicle architecture description file acquisition module 603 can be specifically used to check whether there are duplications or errors in the service interface information in the software architecture design document through data processing tools; when there are duplications or errors in the service interface information in the software architecture design document, based on the historical version of the service description table and the duplicated or erroneous service interface information, generate a corrected version of the service description table in the service design document and use the requirement management tool to retain and manage various versions of the service description table; export the corrected version of the service description table to a target format table to obtain a corrected version of the software architecture design document, and retain and manage various versions of the software architecture design document; and sort and classify the service interface information in the corrected version of the software architecture design document to obtain the standard version of the software architecture design document.

[0117] Software Construction Module 604 is used to build vehicle software that implements various service requirements based on the design version of the vehicle architecture description file. This module, combined with Modules 601 through 603, accurately manages the various service requirements involved in vehicle software development and the service interface information of the corresponding services. This ensures that service requirements are precisely aligned with vehicle services, ensuring that all requirements can be implemented. This facilitates the design of highly personalized and differentiated services and facilitates the rapid update and upgrade of various services, thereby improving the user experience. Furthermore, this module reduces the time required for vehicle software development, thereby improving development efficiency.

[0118] Optionally, the software construction module 604 can be specifically used to determine differentiated configuration parameters of the vehicle based on differentiated features of the vehicle and to construct vehicle software based on the differentiated configuration parameters and a design version of a vehicle architecture description file.

[0119] Optionally, the aforementioned vehicle architecture description file acquisition module 601 is further used to obtain the architecture description file corresponding to the vehicle software to obtain a released version of the vehicle architecture description file.

[0120] Optionally, the aforementioned software architecture design document acquisition module 602 is also used to generate a release version of the software architecture design document through an architecture development tool based on the release version of the vehicle architecture description file, and retain and manage various versions of the software architecture design document.

[0121] Optionally, the aforementioned vehicle architecture description file acquisition module 603 is also used to generate a release version of the service description table in the service design document based on the release version of the software architecture design document, and use a demand management tool to retain and manage various versions of the service description table.

[0122] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional modules is used as an example for illustration. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the functional modules described above can refer to the corresponding process in the aforementioned method embodiment and will not be repeated here.

[0123] An embodiment of the present invention also provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the vehicle software development method provided in any of the above embodiments when executing the program.

[0124] An embodiment of the present invention further provides a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the vehicle software development method provided in any of the above embodiments.

[0125] An embodiment of the present invention further provides a computer program product, comprising a computer program, which, when executed by a processor, implements the vehicle software development method as described in any one of the embodiments of the present invention.

[0126] Reference below Figure 7 , which shows a schematic structural diagram of a computer system 700 of an electronic device suitable for implementing an embodiment of the present invention. Figure 7 The electronic device shown is only an example and should not limit the functions and scope of use of the embodiments of the present invention.

[0127] like Figure 7 As shown, the computer system 700 includes a central processing unit (CPU) 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 702 or a program loaded from a storage unit 708 into a random access memory (RAM) 703. Various programs and data required for the operation of the system 700 are also stored in the RAM 703. The CPU 701, ROM 702, and RAM 703 are connected to each other via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0128] The following components are connected to the I / O interface 705: an input section 706 including a keyboard, a mouse, and the like; an output section 707 including devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), and a speaker; a storage section 708 including a hard disk; and a communication section 709 including a network interface card such as a LAN card or a modem. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the I / O interface 705 as needed. A removable medium 711, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 710 as needed, so that computer programs read therefrom can be installed into the storage section 708 as needed.

[0129] In particular, according to the embodiments disclosed in the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 709, and / or installed from a removable medium 711. When the computer program is executed by the central processing unit (CPU) 701, the above-mentioned functions defined in the system of the present invention are executed.

[0130] It should be noted that the computer-readable medium described in the present invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media can include, but are not limited to, an electrical connection having one or more conductors, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In the present invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. This propagated data signal can take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device. Program code embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wireline, optical fiber cable, RF, or any suitable combination thereof.

[0131] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present invention. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the above-mentioned module, program segment, or a part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0132] The modules and / or units described in the embodiments of the present invention may be implemented in software or hardware. The modules and / or units described may also be provided within a processor. For example, a processor may be described as comprising a service description table acquisition module, a software architecture design document acquisition module, a vehicle architecture description file acquisition module, and a software construction module. The names of these modules do not, in some cases, limit the modules themselves.

[0133] As another aspect, the present invention further provides a computer-readable medium, which may be included in the device described in the above embodiment, or may exist independently and not be incorporated into the device. The computer-readable medium carries one or more programs, and when executed by the device, the device is configured to: manage service requirements using a requirements management tool, and create a service description table corresponding to the service requirements in a service design document of the requirements management tool, wherein the service requirements include at least one functional requirement or non-functional requirement managed by the requirements management tool, and the service description table includes service interface information of the vehicle service corresponding to each service requirement;

[0134] Establish an association between each vehicle service and the corresponding service requirement in the service description table, and export the service description table into a target format table to obtain a software architecture design document; generate a design version of the vehicle architecture description file through an architecture development tool based on the software architecture design document; and build vehicle software that implements each service requirement based on the design version of the vehicle architecture description file.

[0135] The above specific embodiments do not limit the scope of protection of the present invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention are intended to be included within the scope of protection of the present invention.

Claims

1. A vehicle software development method, characterized in that: include: Managing service requirements using a requirements management tool, and creating a service description table corresponding to the service requirements in a service design document of the requirements management tool, wherein the service requirements include at least one functional requirement or non-functional requirement managed by the requirements management tool, and the service description table includes service interface information of the vehicle service corresponding to each service requirement; Establishing an association relationship between each vehicle service and a corresponding service requirement in the service description table, and exporting the service description table into a target format table to obtain a software architecture design document; Generating a design version of a vehicle architecture description file using an architecture development tool based on the software architecture design document; and The vehicle software that implements the various service requirements is constructed based on the design version of the vehicle architecture description file.

2. The vehicle software development method according to claim 1, characterized in that: Generating a design version of a vehicle architecture description file based on the software architecture design document by using an architecture development tool includes: Normalizing the software architecture design document to obtain a standardized version of the software architecture design document; Obtaining automotive open system architecture elements corresponding to each vehicle service through an architecture import plug-in of the architecture development tool based on a specification version of the software architecture design document; The architecture development tool generates software components corresponding to each vehicle service based on corresponding automotive open system architecture elements, and generates architecture description files corresponding to each software component to obtain a design version of the vehicle architecture description file.

3. The vehicle software development method according to claim 2, characterized in that: The method of obtaining the automotive open system architecture elements corresponding to each vehicle service through the architecture import plug-in of the architecture development tool based on the specification version of the software architecture design document includes: The architecture import plug-in is used to parse the various automotive open system architecture elements in the standard version of the software architecture design document; the various automotive open system architecture elements are serialized to obtain architecture element sequence data; and the architecture element sequence data corresponding to each vehicle service is obtained to obtain the automotive open system architecture elements corresponding to each vehicle service.

4. The vehicle software development method according to claim 2, characterized in that: The standardizing of the software architecture design document to obtain a standard version of the software architecture design document includes: Checking whether the service interface information in the software architecture design document is duplicated or incorrect using a data processing tool; When there are duplicate or erroneous service interface information in the software architecture design document, based on historical versions of the service description table and the duplicate or erroneous service interface information, a corrected version of the service description table is generated in the service design document, and each version of the service description table is retained and managed using the requirements management tool; Exporting the corrected version of the service description table into a target format table to obtain a corrected version of the software architecture design document, and retaining and managing various versions of the software architecture design document; and The service interface information in the corrected version of the software architecture design document is sorted and classified to obtain a standard version of the software architecture design document.

5. The vehicle software development method according to claim 1, characterized in that: The vehicle software that implements the various service requirements is constructed based on the design version of the vehicle architecture description file, including: Differentiated configuration parameters of the vehicle are determined based on the differentiated features of the vehicle, and the vehicle software is constructed based on the differentiated configuration parameters and a design version of the vehicle architecture description file.

6. The vehicle software development method according to claim 5, characterized in that: Also includes: Obtaining an architecture description file corresponding to the vehicle software to obtain a release version of the vehicle architecture description file; Generating a release version of a software architecture design document using the architecture development tool based on the release version of the vehicle architecture description file, and retaining and managing various versions of the software architecture design document; A release version of a service description table is generated in the service design document based on the release version of the software architecture design document, and each version of the service description table is retained and managed using the requirement management tool.

7. The vehicle software development method according to claim 1, characterized in that: The service interface information includes: service name, service interface name, interface parameters and parameter data types; the software architecture design document is obtained by exporting the service description table into a target format table, including: Exporting the service name, service interface name and interface parameters in the service description table to the first form, the second form and the third form respectively; Exporting the parameter data types in the service description table to the third table, and making each parameter data type correspond to the position of the corresponding interface parameter; and The software architecture design document is constructed using the first form, the second form, and the third form.

8. A vehicle software development device, characterized in that: include: a service description table acquisition module, configured to manage service requirements using a requirements management tool and create a service description table corresponding to the service requirements in a service design document of the requirements management tool, wherein the service requirements include at least one functional requirement or non-functional requirement managed by the requirements management tool, and the service description table includes service interface information of the vehicle service corresponding to each service requirement; a software architecture design document acquisition module, configured to establish an association between each vehicle service and a corresponding service requirement in the service description table, and to export the service description table into a target format table to obtain a software architecture design document; A vehicle architecture description file acquisition module, configured to generate a design version of a vehicle architecture description file using an architecture development tool based on the software architecture design document; as well as A software construction module is used to construct vehicle software that implements the various service requirements based on the design version of the vehicle architecture description file.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the vehicle software development method according to any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the vehicle software development method according to any one of claims 1 to 7 is implemented.

Images