Method and device for generating service framework model

By obtaining service information from the system service design information file of the vehicle operating system, generating service model design information file, and generating service framework model, the problem that the vehicle operating system service code cannot be imported into MBD software is solved, and services for the vehicle operating system are developed based on MBD are realized, reducing the development complexity.

CN119938025APending Publication Date: 2025-05-06ZHEJIANG ZEEKR INTELLIGENT TECH CO LTD +1
View PDF 0 Cites 1 Cited by

Patent Information

Application Number
CN202510004293.9
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-01-02
Publication Date
2025-05-06

AI Technical Summary

Technical Problem

It is difficult for the existing technology to import the code of related services that need to be developed in the vehicle operating system into model-based design (MBD) software, resulting in the inability to implement services for designing and developing the vehicle operating system based on MBD.

Method used

By obtaining service information from the system service design information file of the vehicle operating system, generating a service model design information file, and generating a service framework model based on the file, in order to realize the services provided by the vehicle operating system based on MBD.

Benefits of technology

It realizes importing the code of the vehicle operating system service into the MBD software, reducing the complexity of the vehicle operating system development and improving the development efficiency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119938025A_ABST
    Figure CN119938025A_ABST
Patent Text Reader

Abstract

The invention provides a service framework model generation method and device, and the method comprises the steps: obtaining the service information of a service provided by a whole vehicle operation system from a system service design information file of the whole vehicle operation system, and enabling the whole vehicle operation system to adopt an SOA software architecture; generating a service model design information file of the whole vehicle operation system according to the service information of the service provided by the whole vehicle operation system; according to the service model design information file, a service framework model is generated, and the service framework model is used for designing services provided by the whole vehicle operation system based on MBD. According to the scheme, services in the whole vehicle operation system can be designed based on MBD, and the development complexity of the whole vehicle operation system is further reduced.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method and device for generating a service framework model. Background Art

[0002] Model-Based Design (MBD) is a system design method. The core idea of ​​this design method is to express the functional and performance requirements of the system through graphical or mathematical models, and then automatically generate code to implement these models. Common MBD software includes MATLAB / Simlink, etc. The vehicle operating system is a program that manages the hardware and software resources of the vehicle's onboard computer. Some vehicle operating systems adopt a service-oriented architecture (SOA). With the development of vehicle electrification, intelligence, and networking, the design and development of services in the vehicle operating system is becoming increasingly important.

[0003] For the development and design of vehicle operating systems, relevant technologies propose to directly use MBD software to develop and design services for vehicle operating systems, which helps to simplify the design difficulty of vehicle operating systems. However, the codes corresponding to the relevant services that need to be developed in the vehicle operating system cannot be directly imported into the MBD software, making it impossible to develop a vehicle operating system based on MBD design. Summary of the invention

[0004] The embodiment of the present application provides a method and device for generating a service framework model, which is introduced from the following aspects.

[0005] In a first aspect, a method for generating a service framework model is provided, comprising: obtaining service information of services provided by a whole vehicle operating system from a system service design information file of the whole vehicle operating system, wherein the whole vehicle operating system adopts a SOA software architecture; generating a service model design information file of the whole vehicle operating system according to the service information of services provided by the whole vehicle operating system; generating a service framework model according to the service model design information file, wherein the service framework model is used to design the services provided by the whole vehicle operating system based on MBD.

[0006] As a possible implementation method, the service model design information file of the whole vehicle operating system is generated according to the service information of the services provided by the whole vehicle operating system, including: generating the service model design information file according to the service information and configuration information of the services provided by the whole vehicle operating system, wherein the configuration information indicates one or more of the following: the service to be configured in the service provided by the whole vehicle operating system; the execution method of the method included in the service to be configured; the return method of the method included in the service to be configured; and whether to generate a status callback function for the method in the service to be configured.

[0007] As a possible implementation method, the method also includes: generating a service framework code for the whole vehicle operating system based on a system service design information file of the whole vehicle operating system; generating a business model of the whole vehicle operating system based on the service framework model and the business logic of the whole vehicle operating system; generating an interface code based on a service model design information file of the whole vehicle operating system, wherein the interface code is used to splice the service framework code of the whole vehicle operating system with the code of the business model.

[0008] As a possible implementation manner, generating a service framework model according to a service model design information file includes: converting data types in the service model design information file into data types supported by the service framework model.

[0009] As a possible implementation method, the service information of the service provided by the vehicle operating system includes one or more of the following: the name of the method interface in the service; the data type of the method interface in the service; the function prototype of the method interface in the service; the name of the subject interface in the service; and the data type of the subject interface in the service.

[0010] In a second aspect, a device for generating a service framework model is provided, comprising: an acquisition unit, used to acquire service information of services provided by a whole vehicle operating system from a system service design information file of the whole vehicle operating system, wherein the whole vehicle operating system adopts the SOA software architecture; a processing unit, used to generate a service model design information file of the whole vehicle operating system according to the service information of services provided by the whole vehicle operating system; the processing unit is used to generate a service framework model according to the service model design information file, and the service framework model is used to design the services provided by the whole vehicle operating system based on MBD.

