Development method and apparatus based on automotive open system architecture, and storage medium

Abstract

The present application relates to the field of vehicles. Provided are a development method and apparatus based on an AUTOSAR, and a storage medium. The method comprises: in response to a first operation, obtaining a secondary baseline configuration, wherein the first operation is used for importing a primary baseline configuration into a user configuration project, the primary baseline configuration comprises a primary Bsw configuration and a primary AppL configuration, and the secondary baseline configuration comprises a secondary Bsw configuration and a secondary AppL configuration; and in response to a second operation, obtaining a secondary customized configuration, wherein the second operation is used for newly adding a Bsw configuration and / or an AppL configuration on the basis of the secondary baseline configuration, the secondary customized configuration comprises a secondary Bsw customized configuration and / or a secondary AppL customized configuration, the primary baseline configuration and the secondary baseline configuration are public configurations, and the secondary customized configuration is a user configuration. By means of hierarchical development, the workload of iterative development can be reduced, thereby improving the development efficiency.

Description

A development method, apparatus, and storage medium based on an automotive open system architecture.

[0001] This application claims priority to Chinese Patent Application No. 202411569884.2, filed on November 4, 2024, entitled "A Development Method, Apparatus and Storage Medium Based on an Open System Architecture for Automobiles", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of vehicles, and more particularly to a development method, apparatus and storage medium based on the automotive open system architecture (AUTOSAR). Background Technology

[0003] With the rapid development of the automotive industry, intelligent driving technology has gradually become a focus of attention for vehicle manufacturers and consumers. Intelligent driving systems integrate various sensors, controllers, and actuators to achieve automatic control and assisted driving functions. In intelligent driving systems, the core component for intelligent driving in the entire vehicle typically uses a microcontroller unit (MCU) as a functional safety subsystem. The selection and development of the MCU chip directly affects the performance and safety of the intelligent driving system.

[0004] To address the complex demands of intelligent driving, the industry commonly develops MCUs based on AUTOSAR. However, with the increasing variety of vehicle models, the development workload also increases, leading to longer development cycles and consequently, lower development efficiency. Summary of the Invention

[0005] This application provides an AUTOSAR-based development method, apparatus, and storage medium, aiming to reduce development workload and improve development efficiency.

[0006] In a first aspect, this application provides an AUTOSAR-based development method. The steps of this method can be executed by a development device, or by a component (such as a chip, chip system, etc.) configured in the development device, or by a logic module or software capable of implementing all or part of the functions of the development device. This application does not limit the scope of the method.

[0007] For example, the method includes: in response to a first operation, obtaining a secondary baseline configuration, the first operation being used to import a primary baseline configuration into a user configuration project, the primary baseline configuration including a primary basic software layer (BSW) configuration and a primary application software layer (AppL) configuration, the secondary baseline configuration including a secondary BSW configuration and a secondary AppL configuration; in response to a second operation, obtaining a secondary customized configuration, the second operation being used to add a BSW configuration and / or an AppL configuration based on the secondary baseline configuration, the secondary customized configuration including a secondary BSW customized configuration and / or a secondary AppL customized configuration, the secondary BSW customized configuration being the newly added BSW configuration, the secondary AppL customized configuration being the newly added AppL configuration; wherein, the primary baseline configuration and the secondary baseline configuration are common configurations, and the secondary customized configuration is a user configuration.

[0008] Understandably, in one possible implementation, the aforementioned secondary baseline configuration and secondary customized configuration can be used for vehicle development; that is, iterative development can be carried out based on the secondary baseline configuration and secondary customized configuration, meaning that both the secondary baseline configuration and the secondary customized configuration can be iteratively updated. In another possible implementation, the secondary customized configuration can be used for vehicle development; that is, after obtaining the secondary customized configuration based on the secondary baseline configuration, subsequent development can only be carried out based on this secondary customized configuration, without updating the secondary baseline configuration.

[0009] Based on the above technical solution, the first-level baseline configuration and the second-level baseline configuration are common configurations, while the second-level customized configuration is a user configuration. Through hierarchical development (or layered development), not only can the workload of iterative development be reduced and development efficiency improved, but the quality of modifications to common issues can also be guaranteed without affecting the customer's customized configuration.

[0010] In conjunction with the first aspect, in some possible implementations, the above method also includes: obtaining the updated content of the primary baseline configuration.

[0011] Understandably, users with permission to modify the primary baseline configuration can perform a third operation—that is, publish a new version of the primary baseline configuration—through the user interface provided by the AUTOSAR toolchain. Correspondingly, the development apparatus can respond to this third operation by overwriting the old version of the primary baseline configuration with the new one, thus completing the update of the primary baseline configuration.

[0012] After the release of the new version of the primary baseline configuration, the development device can obtain the updated content of the primary baseline configuration, that is, obtain the content of the new version of the primary baseline configuration.

[0013] In conjunction with the first aspect, in some possible implementations, the above method further includes: updating the second-level Bsw configuration based on the first-level Bsw configuration in the updated content of the obtained first-level baseline configuration.

[0014] When modifying common issues through the primary baseline configuration, you only need to modify the primary baseline configuration and release the new version of the primary baseline configuration. When updating the primary baseline configuration, it is not necessary to update the secondary baseline configuration for each customer. Instead, the secondary baseline configuration is updated based on the new version of the primary baseline configuration when the customer needs it. In this way, not only can the workload of iterative development be reduced and development efficiency improved, but the quality of modification of common issues can also be guaranteed without affecting the customer's customized configuration.

[0015] In conjunction with the first aspect, in some possible implementations, updating the second-level Bsw configuration based on the first-level Bsw configuration in the updated content of the obtained first-level baseline configuration includes: for the same Bsw configuration parameter, if the first content and the second content are the same, or if the first content and the third content are the same, overwriting the content of the second-level Bsw configuration with the first-level Bsw configuration in the updated content of the obtained first-level baseline configuration to obtain the updated second-level Bsw configuration; wherein, the first content is the content of the first-level Bsw configuration in the updated content of the obtained first-level baseline configuration, the second content is the content of the second-level Bsw configuration, the third content is the content of the customized configuration of the second-level Bsw, and the first content, the second content, and the third content are the values ​​of the same Bsw configuration parameter.

[0016] In conjunction with the first aspect, in some possible implementations, for the same Bsw configuration parameter, if the first content differs from the second content, and if the first content differs from the third content, the user is prompted to take action.

[0017] For example, in one possible implementation, for the same Bsw configuration parameter, if the first content differs from the second content and the first content differs from the third content, the development device can overwrite the value of the second-level Bsw configuration with the value of the first-level Bsw configuration in the new version of the first-level baseline configuration, and remind the user that the first content differs from the second content and the third content. In some possible implementations, the user can also be prompted with the following information: what is the first content, what is the second content, and what is the third content? This application does not limit this aspect.

[0018] In another possible implementation, for the same BSW configuration parameter, if the first content differs from the second content and also differs from the third content, the development device can first prompt the user that the first content differs from the second content and also differs from the third content; or, it can prompt the user that the first content differs from the second content and also differs from the third content, specifying what the first content, the second content, and the third content are. Then, based on the user's actions, it determines whether to overwrite the second content with the first content.

[0019] In conjunction with the first aspect, in some possible implementations, the method further includes: in response to a fourth operation, restoring the secondary Bsw custom configuration to the secondary Bsw configuration, the fourth operation being used to cancel the secondary Bsw custom configuration.

[0020] Understandably, the priority of the secondary BSW custom configuration is higher than that of the secondary BSW configuration. That is, if the value of the same BSW configuration parameter differs between the secondary BSW custom configuration and the secondary BSW configuration, the value in the secondary BSW custom configuration takes precedence. Providing users with the option to revert from the secondary BSW custom configuration to the secondary BSW configuration allows for quick removal of any suppression of the secondary BSW configuration parameter by the secondary BSW configuration parameter.

[0021] In conjunction with the first aspect, in some possible implementations, the method further includes: updating the second-level AppL configuration based on the first-level AppL configuration in the updated content of the obtained first-level baseline configuration.

