CN116048514A

CN116048514A - Model processing method, testing method, device, terminal equipment and storage medium

Info

Publication number: CN116048514A
Application number: CN202310091262.2A
Authority: CN
Inventors: 范俊波; 李宗阳; 李康
Original assignee: Kunyi Electronic Technology Shanghai Co Ltd
Current assignee: Kunyi Electronic Technology Shanghai Co Ltd
Priority date: 2023-02-06
Filing date: 2023-02-06
Publication date: 2023-05-02

Abstract

The embodiment of the application discloses a model processing method, a testing method, a device, terminal equipment and a storage medium, wherein the method comprises the following steps: determining a first JSON file of a target model; configuring the content of the configurable information defined by the first JSON file, and generating a second JSON file of the target model, wherein the second JSON file is used for describing all the configurable information and the non-configurable information of the target model; and compiling and generating a model file package of the target model based on the second JSON file. By the method, port configuration of the target model is realized, connection can be established between the models through the configured ports, connection relation writing is not needed by manually writing glue codes, development efficiency of the hardware-in-the-loop test system is improved, and test efficiency is further improved.

Description

Model processing method, testing method, device, terminal equipment and storage medium

Technical Field

The present disclosure relates to the field of hardware-in-the-loop simulation technologies, and in particular, to a model processing method, a test method, a device, a terminal device, and a storage medium.

Background

Hardware in Loop, HIL (Hardware-in-the-Loop), i.e., hardware in Loop. The hardware-in-loop system (i.e. HIL system) is a hardware-in-loop simulation test system, which is to simulate the running state of a controlled object by running a simulation model through a real-time processor, and is connected with an ECU to be tested through an I/O interface to perform full-scale and systematic test on the ECU to be tested. Hardware-in-the-loop testing has been widely used in the automotive testing field.

The hardware-in-loop test system generally consists of a simulation model, IO hardware of a rack and an object to be tested (such as an ECU), the simulation model is generally generated by modeling software (such as Matlab software), and is generally a mathematical model, and input and output of the simulation model are not related to the IO hardware board card of the rack, but because the hardware-in-loop test is required to be performed, signals of the object to be tested must be given to the simulation model through the IO hardware board card of the rack, and therefore, direct connection between the simulation model and the IO hardware of the rack needs to be established.

In the prior art, the establishment of the direct connection between the simulation models is realized by means of glue codes. Although mutually incompatible models (such as different interfaces and different languages) can be connected and work normally through glue codes, the mode has strong coupling property, modularization is not easy to realize, and the situation that a whole body is pulled and developed easily occurs when a system is updated, namely, the mode cannot be compatible and adapt to various hardware.

Disclosure of Invention

The embodiment of the application provides a model processing method, a testing method, a device, terminal equipment and a storage medium, which are used for solving the problems in the background technology.

In a first aspect, an embodiment of the present application provides a model processing method, where the method includes:

determining a first JSON file of a target model, wherein the first JSON file is used for defining at least one piece of configurable information and non-configurable information of configuration required by generating a model file package of the target model;

configuring the content of the configurable information defined by the first JSON file, and generating a second JSON file of the target model, wherein the second JSON file is used for describing all the configurable information and the non-configurable information of the target model;

and compiling and generating a model file package of the target model based on the second JSON file.

In a second aspect, embodiments of the present application further provide a testing method, where the method includes:

obtaining a model file package of the target model by using the model processing method;

and issuing the model file package of the target model to an industrial personal computer of an HIL system, so that the industrial personal computer runs the target model based on the model file package when the HIL system tests the controlled controller.

In a third aspect, an embodiment of the present application further provides a model processing apparatus, where the apparatus includes:

a determining module configured to determine a first JSON file of a target model, wherein the first JSON file is used to define at least one configurable information and non-configurable information of a configuration required to generate a model file package of the target model;

the configuration module is configured to configure the content of the configurable information defined by the first JSON file and generate a second JSON file of the target model, wherein the second JSON file is used for describing all the configurable information and the non-configurable information of the target model;

and the compiling generation module is configured to compile and generate a model file package of the target model based on the second JSON file.

In a fourth aspect, embodiments of the present application further provide a terminal device, including a memory and a processor, where the memory is configured to store instructions and data, and the processor is configured to perform any one of the foregoing model processing methods or the test method.

In a fifth aspect, embodiments of the present application further provide a storage medium having stored therein a plurality of instructions adapted to be loaded by a processor to perform the model processing method of any one of the above, or the test method.

According to the model processing method, the target model is processed into the model file package which can be analyzed and operated by the industrial personal computer of the HIL system, and in the processing process, the port of the target model is configured, so that the models can be connected through the configured port, the connection relation is not required to be written in a manual glue code writing mode, the development efficiency of the hardware-in-loop test system is improved, and the test efficiency is further improved; meanwhile, as long as the ports between the models can be connected, the transfer processing of signals between the models can be realized, the coupling is low, and various hardware can be compatible and adapted.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the description of the embodiments will be briefly introduced below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

