A collaborative development method, device and system for vehicle control software

Through the collaborative development method, the development process of vehicle control software is decoupled, which solves the high cost and low efficiency problems caused by the coupling of development process in the existing technology, and achieves more efficient software development.

CN119356646BActive Publication Date: 2025-05-06CHENGDU CELIS TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202411908482.0
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-12-24
Publication Date
2025-05-06
Estimated Expiration
2044-12-24

AI Technical Summary

Technical Problem

In the prior art, the development process of vehicle control software is severely coupled, resulting in high development costs and low efficiency. When a link changes, the entire process needs to be re-execute, resulting in efficiency and cost issues.

Method used

A collaborative development method for vehicle control software is proposed. By obtaining development packages and performing network topology development, architecture design, behavior modeling, bottom soft configuration and integration, the software development method is optimized, the development cost is reduced and development efficiency is improved.

Benefits of technology

The software development is decoupled. The software integration end only needs to rely on the development package provided by the development package providing the terminal to perform software development, and does not need to return to the development package providing the terminal for development, which improves development efficiency and saves development costs.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119356646B_ABST
    Figure CN119356646B_ABST
Patent Text Reader

Abstract

The present application relates to the field of software development technology, and discloses a collaborative development method, device and system for vehicle control software. The method includes: obtaining a development package, performing network topology development on the first interface service detail table, and obtaining a first CP Arxml file; performing architecture design on the first CP Arxml file and the library Arxml file, and obtaining a first application layer Arxml file and a first SWC Arxml file; performing behavioral modeling on the first SWC Arxml file, and obtaining the application layer code of the first SWC, and performing bottom software configuration on the first communication matrix table, the first application layer Arxml file and the configuration information file, and obtaining the framework code and RTE layer code of the SWC; integrating the aforementioned files to obtain the vehicle control software. The present application collaboratively develops the vehicle control software, optimizes the development method, and improves the development efficiency.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of software development technology, and in particular to a collaborative development method, device and storage medium for vehicle control software. Background Art

[0002] AUTOSAR (Automotive Open System Architecture) is an automotive open system architecture, which is a software development standard for automotive electronic systems. It is mainly used for the development of automotive electronic control unit (ECU) software. AUTOSAR aims to provide a standardized software development method for automotive electronic systems to achieve interoperability and portability between automotive electronic systems.

[0003] The AUTOSAR development process includes: requirements analysis, design phase, development phase, testing phase and deployment phase. At present, in the software design phase and development phase, vehicle manufacturers and software suppliers need to develop in series. For example, after the vehicle manufacturer completes the architecture design, it needs to submit it to the software supplier for underlying software configuration, and then return it to the vehicle manufacturer for software integration and compilation. The entire development process is severely coupled. If a certain link changes, the entire process needs to be re-executed, resulting in high development costs and low development efficiency. Summary of the invention

[0004] The present application provides a collaborative development method, device and system for vehicle control software, which optimizes the software development method, reduces software development costs and improves software development efficiency.

[0005] In a first aspect, the present application provides a method for collaborative development of vehicle control software, comprising:

[0006] Obtain a development kit for developing the second part of the service in the vehicle control software; the development kit includes: a library Arxml file, a configuration information file, a bottom soft link file and an RTE header file;

[0007] Performing network topology development on the first interface service detailed table to obtain a first CP Arxml file; the first interface service detailed table includes interface information of the first part of the service in the vehicle control software;

[0008] Performing architecture design on the first CP Arxml file and the library Arxml file to obtain a first application layer Arxml file and a first SWC Arxml file;

[0009] Performing behavior modeling on the first SWC Arxml file to obtain the application layer code of the first SWC, and performing bottom software configuration on the first communication matrix table, the first application layer Arxml file and the configuration information file to obtain the framework code and RTE layer code of the first SWC; the first communication matrix table includes the communication information of the first part of the service in the vehicle control software;

[0010] The framework code of the first SWC, the application layer code of the first SWC, the RTE layer code, the bottom soft link file and the RTE header file are integrated to obtain the whole vehicle control software.

[0011] In a second aspect, the present application provides a method for collaborative development of vehicle control software, comprising:

[0012] Obtaining a second communication matrix table, a second interface service detailed table and a third interface service detailed table for developing the second part of the service in the vehicle control software; wherein the third interface service detailed table includes information on interactive services between the local end and the software integration end, and the second interface service detailed table includes information on independent services of the local end;

[0013] Performing network topology development on the second interface service detailed table to obtain a second CP Arxml file; performing network topology development on the third interface service detailed table to obtain a library Arxml file;

[0014] Performing architecture design on the second CP Arxml file to obtain a second application layer Arxml file and a second SWCArxml file;

[0015] Performing behavior modeling on the second SWC Arxml file to obtain the application layer code of the second SWC;

[0016] Performing bottom-soft configuration on the second communication matrix table and the second application layer Arxml file to obtain a configuration Interface information file and a configuration code;

[0017] Integrate the configuration code with the application layer code of the second SWC to obtain a bottom soft link file and an operating environment RTE header file;

[0018] The library Arxml file, configuration Interface information file, bottom soft link file and operating environment RTE header file are used to generate a development kit, and the development kit is sent to the software integration end so that the software integration end can develop the whole vehicle control software according to the development kit.

[0019] In a third aspect, the present application provides an electronic device, including:

[0020] processor;

[0021] at least one memory;

[0022] The processor executes any collaborative development method of vehicle control software by calling the program or instruction stored in the at least one memory.

[0023] In a fourth aspect, the present application provides a collaborative development system for vehicle control software, including: a development package providing end and a software integration end;

[0024] The software integration end is used to execute the collaborative development method of the whole vehicle control software provided by the first aspect, and the development kit providing end is used to execute the collaborative development method of the whole vehicle control software provided by the second aspect.

[0025] Compared with the prior art, this application has the following technical effects:

