CN115766890A

CN115766890A - Message structure applied to offline test and offline test system

Info

Publication number: CN115766890A
Application number: CN202211246586.0A
Authority: CN
Inventors: 李新乐; 刘华
Original assignee: Huizhou Desay SV Automotive Co Ltd
Current assignee: Huizhou Desay SV Automotive Co Ltd
Priority date: 2022-10-12
Filing date: 2022-10-12
Publication date: 2023-03-07

Abstract

The invention discloses a message structure applied to offline testing and an offline testing system. The message structure comprises: sending a frame message structure and a response frame message structure; the sending frame message structure at least comprises a data flow direction identification part and a message information attribute part; the response frame message structure at least comprises a data flow direction identification part, a response state part and a message information attribute part; the data flow direction identification part is used for confirming a sender and a receiver of the message during offline testing so as to realize message forwarding according to the data flow direction identification part, the message information attribute part is used for indicating basic information of the message, and the response state part is used for confirming the execution condition of the message. The off-line test is carried out through the message structure, when the product to be tested contains a plurality of micro control units and/or a plurality of system level chips, the message can be directly forwarded through the message structure, and the compatibility of the message structure and the product to be tested during the off-line test is improved.

Description

Message structure applied to offline test and offline test system

Technical Field

The embodiment of the invention relates to the technical field of communication, in particular to a message structure applied to offline testing and an offline testing system.

Background

With the coming of the era of intelligent assistant driving of automobiles, the functions of automobile electronic products are more and more complex, wherein due to the increase of the computing power requirement of a domain controller playing a critical role, the hardware complexity and the software complexity of the domain controller are increased in multiples, so that the complexity of an End of Line (EOL) test of the whole automobile is also increased in multiples.

The message structure applied to offline testing in the prior art can meet the offline testing that a product to be tested contains a single Micro Control Unit (MCU) and a single System On Chip (SOC). However, in terms of hardware, the modes of a single MCU and a single SOC have not been able to meet the computational demands, and a mode in which multiple MCUs and multiple SOCs cooperate has emerged.

For a mode of co-operation of multiple MCUs and multiple SOCs, a message structure in the prior art has different message protocols for different products, and with the increase of the number of products, different message protocols need to be formulated for different products, so that the problems of long debugging period and high labor input cost are increasingly significant.

Disclosure of Invention

The invention provides a message structure and an offline test system applied to offline tests, which can meet the requirement of the offline tests of products to be tested, including multiple MCUs and multiple SOCs, and can improve the compatibility of the message structure and the products to be tested during the offline tests.

In a first aspect, an embodiment of the present invention provides a packet structure applied to offline testing, including:

sending a frame message structure and a response frame message structure;

the sending frame message structure at least comprises a data flow direction identification part and a message information attribute part;

the response frame message structure at least comprises a data flow direction identification part, a response state part and a message information attribute part;

the data flow direction identification part is used for confirming a sender and a receiver of the message during offline testing so as to realize message forwarding according to the data flow direction identification part, the message information attribute part is used for indicating basic information of the message, and the response state part is used for confirming the execution condition of the message.

In a second aspect, an embodiment of the present invention provides an offline testing system, where the offline testing system communicates using a message structure applied to offline testing according to the first aspect, and the system includes:

an upper computer and a product to be detected;

the upper computer is used for switching a normal mode and an offline test mode and communicating with a product to be tested in the offline test mode so as to complete offline test;

the product to be tested comprises a micro control unit and/or a system level chip, and the number of the micro control unit and the number of the system level chip are one or more.

The technical scheme of the embodiment of the invention confirms the sender and the receiver of the message through the data flow direction part, obtains the basic information of the message through the message information attribute part, and confirms the execution condition of the message through the response state part. When the product to be tested contains a plurality of MCUs and a plurality of SOCs, the message can be directly forwarded through the message structure, and the compatibility of the message structure and the product to be tested during offline testing is improved.

It should be understood that the statements in this section are not intended to identify key or critical features of the embodiments of the present invention, nor are they intended to limit the scope of the invention. Other features of the present invention will become apparent from the following description.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings required to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the description below are only some embodiments of the present invention, and it is obvious for those skilled in the art that other drawings can be obtained according to the drawings without creative efforts.

FIG. 1 is a schematic illustration of pattern management for a drop-off test;

fig. 2 is a schematic structural diagram of a message structure applied to offline testing according to an embodiment of the present invention;

fig. 3 is a schematic structural diagram of a message structure applied to offline testing according to a second embodiment of the present invention;

fig. 4 is a schematic diagram of an arrangement manner of a message structure applied to offline testing according to a second embodiment of the present invention;

