System and method for managing vehicle software design

Abstract

To provide a system and method for managing documentation for vehicle software design. [Solution] A system, method, and apparatus for automatically managing vehicle software design data is provided. In one embodiment, the system may include a memory storage for storing computer-executable instructions and at least one processor communicatively connected to the memory storage, the at least one processor being configured to execute instructions for retrieving multiple vehicle design data, extracting information from the multiple vehicle design data, and generating a vehicle software development plan based on the extracted information, the vehicle software development plan may include multiple design levels that define a plan for designing vehicle software at multiple levels.

Description

Technical Field

[0001] Embodiment examples of the present disclosure relate to vehicle software design, and in particular, relate to the management of materials used in the design and development of vehicle software.

Background Art

[0002] Modern vehicles are capable of performing a wide range of complex functions such as generating telemetry data and transmitting and receiving data via the Internet. In this regard, vehicle software design is an important part of the planning and development process of such vehicles.

[0003] Generally, the process of vehicle software design involves the collection of separate reference materials that are referred to before the start of the vehicle software design process. These materials may include, for example, system requirements specifications (SRS), data sheets, etc., and may be in the form of documents, roadmaps, presentation slides, specifications, data stores, etc. Further, these materials are created and provided to suppliers before the start of the vehicle software design process.

Summary of the Invention

[0004] Embodiment examples consistent with the present disclosure enable the integration of reference materials into the vehicle software design process, and subsequently enable the improvement of the organization and management of reference materials and the improvement of the effectiveness and quality of vehicle software resulting from such vehicle software design processes.

[0005] In one embodiment, a system is provided. The system may include memory storage for storing computer-executable instructions and at least one processor communicatively connected to the memory storage, the at least one processor may be configured to execute instructions such as retrieving data for multiple vehicle designs, extracting information from the data for multiple vehicle designs, and generating a vehicle software development plan based on the extracted information, the vehicle software development plan may include multiple design levels that define a plan for designing vehicle software at multiple levels.

[0006] In one embodiment, at least one processor may be configured to execute instructions for extracting information from multiple vehicle design materials by processing the materials of multiple vehicle designs into an ontology of a domain-specific language.

[0007] In one embodiment, the design levels may include a first level defining the system of interest, a second level defining the vehicle within the system of interest, a third level defining subsystems within the vehicle, a fourth level defining the hardware and software configuration within the subsystem, a fifth level defining the components within the hardware and software configuration, and a sixth level defining subcomponents within the components.

[0008] In one embodiment, the multiple vehicle design documents may include system requirements specifications (SRS).

[0009] In one embodiment, at least one processor may be configured to execute instructions to store the extracted information in a single trusted source (SSOT) database.

[0010] In one embodiment, at least one processor may be configured to execute instructions that generate a graphical user interface (GUI) based on a vehicle software development plan, the GUI may show the interrelationships between elements of multiple design levels across multiple design levels, and the interrelationships between elements of multiple design levels within each of the multiple design levels.

[0011] In one embodiment, at least one processor may be configured to execute instructions to send data related to a vehicle software development plan to a system for testing and verifying the vehicle software.

[0012] In one embodiment, a method is provided. The method may include obtaining data for multiple vehicle designs, extracting information from the data for multiple vehicle designs, and generating a vehicle software development plan based on the extracted information, the vehicle software development plan may include multiple design levels that define a plan for designing the vehicle software at multiple levels.

[0013] In one embodiment, extracting information from multiple vehicle design documents may include processing the multiple vehicle design documents to create an ontology in a domain-specific language.

[0014] In one embodiment, the design levels may include a first level defining the target system, a second level defining the vehicle within the target system, a third level defining subsystems within the vehicle, a fourth level defining the hardware and software configuration within the subsystem, a fifth level defining the components within the hardware and software configuration, and a sixth level defining subcomponents within the components.

[0015] In one embodiment, the multiple vehicle design documents may include system requirements specifications (SRS).

[0016] In one embodiment, the method further includes storing the extracted information in a single trusted source (SSOT) database.

[0017] In one embodiment, the method may further include generating a graphical user interface (GUI) based on a vehicle software development plan, the GUI may show the interrelationships between multiple elements of multiple design levels across multiple design levels, and the interrelationships between multiple elements of multiple design levels within each of the multiple design levels.

[0018] In one embodiment, the method may further include transmitting data related to a vehicle software development plan to a system for testing and verifying the vehicle software.

[0019] In one embodiment, a non-temporary computer-readable recording medium is provided. The non-temporary computer-readable recording medium may have instructions recorded thereon that are executable by at least one processor to cause at least one processor to perform a method including acquiring data for a plurality of vehicle designs, extracting information from the data for the plurality of vehicle designs, and generating a vehicle software development plan based on the extracted information, wherein the vehicle software development plan may include a plurality of design levels that define a plan for the design of the vehicle software at a plurality of levels.

[0020] In one embodiment, extracting information from multiple vehicle design documents may include processing the multiple vehicle design documents to create an ontology in a domain-specific language.

[0021] In an example embodiment, the plurality of design levels may include a first level that defines a target system, a second level that defines a vehicle within the target system, a third level that defines a subsystem within the vehicle, a fourth level that defines the hardware and software configurations within the subsystem, a fifth level that defines components within the hardware and software configurations, and a sixth level that defines sub-components within the components.

[0022] In an example embodiment, the plurality of vehicle design materials may include a system requirements specification (SRS).

[0023] In an example embodiment, the method may further include storing the extracted information in a single source of truth (SSOT) database.

[0024] In an example embodiment, the method may further include generating a graphical user interface (GUI) based on a vehicle software development plan, where the GUI may show the interrelationships between multiple elements of multiple design levels that cross multiple design levels and the interrelationships between multiple elements of multiple design levels within each level of the multiple design levels.