[0011] As a possible implementation method, the processing unit is used to generate the service model design information file based on the service information and configuration information of the services provided by the vehicle operating system, wherein the configuration information indicates one or more of the following: the services to be configured in the services provided by the vehicle operating system; the execution method of the methods included in the services to be configured; the return method of the methods included in the services to be configured; and whether to generate a status callback function for the methods in the services to be configured.

[0012] As a possible implementation method, the processing unit is used to: generate a service framework code for the whole vehicle operating system based on a system service design information file of the whole vehicle operating system; generate a business model for the whole vehicle operating system based on the service framework model and the business logic of the whole vehicle operating system; generate an interface code based on a service model design information file of the whole vehicle operating system, and the interface code is used to splice the service framework code of the whole vehicle operating system with the code of the business model.

[0013] As a possible implementation manner, the processing unit is used to: convert the data type in the service model design information file into a data type supported by the service framework model.

[0014] As a possible implementation method, the service information of the service provided by the vehicle operating system includes one or more of the following: the name of the method interface in the service; the data type of the method interface in the service; the function prototype of the method interface in the service; the name of the subject interface in the service; and the data type of the subject interface in the service.

[0015] In a third aspect, a computing device is provided, comprising a processor and a memory, wherein the memory is used to store a computer program, and the processor is used to call and run the computer program from the memory, so that the computing device executes the method in the first aspect.

[0016] According to a fourth aspect, a computer program product is provided, the computer program product comprising: a computer program code, when the computer program code is run on a computer, the computer executes the method in the first aspect.

[0017] In a fifth aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores a program code, and when the computer program code is executed on a computer, the computer executes the method in the first aspect.

[0018] This application obtains relevant service information from the system service design information file of the vehicle operating system, generates a service model design information file based on the service information, and then generates a service framework model based on the service model design information file. This helps to implement MBD-based design of services in the vehicle operating system to reduce the complexity of vehicle operating system development. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 It is a workflow diagram of methods in SOA.

[0020] Figure 2 It is a workflow diagram of Topics in SOA.

[0021] Figure 3 It is a flow chart of the method for generating a service framework model provided in an embodiment of the present application.

[0022] Figure 4A This is a workflow diagram of the synchronous calling method.

[0023] Figure 4B This is a workflow diagram of the asynchronous calling method.

[0024] Figure 4C This is a workflow diagram of a call method that does not require a return.

[0025] Figure 5 It is a schematic diagram of the configuration of services by developers provided in an embodiment of the present application.

[0026] Figure 6 It is a flowchart of using conversion tools to design services in a vehicle operating system provided in an embodiment of the present application.

[0027] Figure 7 It is an interface structure diagram of the project compilation and operation in the conversion tool provided in the embodiment of the present application.

[0028] Figure 8 It is a structural diagram of a device for generating a service framework model provided in an embodiment of the present application.

[0029] Fig. 9 It is a schematic block diagram of a computing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0030] The technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments.

[0031] MBD is a system design method that focuses on using mathematical models to capture, analyze, design and verify the behavior of complex systems. The core idea of ​​this design method is to express the functional and performance requirements of the system through graphical or mathematical models, and then automatically generate code to implement these models.

[0032] MBD is widely used in control engineering, signal processing, communication systems, automotive electronics, aerospace and other fields. In the field of automotive electronics, MBD-based design specifically refers to the way of using MATLAB and / or Simulink models for software development. Simulink is a model-based design tool, that is, a graphical tool that can perform modeling and simulation. Developers can use Simulink for algorithm development, system simulation, testing, and code generation (such as C, C++). For developers, there is no need to write a lot of programs. Complex systems can be constructed through simple and intuitive mouse operations. In short, MBD-based design provides a direct conversion method from model to code, which helps improve development efficiency, reduce errors, and allows developers to deal with design problems of complex systems in a more abstract way.

[0033] The vehicle operating system is a program that manages the hardware and software resources of the vehicle's onboard computer. It is the core and cornerstone of the computer system. With the development of vehicle electrification, intelligence, and networking, the vehicle operating system has become one of the important components of the vehicle. The vehicle operating system usually includes a safe vehicle operating system, an intelligent driving operating system, and an intelligent cockpit operating system, which largely determine the safety, comfort, intelligence level, and overall performance of the vehicle. In short, the vehicle operating system not only manages various hardware devices of the vehicle, but also provides a wealth of interfaces so that developers or other software can easily use these resources.

[0034] For the vehicle operating system, a variety of software architectures can be used, such as SOA architecture, microservice architecture, microkernel architecture, hierarchical architecture, event-driven architecture, etc. These software architectures have their own characteristics and are suitable for different application scenarios and requirements. The developers of the vehicle operating system can choose the appropriate software architecture based on specific functional requirements and technical background.

