Detailed Description
In order to make the technical problems, technical schemes and beneficial effects to be solved more clear and obvious, the application is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the particular embodiments described herein are illustrative only and are not limiting upon the application.
In this embodiment, the routing scheme of the present application will be described by taking development of an in-vehicle gateway conforming to an AutoSAR (Automotive Open Systems Architecture, automobile open system architecture) as an example.
For example, when developing an automotive gateway according to AutoSAR, the routing table of the automotive gateway is frequently updated along with the change of the requirement, and assuming that hundreds of changes in the routing table all need manual configuration and testing, a lot of resources are occupied in terms of time and labor cost, and the routing function of the automotive gateway affects the CAN (Controller Area Network ) communication functions of all ECUs (Electronic Control Unit, electronic control units) of the whole vehicle, so that the communication function of the whole vehicle is affected once an error occurs, resulting in blocked development progress of the whole vehicle. Therefore, how to quickly and accurately configure the routing table in the vehicle-mounted gateway has very important significance. In the development process, a routing configuration file of the vehicle-mounted gateway is generally generated based on the routing table, for example, a development tool provided by a EB (Elektrobit) company, such as EB tress studio, is adopted to convert data in the routing table into a file in an arxml format, and then into a routing configuration file in a xdm format; and then, the routing configuration file in the xdm format is written into the vehicle-mounted gateway through operations such as compiling and the like, so that the routing configuration of the vehicle-mounted gateway is completed. Obviously, in the route configuration process, the generation step of the route configuration file plays a key role in the whole route configuration.
Therefore, the route configuration scheme of the embodiment of the application mainly improves the efficiency and accuracy of the link of generating the configuration file, thereby driving the improvement of the efficiency and accuracy of the route configuration. Specifically, for the case that when generating a routing configuration file, a routing table path (e.g., pduRoutingpath) needs to be grouped, the embodiment of the present application constructs a packet dictionary (pre-constructed or real-time constructed based on the routing table), and groups the routing table path by using the packet dictionary, so that the efficiency and accuracy of routing configuration are improved by improving the efficiency and accuracy of the grouping. Embodiments of the present application will be described in detail below with reference to the accompanying drawings.
Fig. 1 is a schematic flow chart of an embodiment of the route configuration method of the present application. The method comprises the following steps:
step S10, a routing table is obtained.
In step S10, the obtained routing table may be, for example, an excel format file, which may be uploaded into the route configuration apparatus (for example, a series of tool sets for implementing route configuration) by a developer. A plurality of communication matrices capable of expressing routing relationships are described in the routing table, wherein each communication matrix is a matrix of one row and N columns, and describes data from which a message arrives and to which the message arrives. For example, the routing table is described with reference to table one, which is a portion of the routing table that shows a first row and a second row of the routing table.
List one
As shown in table one, the routing table may include a plurality of data types, located in a first row (i.e., header portion) of the routing table, starting with a second row and each specific communication matrix. It should be noted that the contents (e.g. the types of data included) in the routing table may be flexibly set by those skilled in the art according to the actual situation, and the table is merely for example and not limiting the embodiments of the present application. In some implementations, fewer fields than table one or more fields than table one may be set in the routing table. In addition, the routing table shown in table one is usually a standardized routing table, and in the development of the vehicle gateway, the types of routing tables from different sources are often different, and the original routing table can be converted into the standardized routing table at this time, so that the embodiment of the application is convenient for further processing. Among other things, some conversion tools may be utilized to convert the original routing table into a standardized routing table to increase the efficiency of the conversion. In addition, the conversion tools can detect, prompt or correct format problems, logic problems and the like in the original routing table in the conversion process, so that problems or errors in the converted routing table are reduced, and the configuration of the wrong routing relationship in the gateway is avoided.
Step S11, generating a routing table path and a corresponding grouping condition according to the routing table obtained in the step S10.
Wherein each communication matrix in the routing table may correspondingly generate a routing table path and corresponding packet conditions. In general, the routing table often contains hundreds of communication matrices, and thus, in step S11, hundreds of routing table paths and corresponding packet conditions are generated accordingly.
In step S11, data is first extracted from the input routing table, such as classification (based on the data type shown in the header) of various types of data, and then routing table paths and corresponding packet conditions are generated based on the extracted data. Wherein the routing table path is used to indicate a specific routing relationship, such as where the signal is coming from, where it is going; based on the routing table path, the vehicle gateway can implement a routing function.
The format of the routing table path may be, for example:
"PduRRout-ingPath":"ASPath:/PduR/PduR/PduRRoutingTables/PduRRoutingTable/Can_name_name_ID_R/Can_name_name_ID_T_D"
as can be seen from this format, the routing table path includes: a receiver signal name (can_name_name_id_r) and a transmitter signal name (can_name_name_id_t). Wherein Can represents a Can channel to which a received/transmitted signal belongs, name represents a name of the received/transmitted signal, name_id represents an identity of the received/transmitted signal, R represents a receiving end, and T represents a transmitting end. The vehicle-mounted gateway can realize the routing function through the routing relation represented by the signal names of the receiving end and the signal names of the transmitting end. In addition, the information related to the signal names of the receiving end and the signal names of the transmitting end is extracted from the routing table, namely, the information such as Can, name and name_ID is extracted from each communication matrix in the routing table, then the signal names of the receiving end and the signal names of the transmitting end are respectively constructed according to the formats, and then the routing table path is constructed according to the constructed signal names of the receiving end and the signal names of the transmitting end.
The grouping conditions may be flexibly set according to actual requirements, for example, in some requirements, the grouping conditions include: one or more of vehicle model, route type, CAN channel, and exhaust emission standard. Wherein, the vehicle type can be divided into: conventional vehicle types (such as fuel vehicles), PHEVs (plug-in hybrid vehicles), and EVs (electric only vehicles), and the like. The routing type refers to, for example, that the transmitted message is a diagnostic message or an application message. The CAN channel indicates which CAN the vehicle gateway sends the message out from, such as CAN6; the exhaust emission standard refers to, for example, the supporting situation of the automobile to the country V and the country VI. For example, in a project, where PHEV, EV, route type, CAN channel and exhaust emission standard are required as grouping conditions, the grouping conditions generated for a certain communication matrix in the routing table may be, for example: < PHEV: y; EV is N; route type: diagnosing; CAN channel: can6; GA/V/VI: V >.
Step S12, a grouping dictionary is obtained.
Wherein the grouping dictionary comprises: the plurality of routing packets respectively correspond to different packet conditions. For example, the style of the grouping dictionary may be as follows:
routing packet 1: condition 1 1 Condition 2 1 … …, condition n 1 ;
……
Routing packet n: condition 1 m Condition 2 m … …, condition n m 。
In other words, the routing packet is defined by a combination of all possible values of condition 1 to condition n, i.e. all possible combinations of packet conditions. In addition, the packet dictionary does not include a routing table path. Wherein, the conditions 1 to n are determined according to actual requirements. In some embodiments, conditions 1 through n include: vehicle type, route type, CAN channel and exhaust emission standard. In other embodiments, conditions 1 through n include a vehicle model, a routing type, and a CAN channel.
In some embodiments, the packet dictionary may be generated and stored in advance, and step S12 specifically refers to obtaining a pre-stored packet dictionary; for example, in some embodiments, a grouping dictionary for this requirement may be pre-constructed by a developer according to the requirement and stored in the system. In other embodiments, to increase the versatility of the present approach, a packet dictionary is generated from the acquired routing table. Specifically:
all packet-related data types (e.g., PHEV, EV, CAN lanes, GA/V/VI) are first extracted from the acquired routing table. Wherein, which data types are related to the packet can be predefined, for example, in the first row (i.e. the first row) of the table head of the routing table, certain types can be defined as being related to the packet by adding keywords; after extracting the data of the row of the table head, determining whether the data type corresponding to each column is related to the group according to whether each column contains a preset keyword; for example, if the data recorded in a certain column in the header is "packet-PHEV", and the packet is a predefined key, it may be determined from the packet that "PHEV" is the data type associated with the packet.
Then, a plurality of grouping conditions are generated according to the combination of the data types. After all packet-related data types are extracted, the data types are arranged in a predetermined order (e.g., column size) and all possible packet conditions are generated based on a combination of possible values for each data type, e.g., PHEV, EV, CAN lanes and GA/V/VI are packet-related data types, all possible values for which may be combined in the order PHEV, EV, CAN lanes and GA/V/VI to generate all possible packet conditions. Wherein the order of the respective data types here needs to be the same as the order of the respective conditions in the grouping condition in step S11 in order to make comparison easier at the time of grouping.
Finally, all routing packets are defined by these packet conditions. That is, each packet condition represents one routing packet.
It should be noted that, when the packet dictionary is generated according to the routing table, the step S11 and the step S12 may be performed simultaneously or the step S11 may be performed first or the step S12 may be performed first, which are not limited in this embodiment.
Step S13, grouping the routing table paths according to the grouping conditions of step S11 and the grouping dictionary of step S12.
When the grouping is performed, step S13 may match the grouping condition obtained from each communication matrix with the grouping condition in the grouping dictionary, and when the same grouping condition is matched, divide the corresponding routing table path into the grouping corresponding to the matched grouping condition; thus, routing table paths having the same grouping condition can be divided into the same grouping.
And step S14, generating a routing configuration file according to the grouping result. And
and step S15, configuring the vehicle-mounted gateway according to the routing configuration file generated in the step S14.
In step S14, the routing configuration file may be generated by updating the PduR (protocol data unit routing) configuration file. For example, an empty PduR profile may be loaded and then the routing table path added to the PduR profile as a result of the grouping.
In step S15, the routing configuration file may be compiled into a binary file, and then burned into the memory of the vehicle-mounted gateway to implement the routing configuration.
According to the embodiment, the routing table paths are grouped by utilizing the grouping dictionary, so that the grouping efficiency and accuracy are improved, and the routing configuration efficiency and accuracy are further improved.
As shown in fig. 2, a flow chart of another embodiment of the route configuration method of the present application includes the following steps:
in step S20, a routing table, for example, an xls-format file, is obtained, in which many pieces of routing information are filled, and needs to be configured in the vehicle-mounted gateway product.
Step S21, extracting required data from the routing table of step S21, the data including, for example: vehicle type, routing type, CAN channel, received message name, transmitted message name, etc. In general, the extracted data is mainly data related to the packet and data related to generating the routing table path.
Step S32, generating information available in line with EB tresos, and constructing a packet dictionary. The information meeting the EB tresos is, for example, a routing table path meeting the EB tresos requirement, where the routing table path is a field that can be directly used by a xdm format configuration file in the EB tool, and can be directly filled into the xdm format configuration file.
Step S23, grouping the routing table paths, and storing grouping results into a database.
Steps S24 and S25 update pdur.
Step S26, generating a Pdur. Xdm file and related files (such as an application layer code file in the format of. c.h).
And step S27, compiling the files generated in the step S26 together and burning the files to the vehicle-mounted gateway, so that the routing configuration of the vehicle-mounted gateway is realized.
In this embodiment, the routing configuration is mainly implemented based on the EB tresos and other tools, and in the EB tresos and other tools, a packet dictionary is introduced to implement fast and accurate routing packets, and a mode of updating pdur.
As shown in fig. 3, a schematic structural diagram of an embodiment of the route configuration device 3 for an in-vehicle gateway of the present application is shown. It comprises the following steps: a routing table obtaining module 30, configured to obtain a routing table; a processing module 31, configured to generate a routing table path and a packet condition of the routing table path according to the obtained routing table; a packet dictionary acquisition module 32 for acquiring a packet dictionary; a grouping module 33, configured to group the routing table paths according to grouping conditions of the routing table paths and the grouping dictionary, so as to divide the routing table paths into the plurality of routing packets; a configuration file generating module 34, configured to generate a routing configuration file according to the result of the grouping; and a configuration module 35, configured to configure the vehicle gateway according to the routing configuration file. It should be noted that the details of the operation related to the routing configuration device 3 are described in the foregoing method embodiments, and are not described herein for brevity.
As shown in fig. 4, a schematic structural diagram of an embodiment of the electronic device 4 of the present application, wherein the electronic device 4 is in the form of a general purpose computing device for configuring the routing of the vehicle gateway. The electronic device 4 may include, but is not limited to: at least one memory unit 41 and at least one processing unit 42.
In which the storage unit 41 stores program code executable by the processing unit 42 so that the processing unit 42 performs the route configuration method described in the present specification. For example, the processing unit 42 may perform the steps shown in fig. 1 and 2.
The storage unit 41 may include a readable medium in the form of a volatile storage unit, such as a Random Access Memory (RAM) and/or a cache memory unit, and may further include a Read Only Memory (ROM).
In addition, the electronic device 4 may further include: a display unit 44 for interaction with a user, which is connected to an input/output (I/O) interface 43.
In addition, the electronic device 4 may also communicate with one or more external devices (e.g., keyboard, bluetooth device, etc.) via the I/O interface 43. In addition, electronic device 4 may also communicate with one or more networks such as a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network, such as the Internet, through network adapter 45.
The embodiment of the present application also provides a computer-readable storage medium having stored thereon a computer program comprising executable instructions which, when executed by a processor, implement the route configuration method of the present application, such as the route configuration methods shown in fig. 1 and 2.
From the above description of the embodiments, it will be clear to those skilled in the art that the above-described embodiment method may be implemented by means of software plus a necessary general hardware platform, but of course may also be implemented by means of hardware, but in many cases the former is a preferred embodiment. Based on this understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a storage medium (such as ROM/RAM, magnetic disk, optical disk) as described above, including several instructions for causing a terminal device (which may be a mobile phone, a computer, a server, a controller, or a network device, etc.) to perform the method according to the embodiments of the present application.
The foregoing description is only of the preferred embodiments of the present application, and is not intended to limit the scope of the application, but rather is intended to cover any equivalents of the structures or equivalent processes disclosed herein or in the alternative, which may be employed directly or indirectly in other related arts.