[0026] 1. For the software integration end, obtain the development kit for developing the second part of the service in the vehicle control software, and develop the software in combination with the files in the development kit, the first interface service detailed table for developing the first part of the service, and the first communication matrix table, so as to obtain the vehicle control software including the first part of the service and the second part of the service. This application optimizes the traditional staggered serial development method. The software integration end only needs to rely on the development kit provided by the development kit provider to realize software development, and does not need to return to the development kit provider for development.

[0027] 2. In this application, the development kit provider obtains the second communication matrix table, the second interface service detailed table and the third interface service detailed table for developing the second part of the service in the vehicle control software, and then performs network topology development, architecture design, behavior modeling, bottom software configuration and integration to obtain the development kit. The development process of the development kit provider can be carried out independently and decoupled from the software integration end.

[0028] 3. Based on the collaborative development method provided in this application, when the software requirements change and the functions of the development package provider are not involved, the software integrator can conduct software development internally through the development method. The development package provider is unaware of the internal changes of the software integrator, which improves development efficiency and saves development costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In order to more clearly illustrate the specific implementation methods of the present application or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0030] Figure 1 It is a collaborative development scenario diagram of the vehicle control software provided in the embodiment of the present application;

[0031] Figure 2 It is a flow chart of a first method for collaborative development of vehicle control software provided in an embodiment of the present application;

[0032] Figure 3 is a flow chart of a second method for collaborative development of vehicle control software provided in an embodiment of the present application;

[0033] Figure 4 is a flow chart of a third method for collaborative development of vehicle control software provided in an embodiment of the present application;

[0034] Figure 5 is a flowchart of a fourth method for collaborative development of vehicle control software provided in an embodiment of the present application;

[0035] Figure 6 is a flowchart of a fifth method for collaborative development of vehicle control software provided in an embodiment of the present application;

[0036] Figure 7 is a flow chart of a sixth method for collaborative development of vehicle control software provided in an embodiment of the present application;

[0037] Figure 8 It is a structural schematic diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0038] In order to make the purpose, technical scheme and advantages of the embodiments of the present disclosure clearer, the technical scheme in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are only part of the embodiments of the present disclosure, rather than all of the embodiments. The components of the embodiments of the present disclosure generally described and shown in the drawings here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present disclosure provided in the drawings is not intended to limit the scope of the present disclosure for protection, but merely represents the selected embodiments of the present disclosure. Based on the embodiments of the present disclosure, all other embodiments obtained by those skilled in the art without making creative work belong to the scope of protection of the present disclosure.

[0039] In order to facilitate the introduction of the collaborative development method of vehicle control software provided in the embodiment of the present application, the following terms are first explained:

[0040] (1) SOA (Service-Oriented Architecture) is a software design and software architecture pattern that combines different functional units (services) of an application through well-defined interfaces and protocols. These services are independent and reusable, and they can interact across multiple systems and organizations. The goal of SOA is to improve the flexibility, scalability, and maintainability of software systems.

[0041] (2) Interface service table, or API (Application Programming Interface) service table: a table that defines the detailed information of each service and sub-service in the SOA architecture, such as system services, application services, etc. In the embodiment of the present application, the interface service table also defines the mapping relationship between virtual nodes and ports.

[0042] (3) Communication matrix table: A table that defines and manages the communication information exchanged between the electronic control units (ECUs) in the car through the vehicle network (such as CAN, LIN, FlexRay, Ethernet, etc.). The communication matrix table can include key information such as the sender, receiver, communication method, communication protocol, data format, and communication frequency. The table describes in detail the message information that each ECU node in the vehicle network needs to receive and send; this information includes message ID, signal type, signal length, data format, etc., which is used to ensure that each ECU node can complete the interaction and sharing of information according to the predetermined rules.

[0043] (4) SWC (Software Component): An independent, reusable, self-describing, and replaceable software unit used to implement specific Autosar application layer functions. SWC can run on different ECU electronic control units and has clear input and output interfaces.

[0044] (5) BSW (Basic Software) configuration: the underlying configuration of Autosar.

[0045] (6) RTE (Runtime Environment in Autosar layered architecture): provides an environment for the operation of the software application layer, supports communication mechanisms such as message passing, event triggering, and service calls between software components, and manages tasks such as the life cycle, resource allocation, and scheduling of software components.

[0046] (7) OEM (Original Equipment Manufacturer): This is the manufacturer responsible for the design, manufacture and assembly of the vehicle and is involved in software development.

[0047] (8) Task schedule: In software development, a mechanism for managing and scheduling the execution of tasks. A task schedule can define the execution order, dependencies, and execution time of tasks.

[0048] (9) Arxml file: An XML format file defined in the AUTOSAR standard, used to describe the software architecture, software components, and communication between automotive electronic systems.

[0049] (10) MACL (Media Access Control): Located at the data link layer, the data link layer, as the second layer, serves as a bridge between the physical layer and the network layer. Its core task is to ensure that data transmitted from the network layer can be reliably transmitted between adjacent nodes.

[0050] (11) VOS, the full name of which is Vehicle Operating System.

[0051] (12) CP Arxml, also known as Classic Platform Arxml, is the configuration file of ClassicPlatform in SOA architecture.

[0052] (13) CAN (Controller Area Network) matrix, also known as CAN communication matrix, is an important tool used in the automotive industry to define the CAN communication protocol. It is defined by the vehicle manufacturer. Each node in the vehicle network needs to follow the communication matrix to complete information interaction and sharing.

[0053] (14) DBC (Data Base CAN) communication file: describes the standard format of the CAN communication protocol, including the definitions of CAN messages, signals, nodes, and communication matrices.

[0054] (15) Runnable: A running entity, which is a function in a SWC. Code needs to be added to implement its functionality.