Fig. 1 is a flowchart of a model processing method provided in an embodiment of the present application.

Fig. 2 is a user interface diagram of a configuration port and an expression according to an embodiment of the present application.

Fig. 3 is a user interface diagram of configuration port information according to an embodiment of the present application.

Fig. 4 is a user interface diagram of a configuration triggering event provided in an embodiment of the present application.

FIG. 5 is a user interface diagram of events formed by a configuration model provided in an embodiment of the present application.

Fig. 6 is a user interface diagram of a configuration triggering manner provided in an embodiment of the present application.

Fig. 7 is a user interface diagram of a socket model parameter configuration according to an embodiment of the present application.

Fig. 8 is a user interface diagram of a generic model provided in an embodiment of the present application.

Fig. 9 is a user interface diagram of a network model provided in an embodiment of the present application.

FIG. 10 is a user interface diagram of a custom model provided in an embodiment of the present application.

Fig. 11 is a flowchart of a testing method according to an embodiment of the present application.

Fig. 12 is a schematic structural diagram of a model processing device according to an embodiment of the present application.

Fig. 13 is another schematic structural diagram of a model processing device according to an embodiment of the present application.

Fig. 14 is a schematic structural diagram of a terminal device according to an embodiment of the present application.

Detailed Description

The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are only some, but not all, of the embodiments of the present application. All other embodiments, which can be made by those skilled in the art based on the embodiments herein without making any inventive effort, are intended to be within the scope of the present application.

In the description of the embodiments of the present application, it should be understood that the terms "first," "second," and the like are used for descriptive purposes only and are not to be construed as indicating or implying a relative importance or an implicit indication of the number of features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include one or more of the described features. In the description of the embodiments of the present application, the meaning of "a plurality" is two or more, unless explicitly defined otherwise.

The following description is presented to enable any person skilled in the art to make and use the application. In the following description, details are set forth for purposes of explanation. It will be apparent to one of ordinary skill in the art that the present application may be practiced without these specific details. In other instances, well-known processes have not been described in detail in order to avoid unnecessarily obscuring descriptions of the embodiments of the present application. Thus, the present application is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed in the embodiments of the present application.

The embodiment of the application provides a model processing method, a testing method, a device, a terminal device and a storage medium, and the detailed description will be given below.

Referring to fig. 1, fig. 1 is a flowchart of a model processing method according to an embodiment of the present application, where the method includes the following steps:

101. a first JSON file of the target model is determined.

The first JSON file (JavaScript Object Notation) defines at least one of the configurable information required to generate a model-file package for the target model and the non-configurable information for the target model. A first JSON file is provided from which a corresponding first DLL file (Dynamic Link Library, dynamically linked library) is created.

In an embodiment of the present application, the target model is any one of the following models: CAN model, LIN model, analog output processing model, analog input model, digital output model, digital input model, PWM signal output model, ethernet model, timer model, socket model, custom model, and third party model (e.g., vector device driver).

102. And configuring the content of the configurable information defined by the first JSON file, and generating a second JSON file of the target model.

103. And compiling and generating a model file package of the target model based on the second JSON file.

In an embodiment of the present application, the second JSON file is used to describe all configurable and non-configurable information of the object model.

Optionally, in some embodiments, step 102 includes: and forming a user interface corresponding to the model category to which the target model belongs, wherein the user interface is used for providing an interface element for configuring the content of the configurable information, responding to the configuration operation of the user on the configurable information in the user interface, acquiring the content of the configurable information of the target model, and generating a second JSON file based on the content of the configurable information and the content of the non-configurable information.

The first JSON file and the matched DLL file based on the Schema protocol, namely the first DLL file, are equivalent to a template for obtaining a target model, namely a user interface, the user interface defines operation logic and parameters, and also defines which parameters need manual configuration, namely configuration information, and the parameters needing manual configuration are configured.

For example, for a model named expression_1, as shown in table 1 (corresponding to the user interface of fig. 2), the expressions between the input port, the output port and the input/output port are configurable, the port types and the value ranges ([ 0, 255 ]) of the input port and the output port are fixed, and the configuration is not needed, then the configured or mutated code can be obtained by configuring the expressions between the input port, the output port and the input/output port of the model, the code is injected into the model manager, a second JSON file is generated, and then a second JSON file is created according to the second JSON file.

Optionally, the port types may include types of Int type, uint type, flow type, double type, name struct type, diff struct type, and the like, where each port type includes a plurality of ports of different byte types. For example, the Int type includes ports including an Int8 port, an Int16 port, an Int32 port, and an Int64 port, and the Uint type includes ports including a Uint8 port, a Uint16 port, a Uint32 port, and a Uint64 port.