FIG. 5 is a schematic structural diagram of a offline testing system according to a fourth embodiment of the present invention;

fig. 6 is a schematic diagram of a network topology applied to an offline testing system according to a fourth embodiment of the present invention.

Detailed Description

In order to make the technical solutions of the present invention better understood, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

It should be noted that the terms "first", "second", etc. in the present invention are used for distinguishing similar objects, and are not necessarily used for describing a particular order or sequence. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the invention described herein are capable of operation in sequences other than those illustrated or described herein. Moreover, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

The End of Line (EOL) test is the last detection process for the vehicle to perform fault diagnosis, direct/alternating current charging test, and functional verification before leaving the factory. When the vehicle is subjected to offline testing, the process of the offline testing can be divided into two parts: observing whether the diagnosis data flow in the offline flow is correct or not through simulating the instruction of the upper computer; and after the corresponding command is sent, observing whether the action of each actuator is normal. The off-line test of the product to be tested can be realized through the data interaction between the upper computer and the product to be tested.

The off-line test can be managed in the upper computer, if a mode management interface can be displayed in the upper computer, a normal mode and an EOL mode can be selected in the mode management interface, and a user can interact with the upper computer through the mode management interface to realize mode management of the off-line test.

Fig. 1 is a schematic diagram of mode management for offline testing, which is divided into a normal mode, an EOL password waiting mode, and an EOL mode, as shown in fig. 1. Normal mode may be understood as not entering EOL mode and not necessarily EOL mode. In the EOL password waiting mode, a user can interact with an upper computer through a mode management interface, a password is input in the upper computer, and the EOL password waiting mode is a mode for waiting the user to input the password. The EOL mode is a mode for performing offline testing, and only when entering the EOL mode, the upper computer and the product to be tested can perform data interaction through the message corresponding to the message structure applied to the offline testing provided by the invention, that is, the EOL communication instruction can take effect when entering the EOL mode.

As shown in fig. 1, when the EOL mode needs to be entered from the normal mode, the EOL mode is entered through a specific request entry instruction request, when an entry request instruction is received, the EOL password waiting mode may be entered first, a password input by a user is waited in the EOL password waiting mode, and if a password input by the user is received within a specified time T, the EOL mode may be entered; on the contrary, if the password input by the user is not received within the specified time T, the EOL password waiting mode returns to the normal mode through the request exit instruction; when the EOL mode needs to be exited, the EOL mode may be returned to the normal mode by requesting an exit instruction. The designated time T is not limited, and may be a time set according to actual application needs.

The product to be tested can be in a single MCU and single SOC mode or a mode of co-operation of multiple MCUs and multiple SOCs. The existing message structure applied to offline testing can meet the offline testing that products to be tested contain a single MCU and a single SOC, different message protocols can be set for different products to be tested, different message protocols can be set for different products with the increase of the number of the products, the debugging period is long, and the problem of high labor input cost is increasingly obvious.

The invention provides a message structure and an offline test system applied to offline testing, aiming at solving the problem that the existing message structure can not meet the offline test of a product to be tested containing multiple MCUs and multiple SOCs, namely the requirement of complex EOL test function extension, and can meet the offline test of the product to be tested containing multiple MCUs and multiple SOCs and improve the compatibility of the message structure and the product to be tested during the offline test.

Example one

Fig. 2 is a schematic structural diagram of a message structure applied to offline testing according to an embodiment of the present invention, which is applicable to an offline test of a product to be tested by an upper computer.

As shown in fig. 2, the present invention provides a message structure 10 applied to offline testing, which includes:

a transmission frame message structure 11 and a response frame message structure 12;

the transmission frame message structure 11 includes at least a data flow direction identification portion 111 and a message information attribute portion 112;

the response frame message structure 12 includes at least a data flow direction identification portion 111, a response status portion 121, and a message information attribute portion 112;

the data flow direction identifier 111 is used to identify the sender and receiver of the message during offline testing, so as to implement message forwarding according to the data flow direction identifier, the message information attribute 112 is used to indicate the basic information of the message, and the response status 121 is used to identify the execution status of the message.

The sending frame message and the response frame message are messages used for data interaction between the upper computer and the product to be tested in an EOL mode during offline testing, the sending party of the messages can send the messages to be sent to the receiving party by the sending frame message, and the receiving party of the messages can feed back the execution condition of the messages to the sending party by the response frame message. The sender and/or receiver of the message are not limited, and may be an upper computer or an MCU and an SOC in a product to be tested.

