Method for automatic checking of software interface table for embedded controller software integration

Abstract

The present invention discloses a method for automatically checking a software interface table for software integration of an embedded controller, wherein the software interface table contains several sheets, each sheet represents a software component and each sheet is named after the name of the software component, each sheet includes all output and output interfaces of the software component and the attributes of each interface, and comprises the following steps: establishing checking rules for the integrity of the content of the software interface table, checking rules for Signal Name, checking rules for App Type, checking rules for interface correlation, and checking rules for the validity of CAN signal input / output, and then establishing a checking model based on the above-mentioned checking rules; importing the software interface table to be checked into the established checking model, automatically checking the software interface table to be checked, and generating an inspection report, marking the background color of the cells with problems in the software interface table, so as to facilitate manual inspection by developers. The method can effectively improve the correctness of inspection and work efficiency.

Description

Technical Field

[0001] The invention belongs to the technical field of computer information processing, and in particular relates to a method for automatically checking a software interface table for software integration of an embedded controller. Background Art

[0002] The embedded controller software consists of various software components (SWCs). After the development of each SWC is completed, the integration engineer needs to integrate the SWC codes together and compile the binary files to download to the embedded controller for execution. The main work of software integration is to connect the input and output interfaces of each SWC, compile them in the development environment, and generate binary files. As the main document to guide software integration, the software interface table must correctly describe the input and output interfaces of each SWC and strictly match the attributes such as variable names and data types.

[0003] If the description of each SWC in the software interface table is inaccurate, it will directly affect the software integration. However, the existing method is to check the software interface table through manual comparison, which not only wastes manpower, but also makes people easily tired in the face of large amounts of data, resulting in low accuracy and low work efficiency. Summary of the invention

[0004] In view of the above-mentioned deficiencies in the prior art, the purpose of the present invention is to provide a method for automatically checking a software interface table for embedded controller software integration, which method can effectively improve the checking accuracy and work efficiency.

[0005] The technical solution of the present invention is achieved in this way:

[0006] A method for automatically checking a software interface table for software integration of an embedded controller, wherein the software interface table contains a plurality of sheets, each sheet represents a software component and each sheet is named after the software component, each sheet includes all outputs and output interfaces of the software component and the attributes of each interface, wherein the attributes include but are not limited to Access, Origin / Destination, Signal Name, Name In Chinese, ID, Cycle Time, Bytes Segment, Signal Start Bit, Signal Length, Factor, Offset, Physical Range Min, Physical Range Max, Signal Type, Unit, Description, Initial Value, Invalid Value and App Type; comprising the following steps:

[0007] S1: Establish checking rules for the integrity of the software interface table content, the Signal Name, the App Type, the interface relevance, and the CAN signal input / output validity, and then establish a checking model based on the above checking rules;

[0008] S2: Import the software interface table to be checked into the inspection model established in S1, automatically check the software interface table to be checked, generate an inspection report, and mark the background color of the cells with problems in the software interface table to facilitate manual inspection by developers.

[0009] Furthermore, the checking rule for content integrity is: check whether the content of each sheet in the software interface table is complete. If it is not complete, the background of the corresponding cell is marked in red.

[0010] Furthermore, the check rule for Signal Name is: Signal Name naming format is gALXXXY_Name, where:

[0011] gAL starts with.

[0012] XXX is the abbreviation of the software component name and should be the same as the corresponding sheet name.

[0013] If Y=I, the Access in the software interface table is INPUT. If Y=O or there is no Y, the Access in the software interface table is OUTPUT.

[0014] The variable name corresponding to Signal Name cannot exceed 32 characters.

[0015] If any item does not meet the requirements, the background of the corresponding cell will be marked in red.

[0016] Furthermore, the checking rule of Signal Type is: check whether the interval formed by Physical Range Min and Physical Range Max in the software interface table crosses 0. If it crosses, the Signal Type is defined as Signed, otherwise, the Signal Type is defined as Unsigned. If it does not meet the rules, the background of the corresponding cell is marked red.

[0017] Furthermore, the checking rule of App Type is: the App Type can be defined as any one of uint8, uint16, uint32, boolean, float, double, fixdt(x,y,z) or fixdt(a,b,c,d).

[0018] When App Type is defined as uint8, uint16, uint32, boolean, float, or double, the corresponding Signal Type is Unsigned.

[0019] When App Type is defined as fixdt(x,y,z), when X=0, the corresponding Signal Type is Unsigned; when X=1, the corresponding Signal Type is Signed, and the corresponding Offset is 0; y is the same as the corresponding signal Length (bits); 1 / 2 to the power of z is the same as the corresponding Factor.