As shown in Table 1 below, table 1 below is an example of a model parameter configuration

TABLE 1

For example, for a custom model named custom model_1, the input port, output port, and port attribute of the model need to be configured (as shown in table 2, corresponding to the user interface of fig. 3), and a trigger event may also be configured for the model, that is, when what event occurs to the model, the configured output port outputs data of a corresponding type (as shown in table 3, corresponding to the user interface of fig. 4). Events that can be formed by the model can also be configured through the user interface for triggering of other models (corresponding to the user interface of fig. 5, as shown in table 4). In addition, the triggering mode of the part model can be configured, as shown in table 5 (corresponding to the user interface of fig. 6), and Trigger is adopted.

The port attributes include queue attributes, structure attributes, and port types. The queue attribute is used to describe the port connection mode. Not every port describes a specific queue attribute, and if the port attribute describes that the queue attribute has a corresponding attribute, the corresponding port connection mode may be one-to-many connection or many-to-one connection. If the queue attribute described by the port attribute does not have the corresponding attribute, the corresponding port connection mode may be one-to-one connection. One-to-many connection is a connection in which one output port points to a plurality of input ports, many-to-one connection is a connection in which a plurality of output ports point to one input port, and one-to-one connection is a connection in which one output port points to one input port. The structure attribute is used for describing whether the corresponding target data port has the affiliated structure. With respect to the definition of a structure, it is understood that a structure includes a plurality of members, each member having a corresponding type. For example, a structure includes a set of Int8 ports, a set of Uint8 ports, and a set of Uint16 ports, and then the structure includes three members. Not every port describes a specific queue attribute, and if the structural attribute described by the port attribute is that the port has a corresponding attribute, the structural attributes of the ports to be connected are the same, including the name of the structure to which the port belongs, the number of the ports of the structure, the port type of the structure and the port sequence of the structure to which the port belongs are the same. If the port attribute describes the structure attribute that does not have the object attribute, the structure attribute of the port to be connected may be different.

As shown in Table 2 below, table 2 is an example of a port information configuration for a custom model

TABLE 2

As shown in Table 3 below, table 3 below is an example of a trigger event configuration

TABLE 3 Table 3

As shown in Table 4 below, table 4 below is an example of configuring events formed by a model to activate trigger events for other models

TABLE 4 Table 4

As shown in Table 5 below, table 5 below is an example of a configuration of the model triggering scheme

TABLE 5

For example, for the socket model, information to be configured is shown in fig. 7.

The standardized Schema protocol specifies whether parameters or information are fixed or configurable, how to configure and describe, and so forth. For example: ports, port attributes, expressions, data attributes, scalar quantities, converters, definition of events, trigger of events, and structure of data.

Regarding the manner of definition of an event, for example, the manner of defining an event name and an event description. Regarding the structure of data, for example, a structure is defined by the parameter configuration of the socket model, and various information of the structure is required to be configured for the socket model.

Further, the model related to the hardware in the standard protocol Schema of the ring system comprises: an environment channel model, a network model, a Simulink model, a universal model, and a custom model.

The common models include a decoder model, an Encode model, a Timer model, an Expression model, and an event_Generator model, as shown in FIG. 8. The Simulink model may be used to decode the structure data into a plurality of simple signals output, the Encode model may be used to Encode the plurality of simple signals into one structure signal and output, the Timer model may be used to generate a Timer instance for runtime use, the Expression model may be used to generate an Expression instance for runtime use, and the event_Generator model may be used to create an Event Generator instance for runtime use.

As shown in fig. 9, the network model includes a fastds model, an LDF model, a Socket-Client model, a Socket-Server model, and a SomeIP. The FastDDS model can be used for creating a model instance of FastDDS, the LDF model can be used for completing corresponding LIN tasks according to LDF files, the Socket-Client model can be used for creating a Client to conduct network communication, the Socket-Server model can be used for creating a TCP Server to provide services, and SomeiP can be used for supporting Someip and Someip sd.

As shown in fig. 10, an interface is created for the custom model.

Optionally, in some embodiments, step 101 includes: determining model types of the target model, and generating a first JSON file according to a predefined protocol and the model types of the target model, wherein the protocol is used for defining configurable information, non-configurable information and format conditions of the configurable information of the models of different model types.

Each target model can generate a JSON file based on a hardware-in-the-loop system standard protocol Schema, a user interface of the target model is obtained according to the JSON file and a matched DLL file, and a port, a port attribute, a model triggering event and an output calibration amount included in each target model are defined in the user interface. And configuring the information or parameters, and generating a new JSON file by the variation of the first JSON file, namely generating a second JSON file.

With respect to defining the ports included in each of the object models at the user interface, for example, it is defined that some models may have input ports and some models may have output ports.

With respect to defining model triggering events included for each target model at the user interface, for example, some models may output events and some may output data in response to output events of other models.