It should be noted that the data flow direction identification portion 111 and the message information attribute portion 112 have the same functions and the same structures in the transmission frame message structure 11 and the response frame message structure 12, so the data flow direction identification portion 111 and the message information attribute portion 112 in the transmission frame message structure 11 are taken as an example in the present invention for explanation.

The data flow direction identification part 111 may be used to determine a sender and a receiver of the message during the offline test, and the manner of determining the sender and the receiver of the message during the offline test by the data flow direction identification part 111 is not limited as long as the sender and the receiver of the message can be determined. For example, unique identifiers corresponding to different MCUs and SOCs in the upper computer or the product to be tested may be respectively assigned to the different MCUs and SOCs, and the data flow direction identifier portion 111 may indicate identifiers corresponding to the sender and the receiver when sending or receiving a message.

The identifier is not specifically limited, and may be a unique number or a unique identification number (ID). By respectively giving unique corresponding identifications to different MCUs and SOCs in the upper computer or the product to be tested, the data flow direction identification part 111 can confirm the sender and the receiver of the message through the identifications.

In one embodiment, the upper computer performs data interaction with the product to be tested, so as to realize offline testing of the product to be tested. For example, if there are one MCU and two SOCs (SOC 1 and SOC 2) in the product to be tested, different identifiers may be assigned to the upper computer, the MCU, the SOC1, and the SOC2, respectively, such as numbers 1, 2, 3, and 4 assigned to the upper computer, the MCU, the SOC1, and the SOC2, respectively. When the upper computer needs to perform data interaction with the SOC1, the message can be forwarded through the MCU. The upper computer is used as a sender of the message, the SOC1 is used as a receiver of the message, when the upper computer is communicated with a product to be detected, the message can be sent to the MCU in the product to be detected, the MCU receives the message sent by the upper computer, and the sender and the receiver corresponding to the identification indicated by the data flow direction identification part 111 in the message are identified, namely the sender is identified by the number 1, the receiver is identified by the number 3, the sender is determined to be the upper computer, the receiver is the SOC1, the MCU can forward the message to the receiver SOC1, and then data interaction between the upper computer and the product to be detected is realized.

The number of bytes occupied by the data flow direction identification portion 111 is not limited, as long as the sender and the receiver of the message during the offline test can be confirmed by the data flow direction identification portion 111. In one embodiment, the data stream identifier 111 occupies 2 bytes, and identifiers corresponding to the sender and the receiver are stored in the 2 bytes.

The message information attribute section 112 may be used to indicate basic information of the message. The basic information of the message may describe the content and meaning of the message, and is not limited, for example, the basic information of the message may include, but is not limited to, the length of the message, the type of the communication protocol used when the message is transmitted, the type of the operation that the message needs to execute, or the function that the message needs to implement.

The number of bytes occupied by the message information attribute portion 112 is not limited. In one embodiment, the message information attribute portion 112 occupies 6 bytes.

The transmission frame message structure 11 at least includes a data flow direction identification part 111 and a message information attribute part 112, and the arrangement order of the data flow direction identification part 111 and the message information attribute part 112 is not limited as long as the functions required to be realized by each can be realized.

The response frame message structure 12 is different from the transmission frame message structure 11 in that the response frame message structure 12 includes at least a response status section 121 in addition to the data flow direction identification section 111 and the message information attribute section 112.

The response status portion 121 may be used to confirm the execution of the message. The execution of the message may include, but is not limited to, a command success, a command error, a password error, a failure to enter EOL mode, etc. The response status portion 121 can feed back whether to implement the function that the message should implement when receiving and sending the message. The command may be a command requesting execution of an operation, a read operation, a write operation, or the like.

The number of bytes occupied by the response status portion 121 is not limited. In one embodiment, the response status portion 121 occupies 2 bytes.

The response frame message structure 12 at least includes a data flow direction identification portion 111, a response status portion 121, and a message information attribute portion 112, and the arrangement order of the data flow direction identification portion 111, the response status portion 121, and the message information attribute portion 112 is not limited as long as the functions that are required to be implemented can be implemented.

According to the technical scheme of the embodiment of the invention, the data flow direction part is arranged in the structure of the sending frame message, so that the sender and the receiver of the message can be confirmed according to the data flow direction part, and the message can be forwarded; a message information attribute part is arranged in a sending frame message structure, and the basic information of the message can be obtained according to the message information attribute part; the response frame message structure is characterized in that a response state part is added on the basis of the transmission frame message structure, and the execution condition of the message can be confirmed according to the response state part. When the product to be tested contains a plurality of MCUs and a plurality of SOCs, the message can be directly forwarded through the message structure, and the compatibility of the message structure and the product to be tested during offline testing is improved.

Example two