[0035] The SOA architecture refers to a software architecture that provides componentized services through the network to meet the complex needs of business processes. It can also be understood as a method of reusing software components through service interfaces. In the SOA architecture, different services are independent and do not depend on each other. Through standard service interfaces and communication protocols, these services are connected and called at any time. These service interfaces are defined in a standardized way. Therefore, no matter what the hardware platform, operating system and programming language that implements these services are, it will not affect the calling and combination of different services.

[0036] In some implementations, a service may include one or more methods and / or one or more topics. These methods and topics can be understood as interfaces provided or consumed by the program that implements the service. In other words, the party that provides the interface to the outside world can be called a provider, and correspondingly, the party that calls the interface can be called a consumer. Figure 1 and Figure 2 Explain the methodology and subject workflow.

[0037] Figure 1 This is a schematic diagram of the workflow of the method in SOA applicable to the embodiment of the present application. Figure 1 As shown, the method has several input parameters and output parameters, each of which has a specific data type. When the service consumer 110 needs to request a method, the input parameters will be passed to the provider 120. After receiving the parameters, the provider 120 will perform certain processing and then convert them into output parameters, and pass the output parameters to the consumer 110 as a response.

[0038] Figure 2 The following is a workflow diagram of topics in SOA to which the present application is applicable. In some SOA implementations, topics can be viewed as a logical grouping for organizing and classifying services. Topics can help manage and discover services, especially in large systems with a large number of services, where topics can make it easier to find related services.

[0039] In some implementations, topics can also be associated with messaging and event-driven architecture (EDA). In this architecture, services communicate by publishing and subscribing to specific topics. In this case, a topic is a channel in a messaging system through which services publish events or receive events. See Figure 2 As shown, the consumer 210 will send a subscription request to the provider 220 according to actual needs, indicating a request to subscribe to the required topic. The provider 220 will respond immediately after receiving the subscription request, and send a message notification to all subscribed consumers 210 when the topic content is updated later.

[0040] As mentioned above, MBD can be used for the development and design of vehicle operating systems, which helps to simplify the design difficulty of vehicle operating systems. However, the codes corresponding to the relevant services that need to be developed in the vehicle operating system cannot be directly imported into the MBD software, making it impossible to develop a vehicle operating system based on MBD design.

[0041] For example, the code logic of MBD does not match the code logic of the vehicle operating system. Taking MBD based on Simulink as an example, if the developer wants to design and develop a service in the vehicle operating system, the developer needs to import the relevant code of the service in the vehicle operating system into Simulink for design and development. However, the vehicle operating system has its own set of code generation logic, and Simulink also has a fixed set of code generation logic. These two sets of code generation logic are usually incompatible. Therefore, the code of the vehicle operating system cannot be directly imported into Simulink software for development or design.

[0042] For another example, the interface of MBD does not match the interface of the vehicle operating system. Taking MBD based on Simulink as an example, if the developer wants to design and develop a service in the vehicle operating system, the developer needs to import the relevant code of the service in the vehicle operating system into Simulink for design and development. However, the vehicle operating system has its unified communication interface, through which the communication function is realized. For Simulink, after the developer designs the business model, Simulink will use a fixed set of templates to generate the corresponding function interface. These two interfaces are usually incompatible, so the code of the vehicle operating system cannot be directly imported into the Simulink software for development or design.

[0043] In view of the above-mentioned problems, the embodiment of the present application obtains relevant service information from the system service design information file of the vehicle operating system, generates a service model design information file based on the service information, and then generates a service framework model based on the service model design information file, so as to design the service of the vehicle operating system. This solution helps to implement the design of services in the vehicle operating system based on MBD, and further reduces the complexity of the development of the vehicle operating system.

[0044] Combine the following Figure 3 A method for generating a service framework model according to an embodiment of the present application is introduced. Figure 3 The method shown can be implemented by a service-oriented model building tool (SOa Model Composer, SOMOC), which can also be called a conversion tool. Of course, in the embodiment of the present application, Figure 3 The method shown can also be implemented by other related software with service-oriented model building function (conversion function).

[0045] In some implementations, Figure 3 The method shown can be performed by a computing device. For example, the computing device can be a calculator, a server, etc. Of course, in the embodiment of the present application, Figure 3 The method shown may also be executed by other devices having related functions.

[0046] See also Figure 3 As shown, Figure 3 The method shown includes steps S310 to S330.

[0047] In step S310, service information of services provided by the vehicle operating system is obtained from the system service design information file of the vehicle operating system.

[0048] In some implementations, the system service design information file may be an Architecture eXtensible Markup Language (ARXML) file, which is designed and provided by the vehicle operating system architecture. The system service design information file is a common configuration file or database file in the automotive electronics application field, used to transmit and store automotive electronics data.