[0025] Additional aspects may be made partially apparent by the description that follows, may be partially obvious from the description, or may be realized by the practice of the disclosed example embodiments.

Brief Description of the Drawings

[0026] The features, advantages, and significance of example embodiments of the present disclosure are described below with reference to the accompanying drawings, in which like reference numerals refer to like elements. [Figure 1] FIG. 1 shows a block diagram of an example of a system configuration for managing vehicle software design materials according to one or more example embodiments. [Figure 2] FIG. 2 shows a flowchart of an example of a method for managing vehicle software design materials according to one or more example embodiments. [Figure 3] FIG. 3 shows an example of components of a reliable single source of truth (SSOT) database according to one or more embodiments. [Figures 4A-4F] FIGS. 4A through 4F show an example of a vehicle software development plan according to one or more embodiments. [Figure 5] FIG. 5 shows an example of a graphical user interface (GUI) according to one or more embodiments. [Figure 6] FIG. 6 shows a block diagram of an example of components in a system according to one or more embodiments. **DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS**

[0027] The following detailed description of exemplary embodiments refers to the accompanying drawings. The above disclosure provides the drawings and the description, but is not intended to be exhaustive or to limit the embodiments to the exact forms disclosed. Modifications and variations are possible based on the above disclosure and can be obtained from the practice of the embodiments. Further, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). In addition, in the operation descriptions and flowcharts provided below, one or more operations may be omitted, one or more operations may be added, one or more operations may be performed (at least in part) simultaneously, and the order of one or more operations may be interchanged.

[0028] Even if particular combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of possible embodiments. In fact, many of these features may be combined in ways that are not explicitly recited in the claims and / or disclosed in the specification. Each of the dependent claims listed below depends directly on only one claim, but the disclosure of possible embodiments includes each dependent claim in combination with any other claim in the claims.

[0029] Any elements, actions, or instructions used herein should not be construed as important or essential unless expressly stated otherwise. Furthermore, when used herein, the articles “a” and “an” are intended to include one or more items and may be used interchangeably with “one or more.” Where only one item is intended, the term “one” or similar word should be used. Also, when used herein, terms such as “have,” “include,” etc., are intended to be open-ended terms. Furthermore, the phrase “based on it” is intended to mean “at least, based on it” unless expressly otherwise indicated. Additionally, expressions such as "[A] and / or [B]," “at least one of [A] and [B],” or "[A] or [B]" should be understood to include A only, B only, or both A and B.

[0030] Expressions like "at least one processor" should be understood as either a single processor executing multiple instructions or multiple processors executing at least some (but not necessarily all) of multiple operations, when the system is configured to execute multiple instructions or multiple operations.

[0031] Any references to “one embodiment,” “a certain embodiment,” “an exemplary embodiment not limited to,” or similar terms found throughout this specification mean that any particular feature, structure, or characteristic described in relation to the embodiments shown is included in at least one embodiment of the present solution. Therefore, the phrases “in one embodiment,” “in a certain embodiment,” “in an exemplary embodiment not limited to,” and similar expressions found throughout this specification may, but do not necessarily, refer to the same embodiment.

[0032] Furthermore, the features, advantages, and characteristics of the Disclosure described herein may be combined in any suitable manner relating to one or more embodiments. Those skilled in the art will recognize, based on the description herein, that the Disclosure may be implemented without the presence of one or more specific features or advantages of a particular embodiment. In other instances, additional features or advantages may be recognized in certain embodiments, which may not be present in all embodiments of the Disclosure.

[0033] Furthermore, the term “vehicle” as used herein refers to any suitable type of vehicle that can be operated in the embodiments of this disclosure. For example, “vehicle” may refer to a powered vehicle such as a car, truck, bus, motorcycle, or any other suitable type of automobile powered by an engine, motor, or other mechanical means. Alternatively or additionally, “vehicle” as used herein may refer to a bicycle, skateboard, and any other suitable type of unpowered vehicle, without departing from the scope of this disclosure.

[0034] As explained above, the vehicle software design process involves reference materials that are consulted before the start of the vehicle software design process. In this regard, since the materials are simply referenced before the start of the vehicle design process, they are not directly integrated into or utilized within the vehicle software design process itself.

[0035] This allows for the integration of documentation into the Continuous Development / Continuous Integration (CICD) software development environment during the software design process, as well as the integration of documentation into the initial and ongoing builds of the vehicle software being developed / designed during the software design process. This is hindered. Such a lack of integration can affect the production and verification of vehicle software, in addition to supply chain management and safety. Therefore, there is a need for a system that can properly integrate the data into the vehicle software design process itself.

[0036] The features, advantages, and significance of the embodiments described herein are merely a part of this disclosure and are not intended to be exhaustive or to limit the scope of this disclosure. Further descriptions of the features, components, configurations, operations, and embodiments of the embodiments of this disclosure are provided hereafter.

[0037] Figure 1 shows a block diagram of an example system configuration 100 for managing vehicle software design data according to one or more embodiments. As shown in Figure 1, the system configuration 100 may include a user 110 and a vehicle software design (VSD) system 120.

[0038] User 110 may include entities such as software developers, project managers, vendors, stakeholders, and original equipment manufacturers (OEMs) involved in the vehicle software design process. In an example embodiment, User 110 may provide vehicle design materials to the VSD system 120 for use in the development and design of vehicle software (i.e., the vehicle software design process) and may receive information related to the development and design of vehicle software (e.g., vehicle software development plans) from the VSD system 120.

[0039] The VSD system 120 may include devices, systems, platforms, modules, etc., which may be configured to perform one or more actions or movements for managing vehicle software design data. In an example embodiment, the VSD system 120 may be communicably connected to another system involved in the vehicle software design process. For example, the VSD system may be communicably connected to a test system configured to perform actions related to vehicle software verification and testing. In an example embodiment, the VSD system 120 may be combined with or part of a system involved in the vehicle software design process. For example, the VSD system may be part of a test system.

