A method, apparatus, equipment, and medium for generating a service-oriented model framework for automobiles.

Abstract

This application relates to the field of software development technology, specifically to a method, apparatus, device, and medium for generating an automotive service-oriented model framework. The method includes: acquiring automotive domain controller configuration information and automotive software system functional scenario requirements information; dividing automotive functions into multiple services based on the automotive domain controller configuration information and automotive software system functional scenario requirements information, and calling the service interface configuration information corresponding to multiple services; constructing multiple initial model frameworks corresponding to the multiple services based on the service interface configuration information and pre-configured scripts, and adding initialization modules, main function modules, service call interfaces, and notification interfaces to the multiple initial model frameworks to generate multiple complete automotive service-oriented model frameworks. In this invention, repetitive and routine tasks in the service-oriented model framework development process can be automatically completed in the model building environment through pre-configured scripts, improving the development efficiency of service-oriented models and reducing low-level software defects.

Description

Technical Field

[0001] This application relates to the field of software development technology, specifically to a method, apparatus, device, and medium for generating an automotive service model framework. Background Technology

[0002] With the continuous development of vehicle electrification, intelligence, and connectivity, the trend of software-defined vehicles has emerged. Traditional software architecture can no longer fully meet the needs of vehicles for intelligence, and SOA (Service-Oriented Architecture) is gradually being applied to automobiles.

[0003] SOA enables numerous automotive functionalities to be composed of services, which can be algorithms or methods. In existing technologies, manually developing models for numerous different types of services not only leads to low development efficiency due to the sheer number of services, but also results in low-level software defects such as naming errors and parameter configuration mistakes due to manual development.

[0004] Therefore, how to efficiently develop service-oriented models and reduce low-level software defects during development is an urgent problem to be solved. Summary of the Invention

[0005] In view of the shortcomings of the prior art described above, the purpose of this application is to provide a method, apparatus, device and medium for generating an automotive service model framework, which can solve the problem of how to efficiently develop service models and reduce low-level software defects during development in the prior art.

[0006] To achieve the above and other related objectives, this application provides a method for generating an automotive service model framework, the method comprising:

[0007] Obtain vehicle domain controller configuration information and vehicle software system functional scenario requirements information;

[0008] Based on the vehicle domain controller configuration information and the vehicle software system functional scenario requirements information, the vehicle functions are divided into multiple services, and the service interface configuration information corresponding to the multiple services is called.

[0009] Based on the service interface configuration information and pre-configured scripts, multiple initial model frameworks corresponding to the multiple services are constructed, and initialization modules, main function modules, service call interfaces and notification interfaces are added to the multiple initial model frameworks to generate multiple complete automotive service model frameworks.

[0010] In one embodiment of this application, the service interface configuration information includes:

[0011] Service list information, which includes service name, service interface name, service interface type, and interface parameter name;

[0012] Interface parameter definition information, which includes interface parameter data type and interface parameter numerical definition.

[0013] In one embodiment of this application, after calling the service interface configuration information corresponding to the plurality of services, the method further includes:

[0014] The service list information is converted into a first variable, and the interface parameter definition information is converted into a second variable. The first and second variables are used for information invocation when adding the initialization module, main function module, service call interface and notification interface.

[0015] In one embodiment of this application, multiple initial model frameworks corresponding to the multiple services are constructed, and an initialization module, a main function module, a service call interface, and a notification interface are added to the multiple initial model frameworks, including:

[0016] Call the first variable and iterate through the first variable to determine the service list information of the multiple services;

[0017] Based on the service list information of the multiple service lists and the second variable, an initial model framework corresponding to each service is constructed, and an initialization module, a main function module, a service call interface, and a notification interface are added to the initial model framework corresponding to each service.

[0018] In one embodiment of this application, after constructing the initial model framework corresponding to each service, the method further includes:

[0019] Each initial model framework is named according to the service name, resulting in multiple named initial model frameworks.

[0020] Based on the functional scenario requirements of the automotive software system, initial configuration parameters are set for the named initial model frameworks. The initial configuration parameters include at least one of solver type parameters, solver configuration parameters, and fixed step size.

[0021] In one embodiment of this application, adding an initialization module to the initial model framework corresponding to each service includes:

[0022] Add the initialization function from the pre-configured model building environment library to the first position in the initial model framework, and name the initialization function according to the service name and the preset first suffix;

[0023] Delete all content except the event listener in the named initialization function to complete the addition of the initialization module.

[0024] In one embodiment of this application, a main function module is added to the initial model framework corresponding to each service, including:

[0025] An initial subsystem is added to the initial model framework. The initial subsystem is named according to the service name and a preset second suffix. The contents of the named initial subsystem are then deleted to obtain the target subsystem.

[0026] Add the first trigger to the target subsystem to obtain a preset trigger function and select and call the trigger type through the first trigger;

[0027] The first input submodule is added to the initial model framework, named according to the service name, and the running cycle of the first input submodule is set according to the preset cycle parameters to obtain the configured first input submodule.

[0028] Connect the configured first input submodule to the interface of the first trigger to complete the addition of the main function module.

[0029] In one embodiment of this application, the service invocation interface includes a first type of service invocation interface. Adding a service invocation interface to the initial model corresponding to each service includes:

[0030] Based on the service interface type in the service interface configuration information, determine whether the service call interface is a server-side response message interface or a client-side request to obtain status interface;

[0031] If the service call interface is a server-side response message interface or a client-side request to obtain status interface, then the service call interface is determined to be a first type of service call interface;