[0049] In some implementations, the system service design information file contains relevant information about the service. For example, for a method, the system service design information file includes one or more of the following: the name of the method interface, the function prototype of the method interface, and the data type of the method interface. Among them, the name of the method interface is used to call the method interface in the code, and the function prototype of the method interface is used to indicate the name, return type, parameter type, and number of parameters of the method interface. The data type of the method interface may include, for example, one or more of the following: Boolean, integer, floating point, enumeration, structure, and alias.

[0050] For another example, for a subject, the system service design information file includes one or more of the following: the name of the subject interface, the data type of the subject interface. The name of the subject interface is used to call the subject interface in the code, and the data type of the subject interface may include one or more of the following: Boolean, integer, floating point, enumeration, structure, and alias.

[0051] Accordingly, the service information obtained from the system service design information file may include the name of the method interface, the function prototype of the method interface, the data type of the method interface, the name of the subject interface, and the data type of the subject interface.

[0052] In the embodiments of the present application, there is no limitation on the method for obtaining the service information of the services provided by the vehicle operating system. In some implementations, self-developed tools can be used to parse the ARXML file, such as the service model building tool mentioned above. In other implementations, currently mature tools for parsing ARXML documents can be used, such as Vector Davinci Developer, Autosar Explore, etc. By importing the ARXML file into a tool that supports its file format, the service information of the services provided by the vehicle operating system can be obtained.

[0053] In step S320, a service model design information file of the vehicle operating system is generated according to the service information of the services provided by the vehicle operating system.

[0054] In some implementations, service information can be understood as information related to services provided by the vehicle operating system that is extracted to construct a service model design information file. Accordingly, the service model design information file is used for the model corresponding to the service constructed in the MBD software, or in other words, the service model design information file contains information required for the model corresponding to the service constructed in the MBD software.

[0055] In some implementations, the service model design information file may be a JavaScript Object Notation (JSON) file.

[0056] In step S330, a service framework model is generated according to the service model design information file.

[0057] In some implementations, the service framework model is used to design services provided by the vehicle operating system based on MBD. In other words, the service framework model can be used to design and develop the vehicle operating system based on MBD.

[0058] In some implementations, the above step S320 may include: generating a service model design information file based on the service information and configuration information of the services provided by the vehicle operating system.

[0059] In some implementations, the configuration information indicates one or more of the following: the services to be configured among the services provided by the vehicle operating system; the execution method of the methods included in the services to be configured; the return method of the methods included in the services to be configured; and whether to generate a status callback function for the methods in the services to be configured.

[0060] The execution mode of the method included in the service to be configured may be a synchronous call mode (Sync), an asynchronous call mode (Async), or a call mode without return (No Return). The return mode of the method included in the service to be configured may be an immediate return mode or a conditional return mode.

[0061] In some implementations, the above configuration information can be user-configured, that is, in the process of generating the service model design information file, in addition to the service information, the developer's configuration information can also be considered, which helps developers to personalize different services and implement different service interfaces according to different scenarios during the software development process, further speeding up the development process.

[0062] In some implementations, developers can configure one or more of the following in the service: how the methods included in the service are executed, how the methods included in the service return, and whether to generate a status callback function for the methods of the service to be configured.

[0063] For ease of understanding, the following Figure 4A , Figure 4B as well as Figure 4C This section describes how to execute and return the methods contained in the service to be configured.

[0064] Figure 4A This is a workflow diagram of the synchronous call method. When the consumer 410 sends a request, it must wait for the provider 420 to complete the processing and respond (which can be understood as an immediate return) before continuing to perform subsequent operations. The synchronous call method is suitable for operations with a short execution time or high real-time requirements, thereby ensuring the order and timeliness of the operations.

[0065] Figure 4B This is a workflow diagram of the asynchronous call method. When the consumer 410 sends a request, it does not need to wait for the provider 420 to complete the processing, but can continue to perform other tasks. When the provider 420 completes the processing (it can be understood that the provider waits for the condition to be met), it responds to the consumer 410 and notifies the consumer 410 of the processing result through callback functions, events, message queues, etc. Finally, the consumer 410 executes the callback function. The asynchronous call method is suitable for operations that take a long time to execute or require improved program responsiveness. The consumer 410 does not need to wait for the response of the provider 420, which can further improve the concurrency and efficiency of the program.

[0066] Figure 4CThis is a diagram of a call method without return, which is a special asynchronous call method. After the consumer 410 sends a request, it does not need to care about the processing result of the provider 420, nor does it need to wait for any response, but can continue to perform other tasks. The call method without return is suitable for operations that do not care about the result or the processing result has no effect on the consumer 410, such as logging and event publishing. For developers, how to choose the execution mode and return mode of the method included in the service to be configured depends on specific business needs and performance requirements.

[0067] In some implementations, one or more of the execution mode of the methods included in the above services, the return mode of the methods included in the services, and whether to generate a status callback function for the methods of the services to be configured may be referred to as service configuration items. Accordingly, the above service configuration items may be presented in a tree structure in the user interface to simplify the complexity of service configuration for developers. Figure 5 Make an introduction.