[0020] When App Type is defined as fixed(a,b,c,d), when a=0, the corresponding Signal Type is Unsigned; when a=1, the corresponding Signal Type is Signed, and the corresponding Offset is 0; b is the same as the corresponding signal Length(bits); c is the same as the corresponding Factor; and d is the same as the corresponding Offset.

[0021] If any item does not meet the requirements, the background of the corresponding cell will be marked in red.

[0022] Furthermore, if the Origin / Destination of the corresponding interface in any sheet is defined as a software component name, the interface correlation check rule is used for checking, otherwise the CAN signal input / output validity check rule is used for checking.

[0023] Furthermore, the checking rules for interface correlation are as follows: after extracting the Name from the Signal Name attribute, search for the signal with the same Name in the software components defined in the Origin / Destination, and then compare the Name In Chinese, signal Length, Factor, Offset, Physical Range, SignalType, Unit, Description, Initial Value, Invalid Value and App Type properties corresponding to the two interfaces of the two sheets one by one to see if they are the same. If not, the background of the corresponding cell will be marked in red.

[0024] Furthermore, the checking rules for the validity of CAN signal input / output are as follows: in the CAN network segment and ID of the signal source or destination, look for a signal with the same Name. If not found, look for a signal with the same Name In Chinese. If the Name In Chinese found can be completely matched, the background of the corresponding cell is marked yellow; if the Name In Chinese found cannot be completely matched, the background of the corresponding cell is marked red.

[0025] Compared with the prior art, the present invention has the following beneficial effects:

[0026] 1. The present invention first establishes a check model, and then uses the check model to automatically check the software interface table, which greatly improves work efficiency compared to manual inspection.

[0027] 2. The present invention establishes complete inspection rules for inspection. The inspection rules for the integrity of the software interface table content, the inspection rules for the Signal Name and the inspection rules for the App Type can effectively inspect the interface of each software component. The inspection rules for the interface correlation and the inspection rules for the validity of the CAN signal input / output are used to inspect the interaction between software components and between software components and CAN signals, thereby effectively ensuring the correctness of the inspection. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 - Flowchart of the present invention. DETAILED DESCRIPTION

[0029] The present invention is further described in detail below in conjunction with the accompanying drawings and specific embodiments.

[0030] A method for automatically checking a software interface table for software integration of an embedded controller, wherein the software interface table contains a plurality of sheets, each sheet represents a software component and each sheet is named after the software component, each sheet includes all outputs and output interfaces of the software component and the attributes of each interface, wherein the attributes include but are not limited to Access, Origin / Destination, Signal Name, Name In Chinese, ID, Cycle Time, Bytes Segment, Signal Start Bit, Signal Length, Factor, Offset, Physical Range Min, Physical Range Max, Signal Type, Unit, Description, Initial Value, Invalid Value and App Type; comprising the following steps:

[0031] S1: Establish checking rules for the integrity of the software interface table content, the Signal Name, the App Type, the interface relevance, and the CAN signal input / output validity, and then establish a checking model based on the above checking rules;

[0032] S2: Import the software interface table to be checked into the inspection model established in S1, automatically check the software interface table to be checked, generate an inspection report, and mark the background color of the cells with problems in the software interface table to facilitate manual inspection by developers.

[0033] The amount of data in the software interface table is relatively large. After the inspection model is established through the corresponding rules, the software interface table to be inspected can be quickly and efficiently inspected by simply pouring it into the inspection model, thereby improving work efficiency. The inspection rules for the integrity of the software interface table content, the inspection rules for Signal Name, and the inspection rules for App Type can effectively inspect the interface of each software component, and the inspection rules for interface relevance and the inspection rules for CAN signal input / output validity can be used to inspect the interactions between software components and between software components and CAN signals, effectively ensuring the correctness of the inspection. The flowchart of its automatic inspection is shown below. Figure 1 shown.

[0034] For the software interface table, there are the following points:

[0035] 1. Access indicates whether the interface is input (INPUT) or output (OUTPUT).

[0036] 2. Origin / Destination indicates the input source or output destination of the interface, which is one of the interfaces defined by other software components or CAN.

[0037] 3. Signal Name and Name In Chinese indicate the English and Chinese names of the interface respectively.

[0038] 4. ID, Cycle Time, Bytes Segment, and Signal Start Bit indicate the arrangement of the intermediate variables sent through Ethernet.

[0039] 5. Other attributes represent the properties of the interface variable itself.

[0040] In specific implementation, the checking rule for content integrity is: check whether the content of each sheet in the software interface table is complete. If not, the background of the corresponding cell is marked in red.

[0041] In specific implementation, the check rule of Signal Name is: Signal Name naming method is gALXXXY_Name, where:

[0042] (1) Starts with gAL.