[0032] A first initial model building environment function is added to the initial model framework, and the first initial model building environment function is named according to the service name and the name of the first type of service call interface to obtain the first target model building environment function;

[0033] Delete all content in the first target model building environment function except for the second trigger, name the function of the second trigger according to the service name and the name of the first type of service call interface, and set the visibility of the second trigger to global visibility;

[0034] Based on the second variable, input and output parameters are added to the environment function of the first target model through the preset library paths of the input parameter module and the output parameter module, thereby completing the addition of the service call interface.

[0035] In one embodiment of this application, the step of adding input and output parameters to the environment function of the first target model based on the second variable through preset library paths of the input parameter module and the output parameter module includes:

[0036] Based on the name of the first service call interface, the target parameter in the input parameter module and the output parameter module is determined, and the parameter name of the target parameter is consistent with the name of the first service call interface;

[0037] Search for the name of the first service call interface in the second variable, determine the first data type of the configuration parameter corresponding to the first type of service call interface, and determine the data type string of the input parameter module and the output parameter module according to the first data type;

[0038] Based on the data type strings of the input parameter module and the output parameter module, the target parameters are transmitted to the first target model building environment function through the preset library paths of the input parameter module and the output parameter module.

[0039] In one embodiment of this application, the service call interface includes a second type of service call interface, and the service call interface is added to the initial model corresponding to each service, including:

[0040] Based on the service interface type in the service interface configuration information, determine whether the service call interface is a client request setting status interface;

[0041] If the service call interface is a client request to set status interface, then the service call interface is determined to be a second type of service call interface;

[0042] The second initial model building environment function is added to the initial model framework, and the second initial model building environment function is named according to the service name and the name of the second type of service call interface to obtain the second target model building environment function;

[0043] Delete all content in the second target model building environment function except for the second trigger, name the function of the second trigger according to the service name and the name of the second type of service call interface, and set the visibility of the second trigger to global visibility;

[0044] Based on the second variable, output parameters are added to the environment function of the second target model through the preset output parameter module library path;

[0045] Add a second input submodule to the second target model building environment function, and connect the notification interface of the main function module to the input interface of the second input submodule.

[0046] In one embodiment of this application, the notification interface includes a first notification interface and a second notification interface. Adding a notification interface to the plurality of initial model frameworks includes:

[0047] Add a first initial output submodule to the main function module, and name the first initial output submodule according to the service name and the name of the notification interface to obtain the first target output submodule;

[0048] Search for the parameter name of the notification interface in the second variable, determine the second data type of the parameter corresponding to the notification interface, and set the data type string of the first target output submodule through the second data type to complete the addition of the first notification interface inside the main function module;

[0049] Search all output sub-modules in the main function module, add a second notification interface outside the main function module according to the search results, and connect the first notification interface and the second notification interface with the same name to complete the addition of the notification interface.

[0050] In one embodiment of this application, after connecting the first notification interface and the second notification interface with the same name, the method further includes:

[0051] Connect the second type of service call interface to the corresponding notification interface, and ensure that the output parameters of the second type of service call interface are consistent with the input parameters of the notification interface.

[0052] In one embodiment of this application, an apparatus for generating an automotive service model framework is also provided, the apparatus comprising:

[0053] The information acquisition module is used to acquire vehicle domain controller configuration information and vehicle software system functional scenario requirements information;

[0054] The service interface configuration information determination module is used to divide the vehicle functions into multiple services based on the vehicle domain controller configuration information and the vehicle software system functional scenario requirements information, and call the service interface configuration information corresponding to the multiple services.

[0055] The model generation module is used to construct multiple initial model frameworks corresponding to the multiple services based on the service interface configuration information and pre-configured scripts, and to add an initialization module, a main function module, a service call interface and a notification interface to the multiple initial model frameworks to generate multiple complete automotive service model frameworks.

[0056] In one embodiment of this application, an electronic device is also provided, the electronic device comprising:

[0057] one or more processors;

[0058] A storage device for storing one or more programs, which, when executed by one or more processors, enable the electronic device to implement the automotive service model framework generation method as described above.

[0059] In one embodiment of this application, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a computer's processor, causes the computer to perform the automotive service model framework generation method as described above.

[0060] The beneficial effects of this invention are:

[0061] First, the vehicle domain controller configuration information and the functional scenario requirements of the vehicle software system are obtained. Then, based on the vehicle domain controller configuration information and the functional scenario requirements of the vehicle software system, the vehicle functions are divided into multiple services, and the service interface configuration information corresponding to the multiple services is called. Finally, based on the service interface configuration information and pre-configured scripts, multiple initial model frameworks corresponding to the multiple services are constructed, and initialization modules, main function modules, service call interfaces, and notification interfaces are added to the multiple initial model frameworks to generate multiple complete vehicle service-oriented model frameworks. In this invention, the service-oriented model framework can be generated in the model building environment through pre-configured scripts, which can automatically complete repetitive and regular tasks in the service-oriented model framework development process, improve the development efficiency of service-oriented models, and reduce low-level software defects in the development process through scripts, thus saving the overall time cost of software development projects under the automotive SOA architecture.

[0062] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0063] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0064] Figure 1 This is a schematic diagram illustrating the implementation environment of the method for generating a vehicle service model framework, as shown in an exemplary embodiment of this application.

[0065] Figure 2 This is a schematic flowchart illustrating an exemplary embodiment of the method for generating a vehicle service model framework.