[0040] Examples of operations that can be performed by the VSD system 120 to manage vehicle software design documentation are described below with reference to Figures 2 to 5. Furthermore, several examples of components that may be included in the VSD system 120, relating to one or more embodiments, are described below with reference to Figure 6.

[0041] In the following, some examples of operations that can be performed by the VSD system of this disclosure will be described with reference to Figures 2 to 5.

[0042] Figure 2 shows a flowchart of an example of method 200 for managing vehicle software design data, relating to one or more embodiments. One or more operations in method 200 may be performed by at least one processor of a vehicle software design (VSD) system (e.g., processor 612 as described below).

[0043] As shown in Figure 2, in operation S210, at least one processor may be configured to acquire multiple vehicle design documents. These multiple vehicle design documents may be acquired from the user and may include documents used in the vehicle software design process. For example, the documents may include system requirements specifications (SRS), product requirements specifications (PRD), datasheets, documents, roadmaps, presentation slides, data stores, value streams, etc. The process then proceeds to operation S220.

[0044] In operation S220, at least one processor may be configured to extract information from multiple vehicle design documents.

[0045] In the embodiment, information may be extracted by processing data from multiple vehicle designs into an ontology of a domain-specific language. In particular, the data from multiple vehicle designs may be parsed and normalized into multiple languages. Each of the multiple languages ​​may be specific to any design level (i.e., domain) among multiple design levels in the vehicle software development plan (see the following additional description of operation S240). The method then proceeds to operation S230.

[0046] In operation S230, at least one processor may be configured to store the extracted information. The extracted information may be stored in a single trusted source (SSOT) database.

[0047] Figure 3 shows an example of components of a Sole Trusted Information (SSOT) database 300 in one or more embodiments. As shown in Figure 3, it is understood that the SSOT database 300 may include more or fewer components without departing from the scope of this disclosure, but the SSOT database 300 may include at least a requirements database 310, a system modeling language (SysML) database 320, an implementation database 330, and a verification artifact database 340.

[0048] The requirements database 310 may be configured to store data about the requirements of the extracted information. The SysML database 320 may be configured to store the extracted information in System Modeling Language (SysML) format. The implementation database 330 may be configured to store data about the implementation of the extracted information. The verification artifact database 340 may be configured to store data about the verification and artifacts of the extracted information.

[0049] Here, it is understood that the data concerning the requirements of the extracted information, the data concerning the implementation of the extracted information, the data concerning the verification and artifacts of the extracted information, and the information extracted in SysML format may be obtained as output obtained by analyzing and normalizing multiple vehicle design documents.

[0050] In this embodiment, the requirements database 310, the system modeling language (SysML) database 320, the implementation database 330, and the verification artifact database 340 may be synchronized with each other. The method then proceeds to operation S240.

[0051] In operation S240, at least one processor may be configured to generate a vehicle software development plan. The vehicle software development plan may be generated based on the extracted information, and It may include multiple design levels that define a plan for designing vehicle software at multiple levels.

[0052] In the embodiment, the multiple design levels may include a first level that defines the target system, a second level that defines the vehicle within the target system, a third level that defines the subsystems within the vehicle, a fourth level that defines the hardware and software configuration within the subsystem, a fifth level that defines the components within the hardware and software configuration, and a sixth level that defines the subcomponents within the components.

[0053] For example, the first level may define a connected vehicle ecosystem comprising multiple vehicles, a cloud network, mobile devices, etc., and the second level may define a specific vehicle within such an ecosystem. The third level may define all subsystems within such a vehicle, such as various electronic control units (ECUs) (e.g., a central ECU, an advanced driver-assistance system (ADAS) ECU, an in-vehicle infotainment (IVI) ECU, etc.), the powertrain, chassis, body, etc. The fourth level may define all hardware and software configurations related to each subsystem. For example, the fourth level may define hardware and software configurations related to the ADAS ECU, the central ECU, etc. (e.g., sensors, etc.). The fifth level may define all components related to each of the hardware and software configurations. For example, the fifth level may define multiple system-on-a-chip (SoC) related to the hardware of the central ECU, and multiple applications related to the software of the central ECU. The sixth level may define all sub-components along with each component. For example, the sixth level may define multiple cores of each SoC, and multiple software sub-components of each application.

[0054] In the embodiment, each of the multiple design levels may also be associated with objectives, inputs, and outputs. Objectives may define a higher-level description of the objectives and goals of each design level. Inputs may define the inputs that each design level receives. Outputs may define the main results and outputs that each design level provides. In the embodiment, outputs may also be defined as the architecture and requirements of each level.

[0055] Figures 4A to 4F show examples of vehicle software development plans relating to one or more embodiments. As shown in Figures 4A to 4F, a vehicle software development plan may include six design levels: Level 1, Level 2, Level 3, Level 4, Level 5, and Level 6, but it is understood that a vehicle software development plan may include more or fewer design levels without departing from the scope of this disclosure. Furthermore, although Figures 4A to 4F show vehicle software development plans in the form of tables, it is understood that a vehicle software development plan is not limited to any specific form and can be defined in any form.

[0056] As shown in Figure 4A, the first level of the vehicle software development plan may be associated with an objective, which is specified as defining the target system and defining the engineering at the logic layer to accelerate discussion by avoiding complex hardware / software constraints.

[0057] The first level may also be associated with input, which is specified as a user experience (UX) use case.

[0058] The first level may also be associated with an output, which is designated as the boundary of the target system. Furthermore, the boundary of the target system may be defined as a requirement of the first level, as well as the architecture of the first level. For example, as shown in Figure 4A, if the target system is a connected vehicle platform (ecosystem), the requirements of the first level may be the requirements of the connected vehicle platform, and the architecture of the first level may be the architecture of the connected vehicle platform (i.e., the design of the connected vehicle platform, the various elements within the connected vehicle platform, and the relationships and communications between elements within the connected vehicle platform). It is understood that the boundary of the target system may be explicitly defined as a requirement or implicitly defined as a system context.