[0055] (16) Interface file: Configuration information file. The Interface file defines a set of method signatures, including method name, parameter list, return type, and possible constants, to achieve interface polymorphism and code reusability.

[0056] Figure 1 It is a collaborative development scenario diagram of the whole vehicle control software provided by the embodiment of the present application. The development kit provider generates a development kit according to the second communication matrix table, the second interface service detailed table and the third interface service detailed table, and provides the development kit to the software integration terminal. The software integration terminal performs software development according to the development kit, the first interface service detailed table and the first communication matrix table to obtain the whole vehicle control software. This embodiment does not limit the type of the whole vehicle control software, which can be motor control software or air conditioning control software, etc. The software integration terminal is, for example, an OEM, and of course it can also be other manufacturers or user terminals. The development kit provider is the end that generates the development kit, which can be a software developer. The collaborative development of the whole vehicle control software provided by this embodiment can be applied to the SOA architecture.

[0057] Next, the collaborative development method of vehicle control software executed by the software integration end is introduced in detail.

[0058] The whole vehicle control software includes multiple services, and the multiple services in the whole vehicle control software are pre-divided into the first part of services and the second part of services. The development kit provider generates a development kit for developing the second part of services in the whole vehicle control software and sends it to the software integration end. The software integration end independently develops the first part of services, and integrates the development with the development kit to obtain the whole vehicle control software. The service in this embodiment represents an independent functional unit. A service can contain other sub-service units, use standard interfaces for communication, and encapsulate internal information into a black box to achieve the reusability of sub-services. The upper-level service can call the sub-service content encapsulated by the lower-level service through the standard interface. Each service content corresponds to one or more implemented software modules, which are called SWCs.

[0059] The developer pre-splits the full communication matrix table required for developing the whole vehicle control software into a first communication matrix table and a second communication matrix table. The first communication matrix table includes the communication information of the first part of the service, and the second communication matrix table includes the communication information of the second part of the service. The developer pre-splits the full interface service detailed table (or API service detailed table) required for developing the whole vehicle control software into a first interface service detailed table, a second interface service detailed table, and a third interface service detailed table. Among them, the first interface service detailed table includes information about the first part of the service, for example, the second interface service detailed table includes information about the independently developed service of the development package provider. The third interface service detailed table includes information about the interactive service between the development package provider and the software integration end. The services involved in the second interface service detailed table and the third service detailed table are the second part of the services.

[0060] See also Figure 2 The embodiment of the present application provides a method for collaborative development of vehicle control software, which is applicable to the scenario where a development kit provider develops vehicle control software. The method is executed by the development kit provider and specifically includes the following steps:

[0061] S110, obtaining a second communication matrix table, a second interface service detailed table, and a third interface service detailed table for developing a second part of services in the vehicle control software.

[0062] After the developer completes the splitting of the interface service detail table and the splitting of the communication matrix table, the developer provides the second communication matrix table, the second interface service detail table and the third interface service detail table to the development kit provider.

[0063] S120, performing network topology development on the second interface service detailed table to obtain a second CP Arxml file; performing network topology development on the third interface service detailed table to obtain a library Arxml file.

[0064] Use the network topology tool to design the network topology with the interface, data type, power mode, power-on and power-off mode of the independent service provided by the development kit recorded in the second interface service detailed table. Generate the second CP Armxl with the interface parameters in the network topology structure. Among them, CP Armxl is a standard format for describing the interface information in the vehicle control software, which defines the name, type, unit, boundary value and other information of the interface.

[0065] Using the network topology tool, the interface of the interactive service, the data type of the interactive service and other information recorded in the third interface service detailed table are used for network topology design to obtain the library Arxml file. Library Arxml refers to the ARXML file library, which is an XML-based file format used to describe the automotive software system in the AUTOSAR standard. It is mainly used to describe system elements such as software components, interfaces, data types, and configuration parameters, thereby helping to define the functions and structures of the system. In this embodiment, the library Arxml file includes the interface information of the interactive service, the second SWC framework information communication information. The communication information can be a signal (Signal) associated with the virtual node. Among them, the second SWC framework information includes the interface information and port information of the second SWC, etc. The virtual node is used to exchange information between ECUs working based on Signal. The second SWC is used to implement the functions of the second part of the service.

[0066] Optionally, the second part of services is divided into large services and small services according to the service scale. The information related to the small service in the third interface service detailed table is used for network topology development to obtain a library Arxml file. The information related to the large service in the third interface service detailed table is used for network topology development to obtain a single board Arxml file (also a library Arxml file), which includes the interface information of the large service.

[0067] Put the library Arxml file into the development package as an interface configuration file.

[0068] S130 , performing architecture design on the second CP Arxml file to obtain a second application layer Arxml file and a second SWCArxml file.

[0069] Architecture design refers to the overall planning and design of the system during the software development process to meet specific requirements and functions. Exemplarily, the architecture design engineer imports the second CP Arxml file into the architecture design tool and performs architecture design through the architecture design tool. In this embodiment, an architecture design project is created in the architecture design tool. Since the communication matrix table and the interface service detailed table are split, the architecture design project is used to perform architecture design for the second SWC serving the second part. Compared with the architecture design of all service SWCs in the prior art, the architecture design project is also split, which can be referred to as architecture design project 2 here. The development package provider only needs to maintain architecture design project 1. Interface design, SWC design, Runnable scheduling design, signal mapping, etc. are performed through architecture design project 2. Runnable scheduling design mainly involves multi-threaded programming, defining thread tasks by implementing the Runnable interface, and designing appropriate scheduling strategies to manage the execution of these threads. Signal mapping is the process of associating signals with specific operations or functions. Signal mapping can realize the reception, processing and response of signals, thereby realizing communication and interaction between different components or systems.