Fig. 3 is a schematic structural diagram of a message structure applied to offline testing according to a second embodiment of the present invention, and this embodiment further refines the message structure of the sending frame and the message structure of the response frame on the basis of the first embodiment.

In the embodiment of the present invention, the data flow direction identification section 111 includes:

a source identifier 1111 and a target identifier 1112, where the source identifier 1111 and the target identifier 1112 occupy 1 byte respectively;

source identification 1111 is used to identify the sender of the message and destination identification 1112 is used to identify the recipient of the message.

The source identifier 1111 and the target identifier 1112 may store identifiers of a corresponding sender and a corresponding receiver, respectively, and during a process of receiving and sending a message, the sender and the receiver corresponding to the message may be confirmed by the identifiers of the sender and the receiver stored in the source identifier 1111 and the target identifier 1112, which is particularly advantageous for distinguishing the sender and the receiver when there are multiple MCUs and multiple SOCs, thereby improving the efficiency of receiving and sending the message.

In one embodiment, the product to be tested includes two MCUs (MCU 1 and MCU 2) and two SOCs (SOC 1 and SOC 2), the identifiers of the upper computer, MCU1, SOC2 and MCU2 may be preset to 0x01, 0x02, 0x03, 0x04 and 0x05, when the upper computer sends a message to SOC1, the identifier of the sender, i.e. 0x01, is stored in the corresponding source identifier 1111, and the identifier of the receiver, i.e. 0x03, is stored in the target identifier 1112.

In this embodiment of the present invention, the message information attribute part 112 includes:

data overall length 1121, protocol type 1122, main command word 1123, and information tag 1124;

the data total 1121 and information tag 1124 each occupy 2 bytes, and the protocol type 1122 and the main command word 1123 each occupy 1 byte;

the total data length 1121 is used to indicate the length of a message, the protocol type 1122 is used to indicate the type of a communication protocol when the message is transmitted, the main command word 1123 is used to indicate the type of an operation that needs to be performed by the message, and the information tag 1124 is used to indicate the function of the message or to confirm whether data needs to be carried.

The total data length 1121 may be used to indicate the length of the packet. In the transmission frame message structure 11, the total data length 1121 may represent the length of the transmission frame message, that is, the total length occupied by all the parts included in the transmission frame message structure 11. In the response frame message structure 12, the total data length 1121 may represent the length of the response frame message, i.e., the total length occupied by all the parts included in the response frame message structure 12. It should be noted that, in the sending frame message structure and/or the response frame message structure, the message length indicated by the total data length 1121 also includes the message length occupied by the total data length 1121.

In an embodiment, the total data length 1121 occupies 2 bytes, and it can be understood that, in theory, the maximum length of the packet that can be represented by the total data length 1121 may be 65535, and the length of 2 bytes may break through the limit that the maximum length that can be represented by a single byte is 255, so that a single frame packet can adapt to the transmission requirement of more bytes.

The Protocol type 1122 may be used to indicate a communication Protocol type when a message is transmitted, and the communication Protocol type is not limited, and may be, for example, an extensible service-Oriented Middleware Protocol (SOME/IP) based on an Internet Protocol (IP), a Controller Area Network (CAN) Protocol, a CAN flexible Data length (CAN) Protocol improved based on the CAN Protocol, a User Datagram Protocol (UDP) or a Transmission Control Protocol/Internet Protocol (TCP/IP).

In one embodiment, the protocol type 1122 occupies 1 byte, and different protocols may be assigned with different protocol type identifiers, so that the communication protocol type when a message is transmitted is determined by the protocol type identifiers during message transceiving. If the SOME/IP, CANFD, and UDP may be given with their corresponding protocol type identifiers 0x01, 0x02, and 0x03, respectively, when the protocol type 1122 indicates that the protocol type identifier is 0x03, it indicates that the communication protocol type when the packet is transmitted is UDP.

The master command word 1123 may be used to indicate the type of operation that the message needs to perform. The type of the operation to be performed by the message is not limited, and may be, for example, a request to perform an operation, a read operation, and a write operation.

In one embodiment, the type of operation represented by the master command word 1123 includes at least a request to perform operation, a read operation, and a write operation.

The request execution operation may be determined according to the actual application requirement, and the specific content of the request execution operation is not limited, such as the content of the operation that needs to be executed specifically may be indicated by the information tag 1124, and the request execution operation indicated by the main command word 1123 does not indicate the specific content of the operation that needs to be executed.

The read operation may refer to an operation in which a message needs to read data, and the data that needs to be read may be indicated by the read operation read information tag 1124 represented by the main command word 1123.