The customized model process is exemplified by: the method comprises the steps of generating a first JSON file and a first DLL file of an LDF model based on a Schema protocol, configuring user interface parameters, mutating, generating a second JSON file and a second DLL file, compiling a model file package or a model instance.

The standardized model processing procedure is exemplified by: the method comprises the steps of a first JSON file based on a Schema protocol of a timer model, user interface parameter configuration (such as parameters of a cycle period and the like), mutation, generation of a second JSON file, compiling after integrating a first DLL file, and model file package or model instance.

For a part of models, such as a LIN model, an LDF file can be imported, such as an interface for triggering the creation of the model, clicking the LIN model, then jumping to the interface for importing the LDF file, the importing process is to read the content of the file based on a Schema protocol, so that all configurable information and non-configurable information of the LIN model to be finally generated are determined, then the corresponding interface is presented, and meanwhile, one JSON file, namely a first JSON file, is corresponding to the corresponding interface, in the user interface, a user can adjust and configure the information, and after the configuration is completed, the other JSON file, namely a second JSON file, is present.

For another part of models, such as an analog output model, the input of files is not needed, only corresponding options, such as triggering an interface for creating the model, are needed, clicking to select the model can jump to the interface for configuration, one JSON file is corresponding, and after the configuration is finished, the other JSON file is available.

After the user interface is configured, corresponding codes can be formed and injected into a model manager, and signal ports and events can be dynamically created through variation and compiling of a model to obtain a model instance which can run in the MRT, and then a model file package is obtained. The connection among the models can be established according to the port connection rule, and the model instance is issued to the RTPC to run.

Optionally, the port connection rule may be a preset rule, and may be collocated by combining a port type and a byte type to obtain the port connection rule.

The port connection rules may include connections between ports of the same port type and of different bytes. For example, the Int8 output port may be connected with the Int8 input port, the Int16 input port, the Int32 input port, and the Int64 input port.

The port connection rules may include connections between ports of different port types, the same or different bytes. For example, the Uint8 output port may be connected to an Int32 input port, an Int64 input port, a Uint8 input port, a Uint16 input port, a Uint32 input port, a Uint64 input port, a Float input port, and a Double input port.

The above related content about the port connection rule is merely a setting example provided in the embodiment of the present application, and optionally, the port connection rule may be preset according to conditions such as an actual connection requirement and a scene creation requirement.

In the embodiment of the application, the configuration is carried out according to the JSON file and the matched DLL file of the target model, and the model file package or the model instance which can be analyzed and operated by the industrial personal computer of the HIL system is obtained through compiling, so that the aim of completing the software/hardware in-loop test is fulfilled.

In one embodiment, after the model file package of the target model is compiled and generated based on the second JSON file, the model file package of each target model can be understood as a single simulation model required to be used in the HIL system, so that the connection relationship between the simulation models can be configured, for example, the model file package is imported into a connection tool for file reading, and then the connection relationship of the data ports between the simulation models is determined by using the connection tool;

specifically, in the upper computer, the connection relationship of the data ports between the models can be determined through the following processes: determining data ports available for connection in a target simulation model to be connected, determining port description information of the target data ports, and determining connection relations among the target data ports according to the port description information and preset port connection rules, so that signal transmission is performed based on the connection relations when the target simulation model works.

The process of determining the connection relationship can be implemented in response to the operation of the user on the corresponding interface, and in the process, the result of the operation of the user can be limited, adjusted or verified based on the port description information and the port connection rule.

In the above process, except that the data type in the port description information of the connection data port needs to be the same, and the data transmission direction needs to be corresponding, in one example, whether the target data port has a queue attribute may be determined according to the port description information; and according to the port connection rule, determining that the target data port which does not have the queue attribute in the connection relation and is used as the input port is only connected with one target data port. Further, if the connection relationship achieved by the user operation does not match, the determination of the connection relationship may be prohibited or canceled, or an abnormality of the connection relationship may be presented.

The queue attribute may also be understood as a queue identifier for identifying whether a corresponding port allows connection to a plurality of target data ports, and further may also be understood as: in the corresponding simulation model, whether a mechanism is designed is that: a mechanism for sequentially processing data input (or output) for different data ports connected based on the queues.

In one embodiment, after determining two target simulation models to be connected, if it is assumed that the two target simulation models are a first target simulation model and a second target simulation model, the target data port and the connection relationship thereof may also be determined by the following steps:

acquiring one or more historical connection records of a simulation model (such as a class A, further, a digital quantity output model) of the first target simulation model and a simulation model (such as a class B, further, a CAN model) of the second target simulation model; the historical connection record represents a connection relation which has occurred in the past for a data port between the model of the A class and the model of the B class; for example, a model of class a has two input ports, input ports x1, x2, and a simulation model of class B has 1 output port, output port y, x1 by y in one past history and x2 by y in another past history.

