Airborne software fault log recording method based on ARINC653

Abstract

The invention belongs to the technical field of airborne application software. The invention provides an airborne software fault log recording method based on ARINC653. According to the embodiment of the invention, the header content of the fault log storage space comprises an airborne software name, the size of a fault log fixed storage block, the size of a fault log circulating storage block and a circulating storage block vernier; when the airborne software has a fault, the fault of the airborne software is captured from an operating system interface return code or a callback error processing function return code; traversing and searching a corresponding fault type and a storage position in the fault log record index according to the log identifier in the fault log; if the fault is an idempotent fault, writing the fault log into a fault log fixed storage block; and if the fault is a non-idempotent fault, writing the fault log into a fault log circulating storage block. According to the method, the captured faults are normalized and formatted to be recorded in the nonvolatile storage, so that subsequent reading and analysis are facilitated.

Description

Technical Field

[0001] The embodiments of the present disclosure relate to the technical field of airborne application software, and in particular to an airborne software fault log recording method based on ARINC653. Background Art

[0002] With the continuous development of aviation airborne equipment, new requirements have been placed on airborne platforms regarding functionality, space, weight, and energy consumption. The previous federated system architecture no longer meets these requirements, leading to a shift towards integrated systems. In integrated systems, various systems share a common computing platform, reducing hardware costs and energy consumption, increasing functional diversity, and improving software modularity and reuse. This, coupled with increasing complexity in overall system integration and verification difficulties, has led to the introduction of operating systems within integrated systems. To enable various application software to utilize operating systems, the industry developed the ARINC 653 standard, which specifies the application programming interfaces (APIs) that operating systems should provide, standardizing and unifying the design and implementation of airborne application software.

[0003] When application software on an ARINC 653 operating system calls its function signatures, it performs operations such as process creation, communication port creation, data transmission and reception, process scheduling, partition configuration, and error handling. However, as application software becomes increasingly powerful, failures often occur during these operations. These failures are often difficult to log, creating significant challenges for maintenance personnel.

[0004] Therefore, it is necessary to improve one or more problems existing in the above-mentioned related technical solutions.

[0005] It should be noted that this section is intended to provide background or context for the technical solutions of the present disclosure stated in the claims. The description herein is not admitted to be prior art by virtue of being included in this section. Summary of the Invention

[0006] In order to avoid the shortcomings of the prior art, the present application provides an airborne software fault log recording method based on ARINC653 to solve the problem in the prior art that application software faults cannot be recorded.

[0007] According to an embodiment of the present disclosure, a method for recording an airborne software fault log based on ARINC 653 is provided, the method comprising: Step S1, accessing a storage space and initializing a fault log storage space header of the storage space; Step S2, checking whether there is a fault according to the return code of the ARINC653 operating system; Step S3: If a fault occurs, a single fault log is constructed according to the return code; wherein the fault log includes the UTC time of the log occurrence, the log identifier, and the log message; Step S4, searching the fault log record index for the corresponding fault type and storage location according to the log identifier; wherein the fault type includes idempotent fault and non-idempotent fault; Step S5: If the fault is an idempotent fault, the fault log is written into a fault log fixed storage block, and the process returns to step S2; Step S6: If the fault is a non-idempotent fault, the fault log is written into the fault log circular storage block, and the process returns to step S2.

[0008] Furthermore, the step S1 includes: Set the name of the onboard software, the size of the fault log fixed storage block, the size of the fault log circular storage block, and read the circular storage block cursor.

[0009] Furthermore, the size of the fault log storage space header is 16 bytes, the size of the onboard software name is 4 bytes, the size of the fault log fixed storage block is 4 bytes, the size of the fault log circular storage block is 4 bytes, and the size of the circular storage block cursor is 4 bytes.

[0010] Furthermore, the step S2 includes: Obtaining a return code of the ARINC 653 operating system, and determining whether an onboard software fault exists based on a value of the return code and a preset fault rule; If there is a failure, the return code is captured.