[0022] In conjunction with the first aspect, in some possible implementations, updating the second-level AppL configuration based on the first-level AppL configuration in the updated content of the obtained first-level baseline configuration includes: overwriting the second-level AppL configuration with the first-level AppL configuration in the updated content of the obtained first-level baseline configuration to obtain the updated second-level AppL configuration; and reconnecting the interface of the software component set in the user configuration project based on the updated second-level AppL configuration.

[0023] In conjunction with the first aspect, in some possible implementations, the method further includes: in response to the fifth operation, using the secondary baseline configuration and the secondary custom configuration as the baseline configuration for the next level.

[0024] It supports further layered development of secondary configurations, allowing for more flexible layered (or hierarchical) division of labor and iterative development.

[0025] In conjunction with the first aspect, in some possible implementations, the method further includes: displaying the secondary baseline configuration and the secondary custom configuration, wherein the secondary baseline configuration and the secondary custom configuration are displayed in different ways.

[0026] Alternatively, one possible display method is that the background color of the secondary custom configuration is different from the background color of the secondary baseline configuration.

[0027] Alternatively, another possible implementation is that the labels for the second-level custom configuration and the second-level baseline configuration are different.

[0028] Alternatively, another possible implementation is that the second-level custom configuration can have labels, while the second-level baseline configuration can be unlabeled.

[0029] Displaying the secondary baseline configuration and the secondary custom configuration in different ways makes it easier for users to quickly distinguish between them, and also makes it easier for users to compare the secondary custom configuration and the secondary baseline configuration, quickly identifying the differences between them.

[0030] Secondly, this application provides a development apparatus comprising execution steps for performing the first aspect and any possible implementation thereof. The apparatus includes corresponding modules for performing the methods described above. These modules can be implemented in software and / or hardware.

[0031] Thirdly, this application provides a development apparatus including a processor. The processor is coupled to a memory and can be used to execute a program in the memory to implement the execution steps in the first aspect and any possible implementation thereof.

[0032] Optionally, the development apparatus also includes a memory.

[0033] Optionally, the development device also includes a communication interface, to which the processor is coupled.

[0034] Fourthly, this application provides a chip system including at least one processor for supporting the implementation of the functions involved in the first aspect and any possible implementation of the first aspect, such as receiving or processing data and / or instruction information involved in the above methods.

[0035] In one possible design, the chip system also includes a memory for storing program instructions and data, which may be located within or outside the processor.

[0036] The chip system can consist of chips or include chips and other discrete components.

[0037] Fifthly, this application provides a computer-readable storage medium storing a program (also referred to as code or instructions) that, when run by a processor, causes the methods in the first aspect and any possible implementation thereof to be executed.

[0038] Sixthly, this application provides a computer program product comprising: a computer program (also referred to as code or instructions) that, when run, causes the methods in the first aspect and any possible implementation thereof to be executed.

[0039] It should be understood that the second to sixth aspects of this application correspond to the technical solutions of the first aspect of this application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation are similar, and will not be repeated here. Attached Figure Description

[0040] Figure 1 is a schematic block diagram of AUTOSAR;

[0041] Figure 2 is a schematic diagram of the interface connections between software components in AUTOSAR and the mapping of the relationship between software components and system signals;

[0042] Figure 3 is a schematic diagram of configuring various system stack parameters in AUTOSAR;

[0043] Figure 4 is a schematic flowchart of the AUTOSAR-based development method provided in the embodiments of this application;

[0044] Figure 5 is a schematic diagram of the secondary baseline configuration and the customer's customized configuration obtained based on the primary baseline configuration;

[0045] Figure 6 is a comparative diagram before and after using the method provided in the embodiments of this application;

[0046] Figure 7 is a comparative diagram of the interface connections of the software component set before and after the Level 1 AppL configuration update;

[0047] Figure 8 is a schematic diagram of the interface connection between the secondary AppL configuration and the software component set in the secondary AppL custom configuration after the secondary AppL configuration is updated;

[0048] Figure 9 is a schematic diagram of the mapping relationship between software components and system signals;

[0049] Figure 10 is another schematic flowchart of the AUTOSAR-based development method provided in the embodiments of this application;

[0050] Figure 11 is a schematic block diagram of the development apparatus provided in an embodiment of this application;

[0051] Figure 12 is another schematic block diagram of the development apparatus provided in an embodiment of this application. Detailed Implementation

[0052] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0053] First, in this application, the terms “comprising” and “having” and any variations thereof are intended to cover non-exclusive inclusion, for example, an apparatus, system, product or device that includes a series of modules, units or units is not necessarily limited to those modules, units or units that are explicitly listed, but may include other modules, units or units that are not explicitly listed or that are inherent to such apparatus, system, product or device.

[0054] Second, in this application, the words "exemplarily" and "for example" are used to indicate that something is being described as an example, illustration, or illustration. Any embodiment or design that is described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of words such as "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0055] Third, in this application, "when," "under the circumstances," "if," and "if" all refer to the device making a corresponding action under certain objective circumstances, and are not time-limited, nor do they require the device to make a judgment when it is implemented, nor do they imply any other limitations.

[0056] Fourth, in this application, the terms "first" and "second" are used to distinguish identical or similar items with substantially the same function and effect. For example, the first operation and the second operation are used to distinguish different operations, but do not limit their order. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that the terms "first" and "second" do not necessarily imply that they are different.

[0057] Fifth, in this application, "preset" can be understood as predefined, defined, pre-defined, stored, pre-stored, pre-negotiated, or pre-configured, etc.

[0058] Sixth, in this application, "at least one (kind, type)" refers to one (kind, type) or multiple (kinds, types). "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone, where A and B can be singular or plural. The character " / " generally indicates an "or" relationship between the preceding and following related objects, but it does not exclude the possibility of indicating an "and" relationship. The specific meaning can be understood in conjunction with the context.

[0059] Seventh, in this application, information C is used to determine information D, including both determining information D based solely on information C and determining it based on information C and other information. Furthermore, information C can also be used to determine information D indirectly, for example, in the case where information D is determined based on information E, and information E is determined based on information C.

[0060] To facilitate understanding of the embodiments of this application, some technical terms or vocabulary involved in this application will be briefly explained below.

[0061] 1. AUTOSAR: An open and standardized software architecture designed to improve the reusability, scalability and interoperability of vehicle electronic systems.

[0062] 2. AUTOSAR Toolchain: This is a collection of software development tools that support the AUTOSAR standard, used for designing, configuring, building, and validating AUTOSAR systems. Users can complete feature development simply by modifying configuration options, effectively reducing the difficulty of software development.

[0063] 3. Configuration Project: This can refer to the project that carries the configuration of AUTOSAR functions.

[0064] 4. User configuration project: This can refer to a project that allows users to modify the AUTOSAR function configuration according to their own development needs.

[0065] 5. System Stack: This refers to a combination of multiple modules responsible for a system's functions. For example, the communication stack is responsible for data transmission and network management between electronic control units (ECUs); the memory stack is responsible for managing the ECU's memory resources, which may include electrically erasable programmable read-only memory (EEPROM), flash memory, and random access memory (RAM), and can provide standardized interfaces for memory read and write operations.

[0066] With the rapid development of the automotive industry, intelligent driving technology has gradually become a focus of attention for vehicle manufacturers and consumers. Intelligent driving systems integrate various sensors, controllers, and actuators to achieve automatic control and assisted driving functions. In intelligent driving systems, the core intelligent driving component typically uses an MCU (Microcontroller Unit) as a functional safety subsystem. The selection and development of the MCU chip directly affects the performance and safety of the intelligent driving system.

[0067] To address the complex demands of intelligent driving, the industry commonly develops MCUs based on AUTOSAR. AUTOSAR is a standard ECU software framework jointly initiated by major OEMs and core suppliers. This framework encapsulates and layers the underlying hardware, allowing upper-layer applications to be less aware of changes in the underlying hardware and shortening the development cycle for customized vehicles. However, with the increasing variety of vehicle models, the development workload also increases, leading to a longer development cycle and persistent issues of low development efficiency.