If the number of the history connection records is multiple, counting the occurrence times of each history connection record; prompting candidate connection relations in the interface based on the times, for example, describing the connection relations, and displaying the connection relations in sequence from large to small according to the times; further, the final connection relationship may be determined in response to a user operation of the suggested connection relationship, i.e., the above-related connection operation may be an operation of the user on the recommended connection.

Through the mode, the connection experience of the past connection relation can be used for reference, the connection efficiency is improved, and meanwhile, the error and the leakage of engineers with shallow experience in connection are avoided or reduced.

In a further example, each historical connection record may be further configured with a mapped scene identifier for identifying characteristics of a tested scene, such as a scene of testing a chassis domain controller, a scene of testing a intelligent driving domain controller, etc., where the characteristics of the scene are not limited to domain-based distinction, and may include, for example, a manufacturer of the tested controller, a use, etc.

Furthermore, in the process of acquiring one or more historical connection records of the class a and the class B, only the historical connection record with the scene identifier identical to or partially identical to the scene of the current test may be acquired.

Furthermore, the connection record with stronger correlation can be applied to the test, and the recommended connection line is guaranteed to be helpful to a certain extent.

The model processing method of the embodiment of the application comprises the following steps: determining a first JSON file of a target model, wherein the first JSON file is used for defining at least one piece of configurable information and non-configurable information of configuration required by generating a model file package of the target model; configuring the content of the configurable information defined by the first JSON file, and generating a second JSON file of the target model, wherein the second JSON file is used for describing all the configurable information and the non-configurable information of the target model; and compiling and generating a model file package of the target model based on the second JSON file. According to the method, the target model is processed into the model file package which can be analyzed and operated by the industrial personal computer of the HIL system, and the port of the target model is configured in the processing process, so that the models can be connected through the configured port, the connection relation is not required to be written in a manual glue code writing mode, the development efficiency of the hardware-in-loop test system is improved, and the test efficiency is further improved. Meanwhile, as long as the ports between the models can be connected, the transfer processing of signals between the models can be realized, the coupling is low, and various hardware can be compatible and adapted.

Referring to fig. 11, fig. 11 is a flowchart of a testing method according to an embodiment of the present application, where the method includes the following steps:

201. and obtaining a model file package of the target model by using the model processing method.

202. And issuing the model file package of the target model to an industrial personal computer of an HIL system, so that the industrial personal computer runs the target model based on the model file package when the HIL system tests the controlled controller.

In the embodiment of the application, a corresponding model file package or model instance can be created for each target model, and the model file package or model instance can be analyzed and operated by an industrial personal computer of the HIL system, so that the model file package or model instance is loaded into a hardware-in-loop test system, and after the models are connected through configured ports, signal circulation among the models can be realized, and software/hardware testing is realized.

In another embodiment of the present application, the generated model file package may also be stored in an upper computer or sent to a server, other upper computers, etc. for subsequent calling by the devices with requirements.

Referring to fig. 12, fig. 12 is a schematic structural diagram of a model processing apparatus according to an embodiment of the present application, and the model processing apparatus 300 includes the following modules:

A determining module 301, configured to determine a first JSON file of a target model, where the first JSON file is used to define at least one configurable information and non-configurable information that are required to generate a model file package of the target model.

The configuration module 302 is configured to configure the content of the configurable information defined by the first JSON file, and generate a second JSON file of the target model, where the second JSON file is used to describe all the configurable information and the non-configurable information of the target model.

And the compiling generating module 303 is configured to compile and generate a model file package of the target model based on the second JSON file.

Optionally, the determining module 301 may include the following sub-modules:

and the category determination submodule is used for determining the model category of the target model.

And the file generation sub-module is used for generating a first JSON file according to a predefined protocol and model types of the target model, wherein the protocol is used for defining configurable information, non-configurable information and format conditions of the configurable information required to be configured by the models of different model types.

Optionally, the determining module 301 may include the following sub-modules:

And the first file generation sub-module is used for generating a first JSON file according to a predefined protocol and model types of the target model, wherein the protocol is used for defining configurable information, non-configurable information and format conditions of the configurable information of the models of different model types.

Optionally, the predefined protocol is a Schema protocol.

Optionally, the configuration module 302 may include the following sub-modules:

and the interface generation sub-module is used for forming a user interface corresponding to the model category to which the target model belongs, wherein the user interface is used for providing interface elements for configuring the content of the configurable information.

And the acquisition sub-module is used for responding to the configuration operation of the user on the configurable information in the user interface and acquiring the content of the configurable information of the target model.

And the second file generation sub-module is used for generating the second JSON file based on the content of the configurable information and the content of the non-configurable information.

Optionally, the model processing device 300 in the embodiment of the present application may further include other modules and sub-modules, which are not described herein.