[0068] Figure 5 This is a schematic diagram of the developer configuring the service in the embodiment of this application. Figure 5 As shown, in the configured user interface, a service instance 510, an application software component (ASWC) tree 520, a periodic execution module 530, etc. can be presented. Among them, the service instance 510 contains services to be configured, such as service 1, service 2, service 3, etc. The ASWC tree 520 contains the name of each service and the methods and topics it contains, and each method and topic contains corresponding functions. Taking the method as an example, it can contain related functions, such as getIntParameter_sync, getIntParameters_sync, setIntParameter_sync, setIntParameters_sync, etc. The name of the service, the methods and topics contained in each service, and the related functions contained in each method and topic are presented to the developer in the form of a tree structure as a whole. For the periodic execution module 530, the module contains an execution cycle and a start execution time. Among them, the execution cycle represents a complete time period implemented by the module, and the start execution time represents the start time of the module execution.

[0069] Developers can Figure 5The service configuration items in the configuration are executed. In the service instance 510, the developer can select the service name that he wants to configure. After selecting and determining the service name, the developer can select the method and / or subject that needs to be configured in the ASWC tree 520 in combination with actual business needs, and then check the box in front of the method and / or subject. After selecting the method and / or subject, you can also check the many function names contained in the method and / or subject. Only after checking will the corresponding service interface be generated. In addition, the developer can also set the execution cycle and start execution time in the periodic execution module 530 by setting numbers in the corresponding input boxes.

[0070] In addition to Figure 5 You can also configure the three calling methods of the consumer method (such as synchronous calling method, asynchronous calling method, and calling method without return), the two execution methods of the provider method (immediate return method, conditional return method), whether the consumer generates a status callback function, the maximum length of a variable-length array, etc. For the three calling methods of the consumer method and the two execution methods of the provider method, please refer to the above.

[0071] In some scenarios, the data types based on MBD do not match the data types of the vehicle operating system. MBD uses a fixed-length array data type, while the vehicle operating system uses a variable-length array data type. During the code implementation process, fixed-length arrays and variable-length arrays are incompatible, so corresponding adaptation solutions are also required. In some implementations, in the process of generating a service framework model based on a service model design information file, the data types in the service model design information file can be converted to data types supported by the service framework model to match the two.

[0072] For example, the vehicle operating system uses a variable-length array data type, that is, the service model design information file also uses a variable-length array data type, while the MBD uses a fixed-length array data type. Developers can configure the maximum length of the variable-length array in the service model design information file, so that fixed-length arrays can be used instead of variable-length arrays during the conversion to the service framework model. By converting the data type in the service model design information file to a data type supported by the service framework model, the vehicle operating system and MBD can be further matched, which will help to design and develop services for the vehicle operating system based on MBD in the future.

[0073] For developers, after obtaining the service framework model, they can add business logic on this basis to generate the business model required by the developer. However, there are some basic functions in the process of designing and implementing the business model, which have been implemented in the vehicle operating system. Therefore, in some implementation methods, developers can encapsulate some basic functions of the vehicle operating system middleware, such as persistent storage, logging, diagnostic management, state management, etc., to facilitate developers to directly use the encapsulated corresponding basic functions in the business model, and pass the corresponding configuration information to the corresponding basic functions through the parameters of the module encapsulation. Taking the log function as an example, when developers also need to implement the log function in the process of implementing the business logic, there is no need to think about how to implement the log function separately, just call it from the encapsulation library. This implementation method can improve the ability to customize the business model, further simplify the development process, and reduce the complexity of development.

[0074] Since MBD does not match the vehicle operating system, the code generated based on MBD cannot be directly applied to the vehicle operating system. In an embodiment of the present application, with regard to the code implementation level, the service framework code of the vehicle operating system can be generated based on the system service design information file of the vehicle operating system. Afterwards, the business model of the vehicle operating system is generated based on the service framework model and the business logic of the vehicle operating system. Finally, based on the service model design information file of the vehicle operating system, interface code is generated to splice the service framework code of the vehicle operating system with the code of the business model. Through this series of operations, the service framework code of the vehicle operating system and the code of the business model are spliced ​​and integrated, so that the code generated based on the MBD design can be applied to the vehicle operating system, that is, the code of the services related to the vehicle operating system can be imported into MBD.

[0075] After obtaining the complete spliced ​​code, it is necessary to perform certain operations on the code to convert it from the original source code to the final executable file. In some implementations, the compilation and runtime environment provided by the software development kit (SDK) in the vehicle operating system can be used. For example, the service framework code of the vehicle operating system is spliced ​​with the code of the business model through the interface code. For the spliced ​​code, the software development kit in the vehicle operating system can be used to compile and generate an executable file. After that, the software development kit of the vehicle operating system can continue to be used to run the executable file on the operating system. By integrating the compilation and runtime environment for service-oriented code provided by the vehicle operating system, the development efficiency of developers is further improved.