[0066] Figure 3 This is a block diagram illustrating an automotive service model framework generation apparatus, as shown in an exemplary embodiment of this application.

[0067] Figure 4 A schematic diagram of the structure of a computer system suitable for an electronic device according to an embodiment of this application is shown. Detailed Implementation

[0068] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0069] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0070] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the invention. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the invention.

[0071] First, it's important to note that with the trend of the "new four modernizations" of automobiles, the demands of the new car-buying group have undergone significant changes. While cars are fully realizing connectivity, autonomous driving, and data-driven capabilities, they are also increasingly focused on directly reaching users, improving experience and services, and meeting personalized user needs. SOA (Service-Oriented Architecture) is both a software architecture and a software design philosophy. In SOA, services are the core abstraction method and the most basic unit of the system. Each service has independent functionality, and the interfaces between services follow a unified standard, allowing them to access each other and be composable and extensible. Based on SOA, when dividing the overall scenario functions of a car into numerous services for invocation, corresponding models need to be generated for different services. Manually generating service-oriented models requires a large amount of repetitive and / or regular work, such as setting model parameters, module naming, parameter naming, and data type settings. When performing these tasks manually, the sheer number of services can lead to low-level software defects such as naming errors and parameter setting errors. Furthermore, the extensive model generation work increases the overall time cost of automotive software development projects.

[0072] The following explains the technical terms used in this application:

[0073] Simulink: Simulink is a visual simulation tool within MATLAB (a mathematical software). Simulink is a modular graphical environment and model-building environment used for multi-domain simulation and model-based design. It supports system design, simulation, automatic code generation, and continuous testing and verification of embedded systems. Simulink provides a graphical editor, a customizable library of modules, and solvers, enabling dynamic system modeling and simulation. Simulink integrates with MATLAB, allowing MATLAB algorithms to be incorporated into models within Simulink and simulation results to be exported to MATLAB for further analysis. Simulink applications include automotive, aerospace, industrial automation, large-scale modeling, complex logic, physical logic, and signal processing.

[0074] Subsystem: As model size and complexity increase, blocks can be grouped into subsystems. A subsystem is a group of blocks grouped into a single subsystem block. When using subsystems, follow these steps: create a hierarchical diagram where subsystem blocks are on one layer and the blocks that make up the subsystem are on another layer; keep functionally related blocks together; help reduce the number of blocks displayed in the model window; establish interfaces with inputs and outputs. Subsystems can be virtual or non-virtual. Virtual subsystems provide a graphical hierarchy in the model. Non-virtual subsystems provide a graphical hierarchy and function as a unit within the model.

[0075] Function Visibility: Visibility is a concept discussed from the perspective of referencing identifiers. Visibility indicates what can be seen when "looking" from an inner scope to an outer scope. If an identifier is visible somewhere, then that identifier can be referenced there. Identifiers should be declared first, followed by references. If an identifier is declared in the outer scope and there is no declaration of the same identifier in the inner scope, then that identifier is visible in the inner scope. For two nested scopes, if an identifier with the same name is declared in the inner scope, it is not visible in the inner scope.

[0076] `OutDataTypeStr`: This is the data type string, used to specify the data type. Similar to any wrapper parameter, the data type string can be added to the wrapper dialog box from the wrapper editor. Adding the data type string to the wrapper dialog box allows the module's end users to specify acceptable data types for the associated edit type parameter. When defining a wrapper, you can specify one or more data types for the edit type parameter, from which the module's end users can choose. Specifying a data type for an edit parameter defines rules for the input values ​​provided through the wrapper dialog box. The data type string also allows you to specify minimum and maximum values ​​for the edit parameter by using minimum and maximum wrapper parameters and associating these parameters with the data type string.

[0077] Figure 1 This is a schematic diagram illustrating the implementation environment of the automotive service model framework generation method, as shown in an exemplary embodiment of this application.

[0078] Reference Figure 1 As shown, the implementation environment may include an automotive service model framework generation terminal 101, a cloud platform 102, and an information storage terminal 103. The automotive service model framework generation terminal 101 may include electronic devices such as tablets, laptops, and desktop computers, used for service partitioning and service model generation. The cloud platform 102 may be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services, used to store automotive domain controller configuration information and automotive software system functional scenario requirement information. The information storage terminal 103 is used to interact with developers to obtain automotive software system functional scenario requirement information and to store the automotive domain controller configuration information and automotive software system functional scenario requirement information.

[0079] In addition, the technical solution provided in this application embodiment can be applied to the automotive service model framework generation terminal 101. The automotive service model framework generation terminal 101 is used to connect to the cloud 102 and the information storage terminal 103 through the network and obtain automotive domain controller configuration information and automotive software system functional scenario requirement information. At the same time, the cloud 102 and the information storage terminal 103 also receive and store the service model framework generated by the automotive service model framework generation terminal 101.

[0080] In one embodiment of this application, the automotive service-oriented model framework generation terminal 101 obtains automotive domain controller configuration information and automotive software system functional scenario requirement information; based on the automotive domain controller configuration information and automotive software system functional scenario requirement information, it divides automotive functions into multiple services and calls the service interface configuration information corresponding to the multiple services; based on the service interface configuration information and pre-configured scripts, it constructs multiple initial model frameworks corresponding to the multiple services, and adds initialization modules, main function modules, service call interfaces, and notification interfaces to the multiple initial model frameworks to generate multiple complete automotive service-oriented model frameworks. In this embodiment, the generation of service-oriented model frameworks can be realized in the model building environment through pre-configured scripts, which can automatically complete repetitive and regular tasks in the development process of service-oriented model frameworks, improve the development efficiency of service-oriented models, and reduce low-level software defects in the development process through scripts, thus saving the overall time cost of software development projects under the automotive SOA architecture.