The model processing apparatus 300 of the embodiment of the present application includes: a determining module 301, configured to determine a first JSON file of a target model, where the first JSON file is used to define at least one configurable information and non-configurable information that are required to generate a model file package of the target model; a configuration module 302, configured to configure the content of the configurable information defined by the first JSON file, and generate a second JSON file of the target model, where the second JSON file is used to describe all the configurable information and the non-configurable information of the target model; and the compiling generating module 303 is configured to compile and generate a model file package of the target model based on the second JSON file. Through the device, the target model is processed into the model file package which can be analyzed and operated by the industrial personal computer of the HIL system, and the port of the target model is configured in the processing process, so that the models can be connected through the configured port, the connection relation is not required to be written in a manual glue code writing mode, the development efficiency of the hardware-in-loop test system is improved, and the test efficiency is further improved. Meanwhile, as long as the ports between the models can be connected, the transfer processing of signals between the models can be realized, the coupling is low, and various hardware can be compatible and adapted.

Referring to fig. 13, fig. 13 is another schematic structural diagram of a model processing device according to an embodiment of the present application, where the model processing device 300 includes a memory 120, one or more processors 180, and one or more application programs, and the one or more application programs are stored in the memory 120 and configured to be executed by the processors 180; the processor 180 may include a determination module 301, a configuration module 302, and a compilation generation module 303. For example, the structures and connection relationships of the above respective components may be as follows:

memory 120 may be used to store applications and data. The memory 120 stores application programs including executable code. Applications may constitute various functional modules. The processor 180 executes various functional applications and various steps of the model processing method by running an application program stored in the memory 120. In addition, memory 120 may include high-speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 120 may also include a memory controller to provide access to the memory 120 by the processor 180.

The processor 180 is a control center of the device, connects various parts of the entire terminal using various interfaces and lines, and performs various functions of the device and processes data by running or executing application programs stored in the memory 120 and calling data stored in the memory 120, thereby performing overall monitoring of the device. Optionally, the processor 180 may include one or more processing cores; preferably, the processor 180 may integrate an application processor and a modem processor, wherein the application processor primarily processes an operating system, user interfaces, application programs, and the like.

In particular, in this embodiment, the processor 180 loads executable codes corresponding to the processes of one or more application programs into the memory 120 according to the following instructions, and the processor 180 executes the application programs stored in the memory 120, so as to implement various functions:

And compiling and generating a model file package of the target model based on the second JSON file, namely instantiating the target model.

In some embodiments, the target model is any one of a CAN model, a LIN model, an analog output processing model, an analog input model, a digital output model, a digital input model, a PWM signal output model, an ethernet model, a timer model, a socket model, a custom model, and a third party model.

In some embodiments, the configuring the content of the configurable information defined by the first JSON file, generating a second JSON file of the target model includes:

forming a user interface corresponding to a model category to which the target model belongs, wherein the user interface is used for providing interface elements for configuring the content of the configurable information;

responding to the configuration operation of a user on the configurable information in the user interface, and acquiring the content of the configurable information of the target model;

the second JSON file is generated based on the content of the configurable information and the content of the non-configurable information.

In some embodiments, the configurable information includes a nominal amount output by the target model, port information, trigger event information, wherein,

The port information includes a port name and a port attribute, the port attribute including: queue attribute, structure attribute, and port type;

the trigger event information includes a trigger event that triggers the target model to output a specified signal, a trigger event formed by the target model to activate other models than the target model.

In some embodiments, the trigger event information further includes an event trigger mode including invoking a text box to obtain a focus event trigger and a trigger.

In some embodiments, the determining the first JSON file of the object model includes:

determining a model class of the target model;

the first JSON file is generated according to a predefined protocol and model classes of the target model, wherein the protocol is used to define configurable information, non-configurable information and format conditions of the configurable information for the configuration required by the models of the different model classes.

The embodiment of the application also provides terminal equipment. The terminal equipment can be a server, a smart phone, a computer, a tablet personal computer and the like.

Referring to fig. 14, fig. 14 is a schematic structural diagram of a terminal device provided in the embodiment of the present application, and the terminal device 1200 may be used to implement the model processing method or the test method provided in the above embodiment. The terminal device 1200 may be a smart phone or a tablet computer.

As shown in fig. 14, the terminal device 1200 may include an RF (Radio Frequency) circuit 110, a memory 120 including one or more (only one is shown in the figure) computer readable storage mediums, an input unit 130, a display unit 140, a sensor 150, an audio circuit 160, a transmission module 170, a processor 180 including one or more (only one is shown in the figure) processing cores, and a power supply 190. It will be appreciated by those skilled in the art that the configuration of the terminal device 1200 shown in fig. 14 does not constitute a limitation of the terminal device 1200, and may include more or fewer components than shown, or may combine certain components, or may have a different arrangement of components. Wherein:

the RF circuit 110 is configured to receive and transmit electromagnetic waves, and to perform mutual conversion between the electromagnetic waves and the electrical signals, so as to communicate with a communication network or other devices. RF circuitry 110 may include various existing circuit elements for performing these functions, such as an antenna, a radio frequency transceiver, a digital signal processor, an encryption/decryption chip, a Subscriber Identity Module (SIM) card, memory, and the like. The RF circuitry 110 may communicate with various networks such as the internet, intranets, wireless networks, or other devices via wireless networks.

The memory 120 may be used to store software programs and modules, such as program instructions/modules corresponding to the model processing methods or test methods in the above embodiments, and the processor 180 executes the software programs and modules stored in the memory 120 to perform various functional applications and various steps of the model processing methods or test methods. Memory 120 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, memory 120 may further include memory remotely located relative to processor 180, which may be connected to terminal device 1200 via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The input unit 130 may be used to receive input numeric or character information and to generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control. In particular, the input unit 130 may comprise a touch sensitive surface 131 and other input devices 132. The touch sensitive surface 131, also referred to as a touch display screen or touch pad, may collect touch operations thereon or thereabout by a user (e.g., operations of the user on the touch sensitive surface 131 or thereabout by any suitable object or accessory such as a finger, stylus, etc.), and actuate the corresponding connection means according to a pre-set program. Alternatively, the touch sensitive surface 131 may comprise two parts, a touch detection device and a touch controller. The touch control detection device detects the touch control direction of a user, detects signals brought by touch control operation and transmits the signals to the touch control controller; the touch controller receives touch information from the touch detection device, converts the touch information into touch coordinates, sends the touch coordinates to the processor 180, and can receive and execute commands sent by the processor 180. In addition, the touch-sensitive surface 131 may be implemented in various types of resistive, capacitive, infrared, surface acoustic wave, and the like. In addition to the touch-sensitive surface 131, the input unit 130 may also comprise other input devices 132. In particular, other input devices 132 may include, but are not limited to, one or more of a physical keyboard, function keys (e.g., volume control keys, switch keys, etc.), a trackball, mouse, joystick, etc.

The display unit 140 may be used to display information input by a user or information provided to the user and various graphical user interfaces of the terminal device 1200, which may be composed of graphics, text, icons, video, and any combination thereof. The display unit 140 may include a display panel 141, and alternatively, the display panel 141 may be configured in the form of an LCD (Liquid Crystal Display ), an OLED (Organic Light-Emitting Diode), or the like. Further, the touch-sensitive surface 131 may cover the display panel 141, and after the touch-sensitive surface 131 detects a touch operation thereon or thereabout, the touch-sensitive surface is transferred to the processor 180 to determine a type of touch event, and then the processor 180 provides a corresponding visual output on the display panel 141 according to the type of touch event. Although in fig. 14 the touch-sensitive surface 131 and the display panel 141 are implemented as two separate components for input and output functions, in some embodiments the touch-sensitive surface 131 may be integrated with the display panel 141 to implement the input and output functions.

The terminal device 1200 may also include at least one sensor 150, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor that may adjust the brightness of the display panel 141 according to the brightness of ambient light, and a proximity sensor that may turn off the display panel 141 and/or the backlight when the terminal device 1200 moves to the ear. As one of the motion sensors, the gravity acceleration sensor can detect the acceleration in all directions (generally three axes), and can detect the gravity and the direction when the mobile phone is stationary, and can be used for applications of recognizing the gesture of the mobile phone (such as horizontal and vertical screen switching, related games, magnetometer gesture calibration), vibration recognition related functions (such as pedometer and knocking), and the like; other sensors such as gyroscopes, barometers, hygrometers, thermometers, infrared sensors, etc. that may also be configured with the terminal device 1200 are not described in detail herein.

Audio circuitry 160, speaker 161, microphone 162 may provide an audio interface between a user and terminal device 1200. The audio circuit 160 may transmit the received electrical signal converted from audio data to the speaker 161, and the electrical signal is converted into a sound signal by the speaker 161 to be output; on the other hand, the microphone 162 converts the collected sound signal into an electrical signal, receives the electrical signal from the audio circuit 160, converts the electrical signal into audio data, outputs the audio data to the processor 180 for processing, transmits the audio data to, for example, another terminal via the RF circuit 110, or outputs the audio data to the memory 120 for further processing. Audio circuitry 160 may also include an ear bud jack to provide communication of the peripheral headphones with terminal device 1200.

Terminal device 1200 may facilitate user email, web browsing, streaming media access, etc. via a transmission module 170 (e.g., wi-Fi module) that provides wireless broadband internet access to the user. Although fig. 14 shows the transmission module 170, it is understood that it does not belong to the essential constitution of the terminal device 1200, and can be omitted entirely as required within the scope not changing the essence of the invention.