[0068] To address the aforementioned issues, this application provides an AUTOSAR-based development method that divides the configuration project into two levels: primary configuration and secondary configuration. Primary configuration can provide various platform-based services (e.g., primary configuration may include a baseline configuration implementing all functionalities); secondary configuration includes secondary baseline configuration and secondary customized configuration. The secondary baseline configuration is derived from the primary baseline configuration, and each customer's secondary customized configuration is obtained based on the secondary baseline configuration. Through hierarchical development (or layered development), not only can the workload of iterative development be reduced and development efficiency improved, but the quality of modifications to common issues can also be guaranteed without affecting the customer's customized configuration.

[0069] To facilitate a better understanding of the AUTOSAR-based development method provided in this application, a brief introduction to AUTOSAR will be given below with reference to Figures 1 to 3.

[0070] Figure 1 is a schematic block diagram of AUTOSAR.

[0071] As shown in Figure 1, AUTOSAR can include AppL, real-time runtime environment (Rte) (also abbreviated as RTE) and Bsw.

[0072] AppL can be used to record the interaction relationships between various software components, such as interface connections and task scheduling frequency settings. Rte can be used to isolate AppL and Bsw, and automatically allocate corresponding resources according to the upper and lower layers (i.e., AppL and Bsw). This layer (i.e., Rte) is generally automatically generated by AUTOSAR. Bsw can carry encapsulated various system stack configurations, such as communication-related configurations and storage-related configurations.

[0073] Additionally, as not shown in Figure 1, the Bsw can connect to the Hardware Abstraction Layer (Hardware).

[0074] Figure 2 is a schematic diagram of the interface connections between software components in AUTOSAR and the mapping of the relationship between software components and system signals.

[0075] As shown in Figure 2, AppL can be used to record the interaction relationships between various software components, such as interface connections between software components and the mapping between software components and system signals. Multiple software components can form a software component set. For example, software component 1 and software component 2 can be combined into a software component set. Within this set, software component 1 and software component 2 can be connected through interfaces. Software component 1 and software component 3 can also be connected through interfaces. Software component 2 can be associated with system signals, and software component 3 can also be associated with system signals.

[0076] Figure 3 is a schematic diagram of configuring various system stack parameters in AUTOSAR.

[0077] As shown in Figure 3, various system stack parameters (which can be simply referred to as parameters or parameter items in this application) can be configured in AUTOSAR, such as communication-related configurations and storage-related configurations. As an example and not a limitation, Figure 3 shows the following modules included in the communication stack: Controller Area Network (CAN), CAN Interface Layer (CANIF), Protocol Data Unit (PDU) Router (PDUR), and Communication (COM). Taking CANIF as an example, system stack parameters can be configured for CANIF-related messages. Figure 3 shows several system stack parameters and configuration contents (e.g., values) for a message named "Driver_Controller Area Network 11_Rx (Power_Can11_Rx)". For example, the message identifier (ID) of the message "Power_Can11_Rx" can be configured as "0x101", the message length as "64", length detection checked, and custom period detection unchecked.

[0078] The following will describe in detail, with reference to the accompanying drawings, an AUTOSAR-based development method provided in the embodiments of this application.

[0079] Figure 4 is a schematic flowchart of the AUTOSAR-based development method provided in the embodiments of this application.

[0080] The method 400 shown in Figure 4 may include steps 410 and 420.

[0081] The steps of this method can be executed by a development device, or by a component (such as a chip, chip system, etc.) configured in the development device, or by a logic module or software capable of implementing all or part of the functions of the development device; this application does not limit this. The following describes in detail each step of method 400 using the example of method 400 being executed by a development device.

[0082] It is understood that the development apparatus in this application is equipped with the AUTOSAR toolchain (or, it can be understood that the development apparatus in this application is implemented based on the AUTOSAR toolchain) and is capable of implementing the AUTOSAR-based development method provided in the embodiments of this application.

[0083] In step 410, in response to the first operation, a secondary baseline configuration is obtained.

[0084] The first operation imports the primary baseline configuration into the user's (or client's) configuration project; that is, it merges (pulls) the primary baseline configuration into the user's configuration project. The primary baseline configuration may include a primary BSW configuration and a primary AppL configuration. The secondary baseline configuration may include a secondary BSW configuration and a secondary AppL configuration.

[0085] Baseline configuration can be understood as public configuration, or in other words, the first-level baseline configuration and the second-level baseline configuration are public configurations, while the second-level customized configuration is a user configuration.

[0086] It is understandable that the AUTOSAR toolchain is a type of development system. The AUTOSAR toolchain can provide a user interface, and users can operate on the user interface provided by the AUTOSAR toolchain (the development device is equipped with the AUTOSAR toolchain, that is, users can operate on the development device).

[0087] For example, at the start of development, the user can perform an initial operation on the user interface provided by the AUTOSAR toolchain to import the primary baseline configuration into the user configuration project. Correspondingly, the development device can respond to the user's initial operation by importing the primary baseline configuration into the user configuration project, or in other words, copying the primary baseline configuration into the user configuration project to obtain the secondary baseline configuration. It is understood that the content of the secondary baseline configuration is the same as that of the primary baseline configuration. More specifically, for the same Bsw configuration parameter, the value of the secondary Bsw configuration parameter is the same as that of the primary Bsw configuration parameter; and for the AppL configuration, the set of software components included in the secondary AppL configuration, the interface connections between software components, and the mapping of relationships between software components and system signals are the same as those in the primary AppL configuration.

[0088] In step 420, in response to the second operation, a second-level customized configuration is obtained.

[0089] Specifically, the second operation is used to add a Bsw configuration and / or an AppL configuration based on the secondary baseline configuration. More specifically, the second operation can be used to add a Bsw configuration based on the secondary baseline configuration, or, the second operation can be used to add an AppL configuration based on the secondary baseline configuration, or, the second operation can be used to add both a Bsw configuration and an AppL configuration based on the secondary baseline configuration.

[0090] The secondary customization configuration may include a secondary BSW customization configuration and / or a secondary AppL customization configuration, wherein the secondary BSW customization configuration is the newly added BSW configuration, and the secondary AppL customization configuration is the newly added AppL configuration. More specifically, the secondary customization configuration may include a secondary BSW customization configuration, or it may include a secondary AppL customization configuration, or it may include both a secondary BSW customization configuration and a secondary AppL customization configuration.

[0091] For example, after obtaining the secondary baseline configuration, the user can perform a second operation on the user interface provided by the AUTOSAR toolchain, that is, add a Bsw configuration or an AppL configuration, or add both Bsw and AppL configurations, based on the secondary baseline configuration. Accordingly, the development device can respond to the user's second operation by adding a Bsw configuration or an AppL configuration, or adding both Bsw and AppL configurations, to obtain a customized secondary configuration.

[0092] For example, if a user performs a second operation on the user interface provided by the AUTOSAR toolchain, adding a Bsw configuration based on the secondary baseline configuration, the development device can respond to the user's second operation and add a Bsw configuration based on the secondary Bsw configuration in the secondary baseline configuration, thereby obtaining a customized secondary Bsw configuration.

[0093] An example, such as a portion of a secondary baseline configuration, is shown below:

[0094] Power_Can11_Rx

[0095] CanIfTxPduCanId: 0x100

[0096] CanIfTxPduLength:64

[0097] CanIfRxPduDataLengthCheck:True

[0098] CanIfRxPduCycleDetect: False

[0099] Among them, the field "Power_Can11_Rx" represents the message name, the field "CanIfTxPduCanId" represents the message identifier, and its content is "0x100"; the field "CanIfTxPduLength" represents the message length, and its content is "64"; the field "CanIfRxPduDataLengthCheck" represents the length detection, and its content is "True"; the field "CanIfRxPduCycleDetect" represents the custom cycle detection, and its content is "False".

[0100] Users can modify the content of this secondary baseline configuration to obtain a customized secondary configuration. For example, a user can modify the content of the secondary baseline configuration as follows:

[0101] Power_Can11_Rx

[0102] CanIfRxPduCycleDetect: True