[0076] For ease of understanding, the following uses the SOMOC conversion tool and the Simulink model-based design as an example. Figure 6The method for designing a service for a vehicle operating system according to an embodiment of the present application is introduced. It should be noted that the following examples are only intended to help those skilled in the art understand the embodiments of the present application, and are not intended to limit the embodiments of the present application to the specific numerical values ​​or specific scenarios illustrated. Those skilled in the art can obviously make various equivalent modifications or changes based on the examples given below, and such modifications or changes also fall within the scope of the embodiments of the present application.

[0077] Figure 6 The figure shows a flow chart of using the SOMOC tool to design a service for a vehicle operating system. The SOMOC tool uses MATLAB to design a user interaction interface, and according to the user's operation, calls a customized MATLAB language script to implement the corresponding function. Figure 6 The method shown includes steps S610 to S670.

[0078] In step S610, a system service design information file is obtained.

[0079] The input of SOMOC tool is system service design information file, namely ARXML file. The system service design information file is designed and provided by system service architecture, which contains relevant information of service, namely interface information of methods and subjects and information of data types used by them.

[0080] In step S615, a service framework code is generated.

[0081] For example, the system service design information file is imported into the vehicle operating system service framework code generation tool, and the generation tool can automatically generate the service framework code, and the programming language of the service framework code is C++.

[0082] In step S620, system service information is obtained.

[0083] For example, when you import the system service design information file into the SOMOC tool, the tool will display service-related information. For method interfaces and subject interfaces, the SOMOC tool will display their names, function prototypes, and data types. The function prototype includes input parameters, output parameters, and the number of parameters, and the data type includes the name of the data type and the type of data, such as the basic data type.

[0084] In step S625, the developer configures the model information according to actual business requirements.

[0085] Developers can customize each service. For more information, see Figure 5 . Figure 5It is an interface structure diagram for configuring service information in the SOMOC tool, and is also a schematic diagram for developers to configure services provided by an embodiment of the present application. The configuration information includes a service instance 510, an ASWC tree 520, and a periodic execution module 530. Among them, the service instance 510 includes services to be configured, such as service 1, service 2, service 3, etc. The ASWC tree contains the name of each service and the methods and topics it contains, which are displayed to the user in the form of a tree structure. For methods and topics, the SOMOC tool provides a check box, and developers can select the required services and service interfaces based on actual business needs. Only after checking will the corresponding service interface be generated. The periodic execution module 530 includes an execution cycle and a start execution time. For the periodic execution module, developers can configure its execution cycle and the start execution time.

[0086] In step S630, a service model design information file is generated.

[0087] The SOMOC tool integrates the system service information and the developer's model configuration information, and saves them as a service model design information file. The file format of the service model design information file is JSON.

[0088] In step S635, an interface code is generated.

[0089] The SOMOC tool generates interface code based on the model configuration information of the developer, wherein the programming language of the interface code may be C++.

[0090] In step S640, a service framework model is generated.

[0091] The SOMOC tool generates a service framework model based on the model configuration information of the above developers. The service framework model is a Simulink model. In the process of generating the service framework model, all used data types are converted to corresponding data types in Simulink and stored in the Simulink data dictionary.

[0092] In step S645, business logic is added.

[0093] Based on the above service framework model, developers can add business logic to the service framework model according to actual business needs to generate a business model.

[0094] In step S650, some basic functions of the vehicle operating system middleware are added.

[0095] The SOMOC tool can encapsulate some basic functions of the vehicle operating system middleware, such as persistent storage, logs, diagnostic management, state management, etc. During the development process, developers can obtain relevant functions from the SOMOC encapsulation library based on actual business needs and perform specific configurations on basic functions through module parameters.

[0096] In step S655, a service code is generated.

[0097] Developers add business logic to the service framework model and generate a business model. Then they call the required basic functions from the SOMOC tool package library to further improve the business model. Finally, they use Simulink's code generation tools (such as the Embeded Coder tool) to convert the business model into business code, which is written in C++.

[0098] In step S660, the integration code is spliced.

[0099] From step S610 to step S655, the service framework code, interface code and business code have been obtained. At this time, the service framework code and the business code are spliced ​​and integrated using the interface code to obtain a compilable project.

[0100] In step S665, compile the project.

[0101] The SOMOC tool encapsulates the software development kit of the vehicle operating system, which can compile the above project and generate executable files. For more information about compilation, please refer to Figure 7 .

[0102] Figure 7 It is the interface structure diagram of the project compilation and operation provided by the SOMOC tool. The interface contains input path, output path, SDK path, SDK version, SDK output path, platform, browse button, compile button and run button. Among them, the input path indicates the code generated using Simulink, that is, the business code generated in step S655. The output path indicates the spliced ​​code, that is, the code spliced ​​and integrated in step S660. The SDK path indicates the local storage path of the software development kit. After obtaining the SDK, the SOMOC tool will automatically parse it to obtain the SDK version and the platform on which it can run. The SDK output path indicates the output path of the executable file after the final compilation and run. The browse button is used to select the local path, and the compile button is used to perform compilation operations on the project.