The write operation may refer to an operation for which data needs to be written, and the data that needs to be written may be indicated by the write operation write information tag 1124 indicated by the main command word 1123.

In one embodiment, the primary command word 1123 occupies 1 byte, and different operation type identifications may be given to different operation types represented by the primary command word 1123. If the operation type identifiers 0x01, 0x02 and 0x03 corresponding to the read operation, the write operation and the request execution operation can be respectively given, when the main command word 1123 indicates that the operation type identifier is 0x01, the operation type required to be executed by the message is the read operation.

The information tag 1124 can be used to indicate the function of the message or to confirm whether data needs to be carried. The information tag 1124 can indicate different functions that the message needs to implement, and determine whether data needs to be carried according to the different functions that the message needs to implement. The different functions that the message needs to implement are not limited, for example, the message needs to request to enter the EOL mode or exit the EOL mode.

In one embodiment, the information tag 1124 occupies 2 bytes, so the information tag 1124 may indicate that the number of different functions to be implemented by the packet is 65536 at most, and each function may be allocated with a unique corresponding function code, that is, 65536 function codes at most may be allocated. Under each functional code, a request execution operation, a read operation, or a write operation may be implemented depending on the different operation type represented by the main command word 1123.

The method for determining whether data needs to be carried is not limited according to different functions to be implemented by the message, and the method specifically needs to be determined according to the functions to be implemented by the message and the actual application scenario. For example, when the information tag 1124 indicates that the function that the message needs to implement is to request to enter the EOL mode, the message needs to carry data such as a password required to enter the EOL mode, and thus it is determined that the data needs to be carried.

In one embodiment, when the information tag confirms that data needs to be carried, the sending frame message structure and/or the response frame message structure further includes:

a data field part 113, the data field part 113 including an information length 1131 and information data 1132;

the information length 1131 occupies 2 bytes, and the length occupied by the information data 1132 is the length of data to be carried;

the information length 1131 is used to indicate the length of data to be carried, and the information data 1132 is used to indicate the data to be carried.

When the information tag confirms that data needs to be carried, data transmission is carried by the data field portion 113. The information length 1131 may be used to indicate the length of data to be carried. Information data 1132 may be used to represent data that needs to be carried, that is, when data needs to be carried, information data 1132 may indicate data itself that needs to be carried, and the length occupied by information data 1132 may be the length of data itself that needs to be carried, and may support variable-length data transmission, and the length that information data 1132 needs to occupy is determined according to the data length that actually needs to be carried.

In an embodiment, the maximum length that the information data 1132 can occupy may be a length that the maximum length of the message that can be represented by the total data length 1121 is removed from a length occupied by the other part except the information data 1132 in the message structure.

In an embodiment, when the function code that can be allocated by the information tag 1124 cannot satisfy all the function codes that need to be allocated, a part of the byte length may be allocated in the information data 1132 for allocating a new function code, and the byte length that can be allocated in the information data 1132 may be determined according to the actual application needs, which is not specifically limited herein.

In the embodiment of the present invention, the response status section 121 includes:

the response result 1211, the response result 1211 occupies 2 bytes, and the response result 1211 is used for confirming the execution condition of the message.

The execution condition of the message is not limited, and the execution condition of the message may include, but is not limited to, a command failure, a command success, a command error, a password error, a failure to enter the EOL mode, and the like. The response result 1211 can feed back whether the function to be implemented by the message is implemented when the message is transmitted or received. The command may be a command requesting execution of an operation, a read operation, a write operation, or the like.

In one embodiment, the response result 1211 occupies 2 bytes, and different execution case identifications may be given to different execution cases represented by the response result 1211. If the response result 1211 indicates that the execution condition identifier is 0x0005, it indicates that the execution condition of the message is a password error, if the execution condition identifiers 0x0000, 0x0001, and 0x0005 are respectively assigned to the command failure, the command success, and the password error.

In one embodiment, the sending frame message structure and/or the response frame message structure further comprises:

and the checking part 114, wherein the checking part 114 includes a checking result 1141, and the checking result 1141 occupies 2 bytes and is used for checking the accuracy of the message.

The Check result 1141 may reflect a Check result of the message, and a manner of checking the message is not limited, for example, the Check result may be Cyclic Redundancy Check-16 (CRC-16), and the CRC-16 can further ensure correctness and integrity of data transmission.

In one embodiment, each part in the transmission frame message structure 11 and/or the response frame message structure 12 and the arrangement sequence between the parts are not limited as long as the functions that the parts should implement can be implemented.

In one embodiment, the arrangement of the sending frame message structure 11 is sequentially: data overall length 1121, protocol type 1122, source identification 1111, target identification 1112, main command word 1123, information tag 1124, information length 1131, information data 1132 and check result 1141;