[0081] The above sections introduced exemplary implementation environments for applying the technical solutions of this application. Next, we will continue to introduce the method for generating the automotive service model framework of this application.

[0082] To address the problem of how to efficiently develop service-oriented models and reduce low-level software defects during development in the prior art, embodiments of this application propose a method for generating an automotive service-oriented model framework, an apparatus for generating an automotive service-oriented model framework, an electronic device, a computer-readable storage medium, and a computer program product, which will be described in detail below.

[0083] Please see Figure 2 , Figure 2 This is a schematic flowchart illustrating an exemplary embodiment of the method for generating a vehicle service model framework, which can be applied to... Figure 1 The implementation environment is shown. It should be understood that this method can also be applied to other exemplary implementation environments and specifically executed by devices in other implementation environments. This embodiment does not limit the implementation environment to which the method is applicable.

[0084] like Figure 2As shown, in an exemplary embodiment, the method for generating an automotive service model framework includes at least steps S210 to S230, which are described in detail below:

[0085] In step S210, the vehicle domain controller configuration information and the vehicle software system functional scenario requirements information are obtained.

[0086] First, it should be noted that the vehicle is divided into several domains based on the functions of automotive electronic components, such as powertrain, intelligent cockpit, and autonomous driving. Each domain is centrally controlled using more powerful multi-core CPU / GPU chips, replacing the current distributed electronic and electrical architecture. The vehicle domain controller configuration information determines the primary functions of the domain controller under the current configuration; the functional scenario requirements of the automotive software system determine the functions that the ECU (Electronic Control Unit) needs to perform in different scenarios. In this embodiment, based on the vehicle domain controller configuration information and the functional scenario requirements of the automotive software system, the vehicle's functions can be divided into multiple different services. These services may include algorithms or methods for implementing specific branch functions, and then they can call each other through interfaces defined by the same specification to achieve functions in specific scenarios.

[0087] In addition, after dividing the functions into services, it is necessary to build models for a large number of different services, and then input the current actual parameters into the models for calculation, simulation, etc.

[0088] In step S220, based on the vehicle domain controller configuration information and the vehicle software system functional scenario requirements information, the vehicle functions are divided into multiple services, and the service interface configuration information corresponding to the multiple services is called.

[0089] It should be noted that the service interface configuration information includes: service list information, including service name, service interface name, service interface type, and interface parameter name; and interface parameter definition information, including interface parameter data type and interface parameter value definition. The description of service interface configuration information in this application embodiment is merely illustrative and not limited thereto. It is understood that in specific implementations outside of this application embodiment, other service interface configuration information may be determined according to the needs of the current scenario.

[0090] In step S230, based on the service interface configuration information and the pre-configured script, multiple initial model frameworks corresponding to multiple services are constructed, and initialization modules, main function modules, service call interfaces and notification interfaces are added to the multiple initial model frameworks to generate multiple complete automotive service model frameworks.

[0091] It should be noted that the service-oriented model framework generation process in this embodiment is implemented in an environment integrating Simulink and MATLAB. The pre-configured scripts are m-language scripts, which are program files with the .m extension. These files contain a series of commands to be executed together. The scripts do not accept input and do not return any output. They manipulate data in the MATLAB workspace. In this embodiment, m-language scripts are used to perform repetitive and systematic tasks such as parameter setting, module naming, parameter naming, and data type setting, further improving the efficiency of automotive software system development.

[0092] In addition, after the service-oriented model framework is generated, developers can add logic to the service call interface, add input to the main function module, and add logic to the main function module according to system requirements to complete the generation of the complete service-oriented model.

[0093] As can be seen from steps S210 to S230 above, the solution proposed in this embodiment generates a service-oriented model framework in the Simulink environment through m-language scripts. This can automatically complete repetitive and routine tasks in the development process of the service-oriented model framework, improving the development efficiency of the service-oriented model. In addition, the m-language scripts can also reduce low-level software defects in the development process, saving the overall time cost of software development projects under the automotive SOA architecture.

[0094] In one embodiment of this application, Figure 2 After calling the service interface configuration information corresponding to the multiple services in step S220, the following steps are also included:

[0095] The service list information is converted into a first variable, and the interface parameter definition information is converted into a second variable. The first and second variables are used for information invocation when adding the initialization module, main function module, service call interface and notification interface.

[0096] For example, service interface configuration information is transmitted via table data. Sheet1 stores the service inventory information, and Sheet2 stores the interface parameter definition information. The contents of the two tables are retrieved and read using an M-language script, and two variables are used to store the contents of the two tables in the Matlab workspace for later use.

[0097] In one embodiment of this application, Figure 2 Step S230, shown below, involves constructing multiple initial model frameworks corresponding to the multiple services, and adding initialization modules, main function modules, service call interfaces, and notification interfaces to the multiple initial model frameworks. This includes the following steps:

[0098] Call the first variable and iterate through the first variable to determine the service list information of the multiple services;

[0099] Based on the service list information of the multiple service lists and the second variable, an initial model framework corresponding to each service is constructed, and an initialization module, a main function module, a service call interface, and a notification interface are added to the initial model framework corresponding to each service.