[0059] As shown in Figure 4B, the second level of the vehicle software development plan may be associated with an objective, which is specified as refining the target system and defining the engineering at the logic layer to accelerate the discussion by avoiding complex hardware / software constraints. Here, refining the target system is understood to mean defining the vehicle within the target system.

[0060] The second level may also be associated with inputs, and the inputs of the second level are specified as the architecture and requirements of the first level.

[0061] The second level may also be associated with an output, which is specified as the refined boundary of the target system (i.e., the boundary of the vehicle within the target system). Furthermore, the refined boundary of the target system may be defined as a second-level requirement, as well as the second-level architecture. For example, as shown in Figure 4B, if the vehicle is a specific vehicle (e.g., a specific model / variant of the vehicle), the second-level requirements may be the requirements of the specific vehicle, and the second-level architecture may be the architecture of the specific vehicle (i.e., the design of the specific vehicle, the various subsystems of the specific vehicle (ECU, sensors, etc.), the relationships and communications between the subsystems of the specific vehicle, etc.). It is understood that the specific vehicle may be the flagship product of an original equipment manufacturer (OEM).

[0062] As shown in Figure 4C, the third level of the vehicle software development plan may be associated with an objective, which is specified as refining the target system and defining the engineering at the physical layer to make the discussion concrete by including hardware / software constraints. Here, refining the target system may also mean defining the vehicle subsystems (e.g., ECUs).

[0063] The third level may also be associated with inputs, and the inputs of the third level are specified as the architecture and requirements of the second level.

[0064] The third level may also be associated with an output, which is specified as the refined boundary of the target system. Furthermore, the refined boundary of the target system may be defined as a third-level requirement, as well as the third-level architecture. For example, as shown in Figure 4C, if the subsystem is a central ECU, the third-level requirements may be the requirements of the central ECU, and the third-level architecture may be the architecture of the central ECU (i.e., the design of the central ECU, the various hardware and software associated with the central ECU, the relationships and communications between the hardware and software associated with the central ECU, etc.). It is understood that the subsystem boundary may be defined as a system domain boundary for handover from the central department to each domain system department. Furthermore, it is understood that the third-level architecture and requirements may also be used to verify the quality custom delivery (QCD) of the system (i.e., the main deliverables).

[0065] The above-described explanation of the third level in Figure 4C is for a single subsystem (e.g., a central ECU), but it should be understood that all subsystems within a vehicle (i.e., all specific ECUs, sensors, etc., in a particular vehicle) may be designated at the third level.

[0066] Furthermore, it is understood that the first, second, and third levels may function as strategic layers (levels).

[0067] As shown in Figure 4D, the fourth level of the vehicle software development plan may be associated with an objective, which is specified as defining the hardware and software configuration of the subsystem and ensuring the feasibility of QCD. Since the fourth level has a significant impact on the feasibility of quality, cost, and delivery (QCD feasibility), including technical characteristics, it is understood that QCD feasibility should be ensured at the fourth level. The objective may also include strategies such as breaking down the subsystem into hardware and software.

[0068] The fourth level may also be associated with inputs, and the inputs of the fourth level are specified as the architecture and requirements of the third level.

[0069] The fourth level may also be associated with outputs, which are specified as hardware and software configurations. Furthermore, hardware and software configurations may be defined as fourth-level requirements, as well as fourth-level architectures. For example, if a subsystem is a central ECU that is broken down into hardware and software configurations, as shown in Figure 4D, the fourth-level requirements may be the hardware (not shown) and software configuration requirements of the central ECU, and the fourth-level architecture may be the architecture of the hardware (not shown) and software configuration of the central ECU (i.e., the software design, the various applications within the software, the relationships and communications between applications within the software, etc.).

[0070] The above details regarding the fourth level in Figure 4D are for a single subsystem (e.g., a central ECU), but it should be understood that all subsystems within a vehicle (i.e., all specific ECUs, sensors, etc., in a particular vehicle) may also be broken down into hardware and software configurations that are all identified at the fourth level.

[0071] As shown in Figure 4E, the fifth level of the vehicle software development plan may be associated with an objective, which is specified as defining the components within the hardware and software configuration.

[0072] The fifth level may also be associated with inputs, and the inputs of the fifth level are specified as the architecture and requirements of the fourth level.

[0073] The fifth level may also be associated with outputs, and the fifth-level outputs are specified as components within the hardware and software configurations. Furthermore, components may be defined as fifth-level requirements as well as fifth-level architectures. For example, as shown in Figure 4E, if the components in the software configuration of the central ECU include the OS core application, the fifth-level requirements may be the requirements of the OS core application, and the fifth-level architecture may be the architecture of the OS core application (i.e., the design of the OS core application, the various subcomponents within the OS core application, the communication and relationships between the subcomponents within the OS core application, etc.). In another example, if the components in the hardware configuration of the central ECU include an SoC, the fifth-level requirements may be the requirements of the SoC, and the fifth-level architecture may be the architecture of the SoC (i.e., the design of the SoC, the various subcomponents within the SoC, the communication and relationships between the subcomponents within the SoC, etc.).

[0074] The above-described explanation of the fifth level in Figure 4E is for a single subsystem (e.g., a central ECU), but it should be understood that all subsystems within a vehicle (i.e., all specific ECUs, sensors, etc., in a particular vehicle) can also be broken down into hardware and software configurations, and all of these components may be specified at the fifth level.

[0075] As shown in Figure 4F, the sixth level of the vehicle software development plan may be associated with an objective, which is specified as defining the subcomponents within the components. Here, it is understood that the subcomponents may be referred to as units.