[0043] (2) XXX is the abbreviation of the software component name and should be the same as the corresponding sheet name.

[0044] (3) If Y=I, the Access in the software interface table is INPUT. If Y=O or there is no Y, the Access in the software interface table is OUTPUT.

[0045] (4) The variable name corresponding to the Signal Name must not exceed 32 characters.

[0046] If any of (1) to (4) does not meet the requirements, the background of the corresponding cell will be marked in red.

[0047] For example, if the Signal Name attribute is gALSTMI_OBJ3Classification, then STM is the software component name, which is also the name of the sheet, and Y=I, then Access is INPUT.

[0048] In specific implementation, the checking rule of Signal Type is: check whether the interval formed by Physical Range Min (dec)-Offset and Physical Range Max (dec)-Offset in the software interface table crosses 0. If it crosses, the Signal Type is defined as Signed, otherwise, the Signal Type is defined as Unsigned. If it does not meet the rules, the background of the corresponding cell is marked red.

[0049] Here, when Physical Range Min (dec) - Offset is a negative number and Physical Range Max (dec) - Offset is a positive number, it means that the interval formed by Physical Range Min (dec) - Offset and Physical Range Max (dec) - Offset crosses 0, otherwise it means that it does not cross.

[0050] In specific implementation, the App Type inspection rule is: the App Type can be defined as any one of uint8, uint16, uint32, boolean, float, double, fixdt(x,y,z) or fixdt(a,b,c,d). The following rules should be met. If any one of them does not meet the requirements, the background of the corresponding cell will be marked red.

[0051] When App Type is defined as uint8, uint16, uint32, boolean, float, or double, the corresponding Signal Type is Unsigned.

[0052] When App Type is defined as fixdt(x,y,z), X=0 indicates unsigned, and the corresponding Signal Type is Unsigned; X=1 indicates signed, and the corresponding Signal Type is Signed, and the corresponding Offset is 0; y indicates the number of data bits, which is the same as the corresponding signal Length(bits); z indicates the precision, and 1 / 2 to the power of z is the same as the corresponding Factor.

[0053] When App Type is defined as fixed (a, b, c, d), a=0 indicates unsigned, and the corresponding Signal Type is Unsigned; a=1 indicates signed, and the corresponding Signal Type is Signed, and the corresponding Offset is 0; b indicates the number of data bits, which is the same as the corresponding signal Length (bits); c indicates the precision, which is the same as the corresponding Factor; d indicates the offset, which is the same as the corresponding Offset.

[0054] In specific implementation, if the Origin / Destination of the corresponding interface in any sheet is defined as a software component name, the interface correlation check rule is used for checking, otherwise the CAN signal input / output validity check rule is used for checking.

[0055] In specific implementation, the interface correlation checking rules are as follows: after extracting the Name from the Signal Name attribute, look for the signal with the same Name in the software components defined in Origin / Destination, and then compare the Name In Chinese, signal Length, Factor, Offset, Physical Range, SignalType, Unit, Description, Initial Value, Invalid Value and App Type properties corresponding to the two interfaces of the two sheets one by one to see if they are the same. If not, the background of the corresponding cell will be marked red.

[0056] For example, if the Signal Name attribute is gALSTMI_OBJ3Classification, then according to the Signal Name naming method, its Name is OBJ3Classification, and in this sheet, the Origin / Destination attribute is FUS, and the Access attribute is INPUT. Therefore, it can be known that the name of the software component of the interface signal source is FUS output. Then, in the corresponding sheet of FUS, find the Name as OBJ3Classification. In this sheet, the Signal Name attribute is gALFUS_OBJ3Classification or gALFUSO_OBJ3Classification. Then compare the Name In Chinese, signal Length, Factor, Offset, Physical Range, Signal Type, Unit, Description, Initial Value, Invalid Value and App Type corresponding to the two interfaces of the two sheets to see if they are the same. If not, the background of the corresponding cell will be marked red.

[0057] During specific implementation, the checking rules for the validity of CAN signal input / output are as follows: in the CAN network segment and ID of the signal source or destination, look for a signal with the same Name. If not found, look for a signal with the same Name In Chinese. If the Name In Chinese found can be completely matched, the background of the corresponding cell is marked yellow; if the Name In Chinese found cannot be completely matched, the background of the corresponding cell is marked red.

[0058] If the Name In Chinese found can be completely matched, it means that the developer may have deleted the signal name, and the background is marked yellow to prompt the developer to manually check

[0059] If the Name In Chinese cannot be matched completely, it means that the CAN signal used by the developer is not defined in the protocol, and the background is marked in red.

[0060] The specific color of the background label can be set according to the developer's habits. The yellow and red colors are just for distinction.

