EP2188725A2 - Method for debugging operational software of a system onboard an aircraft and device for implementing the same - Google Patents

Method for debugging operational software of a system onboard an aircraft and device for implementing the same

Info

Publication number
EP2188725A2
EP2188725A2 EP08837964A EP08837964A EP2188725A2 EP 2188725 A2 EP2188725 A2 EP 2188725A2 EP 08837964 A EP08837964 A EP 08837964A EP 08837964 A EP08837964 A EP 08837964A EP 2188725 A2 EP2188725 A2 EP 2188725A2
Authority
EP
European Patent Office
Prior art keywords
program
execution
error
software
functional
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP08837964A
Other languages
German (de)
French (fr)
Inventor
Famantanantsoa Randimbivololona
Florent Fournier
Philippe Lemeur
Vincent Bregeon
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Airbus Operations SAS
Original Assignee
Airbus Operations SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Airbus Operations SAS filed Critical Airbus Operations SAS
Publication of EP2188725A2 publication Critical patent/EP2188725A2/en
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/3636—Software debugging by tracing the execution of the program

Definitions

  • the present invention belongs to the field of the operational safety of the systems when the operation of these systems depends on the execution, in a computer, of logical instruction sequences.
  • the subject of the invention is a method for debugging operating software of a system that must execute logic instruction sequences, in particular a system having high security requirements such as an electronic system intended to to be on board an aircraft.
  • the method makes it possible for a developer to be able to search for and correct errors in the logic instruction sequences of the embedded systems operating software.
  • the present invention finds particularly advantageous, but not exclusive, applications in the field of aeronautics and, more particularly, in the field of carrying out tests of operating software for systems intended to be embedded.
  • each computer is dedicated to an application or to several applications of the same nature, for example flight control applications.
  • Each calculator includes a hardware part and a software part.
  • the hardware portion comprises at least one central processing unit (CPU) and at least one input / output unit (I / O). which the computer is connected to a network of computers, to external devices, etc.
  • An essential feature of embedded systems often implemented in the aeronautical field is related to an architecture, both hardware and software, which avoids the introduction, as much as possible, of any means not necessary to perform the functions dedicated audits systems.
  • the computer is not equipped with a complex operating system.
  • the software is produced in a language as close as possible to the language understood by the central processing unit and the only available inputs / outputs are those necessary for the operation of the system, for example information from sensors or other elements of the aircraft or information intended for actuators or other elements.
  • the advantage of this type of architecture is that the operation of such a system is much better controlled. It is not dependent on a complex operating system, some aspects of which depend on uncontrolled parameters and should otherwise be subject to the same security proofs as the application software.
  • the system is simpler and less vulnerable because it only includes the means strictly necessary for performing the functions entrusted to said system.
  • the operation of such a system is much more difficult to observe.
  • the system does not have conventional human-machine interfaces, such as keyboards and screens, to check the correct sequence of instructions and to interact with this sequence, which makes it difficult to make the necessary checks during development. , verification and qualification of software.
  • the software part of the computer comprises software specific to the application in question and which ensures the operation of the computer, whose logic instructions correspond to the algorithms that determine the operation of the system.
  • the validation phase consists, in general, in verifying at each stage of the calculator's production process, that it complies with the specifications that have been established for said computer to respond to the expected operation of the system. This conformity to the specifications is realized, in particular for the software, in successive stages since the verification of the simplest components of the software until the complete software integrating all the components to be integrated in the target computer.
  • a first step the simplest software items that can be tested are subjected to tests, called unit tests. During these tests, it is verified that the logical instructions, that is to say the code, of said software elements have been individually taken according to the design requirements.
  • a second step the so-called integration step, various software components, having been individually subjected to an isolated verification, are integrated, to constitute a set in which the software components interact. These different software components are subjected to integration tests to verify that the software components are compatible, in particular at the functional interfaces between said components.
  • a third step all the software components are integrated in the calculator for which they are intended. Validation tests are then carried out to demonstrate that the software, formed by all the components integrated in the computer, complies with the specification, that is to say that it performs the expected functions, and that its operation is reliable and safe.
  • a first known method is to set up a file distribution system between the computer under test with the implanted software and an associated platform, using emulators.
  • An emulator means a device for simulating, on the associated platform, the logical operation of a computing unit, a processor of the computer.
  • the processor of the computer is replaced by a probe that provides the interface with the associated platform carrying the emulation of the processor.
  • test bench is an assembly comprising, in particular, interconnection means with the computer to be tested, means for emulating the processor or processors of the computer as well as for executing test programs.
  • each processor requires a specific emulator, for both the emulation software and the probe connecting instead of the processor, it is necessary to multiply the emulators according to the computer definitions.
  • the possibilities of investigation by means of emulators are generally limited.
  • the need to work with a specific machine language of the considered processor implies that the developer is a specialist in programming in machine language.
  • an emulator is an expensive product that is generally produced in small quantities.
  • the cost is also penalized by the fact that different processor models are generally used to provide functional redundancies for design security, thereby multiplying the need for emulators.
  • a second method which aims to overcome the problems of emulators, is to simulate, on a host platform, the operation of the computer to run the program to be tested.
  • the software under test must access files from the host platform, either to read test vectors or to record test results.
  • system call instructions that are issued by the simulated test environment are generally used.
  • the system call instructions can be, for example, opening a file, writing a file or reading a file.
  • the system call instructions are intercepted by the operating system of the host platform which converts them into system calls of the host platform.
  • This second method also has drawbacks. Indeed, the variety of files is such that the development of access features is very dependent on the host platform and its operating system. However, the variability of host platforms is important both in space (in the case of development teams scattered around the world) and over time (replacement of host platforms), which poses practical implementation difficulties. of the method.
  • this method is very intrusive vis-à-vis the software to be tested and the modification of a software, to perform tests, is a source of risk of disruption of the operation of the software itself.
  • the execution of the tests may reveal errors that manifest themselves either by stopping the running of the operating software or by the fact that one or more test cases have produced errors. wrong results.
  • the developer must then look for anomalies or errors in the lines of instruction codes, in order to be able to correct them.
  • This search is performed by an execution in which the succession of points of the execution path appears in the reverse order of that of a normal execution. In other words, a sequence of code lines is retrieved in which the error is sought (that is, it returns to a sequence of code lines already executed but containing one or more errors) and execute the escalated sequence. This search is called reverse execution.
  • This reverse execution requires that at any point in an execution path of the operating software formed of a succession of instruction code lines, the developer understands the progress of the instruction code lines. However, the developer does not know at which level of the execution path is the error. He does not know how many lines of code the reverse execution should be. In addition, for embedded software, the reverse execution must be in the same language as the normal execution, that is to say in machine language. It is therefore difficult for the developer to sufficiently understand the progress of the program of the operating software to trace the sequence of lines and find the error. In addition, there is no way to control or track the reverse run to allow the developer to know how far he has to go up the faulty chain in order to find the error or anomaly.
  • the present invention aims to overcome the disadvantages of the techniques described above.
  • the invention proposes a debugging method of an operating software allowing a developer to easily find the location of an error or an anomaly in the sequence of instructions written by the developer.
  • the method of the invention proposes to structure the execution of a program of the operating software by means of a functional staking of the execution path. This functional staking is achieved by positioning tags at specific locations of the normal execution path of the program so as to split the program into functional units. which allows the developer to locate the location from which a reverse run must be performed. This staking can be performed interactively or automatically.
  • the subject of the invention is a method of debugging an operating system software program of an embedded system, characterized in that it comprises the following steps: a) tagging the program by positioning tags along the an execution path for splitting said execution path into adjacent functional intervals, b) normal execution of the program, c) capture of a program execution state by beacon status vectors, d) when an error is detected: search for a faulty functional interval according to the state vectors of the tags,
  • the method of the invention may also include one or more of the following features:
  • the operation of refining the functional interval comprises a determination of additional input and output tags and / or intermediate tags.
  • the step of searching for the faulty functional interval is performed automatically.
  • the step of searching for the faulty functional interval is performed interactively by means of a developer's intervention.
  • the invention also relates to a device simulating the operation of an onboard system on board an aircraft, characterized in that it comprises a processor implementing a method as defined above.
  • the device of the invention may comprise the following characteristic:
  • the processor is simulated virtually on a test and debug host platform.
  • the invention also relates to an operating program for an aircraft embedded system, loadable on a control unit comprising instruction sequences for implementing the method as defined above, when the program is loaded on the unit and there is executed.
  • Figure 1 is a schematic representation of the program according to the invention.
  • FIG. 3 is a schematic representation of a test environment during the debugging phase of an operating software of an onboard system.
  • Operating software consists of a set of programs.
  • a program consisting of a set of instructions followed by a string of instructions.
  • the method according to the invention proposes positioning cue points in the execution path of the program of the operating software of the on-board system in order to be able to determine, with respect to these reference points, where the error or the error lies. anomaly.
  • Figure 1 is a schematic representation of the different phases of this method. Each phase of FIG. 1 represents the program of the operating software of the on-board system at a different step from the method of the invention.
  • the first phase of FIG. 1 is an example of the program before application of the method of the invention.
  • This program, referenced 20 comprises a set of instruction strings 20-1 to 20-n. These instruction strings executed in their order of occurrence, i.e., from instruction 20-1 to instruction 20-n, constitute the normal execution path of the program.
  • the second phase of FIG. 1 represents program 21 which corresponds to program 20 after beacons 28 have been positioned.
  • Tags 28 are virtual landmarks positioned at specific locations in the program. These locations preferably correspond to the beginning and / or end of the various functions of the program. Tags 28 are placed, for example, at an entry point or an exit point of a program function. When the beacons are placed at the entrance or exit of each function of the program, it is said that the positioning of the beacons is carried out according to a functional staking.
  • Tags can also be positioned at any other pre-defined location in the execution path, for example, at a point of program failure, at the data stream level, or at the control flow level. Tags are landmarks in the program's execution path. It will be understood, subsequently, that the tags thus constitute restart points for the execution of the program execution path, when one or more anomalies or errors have been encountered, this manifests itself either by erroneous results, or by an interruption of the course of the program, or by an infinite execution loop.
  • An anomaly or an error may be functional.
  • the method sends the developer an invitation to correct said anomaly or said error.
  • the anomaly or the error may also be likely to lead to a loss of control of the program's progress.
  • Such an error may be, for example, an arithmetic overflow of the processor following, for example, the presence of a pointer positioned on a forbidden zone. In this case, the execution of the program is interrupted. An interrupt following an arithmetic overflow is called processor exception interrupt.
  • the functional staking of the execution path proposed in the invention makes it possible to detect and then correct this type of error with interrupt on processor exception.
  • staking according to the invention cuts the execution path of the program into adjacent functional intervals.
  • the functions execute one after the other.
  • a tag is positioned at the beginning of each function.
  • Each tag has a state vector that corresponds to the image of the memory. This state vector indicates the state of the memory at a predefined location, i.e. at the location where the tag is located, which allows, later, to reset the memory With the information of the vector of 'state.
  • the state vector of each of these tags is neutral, or disabled, that is, it contains no information.
  • the tag at the input of the following function changes state by activating.
  • the beacon status vector then captures a program execution state, i.e. it captures the information stored in the system memory at this program execution level.
  • the staking can be performed automatically, that is to say, a tag is automatically positioned at the beginning of each functional interval. It can also be interactive, that is to say that the developer chooses to position additional tags within the same function. These additional tags may be input tags, exit tags and / or intermediate tags.
  • the choice of staking, interactive or automatic, is determined by the developer himself. Interactive staking makes it possible to refine the interval of search and correction of an error, which makes it possible to reduce the interval and thus to facilitate the detection of the error.
  • a third phase of FIG. 1 represents the program 22 corresponding to program 21 during execution of said program in normal mode.
  • This execution in normal mode corresponds to the logical flow of the program, statement by instruction, starting with the first instruction line 20-1.
  • a fourth phase of FIG. 1 represents the program 23 corresponding to the program 21, when the information at the execution state of the program and the position of the beacons have been captured. Indeed, during the normal execution of the program, the beacon at the end of a function performed normally is enabled. The state vector of this tag captures or stores the state of memory at this program run level.
  • the last activated tag indicates the function where a program interruption occurred.
  • the state vector of this tag is used to find the execution state in which the program was at the time when the execution of the failed function began.
  • a normal execution observation tool determines the passages on the beacons, in their normal order of occurrence, that is to say following a normal execution of the lines. instructions of the program.
  • the observation tool captures the state of the memory in the state vector of the last beacon encountered and saves it in a data memory 4.
  • the developer When an error occurs, the developer performs a reverse execution of the program to find the error within the program.
  • the fifth phase of FIG. 1 represents the program 24 corresponding to the program 23 during this reverse execution.
  • This reverse execution makes it possible to trace the program in the opposite direction to the normal running of the program, to resume its execution at the first instruction line of the function corresponding to the last activated beacon, that is to say the last function whose state vector has been captured.
  • the reverse execution is conducted by following the tags to go up the program's instruction string and determine the location of the faulty instruction string.
  • the reverse execution can thus be performed within a single functional interval.
  • the developer looks for the error or anomaly in this string and then corrects it.
  • the developer is able to easily locate the faulty instruction string.
  • the developer can continue the reverse run to detect any other errors.
  • the execution path is structured in such a way that several errors or anomalies can be detected and corrected in a single debugging phase of the program.
  • the debugging phase which has just been described, that is to say the search and correction phase of an error, is represented by the program 25 in FIG.
  • program 26 includes interactive staking whereby the developer can jump from one functional interval to another.
  • Figure 2 illustrates in detail the different steps of the method of the invention.
  • the block diagram of Fig. 2 shows a preliminary step in which a control unit of the test environment detects whether a debug phase has been requested by the developer.
  • control unit of the test environment performs, in step 31, a program markup by positioning tags along the execution path to split said execution path into adjacent functional intervals.
  • Each tag has a state vector enabled or disabled, as explained above.
  • the state vector of a tag is said to be activated when the information relating to the execution state of the program has been captured.
  • a beacon state vector is activated when the function preceding the beacon has been executed without error. It remains disabled otherwise.
  • step 32 the control unit starts the normal execution of the program.
  • step 33 the control unit captures the state information in the tag state vectors to determine the program execution state.
  • step 34 the control unit detects whether there is an interruption in program execution of the operating software. If the program stops, it means that an error or anomaly has been detected. Step 35 is then applied. If no interruption occurs, normal execution continues and steps 32 and 33 are repeated.
  • step 35 it is determined whether the interruption occurred on a processor exception. If this is the case, then step 36 is applied. Otherwise, step 37 is applied. In this case, a message is transmitted to developer to mean that the execution of the program ends, either because a functional error has been detected, or because the normal execution has ended without error.
  • control unit stores the position of the tags in a test results file, to allow a subsequent consultation of the execution path.
  • step 44 the test results file is closed.
  • step 45 is a final step indicating the end of the test or the execution of the program. If a processor exception has been detected in step 35, then, in step 36, the first deactivated tag is searched in the normal path in order to deduce the functional interval where the faulty string is located. Step 38 is then applied. At step 38, the developer may interactively implement additional input tags, additional output tags, and / or intermediate tags to refine the search interval of the tag. error in the functional interval determined in step 36. In step 39, points of failure are detected in the data streams or control flows. These points of failure make it possible to further refine the interval around the error. After determining these points of failure, a faulty interval around the error is defined in step 40.
  • steps 38 to 40 constitute a preferred embodiment of the invention in which the interval around the error is reduced in order to facilitate the search for the error during the reverse execution.
  • the method may provide to simply go from step 36 of detection of the idle tag to the step 41 of reverse execution. In this case, the developer must perform reverse execution on the entire function in which the error was detected.
  • step 41 the reverse execution is started, making it possible to go back to the function where the faulty instruction string of the program has been detected.
  • the reverse execution is done between two successive tags (interval). This corresponds in the most common case at the beginning and at the end of the faulty function. We can of course jump from one interval to another without any particular constraint.
  • the reverse execution is performed on a refined interval around the error, that is to say on only part of the function.
  • step 42 the developer performs the debugging of the error that is to say that it determines the error in the faulty functional interval and corrects it.
  • the method is reiterated in step 31 to verify that the program is executing correctly.
  • control unit When the control unit no longer detects a processor exception interrupt, then the control unit sends the developer a message indicating that the debug phase of the program is complete (step 37).
  • the method according to the invention can be implemented in a test environment of the simulated system virtually on a host platform. It can also be installed on a workstation connected to a real embedded system via a dedicated operating emulator.
  • the position of the tags and / or the state vectors are recorded (step 43) on a support accessible to the developer, for example, in a results file of the host platform.
  • the result file is closed (step 44) and the test is completed (step 45).
  • a check of all the results is performed (step 46). When all the results are good, or ok, we come to an end step 47 indicating that all these results are ok. If all the results are not ok, steps 36 to 42 are repeated.
  • FIG. 3 shows an example of a control unit 1 of the test environment of the operating program of the onboard system, implementing the method according to the invention.
  • the control unit 1 comprises a processor 2, a program memory 3, a data memory 4, and an input / output interface 5.
  • the processor 2, the program memory 3, the data memory 4, and the input / output interface 5 are connected to each other by a bidirectional communication bus 6.
  • a program 7 is executed by the processor 2, using instruction code chains implanted in the program memory 3.
  • the role of the program 7 is to control and control the operation of the onboard system.
  • the program 7 comprises, in a non-exhaustive manner, an interrupt manager 8, a library 9, a scheduler 10, and a set of applications 11.
  • the library 9 comprises a collection of control functions activated by the program 7.
  • the role of the interrupt manager 8 is to react in real time to unexpected requests from the processor 2 but also to ensure the multitasking coexistence of the environment. test.
  • the scheduler 10 is a service program for automatically determining an order of priority in the processing of the tasks that the processor 2 must perform, according to various priority criteria and according to the available resources.
  • the program memory 3 comprises, in a zone 12, the instructions for constructing a functional staking of the program 7 as described above and for indicating the position of the error or anomaly encountered in order to correct it.
  • the program memory 3 comprises, in a zone 13, instructions for capturing the beacon status vectors in the program 7. The position of each activated beacon as well as its status vector are recorded in the data memory 4.
  • the program memory 3 comprises, in a zone 14, instructions for starting the normal execution of the program 7.
  • the execution of the program 7 of the operating software proceeds sequentially, instruction by instruction, and gradually causes the activation of the vectors of the program. state of the tags.
  • Tag state vectors that are after the function where the error is located are not enabled.
  • the state vector of the last activated tag then constitutes a marker that indicates the faulty function, that is to say the function containing the error.
  • the program memory 3 comprises, in a zone 15, instructions for initiating a reverse execution.
  • the reverse execution allows, when an error has been detected, to go up to the function containing the faulty instruction.
  • the developer is placed on the tag associated with the last state vector activated to restart the execution of the function. Thus, the developer performs only reverse execution on the failing function.
  • the program memory 3 comprises, in a zone 16, instructions making it possible to exploit the information collected by through the tags. These instructions allow debugging of program 7.
  • the program memory 3 comprises, in a zone 17, instructions for performing functional interval jumps.
  • the instruction codes of the zone 17 make it possible to jump from one functional interval to another, whether the progress of the program 7 is in normal execution or in reverse execution.
  • the functional staking of the invention enables efficient software debugging as it provides a means of locating faulty instruction strings to limit reverse execution to single function instructions. In addition, it can correct multiple errors in a single debugging phase.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)