[0103] In step S670, the project is run.

[0104] The SOMOC tool encapsulates the software development kit of the vehicle operating system and can run the above executable files on the X64 platform. Figure 7 As shown in the figure, the Run button is used to execute the run operation on the project.

[0105] Combination of the above Figures 1 to 7 , describes the method embodiment of the present application in detail, and the following is combined with Figures 8 to 9 , describes the device embodiment of the present application in detail. It should be understood that the description of the method embodiment corresponds to the description of the device embodiment, so the parts not described in detail can refer to the previous method embodiment.

[0106] Figure 8 It is a device 800 for generating a service framework model provided in an embodiment of the present application. The device 800 includes an acquisition unit 810 and a processing unit 820.

[0107] The acquisition unit 810 is used to acquire service information of services provided by the whole vehicle operating system from a system service design information file of the whole vehicle operating system, wherein the whole vehicle operating system adopts a SOA software architecture;

[0108] The processing unit 820 is used to generate a service model design information file of the whole vehicle operating system according to the service information of the service provided by the whole vehicle operating system;

[0109] The processing unit 820 is used to generate a service framework model according to the service model design information file, and the service framework model is used to design the services provided by the vehicle operating system based on MBD.

[0110] In some implementations, the processing unit 820 is used to generate the service model design information file based on the service information and configuration information of the services provided by the vehicle operating system, wherein the configuration information indicates one or more of the following: the services to be configured in the services provided by the vehicle operating system; the execution method of the methods included in the services to be configured; the return method of the methods included in the services to be configured; and whether to generate a status callback function for the methods in the services to be configured.

[0111] In some implementations, the processing unit 820 is used to: generate a service framework code for the whole vehicle operating system based on a system service design information file of the whole vehicle operating system; generate a business model for the whole vehicle operating system based on the service framework model and the business logic of the whole vehicle operating system; generate an interface code based on a service model design information file of the whole vehicle operating system, and the interface code is used to splice the service framework code of the whole vehicle operating system with the code of the business model.

[0112] In some implementations, the processing unit 820 is used to convert the data type in the service model design information file into a data type supported by the service framework model.

[0113] In some implementations, the service information of the service provided by the vehicle operating system includes one or more of the following: the name of the method interface in the service; the data type of the method interface in the service; the function prototype of the method interface in the service; the name of the subject interface in the service; and the data type of the subject interface in the service.

[0114] Fig. 9 It is a schematic block diagram of a computing device according to an embodiment of the present application. Fig. 9 The computing device 900 shown may include: a memory 910, a processor 920, and an input / output interface 930. The memory 910, the processor 920, and the input / output interface 930 are connected via an internal connection path, the memory 910 is used to store instructions, and the processor 920 is used to execute the instructions stored in the memory 910 to control the input / output interface 930 to receive input data and information and output data such as operation results.

[0115] In some implementations, processor 920 is used to: obtain service information of services provided by the whole vehicle operating system from a system service design information file of the whole vehicle operating system, wherein the whole vehicle operating system adopts the SOA software architecture; processor 920 is used to generate a service model design information file of the whole vehicle operating system based on the service information of services provided by the whole vehicle operating system; processor 920 is used to generate a service framework model based on the service model design information file, and the service framework model is used to design the services provided by the whole vehicle operating system based on MBD.

[0116] In some implementations, the processor 920 is used to: generate the service model design information file based on the service information and configuration information of the services provided by the vehicle operating system, wherein the configuration information indicates one or more of the following: the services to be configured in the services provided by the vehicle operating system; the execution method of the methods included in the services to be configured; the return method of the methods included in the services to be configured; and whether to generate a status callback function for the methods in the services to be configured.

[0117] In some implementations, the processor 920 is used to: generate a service framework code for the vehicle operating system based on a system service design information file of the vehicle operating system; generate a business model for the vehicle operating system based on the service framework model and the business logic of the vehicle operating system; and generate an interface code based on a service model design information file of the vehicle operating system, wherein the interface code is used to splice the service framework code of the vehicle operating system with the code of the business model.

[0118] In some implementations, the processor 920 is used to: convert the data type in the service model design information file into a data type supported by the service framework model.

[0119] In some implementations, the service information of the service provided by the vehicle operating system includes one or more of the following: the name of the method interface in the service; the data type of the method interface in the service; the function prototype of the method interface in the service; the name of the subject interface in the service; and the data type of the subject interface in the service.

[0120] It should be understood that in the embodiment of the present application, the processor 920 can adopt a general central processing unit (CPU), a microprocessor, an application specific integrated circuit (ASIC), or one or more integrated circuits to execute relevant programs to implement the technical solution provided in the embodiment of the present application.

[0121] The memory 910 may include a read-only memory and a random access memory, and provides instructions and data to the processor 920. A portion of the processor 920 may also include a nonvolatile random access memory. For example, the processor 920 may also store information on the device type.