[0076] Level 6 may also be associated with inputs, and the inputs of Level 6 are specified as the architecture and requirements of Level 5.

[0077] The sixth level may also be associated with an output, and the output of the sixth level is specified as a subcomponent within a component. Furthermore, the subcomponent may be defined as a requirement of the sixth level, as well as the architecture of the sixth level. For example, as shown in Figure 4F, the requirements of the sixth level may be the requirements of a subcomponent (unit) in the core application of the OS, and the architecture of the sixth level may be the architecture of the subcomponent (unit) in the core application of the OS (i.e., the design of the subcomponent, the various sub-subcomponents within the subcomponent, the relationships and communications between sub-subcomponents within the subcomponent, etc.).

[0078] The above explanation of the fifth level in Figure 4F is for a single subsystem (e.g., a central ECU), but it should be understood that all subsystems within a vehicle (i.e., all specific ECUs, sensors, etc., in a particular vehicle) may also be broken down into hardware and software components, and all subcomponents within these components may be designated at the sixth level.

[0079] In the embodiment, the inputs and outputs of multiple design levels may be obtained by analyzing and normalizing data for multiple vehicle designs. In particular, the data for multiple vehicle designs may be normalized into multiple languages, which may then be analyzed and classified into multiple design levels, with each of the languages ​​corresponding to the inputs and outputs of each design level of the vehicle software development plan. It is understood that the data for multiple vehicle designs may be analyzed and normalized into inputs and outputs of multiple design levels using any means. For example, machine learning models and artificial intelligence may be used to analyze and normalize the data for multiple vehicle designs into inputs and outputs of multiple design levels. Machine learning models may include supervised learning (e.g., linear regression analysis, k-nearest neighbors (KNN), decision tree algorithm, support vector machine, Bayesian algorithm, assembly algorithm, etc.), unsupervised learning (e.g., K-means clustering, principal component analysis (PCA), etc.), reinforcement learning (e.g., Q-learning, multi-armed bandit learning, deep reinforcement learning, etc.), neural networks, etc.

[0080] Therefore, the extracted information may be organized and classified into multiple design levels. Different design levels correspond to different functional levels, which facilitates mutual or cross-functional organizational cooperation between different functional groups of the original equipment manufacturer (OEM) and software and hardware suppliers. In other words, the use of multiple design levels as described above enables multiple users (e.g., vendors, OEM stakeholders, etc.) to work collaboratively. The use of multiple design levels as described above enables the substitution of software and hardware vendors not only between models and variants but also within models or variants. The method then proceeds to operation S250.

[0081] In operation S250, at least one processor may be configured to generate a graphical user interface (GUI). The GUI may be generated based on the vehicle software development plan. Furthermore, the GUI may represent multiple design levels of the vehicle software development plan, along with the interrelationships between multiple elements of multiple design levels across multiple design levels, and the interrelationships between multiple elements of multiple design levels within each of the multiple design levels. Here, the multiple elements may refer to objects of each design level (e.g., a subsystem at the third level, hardware and software configuration at the fourth level, etc.).

[0082] For example, the GUI may indicate that the sixth-level core is a subcomponent of the fifth-level SoC, the fifth-level SoC is a component of the fourth-level hardware configuration, the fourth-level hardware configuration relates to the third-level central ECU, the third-level central ECU is a subsystem of a second-level specific vehicle, and the second-level specific vehicle relates to the first-level connected vehicle ecosystem.

[0083] Figure 5 shows an example of a graphical user interface (GUI) according to one or more embodiments.

[0084] As shown in Figure 5, the GUI represents multiple design levels (i.e., Level 1 to Level 6) in the vehicle software development plan, along with the interrelationships between multiple elements across multiple design levels. For example, the GUI shows the interrelationships between Core 1 and Core 2 at Level 6, SoC-A at Level 5, the hardware configuration of the Central ECU at Level 4, the Central ECU at Level 3, the vehicle at Level 2, and the connected vehicle ecosystem at Level 1.

[0085] These vehicle software development plans, shown here with the interrelationships between multiple elements at multiple design levels, may be considered as system hierarchy trees.

[0086] Therefore, the generated GUI may be provided to the user, enabling visualization and monitoring of the progress of the entire software design process. The GUI may also enable monitoring of the progress of the vehicle software design process, as well as visualization of real-time documentation (e.g., SRS) updates by capturing key metrics regarding code commits, unit tests, and functional performance metrics in the vehicle. The GUI may also enable cross-supplier testing, cross-function testing, real-time progress implementation in distributed teams, multi-supplier testing with real-time variance management to reduce software development cost timelines and improve software reusability and security of software updates, and measurement of different metrics across the codebase to prioritize investments in quality and continuous improvement.

[0087] Furthermore, as shown in the design level and GUI examples in Figures 4 and 5, the architecture and requirements are closely related both within the same design level and across different design levels, enabling traceability of software changes within and between design levels.

[0088] For example, OEMs and vendors can visualize the entire software design process, test individual deliverables, test multiple deliverables using a unified SI unit system, identify software reusability, and normalize management metrics to measure progress and quality.

[0089] From the perspective described above, integrating reference materials (vehicle software design reference materials) into the vehicle software design process at interrelated design levels enables specific design capabilities such as the ability to separate impact analysis by level, the ability to separate complexity by level, the reuse of code and frameworks across supplier and vehicle variants, risk and responsibility explanation, and the identification and correction of bugs and defects in all vehicles and variants, and the identification, iteration, and improvement of software in all vehicles and variants.

[0090] Furthermore, the integration of data into the vehicle software design process at an interrelated design level makes the vehicle software adaptable. This means that vehicle software may be implemented based on design constraints from a single repository rather than being implemented as a stand-alone silo. Thus, a single repository can manage numerous variants so that multiple variants adapt to different signal and hardware capabilities while the architecture remains identical, standardize interfaces between the hardware of the vehicle in use, and define signal bridging and metadata languages. Adaptable vehicle software may enable recognition of incompatible signals between hardware, a complete understanding of the data about the impact on the entire system, an understanding of different frequencies, bandwidths, and modulation software, and adjustment or rejection of design constraints (when signals have different ODDs).