[0103] Understandably, the user changed the value of the field "CanIfRxPduCycleDetect" from "False" to "True" based on the secondary baseline, thus obtaining the secondary customized configuration.

[0104] In one possible implementation, the parameters in the Bsw configuration of the secondary baseline configuration cannot be modified; only the values ​​of the Bsw configuration parameters can be changed. For example, the specific parameters included in "Power_Can11_Rx" and their field names (e.g., "CanIfTxPduCanId" for packet identification, "CanIfTxPduLength" for packet length, "CanIfRxPduDataLengthCheck" for length detection, and "CanIfRxPduCycleDetect" for custom cycle detection) cannot be modified. However, the values ​​of the parameters can be changed; for example, the value of the parameter "CanIfRxPduCycleDetect" can be changed from "False" to "True".

[0105] Modifying the values ​​of the secondary BSW configuration parameters in the secondary baseline configuration leads to the secondary BSW custom configuration. It's important to understand that adding a new BSW configuration based on the secondary baseline configuration means adding one or more new values ​​to the secondary BSW configuration parameters, rather than adding new BSW configuration parameter items.

[0106] Optionally, the secondary BSW configuration and the secondary BSW custom configuration can be compared and displayed in the form of a configuration list in the user interface. That is, for the same BSW configuration parameter, the value of the BSW configuration parameter in the secondary BSW configuration and the value in the secondary BSW custom configuration can be compared and displayed.

[0107] For example, if a user performs a second operation on the user interface provided by the AUTOSAR toolchain, adding an AppL configuration based on the secondary baseline configuration, the development device can respond to the user's second operation by adding an AppL configuration based on the secondary AppL configuration in the secondary baseline configuration, thereby obtaining a customized secondary AppL configuration.

[0108] In one possible implementation, the content of the AppL configuration in the secondary baseline configuration is not allowed to be modified. That is, the names of software component sets and the addition of new software component sets are not permitted, nor are the interface connection relationships between software components or the mapping relationships between software components and system signals. It can be understood that adding an AppL configuration based on the secondary baseline configuration means adding one or more of the following: software components, software component sets, interface connection relationships between newly added software components, mapping relationships between newly added software components and system signals, and interface connection relationships between newly added software component sets and existing software component sets.

[0109] For example, a user performs a second operation on the user interface provided by the AUTOSAR toolchain, adding Bsw and AppL configurations based on the secondary baseline configuration. This could be done by filling out a form, selecting a drop-down menu item, or inputting parameter values ​​through other interactive methods. The user can then click a button indicating "Confirm" or "Generate," triggering the development device to begin processing the newly added Bsw and AppL configurations. Accordingly, the development device can respond to this second user operation by adding a Bsw configuration based on the secondary Bsw configuration in the secondary baseline configuration, for example, by saving the values ​​of the parameter items entered by the user, thus obtaining a customized secondary Bsw configuration. Similarly, it can add an AppL configuration based on the secondary AppL configuration in the secondary baseline configuration, thus obtaining a customized secondary AppL configuration.

[0110] Figure 5 is a schematic diagram of the secondary baseline configuration and the customer's customized configuration obtained based on the primary baseline configuration.

[0111] As shown in Figure 5, the black circular baseline configuration represents the primary baseline configuration. The development device can, in response to the first operation as described in step 410 above, import (or copy) this primary baseline configuration into the user (or client) configuration project to obtain the secondary baseline configuration (the white circular baseline configuration shown in Figure 5). The development device can also, in response to the second operation as described in step 420 above, obtain a secondary custom configuration based on the secondary baseline configuration (the white square custom configuration shown in Figure 5).

[0112] Figure 6 is a comparative diagram showing the process before and after using the method provided in the embodiments of this application.

[0113] As shown in Figure 6a), before using the method provided in this application embodiment, the configuration of each customer (e.g., customer A and customer B shown in the figure) is independent, meaning that the configurations of each customer are not related. For example, the configurations of customer A and customer B are independent configurations, and there is no association between them. In this development approach, if a common issue needs to be modified, the same modification needs to be made to the configuration of each customer individually (e.g., the configuration of customer A needs to be modified, and the configuration of customer B also needs to be modified). This not only involves a large workload but also fails to guarantee the quality of the modification, resulting in low development efficiency.

[0114] After using the method provided in this application embodiment, as shown in Figure 6b), the configuration can be divided into primary configuration and secondary configuration. Primary configuration may include a baseline configuration (i.e., primary baseline configuration), which is a common configuration providing various platform-based services. Secondary configuration may include configurations for at least one customer, such as customer A configuration and customer B configuration in Figure 6b). Customer A configuration may include the baseline configuration (i.e., secondary baseline configuration) and a customized configuration for customer A, and customer B configuration may include the baseline configuration (i.e., secondary baseline configuration) and a customized configuration for customer B. In this development approach (i.e., layered or hierarchical development), each customer configuration is a customized configuration based on the primary configuration. When modifying the primary configuration (i.e., primary baseline configuration), only one modification is needed to overwrite (or merge) the modified primary configuration into the secondary configuration. This not only reduces the workload of iterative development and improves development efficiency but also ensures the quality of modifications to common issues without affecting the customized configurations of customers.

[0115] In one possible implementation, the AUTOSAR toolchain can respond to a third operation to update the primary baseline configuration, which is used to release a new version of the primary baseline configuration.

[0116] For example, a user with permissions to modify and publish the Level 1 baseline configuration (i.e., the provider of the Level 1 baseline configuration; for ease of description, this type of user will be referred to as a Level 1 user) can perform a third operation on the user interface provided by the AUTOSAR toolchain. For instance, clicking a button on the user interface that represents "Publish" or "Update" triggers the development device to publish a new version of the Level 1 baseline configuration or update the Level 1 baseline configuration. Accordingly, the development device can respond to the Level 1 user's third operation by overwriting the old version of the Level 1 baseline configuration with the new version, thus completing the update of the Level 1 baseline configuration.

[0117] In one possible implementation, after a new version of the primary baseline configuration is released (i.e., after the primary baseline configuration is updated), the method 400 further includes: obtaining the updated content of the primary baseline configuration.

[0118] For example, after a new version of the primary baseline configuration is released, the development device can respond to another first operation to obtain the updated content of the primary baseline configuration, that is, obtain the content of the new version of the primary baseline configuration.

[0119] It is understandable that the first operation here (for ease of description, this first operation is referred to as the subsequent first operation) is not the same operation as the first operation in step 410 above (for ease of description, this first operation is referred to as the initial first operation), but both of these first operations are used to import the first-level baseline configuration into the user configuration project.

[0120] In one possible implementation, the method 400 further includes updating the secondary Bsw configuration based on the primary Bsw configuration in the updated content of the primary baseline configuration obtained above.

[0121] For example, if a secondary baseline configuration does not yet exist in the user configuration project, after the user performs the aforementioned initial first operation, the development device can directly copy the primary baseline configuration into the user configuration project to obtain the secondary baseline configuration. It can be understood that after the development device responds to this initial first operation, the secondary baseline configuration is created from scratch.

[0122] If a secondary baseline configuration already exists in the user configuration project, after the user performs the aforementioned first subsequent operation, the development device can overwrite the existing secondary baseline configuration with the primary baseline configuration. It can be understood that after the development device responds to this first subsequent operation, a secondary baseline configuration is created. It can also be understood that if the primary baseline configuration is a new version, after the development device responds to this first subsequent operation, the content of the secondary baseline configuration will be updated. That is, if the content of the primary Bsw configuration in the new version of the primary baseline configuration differs from that in the old version, after the development device responds to this first subsequent operation, the content of the secondary Bsw configuration in the secondary baseline configuration will be updated, and the updated content will be identical to the content of the primary Bsw configuration in the new version of the primary baseline configuration. If the primary baseline configuration is an old version, after the development device responds to this first subsequent operation, the content of the secondary baseline configuration remains unchanged.