[0100] For example, each service corresponds to a model. The service with different names is traversed through the first variable using the m-language script, and the initial model framework construction, module addition, and interface addition steps are performed for each service to avoid low-level software defects in the generation process of each service model framework.

[0101] In one embodiment of this application, after constructing the initial model framework corresponding to each service, the following steps are further included:

[0102] Each initial model framework is named according to the service name, resulting in multiple named initial model frameworks.

[0103] Based on the functional scenario requirements of the automotive software system, initial configuration parameters are set for the named initial model frameworks. The initial configuration parameters include at least one of solver type parameters, solver configuration parameters, and fixed step size.

[0104] It should be noted that after constructing the initial model framework, name the initial model framework after the name of the current service, and then configure the initial configuration parameters such as SolverType, Solver, and FixedStep according to the functional scenario requirements of the automotive software system. Among them, SolverType is the solver type parameter, Solver is the solver configuration parameter, and FixedStep is the fixed step size.

[0105] In this embodiment, the initial environment within the initial model framework is established by setting relevant parameters of the solver, preparing for the subsequent addition of modules and interfaces. The solver configuration affects the quality of the model generated in the Simulink environment. A solver is a set of programs provided by Simulink, with each solver representing a specific model solution method. A suitable solver for a model depends on the following characteristics: system dynamics, solution stability, computational speed, and solver robustness.

[0106] Solvers can be broadly classified according to two attributes:

[0107] (1) Classification by calculation step size type

[0108] Fixed-step solvers use the same step size from the start to the end of the simulation to solve the model. The step size can be specified or selected by the solver. Generally, decreasing the step size will improve the accuracy of the results but increase the simulation time. Variable-step solvers change the step size during the simulation. Variable-step solvers decrease the step size to improve accuracy for certain events (such as rapid state changes, zero-crossing events, etc.). Additionally, when the model state changes slowly, the solver will increase the step size to avoid performing unnecessary steps.

[0109] (2) Classification by model status

[0110] The continuous solver uses numerical integration to calculate the continuous state of the model at the current time step based on the model's state and state derivative at the previous time step. The continuous solver relies on a single module to calculate the discrete state values ​​of the model at each time step. The discrete solver is mainly used to solve purely discrete models, calculating only the model's next simulation time step.

[0111] In one embodiment of this application, an initialization module is added to the initial model framework corresponding to each service, including the following steps:

[0112] Add the initialization function from the pre-configured model building environment library to the first position in the initial model framework, and name the initialization function according to the service name and the preset first suffix;

[0113] Delete all content except the event listener in the named initialization function to complete the addition of the initialization module.

[0114] For example, add an initialization module to a specified location in the model. This involves adding the `InitializeFunction` from the Simulink library to the specified location, naming it with the service name followed by "_Init", and then deleting the built-in content of the initialization function, keeping only the `Event Listener`. Here, `InitializeFunction` is the initialization function, `_Init` is the first suffix, and `Event Listener` is the event listener.

[0115] In one embodiment of this application, a main function module is added to the initial model framework corresponding to each service, including the following steps:

[0116] An initial subsystem is added to the initial model framework. The initial subsystem is named according to the service name and a preset second suffix. The contents of the named initial subsystem are then deleted to obtain the target subsystem.

[0117] Add the first trigger to the target subsystem to obtain a preset trigger function and select and call the trigger type through the first trigger;

[0118] The first input submodule is added to the initial model framework, named according to the service name, and the running cycle of the first input submodule is set according to the preset cycle parameters to obtain the configured first input submodule.

[0119] Connect the configured first input submodule to the interface of the first trigger to complete the addition of the main function module.

[0120] For example, first, add a Subsystem, name it with the service name followed by "_Ctrl", and delete the built-in content of the Subsystem; then, add a Trigger to the Subsystem and set TriggerType to function-call; finally, add an input module In1, name it with "TMT10ms_" followed by the service name, set the execution period to 10ms, set OutputFunctionCall to ON and SampleTime to 0.01, and then connect In1 to the Trigger interface of the Subsystem. Here, Subsystem is the subsystem, _Ctrl is the second suffix, Trigger is the trigger, TriggerType is the trigger type, function-call is a function call (indicating that the trigger is selected and called through the trigger function), OutputFunctionCall is the output function call switch, and SampleTime is the sampling time.

[0121] In one embodiment of this application, the service call interface includes a first type of service call interface. Adding a service call interface to the initial model corresponding to each service includes the following steps:

[0122] Based on the service interface type in the service interface configuration information, determine whether the service call interface is a server-side response message interface or a client-side request to obtain status interface;

[0123] If the service call interface is a server-side response message interface or a client-side request to obtain status interface, then the service call interface is determined to be a first type of service call interface;

[0124] A first initial model building environment function is added to the initial model framework, and the first initial model building environment function is named according to the service name and the name of the first type of service call interface to obtain the first target model building environment function;

[0125] Delete all content in the first target model building environment function except for the second trigger, name the function of the second trigger according to the service name and the name of the first type of service call interface, and set the visibility of the second trigger to global visibility;

[0126] Based on the second variable, input and output parameters are added to the environment function of the first target model through the preset library paths of the input parameter module and the output parameter module, thereby completing the addition of the service call interface.

[0127] For example, the first type of service call interface consists of RR_Method and Setter class service call interfaces. For RR_Method and Setter class service call interfaces, a Simulink Function is added to the model, named with the service name followed by an underscore and the interface name. All built-in content is removed, leaving only the Trigger. The Trigger's FunctionName is set to the service name followed by an underscore and the interface name, and FunctionVisibility is set to global. Then, based on the interface's parameter information, input and output parameters are added to the Simulink Function. The library path for the input parameter module is "simulink / User-Defined Functions / Simulink Function / u", and the library path for the output parameter module is "simulink / User-Defined Functions / Simulink Function / y".