[0011] Furthermore, the return code includes: Interface return code and error handling function return code.

[0012] Furthermore, the step S4 includes: The log identifier searches for the fault type and the storage location of the fault in the corresponding relationship table of all fault types and storage locations in the fault log record index; The fault is determined to be the idempotent fault or the non-idempotent fault according to the fault type.

[0013] Furthermore, step S6 includes: If the fault is a non-idempotent fault, the circular storage block cursor indicates a writable position in the circular storage block, and the fault log is written to the position; Then, the fault log is written into the corresponding storage address according to the circular storage block cursor; The circular storage block cursor is added with a log length, and the newly added circular storage block cursor is written back to the head of the fault log storage space, and the process returns to step S2.

[0014] Furthermore, the fault log in the circular storage block is recorded from the starting position of the circular storage block, and is added each time a fault occurs; when the fault log in the circular storage block is full, the record is overwritten from the starting position of the circular storage block.

[0015] Furthermore, after the circular storage block cursor is increased, the circular storage block cursor value in the head of the fault log storage space is written back.

[0016] Furthermore, the size of the fault log is 16 bytes; wherein, The size of the UTC time of the log occurrence is 8 bytes, the size of the log identifier is 4 bytes, and the size of the log message is 4 bytes.

[0017] The technical solutions provided by the embodiments of the present disclosure may have the following beneficial effects: In an embodiment of the present disclosure, the above-mentioned method for recording airborne software fault logs based on ARINC653 is as follows: on the one hand, the airborne software runs on the ARINC653 operating system and can access a non-volatile memory, and the storage space of the non-volatile memory is divided into a fault log storage space header, a fault log fixed storage block, and a fault log circular storage block; the fault log storage space header content includes the airborne software name, the fault log fixed storage block size, the fault log circular storage block size, and the circular storage block cursor; when the airborne software fails, the airborne software fault is captured from the ARINC653 operating system interface return code or the callback error handling function return code; according to the log identifier in the fault log, the corresponding fault type and storage location are traversed in the fault log record index; if the fault is an idempotent fault, the fault log is written to the fault log fixed storage block; if the fault is a non-idempotent fault, the fault log is written to the fault log circular storage block. On the other hand, the captured fault can be standardized and formatted and recorded in the non-volatile storage for subsequent reading and analysis. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The accompanying drawings are incorporated into and constitute a part of the specification, illustrate embodiments consistent with the present disclosure, and together with the specification, are used to explain the principles of the present disclosure. Obviously, the drawings described below are only some embodiments of the present disclosure, and those skilled in the art can derive other drawings based on these drawings without inventive effort.

[0019] Figure 1 A diagram showing the steps of an ARINC 653-based airborne software fault logging method in an exemplary embodiment of the present disclosure; Figure 2 A schematic diagram showing the division of storage space in an exemplary embodiment of the present disclosure is shown; Figure 3 A specific flow chart of an ARINC 653-based airborne software fault logging method in an exemplary embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0020] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be embodied in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete and will fully convey the concepts of the example embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0021] In addition, the accompanying drawings are merely schematic illustrations of embodiments of the present disclosure and are not necessarily drawn to scale. Like reference numerals in the figures represent like or similar parts, and thus repeated descriptions thereof will be omitted. Some of the blocks shown in the accompanying drawings are functional entities and do not necessarily correspond to physically or logically separate entities.

[0022] This example embodiment provides an ARINC653-based airborne software fault logging method. Figure 1 As shown in , the ARINC653-based airborne software fault log recording method may include: steps S1 to S6.

[0023] Step S1, accessing a storage space and initializing a fault log storage space header of the storage space; Step S2, checking whether there is a fault according to the return code of the ARINC653 operating system; Step S3: If a fault occurs, a single fault log is constructed according to the return code; wherein the fault log includes the UTC time of the log occurrence, the log identifier, and the log message; Step S4, searching the fault log record index for the corresponding fault type and storage location according to the log identifier; wherein the fault type includes idempotent fault and non-idempotent fault; Step S5: If the fault is an idempotent fault, the fault log is written into a fault log fixed storage block, and the process returns to step S2; Step S6: If the fault is a non-idempotent fault, the fault log is written into the fault log circular storage block, and the process returns to step S2.