[0123] Optionally, updating the secondary Bsw configuration based on the updated content of the primary baseline configuration obtained above includes: for the same Bsw configuration parameter, if the first content and the second content are the same, or if the first content and the third content are the same, overwriting the content of the secondary Bsw configuration with the updated content of the primary baseline configuration obtained above, to obtain the updated secondary Bsw configuration; wherein, the first content is the content of the primary Bsw configuration obtained in the updated content of the primary baseline configuration, the second content is the content of the secondary Bsw configuration, the third content is the content of the customized configuration of the secondary Bsw, and the first content, the second content, and the third content are the values ​​of the same Bsw configuration parameter.

[0124] For example, for the same Bsw configuration parameter, if the first content and the second content are the same, or if the first content and the third content are the same, the development device can directly overwrite the value of the second-level Bsw configuration in the first-level baseline configuration of the new version with the value of the second-level Bsw configuration, that is, update the content of the second-level Bsw configuration to the content of the first-level Bsw configuration in the first-level baseline configuration of the new version.

[0125] Optionally, method 400 further includes: for the same Bsw configuration parameter, if the first content is different from the second content, and if the first content is different from the third content, prompting the user to take action.

[0126] For example, in one possible implementation, for the same Bsw configuration parameter, if the first content differs from the second content and the first content differs from the third content, the development device can overwrite the value of the first-level Bsw configuration in the new version of the first-level baseline configuration with the value of the second-level Bsw configuration (that is, update the content of the second-level Bsw configuration to the value of the first-level Bsw configuration in the new version of the first-level baseline configuration), and remind the user that the first content differs from the second content and the third content. In some possible implementations, the user can also be prompted with the following information: what is the first content, what is the second content, and what is the third content? This application does not limit this aspect.

[0127] In another possible implementation, for the same BSW configuration parameter, if the first content differs from the second content and also differs from the third content, the development device can first prompt the user that the first content differs from the second content and also differs from the third content; or, it can prompt the user that the first content differs from the second content and also differs from the third content, specifying what the first content, the second content, and the third content are. Then, based on the user's actions, it determines whether to overwrite the second content with the first content.

[0128] To facilitate better understanding, the following examples, in conjunction with Table 1, illustrate under what circumstances the development device can prompt the user to take action and under what circumstances it can not.

[0129] Table 1

[0130] As shown in the second row of Table 1, during the initial development, for the same Bsw configuration parameter, the first content (let's call it A for ease of description) is 9, the second content (let's call it B for ease of description) is 9, and the third content (let's call it C for ease of description) is also 9.

[0131] As shown in row 3 of Table 1, after iteration 1 is completed, A = 10, B = 9, and C = 10. After the user performs the first operation, the development device can respond to this operation, determine that A ≠ B and A = C, without prompting the user, and merge the primary baseline configuration into the secondary baseline configuration; that is, the primary content overrides the secondary content. As shown in row 4 of Table 1, after the configuration is merged, A = 10, B = 10, and C = 10.

[0132] As shown in row 5 of Table 1, after iterative development 2 is completed, A = 11, B = 10, and C = 10. After the user performs the first operation, the development device can respond to this operation, determine that A ≠ B and A ≠ C, and prompt the user to merge the primary baseline configuration into the secondary baseline configuration. Based on the user's operation, the device can retain the content the user wants to keep as the secondary content. For example, if the user wants to update the primary content to the secondary content, the development device can overwrite the secondary content with the primary content. As shown in row 6 of Table 1, after the configuration is merged, A = 11, B = 11, and C = 10.

[0133] As shown in row 7 of Table 1, after iteration 3 is completed, A = 11, B = 11, and C = 10. After the user performs the first operation, the development device can respond to this operation, determine that A = B and A ≠ C, and does not need to prompt the user. It then merges the primary baseline configuration into the secondary baseline configuration; that is, the primary content overrides the secondary content. As shown in row 8 of Table 1, after the configuration merge, A = 11, B = 11, and C = 10.

[0134] As shown in row 9 of Table 1, after iteration 4 is completed, A = 12, B = 11, and C = 10. After the user performs the first operation, the development device can respond to this operation, determine that A ≠ B and A ≠ C, and prompt the user to merge the primary baseline configuration into the secondary baseline configuration. Based on the user's operation, the device can retain the content the user wants to keep as the secondary content. For example, if the user wants to update the primary content to the secondary content, the development device can overwrite the secondary content with the primary content. As shown in row 10 of Table 1, after the configuration is merged, A = 12, B = 12, and C = 12.

[0135] As shown in row 11 of Table 1, after iteration 5 is completed, A = 12, B = 12, and C = 13. After the user performs the first operation, the development device can respond to this operation, determine that A = B and A ≠ C, and does not need to prompt the user. It then merges the primary baseline configuration into the secondary baseline configuration; that is, the primary content overrides the secondary content. As shown in row 12 of Table 1, after the configuration merge, A = 12, B = 12, and C = 13.

[0136] In one possible implementation, the method 400 further includes: in response to a fourth operation, restoring the secondary Bsw custom configuration to the secondary Bsw configuration, the fourth operation being used to cancel the secondary Bsw custom configuration.

[0137] For example, a user can perform a fourth operation on the user interface provided by the AUTOSAR toolchain regarding the second-level BSW custom configuration. Correspondingly, the development device can respond to the user's fourth operation by restoring the second-level BSW custom configuration to the original second-level BSW configuration, i.e., deleting the second-level custom configuration, with the relevant configuration taking precedence over the second-level BSW configuration. In other words, for the same BSW configuration, if both a second-level custom configuration and a second-level BSW configuration exist, the second-level custom configuration has higher priority than the original second-level BSW configuration.

[0138] In one possible implementation, the method 400 further includes: displaying the secondary baseline configuration and the secondary custom configuration, wherein the secondary baseline configuration and the secondary custom configuration are displayed in different ways.

[0139] Alternatively, one possible display method is that the background color of the secondary custom configuration is different from the background color of the secondary baseline configuration.

[0140] For example, during the development process, the development device can use different colors to show the user which are secondary custom configurations and which are secondary baseline configurations; that is, the background color of the secondary custom configurations is different from the background color of the secondary baseline configurations.

[0141] Alternatively, another possible implementation is that the labels for the second-level custom configuration and the second-level baseline configuration are different.

[0142] In other words, the development device can display different labels to help users distinguish between secondary custom configurations and secondary baseline configurations.

[0143] Alternatively, another possible implementation is that the second-level custom configuration can have labels, while the second-level baseline configuration can be unlabeled.

[0144] In other words, the development device can help users distinguish between secondary custom configurations and secondary baseline configurations by whether or not it has a label.

[0145] In one possible implementation, the method 400 further includes: in response to the fifth operation, using the secondary baseline configuration and the secondary custom configuration as the next-level baseline configuration.

[0146] For example, a user can perform a fifth operation on the user interface provided by the AUTOSAR toolchain to package and publish the secondary baseline configuration and the secondary custom configuration, so that the next level user can carry out further development based on the secondary baseline configuration and the secondary custom configuration, that is, so that the next level user can use the secondary baseline configuration and the secondary custom configuration as the baseline configuration of the next level.

[0147] In other words, the AUTOSAR-based development method provided in this application supports the decoupling of the main domain controller (MDC) from downstream (or lower-level) configurations, and the lower-level configurations can also form a new baseline configuration at the next lower level.

[0148] It is understood that in the AUTOSAR-based development method provided in this application, the development device can display the user interface provided by the AUTOSAR toolchain, and the user can perform the first to fifth operations on the user interface provided by the AUTOSAR toolchain.

[0149] The above describes the layered development (or layered configuration or hierarchical configuration) for the BSW shown in Figure 1. When the baseline configuration (i.e., the first-level baseline configuration) is imported into the customer configuration (as shown in Figure 5), configuration parameters can be customized (e.g., CanIfRxPduCycleDetect). A copy of the baseline configuration (i.e., the second-level baseline configuration) is saved in the customer configuration. When a new version of the first-level baseline configuration (i.e., the first content (A)) is imported into the customer configuration, if the customer has not modified the corresponding customized configuration (i.e., the third content (C)), it will be automatically merged. If the customer has modified the corresponding customized configuration, and a conflict occurs (i.e., A≠B and A≠C), the customer needs to be prompted to handle it, and the customer should be able to manually revert the user configuration to the second-level baseline configuration.

[0150] The following description pertains to the layered development of AppL as shown in Figure 1.

[0151] In one possible implementation, the method 400 further includes updating the secondary AppL configuration based on the primary AppL configuration in the updated content of the acquired primary baseline configuration.

[0152] For example, after a new version of the primary baseline configuration is released, the development device can respond to another first operation to obtain the updated content of the primary baseline configuration, that is, obtain the content of the new version of the primary baseline configuration.

[0153] It is understandable that the other first operation here (for ease of description, this first operation is referred to as the subsequent first operation) is not the same operation as the first operation in step 410 above (for ease of description, this first operation is referred to as the initial first operation), but both of these first operations are used to import the first-level baseline configuration into the user configuration project.

[0154] If the secondary baseline configuration does not yet exist in the user configuration project, after the user performs the aforementioned initial first operation, the development device can directly copy the primary baseline configuration into the user configuration project to obtain the secondary baseline configuration. It can be understood that after the development device responds to this initial first operation, the secondary baseline configuration is created from scratch.

[0155] If a secondary baseline configuration already exists in the user configuration project, after the user performs the aforementioned first subsequent operation, the development device can overwrite the existing secondary baseline configuration with the primary baseline configuration. It can be understood that after the development device responds to this first subsequent operation, a secondary baseline configuration is created. It can also be understood that if the primary baseline configuration is a new version, after the development device responds to this first subsequent operation, the content of the secondary baseline configuration will be updated. That is, if the content of the primary AppL configuration in the new version of the primary baseline configuration differs from that in the old version, after the development device responds to this first subsequent operation, the content of the secondary AppL configuration in the secondary baseline configuration will be updated, and the updated content will be identical to the content of the primary AppL configuration in the new version of the primary baseline configuration. If the primary baseline configuration is an old version, after the development device responds to this first subsequent operation, the content of the secondary baseline configuration remains unchanged.

[0156] Optionally, updating the secondary AppL configuration based on the primary AppL configuration in the updated content of the primary baseline configuration includes: overwriting the secondary AppL configuration with the primary AppL configuration to obtain the updated secondary AppL configuration; and reconnecting the interface of the software component set in the user configuration project based on the updated secondary AppL configuration.

[0157] Figure 7 is a comparative diagram showing the interface connections of the software component set before and after the Level 1 AppL configuration update.

[0158] For example, as shown in Figure 7, the Level 1 AppL configuration includes a collection of software components named "CoreComposition" (also referred to as "CoreComposition"). This CoreComposition includes software components Swc1 and Swc2. As shown in Figure 7a), before the Level 1 AppL configuration is updated, interface 2 of software component Swc1 (e.g., named "Core.Swc1.2") is mapped to Bsw signal 1 in the system signals (also referred to as "CoreSignalMapping") named "CoreSignalMapping"; interface 3 of software component Swc2 (e.g., named "Core.Swc2.3") is mapped to Bsw signal 2 in the system signals CoreSignalMapping. As shown in Figure 7b), after the first-level AppL configuration is updated, a connection relationship is added between interface 3 of software component Swc1 and interface 4 of software component Swc2, based on Figure 7a).

