WO2009047433A2 - Procédé de traitement du volume d'informations manipulé durant une phase de débogage d'un logiciel de fonctionnement d'un système embarqué à bord d'un aéronef, et dispositif de mise en oeuvre - Google Patents
Procédé de traitement du volume d'informations manipulé durant une phase de débogage d'un logiciel de fonctionnement d'un système embarqué à bord d'un aéronef, et dispositif de mise en oeuvre Download PDFInfo
- Publication number
- WO2009047433A2 WO2009047433A2 PCT/FR2008/051647 FR2008051647W WO2009047433A2 WO 2009047433 A2 WO2009047433 A2 WO 2009047433A2 FR 2008051647 W FR2008051647 W FR 2008051647W WO 2009047433 A2 WO2009047433 A2 WO 2009047433A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- program
- execution
- state
- waypoint
- execution state
- Prior art date
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 subject of the present invention is a method for processing information manipulated during a debugging phase of an operating software of a system intended to be on board an aircraft. This method allows a developer to significantly reduce the volume of information, and therefore the memory resources, necessary for finding and correcting errors in systems operating software intended to be embedded.
- the present invention finds particularly advantageous, but not exclusive, applications in the field of aeronautics and, more particularly, in the field of embedded system software testing.
- 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.
- 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 part comprises at least one central processing unit (CPU) and at least one input / output unit by which the computer is connected to a computer network, to external peripherals, etc.
- CPU central processing unit
- 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 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 step of the calculator's production process that it This is in accordance with the specifications that have been established for said calculator to respond to the expected operation of the system.
- 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.
- 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.
- System call instructions are intercepted by the system operating the host platform that converts them into system calls from 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.
- This reverse execution requires, that at any point of a running path of the operating software formed of a succession of lines of instruction codes, 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.
- a first solution consists in compressing all the data manipulated. This solution is not very effective because the compression coefficient is random (it varies according to the different data manipulated). In addition, it turns out that at the end of the compression operation, the memory space gain obtained is relatively low for a high cost of data compression.
- a second solution is to reduce the data by capturing only the strictly necessary data.
- the method used in this second solution is that of copy-on-write. This solution is based on a regular verification of the information to capture only modified data pages, which allows for minimal information for subsequent regeneration.
- the cost of this capture is minimal; on the other hand, the regeneration that is done requires a relatively long time, especially during an interactive debugging activity because each reconstitution of an initial execution state is established from the totality of the control points captured, since the beginning of the program .
- the present invention aims to overcome the disadvantages described above.
- the invention proposes a method of processing the volume of information manipulated during a debugging phase of an operating software of an embedded system.
- the method of the invention makes it possible to reduce and optimize the memory resource requests allocated to an embedded system.
- the method of the invention proposes to cut the execution path of the operating software into functional intervals, to capture information relating to the state of execution of the software under test, at a given location, and to restore this information later.
- the invention relates to a method of processing the volume of information manipulated during a debugging phase of a program of the operating software of an embedded system, characterized in that it comprises the following steps: a) cutting the execution path of said operating program in functional intervals by setting waypoints to each function of the program, b) setting up control points associated with each waypoint, c) normal execution of the program, in which is performed:
- the invention may also include one or more of the following features:
- the waypoint corresponding to this function changes from a deactivated state to an activated state
- the search for the faulty function consists of searching for the last activated waypoint
- the invention also relates to a device simulating the operation of an on-board computer on board an aircraft, characterized in that it implements the method as defined above.
- This device may comprise a data memory capable of storing a program execution state.
- the subject of the invention is also a program of the operating software for an onboard system on board an aircraft, loadable on a control unit comprising instruction sequences for implementing the method as described above, when the program is loaded on the unit and is executed there.
- FIG. 1 illustrates a functional diagram of the method of the invention
- FIGS. 2a and 2b schematically show a device in which the method of the invention is implemented.
- Operating software consists of a set of programs.
- a program consisting of a set of written instruction suites subsequently called instruction strings. These instruction strings are executed, normally, in their order of occurrence, that is, from the first instruction to the last instruction.
- These chains Instructions executed in their order of occurrence constitute the normal execution path of the program.
- the method of the invention proposes to position tags in the path. program execution in order to determine, with respect to these tags, where the error or anomaly lies.
- Tags are virtual landmarks positioned at specific locations in the program. These locations correspond, for example, to the beginning or the end of the various functions of the program.
- a function is a sequence of instructions that allows you to perform a specific operation together.
- the functions of the program execute one after the other.
- the tags are placed, for example, at each entry point or at each exit point of a program function. When the tags are placed at the entrance or exit of each function of the program, it is said that the tags perform a functional staking of the program.
- Each tag has a waypoint and a control point.
- the waypoint is a virtual landmark that can be positioned at specific locations in the program.
- the locations of waypoints in the program are those previously described for tags.
- Waypoints are benchmarks when running the program. It will be understood later that the waypoints constitute restart points for the execution of the execution path of the program, in case of reverse execution following an interruption of the program flow (when one or more anomalies or errors were encountered). Indeed, a regular distribution of these waypoints throughout the execution path of the program makes it easy to quickly find errors or anomalies encountered.
- This distribution can be of functional type, that is, the waypoints divide the execution path of the program into adjacent functional intervals.
- the checkpoint of each tag is a state vector that corresponds to an image of the memory in which the tags are stored. different data used when running the program.
- a checkpoint indicates the execution state of the program at a given location, ie at the location of the program where the beacon is located, which allows, later, to reset the memory with the information checkpoint.
- a checkpoint is associated with each waypoint.
- a checkpoint consists of all the information referenced by the execution of the program between two temporally consecutive tags. This set is therefore the smallest set, necessary and sufficient, to re-execute the program between these two tags.
- Each waypoint can take two states: an enabled state and a disabled state.
- a waypoint contains, in addition to its state (enabled / disabled), the associated program address and the information that defines the processing to be done when the execution of the program reaches the waypoint address.
- All waypoints are disabled. All control points corresponding to the waypoints are neutral, that is, they contain no information.
- the waypoint at the end of the function, or at the input of the next function changes state by activating.
- the control point associated with this waypoint then captures or stores the execution state in which the program is located at the location of the waypoint.
- the waypoint after a function that runs normally changes from a disabled state to an enabled state.
- the execution state of the program is captured by the control point corresponding to that waypoint.
- the execution state of the program at a given location of the program is stored in a data memory.
- the different execution states of the program are recorded successively, one after the other in the same data memory so that a single execution state is stored simultaneously in the data memory.
- This stored execution state is the last captured execution state, i.e., the execution state of the program at the location of the last enabled waypoint. Indeed, it is considered in the invention that only the storage of the latter execution state is necessary to regenerate, later, the execution state of the program, during a reverse execution.
- capturing an execution state overwrites the record of the previous execution state.
- the previously recorded execution state is deleted, so that the data memory contains only one execution state, namely the execution state useful for program recovery during reverse execution.
- the developer When an error occurs, the developer performs a reverse execution of the program to find the error within the program.
- This reverse execution makes it possible to trace the program in the opposite direction of the normal course of the program, to resume its execution at the first instruction line of the function corresponding to the last activated waypoint, that is to say the last function of which the checkpoint captured the program status information.
- a list of waypoints is stored with the status of each of these points. Thus, when an interruption in the execution of the program occurs, it is searched which was the last waypoint activated and one goes back to the place of the program corresponding to this waypoint. The stored execution status is then searched for in the data memory and the program is re-executed from this location using the data relating to the recorded execution status.
- the reverse execution is carried out following the waypoints to go up the program instruction chain 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 program can be re-executed from the location of the last enabled waypoint.
- This recovery of the program requires recovering the initial execution state.
- this recovery of the execution state only requires, as memory space, the place corresponding to an execution state.
- the link between the waypoint and the control point makes it possible to recover the starting execution state quickly.
- FIG. 1 is an example of a functional diagram of the method of the invention.
- This method comprises a preliminary stage 31 of initialization of a debug phase. This step resets the various parameters useful for the smooth running of the debugging phase.
- step 32 a regular and appropriate cutting of the execution path of the program of the operating software is performed. This cutout identifies the operating context associated with any interval of the program execution path.
- step 33 waypoints are distributed along the program execution path so as to cut said execution path into functional intervals.
- Next to each waypoint is associated a control point. All control points and waypoints form a markup.
- Each waypoint has a passive role; it is only an indicator of the point of resumption of program execution.
- the control point has an active role, that is, it can take two different states (on or off).
- the purpose of the checkpoint is to capture run status information at a specific point in the program and at a specified time.
- step 34 a normal execution of the program is performed.
- a test loop is applied to the program in step 35.
- the passages on a waypoint are detected. If a passage on a waypoint was detected during the execution of the program, ie if a waypoint has been crossed, then step 36 is applied. Otherwise, the procedure is repeated. step 34.
- step 36 the execution state of the program is captured at a given location. This execution state of the captured program is stored in step 37.
- Step 38 is an error detection step in the program. If an error has been detected in the program, then step 39 is applied, otherwise step 40 is applied. In step 39, program execution is stopped. Then, in step 41, the start state of execution of the program is determined. This start state of execution is the last execution state stored in the data memory in step 37.
- step 42 the start state of the execution is regenerated, that is, the execution state in which the program was at the end of the last function executed without error. This regeneration of the start state of execution makes it possible to restore the context of the functional interval of the execution path.
- step 43 a reverse execution is performed in which the program is re-executed from the last activated waypoint and considering, as the execution state, the one captured by the control point associated with the activated waypoint. .
- step 44 the root cause of the error, in the faulty function, is searched in order to trace the faulty string and then correct the error in the program.
- step 45 it is verified that the debugging phase is complete. If the debug phase is complete then the program can be executed in its entirety (step 46). In the opposite case, we return to step 34 and rerun steps 34 to 45.
- step 40 is applied.
- step 40 it is determined whether a functional gap break has been interactively requested by the developer. . If a functional gap break has been required, then step 41 and the following steps are applied.
- step 34 is again used to continue the execution of the program.
- the staking of the program can be performed automatically, that is to say, a tag is automatically positioned at the beginning of each functional interval.
- This staking of the program 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 search and correction interval of a error, which makes it possible to reduce said interval and thus to facilitate the detection of the error.
- the method of the invention makes it possible to perform debugging using a small volume of information, compared to known methods, because the data captured and then restored by means of control points and Waypoints are only those corresponding to a single execution state. Indeed, the volume of program status information is low. In addition, the cost of such a regeneration does not depend on the position of the starting execution state of the program that is to be regenerated, nor on the size of the data memory 4.
- FIG. 2a shows an example of a control unit 1 of a test environment of a system operating software intended to be embedded in an aircraft.
- the test environment may be, according to alternative embodiments, either simulated virtually on a host platform, or based on emulator type hardware equipment.
- the control unit 1 comprises, in a non-exhaustive manner, 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 memory 4 and the input / output interface 5 are connected to each other via a bidirectional communication bus 6.
- FIG. 2a schematically shows a program 7 of the operating software during a debugging phase.
- the program 7 comprises an execution path 8.
- the execution path 8 comprises a set of instruction code lines. Execution path 8 is cut evenly and appropriately to form functional gaps.
- the program 7 is therefore constantly connected, during the debugging phase, with the processor 2, the program memory 3 and the data memory 4.
- the program memory 3 comprises, in a zone 9, the instructions making it possible to carry out a marking of the program 7.
- the marking of the program 7 makes it possible to set up along the execution path 8 waypoints 10. Each point path 10 is associated with a functional interval.
- the marking of the program 7 also makes it possible to position control points 11, 12, 13, 14 and 15 in look at the respective waypoints 10.
- the program memory 3 comprises, in a zone 21, the instructions allowing execution of the program 7.
- the execution of the program 7 makes it possible to unwind the execution path 8, instruction by instruction.
- the execution of the execution path of the program 7 validates the passage on waypoints 10.
- the crossing of waypoints activates sequentially the control points 11, 12, 13, 14 and 15.
- the program memory 3 comprises in a zone 22 the instructions for capturing program execution start state information 7.
- the program memory 3 comprises, in a zone 23, the instructions for storing the program execution start state information 7. The storage of this information is performed in the data memory 4.
- the program memory 3, comprises, in a zone 24, instructions for returning the stored execution status information.
- FIG. 2b shows in more detail the data memory 4.
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
Description
Claims
Priority Applications (6)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CA2697725A CA2697725C (fr) | 2007-09-14 | 2008-09-12 | Procede de traitement du volume d'informations manipule durant une phase de debogage d'un logiciel de fonctionnement d'un systeme embarque a bord d'un aeronef, et dispositif de mise en oeuvre |
US12/678,144 US20100299559A1 (en) | 2007-09-14 | 2008-09-12 | Method for processing the volume of information handled during the debugging phase of operational software onboard an aircraft and device for implementing the same |
CN200880106873A CN101802793A (zh) | 2007-09-14 | 2008-09-12 | 处理飞行器机载系统的运行软件在调试阶段期间处理的信息容量的方法和实施该方法的设备 |
JP2010524556A JP2010539577A (ja) | 2007-09-14 | 2008-09-12 | 航空機搭載のオペレーション・ソフトウェアのデバッグ・フェーズ中に扱われる情報の量を処理するための方法およびその方法を実施するためのデバイス |
BRPI0816978 BRPI0816978A2 (pt) | 2007-09-14 | 2008-09-12 | Processo de tratamento do volume de informações manipulado durante uma fase de depuração de um software de funcionamento de um sistema embarcado a bordo de uma aeronave, e dispositivo de utilização. |
EP08836916A EP2188724A2 (fr) | 2007-09-14 | 2008-09-12 | Procédé de traitement du volume d'informations manipulé durant une phase de débogage d'un logiciel de fonctionnement d'un système embarqué à bord d'un aéronef, et dispositif de mise en oeuvre |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR0757600 | 2007-09-14 | ||
FR0757600A FR2921171B1 (fr) | 2007-09-14 | 2007-09-14 | Procede de minimisation du volume d'informations requis pour le debogage d'un logiciel de fonctionnement d'un systeme embarque a bord d'un aeronef, et dispositif de mise en oeuvre |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2009047433A2 true WO2009047433A2 (fr) | 2009-04-16 |
WO2009047433A3 WO2009047433A3 (fr) | 2010-03-18 |
Family
ID=39145012
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/FR2008/051647 WO2009047433A2 (fr) | 2007-09-14 | 2008-09-12 | Procédé de traitement du volume d'informations manipulé durant une phase de débogage d'un logiciel de fonctionnement d'un système embarqué à bord d'un aéronef, et dispositif de mise en oeuvre |
Country Status (9)
Country | Link |
---|---|
US (1) | US20100299559A1 (fr) |
EP (1) | EP2188724A2 (fr) |
JP (1) | JP2010539577A (fr) |
CN (1) | CN101802793A (fr) |
BR (1) | BRPI0816978A2 (fr) |
CA (1) | CA2697725C (fr) |
FR (1) | FR2921171B1 (fr) |
RU (1) | RU2451990C2 (fr) |
WO (1) | WO2009047433A2 (fr) |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8880668B2 (en) * | 2011-02-28 | 2014-11-04 | Verizon Patent And Licensing Inc. | Method and system for integrating data from multiple sources |
US8776029B2 (en) | 2011-03-23 | 2014-07-08 | Zerodee, Inc. | System and method of software execution path identification |
US8755612B2 (en) | 2011-12-15 | 2014-06-17 | Hewlett-Packard Development Company, L.P. | Identifying truncated character strings |
FR2989794B1 (fr) * | 2012-04-24 | 2014-04-04 | Thales Sa | Procede et dispositif de capture du besoin pour un systeme de pilotage automatique pour aeronef |
US9921859B2 (en) * | 2014-12-12 | 2018-03-20 | The Regents Of The University Of Michigan | Runtime compiler environment with dynamic co-located code execution |
CN106371991A (zh) * | 2016-08-31 | 2017-02-01 | 重庆四联测控技术有限公司 | 一种程序故障的监控方法及系统 |
FR3072475B1 (fr) * | 2017-10-17 | 2019-11-01 | Thales | Procede de traitement d'une erreur lors de l'execution d'une procedure avionique predeterminee, programme d'ordinateur et systeme de detection et d'alerte associe |
CN111427327A (zh) * | 2019-12-27 | 2020-07-17 | 湖北航天飞行器研究所 | 一种飞行器控制软件异常重启的保护方法 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040078784A1 (en) * | 2002-10-17 | 2004-04-22 | International Business Machines Corporation, Armonk, New York | Collection and detection of differences of values of expressions/variables when debugging a computer process |
FR2864655A1 (fr) * | 2003-12-31 | 2005-07-01 | Trusted Logic | Procede de controle d'integrite de programmes par verification d'empreintes de traces d'execution |
Family Cites Families (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH03225533A (ja) * | 1990-01-31 | 1991-10-04 | Fujitsu Ltd | コピーオンライト逆実行チェックポイント方式 |
JPH103403A (ja) * | 1996-06-18 | 1998-01-06 | Toshiba Corp | 計算機システムおよびデバッグ方法 |
JPH10198578A (ja) * | 1998-01-29 | 1998-07-31 | Toshiba Corp | デバッグ方式およびデバッグ方法 |
US6748583B2 (en) * | 2000-12-27 | 2004-06-08 | International Business Machines Corporation | Monitoring execution of an hierarchical visual program such as for debugging a message flow |
JP2002207611A (ja) * | 2001-01-11 | 2002-07-26 | Mitsubishi Heavy Ind Ltd | ソフトウェアワーキングベンチ |
IL151251A0 (en) * | 2002-08-14 | 2003-04-10 | Elta Systems Ltd | Parallel processing platform with synchronous system halt-resume |
RU2215668C1 (ru) * | 2002-11-11 | 2003-11-10 | ОАО "ОКБ им. А.С. Яковлева" | Комплекс бортового радиоэлектронного оборудования легкого многоцелевого самолета |
ATE504446T1 (de) * | 2002-12-02 | 2011-04-15 | Silverbrook Res Pty Ltd | Totdüsenausgleich |
RU42303U1 (ru) * | 2004-06-08 | 2004-11-27 | Открытое акционерное общество "Раменское приборостроительное конструкторское бюро" | Имитатор бортового радиоэлектронного оборудования |
US7543278B2 (en) * | 2004-10-15 | 2009-06-02 | Microsoft Corporation | System and method for making a user interface element visible |
US7849450B1 (en) * | 2005-01-28 | 2010-12-07 | Intel Corporation | Devices, methods and computer program products for reverse execution of a simulation |
US20080155216A1 (en) * | 2005-02-17 | 2008-06-26 | Dov Shoham | Protection and Recovery System for Automatic Disk Recovery |
US7443196B2 (en) * | 2005-07-15 | 2008-10-28 | Tabula, Inc. | Configuration network for a configurable IC |
US8656350B2 (en) * | 2007-02-06 | 2014-02-18 | Software Ag | Event-based process configuration |
US20080307397A1 (en) * | 2007-06-08 | 2008-12-11 | Bill Angell | Program Analysis by Partial Emulation |
-
2007
- 2007-09-14 FR FR0757600A patent/FR2921171B1/fr not_active Expired - Fee Related
-
2008
- 2008-09-12 BR BRPI0816978 patent/BRPI0816978A2/pt not_active IP Right Cessation
- 2008-09-12 US US12/678,144 patent/US20100299559A1/en not_active Abandoned
- 2008-09-12 CN CN200880106873A patent/CN101802793A/zh active Pending
- 2008-09-12 EP EP08836916A patent/EP2188724A2/fr not_active Withdrawn
- 2008-09-12 CA CA2697725A patent/CA2697725C/fr not_active Expired - Fee Related
- 2008-09-12 WO PCT/FR2008/051647 patent/WO2009047433A2/fr active Application Filing
- 2008-09-12 RU RU2010114708/08A patent/RU2451990C2/ru not_active IP Right Cessation
- 2008-09-12 JP JP2010524556A patent/JP2010539577A/ja active Pending
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040078784A1 (en) * | 2002-10-17 | 2004-04-22 | International Business Machines Corporation, Armonk, New York | Collection and detection of differences of values of expressions/variables when debugging a computer process |
FR2864655A1 (fr) * | 2003-12-31 | 2005-07-01 | Trusted Logic | Procede de controle d'integrite de programmes par verification d'empreintes de traces d'execution |
Non-Patent Citations (1)
Title |
---|
CHOI, MILLER, NETZER: "Techniques for debugging parallel programs with flowback analysis", ACM TRANSACTIONS ON PROGRAMMING LANGUAGES AND SYSTEMS, vol. 13, no. 4, 1991, pages 491 - 530, XP002472622 * |
Also Published As
Publication number | Publication date |
---|---|
FR2921171B1 (fr) | 2015-10-23 |
CA2697725A1 (fr) | 2009-04-16 |
EP2188724A2 (fr) | 2010-05-26 |
US20100299559A1 (en) | 2010-11-25 |
CA2697725C (fr) | 2015-11-17 |
JP2010539577A (ja) | 2010-12-16 |
CN101802793A (zh) | 2010-08-11 |
WO2009047433A3 (fr) | 2010-03-18 |
RU2451990C2 (ru) | 2012-05-27 |
BRPI0816978A2 (pt) | 2015-03-24 |
RU2010114708A (ru) | 2011-10-20 |
FR2921171A1 (fr) | 2009-03-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2697725C (fr) | Procede de traitement du volume d'informations manipule durant une phase de debogage d'un logiciel de fonctionnement d'un systeme embarque a bord d'un aeronef, et dispositif de mise en oeuvre | |
US10783055B2 (en) | Time travel source code debugger incorporating live coding ability | |
FR2921172A1 (fr) | Procede de debogage d'un logiciel de fonctionnement d'un systeme embarque a bord d'un aeronef et dispositif de mise en oeuvre | |
FR2921170A1 (fr) | Procede de generation automatique de programmes de test d'un logiciel de fonctionnement d'un systeme embarque a bord d'un aeronef, et dispositif de mise en oeuvre | |
US9063766B2 (en) | System and method of manipulating virtual machine recordings for high-level execution and replay | |
US20080244325A1 (en) | Automated software support system with backwards program execution and debugging | |
US9256417B2 (en) | Automatic quality assurance for software installers | |
EP1593982B1 (fr) | Contrôle de la robustesse d'une modélisation d'un système physique | |
EP2150897B1 (fr) | Procede de simulation d'un systeme embarque a bord d'un aeronef pour tester un logiciel de fonctionnement et dispositif pour la mise en oeuvre de ce procede | |
US9436583B1 (en) | Minimally disruptive debugging in a production environment | |
US20030126521A1 (en) | Test and verification framework | |
US9183122B2 (en) | Automated program testing to facilitate recreation of test failure | |
FR3012636A1 (fr) | Procede de non-regression d'un outil de conception d'un systeme de surveillance de moteur d'aeronef | |
FR3101987A1 (fr) | Procédé de simulation parallèle reproductible de niveau système électronique mis en œuvre au moyen d'un système informatique multi-cœurs de simulation à événements discrets | |
Mackey et al. | On-board model based fault diagnosis for cubesat attitude control subsystem: Flight data results | |
WO2015158742A1 (fr) | Procédé d'analyse du fonctionnement d'un programme exécutable binaire et installation pour la mise en oeuvre de ce procédé | |
WO2013153167A1 (fr) | Dispositif pour générer une signature à l'exécution d'une tâche de programme et méthode de comparaison de flots d'exécution | |
WO2020154064A1 (fr) | Instrumentation de code de diagnostic dynamique sur une exécution de programme historique | |
Chu | Test and evaluation of the robustness of the functional layer of an autonomous robot | |
FR3035984A1 (fr) | Procede de detection d'un logiciel malveillant |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
WWE | Wipo information: entry into national phase |
Ref document number: 200880106873.3 Country of ref document: CN |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 08836916 Country of ref document: EP Kind code of ref document: A2 |
|
REEP | Request for entry into the european phase |
Ref document number: 2008836916 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2008836916 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2697725 Country of ref document: CA |
|
ENP | Entry into the national phase |
Ref document number: 2010524556 Country of ref document: JP Kind code of ref document: A |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2010114708 Country of ref document: RU |
|
WWE | Wipo information: entry into national phase |
Ref document number: 12678144 Country of ref document: US |
|
ENP | Entry into the national phase |
Ref document number: PI0816978 Country of ref document: BR Kind code of ref document: A2 Effective date: 20100315 |