[0070] After the architecture design is completed, export the second application layer Arxml file and the second SWC Arxml file from the architecture design tool. The second application layer Arxml file is the Arxml file of the Flat description of the entire architecture design system, and the Arxml file of the Flat description is the Arxml of the entire application layer, describing the hierarchical relationship of the architecture. The second SWC Arxml file includes the scheduling logic of the port and Runnable.

[0071] S140 , performing behavior modeling on the second SWC Arxml file to obtain application layer code of the second SWC.

[0072] Use a modeling tool to perform behavioral modeling on the second SWC Arxml file and implement the functions of the second SWC at the code level. The modeling tool can be Simulink, etc. In addition to using modeling tools to perform behavioral modeling, behavioral modeling can also be achieved by software engineers writing codes by hand. The obtained code is called the application layer code of the second SWC.

[0073] S150, perform bottom-soft configuration on the second communication matrix table and the second application layer Arxml file to obtain a configuration information file and a configuration code.

[0074] The bottom software configuration mainly focuses on the setting of software components closely related to the hardware, aiming to ensure that the software can correctly interact with the hardware and achieve the expected functions and performance. Exemplarily, the DBC communication file and the second application layer Arxml file in the second communication matrix table are imported into the bottom software configuration tool for bottom software configuration (referred to as bottom software configuration). A bottom software configuration project is created in the bottom software configuration tool. Since the communication matrix table and the interface service detailed table are split, the bottom software configuration project is used to perform bottom software configuration for the second SWC serving the second part. Compared with the bottom software configuration of all service SWCs in the prior art, the bottom software configuration project is also split, which can be referred to as bottom software configuration project 2 here. Based on this, the development kit provider only needs to use the second communication matrix table and the second application layer Arxml file to configure the application layer Runnable in the Task scheduling table. Compared with the prior art, the development kit provider does not need to rely on the input of the software integration end when configuring the bottom software. The bottom software configuration includes: BSW configuration and Task Mapping configuration. Among them, Task Mapping (task matching) mainly involves mapping the Runnable in the SWC design to the task Task of the operating system. This mapping is a key step to ensure that SWC can be correctly executed and scheduled in the operating system. After BSW configuration is completed, standardized system functions and interfaces are generated, making the entire software structure independent of hardware. BSW configuration involves many aspects, including module selection, parameter setting, interface definition, etc., to ensure that SWC can run correctly and efficiently.

[0075] After the bottom software configuration is completed, the configuration information file (ie, Interface file) of the bottom software configuration project 2 is exported and placed in the development kit. After the bottom software configuration, the configuration code is also generated, including: dynamic BSW code, VOS static code, and MACL layer code.

[0076] S160: Integrate the configuration code and the application layer code of the second SWC to obtain a bottom soft link file and a runtime environment RTE header file.

[0077] Integration includes code compilation, linking, and code integration. Through integration, codes of different types and sources are merged together to form a base soft link file and an RTE header file. The base soft link file includes the integrated code, and the RTE header file contains information such as data types and interface definitions required in the RTE generation process.

[0078] S170, generate a development kit from the library Arxml file, configuration information file, bottom soft link file and operating environment RTE header file, and send the development kit to the software integration end so that the software integration end can develop the vehicle control software according to the development kit.

[0079] The development kit provider packages the library Arxml file, configuration information file, bottom soft link file and runtime environment RTE header file into the development kit, and releases the development kit to the software integrator.

[0080] In the embodiment of the present application, the development kit provider obtains the second communication matrix table, the second interface service detailed table and the third interface service detailed table for developing the second part of the service in the vehicle control software, and then performs network topology development, architecture design, behavior modeling, bottom software configuration and integration to obtain a development kit. The development process of the development kit provider can be carried out independently and decoupled from the software integration end.

[0081] See also Figure 3 The embodiment of the present application also provides a method for collaborative development of vehicle control software, which is applicable to the scenario where a development kit provider develops vehicle control software. The method is executed by a software integration end and specifically includes the following steps:

[0082] S210: Obtain a development kit for developing the second part of the service in the vehicle control software.

[0083] The software integration end obtains the development kit from the development kit provider, including: library Arxml file, configuration information file, bottom soft link file and RTE header file. Among them, the library Arxml file includes the interface information of the interactive service, the framework information of the second SWC and the communication information.

[0084] S220: Perform network topology development on the first interface service detailed table to obtain a first CP Arxml file.

[0085] Using the network topology tool, the interface, data type, power mode, power-on and power-off mode, and other information of the first part of the service recorded in the first interface service detailed table are used to design the network topology. The interface parameters in the network topology structure are used to generate the first CP Armxl.

[0086] S230, performing architecture design on the first CP Arxml file and the library Arxml file to obtain a first application layer Arxml file and a first SWC Arxml file.

[0087] Exemplarily, the architecture design engineer imports the first CP Arxml file and the library Arxml file in the architecture design tool. An architecture design project is created in the architecture design tool. Since the communication matrix table and the interface service detail table are split, the architecture design project is used to perform architecture design for the first SWC serving the first part. Compared with the prior art of performing architecture design on all service SWCs, the architecture design project is also split, which can be referred to as architecture design project 1 here. The software integration end only needs to maintain architecture design project 1. Interface design, SWC design, Runnable scheduling design, signal mapping, etc. are performed through architecture design project 1.

[0088] After the architecture design is completed, the first application layer Arxml file and the first SWC Arxml file are exported from the architecture design tool. The first application layer Arxml file is the Arxml file of the Flat description of the entire architecture design system; the second SWC Arxml file includes the scheduling logic of the port and Runnable.

[0089] In this embodiment, the architecture design tool needs to support hiding the internal logic of the first / second SWC and only expose the functions of the service interface API. This SWC that only exposes the API is called a clone SWC. Import the library Arxml file into the architecture design tool, and in the architecture design tool, the second SWC exposes the interface to the outside; perform architecture design on the first CP Arxml file and the interface exposed to the outside by the second SWC to obtain the first application layer Arxml file and the first SWC Arxml file. In this way, when the internal logic of the second SWC changes, it will not affect the exposed interface, nor will it affect the architecture design of the software integration end. The first SWC is used to implement the functions of the first part of the service.