[0159] After the primary AppL configuration is updated, the development device can respond to the user's operation, obtain the primary AppL configuration from the updated primary baseline configuration, and overwrite the secondary AppL configuration with the updated primary AppL configuration to obtain the updated secondary AppL configuration. It is understood that the updated secondary AppL configuration is the same as the updated primary AppL configuration. For example, based on the updated primary AppL configuration shown in Figure 7b), the obtained updated secondary AppL configuration is also shown in Figure 7b).

[0160] After obtaining the updated secondary AppL configuration, the interface of the software component collection can be reconnected in the user configuration project based on the updated secondary AppL configuration and the current version of the secondary AppL custom configuration.

[0161] Figure 8 is a schematic diagram of the interface connection between the secondary AppL configuration and the software component set in the secondary AppL custom configuration after updating the secondary AppL configuration.

[0162] As shown in Figure 8, after updating the secondary AppL configuration based on the primary AppL configuration to obtain the updated secondary AppL configuration, the interfaces of the software component collections are reconnected in the user configuration project based on the updated secondary AppL configuration and the current version of the secondary AppL custom configuration. For example, the part within the dashed box in Figure 8 is the updated secondary AppL configuration; the part outside the dashed box is the secondary AppL custom configuration. For example, the interface of the software component collection CoreComposition named "Core.Swc1.1" has a connection relationship with the interface of the software component collection named "SolutionComposition" (also known as "Software Component Collection SolutionComposition") named "Solution.Swc1.1"; the interface of the software component collection CoreComposition named "Core.Swc2.1" has a connection relationship with the interface of the software component collection SolutionComposition. There is a connection between the interface named "Solution.Swc2.1 (Solu.Swc2.1)" and the interface named "Core.Swc2.2 (Core.Swc2.2)" of the software component collection CoreComposition; there is a connection between the interface named "Solution.Swc2.2 (Solu.Swc2.2)" of the software component collection SolutionComposition; and there is a mapping relationship between the interface named "Solution.Swc4.2 (Solu.Swc4.2)" of the software component collection SolutionComposition and the Bsw signal 3 in the system signal (also known as "System Signal SolutionSignalMap") named "SolutionSignalMap".

[0163] As shown in Figure 8, the software component set CoreComposition and the software component set SolutionComposition can be combined into a larger software component set (e.g., named "ECU Composition" or "Software Component Set EcuComposition"). Similarly, the system signal CoreSignalMapping and the system signal SolutionSignalMap can form a larger system signal set (e.g., named "ECU Signal Mapping" or "System Signal EcuSignalMapping").

[0164] The above describes the layered development (or layered configuration or hierarchical configuration) for AppL as shown in Figure 1. In the baseline configuration (i.e., the first-level baseline configuration), as shown in Figure 7, multiple software components are merged into a software component set, and various public interfaces are provided on the software component set. As shown in Figure 8, after the first-level AppL configuration is imported into the user configuration, the software component set in the first-level AppL configuration automatically connects with the client's software component set through interfaces. The automatic connection of interfaces can be achieved by using a predefined interface (e.g., "CompositionName.FuncName"), or by using tagging, type judgment, etc., which are not limited in this application. Figure 8 uses a predefined interface (CompositionName.FuncName) as an example, pre-defining the naming rules for the interface names and the connection rules between interfaces. This is an example and not a limitation. For example, the connection rules between interfaces can include allowing two interfaces with the same suffix in their names to establish a connection relationship.

[0165] Figure 9 is a schematic diagram of the mapping relationship between software components and system signals.

[0166] As shown in Figure 9, system signals are associated with corresponding software components. For example, the system signal EcuSignalMapping is associated with the software component set EcuComposition, the system signal CoreSignalMapping is associated with the software component set CoreComposition, and the system signal SolutionSignalMap is associated with the software component set SolutionComposition. When exporting configurations (first-level or second-level configurations), the associated system signals and their corresponding interfaces can be deduced based on the hierarchical relationship of the software components.

[0167] To facilitate better understanding, the AUTOSAR-based development method provided in this application will be explained again below with reference to Figure 10.

[0168] Figure 10 is another schematic flowchart of the AUTOSAR-based development method provided in the embodiments of this application.

[0169] As shown in Figure 10, the AUTOSAR-based development method may include steps 1001 to 1004.

[0170] The steps of this method can be executed by a development device, or by a component (such as a chip, chip system, etc.) configured in the development device, or by a logic module or software capable of implementing all or part of the functions of the development device; this application does not limit this. The following describes each step of the method in detail, taking the execution of the method by a development device as an example.

[0171] In step 1001, the first-level Bsw configuration and the first-level AppL configuration in the first-level baseline configuration are exported.

[0172] Level 1 users (i.e., users with permissions to modify and publish the Level 1 baseline configuration) can perform a third operation on the user interface provided by the AUTOSAR toolchain to publish the Level 1 baseline configuration. Correspondingly, the development apparatus can respond to the user's third operation by exporting the Level 1 baseline configuration, that is, exporting the Level 1 Bsw configuration and Level 1 AppL configuration from the Level 1 baseline configuration.