the response frame message structure 12 is arranged in sequence as follows: data overall length 1121, protocol type 1122, source identification 1111, target identification 1112, master command word 1123, response result 1211, information tag 1124, information length 1131, information data 1132, and check result 1141.

Fig. 4 is a schematic diagram of an arrangement manner of a message structure applied to offline testing according to a second embodiment of the present invention, and fig. 4 illustrates a sending frame message structure 11 and a response frame message structure 12 arranged according to the arrangement manner, where an offline test of an upper computer on a product to be tested can be implemented through a message corresponding to the message structures.

The technical scheme of the embodiment of the invention is to further refine the message structure of the sending frame and the message structure of the response frame. The data flow direction identification part, the message information attribute part and the response state part are respectively divided into a plurality of parts by further refining the data flow direction identification part, the message information attribute part and the response state part, wherein when the information label confirms that data is required to be carried, the sending frame message structure and/or the response frame message structure also comprises a data domain part, and the data transmission can be carried through the data domain part; the check part can reflect the check result of the message, thereby improving the correctness and the integrity of data transmission. When the product to be tested contains a plurality of MCUs and a plurality of SOCs, the message can be directly forwarded through the message structure, and the compatibility of the message structure and the product to be tested during offline testing is improved.

EXAMPLE III

The present embodiment is an exemplary illustration of the above embodiments, and in the embodiments of the present invention, a communication packet structure for an EOL offline test for a production line and an application thereof in EOL mode management are provided, where a mode of managing an EOL mode is consistent with a mode management mode shown in fig. 1.

The communication protocol message structure comprises: a control request frame structure (i.e., a transmission frame message structure) and a feedback message frame structure (i.e., a response frame message structure), where the frame structures include a total data length, a protocol type, a source ID (i.e., a source identifier), a target ID (i.e., a target identifier), a master command (i.e., a master command word), an information tag, an information length, information data, a CRC16 check code (i.e., a check result), and the like. The protocol is suitable for various communication link protocols, such as SOME/IP, CANFD and UDP. The information flow direction can be identified through the source ID and the target ID, the instruction function is expanded through different information labels, the applicability of the protocol message is enhanced through the variable-length information data, and the CRC16 check is added to ensure the reliability of data transmission. The feedback frame with the reply code (i.e. the response result) may feed back the instruction execution condition, including error codes such as information tag error, check error, and non-EOL mode read/write operation error. The message structure has the advantages of strong compatibility, reliable data and error feedback. Misoperation in a non-EOL mode can be avoided by managing the EOL mode and meeting the requirements of a message protocol. And the upper computer of the production line realizes the automatic test of the EOL of the product through the message protocol.

The request frame message structure provided by the embodiment of the invention comprises a data total length, a protocol type, a source ID, a target ID, a main command word, an information tag, an information length, information data and CRC (cyclic redundancy check) check (namely a check result). Wherein, the total length of data of 2 bytes, information label, information length and CRC check can be that the low byte is before and the high byte is after. Table 1 shows a request frame message structure provided in the embodiment of the present invention.

Table 1 request frame message structure

The communication message structure of the EOL offline test for the production line provided by this embodiment may be applicable to protocol types such as SOME/IP, CANFD, UDP, etc., the total length of data and the length of information support variable length information transmission, the length data segment of two bytes may break through the limit of the maximum length of one byte of 255, the maximum length of the message that can be represented may be 65535, and a single frame may be adapted to the transmission requirement of more bytes.

The source ID and the target ID are designed, so that a sender and a receiver of information can be clear, a receiver and a receiver are clear when multiple MCUs and multiple SOCs are provided, the information can be processed in actual use, for example, the information of the upper computer is sent to the MCU1 firstly, the MCU1 detects that the target ID is the SOC1 after receiving the information, and the MCU1 can directly forward the information to the SOC1 for processing without processing.

Main command word (1 byte): the main command word sets a result of requesting execution of a certain operation (i.e., a request to execute an operation), reading a specified information tag (i.e., a read operation), and writing data of the specified information tag (i.e., a write operation).

Information tag (2 bytes): the information tag can also be called functional code, and can support 65536 functional codes at most. The same function code can be read and written according to different main command words.

Information length, information data: when the function corresponding to the information label needs to carry data, the data field transmission is carried by the segment, the information length occupies two bytes, and variable-length data transmission is supported. When the information label is not enough, some bytes can be separated out to be used as a sub-function code so as to achieve the extension of more functions.

Check (2 bytes): the check field can adopt CRC16 check, and compared with a simple single byte check sum mode, the accuracy of the data after passing the check can be better ensured.