[0090] S240, perform behavior modeling on the first SWC Arxml file to obtain the application layer code of the first SWC, and perform bottom software configuration on the first communication matrix table, the first application layer Arxml file and the configuration information file to obtain the framework code and RTE layer code of the first SWC.

[0091] The first SWC Arxml file is behaviorally modeled using a modeling tool to implement the functions of the first SWC at the code level. The modeling tool may be Simulink, etc. In addition to using a modeling tool to perform behavioral modeling, behavioral modeling may also be implemented by handwriting code by a software engineer, and the resulting code is called the application layer code of the first SWC.

[0092] Then, the DBC communication file, the first application layer Arxml file and the configuration information file in the first communication matrix table are imported into the bottom software configuration tool to perform bottom software configuration (referred to as bottom software configuration), and the bottom software configuration includes: BSW configuration and Task Mapping configuration.

[0093] Exemplarily, a bottom software configuration project is created in the bottom software configuration tool. Since the communication matrix table and the interface service detail table are split, the bottom software configuration project is used to perform bottom software configuration for the first SWC of the first part of the service. Compared with the bottom software configuration of all service SWCs in the prior art, the bottom software configuration project is also split, which can be referred to as bottom software configuration project 1. Based on this, the software integration end only needs to use the first communication matrix table and the first application layer Arxml file, and the engineer using the bottom software configuration tool implements the configuration of Task Mapping in the bottom software configuration project 1 according to the Task scheduling table.

[0094] Optionally, the software integration end verifies and troubleshoots the underlying software configuration project 1. Then, the underlying software configuration project 1 is used to generate the framework code and RTE layer code of the first SWC, the RTE layer code (ie, the dynamic code configured by the software integration end).

[0095] S250, integrating the framework code of the first SWC, the application layer code of the first SWC, the RTE layer code, the bottom soft link file and the RTE header file to obtain the whole vehicle control software.

[0096] Integrate the framework code of the first SWC, the RTE layer code and the application layer code of the first SWC to obtain a static library file. The static library file is integrated and linked with the bottom soft link file and the RTE header file in the development package to obtain the Map (Memory Allocation File, memory mapping file) file, Elf and S19 files. The Map file, Elf and S19 files constitute the vehicle control software. At this point, the development of the first version of the vehicle control software has been completed.

[0097] Compared with the prior art, in this embodiment, for the software integration end, a development kit for developing the second part of the service in the vehicle control software is obtained, and the software development is carried out in combination with the files in the development kit, the first interface service detailed table for developing the first part of the service, and the first communication matrix table, so that the vehicle control software including the first part of the service and the second part of the service can be obtained. This application optimizes the traditional staggered serial development method. The software integration end only needs to rely on the development kit provided by the development kit provider to realize software development, and does not need to return to the development kit provider for development.

[0098] See also Figure 4, the embodiment of the present application provides a collaborative development method for vehicle control software, which is applicable to the case where the internal communication relationship of the first part of the service of the software integration end is changed, and is mainly executed by the software integration end. Figure 4 , this application includes the following operations:

[0099] S310: Obtain a development kit for developing the second part of the service in the vehicle control software.

[0100] S320: Perform network topology development on the first interface service detailed table to obtain a first CP Arxml file.

[0101] S330, performing architecture design on the first CP Arxml file and the library Arxml file to obtain a first application layer Arxml file and a first SWC Arxml file.

[0102] S340, perform behavior modeling on the first SWC Arxml file to obtain the application layer code of the first SWC, and perform bottom software configuration on the first communication matrix table, the first application layer Arxml file and the configuration information file to obtain the framework code and RTE layer code of the first SWC.

[0103] S350, integrating the framework code of the first SWC, the application layer code of the first SWC, the RTE layer code, the bottom soft link file and the RTE header file to obtain the whole vehicle control software.

[0104] S360: In response to the request for adding or deleting the first SWC, and / or the request for changing the interface, and / or the request for changing the port, the first interface service detailed table is updated according to the information of the changed first SWC. Return to S320.

[0105] Exemplarily, if the communication relationship between different services in the same controller changes, and the software integration end has a change request for the first SWC, for example, the first SWC as a whole is added or deleted, the interface elements (including data types and structure elements) are changed, and the Port port is added or deleted, then in response to the addition or deletion request for the first SWC, and / or the interface change request, and / or the port change request, the first interface service detailed table is updated according to the information of the changed first SWC.

[0106] In this embodiment, because the architecture design project, interface service details table and bottom software configuration project have been separated, the software integration end only needs to modify the first interface service details table by itself (including modifying the service interface, data type, etc.), and then use the network topology tool to develop the network topology of the modified first interface service details table, and then use the development kit obtained in S310 to perform subsequent architecture design, behavior modeling, bottom software configuration and integration operations, and finally form a new vehicle control software. In this embodiment, when the internal communication behavior changes, only the software integration end needs to update the first interface service details table, and the development kit provider does not need to generate and generate the development kit again, thereby realizing decoupled development.

[0107] See also Figure 5 The embodiment of the present application provides a method for collaborative development of vehicle control software, which is applicable to the case where the first communication matrix table of the software integration terminal is changed, and is mainly executed by the software integration terminal. Figure 5 , this application includes the following operations:

[0108] S410: After obtaining the vehicle control software, in response to a request to change the first communication matrix table, update the first interface service details table and the first communication matrix table according to the changed CAN signal.

[0109] The vehicle control software is obtained by using any of the above embodiments. After the vehicle control software is obtained, a change request to the first communication matrix table may be generated due to business needs, for example, the CAN matrix in the first communication matrix table may be changed. The information of the changed CAN matrix needs to be updated to the first interface service detailed table and the first communication matrix table. For example, the information of the CAN signal is added / deleted in the first communication matrix table, and the information of the interface mapped by the CAN signal is added / deleted in the first interface service detailed table.