Abstract

The invention relates to a method for debugging the program of operational software of an onboard system, characterised in that it comprises the following steps: a) flagging (31) the program by positioning flags along an execution path for dividing said execution path into adjacent functional intervals; b) normal execution (32) of the program; c) acquiring (33) an execution condition of the program by flag condition vectors; d) when an error is detected, searching (36) a faulty functional interval based on the flag condition vectors, reverse execution (41) of the program in said faulty functional interval, and determination and correction of the error (42).

Description

Procédé de débogage d'un logiciel de fonctionnement d'un système embarqué à bord d'un aéronef et dispositif de mise en œuvre Method of debugging an operating software of an onboard system on board an aircraft and device for implementing it
La présente invention appartient au domaine de la sécurité de fonctionnement des systèmes lorsque le fonctionnement de ces systèmes dépend de l'exécution, dans un calculateur, de suites d'instructions logiques.The present invention belongs to the field of the operational safety of the systems when the operation of these systems depends on the execution, in a computer, of logical instruction sequences.
En particulier, l'invention a pour objet un procédé de débogage d'un logiciel de fonctionnement d'un système devant exécuter des suites d'instructions logiques, notamment d'un système ayant des exigences de sécurité élevées tel qu'un système électronique destiné à être embarqué à bord d'un aéronef.In particular, the subject of the invention is a method for debugging operating software of a system that must execute logic instruction sequences, in particular a system having high security requirements such as an electronic system intended to to be on board an aircraft.
Le procédé permet, à un développeur, de pouvoir rechercher et corriger des erreurs dans les suites d'instructions logiques des logiciels de fonctionnement de systèmes embarqués. La présente invention trouve des applications particulièrement avantageuses, mais non exclusives, dans le domaine de l'aéronautique et, plus particulièrement, dans le domaine de la réalisation de tests de logiciels de fonctionnement de systèmes destinés à être embarqués.The method makes it possible for a developer to be able to search for and correct errors in the logic instruction sequences of the embedded systems operating software. The present invention finds particularly advantageous, but not exclusive, applications in the field of aeronautics and, more particularly, in the field of carrying out tests of operating software for systems intended to be embedded.
Pour des raisons de sécurité, les systèmes destinés à être embarqués à bord d'un aéronef sont soumis à des vérifications de bon fonctionnement au cours desquels il doit être démontré que lesdits systèmes répondent à des exigences de certification, avant qu'un aéronef équipé de tels systèmes soit autorisé à voler et, plus encore, à entrer en service commercial.For safety reasons, systems intended to be carried on board an aircraft shall be subjected to functional checks during which it shall be demonstrated that the systems meet certification requirements, before an aircraft equipped with such systems be allowed to fly and, even more, to enter commercial service.
Avant leur implantation, ces systèmes subissent de nombreux tests pour vérifier qu'ils répondent aux exigences d'intégrité et de sécurité, entre autre, émises par les autorités de certification. Ces systèmes embarqués peuvent être, notamment, des calculateurs spécialisés destinés à réaliser des fonctions pouvant être importantes pour l'aéronef, par exemples des fonctions de pilotage. Ces systèmes seront appelés par la suite calculateurs. Le plus souvent, dans les architectures des systèmes actuels, chaque calculateur est dédié à une application ou à plusieurs applications de même nature, par exemple des applications de commande de vol. Chaque calculateur comprend une partie matérielle et une partie logicielle. La partie matérielle comporte au moins une unité de traitement central (CPU: Central Processing Unit en anglais) et au moins une unité d'entrées/sorties par laquelle le calculateur est connecté à un réseau de calculateurs, à des périphériques externes, etc ..Before their implementation, these systems undergo numerous tests to check that they meet the requirements of integrity and safety, among others, issued by the certification authorities. These embedded systems may be, in particular, specialized computers for performing functions that may be important for the aircraft, for example driving functions. These systems will be called later calculators. Most often, in the architectures of the current systems, each computer is dedicated to an application or to several applications of the same nature, for example flight control applications. Each calculator includes a hardware part and a software part. The hardware portion comprises at least one central processing unit (CPU) and at least one input / output unit (I / O). which the computer is connected to a network of computers, to external devices, etc.
Une caractéristique essentielle des systèmes embarqués souvent mis en œuvre dans le domaine aéronautique est liée à une architecture, tant matérielle que logicielle, qui évite l'introduction, autant que possible, de tout moyen non nécessaire pour exécuter les fonctions dédiées audits systèmes.An essential feature of embedded systems often implemented in the aeronautical field is related to an architecture, both hardware and software, which avoids the introduction, as much as possible, of any means not necessary to perform the functions dedicated audits systems.
Ainsi, contrairement aux systèmes généralement rencontrés dans des applications répandues, en aéronautique, le calculateur n'est pas pourvu d'un système d'exploitation complexe. De plus, le logiciel est réalisé dans un langage aussi proche que possible du langage compris par l'unité de traitement central et les seules entrées/sorties disponibles sont celles nécessaires au fonctionnement du système, par exemple des informations provenant de capteurs ou d'autres éléments de l'aéronef ou des informations à destination d'actionneurs ou d'autres éléments. L'avantage de ce type d'architecture tient au fait que le fonctionnement d'un tel système est beaucoup mieux maîtrisé. Il n'est pas dépendant d'un système d'exploitation complexe dont certains aspects du fonctionnement sont fonction de paramètres non maîtrisés et qui devrait, sinon, faire l'objet des mêmes démonstrations de sécurité que les logiciels d'application. Le système est plus simple et moins vulnérable car il ne comporte que les moyens strictement nécessaires à l'exécution des fonctions confiées audit système.Thus, unlike the systems generally encountered in widespread applications, in aeronautics, the computer is not equipped with a complex operating system. In addition, the software is produced in a language as close as possible to the language understood by the central processing unit and the only available inputs / outputs are those necessary for the operation of the system, for example information from sensors or other elements of the aircraft or information intended for actuators or other elements. The advantage of this type of architecture is that the operation of such a system is much better controlled. It is not dependent on a complex operating system, some aspects of which depend on uncontrolled parameters and should otherwise be subject to the same security proofs as the application software. The system is simpler and less vulnerable because it only includes the means strictly necessary for performing the functions entrusted to said system.
En contrepartie, le fonctionnement d'un tel système est beaucoup plus difficile à observer. Par exemple, le système ne dispose pas des interfaces homme/machine conventionnelles, comme les claviers et écrans, permettant de vérifier le déroulement correct des suites d'instructions et d'interagir sur ce déroulement, ce qui rend difficile les vérifications indispensables pendant le développement, la vérification et la qualification des logiciels.In return, the operation of such a system is much more difficult to observe. For example, the system does not have conventional human-machine interfaces, such as keyboards and screens, to check the correct sequence of instructions and to interact with this sequence, which makes it difficult to make the necessary checks during development. , verification and qualification of software.
La partie logicielle du calculateur comprend un logiciel spécifique à l'application considérée et qui assure le fonctionnement du calculateur, dont les instructions logiques correspondent aux algorithmes qui déterminent le fonctionnement du système.The software part of the computer comprises software specific to the application in question and which ensures the operation of the computer, whose logic instructions correspond to the algorithms that determine the operation of the system.
Pour obtenir la certification du système, préalable à sa mise en service et à celle de l'aéronef, une phase de validation du calculateur est effectuée. De façon connue, la phase de validation consiste, en général, à vérifier à chaque étape du processus de réalisation du calculateur, que celui- ci est conforme aux spécifications qui ont été établies pour que ledit calculateur réponde au fonctionnement attendu du système. Cette conformité aux spécifications est réalisée, en particulier pour les logiciels, par étapes successives depuis la vérification des composants les plus simples du logiciel jusqu'au logiciel complet intégrant tous les composants devant être intégrés dans le calculateur cible.To obtain the certification of the system, prior to its commissioning and that of the aircraft, a validation phase of the computer is performed. In a known manner, the validation phase consists, in general, in verifying at each stage of the calculator's production process, that it complies with the specifications that have been established for said computer to respond to the expected operation of the system. This conformity to the specifications is realized, in particular for the software, in successive stages since the verification of the simplest components of the software until the complete software integrating all the components to be integrated in the target computer.
Dans une première étape, les éléments de logiciel les plus simples pouvant être testés sont soumis à des tests, dits tests unitaires. Au cours de ces tests, il est vérifié que les instructions logiques, c'est-à-dire le code, desdits éléments de logiciel ont été, pris individuellement, réalisés conformément aux exigences de conception.In a first step, the simplest software items that can be tested are subjected to tests, called unit tests. During these tests, it is verified that the logical instructions, that is to say the code, of said software elements have been individually taken according to the design requirements.
Dans une deuxième étape, dite étape d'intégration, différents composants logiciels, ayant été soumis individuellement à une vérification isolée, sont intégrés, pour constituer un ensemble dans lequel les composants logiciels interagissent. Ces différents composants logiciels sont soumis à des tests d'intégration destinés à vérifier que les composants logiciels sont compatibles, en particulier au niveau des interfaces fonctionnelles entre lesdits composants.In a second step, the so-called integration step, various software components, having been individually subjected to an isolated verification, are integrated, to constitute a set in which the software components interact. These different software components are subjected to integration tests to verify that the software components are compatible, in particular at the functional interfaces between said components.
Dans une troisième étape, l'ensemble des composants logiciels est intégré dans le calculateur auquel ils sont destinés. Des essais de validation sont alors réalisés pour démontrer que le logiciel, formé par l'ensemble des composants intégrés dans le calculateur, est conforme à la spécification, c'est-à-dire qu'il réalise les fonctions attendues, et que son fonctionnement est fiable et sûr.In a third step, all the software components are integrated in the calculator for which they are intended. Validation tests are then carried out to demonstrate that the software, formed by all the components integrated in the computer, complies with the specification, that is to say that it performs the expected functions, and that its operation is reliable and safe.
Pour garantir qu'un logiciel est sûr, et pour satisfaire aux exigences de certification, il est également nécessaire, au cours de cette phase de validation, de démontrer que l'ensemble des tests auxquels le logiciel a été soumis permet de conclure, avec un niveau de probabilité adéquat, que le logiciel est conforme aux exigences de sûreté requises du système où il est incorporé.To ensure that software is safe, and to meet the certification requirements, it is also necessary, during this validation phase, to demonstrate that all the tests to which the software has been submitted make it possible to conclude, with a adequate level of probability that the software meets the security requirements of the system in which it is incorporated.
Les différents tests effectués, pendant la phase de validation, sur le logiciel, permettent de s'assurer qu'aucun dysfonctionnement dudit logiciel (qui pourrait avoir un impact sur le bon fonctionnement des calculateurs, et par suite sur l'aéronef et sa sécurité) ne peut se produire ou que, si un dysfonctionnement se produit, le logiciel est apte à le maîtriser.The various tests performed, during the validation phase, on the software, make it possible to ensure that no malfunction of said software (which could have an impact on the proper functioning of the computers, and consequently on the aircraft and its security) can not occur or that, if a malfunction occurs, the software is able to control it.
Toutefois, pendant la phase de validation, et surtout pour les opérations d'investigation lorsque des anomalies sont constatées, il est souvent nécessaire de s'assurer que, non seulement, les paramètres d'entrée et de sortie du calculateur sur lequel est implanté le logiciel sont conformes aux attentes mais, également, que certains comportements internes du logiciel sont corrects.However, during the validation phase, and especially for the investigation operations when anomalies are found, it is often necessary to ensure that, not only the input and output parameters of the computer on which the computer is installed, software are in line with expectations but, also, that some internal behaviors of the software are correct.
Dans ce cas, en raison de l'architecture spécifique des calculateurs spécialisés pour les applications embarquées, il est généralement très difficile d'observer le fonctionnement du logiciel sans mettre en œuvre des dispositifs et des méthodes particulières.In this case, because of the specific architecture of specialized computers for embedded applications, it is generally very difficult to observe the operation of the software without implementing particular devices and methods.
Une première méthode connue consiste à mettre en place un système de distribution de fichiers entre le calculateur en test avec le logiciel implanté et une plate-forme associée, en utilisant des émulateurs. On entend, par émulateur, un dispositif permettant de simuler, sur la plate-forme associée, le fonctionnement logique d'une unité de calcul, d'un processeur du calculateur.A first known method is to set up a file distribution system between the computer under test with the implanted software and an associated platform, using emulators. An emulator means a device for simulating, on the associated platform, the logical operation of a computing unit, a processor of the computer.
Dans un tel mode de fonctionnement avec un émulateur, le processeur du calculateur est remplacé par une sonde qui assure l'interface avec la plate-forme associée portant l'émulation du processeur.In such an operating mode with an emulator, the processor of the computer is replaced by a probe that provides the interface with the associated platform carrying the emulation of the processor.
Ainsi, il est possible de faire exécuter le logiciel à tester sur le calculateur, sauf pour la partie processeur et, par des fonctions propres de la plate-forme associée, d'observer le fonctionnement ou certains dysfonctionnements internes du logiciel, par exemple, en réponse à des stimulations des entrées des unités d'entrée/sortie, en plus de l'observation des sorties desdites unités d'entrée/sortie.Thus, it is possible to run the software to be tested on the computer, except for the processor part and, by the proper functions of the associated platform, to observe the operation or certain internal malfunctions of the software, for example, in responding to input / output unit input stimulations, in addition to observing the outputs of said input / output units.
Cette première méthode présente de nombreux inconvénients. En effet, chaque type de calculateur à tester nécessite un banc de tests spécifique ou pour le moins une configuration très spécialisée d'un banc de test. Un banc de tests est un ensemble comportant, en particulier, des moyens d'interconnexion avec le calculateur à tester, des moyens pour émuler le ou les processeurs du calculateur ainsi que pour exécuter des programmes de tests. Comme chaque processeur nécessite un émulateur spécifique, tant pour le logiciel d'émulation que pour la sonde se raccordant à la place du processeur, il est nécessaire de multiplier les émulateurs conformément aux définitions des calculateurs. Par ailleurs, les possibilités d'investigation au moyen des émulateurs sont en général limitées. De plus, la nécessité de travailler avec un langage machine spécifique du processeur considéré implique que le développeur soit un spécialiste de la programmation en langage machine. En outre, un émulateur est un produit coûteux qui n'est généralement produit qu'en faible quantité. Le cycle de vie de ce type de produit est très court (6 mois à 2 ans) alors que le maintien en condition opérationnelle des moyens de développement et de vérification est exigible (réglementations, réactivité industrielle) pour la durée du programme avion (20 ans, voire plus). Cela se traduit par des problèmes de traitement d'obsolescence de plus en plus difficiles à résoudre.This first method has many disadvantages. Indeed, each type of computer to be tested requires a specific test bench or at least a very specialized configuration of a test bench. A test bench is an assembly comprising, in particular, interconnection means with the computer to be tested, means for emulating the processor or processors of the computer as well as for executing test programs. As each processor requires a specific emulator, for both the emulation software and the probe connecting instead of the processor, it is necessary to multiply the emulators according to the computer definitions. In addition, the possibilities of investigation by means of emulators are generally limited. In addition, the need to work with a specific machine language of the considered processor implies that the developer is a specialist in programming in machine language. In addition, an emulator is an expensive product that is generally produced in small quantities. The life cycle of this type of product is very short (6 months to 2 years) while the maintenance in operational condition of the means of development and verification is required (regulations, industrial reactivity) for the duration of the aircraft program (20 years , see more). This results in obsolescence processing problems becoming more difficult to solve.
Cette solution de l'émulateur s'avère donc mal adaptée car, outre ses performances limitées en termes d'investigation, elle est coûteuse à mettre en place et coûteuse à entretenir.This solution of the emulator is therefore poorly adapted because, in addition to its limited performance in terms of investigation, it is expensive to implement and expensive to maintain.
Le coût se trouve également pénalisé par le fait que différents modèles de processeurs sont en général utilisés pour assurer des redondances fonctionnelles par sécurité de conception, multipliant d'autant les besoins en émulateurs.The cost is also penalized by the fact that different processor models are generally used to provide functional redundancies for design security, thereby multiplying the need for emulators.
Une deuxième méthode, qui vise à s'affranchir des problèmes des émulateurs, consiste à simuler, sur une plate-forme hôte, le fonctionnement du calculateur devant exécuter le programme à tester. Dans ce cas, les logiciels sous test doivent accéder à des fichiers de la plate-forme hôte, soit pour lire les vecteurs de tests, soit pour enregistrer des résultats de tests.A second method, which aims to overcome the problems of emulators, is to simulate, on a host platform, the operation of the computer to run the program to be tested. In this case, the software under test must access files from the host platform, either to read test vectors or to record test results.
Comme le logiciel à tester ne comporte pas naturellement les fonctions pour de tels accès au système de fichiers de la plate-forme hôte, il est nécessaire de modifier le logiciel à tester pour intégrer ces fonctions d'accès.Since the software to be tested does not naturally include the functions for such accesses to the file system of the host platform, it is necessary to modify the software to be tested to integrate these access functions.
Pour transférer les informations, on utilise généralement des instructions d'appels système qui sont émises par l'environnement de test simulé. Les instructions d'appels système peuvent être, par exemple, l'ouverture d'un fichier, l'écriture d'un fichier ou encore la lecture d'un fichier. Les instructions d'appels système sont interceptées par le système d'exploitation de la plate-forme hôte qui les convertit en appels système de la plate-forme hôte.To transfer the information, system call instructions that are issued by the simulated test environment are generally used. The system call instructions can be, for example, opening a file, writing a file or reading a file. The system call instructions are intercepted by the operating system of the host platform which converts them into system calls of the host platform.
Cette deuxième méthode présente également des inconvénients. En effet, la variété des fichiers est telle que le développement des fonctionnalités d'accès est très dépendant de la plate-forme hôte et de son système d'exploitation. Or, la variabilité des plates-formes hôtes est importante tant dans l'espace (cas des équipes de développement dispersées dans le monde) que dans le temps (remplacement des plates- formes hôtes), ce qui pose des difficultés pratiques de mise en œuvre de la méthode.This second method also has drawbacks. Indeed, the variety of files is such that the development of access features is very dependent on the host platform and its operating system. However, the variability of host platforms is important both in space (in the case of development teams scattered around the world) and over time (replacement of host platforms), which poses practical implementation difficulties. of the method.
Ces difficultés sont accentuées par le fait que des compétences d'experts capables de modifier des fonctions du système d'exploitation sont requises pour le développement de telles fonctionnalités d'accès aux systèmes de fichiers et ne peuvent donc pas être confiées à des spécialistes des essais.These difficulties are compounded by the fact that expert skills capable of modifying operating system functions are required for the development of such file system access features and therefore can not be entrusted to trial specialists .
En conséquence, cette méthode s'avère coûteuse et difficile à mettre en œuvre.As a result, this method is expensive and difficult to implement.
En outre cette méthode est très intrusive vis-à-vis du logiciel à tester et la modification d'un logiciel, pour en réaliser des tests, est une source de risque de perturbation du fonctionnement du logiciel lui-même.In addition, this method is very intrusive vis-à-vis the software to be tested and the modification of a software, to perform tests, is a source of risk of disruption of the operation of the software itself.
Pendant la phase de validation et de vérification du logiciel du calculateur, l'exécution des tests peut révéler des erreurs qui se manifestent soit par un arrêt du déroulement du logiciel de fonctionnement, soit par le fait que un ou plusieurs cas de test ont produit des résultats erronés. Le développeur doit alors rechercher des anomalies ou des erreurs dans les lignes de codes instructions, afin de pouvoir les corriger. Cette recherche est effectuée par une exécution dans laquelle la succession des points du chemin d'exécution apparaît dans l'ordre inverse de celle d'une exécution normale. Autrement dit, on remonte une séquence de lignes de codes dans laquelle on recherche l'erreur (c'est-à-dire qu'on retourne dans une séquence de lignes de codes déjà exécutée mais contenant une ou plusieurs erreurs) et on ré-exécute la séquence remontée. Cette recherche est appelée exécution reverse. Cette exécution reverse exige, qu'en tout point d'un chemin d'exécution du logiciel de fonctionnement formé d'une succession de lignes de codes instructions, le développeur comprenne le déroulement des lignes de codes instructions. Or, le développeur ne sait pas à quel niveau du chemin d'exécution se situe l'erreur. Il ne sait donc pas sur combien de lignes de codes l'exécution reverse doit s'effectuer. De plus, pour les logiciels embarqués, l'exécution reverse doit se faire dans le même langage que l'exécution normale, c'est-à-dire en langage machine. Il est donc difficile, pour le développeur, de comprendre suffisamment le déroulement du programme du logiciel de fonctionnement pour remonter la séquence de lignes et retrouver l'erreur. En outre, il n'y a aucun moyen de contrôle ou de suivi de l'exécution reverse pour permettre au développeur de savoir jusqu'où il doit remonter la chaîne défaillante afin de trouver l'erreur ou l'anomalie. Compte tenu de sa complexité, cette recherche d'erreur nécessite un temps considérable pouvant aller de quelques heures à plusieurs jours, ce qui entraîne un coût relativement élevé de la phase de débogage, en terme de productivité et de main d'œuvre. Cela est dû au fait que les outils de débogage actuels n'offre aucun moyen pour supporter efficacement l'exécution reverse : il s'agit de revenir soit de n unités de temps (généralement la seconde), soit de n pas de calcul. Il n'y a aucun lien fonctionnel avec la logique du logiciel à déboguer. L'efficacité de l'exécution reverse en est considérablement amoindrie, voire complètement annihilée s'il s'agit d'un logiciel à logique complexe comme c'est généralement le cas pour le logiciel embarqué.During the validation and verification phase of the computer software, the execution of the tests may reveal errors that manifest themselves either by stopping the running of the operating software or by the fact that one or more test cases have produced errors. wrong results. The developer must then look for anomalies or errors in the lines of instruction codes, in order to be able to correct them. This search is performed by an execution in which the succession of points of the execution path appears in the reverse order of that of a normal execution. In other words, a sequence of code lines is retrieved in which the error is sought (that is, it returns to a sequence of code lines already executed but containing one or more errors) and execute the escalated sequence. This search is called reverse execution. This reverse execution requires that at any point in an execution path of the operating software formed of a succession of instruction code lines, the developer understands the progress of the instruction code lines. However, the developer does not know at which level of the execution path is the error. He does not know how many lines of code the reverse execution should be. In addition, for embedded software, the reverse execution must be in the same language as the normal execution, that is to say in machine language. It is therefore difficult for the developer to sufficiently understand the progress of the program of the operating software to trace the sequence of lines and find the error. In addition, there is no way to control or track the reverse run to allow the developer to know how far he has to go up the faulty chain in order to find the error or anomaly. Given its complexity, this search for error requires a considerable time that can go from a few hours to several days, resulting in a relatively high cost of the debugging phase, in terms of productivity and labor. This is due to the fact that the current debugging tools do not offer any means to effectively support the reverse execution: it is a question of returning either n time units (generally the second) or n no computation. There is no functional link with the logic of the software to debug. The efficiency of the reverse execution is considerably diminished, or even completely annihilated if it is a complex logic software as is generally the case for the embedded software.
La présente invention a pour but de remédier aux inconvénients des techniques exposées précédemment. A cette fin, l'invention propose un procédé de débogage d'un logiciel de fonctionnement permettant à un développeur de retrouver facilement l'emplacement d'une erreur ou d'une anomalie dans la suite d'instruction écrite par le développeur. Pour cela, le procédé de l'invention propose de structurer l'exécution d'un programme du logiciel de fonctionnement au moyen d'un jalonnement fonctionnel du chemin d'exécution. Ce jalonnement fonctionnel est réalisé en positionnant des balises à des emplacements spécifiques du chemin d'exécution normal du programme de façon à découper le programme en unités fonctionnelles, ce qui permet au développeur de repérer l'emplacement à partir duquel une exécution reverse doit être effectuée. Ce jalonnement peut être effectué de manière interactive ou automatique.The present invention aims to overcome the disadvantages of the techniques described above. To this end, the invention proposes a debugging method of an operating software allowing a developer to easily find the location of an error or an anomaly in the sequence of instructions written by the developer. For this, the method of the invention proposes to structure the execution of a program of the operating software by means of a functional staking of the execution path. This functional staking is achieved by positioning tags at specific locations of the normal execution path of the program so as to split the program into functional units. which allows the developer to locate the location from which a reverse run must be performed. This staking can be performed interactively or automatically.
Plus précisément, l'invention a pour objet un procédé de débogage d'un programme de logiciel de fonctionnement d'un système embarqué, caractérisé en ce qu'il comporte les étapes suivantes : a) balisage du programme en positionnant des balises le long d'un chemin d'exécution pour découper ledit chemin d'exécution en intervalles fonctionnels adjacents, b) exécution normale du programme, c) capture d'un état d'exécution du programme par des vecteurs d'état des balises, d) lorsqu'une erreur est détectée : recherche d'un intervalle fonctionnel défaillant en fonction des vecteurs d'état des balises,More specifically, the subject of the invention is a method of debugging an operating system software program of an embedded system, characterized in that it comprises the following steps: a) tagging the program by positioning tags along the an execution path for splitting said execution path into adjacent functional intervals, b) normal execution of the program, c) capture of a program execution state by beacon status vectors, d) when an error is detected: search for a faulty functional interval according to the state vectors of the tags,
- exécution reverse du programme dans cet intervalle fonctionnel défaillant,- reverse execution of the program in this faulty functional interval,
- détermination et correction de l'erreur.- determination and correction of the error.
Le procédé de l'invention peut comporter également une ou plusieurs des caractéristiques suivantes :The method of the invention may also include one or more of the following features:
- une erreur est détectée lorsqu'un arrêt du programme a été détecté, suite à une exception processeur.- an error is detected when a program shutdown has been detected, following a processor exception.
- il comporte une opération d'affinage de l'intervalle fonctionnel dans lequel se trouve l'erreur. - l'opération d'affinage de l'intervalle fonctionnel comporte une détermination de balises supplémentaires d'entrée et de sortie et/ou de balises intermédiaires.it comprises a refining operation of the functional interval in which the error is located. the operation of refining the functional interval comprises a determination of additional input and output tags and / or intermediate tags.
- l'étape de recherche de l'intervalle fonctionnel défaillant est effectuée de manière automatique. - l'étape de recherche de l'intervalle fonctionnel défaillant est effectuée de manière interactive par intervention d'un développeur.the step of searching for the faulty functional interval is performed automatically. the step of searching for the faulty functional interval is performed interactively by means of a developer's intervention.
- il comporte une étape d'enregistrement de la position de chaque balise et des informations sur l'état d'exécution du programme, dans un fichier de résultats d'une plate-forme hôte. L'invention concerne également un dispositif simulant le fonctionnement d'un système embarqué à bord d'un aéronef, caractérisé en ce qu'il comporte un processeur mettant en œuvre un procédé tel que définit précédemment. Le dispositif de l'invention peut comporter la caractéristique suivante :it comprises a step of recording the position of each beacon and information on the state of execution of the program, in a results file of a host platform. The invention also relates to a device simulating the operation of an onboard system on board an aircraft, characterized in that it comprises a processor implementing a method as defined above. The device of the invention may comprise the following characteristic:
- le processeur est simulé virtuellement sur une plate-forme hôte de test et de débogage.the processor is simulated virtually on a test and debug host platform.
L'invention a également pour objet un programme de fonctionnement pour système embarqué pour aéronef, chargeable sur une unité de commande comprenant des séquences d'instructions pour mettre en œuvre le procédé tel que définit précédemment, lorsque le programme est chargé sur l'unité et y est exécuté.The invention also relates to an operating program for an aircraft embedded system, loadable on a control unit comprising instruction sequences for implementing the method as defined above, when the program is loaded on the unit and there is executed.
L'invention sera mieux comprise à la lecture de la description qui suit et à l'examen des figures qui l'accompagnent. Celles-ci sont présentées à titre indicatif et nullement limitatif de l'invention.The invention will be better understood on reading the description which follows and on examining the figures which accompany it. These are presented as an indication and in no way limitative of the invention.
La figure 1 est une représentation schématique du programme selon l'invention.Figure 1 is a schematic representation of the program according to the invention.
La figure 2 illustre un diagramme fonctionnel du procédé de l'invention. La figure 3 est une représentation schématique d'un environnement de test en phase de débogage d'un logiciel de fonctionnement d'un système embarqué.Figure 2 illustrates a functional diagram of the method of the invention. FIG. 3 is a schematic representation of a test environment during the debugging phase of an operating software of an onboard system.
Un logiciel de fonctionnement est constitué d'un ensemble de programmes. Un programme étant constitué d'un ensemble de suite d'instructions écrites appelé par la suite chaîne d'instructions. Le procédé selon l'invention propose de positionner des points de repère dans le chemin d'exécution du programme du logiciel de fonctionnement du système embarqué afin de pouvoir déterminer, par rapport à ces points de repère, où se situe l'erreur ou l'anomalie. La figure 1 est une représentation schématique des différentes phases de ce procédé. Chaque phase de la figure 1 représente le programme du logiciel de fonctionnement du système embarqué à une étape différente du procédé de l'invention. La première phase de la figure 1 est un exemple du programme avant application du procédé de l'invention. Ce programme, référencé 20, comprend un ensemble de chaînes d'instructions 20-1 à 20-n. Ces chaînes d'instructions exécutées dans leur ordre d'occurrence, c'est-à- dire de l'instruction 20-1 à l'instruction 20-n, constituent le chemin d'exécution normal du programme.Operating software consists of a set of programs. A program consisting of a set of instructions followed by a string of instructions. The method according to the invention proposes positioning cue points in the execution path of the program of the operating software of the on-board system in order to be able to determine, with respect to these reference points, where the error or the error lies. anomaly. Figure 1 is a schematic representation of the different phases of this method. Each phase of FIG. 1 represents the program of the operating software of the on-board system at a different step from the method of the invention. The first phase of FIG. 1 is an example of the program before application of the method of the invention. This program, referenced 20, comprises a set of instruction strings 20-1 to 20-n. These instruction strings executed in their order of occurrence, i.e., from instruction 20-1 to instruction 20-n, constitute the normal execution path of the program.
La deuxième phase de la figure 1 représente le programme 21 qui correspond au programme 20 après que des balises 28 aient été positionnées. Les balises 28 sont des repères virtuels positionnés à des emplacements spécifiques du programme. Ces emplacements correspondent, de préférence, au début et/ou à la fin des différentes fonctions du programme. Les balises 28 sont placées, par exemple, à un point d'entrée ou à un point de sortie d'une fonction du programme. Lorsque les balises sont placées à l'entrée ou à la sortie de chaque fonction du programme, on dit que le positionnement des balises est réalisé suivant un jalonnement fonctionnel.The second phase of FIG. 1 represents program 21 which corresponds to program 20 after beacons 28 have been positioned. Tags 28 are virtual landmarks positioned at specific locations in the program. These locations preferably correspond to the beginning and / or end of the various functions of the program. Tags 28 are placed, for example, at an entry point or an exit point of a program function. When the beacons are placed at the entrance or exit of each function of the program, it is said that the positioning of the beacons is carried out according to a functional staking.
Les balises peuvent aussi être positionnées à tout autre emplacement prédéfini du chemin d'exécution, par exemple, à un point de défaillance du programme, au niveau des flots de données ou au niveau du flot de contrôle. Les balises constituent des points de repère dans le chemin d'exécution du programme. On comprendra, par la suite, que les balises constituent ainsi des points de reprise du déroulement du chemin d'exécution du programme, lorsqu'une ou plusieurs anomalies(s) ou erreur(s) a (ont) été rencontrée(s), ce qui se manifeste soit par des résultats erronés, soit par une interruption du déroulement du programme, soit par une boucle d'exécution infinie.Tags can also be positioned at any other pre-defined location in the execution path, for example, at a point of program failure, at the data stream level, or at the control flow level. Tags are landmarks in the program's execution path. It will be understood, subsequently, that the tags thus constitute restart points for the execution of the program execution path, when one or more anomalies or errors have been encountered, this manifests itself either by erroneous results, or by an interruption of the course of the program, or by an infinite execution loop.
Une anomalie ou une erreur peut être fonctionnelle. Dans ce cas, le procédé envoie, au développeur, une invitation à corriger ladite anomalie ou ladite erreur.An anomaly or an error may be functional. In this case, the method sends the developer an invitation to correct said anomaly or said error.
L'anomalie ou l'erreur peut aussi être de nature à engendrer une perte de contrôle du déroulement du programme. Une telle erreur peut être, par exemple, un débordement arithmétique du processeur faisant suite, par exemple, à la présence d'un pointeur positionné sur une zone interdite. Dans ce cas, l'exécution du programme s'interrompt. Une interruption consécutive à un débordement arithmétique est appelée interruption sur exception processeur.The anomaly or the error may also be likely to lead to a loss of control of the program's progress. Such an error may be, for example, an arithmetic overflow of the processor following, for example, the presence of a pointer positioned on a forbidden zone. In this case, the execution of the program is interrupted. An interrupt following an arithmetic overflow is called processor exception interrupt.
Le jalonnement fonctionnel du chemin d'exécution proposé dans l'invention permet de détecter, puis de corriger, ce type d'erreur avec interruption sur exception processeur. Pour cela, le jalonnement selon l'invention découpe le chemin d'exécution du programme en intervalles fonctionnels adjacents. Les fonctions s'exécutent les unes à la suite des autres. Dans un mode de réalisation de l'invention, une balise est positionnée au début de chaque fonction. Chaque balise comporte un vecteur d'état qui correspond à l'image de la mémoire. Ce vecteur d'état indique l'état de la mémoire à un emplacement prédéfini, c'est-à-dire à l'emplacement où se situe la balise, ce qui permet, ultérieurement, de réinitialiser la mémoire Avec les informations du vecteur d'état.The functional staking of the execution path proposed in the invention makes it possible to detect and then correct this type of error with interrupt on processor exception. For this, staking according to the invention cuts the execution path of the program into adjacent functional intervals. The functions execute one after the other. In one embodiment of the invention, a tag is positioned at the beginning of each function. Each tag has a state vector that corresponds to the image of the memory. This state vector indicates the state of the memory at a predefined location, i.e. at the location where the tag is located, which allows, later, to reset the memory With the information of the vector of 'state.
Au début du déroulement du programme, toutes les balises sont désactivées. Le vecteur d'état de chacune de ces balises est neutre, ou désactivé, c'est-à-dire qu'il ne contient aucune information. Chaque fois qu'une fonction a été exécutée normalement, la balise située à l'entrée de la fonction suivante change d'état en s'activant. Le vecteur d'état de la balise capture alors un état d'exécution du programme, c'est-à-dire qu'il capture les informations enregistrées dans la mémoire du système à ce niveau d'exécution du programme.At the beginning of the program, all tags are disabled. The state vector of each of these tags is neutral, or disabled, that is, it contains no information. Whenever a function has been executed normally, the tag at the input of the following function changes state by activating. The beacon status vector then captures a program execution state, i.e. it captures the information stored in the system memory at this program execution level.
Le jalonnement peut être réalisé de manière automatique, c'est-à-dire qu'une balise est positionnée automatiquement au début de chaque intervalle fonctionnel. Il peut aussi être interactif, c'est-à-dire que le développeur choisit de positionner des balises supplémentaires, au sein d'une même fonction. Ces balises supplémentaires peuvent être des balises d'entrée, des balises de sortie et/ou des balises intermédiaires. Le choix du jalonnement, interactif ou automatique, est déterminé par le développeur lui- même. Le jalonnement interactif permet d'affiner l'intervalle de recherche et de correction d'une erreur, ce qui permet de réduire ledit intervalle et donc de faciliter la détection de l'erreur.The staking can be performed automatically, that is to say, a tag is automatically positioned at the beginning of each functional interval. It can also be interactive, that is to say that the developer chooses to position additional tags within the same function. These additional tags may be input tags, exit tags and / or intermediate tags. The choice of staking, interactive or automatic, is determined by the developer himself. Interactive staking makes it possible to refine the interval of search and correction of an error, which makes it possible to reduce the interval and thus to facilitate the detection of the error.
Une troisième phase de la figure 1 représente le programme 22 correspondant au programme 21 lors d'une exécution dudit programme en mode normal. Cette exécution en mode normal, appelée exécution normale, correspond au déroulement logique du programme, instruction par instruction, en commençant par la première ligne d'instruction 20-1.A third phase of FIG. 1 represents the program 22 corresponding to program 21 during execution of said program in normal mode. This execution in normal mode, called normal execution, corresponds to the logical flow of the program, statement by instruction, starting with the first instruction line 20-1.
Une quatrième phase de la figure 1 représente le programme 23 correspondant au programme 21 , lorsque les informations à l'état d'exécution du programme et à la position des balises ont été capturées. En effet, lors de l'exécution normale du programme, la balise située à la fin d'une fonction exécutée normalement est activée. Le vecteur d'état de cette balise capture ou mémorise l'état de la mémoire à ce niveau d'exécution du programme.A fourth phase of FIG. 1 represents the program 23 corresponding to the program 21, when the information at the execution state of the program and the position of the beacons have been captured. Indeed, during the normal execution of the program, the beacon at the end of a function performed normally is enabled. The state vector of this tag captures or stores the state of memory at this program run level.
Lors d'une interruption du programme, la dernière balise activée indique la fonction où une interruption du programme a eu lieu. Le vecteur d'état de cette balise permet de retrouver l'état d'exécution dans lequel était le programme au moment où débutait l'exécution de la fonction défaillante.When the program is interrupted, the last activated tag indicates the function where a program interruption occurred. The state vector of this tag is used to find the execution state in which the program was at the time when the execution of the failed function began.
Pour permettre la capture par les vecteurs d'état, un outil d'observation de l'exécution normale détermine les passages sur les balises, dans leur ordre d'occurrence normale, c'est-à-dire suivant une exécution normale des lignes d'instructions du programme. Lorsqu'une balise a été franchie, l'outil d'observation capture l'état de la mémoire dans le vecteur d'état de la dernière balise rencontrée et l'enregistre dans une mémoire de données 4.To allow the capture by the state vectors, a normal execution observation tool determines the passages on the beacons, in their normal order of occurrence, that is to say following a normal execution of the lines. instructions of the program. When a beacon has been crossed, the observation tool captures the state of the memory in the state vector of the last beacon encountered and saves it in a data memory 4.
Lorsqu'une erreur survient, le développeur effectue une exécution reverse du programme pour retrouver ladite erreur au sein du programme. La cinquième phase de la figure 1 représente le programme 24 correspondant au programme 23 lors de cette exécution reverse. Cette exécution reverse permet de remonter le programme en sens inverse du déroulement normal du programme, pour reprendre son exécution à la première ligne d'instruction de la fonction correspondant à la dernière balise activée, c'est-à-dire la dernière fonction dont le vecteur d'état a été capturé.When an error occurs, the developer performs a reverse execution of the program to find the error within the program. The fifth phase of FIG. 1 represents the program 24 corresponding to the program 23 during this reverse execution. This reverse execution makes it possible to trace the program in the opposite direction to the normal running of the program, to resume its execution at the first instruction line of the function corresponding to the last activated beacon, that is to say the last function whose state vector has been captured.
Autrement dit, l'exécution reverse est menée en suivant les balises pour remonter la chaîne d'instructions du programme et déterminer l'emplacement de la chaîne d'instructions défaillante. L'exécution reverse peut ainsi être effectuée à l'intérieur d'un seul intervalle fonctionnel. Lorsqu'une chaîne défaillante, ou erreur, a été détectée dans cet intervalle fonctionnel, le développeur recherche l'erreur ou l'anomalie dans cette chaîne, puis la corrige.In other words, the reverse execution is conducted by following the tags to go up the program's instruction string and determine the location of the faulty instruction string. The reverse execution can thus be performed within a single functional interval. When a faulty string, or error, has been detected in this functional interval, the developer looks for the error or anomaly in this string and then corrects it.
Grâce aux balises, le développeur est capable de repérer facilement la chaîne d'instructions défaillante. Lorsqu'une erreur a été corrigée, le développeur peut continuer l'exécution reverse pour détecter les éventuelles autres erreurs. En effet, avec le procédé de l'invention, le chemin d'exécution est structuré de telle sorte que plusieurs erreurs ou anomalies peuvent être détectées et corrigées en une seule phase de débogage du programme. La phase de débogage qui vient d'être décrite, c'est-à-dire la phase de recherche et de correction d'une erreur, est représentée par le programme 25 sur la figure 1.Thanks to the tags, the developer is able to easily locate the faulty instruction string. When an error has been corrected, the developer can continue the reverse run to detect any other errors. Indeed, with the method of the invention, the execution path is structured in such a way that several errors or anomalies can be detected and corrected in a single debugging phase of the program. The debugging phase which has just been described, that is to say the search and correction phase of an error, is represented by the program 25 in FIG.
Lorsqu'une erreur a été fixée et que le développeur souhaite passer à une erreur suivante ou précédente, il peut disposer d'une phase interactive.When an error has been fixed and the developer wishes to move to a next or previous error, he may have an interactive phase.
Dans cette phase interactive, le programme 26 comporte un jalonnement interactif grâce auquel le développeur peut sauter d'un intervalle fonctionnel à un autre.In this interactive phase, program 26 includes interactive staking whereby the developer can jump from one functional interval to another.
La figure 2 illustre de façon détaillée les différentes étapes du procédé de l'invention. Le diagramme fonctionnel de la figure 2 montre une étape préliminaire 30 dans laquelle une unité de commande de l'environnement de test détecte si une phase de débogage a été sollicitée par le développeur.Figure 2 illustrates in detail the different steps of the method of the invention. The block diagram of Fig. 2 shows a preliminary step in which a control unit of the test environment detects whether a debug phase has been requested by the developer.
Lorsque le développeur souhaite effectuer un débogage, l'unité de commande de l'environnement de test effectue, à l'étape 31 , un balisage du programme en positionnant des balises le long du chemin d'exécution pour découper ledit chemin d'exécution en intervalles fonctionnels adjacents.When the developer wishes to perform debugging, the control unit of the test environment performs, in step 31, a program markup by positioning tags along the execution path to split said execution path into adjacent functional intervals.
Chaque balise comporte un vecteur d'état activé ou désactivé, comme expliqué précédemment. Le vecteur d'état d'une balise est dit activé lorsque les informations relatives à l'état d'exécution du programme ont été capturées. Ainsi, un vecteur d'état d'une balise est activé lorsque la fonction qui précède la balise a été exécutée sans erreur. Il reste désactivé dans le cas contraire.Each tag has a state vector enabled or disabled, as explained above. The state vector of a tag is said to be activated when the information relating to the execution state of the program has been captured. Thus, a beacon state vector is activated when the function preceding the beacon has been executed without error. It remains disabled otherwise.
A l'étape 32, l'unité de commande lance l'exécution normale du programme. A l'étape 33, l'unité de commande capture les informations d'état dans les vecteurs d'états des balises afin de connaître l'état d'exécution du programme.In step 32, the control unit starts the normal execution of the program. In step 33, the control unit captures the state information in the tag state vectors to determine the program execution state.
A l'étape 34, l'unité de commande détecte s'il y a une interruption de l'exécution du programme du logiciel de fonctionnement. Si le programme s'arrête, cela signifie qu'une erreur ou une anomalie a été détectée. On applique, alors l'étape 35. Si aucune interruption n'a lieu, l'exécution normale se poursuit et les étapes 32 et 33 sont réitérées.In step 34, the control unit detects whether there is an interruption in program execution of the operating software. If the program stops, it means that an error or anomaly has been detected. Step 35 is then applied. If no interruption occurs, normal execution continues and steps 32 and 33 are repeated.
A l'étape 35, on détermine si l'interruption a eu lieu sur une exception processeur. Si tel est le cas, alors on applique l'étape 36. Dans le cas contraire, on applique l'étape 37. Dans ce cas, un message est transmis au développeur pour signifier que l'exécution du programme se termine, soit parce qu'une erreur fonctionnelle a été détectée, soit parce que l'exécution normale s'est terminée sans erreur.In step 35, it is determined whether the interruption occurred on a processor exception. If this is the case, then step 36 is applied. Otherwise, step 37 is applied. In this case, a message is transmitted to developer to mean that the execution of the program ends, either because a functional error has been detected, or because the normal execution has ended without error.
Le procédé se poursuit alors par une étape 43, dans laquelle l'unité de commande enregistre la position des balises dans un fichier de résultats des tests, pour permettre une consultation ultérieure du cheminement d'exécution.The method then continues with a step 43, wherein the control unit stores the position of the tags in a test results file, to allow a subsequent consultation of the execution path.
A l'étape 44, le fichier de résultats des tests est fermé. L'étape 45 est une étape finale indiquant la fin du test ou de l'exécution du programme. Si une exception processeur a été détectée à l'étape 35, alors, on recherche, à l'étape 36, la première balise désactivée dans le cheminement normal afin d'en déduire l'intervalle fonctionnel où se trouve la chaîne défaillante. On applique ensuite l'étape 38. A l'étape 38, le développeur peut implanter, de manière interactive, des balises supplémentaires d'entrée, des balises supplémentaires de sortie et/ou des balises intermédiaires pour affiner l'intervalle de recherche de l'erreur dans l'intervalle fonctionnel déterminé à l'étape 36. A l'étape 39, on détecte des points de défaillance dans les flots de données ou les flots de contrôle. Ces points de défaillance permettent d'affiner encore l'intervalle autour de l'erreur. Après détermination de ces points de défaillance, on délimite, à l'étape 40, un intervalle défaillant autour de l'erreur.In step 44, the test results file is closed. Step 45 is a final step indicating the end of the test or the execution of the program. If a processor exception has been detected in step 35, then, in step 36, the first deactivated tag is searched in the normal path in order to deduce the functional interval where the faulty string is located. Step 38 is then applied. At step 38, the developer may interactively implement additional input tags, additional output tags, and / or intermediate tags to refine the search interval of the tag. error in the functional interval determined in step 36. In step 39, points of failure are detected in the data streams or control flows. These points of failure make it possible to further refine the interval around the error. After determining these points of failure, a faulty interval around the error is defined in step 40.
Il est à noter que les étapes 38 à 40 constituent un mode de réalisation préféré de l'invention dans lequel l'intervalle autour de l'erreur est réduit afin de faciliter la recherche de l'erreur lors de l'exécution reverse. Toutefois, le procédé peut prévoir de passer simplement de l'étape 36 de détection de la balise inactive à l'étape 41 d'exécution reverse. Dans ce cas, le développeur doit effectuer l'exécution reverse sur l'ensemble de la fonction dans laquelle l'erreur a été détectée.It should be noted that steps 38 to 40 constitute a preferred embodiment of the invention in which the interval around the error is reduced in order to facilitate the search for the error during the reverse execution. However, the method may provide to simply go from step 36 of detection of the idle tag to the step 41 of reverse execution. In this case, the developer must perform reverse execution on the entire function in which the error was detected.
A l'étape 41 , on lance l'exécution reverse permettant de remonter à la fonction où la chaîne d'instructions défaillante du programme a été détectée. Dans un mode de réalisation de l'invention, l'exécution reverse se fait entre deux balises successives (intervalle). Cela correspond dans le cas les plus courants au début et à la fin de la fonction défaillante. On peut bien sûr sauter d'un intervalle à l'autre sans aucune contrainte particulière. Dans un autre mode de réalisation, l'exécution reverse est effectuée sur un intervalle affiné autour de l'erreur, c'est-à-dire sur une partie seulement de la fonction.In step 41, the reverse execution is started, making it possible to go back to the function where the faulty instruction string of the program has been detected. In one embodiment of the invention, the reverse execution is done between two successive tags (interval). This corresponds in the most common case at the beginning and at the end of the faulty function. We can of course jump from one interval to another without any particular constraint. In one Another embodiment, the reverse execution is performed on a refined interval around the error, that is to say on only part of the function.
A l'étape 42, le développeur effectue le débogage de l'erreur c'est-à- dire qu'il détermine l'erreur dans l'intervalle fonctionnel défaillant et la corrige. Lorsque l'étape 42 de débogage est terminée, le procédé est réitéré à l'étape 31 afin de vérifier si le programme s'exécute correctement.In step 42, the developer performs the debugging of the error that is to say that it determines the error in the faulty functional interval and corrects it. When the debugging step 42 is complete, the method is reiterated in step 31 to verify that the program is executing correctly.
Lorsque l'unité de commande ne détecte plus d'interruption sur exception processeur, alors l'unité de commande envoie, au développeur, un message indiquant que la phase de débogage du programme est terminée (étape 37).When the control unit no longer detects a processor exception interrupt, then the control unit sends the developer a message indicating that the debug phase of the program is complete (step 37).
Le procédé selon l'invention peut être mis en œuvre dans un environnement de test du système simulé virtuellement sur une plate-forme hôte. Il peut être également implanté sur une station de travail connectée à un système embarqué réel par l'intermédiaire d'un émulateur de fonctionnement dédié. Dans ce cas, la position des balises et/ou les vecteurs d'états sont enregistrés (étape 43) sur un support accessible au développeur, par exemple, dans un fichier de résultats de la plate forme hôte. Lorsque toutes les positions de balises ont été enregistrées, le fichier de résultats est fermé (étape 44) et le test est terminé (étape 45). Une vérification de tous les résultats est effectuée (étape 46). Lorsque tous les résultats sont bons, ou ok, on arrive à une étape 47 de fin indiquant que tous ces résultats sont ok. Si tous les résultats ne sont pas ok, les étapes 36 à 42 sont réitérées.The method according to the invention can be implemented in a test environment of the simulated system virtually on a host platform. It can also be installed on a workstation connected to a real embedded system via a dedicated operating emulator. In this case, the position of the tags and / or the state vectors are recorded (step 43) on a support accessible to the developer, for example, in a results file of the host platform. When all tag positions have been recorded, the result file is closed (step 44) and the test is completed (step 45). A check of all the results is performed (step 46). When all the results are good, or ok, we come to an end step 47 indicating that all these results are ok. If all the results are not ok, steps 36 to 42 are repeated.
La figure 3 montre un exemple d'une unité de commande 1 de l'environnement de test du programme de fonctionnement du système embarqué, mettant en œuvre le procédé selon l'invention. L'unité de commande 1 comporte un processeur 2, une mémoire programme 3, une mémoire de données 4, et une interface d'entrée/sortie 5. Le processeur 2, la mémoire programme 3, la mémoire de donnée 4, et l'interface entrée/sortie 5 sont reliés les uns aux autres par un bus de communication 6 bidirectionnel. Un programme 7 est exécuté par le processeur 2, en utilisant des chaînes de codes instructions implantées dans la mémoire programme 3. Le programme 7 a pour rôle de piloter et de contrôler le fonctionnement du système embarqué. Le programme 7 comporte, de manière non exhaustive, un gestionnaire d'interruptions 8, une librairie 9, un ordonnanceur 10, et un ensemble d'applications 11. La librairie 9 comporte une collection de fonctions de commandes activées par le programme 7. Le gestionnaire d'interruptions 8 a pour rôle de réagir en temps réel à des sollicitations du processeur 2 inattendues mais aussi d'assurer la cohabitation multitâche de l'environnement de test. L'ordonnanceur 10 est un programme de service permettant de déterminer automatiquement un ordre de priorité dans le traitement des tâches que le processeur 2 doit effectuer, en fonction de divers critères de priorité et en fonction des ressources disponibles.FIG. 3 shows an example of a control unit 1 of the test environment of the operating program of the onboard system, implementing the method according to the invention. The control unit 1 comprises a processor 2, a program memory 3, a data memory 4, and an input / output interface 5. The processor 2, the program memory 3, the data memory 4, and the input / output interface 5 are connected to each other by a bidirectional communication bus 6. A program 7 is executed by the processor 2, using instruction code chains implanted in the program memory 3. The role of the program 7 is to control and control the operation of the onboard system. The program 7 comprises, in a non-exhaustive manner, an interrupt manager 8, a library 9, a scheduler 10, and a set of applications 11. The library 9 comprises a collection of control functions activated by the program 7. The role of the interrupt manager 8 is to react in real time to unexpected requests from the processor 2 but also to ensure the multitasking coexistence of the environment. test. The scheduler 10 is a service program for automatically determining an order of priority in the processing of the tasks that the processor 2 must perform, according to various priority criteria and according to the available resources.
La mémoire programme 3 comporte, dans une zone 12, les instructions permettant de construire un jalonnement fonctionnel du programme 7 tel que décrit précédemment et d'indiquer la position de l'erreur ou de l'anomalie rencontrée afin de la corriger.The program memory 3 comprises, in a zone 12, the instructions for constructing a functional staking of the program 7 as described above and for indicating the position of the error or anomaly encountered in order to correct it.
La mémoire programme 3 comporte, dans une zone 13, des instructions pour capturer les vecteurs d'état des balises dans le programme 7. La position de chaque balise activée ainsi que son vecteur d'état sont enregistrés dans la mémoire de données 4.The program memory 3 comprises, in a zone 13, instructions for capturing the beacon status vectors in the program 7. The position of each activated beacon as well as its status vector are recorded in the data memory 4.
La mémoire programme 3 comporte, dans une zone 14, des instructions pour lancer l'exécution normale du programme 7. L'exécution du programme 7 du logiciel de fonctionnement se déroule séquentiellement, instruction par instruction, et provoque progressivement l'activation des vecteurs d'état des balises. Quand une erreur survient dans une fonction, l'exécution du programme 7 s'arrête. Les vecteurs d'état des balises qui se trouvent après la fonction où se trouve l'erreur ne sont pas activés. Le vecteur d'état de la dernière balise activée constitue alors un repère qui indique la fonction défaillante, c'est-à-dire la fonction contenant l'erreur.The program memory 3 comprises, in a zone 14, instructions for starting the normal execution of the program 7. The execution of the program 7 of the operating software proceeds sequentially, instruction by instruction, and gradually causes the activation of the vectors of the program. state of the tags. When an error occurs in a function, the execution of program 7 stops. Tag state vectors that are after the function where the error is located are not enabled. The state vector of the last activated tag then constitutes a marker that indicates the faulty function, that is to say the function containing the error.
La mémoire programme 3 comporte, dans une zone 15, des instructions pour lancer une exécution reverse. L'exécution reverse permet, lorsqu'une erreur a été détectée, de remonter jusqu'à la fonction contenant l'instruction défaillante. Le développeur se place sur la balise associée au dernier vecteur d'état activé pour recommencer l'exécution de la fonction. Ainsi, le développeur effectue uniquement l'exécution reverse sur la fonction défaillante.The program memory 3 comprises, in a zone 15, instructions for initiating a reverse execution. The reverse execution allows, when an error has been detected, to go up to the function containing the faulty instruction. The developer is placed on the tag associated with the last state vector activated to restart the execution of the function. Thus, the developer performs only reverse execution on the failing function.
La mémoire programme 3 comporte, dans une zone 16 des instructions permettant d'exploiter les informations recueillies par l'intermédiaire des balises. Ces instructions permettent le débogage du programme 7.The program memory 3 comprises, in a zone 16, instructions making it possible to exploit the information collected by through the tags. These instructions allow debugging of program 7.
La mémoire programme 3 comporte, dans une zone 17, des instructions permettant d'effectuer des sauts d'intervalles fonctionnels. En d'autres termes, les codes instructions de la zone 17 permettent de sauter d'un intervalle fonctionnel à un autre, que le déroulement du programme 7 soit en exécution normale ou en exécution reverse.The program memory 3 comprises, in a zone 17, instructions for performing functional interval jumps. In other words, the instruction codes of the zone 17 make it possible to jump from one functional interval to another, whether the progress of the program 7 is in normal execution or in reverse execution.
On comprend de ce qui précède que le jalonnement fonctionnel de l'invention permet un débogage de logiciels efficace car il offre un moyen de repérer les chaînes d'instructions défaillantes afin de limiter l'exécution reverse aux instructions d'une seule fonction. En outre, il permet de corriger plusieurs erreurs en une seule phase de débogage. It is understood from the foregoing that the functional staking of the invention enables efficient software debugging as it provides a means of locating faulty instruction strings to limit reverse execution to single function instructions. In addition, it can correct multiple errors in a single debugging phase.