The response frame message structure provided by the embodiment of the present invention is substantially the same as the transmission frame, except that a reply code of two bytes (i.e., a response result) is added between the main command word and the information tag, and table 2 shows the response frame message structure provided by the embodiment of the present invention.

Table 2 response frame message structure

In one embodiment, the reply code may be:

EOL _ FAILED =0x0000, command failure;

EOL _ SUCCESSED =0x0001, command success;

EOL _ PASSWORD _ ERROR =0x0005, cipher ERROR;

EOL _ CMD _ CRC _ ERROR =0 × 0006, CRC ERROR;

EOL _ NOT _ IN _ MODE =0x0007, does NOT enter EOL, and receives a read-write command;

EOL _ CMD _ ERROR =0x0009, command ERROR;

EOL _ NEED _ REQ _ FIST =0x000A, EOL was not requested, password was received;

EOL _ info _ ERROR =0x000B, tag ERROR;

EOL _ NVM _ length _ ERROR =0x000E, data length ERROR.

The communication message structure for the EOL offline test for the production line provided by the embodiment has the advantages of strong compatibility, reliable data and error diagnosis; the upper computer of the production line can realize the automatic offline test of the product through the message protocol; modules with multiple processors in a single product can be adapted, EOL modes can be managed, EOL instructions processed or forwarded by specifying a single processor; the network topology structure of the upper computer during EOL test can be simplified; because the structure of the EOL test message is unified, the cost for maintaining a plurality of sets of communication protocols is saved, and the labor input in the message debugging process is saved.

Example four

Fig. 5 is a schematic structural diagram of an offline testing system according to a fourth embodiment of the present invention, which is applicable to an offline test of a product to be tested by an upper computer in this embodiment.

As shown in fig. 5, the present invention provides an offline testing system 20, where the offline testing system 20 can communicate by using the message structure applied to the offline test provided in the foregoing embodiment, and the offline testing system 20 includes:

an upper computer 21 and a product 22 to be detected;

the upper computer 21 is used for switching a normal mode and an offline test mode, and communicating with the product 22 to be tested in the offline test mode to complete the offline test;

the product 22 to be tested includes the micro control unit 221 and/or the system-on-chip 222, and the number of the micro control unit 221 and the system-on-chip 222 is one or more.

It should be noted that, in practical applications, the number of the micro control unit 221 and/or the system-on-chip 222 is not limited, and fig. 5 shows only one micro control unit 221 and two system-on-chips 222 (i.e., SOC1 and SOC 2).

The upper computer 21 may be configured to switch the normal mode and the offline test mode (i.e., EOL mode), and the mode of switching the normal mode and the offline test mode of the upper computer 21 is not limited as long as the normal mode and the offline test mode can be switched. If a mode management interface is displayed in the upper computer, a normal mode and an EOL mode can be selected in the mode management interface, and a user can interact with the upper computer through the mode management interface to realize mode management of offline testing. For example, two controls numbered 1 and 2 are provided in the mode management interface, and the mode management interface can respectively control to enter a normal mode and an EOL mode, and when the control numbered 2 is clicked, it can be understood that the EOL mode needs to be entered, and then a password is input through the mode management interface, so that the EOL mode can be entered, and further the upper computer 21 can perform offline testing on the product 22 to be tested.

In the product 22 to be tested, data interaction between the upper computer 21 and the product 22 to be tested can be realized through the micro control unit 221, and the micro control unit 221 can receive a message sent by the upper computer 21 or the system on chip 222 and realize forwarding of the message according to a target identifier carried by the message. For example, when the message sent by the upper computer 21 indicates that the target identifier is SOC1, the micro control unit 221 may directly forward the message sent by the upper computer 21 to the SOC1, so as to implement data interaction between the upper computer 21 and the SOC 1.

In one embodiment, any one of the micro control units 221 is configured to implement message forwarding between the upper computer 21 and the micro control unit 221 and/or the soc 222 according to the source identifier or the target identifier in the offline test mode.

When the product to be tested comprises a plurality of micro control units 221, any one of the micro control units 221 can be selected as a transfer station for forwarding the message, and data interaction is provided for the upper computer 21 and the product to be tested 22. For example, when the soc 222 is to send a response frame message to the upper computer 21, the response frame message may be sent to the micro control unit 221, after the micro control unit 221 receives the response frame message, the receiving party is determined to be the upper computer 21 according to the target identifier carried in the response frame message, and the response frame message is further forwarded to the upper computer 21, so that the upper computer 21 may receive the response frame message sent by the soc 222, and further may determine the execution condition of the message according to the response result indicated by the response frame message, and meanwhile, the upper computer 21 may also determine the sending party of the response frame message according to the source identifier indicated by the response frame message.