[0128] Among them, the RR_Method class service call interface is the interface for the server to reply with response messages, the Setter class service call interface is the interface for the client to request and obtain status, Simulink Function is the Simulink function, FunctionName is the function name, FunctionVisibility is the function visibility, and global is global visibility.

[0129] In one embodiment of this application, the step of adding input and output parameters to the environment function of the first target model based on the second variable through preset library paths of the input parameter module and the output parameter module includes the following steps:

[0130] Based on the name of the first service call interface, the target parameter in the input parameter module and the output parameter module is determined, and the parameter name of the target parameter is consistent with the name of the first service call interface;

[0131] Search for the name of the first service call interface in the second variable, determine the first data type of the configuration parameter corresponding to the first type of service call interface, and determine the data type string of the input parameter module and the output parameter module according to the first data type;

[0132] Based on the data type strings of the input parameter module and the output parameter module, the target parameters are transmitted to the first target model building environment function through the preset library paths of the input parameter module and the output parameter module.

[0133] For example, the ArgumentName of the parameter module is set to the parameter name of the interface in the first variable. Then, the data type of the parameter is obtained by searching for the parameter name in the parameter definition variable, and used to set the OutDataTypeStr of the parameter module. Here, ArgumentName is the function name, and OutDataTypeStr is the data type string.

[0134] In one embodiment of this application, the service call interface includes a second type of service call interface. Adding a service call interface to the initial model corresponding to each service includes the following steps:

[0135] Based on the service interface type in the service interface configuration information, determine whether the service call interface is a client request setting status interface;

[0136] If the service call interface is a client request to set status interface, then the service call interface is determined to be a second type of service call interface;

[0137] The second initial model building environment function is added to the initial model framework, and the second initial model building environment function is named according to the service name and the name of the second type of service call interface to obtain the second target model building environment function;

[0138] Delete all content in the second target model building environment function except for the second trigger, name the function of the second trigger according to the service name and the name of the second type of service call interface, and set the visibility of the second trigger to global visibility;

[0139] Based on the second variable, output parameters are added to the environment function of the second target model through the preset output parameter module library path;

[0140] Add a second input submodule to the second target model building environment function, and connect the notification interface of the main function module to the input interface of the second input submodule.

[0141] For example, the second type of service call interface is the Getter class service call interface. The Getter class service call interface is added in the same way as the RR_Method and Setter class service call interfaces, also by adding a Simulink Function. However, the Getter class service call interface only has output parameters. Since the output parameters of the Getter class service call interface are the event parameters of the notification, an In1 module needs to be added to this Simulink Function. Then, the notification interface of the main function module is connected to the input interface of the corresponding Getter class service call interface's Simulink Function, and a name is set on the connection line, named "IRV_" followed by the name of the notification Out1 module. The Getter class service call interface is the interface for the client to request setting the status.

[0142] In one embodiment of this application, the notification interface includes a first notification interface and a second notification interface. Adding a notification interface to the plurality of initial model frameworks includes the following steps:

[0143] Add a first initial output submodule to the main function module, and name the first initial output submodule according to the service name and the name of the notification interface to obtain the first target output submodule;

[0144] Search for the parameter name of the notification interface in the second variable, determine the second data type of the parameter corresponding to the notification interface, and set the data type string of the first target output submodule through the second data type to complete the addition of the first notification interface inside the main function module;

[0145] Search all output sub-modules in the main function module, add a second notification interface outside the main function module according to the search results, and connect the first notification interface and the second notification interface with the same name to complete the addition of the notification interface.

[0146] For example, first, add an output module named Out1 in the main function module, also named after the service name followed by an underscore and the interface name. Then, search for the event parameter name of this notification interface in the second variable to obtain the data type of the parameter, which is used to set the OutDataTypeStr of the output module Out1. By searching all Out1 modules in the main function module, add another notification interface outside the main function module and connect the interfaces with the same name.

[0147] In one embodiment of this application, after connecting the first notification interface and the second notification interface with the same name, the following steps are further included:

[0148] Connect the second type of service call interface to the corresponding notification interface, and ensure that the output parameters of the second type of service call interface are consistent with the input parameters of the notification interface.

[0149] For example, in the interface design, the Getter class service call interface and the notification interface are mapped one-to-one, and the output parameters of the Getter class service call interface and the event parameters of the notification interface are consistent. In this embodiment, when adding a notification interface outside the main function module, the corresponding Getter class service call interface can be added at the same time.

[0150] Figure 3 This is a block diagram illustrating an automotive service model framework generation apparatus according to an exemplary embodiment of this application. The apparatus can be applied to... Figure 1 The implementation environment shown is not limited to this embodiment. This device can also be applied to other exemplary implementation environments and specifically configured in other devices. This embodiment does not limit the implementation environment to which the device is applicable.

[0151] like Figure 3 As shown, the exemplary vehicle service model framework generation apparatus includes:

[0152] The information acquisition module 301 is used to acquire vehicle domain controller configuration information and vehicle software system functional scenario requirements information;

[0153] The service interface configuration information determination module 302 is used to divide the vehicle functions into multiple services based on the vehicle domain controller configuration information and the vehicle software system functional scenario requirements information, and call the service interface configuration information corresponding to the multiple services.