Claims

REVENDICATIONS
1 - Procédé de débogage d'un logiciel de fonctionnement d'un système embarqué, caractérisé en ce qu'il comporte les étapes suivantes : a) balisage (31 ) du programme en positionnant des balises le long d'un chemin d'exécution pour découper ledit chemin d'exécution en intervalles fonctionnels adjacents, b) exécution (32) normale du programme, c) capture (33) d'un état d'exécution du programme par des vecteurs d'état des balises, d) lorsqu'une erreur est détectée : recherche (36) d'un intervalle fonctionnel défaillant en fonction des vecteurs d'état des balises,1 - Method of debugging an operating software of an embedded system, characterized in that it comprises the following steps: a) tagging (31) of the program by positioning tags along an execution path for partitioning said execution path into adjacent functional intervals, b) normal execution (32) of the program, c) capture (33) of a program execution state by tag state vectors, d) when a error is detected: search (36) for a faulty functional interval according to the tag state vectors,
- exécution reverse (41) du programme dans cet intervalle fonctionnel défaillant,- reverse execution (41) of the program in this faulty functional interval,
- détermination et correction de l'erreur (42).- determination and correction of the error (42).
2 - Procédé selon la revendication 1 , caractérisé en ce qu'une erreur est détectée lorsqu'un arrêt de programme a été détecté, suite à une exception processeur. 3 - Procédé selon la revendication 1 ou 2, caractérisé en ce qu'il comporte une opération d'affinage de l'intervalle fonctionnel dans lequel se trouve l'erreur.2 - Process according to claim 1, characterized in that an error is detected when a program stop has been detected, following a processor exception. 3 - Process according to claim 1 or 2, characterized in that it comprises a refining operation of the functional interval in which is the error.
4 - Procédé selon la revendication 3, caractérisé en ce que l'opération d'affinage de l'intervalle fonctionnel comporte une détermination de balises supplémentaires d'entrée et de sortie et/ou de balises intermédiaires.4 - Process according to claim 3, characterized in that the operation of refining the functional interval comprises a determination of additional tags input and output and / or intermediate tags.
5 - Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que l'étape de recherche de l'intervalle fonctionnel défaillant est effectuée de manière automatique.5 - Process according to any one of claims 1 to 4, characterized in that the step of finding the faulty functional interval is performed automatically.
6 - Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que l'étape de recherche de l'intervalle fonctionnel défaillant est effectuée de manière interactive par intervention d'un développeur.6 - Process according to any one of claims 1 to 4, characterized in that the step of finding the faulty functional interval is performed interactively by intervention of a developer.
7 - Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'il comporte une étape d'enregistrement de la position de chaque balise et des informations sur l'état d'exécution du programme, dans un fichier de résultats d'une plate-forme hôte.7 - Process according to any one of claims 1 to 6, characterized in that it comprises a step of recording the position of each tag and information about the program execution state, in a result file of a host platform.
8 - Dispositif simulant le fonctionnement d'un système embarqué à bord d'un aéronef, caractérisé en ce qu'il comporte un processeur (2) mettant en œuvre un procédé selon l'une quelconque des revendications 1 à 7.8 - Device simulating the operation of an onboard system on board an aircraft, characterized in that it comprises a processor (2) implementing a method according to any one of claims 1 to 7.
9 - Dispositif selon la revendication 8, caractérisé en ce que le processeur (2) est simulé virtuellement sur une plate-forme hôte de test et de débogage.9 - Device according to claim 8, characterized in that the processor (2) is simulated virtually on a host platform test and debug.
10 - Programme de fonctionnement pour système embarqué pour aéronef, chargeable sur une unité de commande (1) comprenant des séquences d'instructions pour mettre en œuvre le procédé selon l'une des revendications 1 à 7, lorsque le programme est chargé sur l'unité et y est exécuté. 10 - Operation program for an aircraft onboard system, loadable on a control unit (1) comprising sequences of instructions for implementing the method according to one of claims 1 to 7, when the program is loaded on the unit and is executed there.
EP08837964A 2007-09-14 2008-09-12 Method for debugging operational software of a system onboard an aircraft and device for implementing the same Withdrawn EP2188725A2 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0757608A FR2921172B1 (en) 2007-09-14 2007-09-14 METHOD FOR DEBUGGING OPERATING SOFTWARE OF AN ON-BOARD AIRCRAFT SYSTEM AND DEVICE FOR IMPLEMENTING THE SAME
PCT/FR2008/051649 WO2009047435A2 (en) 2007-09-14 2008-09-12 Method for debugging operational software of a system onboard an aircraft and device for implementing the same