[0110] S420: Perform network topology development on the updated first interface service detailed table to obtain a new first CP Arxml file.

[0111] Since the first interface service details table is updated, the network topology needs to be redeveloped.

[0112] S430: In the architecture design project, update the interface of the target SWC according to the changed CAN signal.

[0113] In the case of a newly added CAN signal, the newly added CAN signal needs to be forwarded to the application layer. For example, in the architecture design project 1, a new CAN signal 1 is added, and an interface to which the CAN signal 1 is mapped is added in the target SWC. The target SWC is used to map the CAN signal to the interface, so as to call the interface to obtain the CAN signal 1.

[0114] In the case of deleting a CAN signal, the CAN signal also needs to be deleted in the application layer. For example, in the architecture design project 1, if the CAN signal 2 is deleted, the interface to which the CAN signal 2 is mapped is deleted in the target SWC.

[0115] S440, perform architecture design on the new first CP Arxml file, the target SWC and the library Arxml file to obtain a new first application layer Arxml file and a new first SWC Arxml file.

[0116] Optionally, in the architecture design project 1, the new first CP Arxml file, the target SWC and the library Arxml file are architecture-designed to obtain a new first application layer Arxml file and a new first SWC Arxml file. The architecture design includes: interface design, SWC design, Runnable scheduling design, signal mapping, etc.

[0117] S450: Perform behavior modeling on the new first SWC Arxml file to obtain the new first SWC application layer code.

[0118] Use modeling tools to perform behavioral modeling on the new first SWC Arxml file and implement the functions of the first SWC at the code level.

[0119] S460, performing bottom software configuration on the updated first communication matrix table, the new first application layer Arxml file and the configuration information file to obtain a new first SWC framework code and a new RTE layer code.

[0120] Since the first communication matrix table and the first application layer Arxml file are updated, the bottom software needs to be reconfigured to obtain the new first SWC framework code and the new RTE layer code. It should be noted that the configuration information file still uses the file in the development package, and there is no need to obtain the development package again.

[0121] S470: Integrate the framework code of the new first SWC, the application layer code of the new first SWC, the new RTE layer code, the bottom soft link file and the new RTE header file to obtain new vehicle control software.

[0122] In this embodiment, if the first communication matrix table is changed, the software integration end needs to update the first interface service details table and the first communication matrix table, but there is no need to re-acquire the development package. That is, the previously acquired development package is used to perform network topology development, architecture design, bottom software configuration and integration to obtain a new vehicle control software.

[0123] See also Figure 6The embodiment of the present application provides a method for collaborative development of vehicle control software, which is applicable to the case where the internal logic of the first SWC of the software integration end is changed, and is mainly executed by the software integration end. Figure 6 , this application includes the following operations:

[0124] S510: Obtain a development kit for developing the second part of the service in the vehicle control software.

[0125] S520: Perform network topology development on the first interface service detailed table to obtain a first CP Arxml file.

[0126] S530 , performing architecture design on the first CP Arxml file and the library Arxml file to obtain a first application layer Arxml file and a first SWC Arxml file.

[0127] S540, perform behavior modeling on the first SWC Arxml file to obtain the application layer code of the first SWC, and perform bottom software configuration on the first communication matrix table, the first application layer Arxml file and the configuration information file to obtain the framework code and RTE layer code of the first SWC.

[0128] S550: Integrate the framework code of the first SWC, the application layer code of the first SWC, the RTE layer code, the bottom soft link file and the RTE header file to obtain the vehicle control software.

[0129] For S510~~S550, please refer to the records of S210~S250 and will not be repeated here.

[0130] S560 : In response to the change request for the internal logic of the first SWC, update the architecture design project according to the changed internal logic.

[0131] S570, using the updated architecture design project, perform architecture design on the first CP Arxml file and the library Arxml file. Return to S540.

[0132] In the decoupled development mode, because the architecture design project and the bottom software configuration project have been split, the software integration end only needs to change its own architecture design project 1, that is, update the architecture design project according to the changed internal logic. Then, using the updated architecture design project, the first CP Arxml file and the library Arxml file are architected to obtain a new first application layer Arxml file and a first SWC Arxml file. Next, behavioral modeling, bottom software configuration and integration are performed. During the bottom software configuration and integration, the development kit in S510 is still used. The development kit provider does not respond to changes in the internal logic of the first SWC and does not need to provide a new development kit. The software integration end only needs to redevelop according to the internal logic of the first SWC. Compared with the existing staggered serial mode, the development efficiency is improved.

[0133] See also Figure 7 The embodiment of the present application provides a collaborative development method for vehicle control software, which is applicable to the case where the internal logic of the second SWC of the development kit provider is changed, and is mainly executed by the software integration end and the development kit provider end. Figure 7 , this application includes the following operations:

[0134] S610: In response to the request to change the internal logic of the second SWC, the development kit provider generates a new development kit according to the changed internal logic of the SWC and the internal logic of the unchanged SWC.

[0135] After the development kit provider has provided the development kit (including the original library Arxml file, the original configuration information file, the original bottom soft link file and the original RTE header file), and the software integration end uses the development kit to develop the complete vehicle control software. Due to business needs, the internal logic of the second SWC needs to be changed, then the architecture of the second CP Arxml file is redesigned, and the behavior modeling of the second SWC Arxml file is performed; the bottom soft configuration of the second communication matrix table and the second application layer Arxml file is performed to obtain a new configuration information file and a new configuration code; the new configuration code is integrated with the application layer code of the second SWC to obtain a new bottom soft link file and RTE header file; the new bottom soft link file, the original library Arxml file, the new configuration information file and the original RTE header file are used to generate a new development kit.