[0173] For a detailed description of the third operation, please refer to the relevant description in method 400 above. For the sake of brevity, it will not be repeated here.

[0174] In step 1002, the first-level Bsw configuration from the first-level baseline configuration is imported into the user configuration project, and conflicting configurations are handled.

[0175] Users can perform the first operation on the user interface provided by the AUTOSAR toolchain. Correspondingly, the development device can respond to the user's first operation by importing the first baseline configuration into the user configuration project, which includes importing the first-level Bsw configuration from the first-level baseline configuration into the user configuration project. A detailed description of the first operation can be found in the relevant description in method 400 above, and will not be repeated here for the sake of brevity.

[0176] It is understandable that if a secondary baseline configuration does not exist in the user configuration project, copying the primary baseline configuration into the user configuration project will result in a secondary baseline configuration, which includes the secondary Bsw configuration. If a secondary baseline configuration exists in the user configuration project, importing the primary Bsw configuration from the primary baseline configuration into the user configuration project is equivalent to overwriting the secondary Bsw configuration in the secondary baseline configuration with the primary Bsw configuration from the primary baseline configuration. In the case of conflicting configurations, i.e., A≠B and A≠C, the user needs to be prompted to handle the situation. A detailed description of this can be found in the relevant descriptions in Table 1, and for brevity, it will not be repeated here.

[0177] In step 1003, the first-level AppL configuration in the first-level baseline configuration is forcibly imported in the user configuration project.

[0178] Users can perform their first operation on the user interface provided by the AUTOSAR toolchain. In response, the development device can import the first baseline configuration into the user configuration project, which includes importing the first-level AppL configuration from the first-level baseline configuration into the user configuration project.

[0179] It's understandable that if a secondary baseline configuration doesn't exist in the user configuration project, copying the primary baseline configuration into the user configuration project will result in a secondary baseline configuration, which will include the secondary AppL configuration. Conversely, if a secondary baseline configuration exists in the user configuration project, importing the primary AppL configuration from the primary baseline configuration into the user configuration project is equivalent to overwriting the secondary AppL configuration within the secondary baseline configuration with the primary AppL configuration from the primary baseline configuration.

[0180] In step 1004, the interfaces between the software component sets are re-associated in the user configuration project.

[0181] Based on the secondary AppL configuration obtained after being forcibly overridden by the primary AppL configuration, the interface for reconnecting the software component set is re-established in the user configuration project. For a detailed description, please refer to Figures 7 to 9 in Method 400 above; for brevity, they will not be repeated here.

[0182] Understandably, in one possible implementation, the aforementioned secondary baseline configuration and secondary customized configuration can be used for vehicle development; that is, iterative development can be carried out based on the secondary baseline configuration and secondary customized configuration, meaning that both the secondary baseline configuration and the secondary customized configuration can be iteratively updated. In another possible implementation, the secondary customized configuration can be used for vehicle development; that is, after obtaining the secondary customized configuration based on the secondary baseline configuration, subsequent development can only be carried out based on this secondary customized configuration, without updating the secondary baseline configuration.

[0183] Based on the above technical solution, the primary baseline configuration and the secondary baseline configuration are common configurations, while the secondary customized configuration is a user configuration. When modifying common issues through the primary baseline configuration, only the primary baseline configuration needs to be modified and a new version of the primary baseline configuration needs to be released. When updating the primary baseline configuration, it is not necessary to update the secondary baseline configuration for each customer. Instead, the secondary baseline configuration is updated based on the new version of the primary baseline configuration when the customer needs it. This not only reduces the workload of iterative development and improves development efficiency, but also ensures the quality of modifications to common issues and does not affect the customized configurations of customers. In other words, the platform module only needs to be stored in the primary baseline configuration library, and the integration of the baseline configuration and the customized configurations of each customer can be achieved by merging the scripts of the primary and secondary baseline configurations. As a result, it is estimated that the workload of adding new single-model customizations can be reduced by approximately 10 person-months, which not only reduces the workload of iterative development but also improves development efficiency.

[0184] The AUTOSAR-based development method provided in this application has been described in detail above with reference to the accompanying drawings. The development apparatus provided in this application will now be described in detail with reference to the accompanying drawings.

[0185] It should be understood that the development apparatus shown in Figures 11 and 12 can be used to implement the functions of the development apparatus in the above method embodiments, and therefore can also achieve the beneficial effects of the above method embodiments. In the embodiments of this application, the development apparatus can be the development apparatus in any of the method embodiments shown in Figure 4 or Figure 10, or it can be a component (such as a chip, chip system, processor, etc.) configured in the development apparatus, or it can be a logic module or software capable of implementing some or all of the functions of the development apparatus.

[0186] Figure 11 is a schematic block diagram of the development apparatus provided in an embodiment of this application.

[0187] As shown in Figure 11, the development device 1100 includes an instruction receiving module 1110 and a processing module 1120. The development device 1100 can be used to implement the functions of the development device in any of the method embodiments shown in Figure 4 or Figure 10.

[0188] For example, when the development device 1100 is used to implement the functions of the development device in the method embodiment shown in FIG4, the instruction receiving module 1110 can be used to receive a first instruction from the user corresponding to a first operation; the processing module 1120 can be used to obtain a secondary baseline configuration in response to the first operation, the first operation being used to import the primary baseline configuration into the user configuration project, the primary baseline configuration including a primary Bsw configuration and a primary AppL configuration, the secondary baseline configuration including a secondary Bsw configuration and a secondary AppL configuration; the instruction receiving module 1110 can also be used to receive a second instruction from the user corresponding to a second operation; the processing module 1120 can also be used to obtain a secondary customized configuration in response to the second operation, the second operation being used to add a Bsw configuration and / or an AppL configuration based on the secondary baseline configuration, the secondary customized configuration including a secondary Bsw customized configuration and / or a secondary AppL customized configuration, the secondary Bsw customized configuration being the newly added Bsw configuration, the secondary AppL customized configuration being the newly added AppL configuration; wherein, the primary baseline configuration and the secondary baseline configuration are common configurations, and the secondary customized configuration is a user configuration.

[0189] Optionally, the processing module 1120 can also be used to: obtain the updated content of the primary baseline configuration.

[0190] Optionally, the processing module 1120 can also be used to update the secondary Bsw configuration based on the primary Bsw configuration in the obtained updated content of the primary baseline configuration.

[0191] Optionally, the processing module 1120 can be specifically used to: for the same Bsw configuration parameter, if the first content and the second content are the same, or if the first content and the third content are the same, overwrite the content of the second-level Bsw configuration in the updated content of the first-level baseline configuration obtained by the module to obtain the updated second-level Bsw configuration; wherein, the first content is the content of the first-level Bsw configuration in the updated content of the first-level baseline configuration obtained by the module, the second content is the content of the second-level Bsw configuration, the third content is the content of the customized configuration of the second-level Bsw, and the first content, the second content and the third content are the values ​​of the same Bsw configuration parameter.

[0192] Optionally, the processing module 1120 can also be used to: prompt the user to perform processing when the first content is different from the second content and the first content is different from the third content for the same Bsw configuration parameter.

[0193] Optionally, the processing module 1120 can also be used to: in response to a fourth operation, restore the secondary Bsw custom configuration to the secondary Bsw configuration, the fourth operation being used to cancel the secondary Bsw custom configuration.

[0194] Optionally, the processing module 1120 can also be used to update the secondary AppL configuration based on the primary AppL configuration in the obtained updated content of the primary baseline configuration.

[0195] Optionally, the processing module 1120 may be specifically used to: overwrite the secondary AppL configuration with the primary AppL configuration in the updated content of the primary baseline configuration to obtain the updated secondary AppL configuration; and reconnect the interface of the software component set in the user configuration project based on the updated secondary AppL configuration.

[0196] Optionally, the processing module 1120 can also be used to: in response to the fifth operation, use the secondary baseline configuration and the secondary custom configuration as the baseline configuration of the next level.