[0024] The above-mentioned airborne software fault logging method based on ARINC653, on the one hand, the airborne software runs on the ARINC653 operating system and can access a non-volatile memory, and the storage space of the non-volatile memory is divided into a fault log storage space header, a fault log fixed storage block, and a fault log cyclic storage block. The fault log storage space header includes the airborne software name, the size of the fault log fixed storage block, the size of the fault log cyclic storage block, and the cyclic storage block cursor. When the airborne software fails, the airborne software fault is captured from the return code of the ARINC653 operating system interface or the return code of the callback error handling function. The corresponding fault type and storage location are traversed in the fault log record index based on the log identifier in the fault log. If the fault is an idempotent fault, the fault log is written to the fault log fixed storage block; if the fault is a non-idempotent fault, the fault log is written to the fault log cyclic storage block. On the other hand, the captured fault can be recorded in a standardized and formatted form in the non-volatile storage for subsequent reading and analysis.

[0025] Below, we will refer to Figures 1 to 3 Each step of the above-mentioned method for recording airborne software fault logs based on ARINC 653 in this example implementation is described in more detail.

[0026] In step S1, Figure 2 As shown, the non-volatile memory should provide a continuous storage space for storing fault content, and the storage space should be divided into three parts: the fault log storage space header, the fault log fixed storage block and the fault log circular storage block; among them, the fault log header content includes the name of the onboard software, the size of the fault log fixed storage block, the size of the fault log circular storage block and the circular storage block cursor.

[0027] In a specific embodiment, the storage space of the fault log should be a continuous space on the non-volatile storage, and divided into the fault log storage space header, the fault log fixed storage block, and the fault log circular storage block in sequence, such as Figure 2 shown.

[0028] More specifically, the size of the fault log storage space header is 16 bytes, the size of the onboard software name is 4 bytes, the size of the fault log fixed storage block is 4 bytes, the size of the fault log circular storage block is 4 bytes, and the size of the circular storage block cursor is 4 bytes.

[0029] In a specific embodiment, the fault log name is marked with four characters and occupies 4 bytes; Fixed block size for fault logs: This size is 4 bytes and is equal to the number of idempotent fault entries. Fault log ring buffer block size: occupies 4 bytes. Its size is the total size of the fault log storage space minus the fixed storage block size. Ring buffer block cursor: occupies 4 bytes, and its value is the current location of the fault recordable in the ring buffer block.

[0030] In steps S2 and S3, the return code from the ARINC 653 operating system is obtained. Based on the return code value and preset fault rules, it is determined whether the onboard software has a fault. If a fault exists, the return code is captured and a single fault log is constructed based on the return code. Return codes include interface return codes and error handling function return codes. The fault log contains the UTC time the log occurred, the log identifier, and the log message.

[0031] In a specific embodiment, the structure of a single fault log is designed as follows: Occurrence time: log time, occupies 8 bytes, and its value is UTC time; Log tag: occupies 4 bytes and is a unique identifier for each fault log; Log message: occupies 4 bytes. The specific message of each fault log can be the return code of the calling interface or the fault address obtained in the error handling function.

[0032] In a specific embodiment, the size of the fault log is 16 bytes, wherein the size of the UTC time of the log occurrence is 8 bytes, the size of the log identifier is 4 bytes, and the size of the log message is 4 bytes.

[0033] In step S4, when a fault occurs, the onboard software queries the fault log record index to determine whether the fault log should be recorded in a fixed location in a fixed storage block or in a cyclic storage block. The fault log record index is a table of correspondences between all fault types and storage locations, and the table is stored within the onboard software.