Publications (1)

Publication Number Publication Date
EP2188725A2 true EP2188725A2 (en) 2010-05-26

Family

ID=39247645

Family Applications (1)

Application Number Title Priority Date Filing Date
EP08837964A Withdrawn EP2188725A2 (en) 2007-09-14 2008-09-12 Method for debugging operational software of a system onboard an aircraft and device for implementing the same

Country Status (8)

Country Link
US (1) US8650547B2 (en)
EP (1) EP2188725A2 (en)
JP (1) JP5580200B2 (en)
BR (1) BRPI0816977A2 (en)
CA (1) CA2697726A1 (en)
FR (1) FR2921172B1 (en)
RU (1) RU2454706C2 (en)
WO (1) WO2009047435A2 (en)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120192158A1 (en) * 2010-11-22 2012-07-26 Carlo Amalfitano Model Based Verification Using Forward and Reverse Traversal of Variable Time Line
FR2978264B1 (en) * 2011-07-18 2014-06-27 Airbus Operations Sas AN AUTOMATIC SOFTWARE RECHARGING METHOD AND AN AUTOMATIC SOFTWARE RECHARGING DEVICE
US8793661B1 (en) * 2012-04-27 2014-07-29 Google Inc. Programmer specified conditions for raising exceptions and handling errors detected within programming code
CN103577315B (en) * 2012-07-30 2017-02-22 国际商业机器公司 reverse debugger and reverse debugging method
US9183122B2 (en) * 2012-09-14 2015-11-10 International Business Machines Corporation Automated program testing to facilitate recreation of test failure
CN106155899B (en) * 2015-04-17 2019-02-26 比亚迪股份有限公司 The localization method and system of Multimedia Program defect
RU2632546C1 (en) * 2016-06-23 2017-10-05 Публичное акционерное общество "Авиационная холдинговая компания "Сухой" Stand of complexing information-control systems of multifunctional aircraft
US10482000B2 (en) 2017-04-24 2019-11-19 Microsoft Technology Licensing, Llc Machine learned decision guidance for alerts originating from monitoring systems
FR3072475B1 (en) * 2017-10-17 2019-11-01 Thales METHOD OF PROCESSING AN ERROR DURING THE EXECUTION OF A PREDETERMINED AVIONIC PROCEDURE, COMPUTER PROGRAM AND SYSTEM FOR DETECTION AND ALERT
CN108549602B (en) * 2018-03-30 2022-03-08 深圳市江波龙电子股份有限公司 Software debugging method

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06222952A (en) * 1993-01-27 1994-08-12 Toshiba Corp Debug supporting device
JP3585601B2 (en) 1995-09-25 2004-11-04 松下電器産業株式会社 Automatic test apparatus and method for control software
US5870607A (en) * 1996-09-11 1999-02-09 Brown University Research Foundation Method and apparatus for selective replay of computer programs
JPH11184728A (en) 1997-12-25 1999-07-09 Toshiba Corp Debug processing method and device therefor and recording medium for programing and recording the same method
US6202204B1 (en) * 1998-03-11 2001-03-13 Intel Corporation Comprehensive redundant load elimination for architectures supporting control and data speculation
JP3068578B2 (en) 1998-12-10 2000-07-24 日本電気アイシーマイコンシステム株式会社 In-circuit emulator and saturation calculation processing method
US6832367B1 (en) * 2000-03-06 2004-12-14 International Business Machines Corporation Method and system for recording and replaying the execution of distributed java programs
JP2002207611A (en) 2001-01-11 2002-07-26 Mitsubishi Heavy Ind Ltd Software working bench
US7069544B1 (en) * 2001-04-30 2006-06-27 Mips Technologies, Inc. Dynamic selection of a compression algorithm for trace data
US8473922B2 (en) * 2001-09-19 2013-06-25 Hewlett-Packard Development Company, L.P. Runtime monitoring in component-based systems
JP2004094800A (en) 2002-09-03 2004-03-25 Toshiba Corp Program simulation device and its method
CA2408457A1 (en) * 2002-10-17 2004-04-17 Ibm Canada Limited-Ibm Canada Limitee Collection and detection of differences of values of expressions/variables when debugging a computer process
JP2005353020A (en) * 2004-06-08 2005-12-22 Yellow Soft:Kk Simulation system for computer program
US7543278B2 (en) 2004-10-15 2009-06-02 Microsoft Corporation System and method for making a user interface element visible
JP2006139440A (en) 2004-11-11 2006-06-01 Toshiba Corp Emulator apparatus and its control method
US7627857B2 (en) * 2004-11-15 2009-12-01 International Business Machines Corporation System and method for visualizing exception generation
US7849450B1 (en) * 2005-01-28 2010-12-07 Intel Corporation Devices, methods and computer program products for reverse execution of a simulation
WO2006099446A2 (en) * 2005-03-11 2006-09-21 Argade Pramod V Environment for controlling the execution of computer programs
US7836430B2 (en) * 2006-07-21 2010-11-16 Apple Inc. Reversing execution of instructions in a debugger
US8176475B2 (en) * 2006-10-31 2012-05-08 Oracle America, Inc. Method and apparatus for identifying instructions associated with execution events in a data space profiler
US8104022B2 (en) * 2006-11-06 2012-01-24 International Business Machines Corporation Automated method for historical analysis of a memory state
US20080209406A1 (en) * 2007-02-27 2008-08-28 Novell, Inc. History-based call stack construction

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None *