[0154] The model generation module 303 is used to construct multiple initial model frameworks corresponding to the multiple services based on the service interface configuration information and pre-configured scripts, and to add an initialization module, a main function module, a service call interface and a notification interface to the multiple initial model frameworks to generate multiple complete automotive service model frameworks.

[0155] In this exemplary automotive service model framework generation device, the service model framework is generated in the Simulink environment using m-language scripts. This automatically completes repetitive and routine tasks in the service model framework development process, improving the development efficiency of the service model. In addition, the m-language can also reduce low-level software defects in the development process, thus saving overall time costs for software development projects under the automotive SOA architecture.

[0156] It should be noted that the vehicle service model framework generation device and the vehicle service model framework generation method provided in the above embodiments belong to the same concept. The specific ways in which each module and unit performs operations have been described in detail in the method embodiments and will not be repeated here. In practical applications, the vehicle service model framework generation device provided in the above embodiments can allocate the above functions to different functional modules as needed, that is, divide the internal structure of the device into different functional modules to complete all or part of the functions described above, and this is not a limitation here.

[0157] Embodiments of this application also provide an electronic device, including: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to implement the automotive service model framework generation method provided in the above embodiments.

[0158] Figure 4 A schematic diagram of a computer system suitable for an electronic device according to an embodiment of this application is shown. It should be noted that... Figure 4 The computer system 400 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0159] like Figure 4 As shown, the computer system 400 includes a Central Processing Unit (CPU) 401, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 402 or programs loaded from Storage Unit 408 into Random Access Memory (RAM) 403, such as performing the methods described in the above embodiments. The RAM 403 also stores various programs and data required for system operation. The CPU 401, ROM 402, and RAM 403 are interconnected via a bus 404. An Input / Output (I / O) interface 405 is also connected to the bus 404.

[0160] The following components are connected to I / O interface 405: an input section 406 including a keyboard, mouse, etc.; an output section 407 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 408 including a hard disk, etc.; and a communication section 409 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 409 performs communication processing via a network such as the Internet. A drive 410 is also connected to I / O interface 405 as needed. A removable medium 411, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 410 as needed so that computer programs read from it can be installed into storage section 408 as needed.

[0161] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 409, and / or installed from removable medium 411. When the computer program is executed by central processing unit (CPU) 401, it performs various functions defined in the system of this application.

[0162] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0163] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0164] The units involved in the embodiments described in this application may be implemented by software or hardware, and the units described may also be set in a processor. In some cases, the names of these units do not constitute limitations on the units themselves.

[0165] Another aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a computer's processor, causes the computer to perform the aforementioned automotive service model framework generation method. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently and not assembled into the electronic device.

[0166] Another aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the automotive service model framework generation method provided in the various embodiments described above.

[0167] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the invention. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in the present invention should still be covered by the claims of the present invention.

Claims

1. A method for generating a service-oriented model framework for automobiles, characterized in that, The method comprises: Obtain vehicle domain controller configuration information and vehicle software system functional scenario requirements information; Based on the vehicle domain controller configuration information and the vehicle software system functional scenario requirements information, the vehicle functions are divided into multiple services, and the service interface configuration information corresponding to the multiple services is called. Based on the service interface configuration information and pre-configured scripts, construct multiple initial model frameworks corresponding to the multiple services, and add initialization modules, main function modules, service call interfaces and notification interfaces to the multiple initial model frameworks to generate multiple complete automotive service model frameworks; The service interface configuration information includes: Service list information, which includes service name, service interface name, service interface type, and interface parameter name; Interface parameter definition information, which includes interface parameter data type and interface parameter numerical definition; After invoking the service interface configuration information corresponding to the multiple services, the process also includes: The service list information is converted into a first variable, and the interface parameter definition information is converted into a second variable. The first and second variables are used for information invocation when adding the initialization module, main function module, service call interface and notification interface. Add a main function module to the initial model framework corresponding to each service, including: An initial subsystem is added to the initial model framework. The initial subsystem is named according to the service name and a preset second suffix. The contents of the named initial subsystem are then deleted to obtain the target subsystem. Add the first trigger to the target subsystem to obtain a preset trigger function and select and call the trigger type through the first trigger; The first input submodule is added to the initial model framework, named according to the service name, and the running cycle of the first input submodule is set according to the preset cycle parameters to obtain the configured first input submodule. Connect the configured first input submodule to the interface of the first trigger to complete the addition of the main function module.

2. The method for generating a vehicle service model framework according to claim 1, characterized in that, Construct multiple initial model frameworks corresponding to the multiple services, and add initialization modules, main function modules, service call interfaces, and notification interfaces to the multiple initial model frameworks, including: Call the first variable and iterate through the first variable to determine the service list information of the multiple services; Based on the service list information of the multiple service lists and the second variable, an initial model framework corresponding to each service is constructed, and an initialization module, a main function module, a service call interface, and a notification interface are added to the initial model framework corresponding to each service.

3. The method for generating a vehicle service model framework according to claim 2, characterized in that, After constructing the initial model framework for each service, the following is also included: Each initial model framework is named according to the service name, resulting in multiple named initial model frameworks. Based on the functional scenario requirements of the automotive software system, initial configuration parameters are set for the named initial model frameworks. The initial configuration parameters include at least one of solver type parameters, solver configuration parameters, and fixed step size.