[0034] The fixed storage block of the fault log is used to record idempotent faults. Idempotent faults are faults that are recorded in a fixed location no matter how many times they occur.

[0035] The fault log circular storage block is used to record non-idempotent faults. Each time a non-idempotent fault occurs, a new fault log is added.

[0036] In steps S5 and S6, if it is determined that the fault log is stored in a fixed storage block, the fixed address is written and the process returns to S2; if it is determined that the fault log is stored in a circular storage block, the storage address is determined by the circular storage block cursor, the circular storage block cursor is updated after writing the fault log, and the circular storage block cursor in the head of the fault log storage space is written back, and the process returns to S2.

[0037] Specifically, the fault log in the cyclic storage block starts recording from the starting position of the cyclic storage block. Each time a fault occurs, an additional fault is added. When the fault log in the cyclic storage block is full, the record is overwritten from the starting position of the cyclic storage block.

[0038] The circular storage block cursor is used to indicate the writable position of the current fault log in the circular storage block. After the new fault log is recorded, the circular storage block cursor adds a log length.

[0039] The size of each fault log is the same. Each log should contain the log occurrence time, log identifier and log message. The log occurrence time is UTC time, the log identifier is a unique identifier indicating the fault type, and the log message is the return code of the ARINC653 operating system interface or the return code of the callback error handling function.

[0040] The fault log in the circular storage block starts recording from the starting position of the circular storage block, and is added each time a fault occurs; when the fault log in the circular storage block is full, the record is overwritten from the starting position of the circular storage block.

[0041] After the circular storage block cursor is increased, the circular storage block cursor value in the head of the fault log storage space is written back.

[0042] In a specific embodiment, the specific process of recording the fault log is as follows: When a fault occurs, use its log ID to traverse the fault log record index to find the fault log storage location; Idempotent faults are stored in the fault log fixed storage block after their storage address is determined in the fault log record index based on the log identifier. For non-idempotent faults, the log identifier does not indicate a fixed address in the fault log record index. Instead, it points to a fault log circular storage block. In this case, the storage address must be determined based on the circular storage block cursor in the head of the fault log storage space. The calculation method is as follows:

[0043] in The size of a single log.

[0044] After a write failure, the circular storage block cursor should be updated. When the circular storage block is full, it is overwritten from the beginning of the circular storage block. Therefore, the update calculation method is as follows:

[0045] In update Afterwards, the fault log storage space header should be written back.

[0046] In one embodiment, the present application aims to record the content of the fault when the airborne software running based on ARINC653 encounters a fault, so as to facilitate the subsequent troubleshooting and analysis of the fault. Airborne software based on ARINC653 needs to call the standard interface of the airborne application software that complies with the ARINC653 standard to implement. These standard interfaces are usually provided by the operating system and usually include process creation, transmission port creation, receiving and sending messages, creating error handling functions, process startup and partition scheduling startup, etc., in addition to specific peripheral interfaces. Faults that occur during software operation are generally captured through the return code of the interface or in the callback error handling function. The present application proposes a method for capturing fault log records, a method for designing log formats, a method for dividing storage space, and a method for addressing storage locations. The present method can standardize and format the captured faults and record them in non-volatile storage for subsequent reading and analysis.

[0047] like Figure 3 FIG. 1 is a flow chart of an airborne software fault log recording method based on ARINC 653.

[0048] The above-mentioned airborne software fault logging method based on ARINC653, on the one hand, the airborne software runs on the ARINC653 operating system and can access a non-volatile memory, and the storage space of the non-volatile memory is divided into a fault log storage space header, a fault log fixed storage block, and a fault log circular storage block; the fault log storage space header content includes the airborne software name, the fault log fixed storage block size, the fault log circular storage block size, and the circular storage block cursor; when the airborne software fails, the airborne software fault is captured from the ARINC653 operating system interface return code or the callback error handling function return code; according to the log identifier in the fault log, the corresponding fault type and storage location are traversed in the fault log record index; if the fault is an idempotent fault, the fault log is written to the fault log fixed storage block; if the fault is a non-idempotent fault, the fault log is written to the fault log circular storage block. On the other hand, the captured fault can be standardized and formatted and recorded in the non-volatile storage for subsequent reading and analysis.