[0136] S620: The development kit provider sends the new development kit to the software integrator.

[0137] S630: The software integration end obtains a new development kit from the providing end in response to the request to change the internal logic of the second SWC.

[0138] Get the new bottom soft link file and new configuration information file from the new development package.

[0139] S640: The software integration end performs bottom software configuration on the new configuration information file to obtain a new framework code and a new RTE layer code of the first SWC.

[0140] Since the configuration information file is updated, the bottom software configuration needs to be re-performed in the bottom software configuration project 1 according to the new configuration information file.

[0141] S650, the software integration end integrates the new framework code of the SWC, the application layer code of the first SWC, the new RTE layer code, the new bottom soft link file and the RTE header file to obtain the vehicle control software.

[0142] In this embodiment, the development kit provider has a second interface service detailed table and a third interface service detailed table, which not only supports the development of independent services, but also supports the development of interactive services with the software integration end. The interface of the second SWC obtained by the development kit provider when the software is first developed is full, and the meaning of full includes: 1. The interface of the second SWC obtained by the development kit provider when the software is first developed will not change with the subsequent changes in the internal logic of the second SWC; 2. Based on the decoupled development mode in this embodiment, the development kit provider develops the interface of the SWC for the service according to the second interface service detailed table and the third interface service detailed table. In this version, the interface of these interactive service SWCs is unchanged. The second SWC in this embodiment is a clone SWC, which only exposes the interface to the outside. Therefore, on the basis of the full second SWC interface, even if the internal logic of the second SWC changes, the software integration end will not have any interface changes, and will not affect the network topology and architecture design of the software integration end. It only needs to use a new configuration information file for bottom software configuration and integration.

[0143] like Figure 8 As shown, this embodiment provides an electronic device, which can be used as a software integration terminal or a development kit providing terminal. The electronic device integrates a network topology tool, an architecture design tool, a bottom software configuration tool, and a code compilation and integration tool.

[0144] The electronic device includes: at least one processor; and a memory communicatively connected to the at least one processor.

[0145] The memory stores instructions that can be executed by at least one processor, and the instructions are executed by at least one processor so that at least one processor can execute the above-mentioned collaborative development method of vehicle control software. At least one processor in the electronic device can execute the above-mentioned method, and thus has at least the same advantages as the above-mentioned method.

[0146] Optionally, the electronic device also includes interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. The various components are connected to each other using different buses and can be installed on a common mainboard or installed in other ways as needed. The processor can process instructions executed in the electronic device, including instructions stored in or on a memory to display graphical information of a GUI (Graphical User Interface) on an external input / output device (such as a display device coupled to an interface). In other embodiments, if necessary, multiple processors can be used together with multiple memories, and / or multiple buses can be used together with multiple memories. Similarly, multiple electronic devices can be connected (for example, as a server array, a group of blade servers, or a multi-processor system), and each device provides some necessary operations. Figure 8 A processor 301 is taken as an example.

[0147] The memory 302, as a computer-readable storage medium, can be used to store software programs, computer executable programs and modules, such as program instructions / modules corresponding to the collaborative development method of the whole vehicle control software in the embodiment of the present invention, as well as the first interface service detailed table, the second interface service detailed table, the third interface service detailed table, the first communication matrix table and the second communication matrix table. The processor 301 executes various functional applications and data processing of the device by running the software programs, instructions and modules stored in the memory 302, that is, realizes the above-mentioned collaborative development method of the whole vehicle control software.

[0148] The memory 302 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system and at least one application required for a function; the data storage area may store data created according to the use of the terminal, etc. In addition, the memory 302 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 302 may further include a memory remotely arranged relative to the processor 301, and these remote memories may be connected to the device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0149] The electronic device may further include: an input device 303 and an output device 304. The processor 301, the memory 302, the input device 303 and the output device 304 may be connected via a bus or other means. Figure 8 The example of connecting through bus is taken in the following.

[0150] The input device 303 can receive input digital or character information, and the output device 304 can include a display device, an auxiliary lighting device (e.g., LED), and a tactile feedback device (e.g., a vibration motor), etc. The display device can include, but is not limited to, a liquid crystal display (LCD), a light emitting diode (LED) display, and a plasma display. In some embodiments, the display device can be a touch screen.

[0151] The embodiment of the present application also provides a collaborative development system for vehicle control software, including: a development kit provider and a software integration terminal. The development kit provider and the software integration terminal collaboratively develop the vehicle control software. The specific operations and technical effects of the development kit provider and the software integration terminal are described in the above embodiments and will not be repeated here.

[0152] It should be noted that the terms used in this application are only for describing specific embodiments, rather than limiting the scope of this application. As shown in the specification of this application, unless the context clearly indicates an exception, the words "one", "a", "a kind of" and / or "the" do not specifically refer to the singular, but may also include the plural. The terms "include", "comprise" or any other variant thereof are intended to cover non-exclusive inclusion, so that the process, method or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method or device. In the absence of more restrictions, the elements defined by the sentence "include one..." do not exclude the presence of other identical elements in the process, method or device including the elements.

[0153] The term "and / or" herein only describes an association relationship, indicating that three relationships may exist. For example, A and / or B may represent the following three situations: A exists alone, A and B exist at the same time, and B exists alone. In addition, the term "at least one" herein represents any combination of at least two of any one or more of a plurality of. For example, including at least one of A, B, and C may represent including any one or more elements selected from the set consisting of A, B, and C.

[0154] The terms "first", "second", etc. are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first", "second", etc. may explicitly or implicitly include one or more of the features. In the description of the invention of this application, unless otherwise specified, the meaning of "plurality" is two or more.

[0155] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the technical solutions of the embodiments of the present application.

Claims