[0091] In addition, in the embodiment, the VSD system may be communicably connected to a test system configured to perform operations related to verifying and testing vehicle software.

[0092] In this regard, in an example embodiment, at least one processor may be configured to transmit data related to the vehicle software development plan to a test system for testing and verifying the vehicle software. The data may include at least one of the following related to the vehicle software development plan: software, metadata, documentation, build artifacts, and bug trackers. In an example embodiment, at least one processor may be configured to tag the data before transmitting it to the test system.

[0093] The aforementioned tagging and transmission of data related to the vehicle software development plan to the test system enable the separation of IP protection for stakeholders and vendors. Furthermore, the process described above may enable traceability for software and project completion payments, guarantee the origin and ownership of IP to facilitate allocation based on payment or royalty shares, and allow for pay-per-use royalties or microtransactions to ensure payment. The above may apply to both integrated and standalone software applications.

[0094] Furthermore, the process described above enables the integration of documentation with software tests performed by the test system. In particular, multiple design levels allow for multiple levels and criteria for testing, enabling insights into the completeness and quality of various stakeholders and suppliers. This is achieved at multiple design levels, which enable the analyzed documentation to generate software tests from human language. In particular, multiple design levels (related to multiple languages) may be utilized by the test system (e.g., based on their syntax) to generate tests that can be used and reused over the long term across different vehicles and vehicle variants. Thus, OEMs can monitor the software repository and where the things are developed and run, and similarly define tests for the software not only internally but also for suppliers. In other words, this enables vehicle software development by multiple vendors and multiple stakeholders.

[0095] Furthermore, the process described above may allow for the introduction of non-compliant or unknown hardware, in which case software testing may be performed to determine how much the hardware deviates from the specifications. In particular, multiple design levels may be utilized by the test system to generate an ontological software test framework that uses rules or machine learning to identify hardware and determine whether that hardware complies or does not comply with the vehicle specifications. From these, there may be a "tentative approval" for hardware that can only function under certain circumstances. In other words, the test system may identify non-compliant hardware in the vehicle by using unit tests to adapt the software to the limitations of the non-compliant hardware. For example, an ECU may not be compatible with the high-performance operation of the vehicle, but it may be able to operate the vehicle in "limp mode" for a limited period of time. This process may be assisted by a rule-based process or a machine learning process to adapt the hardware. In addition, this system can be applied to non-automotive applications, including the Internet of Things (IoT) that connects various devices in a home, such as air conditioners, heaters, batteries, solar panels, and smart controllers.

[0096] The tests described above may be automated between suppliers, and suppliers specify interoperability between suppliers. This makes it easy for OEMs to It enables the generation and simulation of diverse scenarios regarding safety, quality, and functionality; real-time visualization of the progress of test system implementation; and the trial testing, specification definition, test operation, and delta impact analysis using multiple suppliers and variants.

[0097] Method 200 may terminate once operation S250 has been completed. Alternatively, Method 200 may return to operation S210 and be configured to have at least one processor repeatedly perform, for at least a predetermined time, the acquisition of data for multiple vehicle designs (in operation S210), the extraction of information (in operation S220), the storage of the extracted information (in operation S230), the generation of a vehicle software development plan (in operation S240), and / or the generation of a GUI (in operation S250).

[0098] For example, at least one processor continuously (or periodically) receives additional vehicle design data, and then restarts the acquisition of multiple vehicle design data (in operation S210), extraction of information (in operation S220), storage of the extracted information (in operation S230), generation of a vehicle software development plan (in operation S240), and / or generation of a GUI (in operation S250).

[0099] Figure 6 shows a block diagram of an example component in system 610 according to one or more embodiments. System 610 may correspond to the VSD system 120 in Figure 1, and therefore features related to the VSD system 120 and system 610 may be similarly applicable to each other unless otherwise explicitly stated.

[0100] As shown in Figure 6, the system 610 may include at least one bus 611, at least one processor 612, at least one memory 613, at least one storage component 614, at least one input component 615, at least one output component 616, and at least one communication interface 617.

[0101] It should be considered that system 610 may include more or fewer components than those shown in Figure 6 without departing from the scope of this disclosure. For example, in some embodiments, system 610 may include a plurality of storage components 614, input component 615 and output component 616 may be implemented as components of a transceiver, memory 613 and storage component 614 may be implemented as memory storage, and so on.

[0102] Bus 611 may be configured to facilitate or enable communication between components of system 610. In particular, bus 611 may connect components in a communicative manner to provide means for data transfer and the flow of control signals between components. Bus 611 may include one or more internal buses, address buses, data buses, control buses, Controller Area Network (CAN) buses, Ethernet buses, Peripheral Component Interconnect Express (PCIe) buses, and any other suitable types of buses that can be implemented in system 610 to enable real-time (or near real-time) communication and coordination between components within system 610.

[0103] The processor 612 may be implemented in hardware, firmware, or a combination of hardware and software, and may be configured to handle real-time (or near real-time) data processing and control of the control system 610. The processor 612 may include one or more of the following: a central processing unit (CPU), an image processing unit (GPU), a neural processing unit (NPU), a tensor processing unit (TPU), an accelerator processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), and / or other types of processing or computation components that may be implemented in system 610. In some embodiments, the processor 612 may be programmable to perform one or more operations described herein. Furthermore, the processor 612 may include a plurality of processing units, each dedicated to performing a specific operation.

[0104] Memory 613 may include one or more media for storing buffers, temporary data, runtime variables, and program instructions required for the operation of the control system 610. Memory 613 may include flash memory, read-only memory (ROM), random access memory (RAM), dynamic or static storage devices (e.g., flash memory, magnetic memory, and / or optical memory), and To store information and / or instructions used by processor 612 The system 610 may include one or more of any other suitable types of memory that can be implemented.