Also Published As

Publication number Publication date
BRPI0816977A2 (en) 2015-03-24
CA2697726A1 (en) 2009-04-16
CN101802794A (en) 2010-08-11
FR2921172A1 (en) 2009-03-20
RU2454706C2 (en) 2012-06-27
WO2009047435A3 (en) 2010-03-18
JP5580200B2 (en) 2014-08-27
US20110016358A1 (en) 2011-01-20
FR2921172B1 (en) 2015-09-04
WO2009047435A2 (en) 2009-04-16
JP2010539578A (en) 2010-12-16
RU2010114707A (en) 2011-10-20
US8650547B2 (en) 2014-02-11

Similar Documents

Publication Publication Date Title
EP2188725A2 (en) Method for debugging operational software of a system onboard an aircraft and device for implementing the same
US10789151B2 (en) Time travel source code debugger incorporating pivoting ability
EP1593982B1 (en) Test of the robustness of a modeling of a physical system
US8839203B2 (en) Code coverage-based taint perimeter detection
US8839201B2 (en) Capturing test data associated with error conditions in software item testing
US8943478B2 (en) Fault detection and localization in dynamic software applications
US9292416B2 (en) Software development kit testing
CA2697725C (en) Method for processing the volume of information handled during the debugging phase of operational software onboard an aircraft and device for implementing the same
CA2696020A1 (en) Method for automatic script generation for testing the validity of operational software of a system onboard and aircraft and device for implementing the same
US9684587B2 (en) Test creation with execution
US20080244325A1 (en) Automated software support system with backwards program execution and debugging
US20120054553A1 (en) Fault localization using condition modeling and return value modeling
US20140109052A1 (en) Test environment managed within tests
US20140109058A1 (en) Test language interpreter
EP2160682B1 (en) Electronic card able to execute a command originating from a simulation system and a command originating from a diagnostic module and associated simulation method
EP2150897B1 (en) Method for simulating a system on board an aircraft for testing an operating software program and device for implementing said method
US10387294B2 (en) Altering a test
CN111597100A (en) Embedded system fault log recording and analyzing method
US9292422B2 (en) Scheduled software item testing
Eichelberger et al. Debugger-based record replay and dynamic analysis for in-vehicle infotainment
Raveh et al. Design for Maintainability Maintainability by Design

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20100223

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MT NL NO PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA MK RS

17Q First examination report despatched

Effective date: 20100721

RIN1 Information on inventor provided before grant (corrected)

Inventor name: BREGEON, VINCENT

Inventor name: RANDIMBIVOLOLONA, FAMANTANANTSOA

Inventor name: FOURNIER, FLORENT

Inventor name: LEMEUR, PHILIPPE

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20170728