[0049] In the description of this specification, the reference terms "one embodiment", "some embodiments", "example", "specific example" or "some examples" mean that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present disclosure. In this specification, the schematic expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine different embodiments or examples described in this specification.

[0050] Those skilled in the art will readily appreciate other embodiments of the present disclosure after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present disclosure that follow the general principles of the present disclosure and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered as exemplary only, with the true scope and spirit of the present disclosure being indicated by the appended claims.

Claims

1. A method for recording airborne software fault logs based on ARINC653, characterized in that: The method includes: Step S1, accessing a storage space and initializing a fault log storage space header of the storage space; Step S2, checking whether there is a fault according to the return code of the ARINC653 operating system; Step S3: if there is a fault, construct a single fault log according to the return code; wherein the fault log includes the UTC time when the log occurs, the log identifier and the log message; Step S4, searching the fault log record index for the corresponding fault type and storage location according to the log identifier; wherein the fault type includes an idempotent fault and a non-idempotent fault; Step S5: if the fault is an idempotent fault, the fault log is written into a fault log fixed storage block, and the process returns to step S2; Step S6: If the fault is a non-idempotent fault, the fault log is written into the fault log circular storage block, and the process returns to step S2.

2. The method for recording airborne software fault logs based on ARINC653 according to claim 1, characterized in that: The step S1 comprises: Set the name of the onboard software, the size of the fixed storage block of the fault log, the size of the circular storage block of the fault log, and read the circular storage block cursor.

3. The method for recording airborne software fault logs based on ARINC653 according to claim 2, characterized in that: The size of the fault log storage space header is 16 bytes, the size of the onboard software name is 4 bytes, the size of the fault log fixed storage block is 4 bytes, the size of the fault log circular storage block is 4 bytes, and the size of the circular storage block cursor is 4 bytes.

4. The method for recording airborne software fault logs based on ARINC653 according to claim 2, characterized in that: The step S2 comprises: Obtaining a return code of the ARINC653 operating system, and determining whether the onboard software has a fault according to the value of the return code and a preset fault rule; If there is a failure, the return code is captured.

5. The method for recording airborne software fault logs based on ARINC653 according to claim 4, characterized in that: The return codes include: Interface return code and error handling function return code.

6. The method for recording airborne software fault logs based on ARINC653 according to claim 4, characterized in that: The step S4 comprises: The log identifier searches for the fault type and the storage location of the fault in the corresponding relationship table of all fault types and storage locations in the fault log record index; It is determined according to the fault type whether the fault is the idempotent fault or the non-idempotent fault.

7. The method for recording airborne software fault logs based on ARINC653 according to claim 6, characterized in that: The step S6 comprises: If the fault is a non-idempotent fault, the circular storage block cursor indicates a writable position in the circular storage block, and the fault log is written into the position; then writing the fault log into the corresponding storage address according to the circular storage block cursor; The circular storage block cursor is added with a log length, and the newly added circular storage block cursor is written back to the head of the fault log storage space, and the process returns to step S2.

8. The method for recording airborne software fault logs based on ARINC653 according to claim 7, characterized in that: The fault log in the circular storage block is recorded from the starting position of the circular storage block, and is added every time a fault occurs; when the fault log in the circular storage block is full, the record is overwritten from the starting position of the circular storage block.

9. The method for recording airborne software fault logs based on ARINC653 according to claim 7, characterized in that: After the circular storage block cursor is increased, the circular storage block cursor value in the head of the fault log storage space is written back.

10. The method for recording airborne software fault logs based on ARINC653 according to claim 1, characterized in that: The size of the fault log is 16 bytes; The size of the UTC time of the log occurrence is 8 bytes, the size of the log identifier is 4 bytes, and the size of the log message is 4 bytes.

Images