[0197] Optionally, the processing module 1120 can also be used to display the secondary baseline configuration and the secondary customized configuration, wherein the secondary baseline configuration and the secondary customized configuration are displayed in different ways.

[0198] For a more detailed description of each of the above modules, please refer directly to the relevant descriptions in the method embodiment shown in Figure 4, which will not be repeated here.

[0199] It should be understood that the module division in the embodiments of this application is illustrative and only represents a logical functional division. In actual implementation, there may be other division methods. Furthermore, the functional modules in the various embodiments of this application can be integrated into a single processor, exist as separate physical entities, or be integrated into a single module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0200] Figure 12 is another schematic block diagram of the development apparatus provided in an embodiment of this application.

[0201] The development apparatus 1200 can be a chip system, or it can be a device configured with a chip system for implementing the methods described in the above-described method embodiments. In the embodiments of this application, the chip system can be composed of chips, or it can include chips and other discrete devices.

[0202] As shown in FIG12, the development apparatus 1200 may include a processor 1210, which can be used to execute computer programs or instructions in memory to implement the steps performed by the development apparatus in any of the method embodiments shown in FIG4 or FIG10.

[0203] Optionally, the development apparatus 1200 further includes a communication interface 1220. The communication interface 1220 can be used to communicate with other devices via a transmission medium, thereby enabling the development apparatus 1200 to communicate with other devices. The communication interface 1220 may be, for example, a transceiver, interface, bus, circuit, or a device capable of transmitting and receiving functions. The processor 1210 can use the communication interface 1220 to input and output data and to implement the method described in any embodiment corresponding to FIG. 4 or FIG. 10. Specifically, the development apparatus 1200 can be used to implement the functions of the development apparatus in the above-described method embodiments.

[0204] Optionally, the development apparatus 1200 further includes at least one memory 1230 for storing program instructions and / or data. The memory 1230 is coupled to the processor 1210. The coupling in this embodiment is an indirect coupling or communication connection between devices, units, or modules, and can be electrical, mechanical, or other forms, used for information exchange between devices, units, or modules. The processor 1210 may operate in conjunction with the memory 1230. The processor 1210 may execute program instructions stored in the memory 1230.

[0205] In this application, the memory 1230 can be integrated into the processor 1210, or the processor 1210 and the memory 1230 can be set up separately. This application does not limit this.

[0206] It should be understood that the coupling in the embodiments of this application is an indirect coupling or communication connection between devices, units, or modules, which can be electrical, mechanical, or other forms, used for information interaction between devices, units, or modules. The processor 1210 may operate in conjunction with the memory 1230. The embodiments of this application do not limit the specific connection medium between the processor 1210, communication interface 1220, and memory 1230. In Figure 12, the processor 1210, communication interface 1220, and memory 1230 are connected via a bus 1240. The bus 1240 is represented by a thick line in Figure 12. The connection methods between other components are only illustrative and not intended to be limiting. The bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used in Figure 12, but this does not indicate that there is only one bus or one type of bus.

[0207] This application also provides a computer program product, which includes a computer program (also referred to as code or instructions) that, when run, can implement the steps performed by the development device in any of the embodiments shown in FIG4 or FIG10.

[0208] This application also provides a computer-readable storage medium storing a computer program (also referred to as code or instructions). When the computer program is run, it can implement the steps performed by the development apparatus in any of the embodiments shown in FIG4 or FIG10.

[0209] This application provides a chip system including at least one processor for supporting the implementation of the steps performed by the development apparatus in any of the embodiments shown in FIG4 or FIG10.

[0210] In one possible design, the chip system also includes a memory for storing program instructions and data, which may be located within or outside the processor.

[0211] The chip system can consist of chips or include chips and other discrete components.

[0212] It should be understood that the processor in the embodiments of this application can be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method embodiments can be completed by the integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method.

[0213] It should also be understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), EEPROM, or flash memory. Volatile memory can be RAM, which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0214] The terms "unit," "module," etc., used in this specification can be used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution. In the embodiments of this application, "unit" and "module" have the same meaning and can be used interchangeably.

[0215] Those skilled in the art will recognize that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. In the several embodiments provided in this application, it should be understood that the disclosed apparatus, devices, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0216] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0217] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0218] In the above embodiments, the functions of each functional unit can be implemented entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions (programs). When the computer program instructions (programs) are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs, DVDs), or semiconductor media (e.g., solid-state disks, SSDs), etc.

[0219] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the technology, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0220] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A development method based on an open system architecture for automobiles, characterized in that, The method includes: In response to the first operation, a secondary baseline configuration is obtained. The first operation is used to import the primary baseline configuration into the user configuration project. The primary baseline configuration includes the primary basic software layer Bsw configuration and the primary application software layer AppL configuration. The secondary baseline configuration includes the secondary Bsw configuration and the secondary AppL configuration. In response to the second operation, a secondary customized configuration is obtained. The second operation is used to add a Bsw configuration and / or an AppL configuration based on the secondary baseline configuration. The secondary customized configuration includes a secondary Bsw customized configuration and / or a secondary AppL customized configuration. The secondary Bsw customized configuration is the newly added Bsw configuration, and the secondary AppL customized configuration is the newly added AppL configuration. The primary baseline configuration and the secondary baseline configuration are common configurations, while the secondary customized configuration is a user configuration.

2. The method as described in claim 1, characterized in that, The method further includes: Obtain the updated content of the first-level baseline configuration.

3. The method as described in claim 2, characterized in that, The method further includes: The secondary Bsw configuration is updated based on the primary Bsw configuration in the updated content of the primary baseline configuration.

4. The method as described in claim 3, characterized in that, The process of updating the secondary BSW configuration based on the primary BSW configuration in the obtained updated primary baseline configuration includes: For the same Bsw configuration parameter, if the first content and the second content are the same, or if the first content and the third content are the same, the content of the second-level Bsw configuration in the updated content of the first-level baseline configuration is overwritten to obtain the updated second-level Bsw configuration. Wherein, the first content is the content of the first-level Bsw configuration in the obtained updated content of the first-level baseline configuration, the second content is the content of the second-level Bsw configuration, and the third content is the content of the second-level Bsw customized configuration. The first content, the second content, and the third content are the values ​​of the same Bsw configuration parameter.

5. The method as described in claim 4, characterized in that, The method further includes: For the same Bsw configuration parameter, if the first content differs from the second content, and the first content differs from the third content, the user will be prompted to take action.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: In response to the fourth operation, the secondary BSW custom configuration is restored to the original secondary BSW configuration, and the fourth operation is used to cancel the secondary BSW custom configuration.

7. The method according to any one of claims 2 to 6, characterized in that, The method further includes: The secondary AppL configuration is updated based on the primary AppL configuration obtained from the updated primary baseline configuration.

8. The method as described in claim 7, characterized in that, The process of updating the secondary AppL configuration based on the primary AppL configuration in the obtained updated primary baseline configuration includes: The updated second-level AppL configuration is obtained by overwriting the first-level AppL configuration with the first-level AppL configuration in the updated first-level baseline configuration. Based on the updated secondary AppL configuration, the interface of the software component set is reconnected in the user configuration project.

9. The method according to any one of claims 1 to 8, characterized in that, The method further includes: In response to the fifth operation, the secondary baseline configuration and the secondary custom configuration are used as the next level baseline configuration.

10. The method according to any one of claims 1 to 9, characterized in that, The method further includes: The secondary baseline configuration and the secondary custom configuration are displayed, and the secondary baseline configuration and the secondary custom configuration are displayed in different ways.

11. A development device based on an open system architecture for automobiles, characterized in that, The apparatus includes a module for performing the method as described in any one of claims 1 to 10.

12. A development device based on an open system architecture for automobiles, characterized in that, Including processor and memory, among which, The memory is used to store programs; The processor is used to invoke the program so that the device performs the method as described in any one of claims 1 to 10.

13. A computer-readable storage medium having a program stored thereon, characterized in that, When the program is executed, the method as described in any one of claims 1 to 10 is performed.

14. A computer program product, characterized in that, Includes a computer program that, when run, causes the method as described in any one of claims 1 to 10 to be performed.

Images