[0122] In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in the processor 920 or an instruction in the form of software. The method for requesting uplink transmission resources disclosed in conjunction with the embodiment of the present application can be directly embodied as a hardware processor for execution, or a combination of hardware and software modules in the processor for execution. The software module can be located in a mature storage medium in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory 910, and the processor 920 reads the information in the memory 910 and completes the steps of the above method in conjunction with its hardware. To avoid repetition, it will not be described in detail here.

[0123] It should be understood that in the embodiments of the present application, the processor may be a central processing unit (CPU), and the processor may also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0124] An embodiment of the present application further provides a computer program product, which includes: a computer program code, and when the computer program code is run on a computer, the computer executes the method in any of the above embodiments.

[0125] An embodiment of the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a program code. When the computer program code runs on a computer, the computer executes the method in any of the above embodiments.

[0126] It should be understood that in the embodiment of the present application, "B corresponding to A" means that B is associated with A, and B can be determined according to A. However, it should also be understood that determining B according to A does not mean determining B only according to A, and B can also be determined according to A and / or other information.

[0127] It should be understood that the term "and / or" in this article is only a description of the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship.

[0128] It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0129] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

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

[0131] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0132] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (digital subscriber line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium may be any available medium that can be read by a computer or a data storage device such as a server or data center that includes one or more available media integrated. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a digital video disc (DVD)), or a semiconductor medium (eg, a solid state disk (SSD)).

[0133] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A method for generating a service framework model, characterized in that: include: Acquire service information of services provided by the vehicle operating system from a system service design information file of the vehicle operating system; wherein the vehicle operating system adopts a service-oriented SOA software architecture; Generate a service model design information file of the vehicle operating system according to the service information of the service provided by the vehicle operating system; A service framework model is generated according to the service model design information file, and the service framework model is used to design the services provided by the vehicle operating system based on the model.

2. The method according to claim 1, characterized in that The generating of the service model design information file of the vehicle operating system according to the service information of the service provided by the vehicle operating system includes: The service model design information file is generated according to the service information and configuration information of the service provided by the vehicle operating system, wherein the configuration information indicates one or more of the following: The services to be configured among the services provided by the vehicle operating system; The execution mode of the method included in the service to be configured; The return mode of the method included in the service to be configured; Whether to generate a status callback function for the method in the service to be configured.

3. The method according to claim 2, characterized in that The method further comprises: Generate a service framework code for the vehicle operating system according to the system service design information file of the vehicle operating system; Generate a business model of the vehicle operating system according to the service framework model and the business logic of the vehicle operating system; According to the service model design information file of the whole vehicle operating system, an interface code is generated, and the interface code is used to splice the service framework code of the whole vehicle operating system with the code of the business model.

4. The method according to claim 1, characterized in that Generating a service framework model according to the service model design information file includes: The data types in the service model design information file are converted into data types supported by the service framework model.

5. The method according to claim 1, characterized in that The service information provided by the vehicle operating system includes one or more of the following: The name of the method interface in the service; The data type of the method interface in the service; The function prototype of the method interface in the service; The name of the subject interface in the service; The data type of the subject interface in the service.

6. A device for generating a service framework model, characterized in that: include: An acquisition unit, used to acquire service information of services provided by the whole vehicle operating system from a system service design information file of the whole vehicle operating system, wherein the whole vehicle operating system adopts a service-oriented SOA software architecture; A processing unit, configured to generate a service model design information file of the whole vehicle operating system according to service information of services provided by the whole vehicle operating system; The processing unit is used to generate a service framework model based on the service model design information file, and the service framework model is used to design the services provided by the vehicle operating system based on the model.

7. The device according to claim 6, characterized in that The processing unit is used for: The service model design information file is generated according to the service information and configuration information of the service provided by the vehicle operating system, wherein the configuration information indicates one or more of the following: The services to be configured among the services provided by the vehicle operating system; The execution mode of the method included in the service to be configured; The return mode of the method included in the service to be configured; Whether to generate a status callback function for the method in the service to be configured.

8. The device according to claim 7, characterized in that The processing unit is used for: Generate a service framework code for the vehicle operating system according to the system service design information file of the vehicle operating system; Generate a business model of the vehicle operating system according to the service framework model and the business logic of the vehicle operating system; According to the service model design information file of the whole vehicle operating system, an interface code is generated, and the interface code is used to splice the service framework code of the whole vehicle operating system with the code of the business model.

9. The device according to claim 6, characterized in that The processing unit is used for: The data types in the service model design information file are converted into data types supported by the service framework model.

10. The device according to claim 6, characterized in that The service information provided by the vehicle operating system includes one or more of the following: The name of the method interface in the service; The data type of the method interface in the service; The function prototype of the method interface in the service; The name of the subject interface in the service; The data type of the subject interface in the service.

Citation Information

Cited By

  • Middleware management method and device

    CN120909667A