Fig. 6 is a schematic diagram of a network topology applied to an offline testing system according to a fourth embodiment of the present invention, as shown in fig. 6, a Personal Computer (PC) may be provided in the network topology, and the PC corresponds to an upper Computer; the product to be tested can be an Electronic Control Unit (ECU), wherein the ECU comprises two micro Control units (MCU 1 and MCU 2) and two system-on-chip (SOC 1 and SOC 2), and when the product to be tested enters an EOL mode, the upper computer can perform offline testing on the product to be tested.

When a plurality of MCUs and SOCs are arranged in the ECU, one designated MCU can be used as a management module of the EOL mode. For example, as shown in fig. 6, after the MCU1 enters the EOL mode, the MCU1 may receive an EOL communication instruction, and when the message sent by the upper computer indicates the target identifier SOC1, the MCU1 may forward the data to the SOC1, and when the SOC1 replies the data, the MCU1 may also forward the data to the upper computer through the MCU 1. MCU2, SOC2, etc. in the ECU can all forward data through MCU1, which benefits from the design of message source identification and target identification in the invention.

According to the technical scheme of the embodiment of the invention, any micro control unit contained in the product to be tested is used as a transfer station for forwarding the message, so that data interaction between the upper computer and the product to be tested can be realized, and the upper computer can perform offline test on the product to be tested. Meanwhile, the offline test system can use the message structure applied to the offline test to carry out communication, when a product to be tested contains a plurality of MCUs and a plurality of SOCs, the message structure can be directly used for forwarding the message, and the compatibility of the message structure and the product to be tested during the offline test is improved.

It should be understood that various forms of the flows shown above, reordering, adding or deleting steps, may be used. For example, the steps described in the present invention may be executed in parallel, sequentially, or in different orders, and are not limited herein as long as the desired result of the technical solution of the present invention can be achieved.

The above-described embodiments should not be construed as limiting the scope of the invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may be made, depending on design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A message structure applied to offline testing, comprising:

sending a frame message structure and a response frame message structure;

2. The structure of claim 1, wherein the data flow identification portion comprises:

the system comprises a source identifier and a target identifier, wherein the source identifier and the target identifier respectively occupy 1 byte;

the source identification is used for confirming a sender of the message, and the target identification is used for confirming a receiver of the message.

3. The architecture of claim 1, wherein the message information attribute section comprises:

the data total length, the protocol type, the main command word and the information label;

the total data length and the information label occupy 2 bytes respectively, and the protocol type and the main command word occupy 1 byte respectively;

the total data length is used for representing the length of a message, the protocol type is used for representing the communication protocol type when the message is transmitted, the main command word is used for representing the operation type to be executed by the message, and the information label is used for representing the function of the message or confirming whether the message needs to be carried with data.

4. The structure of claim 3, wherein when the information tag confirms that data needs to be carried, the transmit frame message structure and/or the response frame message structure further comprises:

a data field part including an information length and information data;

the information length occupies 2 bytes, and the length occupied by the information data is the length of data to be carried;

the information length is used for representing the length of data to be carried, and the information data is used for representing the data to be carried.

5. The architecture of claim 3, wherein the type of operation represented by the master command word includes at least a request to perform operation, a read operation, and a write operation.

6. The structure of claim 1, wherein the response status portion comprises:

and a response result, wherein the response result occupies 2 bytes and is used for confirming the execution condition of the message.

7. The architecture of claim 1, wherein the transmit frame message structure and/or the response frame message structure further comprises:

and the checking part comprises a checking result, and the checking result occupies 2 bytes and is used for checking the accuracy of the message.

8. The structure according to any one of claims 1 to 7,

the arrangement of the sending frame message structure is as follows in sequence: the method comprises the steps of data total length, protocol type, source identification, target identification, main command word, information tag, information length, information data and verification result;

the arrangement of the response frame message structure is as follows in sequence: the method comprises the steps of data total length, protocol type, source identification, target identification, main command word, response result, information tag, information length, information data and verification result.

9. An offline testing system, which communicates using the message structure applied to offline testing of any of claims 1-8, the system comprising:

the system comprises an upper computer and a product to be detected;

the upper computer is used for switching a normal mode and an off-line test mode and communicating with a product to be tested in the off-line test mode so as to complete off-line test;

10. The system according to claim 9, wherein any one of the micro control units is configured to implement message forwarding between the upper computer and the micro control unit and/or the soc according to a source identifier or a target identifier in an offline test mode.