[0105] The storage component 614 may be configured to store non-volatile data such as firmware, configuration settings, calibration data, information, and / or software relating to the operation and use of the system 610. For example, the storage component 614 may include, in correspondence with drives, hard disks (e.g., magnetic disks, optical disks, magneto-optical disks, and / or solid disks), compact discs (CDs), digital versatile discs (DVDs), floppy disks, cartridges, magnetic tapes, and / or other types of non-temporary computer-readable media.

[0106] In one embodiment, the storage component 614 may be configured to store computer-readable or computer-executable instructions for performing one or more operations of the system 610. The storage component 614 may provide the stored information to the memory 613 for execution by the processor 612.

[0107] The input component 615 may include one or more input components (e.g., a touchscreen display, keyboard, keypad, mouse, buttons, switches, and / or a microphone) that allow the system 610 to receive information, for example, via user input. The output component 616 may include one or more output components (e.g., a display, speaker, navigation device, one or more light-emitting diodes (LEDs), etc.) that provide output information from the system 610. In one embodiment, the input component 615 and / or the output component 616 may be optional and may be excluded from the system 610.

[0108] At least one communication interface 617 may include transceiver-like components (e.g., transceivers and / or individual receivers and transmitters) that enable the system 610 to communicate with other components (e.g., ECUs, user devices, etc.) via, for example, wired connections, wireless connections, or a combination of wireless and wired connections. For example, the communication interface 617 may include a Controller Area Network (CAN) bus interface, an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a Universal Serial Bus (USB) interface, a Wi-Fi interface, a cellular network interface, or equivalents thereof.

[0109] In one or more embodiments, the communication interface 617 may include at least one input / output (I / O) interface, at least one network interface, at least one storage interface, or equivalent thereof, enabling components 612–616 to communicate with other components. Furthermore, the communication interface 617 may include one or more application programming interfaces (APIs) that enable system 610 (or one or more components included therein) to communicate with one or more software applications (e.g., software applications deployed on an ECU).

[0110] Computer executable instructions (e.g., software instructions) may be read into memory 613 and / or storage component 614 from another computer-readable medium or another device (e.g., a remote server, external storage) via, for example, a communication interface 617. When executed, computer executable instructions stored in memory 613 and / or storage component 614 may cause the processor 612 to perform one or more processes described herein. In addition, or instead, hardware circuits may be used instead of or in combination with software instructions to perform one or more processes described herein. Therefore, the embodiments described herein are not limited to any specific combination of hardware circuits and software.

[0111] The features, advantages, and importance of the embodiments described herein are merely a part of this disclosure and are not intended to be exhaustive or to limit the scope of this disclosure. Further descriptions of the features, components, configurations, operations, and embodiments of the embodiments of this disclosure, as well as the related technical advantages and importance, are provided hereafter.

[0112] It is understood that the specific order or hierarchy of blocks in the processes / flowcharts disclosed herein represents an example approach. It is understood that the specific order or hierarchy of blocks in the processes / flowcharts may be rearranged based on design preferences. Furthermore, some blocks may be combined or omitted. The claims of the appended methods represent various block elements in an example order and are not limited to the specific order or hierarchy expressed herein.

[0113] Some embodiments may relate to systems, methods, and / or computer-readable media at a level of technical detail that may be integrated. Furthermore, as described herein, one or more of the above components may be implemented as instructions stored on a computer-readable medium and may be executable by at least one processor (and / or include at least one processor). The computer-readable medium may include a computer-readable non-temporary storage medium (or media) having computer-readable program instructions for causing a processor (or more processors) to perform an operation.

[0114] Computer-readable storage media can be tangible devices capable of maintaining and storing instructions for use by instruction execution devices. Computer-readable media include, but are not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. A more specific example list of computer-readable storage media includes: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or grooved raised structures on which instructions are recorded, and any suitable combination thereof. The computer-readable storage medium used herein is one that is not interpreted as a transient signal in itself, such as radio waves or other freely propagating electromagnetic waves, or electronic signals propagating through a wire, and which propagates through a waveguide or transmission medium (e.g., light pulses passing through an optical fiber cable).

[0115] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computer / processor, or to an external computer or external storage device via a network such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical transmission fibers, wireless transmission routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computer / processor receives computer-readable program instructions from the network and transfers the computer-readable program instructions for storage in a computer-readable storage medium within each computer / processor.

[0116] Computer-readable program code / instructions for performing an operation may be assembler instructions, instruction set architecture (ISA) instructions, machine language instructions, machine language-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or either source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk and C++, and procedural programming languages ​​such as C or similar programming languages. Computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or wide area network (WAN), or it may be connected to an external computer (for example, via the Internet using an Internet Service Provider). In some embodiments, electronic circuits including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) are configured to personalize the electronic circuit in order to perform a particular action or operation. Computer-readable program instructions may be executed by using the state information of the computer-readable program instructions.

[0117] These computer-readable program instructions may be provided to a processor of an SoC, a general-purpose computer, a dedicated computer, or other programmable data processing device to produce a machine such that instructions executed via the computer's processor or other programmable data processing device generate means for performing functions / operations defined in one or more blocks of a flowchart and / or block diagram. These computer-readable program instructions may be stored in a computer-readable storage medium that can instruct a computer, a programmable data processing device, and / or other device to function in a specific manner in order to function in a particular way, wherein the computer-readable storage medium storing the instructions comprises a product containing instructions that perform the modes of functions / operations defined in one or more blocks of a flowchart and / or block diagram.

[0118] Computer-readable program instructions may be read into a computer, another programmable data processing device, or another device to cause the computer, the other programmable device, or the other device to perform a series of operational steps to generate a computer implementation process, in which case the instructions executed by the computer, the other programmable device, or the other device perform functions / operations defined by one or more blocks in a flowchart and / or block diagram.