[0061] Finally, it should be noted that the above embodiments of the present invention are only examples for illustrating the present invention, and are not intended to limit the implementation methods of the present invention. For those skilled in the art, other different forms of changes and modifications can be made based on the above description. It is impossible to list all implementation methods here. Any obvious changes or modifications derived from the technical solution of the present invention are still within the scope of protection of the present invention.

Claims

1. A method for automatically checking a software interface table for embedded controller software integration, wherein the software interface table contains a plurality of sheets, each sheet represents a software component and each sheet is named after the software component, each sheet includes all outputs and output interfaces of the software component and the attributes of each interface, wherein the attributes include Access, Origin / Destination, Signal Name, Name In Chinese, ID, Cycle Time, Bytes Segment, signalStart Bit, signal Length, Factor, Offset, Physical Range Min, Physical Range Max, Signal Type, Unit, Description, Initial Value, Invalid Value and App Type; characterized in that: The following steps are involved: S1: Establish checking rules for the integrity of the software interface table content, the Signal Name, the App Type, the interface relevance, and the CAN signal input / output validity, and then establish a checking model based on the above checking rules; The Signal Name checking rule is as follows: The Signal Name naming method is gALXXXY_Name, where: gAL is the beginning; XXX is the abbreviation of the software component name and should be the same as the corresponding sheet name; If Y=I, the Access in the software interface table is INPUT; if Y=O or there is no Y, the Access in the software interface table is OUTPUT; The variable name corresponding to Signal Name shall not exceed 32 characters. If any item does not meet the requirements, the background of the corresponding cell will be marked red; S2: Import the software interface table to be checked into the inspection model established in S1, automatically check the software interface table to be checked, generate an inspection report, and mark the background color of the cells with problems in the software interface table to facilitate manual inspection by developers.

2. The method for automatically checking the software interface table for embedded controller software integration according to claim 1, characterized in that: The checking rule for content completeness is: check whether the content of each sheet in the software interface table is complete. If not, the background of the corresponding cell is marked in red.

3. The method for automatically checking the software interface table for embedded controller software integration according to claim 1, characterized in that: The checking rule for Signal Type is: check whether the interval formed by Physical Range Min and PhysicalRange Max in the software interface table crosses 0. If it does, the Signal Type is defined as Signed, otherwise, the SignalType is defined as Unsigned. If it does not meet the rules, the background of the corresponding cell is marked red.

4. The method for automatically checking the software interface table for embedded controller software integration according to claim 1, characterized in that: The check rule of App Type is as follows: the App Type can be defined as any one of uint8, uint16, uint32, boolean, float, double, fixdt(x,y,z) or fixdt(a,b,c,d); When App Type is defined as uint8, uint16, uint32, boolean, float, or double, the corresponding SignalType is Unsigned; When App Type is defined as fixdt(x,y,z), when X=0, the corresponding Signal Type is Unsigned; when X=1, the corresponding Signal Type is Signed, and the corresponding Offset is 0; y is the same as the corresponding signal Length (bits); 1 / 2 to the power of z is the same as the corresponding Factor; When App Type is defined as fixed (a, b, c, d), when a=0, the corresponding Signal Type is Unsigned; when a=1, the corresponding Signal Type is Signed, and the corresponding Offset is 0; b is the same as the corresponding signal Length (bits); c is the same as the corresponding Factor; d is the same as the corresponding Offset; If any item does not meet the requirements, the background of the corresponding cell will be marked in red.

5. The method for automatically checking the software interface table for embedded controller software integration according to claim 1, characterized in that: If the Origin / Destination of the corresponding interface in any sheet is defined as a software component name, the interface correlation check rule is used for checking; otherwise, the CAN signal input / output validity check rule is used for checking.

6. The method for automatically checking the software interface table for embedded controller software integration according to claim 5, characterized in that: The rules for checking interface correlation are as follows: after extracting the Name from the Signal Name attribute, search for the signal with the same Name in the software components defined in Origin / Destination, and then compare the Name In Chinese, signal Length, Factor, Offset, Physical Range, Signal Type, Unit, Description, Initial Value, Invalid Value and App Type properties corresponding to the two interfaces of the two sheets one by one to see if they are the same. If not, the background of the corresponding cell will be marked in red.

7. The method for automatically checking the software interface table for embedded controller software integration according to claim 6, characterized in that: The checking rules for the validity of CAN signal input / output are as follows: in the CAN network segment and ID of the signal source or destination, look for a signal with the same Name. If not found, look for a signal with the same Name In Chinese. If the Name In Chinese found can be completely matched, the background of the corresponding cell will be marked yellow; if the Name In Chinese found cannot be completely matched, the background of the corresponding cell will be marked red.

Images