The processor 180 is a control center of the terminal device 1200, connects various parts of the entire mobile phone using various interfaces and lines, and performs various functions of the terminal device 1200 and processes data by running or executing software programs and/or modules stored in the memory 120, and calling data stored in the memory 120, thereby performing overall monitoring of the mobile phone. Optionally, the processor 180 may include one or more processing cores; in some embodiments, the processor 180 may integrate an application processor that primarily processes operating systems, user interfaces, applications, etc., with a modem processor that primarily processes wireless communications. It will be appreciated that the modem processor described above may not be integrated into the processor 180.

The terminal device 1200 also includes a power supply 190 that provides power to the various components, and in some embodiments, may be logically coupled to the processor 180 via a power management system to perform functions such as managing discharge, and managing power consumption via the power management system. The power supply 190 may also include one or more of any of a direct current or alternating current power supply, a recharging system, a power failure detection circuit, a power converter or inverter, a power status indicator, and the like.

Although not shown, the terminal device 1200 may further include a camera (such as a front camera, a rear camera), a bluetooth module, etc., which will not be described herein. In particular, in the present embodiment, the display unit 140 of the terminal device 1200 is a touch screen display, the terminal device 1200 further includes a memory 120, and one or more programs, wherein the one or more programs are stored in the memory 120 and configured to be executed by the one or more processors 180, the one or more programs include steps for:

In some embodiments, the configurable information is at least one of a nominal amount, port information, trigger event information output by the target model, wherein,

the port information comprises a port name and a port attribute, wherein the port attribute comprises a queue attribute, a structure attribute and a port type;

determining a model class of the target model;

In particular, in the present embodiment, the terminal device 1200 further includes a memory 120, and one or more programs, wherein the one or more programs are stored in the memory 120, and configured to be executed by the one or more processors 180, the one or more programs include steps for:

and issuing a model file package of the target model to an industrial personal computer of the HIL system, so that the industrial personal computer runs the target model based on the model file package when the HIL system tests the tested controller.

The embodiment of the application further provides a storage medium, in which a computer program is stored, and when the computer program runs on a computer, the computer executes the model processing method or the test method according to any one of the embodiments.

It should be noted that, for the model processing method or the test method described in the present application, it will be understood by those skilled in the art that all or part of the flow of implementing the model processing method or the test method described in the embodiments of the present application may be implemented by controlling related hardware by using a computer program, where the computer program may be stored in a computer readable storage medium, for example, stored in a memory of the terminal device, and executed by at least one processor in the terminal device, and the execution may include the flow of implementing the embodiment of the model processing method or the test method. The storage medium may be a magnetic disk, an optical disk, a Read Only Memory (ROM), a random access Memory (RAM, random Access Memory), or the like.

For the model processing device in the embodiment of the present application, each functional module may be integrated in one processing chip, or each module may exist separately and physically, or two or more modules may be integrated in one module. The integrated modules may be implemented in hardware or in software functional modules. The integrated module, if implemented as a software functional module and sold or used as a stand-alone product, may also be stored in a computer readable storage medium such as read-only memory, magnetic or optical disk, etc.

The model processing method, the test method, the device, the terminal equipment and the storage medium provided by the embodiment of the application are described in detail. Specific examples are set forth herein to illustrate the principles and embodiments of the present application, and the description of the examples above is only intended to assist in understanding the methods of the present application and their core ideas. Meanwhile, those skilled in the art will have variations in the specific embodiments and application scope in light of the ideas of the present application, and the present description should not be construed as limiting the present application in view of the above.

Claims

1. A model processing method is applied to an upper computer of an HIL system, and is characterized by comprising the following steps:

2. The model processing method according to claim 1, wherein the target model is any one of a CAN model, a LIN model, an analog output processing model, an analog input model, a digital output model, a digital input model, a PWM signal output model, an ethernet model, a timer model, a socket model, a custom model, and a third party model.

3. The model processing method according to claim 1, wherein configuring the content of the configurable information defined by the first JSON file, generating a second JSON file of the target model, includes:

4. The method of claim 1, wherein the configurable information is at least one of a nominal amount, port information, and trigger event information outputted by the target model, wherein,

5. The model processing method of claim 4, wherein the trigger event information further comprises an event trigger mode, the event trigger mode comprising invoking a text box to obtain a focus event trigger and a trigger.

6. The model processing method according to claim 1, wherein determining the first JSON file of the target model includes:

determining a model class of the target model;

7. A test method applied to a HIL system, the method comprising:

obtaining a model file package of a target model by using the model processing method according to any one of claims 1 to 6;

8. A model processing apparatus, characterized in that the apparatus comprises:

9. A terminal device comprising a memory for storing instructions and data and a processor for executing the model processing method of any one of claims 1-6 or the test method of claim 7.

10. A storage medium having stored therein a plurality of instructions adapted to be loaded by a processor to perform the model processing method of any one of claims 1-6 or the test method of claim 7.