[0119] The flowcharts and block diagrams in the drawings illustrate the architecture, functions, and operation of possible embodiments of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in a flowchart or block diagram represents a module, segment, or portion of an instruction, which constitute one or more executable instructions to perform a particular logical function. Methods, computer systems, and computer-readable media may include additional blocks, fewer blocks, different blocks, or blocks arranged differently from those depicted in the diagram. In some alternative embodiments, the functions shown in a block may occur contrary to the rules shown in the diagram. For example, two blocks shown consecutively may actually be executed simultaneously or substantially simultaneously, or these blocks may sometimes be executed in reverse order depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, may be performed by a dedicated hardware-based system that performs a particular function or operation, or by a combination of dedicated hardware and computer instructions.

[0120] It is evident that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not limiting to the embodiments. Therefore, although the operation and behavior of the systems and / or methods are described herein without reference to specific software code, it will be understood that software and hardware may be designed to perform the systems and / or methods based on the descriptions herein.

Claims

1. It is a system, Memory storage for storing computer-executable instructions, At least one processor that is communicably connected to the aforementioned memory storage, Equipped with, The at least one processor is Obtaining data from multiple vehicle designs, Information is extracted from the aforementioned multiple vehicle design documents, Based on the extracted information, a vehicle software development plan is generated. It is configured to execute the aforementioned instruction, The aforementioned vehicle software development plan includes multiple design levels that define a plan for designing the vehicle software at multiple levels. system.

2. A system according to claim 1, wherein at least one processor is configured to execute instructions for extracting information from the plurality of vehicle design materials by processing the plurality of vehicle design materials into an ontology of a domain-specific language.

3. A system according to claim 1 or 2, wherein the plurality of design levels are The first level defines the target system, A second level that defines the vehicles within the aforementioned target system, A third level that defines subsystems within the vehicle, A fourth level that defines the hardware and software configuration within the subsystem, A fifth level that defines the components within the hardware and software configuration, A sixth level that defines the subcomponents within the aforementioned component, A system that includes this.

4. A system according to claim 1 or 2, wherein the plurality of vehicle design data comprises a system requirements specification (SRS).

5. A system according to claim 1 or 2, wherein at least one processor is configured to execute an instruction to store the extracted information in a Sole Trusted Source (SSOT) database.

6. A system according to claim 1 or 2, wherein at least one processor is configured to execute instructions that generate a graphical user interface (GUI) based on the vehicle software development plan, the GUI representing the interrelationships between the elements of the plurality of design levels across the plurality of design levels, and the interrelationships between the elements of the plurality of design levels within each of the plurality of design levels.

7. A system according to claim 1 or 2, wherein at least one processor is configured to execute the instruction to transmit data relating to the vehicle software development plan to a system for testing and verifying the vehicle software.

8. A method performed by at least one processor, Obtaining data on multiple vehicle designs, Extracting information from the aforementioned multiple vehicle design documents, To generate a vehicle software development plan based on the extracted information. Includes, The aforementioned vehicle software development plan is a method that includes multiple design levels, which define a plan for designing vehicle software at multiple levels.

9. A method according to claim 8, wherein extracting the information from the plurality of vehicle design materials comprises processing the plurality of vehicle design materials into an ontology of a domain-specific language.

10. A method according to claim 8 or 9, wherein the plurality of design levels are The first level defines the target system, A second level that defines the vehicles within the aforementioned target system, A third level that defines subsystems within the vehicle, A fourth level that defines the hardware and software configuration within the subsystem, A fifth level that defines the components within the hardware and software configuration, A sixth level that defines the subcomponents within the aforementioned component, A method that includes this.

11. A method according to claim 8 or 9, wherein the data for the plurality of vehicle designs comprises a System Requirements Specification (SRS).

12. A method according to claim 8 or 9, further comprising storing the extracted information in a Sole Trusted Source (SSOT) database.

13. A method according to claim 8 or 9, further comprising generating a graphical user interface (GUI) based on the vehicle software development plan, wherein the GUI represents the interrelationships between the elements of the design levels across the design levels and the interrelationships between the elements of the design levels within each of the design levels.

14. A method according to claim 8 or 9, further comprising transmitting data relating to the vehicle software development plan to a system for testing and verifying the vehicle software.

15. A computer program for causing at least one processor to perform a method, wherein the method is Obtaining data on multiple vehicle designs, Extracting information from the aforementioned multiple vehicle design documents, To generate a vehicle software development plan based on the extracted information. Includes, The aforementioned vehicle software development plan is a computer program that includes multiple design levels, which define a plan for designing vehicle software at multiple levels.

16. A computer program according to claim 15, wherein extracting the information from the plurality of vehicle design materials includes processing the plurality of vehicle design materials into an ontology of a domain-specific language.

17. A computer program according to claim 15 or 16, wherein the plurality of design levels are The first level defines the target system, A second level that defines the vehicles within the aforementioned target system, A third level that defines subsystems within the vehicle, A fourth level that defines the hardware and software configuration within the subsystem, A fifth level that defines the components within the hardware and software configuration, A sixth level that defines the subcomponents within the aforementioned component, A computer program that includes [this].

18. A computer program according to claim 15 or 16, wherein the plurality of vehicle design data comprises a system requirements specification (SRS).

19. A computer program according to claim 15 or 16, wherein the method further comprises storing the extracted information in a Sole Trusted Source (SSOT) database.

20. A computer program according to claim 15 or 16, wherein the method further comprises generating a graphical user interface (GUI) based on the vehicle software development plan, the GUI representing the interrelationships between the elements of the plurality of design levels across the plurality of design levels, and the interrelationships between the elements of the plurality of design levels within each of the plurality of design levels.

Images