4. The method for generating a vehicle service model framework according to claim 2, characterized in that, The step of adding an initialization module to the initial model framework corresponding to each service includes: Add the initialization function from the pre-configured model building environment library to the first position in the initial model framework, and name the initialization function according to the service name and the preset first suffix; Delete all content except the event listener in the named initialization function to complete the addition of the initialization module.

5. The method for generating a vehicle service model framework according to claim 2, characterized in that, The service call interface includes a first type of service call interface, which adds a service call interface to the initial model corresponding to each service, including: Based on the service interface type in the service interface configuration information, determine whether the service call interface is a server-side response message interface or a client-side request to obtain status interface; If the service call interface is a server-side response message interface or a client-side request to obtain status interface, then the service call interface is determined to be a first type of service call interface; A first initial model building environment function is added to the initial model framework, and the first initial model building environment function is named according to the service name and the name of the first type of service call interface to obtain the first target model building environment function; Delete all content in the first target model building environment function except for the second trigger, name the function of the second trigger according to the service name and the name of the first type of service call interface, and set the visibility of the second trigger to global visibility; Based on the second variable, input and output parameters are added to the environment function of the first target model through the preset library paths of the input parameter module and the output parameter module, thereby completing the addition of the service call interface.

6. The method for generating a vehicle service model framework according to claim 5, characterized in that, The step of adding input and output parameters to the environment function of the first target model based on the second variable and through the preset library paths of the input parameter module and output parameter module includes: Based on the name of the first type of service call interface, the target parameter in the input parameter module and the output parameter module is determined, and the parameter name of the target parameter is consistent with the name of the first type of service call interface; Search for the name of the first type of service call interface in the second variable, determine the first data type of the configuration parameter corresponding to the first type of service call interface, and determine the data type string of the input parameter module and the output parameter module according to the first data type; Based on the data type strings of the input parameter module and the output parameter module, the target parameters are transmitted to the first target model building environment function through the preset library paths of the input parameter module and the output parameter module.

7. The method for generating a vehicle service model framework according to claim 2 or 1, characterized in that, The service call interface includes a second type of service call interface, which is added to the initial model corresponding to each service, including: Based on the service interface type in the service interface configuration information, determine whether the service call interface is a client request setting status interface; If the service call interface is a client request to set status interface, then the service call interface is determined to be a second type of service call interface; The second initial model building environment function is added to the initial model framework, and the second initial model building environment function is named according to the service name and the name of the second type of service call interface to obtain the second target model building environment function; Delete all content in the second target model building environment function except for the second trigger, name the function of the second trigger according to the service name and the name of the second type of service call interface, and set the visibility of the second trigger to global visibility; Based on the second variable, output parameters are added to the environment function of the second target model through the preset output parameter module library path; Add a second input submodule to the second target model building environment function, and connect the notification interface of the main function module to the input interface of the second input submodule.

8. The method for generating a vehicle service model framework according to claim 7, characterized in that, The notification interface includes a first notification interface and a second notification interface. Adding a notification interface to the plurality of initial model frameworks includes: Add a first initial output submodule to the main function module, and name the first initial output submodule according to the service name and the name of the notification interface to obtain the first target output submodule; Search for the parameter name of the notification interface in the second variable, determine the second data type of the parameter corresponding to the notification interface, and set the data type string of the first target output submodule through the second data type to complete the addition of the first notification interface inside the main function module; Search all output sub-modules in the main function module, add a second notification interface outside the main function module according to the search results, and connect the first notification interface and the second notification interface with the same name to complete the addition of the notification interface.

9. The method for generating a vehicle service model framework according to claim 8, characterized in that, After connecting the first notification interface and the second notification interface with the same name, the method further includes: Connect the second type of service call interface to the corresponding notification interface, and ensure that the output parameters of the second type of service call interface are consistent with the input parameters of the notification interface.

10. A vehicle service model framework generation device, characterized in that, The device comprises: The information acquisition module is used to acquire vehicle domain controller configuration information and vehicle software system functional scenario requirements information; The service interface configuration information determination module is used to divide the vehicle functions into multiple services based on the vehicle domain controller configuration information and the vehicle software system functional scenario requirements information, and to call the service interface configuration information corresponding to the multiple services. The service interface configuration information includes service list information and interface parameter definition information. The service list information includes service name, service interface name, service interface type, and interface parameter name. The interface parameter definition information includes interface parameter data type and interface parameter value definition. The module is also used to convert the service list information into a first variable and the interface parameter definition information into a second variable. The first and second variables are used for information invocation when adding initialization modules, main function modules, service call interfaces, and notification interfaces. The model generation module is used to construct multiple initial model frameworks corresponding to the multiple services based on the service interface configuration information and pre-configured scripts, and to add an initialization module, a main function module, a service call interface, and a notification interface to the multiple initial model frameworks to generate multiple complete automotive service model frameworks. Specifically, it is used to add an initial subsystem to the initial model framework, name the initial subsystem according to the service name and a preset second suffix, and delete the content in the named initial subsystem to obtain a target subsystem; add a first trigger to the target subsystem to obtain a preset trigger function and select and call the trigger type through the first trigger; add a first input submodule to the initial model framework, name the first input submodule according to the service name, and set the running cycle of the first input submodule according to a preset cycle parameter to obtain a configured first input submodule; connect the configured first input submodule to the interface of the first trigger to complete the addition of the main function module.

11. An electronic device, characterized in that, The electronic device includes: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the electronic device to implement the automotive service model framework generation method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by the computer's processor, causes the computer to perform the automotive service model framework generation method as described in any one of claims 1 to 9.

Images