1. A collaborative development method for vehicle control software, characterized in that: The method is executed by a software integration terminal, and the method includes: Obtain a development kit for developing the second part of the service in the vehicle control software; the development kit includes: a library Arxml file, a configuration information file, a bottom soft link file and an RTE header file; the development kit is provided by a development kit provider; Performing network topology development on the first interface service detailed table to obtain a first CP Arxml file; the first interface service detailed table includes information on the first part of services in the vehicle control software; Performing architecture design on the first CP Arxml file and the library Arxml file to obtain a first application layer Arxml file and a first SWC Arxml file; Performing behavior modeling on the first SWC Arxml file to obtain the application layer code of the first SWC, and performing bottom software configuration on the first communication matrix table, the first application layer Arxml file and the configuration information file to obtain the framework code and RTE layer code of the first SWC; the first communication matrix table includes the communication information of the first part of the service in the vehicle control software; The framework code of the first SWC, the application layer code of the first SWC, the RTE layer code, the bottom soft link file and the RTE header file are integrated to obtain the whole vehicle control software.

2. The method according to claim 1, characterized in that The library Arxml file includes interface information of the interactive service, framework information of the second SWC and communication information.

3. The method according to claim 2, characterized in that Performing architecture design on the first CP Arxml file and the library Arxml file to obtain a first application layer Arxml file and a first SWC Arxml file, including: Importing the library Arxml file into an architecture design tool; in the architecture design tool, the second SWC exposes an interface externally; The first CP Arxml file and the interface exposed to the outside of the second SWC are architecturally designed to obtain a first application layer Arxml file and a first SWC Arxml file.

4. The method according to claim 1, characterized in that: After obtaining the vehicle control software, it also includes: In response to a request to add or delete a first SWC, and / or an interface change request, and / or a port change request, updating the first interface service detailed table according to information of the changed first SWC; Return to perform the operation of developing the network topology for the first interface service detail table, and continue to perform subsequent operations.

5. The method according to claim 1, characterized in that After obtaining the vehicle control software, it also includes: In response to a request for changing the first communication matrix table, updating the first interface service details table and the first communication matrix table according to the changed CAN signal; Perform network topology development on the updated first interface service detailed table to obtain a new first CP Arxml file; In the architecture design project, an interface of a target SWC is updated according to the changed CAN signal, wherein the target SWC is used to map the CAN signal to the interface; Performing architecture design on the new first CP Arxml file, the target SWC and the library Arxml file to obtain a new first application layer Arxml file and a new first SWC Arxml file; Performing behavior modeling on the new first SWC Arxml file to obtain the application layer code of the new first SWC; Performing bottom-soft configuration on the updated first communication matrix table, the new first application layer Arxml file and the configuration information file to obtain a new first SWC framework code and a new RTE layer code; The framework code of the new first SWC, the application layer code of the new first SWC, the new RTE layer code, the bottom soft link file and the new RTE header file are integrated to obtain new vehicle control software.

6. The method according to claim 1, characterized in that After obtaining the vehicle control software, the first process and / or the second process are also included: First process: in response to a request to change the internal logic of the first SWC, updating the architecture design project according to the changed internal logic; using the updated architecture design project to perform architecture design on the first CP Arxml file and the library Arxml file; Return to perform the behavior modeling operation on the first SWC Arxml file, and continue to perform subsequent operations; The second process: in response to a request to change the internal logic of the second SWC, a new development kit is obtained from the development kit provider; the new development kit includes a new bottom soft link file and a new configuration information file; the bottom soft configuration is performed on the new configuration information file to obtain a new framework code and a new RTE layer code of the SWC; the new framework code of the first SWC, the application layer code of the first SWC, the new RTE layer code, the new bottom soft link file and the RTE header file are integrated to obtain the vehicle control software; wherein the second SWC is used to implement the functions of the second part of the service.

7. A collaborative development method for vehicle control software, characterized in that: include: Obtaining a second communication matrix table, a second interface service detailed table and a third interface service detailed table for developing the second part of the service in the vehicle control software; wherein the third interface service detailed table includes information on interactive services between the local end and the software integration end, and the second interface service detailed table includes information on independent services of the local end; Performing network topology development on the second interface service detailed table to obtain a second CP Arxml file; performing network topology development on the third interface service detailed table to obtain a library Arxml file; Performing architecture design on the second CP Arxml file to obtain a second application layer Arxml file and a second SWC Arxml file; Performing behavior modeling on the second SWC Arxml file to obtain the application layer code of the second SWC; Performing bottom-soft configuration on the second communication matrix table and the second application layer Arxml file to obtain a configuration information file and a configuration code; Integrate the configuration code with the application layer code of the second SWC to obtain a bottom soft link file and a runtime environment RTE header file; The library Arxml file, configuration information file, bottom soft link file and operating environment RTE header file are used to generate a development kit, and the development kit is sent to the software integration end so that the software integration end can develop the whole vehicle control software according to the development kit.

8. The method according to claim 7, characterized in that After the library Arxml file, the configuration Interface information file, the bottom soft link file and the operating environment RTE header file are generated into a development package, it also includes: In response to a request for changing the internal logic of the SWC, a new development package is generated according to the changed internal logic of the SWC and the internal logic of the SWC that remains unchanged, wherein the new development package includes a new bottom soft link file and a new project configuration file; Send the new development kit to the software integrator.

9. An electronic device, characterized in that: include: processor; at least one memory; The processor executes the collaborative development method of vehicle control software as described in any one of claims 1 to 8 by calling the program or instruction stored in the at least one memory.

10. A collaborative development system for vehicle control software, characterized in that: include: Development kit provider and software integrator; The software integration end is used to execute the collaborative development method of the whole vehicle control software described in any one of claims 1-6, and the development kit providing end is used to execute the collaborative development method of the whole vehicle control software described in claim 7 or 8.

Citation Information

Patent Citations

  • A2L file splitting design method and system, medium and equipment

    CN115774440A

  • Method and device for adaptive automobile open system architecture to adapt to complex application software

    CN116560645A