Method and electronic device for monitoring an executable code suitable for execution on a computer platform, and computer program implementing such a method

Description

[0001] The present invention relates to a method for monitoring executable code capable of being executed on a computer platform, the executable code comprising a sequence of software instructions, the method being implemented by an electronic monitoring device.

[0002] The invention also relates to a computer program comprising software instructions which, when executed by a computer, implement such a monitoring method.

[0003] The invention also relates to such an electronic device for monitoring executable code capable of being executed on a computer platform.

[0004] The invention relates to the field of monitoring executable codes comprising sequences of software instructions capable of being executed on computer platforms, in particular monitoring the execution of sequences of instructions expressed in machine language, directly interpretable by the computer platform.

[0005] The article "Formal Executable Models for Automatic Detection of Timing Anomalies" by M. Asavoae, B. Ben Hedia and M. Jan, WCET 2018, teaches that a timing anomaly (from the English timing anomaly ) of an instruction sequence is a counterintuitive timing behavior of that sequence in the sense that fast local execution slows down global execution. The presence of such behaviors is troublesome for worst-case execution time analysis, or WCET analysis (from the English Worst Case Execution Time ), which requires a certain monotony in the order of execution of the instructions, in order to then be able to calculate safe limit values.

[0006] However, this article does not teach how to automatically detect timing anomalies in given computer architecture designs, especially in given sequences of machine language instructions.

[0007] The documents "Data-driven Anomaly Detection with Timing Features for Embedded Systems" by Lu et al, "Virtual simple architecture (VISA): exceeding the complexity limit in safe real-time systems" by Anantaraman et al, and "An efficient reduction technique for degree-constrained subgraph and bidirected network flow problems" by H. Gabow, concern the technological background of the invention.

[0008] The aim of the invention is then to propose a method, and an associated electronic device, for monitoring an executable code comprising a sequence of software instructions, capable of being executed on a computer platform, making it possible to automatically detect temporal anomalies.

[0009] To this end, the invention relates to a method for monitoring executable code capable of being executed on a computer platform, according to claim 1.

[0010] According to other advantageous aspects of the invention, the monitoring method is according to any one of claims 2 to 12.

[0011] The invention also relates to a computer program according to claim 13.

[0012] The invention also relates to an electronic device for monitoring executable code capable of being executed on a computer platform, according to claim 14.

[0013] These characteristics and advantages of the invention will appear more clearly on reading the description which follows, given solely by way of non-limiting example, and made with reference to the appended drawings, in which: there figure 1 is a schematic representation of a computer platform capable of executing executable code, and an electronic device for monitoring said executable code; figure 2 is an illustration of an example of a directed acyclic graph representing a sequence of software instructions forming the executable code monitored by the monitoring device figure 1 ; there figure 3 is a schematic representation of a propagation of time quantization data from one critical chain of instructions to the next; the figure 4 is a schematic representation of four execution timing diagrams of a sequence of four instructions A to D, during different executions by the platform of the figure 1 , comprising two parallel execution units, the fourth timing diagram corresponding to a temporal anomaly; and the figure 5 is a flowchart of a method according to the invention for monitoring an executable code comprising a sequence of software instructions, the method being implemented by the electronic device for monitoring the figure 1 .

[0014] On the figure 1 , an electronic monitoring device 30 is configured to monitor an executable code 32 capable of being executed on a computing platform 34, the executable code 32 comprising a sequence of software instructions.

[0015] The electronic monitoring device 30 comprises a module 40 for acquiring the sequence of software instructions forming the executable code 32 to be monitored; a module 42 for generating a first modeling structure of an execution path of the sequence of instructions; a module 44 for calculating a second modeling structure of an operation of the sequence of instructions; and a module 46 for searching for one or more temporal anomalies from critical chain(s) of instructions determined via the second modeling structure.

[0016] As an optional addition, the electronic monitoring device 30 comprises a module 48 for propagating time quantization data from one critical chain of instructions to the next.

[0017] In the example of the figure 1 , the electronic monitoring device 30 comprises an information processing unit 50 formed for example of a memory 52 and a processor 54 associated with the memory 52.

[0018] The executable code 32 comprises the sequence of software instructions, and the sequence of software instructions is for example a sequence of instructions expressed in machine language, directly interpretable by the computer platform 34.

[0019] The computing platform 34 typically comprises several instruction execution units, such as a first instruction execution unit, also called a first functional unit FU1, and a second instruction execution unit, also called a second functional unit FU2.

[0020] In the example of the figure 1 , the computing platform 34 has a pipelined, or even cascaded, architecture. In this example of the figure 1 , the computer platform 34 comprises six successive stages; namely a first stage for reading IF instructions (from the English Instruction Fetch ); a second stage of decoding and reordering of DR instructions (from the English Decode Reorder ) connected to the output of the first IF instruction reading stage; a third IR instruction register stage (from the English Instruction Register ), connected to the output of the second stage DR; a fourth stage of execution of instructions FU (from the English Functional Unit ), comprising the first and second functional units FU1, FU2 and connected to the output of the third stage of instruction register IR; a fifth stage of access to the memory MEM (from the English MEMory access ), this stage being useful only for the execution of loading and storage instructions, and being for example connected only at the output of the second functional unit FU2 in the example of the figure 1 ; and a sixth floor for storing the WB result (from English Write Back ), the sixth stage being connected to the output of the first functional unit FU1 on the one hand, and of the fifth stage for accessing the memory MEM on the other hand, itself connected to the output of the second functional unit FU2.

[0021] The first instruction reading stage IF is known per se, and is capable of receiving, then successively reading each of the instructions of the sequence of instructions forming the executable code 32 intended to be executed by the computer platform 34.

[0022] The second decoding and reordering stage DR is also known per se, and is capable of preparing the arguments of the instruction for subsequent execution of the instruction by one of the functional units FU1, FU2.

[0023] The third IR instruction register stage typically has one instruction register for each functional unit of the fourth execution stage. In the example of the figure 1 , the third stage IR then comprises two instruction registers, namely a first instruction register IR1 associated with the first execution unit FU1 and connected to the input thereof, and a second instruction register IR2 associated with the second instruction execution unit FU2 and connected to the input thereof.

[0024] The first execution unit FU1 is typically adapted to execute arithmetic and logic instructions, also called ALU instructions (from the English Arithmetical and Logical Unit ), or branch and jump instructions (from English branch And jump ), and the second execution unit FU2 is for example suitable for executing loading and stowing instructions (from the English load And store ), the second execution unit FU2 then being connected for this purpose to the input of the memory access stage MEM.

[0025] The memory access stage MEM is only useful for load and store instructions, and as known per se allows reading the value to be stored in the register concerned in the case of a store instruction, or putting the value read from memory in the register concerned in the case of a load instruction.

[0026] The result storage stage WB is finally adapted to store, in the destination register, the result of the execution of the corresponding software instruction, for example to store the result of arithmetic and logical operations carried out by the first execution unit FU1, or to store in the destination register the value read in memory by the loading instructions, or a new address in the case of branch instructions.

[0027] The sequence of software instructions is a succession of software instructions capable of being executed successively by the computer platform 34. In the example of the figure 2 , the sequence of software instructions comprises twenty-two software instructions numbered from 1 to 22, the software instructions capable of being executed by the first execution unit FU1 being represented in a circular manner, and the software instructions capable of being executed by the second execution unit FU2 being represented in a rectangular manner. The instructions capable of being executed by the first execution unit FU1 are typically ALU type instructions, represented in the form of a circle at the figure 2 , or branch and jump instructions, represented as a circle intersected by an arc in the lower right part of the figure 2 . The software instructions capable of being executed by the second execution unit FU2 are typically memory access instructions, such as load and store instructions, represented in the form of a rectangle at the figure 2 .

[0028] The software instructions represented in the figure 2 then correspond for example to the instructions listed below. 1. jr ra FU1 2. jal ra, -56 FU1 3. addi sp, -32 FU1 4. sdsp ra, 24(sp) FU2 5. sdsp s0, 16(sp) FU2 6. addi4spn s0, sp, 32 FU1 7. sw zero -20(s0) FU2 8. jal ra, -256 FU1 9. addi sp, -32 FU1 10. sdsp s0, 23(sp) FU2 11. addi4spn s0, sp, 32 FU1 12. sw zero, -20(s0) FU2 13. li a5, -1 FU1 14. sw a5, -24(s0) FU2 15. li a5. -1 FU1 16. sw a5, -28(s0) FU2 17. j 62 FU1 18. lw a5, -24(s0) FU2 19. addiw a5, 0 FU1 20. bnez a5, -66 FU1 21. lw a4, -20(s0) FU2 22. slli a4, 2 FU1

[0029] Those skilled in the art will observe that the instructions listed above are then instructions expressed in machine language, directly interpretable by the computer platform 34. The instructions listed above are in this case and as known per se RISC-V type instructions.

[0030] Those skilled in the art will observe that in the above example, the instructions jr, jal, j and bnez are branch and jump instructions, capable of being executed by the first execution unit FU1; the instructions addi, li, addiw, slli and addi4spn are ALU type instructions, capable of being executed by the first execution unit FU1; and that the instructions sdsp, sw and lw are load or store instructions, capable of being executed by the second execution unit FU2.

[0031] In the example of the figure 2 , the relationships between software instructions are represented in the form of arrows, or even in the form of oriented arcs, it being noted that the relationships between two successive software instructions are not necessarily represented for the sake of simplifying the drawing.

[0032] In the example of the figure 1 , the acquisition module 40, the generation module 42, the calculation module 44 and the search module 46, as well as optionally the propagation module 48, are each produced in the form of software, a software brick, executable by the processor 54. The memory 52 of the electronic monitoring device 30 is then capable of storing software for acquiring the sequence of software instructions forming the executable code to be monitored; software for generating the first structure for modeling the execution path of the sequence of instructions; software for calculating the second structure for modeling the operation of the sequence of instructions; and software for searching for temporal anomaly(ies) from critical chain(s) of instructions determined via the second modeling structure.As an optional addition, the memory 52 of the electronic monitoring device 30 is capable of storing software for propagating time quantization data from a respective critical chain of instructions to the next. The processor 54 is then capable of executing each of the software among the acquisition software, the generation software, the calculation software and the search software, as well as, as an optional addition, the propagation software.

[0033] In a variant not shown, the acquisition module 40, the generation module 42, the calculation module 44 and the search module 46, as well as, as an optional addition, the propagation module 48, are each produced in the form of a programmable logic component, such as an FPGA (from the English Field Programmable Gate Array ) , or an integrated circuit, such as an ASIC (from the English Application Specific Integrated Circuit ).

[0034] When the electronic monitoring device 30 is produced in the form of one or more software programs, that is to say in the form of a computer program, also called a computer program product, it is furthermore capable of being recorded on a medium, not shown, that is readable by a computer. The computer-readable medium is, for example, a medium capable of storing electronic instructions and of being coupled to a bus of a computer system. For example, the readable medium is an optical disk, a magneto-optical disk, a ROM memory, a RAM memory, any type of non-volatile memory (for example EPROM, EEPROM, FLASH, NVRAM), a magnetic card or an optical card. A computer program comprising software instructions is then stored on the readable medium.

[0035] The acquisition module 40 is configured to acquire the sequence of software instructions forming the executable code 32. The sequence of software instructions acquired is typically a sequence of instructions expressed in machine language, directly interpretable by the computer platform 34.

[0036] The generation module 42 is configured to generate the first modeling structure of the execution path of the sequence of instructions, the first structure being generated from the sequence of instructions acquired by the acquisition module 40 and comprising a plurality of first data groups, each being associated with a respective software instruction.

[0037] Each first group associated with a respective software instruction comprises an identifier of a software instruction preceding said respective instruction and an identifier of a software instruction following said respective instruction, within the sequence of instructions forming the executable code 32.

[0038] For the generation of the first modeling structure, the generation module 42 is for example configured to traverse an execution path of the sequence of instructions, typically at the binary level, that is to say in machine language, and to determine, for each software instruction, the identifier of each previous instruction, as well as the identifier of each following instruction.

[0039] In addition, each first group further comprises a time quantization of an execution of the respective software instruction, this time quantization being for example expressed in the form of a number of clock cycles for said execution, or in the form of an interval of values ​​of numbers of clock cycles for said execution, between a minimum value and a maximum value of the number of clock cycles possible for executing the respective software instruction. In other words, this time quantization of execution of the respective software instruction, also called execution latency, is expressed in the form of a single value of the number of clock cycles, or in the form of an interval of values ​​of the number of clock cycles.

[0040] As an optional addition, each first group further comprises an identifier of the execution unit associated with the respective software instruction, such as an identifier indicating the execution unit concerned among the first execution unit FU1 and the second execution unit FU2 in the example of figures 1 And 2 .

[0041] As an optional addition, each first group also includes information on possible dependency with other software instructions, such as an identifier of a register common with said other software instructions and / or an identifier of a memory area common with said other software instructions.

[0042] Each first group is for example in the form of a data word, or message, where each of the identifiers or information included in the first group is then in the form of a respective field of that data word.

[0043] The calculation module 44 is configured to calculate the second structure for modeling the operation of the sequence of instructions, the second structure comprising a plurality of second data groups, each being associated with a respective software instruction.

[0044] Each second group is for example in the form of a data word, or message, where each of the elements included in the second group is then in the form of a respective field of that data word.

[0045] Each second data group typically includes an indicator of possible membership in a critical chain of instructions, also called a hot spot (from the English hot point ), and in the case of belonging to a respective critical chain, an identifier of an initial instruction of said critical chain. The indicator of possible belonging to the critical chain is for example identified by the English acronym is_local, and the identifier of the initial instruction of the critical chain is for example identified by the English name start.

[0046] The calculation module 44 is typically configured to calculate the second modeling structure from the first modeling structure generated by the generation module 42, by successively traversing the first groups of the first structure.

[0047] Each respective critical chain corresponds to instructions of the same software function, and the calculation module 44 is configured to calculate each respective critical chain by solving a degree-constrained subgraph problem, also called DCSP (from the English Degree Constrained Subgraph Problem ) each critical chain corresponding to a subgraph, the number of instructions included in each critical chain being less than a predefined maximum number, and an optimization parameter of said problem being the number of relationships between the instructions of the respective critical chain, said number of relationships then corresponding to a number of directed arcs in the associated subgraph.

[0048] Solving DCSP problems is known in itself, and is for example described in the article "Another look at the degree constrained subgraph problem" by Y. Shiloach, published in 1981, or in the article "On the approximability of some degree-constrained subgraph problems" by O. Amini et al., published in 2012.

[0049] The predefined maximum number of instructions contained in each critical chain is for example chosen as a function of a parameter of the pipeline architecture of the computing platform 34, for example as a function of a number of instructions capable of being contained in the entire pipeline of the computing platform 34, or even as a function of the number of instructions capable of being contained in one of the stages of said platform 34, for example in the third stage of instruction register IR or even in the fourth stage of execution of instructions FU.

[0050] In the example of the figure 2 , the predefined maximum number of instructions of the critical chain is equal to 9, and the critical chain L j corresponds to the software instructions 8 to 16, and for this critical chain of instructions, the optimization parameter is here equal to 19 corresponding to the sum of all the relations between the instructions 8 to 16 of said chain, also called internal relations, of the incoming relations towards the instructions of said chain, that is to say the relations between instructions upstream of said chain and said instructions of the chain, and of the outgoing relations of said chain, that is to say the relations between an instruction of said chain and a software instruction downstream of said chain.

[0051] For each critical chain determined via the resolution of the DCSP problem, the calculation module 44 is configured to position the membership indicator at a true value, such as the Boolean value 1 or the value TRUE. is_local associated with each of the software instructions included in the determined critical chain, and also to provide information, as an initial instruction identifier start and for each software instruction included in the determined critical chain, the identifier of the first software instruction in the critical chain thus determined.

[0052] In other words, after having determined a respective critical chain, the calculation module 44 is configured to inform the membership indicator is_local and the initial instruction identifier start for each of the software instructions forming the determined critical chain, and in an identical manner for each of these instructions, the membership indicator is_local being set to true, and the initial instruction identifier start being filled with the identifier of the first instruction of the respective chain.

[0053] As an optional addition, the calculation module 44 is, for each software instruction belonging to a respective critical chain, further configured to calculate a pre-context field, also noted pre_v, and a post-context field, also noted post_v, the pre-context field pre_v including the identifier of each instruction preceding the instruction associated with said second group and not belonging to the critical chain of which said instruction is part, and the post-context field post_v including the identifier of each instruction following the instruction associated with said second group and not belonging to the critical chain of which said instruction is part.

[0054] As an optional addition, the calculation module 44 is configured to calculate, for each software instruction, at least one temporal quantization of an execution path up to said respective instruction, the at least one temporal quantization of the execution path being included in the second group associated with the respective instruction.

[0055] According to this optional addition, the calculation module 44 is typically configured to calculate each execution path time quantization up to the respective software instruction from the pre-context field pre_v for said instruction and execution time quantifications for the instructions identified in this pre-context field pre_v, and from the time quantification of execution of said respective instruction, i.e. its execution latency.

[0056] According to this optional addition, the calculation module 44 is for example configured to calculate, for each software instruction, a first temporal quantization of a shortest execution path up to said respective instruction, i.e. a temporal quantization of the shortest execution path between an initial instruction of the sequence and the respective instruction, the first temporal quantization also being noted sh and included in the second group associated with said instruction.

[0057] The calculation module 44 is configured to calculate the first time quantization sh for the respective instruction from first time quantizations previously calculated for the instructions identified in the pre-context field pre_v of said instruction, that is to say for the instructions preceding said instruction following the possible execution paths, and from the execution latency of said instruction.

[0058] The calculation module 44 is for example configured to calculate the first time quantization sh for said respective instruction from the minimum among the first time quantizations calculated for the instructions identified in the pre-context field. pre_v of the respective software instruction, and from the execution latency of said instruction. The first time quantization sh for said respective instruction is preferably equal to the sum of the minimum among the first time quantizations calculated for the instructions identified in the pre-context field pre_v of the respective software instruction and the execution latency of said instruction.

[0059] The first temporal quantization sh then verifies for example the following equation: sh j = min sh i / i ∈ pre _ v j + Inf lat j Or sh(j) represents the first time quantization for the software instruction of index j, min represents the minimum function, sh(i) represents each first time quantization for a software instruction of index i belonging to the pre-context field pre_v(j) of the instruction of index j, each sh(i) corresponding then to the first time quantization for a respective instruction preceding the instruction of index j, Inf represents the lower bound function, and lat(j) represents the execution latency of the instruction of index j.

[0060] Those skilled in the art will observe that when the execution latency of the instruction of index j is in the form of an interval of values ​​of numbers of clock cycles, then the lower bound is equal to the minimum value of this interval of values, i.e. of this range of values. Alternatively, when the execution latency of the instruction of index j is expressed in the form of a given number of clock cycles for said execution, then the lower bound of this execution latency is equal to said given number of clock cycles.

[0061] According to this optional addition, the calculation module 44 is also configured to calculate a second time quantization corresponding to the time quantization of a longer execution path up to said respective instruction, i.e. of the longest execution path between the initial instruction of the sequence and the respective instruction, the second time quantization also being denotedlo and included in the second group associated with said instruction.

[0062] The calculation module 44 is configured to calculate the second time quantization for the respective instruction from second time quantizations previously calculated for the instructions identified in the pre-context field. pre_v of said instruction, and from the execution latency of said instruction.

[0063] The calculation module 44 is for example configured to calculate the second temporal quantization. lo for said respective instruction from the maximum among the second time quantizations calculated for the instructions identified in the pre-context field pre_v of the respective software instruction, and from the execution latency of said instruction. The second time quantization lofor said respective instruction is preferably equal to the sum of the maximum among the second time quantizations calculated for the instructions identified in the pre-context field pre_v of the respective software instruction and the execution latency of said instruction.

[0064] The second time quantization lo for the respective instruction then verifies for example the following equation: lo j = Max lo i / i ∈ pre _ v j + Sup lat j Or lo(j) represents the second time quantization for the software instruction of index j, Max represents the maximum function, lo(i) represents each second time quantization for a software instruction of index i belonging to the pre-context field pre_v(j) of the instruction of index j, each lo(i) corresponding then to the second time quantization for a respective instruction preceding the instruction of index j, Sup represents the upper bound function, and lat(j) represents the execution latency of the instruction of index j.

[0065] Those skilled in the art will observe similarly that when the execution latency of the instruction of index j is in the form of an interval of values ​​of numbers of clock cycles, then the upper bound is equal to the maximum value of this interval of values, i.e. of this range of values. Alternatively, when the execution latency of the instruction of index j is expressed in the form of a given number of clock cycles for said execution, then the upper bound of this execution latency is equal to said given number of clock cycles.

[0066] As an optional addition, the calculation module 44 is configured to calculate a range field, also referred to by the English name scope, for each determined critical instruction chain, and to then include said scope field scope in the second modeling structure. The calculation module 44 is configured to calculate the extent field scope for said respective critical chain as a function of the memory accesses made by all the instructions of said critical chain, the scope field scope representing an extent, or even an amplitude, of the memory accesses carried out by said critical chain.

[0067] According to this optional complement, the scope field scope includes for example a value equal to the number of memory accesses made by all the instructions in said critical chain. In addition or as a variant, the scope field scope is a function of cache memory misses (from English cache miss) associated with the instructions of said critical chain, a cache memory fault then being counted as a predefined number of memory accesses, this predefined number of memory accesses typically having a value strictly greater than 1, in order to take more account in said scope field scope cache memory miss(s) than simple memory access. A cache memory miss is for example counted as being equal to 10 memory access cycles.

[0068] The scope of the field scope then allows prioritization between several calculated critical chains, in particular when several critical chains are associated with the same respective software function. The selected critical chain is then the one for which the value included in the scope field scope, representative of the extent of memory accesses performed by the respective critical chain, is the highest.

[0069] As an optional addition, the calculation module 44 is configured to calculate a variability field boil for each respective critical instruction chain, and to then include said variability field boil in the second modeling structure. The field of variability boil has a pre-context variable equal to the most frequent identifier among the instruction identifiers contained in the pre-context fields for_v for said critical chain; and a post-context variable equal to the most frequent identifier among the instruction identifiers contained in the post-context fields post_v for the said respective critical chain.

[0070] The field of variability boil then allows to identify a critical entry point of the critical chain via the pre-context field for_vfor said critical chain; and / or to identify a critical exit point of said critical chain via the post-context field post_v. For example, the pre-context field for_v allows to establish input values ​​that are useful for fully exploring the critical chain, using the above-mentioned procedure, and the post-context field post_v allows to have the observed output values ​​of the complete exploration of the critical chain. Thus, the field of variability boil allows capturing input-output time relationships at the critical chain level.

[0071] In addition, the field of variability boil is taken into account when propagating time quantization data from one chain to the next. According to this complement, the post-context field post_v of the critical chain L j is propagated to the next critical chain L j+1 , this post-context field post_vof the critical chain L j being for example taken into account for the determination of the pre-context field for_v of the following critical chain L j+1 .

[0072] The search module 46 is configured to search for one or more time anomalies from critical instruction chain(s) determined via the second modeling structure. A time anomaly is detected in the event of an inconsistency between the time quantifications associated with a current critical chain and the time quantifications associated with a following critical chain. The search module 46 is then typically configured to search for inconsistencies between the time quantifications. sh, loof two successive critical chains. An inconsistency between the time quantizations associated with two successive critical chains corresponds, for example, to the case where the longest execution path corresponding to a second time quantization associated with a respective critical chain does not include the software instructions of the previous critical chain, i.e. does not pass through the previous critical chain.

[0073] A timing anomaly during the execution of the sequence of software instructions is a counter-intuitive temporal behavior during the execution of this sequence, typically corresponding to a break in the monotony of the temporal evolution of the execution of the sequence, this being then due to a fast local execution slowing down a global execution.

[0074] A break in the monotony of the time evolution of the execution of the sequence of software instructions is typically due to the presence of one or more cache memory faults (from the English cache misses) associated with one or more of the software instructions. In other words, the presence of such cache memory faults is likely to lead to the appearance of a timing anomaly.

[0075] A break in the monotony of the time evolution is illustrated as an example on the figure 4 . In the example of the figure 4, four execution paths 60, namely a first 60A, a second 60B, a third 60C and a fourth 60D execution paths, are represented in parallel within the framework of the execution of a sequence formed of four software instructions A, B, C and D, where instructions A and D are intended to be executed by the first execution unit FU1, and software instructions B and C are intended to be executed by the second execution unit FU2.

[0076] In this example of the figure 4 , the execution time of the sequence increases progressively from the first execution path 60A shown at the top of the figure 4, and for which the execution of the sequence is carried out in ten clock cycles numbered 1 to 10, up to the third execution path 60C, this third execution path 60C corresponding to an execution of the sequence in twelve clock cycles numbered 1 to 12. Those skilled in the art will then observe that the increase in the execution time between the first 60A and third 60C paths is due to a progressive increase in the execution time of the software instruction A by the first execution unit FU1, this being equal to one clock cycle for the first execution path 60A, then to two clock cycles numbered 1 and 2 for the second execution path 60B, and finally to three clock cycles for the third execution path 60C. The fourth execution path 60D, shown at the bottom of the figure 4 , then presents a temporal anomaly TA (from English Timing Anomaly), since the overall execution time of the sequence then corresponds to nine clock cycles, numbered 1 to 9, that is to say the execution time of the shortest sequence among the four execution paths 60 represented in figure 4 , whereas the execution time of the software instruction A for this fourth execution path 60D is equal to the execution time of the software instruction A for the third execution path 60C, and is strictly greater than the execution time of the software instruction A for each of the first 60A and second 60B execution paths.

[0077] We then observe that in this example of the figure 4, the time anomaly TA is due to the fact that, for this fourth execution path 60D, the software instruction C is executed before the software instruction D by the second execution unit FU2, and that the last software instruction D of the sequence is then executed by the first execution unit FU1 in parallel with the execution of the software instruction B by the second execution unit FU2. The execution of the last software instruction D then ends at the end of cycle 9, at the same time as that of the software instruction B, and this shortening of the overall execution time of the sequence then causes a break in the monotony of the evolution of the duration of the execution of said sequence, characteristic of the time anomaly TA to be detected.

[0078] As an optional addition, the propagation module 48 is configured to propagate time quantization data from a current critical chain of instructions to a following critical chain of instructions, the time quantizations associated with the following critical chain then being determined from those associated with the current critical chain.

[0079] For the propagation of the time quantization data from one chain to the next, the propagation module 48 is for example configured to calculate at least one limit value 70, 80 representative of a global execution time quantization of the current critical chain, such as the critical chain L j , in order to then propagate it to the next critical chain, such as the critical chain L j+1 .

[0080] The propagation module 48 is for example configured to calculate a first limit value 70 corresponding to a shortest overall execution path of the critical chain, this first limit value 70 being for example noted Lj.sh for the critical chain L j; and a second limit value 80 corresponding to a longest overall execution path for the critical chain, this second limit value 80 being for example noted Lj.lo for the critical chain L j.

[0081] According to this optional addition, the propagation module 48 is for example configured to calculate the at least one limit value 70, 80 by applying a model verification algorithm (from the English model checking ) to the current critical chain, such as the critical chain L j , i.e. by implementing said model checking algorithm for said current critical chain.

[0082] The model checking algorithm is known per se, and is for example described in the paper entitled "Model checking (second edition)" by E. Clarke et al., MIT Press, 2018, and is based on a Kripke structure allowing to model a transition system, such as the respective critical chain. The Kripke structure is typically in the form of a 4-tuple (S, S0, R, L), where S is a set of a finite number of states; S0 is the set of initial values ​​of the states of the set S; R is a transition relation on the states of the set S; and L is a labeling function (from the English labeling function ) of the states of the set S into logical formulas, that is to say a function of interpretation of said states of the set S into logical formulas.

[0083] For the application of the model verification algorithm to the respective critical chain, and in particular for the implementation of the Kripke structure for said critical chain, the propagation module 48 is then configured to fill in the tuple S0 corresponding to the set of initial values ​​of the states with the pre-context field for_in, and the model verification algorithm then makes it possible to explore the set of execution paths for said critical chain, this set of execution paths corresponding to the tuple S, or in other words each state of the set S corresponding to a possible execution of the software instructions of the critical chain, as described for example in the article “Formal executable models for automatic detection of timing anomalies” by M. Asavoae et al., WCET 2018.

[0084] The propagation module 48 is then configured to calculate the first and second limit values ​​70, 80 for the current critical chain, such as the values ​​Lj.sh and Lj.lo for the critical chain L j , via the implementation of the model verification algorithm for said current critical chain, such as the critical chain L j ; then to propagate the limit value(s) 70, 80 thus calculated to the next critical chain, such as the critical chain L j+1 .

[0085] The propagation module 48 is configured to carry out said propagation of time quantization data by determining an execution path connecting the end of the current critical chain, such as the critical chain L j , to the start of the next critical chain, such as the critical chain L j+1 , this execution path preferably being unique. The propagation module 48 is then for example configured to add, to the limit value(s) 70, 80, the execution latency of each of the software instructions forming said path between the end of the current critical chain and the start of the next critical chain.

[0086] The propagation module 48 is then configured to update the pre-context field for_vfor the following critical chain, such as the critical chain L j+1 , with the result of this propagation, that is to say with the sum of the limit value(s) 70, 80 of the critical chain which precedes it, that is to say of the current critical chain, such as the critical chain L j , and the execution latencies for the software instructions between said current critical chain and the following critical chain, said instructions between two successive critical chains also being called intermediate instructions.

[0087] Additionally, the propagation module 48 is then configured to apply the model verification algorithm to the next critical chain, such as the critical chain L j+1 , using the result of this propagation contained in the pre-context field for_vupdated, in order to calculate the at least one limit value 70, 80 for the following critical chain, and for example the first limit value 70 for said following critical chain, such as the value Lj+1.sh, and the second limit value 80 for said following critical chain, such as the value Lj+1.lo.

[0088] This propagation of time quantization data is illustrated in the figure 3where during a first iteration, denoted iter i , the calculation module 44 is configured to calculate successive critical chains denoted L j , L j+1 , L j+2 via the resolution of DCSP problems. Then, during a following iteration denoted iter i+1 , the propagation module 48 is configured to calculate the limit values ​​70, 80 associated with the current critical chain, such as the limit values ​​Lj.sh, Lj.lo for the critical chain L j , via the implementation of the model verification algorithm for said current critical chain, such as the critical chain L j .Then, during a subsequent iteration, denoted iter i+2 , the propagation module 48 is configured - on the one hand - to perform the sum of the execution latencies for the software instructions located between the end of the current critical chain, such as the critical chain L j , and the start of the following critical chain, , such as the critical chain L j+1 , and add this sum to the limit values ​​70, 80 in order to propagate these values ​​70, 80 from the current critical chain to the following critical chain, then on the other hand - to implement the model verification algorithm for the following critical chain, such as the critical chain L j+1 , in order to calculate the limit value(s) 70, 80, such as the limit values ​​Lj+1.sh, Lj+1.lo, and then taking into account the result of the time propagation previously performed and contained in the pre-context field . for_vupdated for the next critical chain, such as critical chain L j+1 .

[0089] According to this optional addition, the search module 46 is then further configured to search for a possible time anomaly between the current critical chain and the following critical chain, by checking whether the limit value(s) 70, 80 calculated for the following critical chain are consistent with the critical chain which precedes it, i.e. with the current critical chain, and typically to check whether the longest overall execution path to the following critical chain corresponding to the second limit value 80 calculated for the following critical chain, such as the value Lj+1.lo for the critical chain L j+1, includes the software instructions of the critical chain which precedes it, i.e. of the current critical chain, such as the critical chain L j.

[0090] If the longest global execution path to the next critical chain contains the software instructions of the critical chain that precedes it, i.e. the current critical chain, or in other words if the longest global execution path to the next critical chain passes through the current critical chain, then the search module 46 is configured to determine an absence of a time anomaly between the current critical chain and the next critical chain. Otherwise, if the longest global execution path to the next critical chain does not contain the software instructions of the critical chain that precedes it, i.e. the current critical chain, then the search module 46 is configured to detect the presence of a time anomaly between the current critical chain and the next critical chain.

[0091] Additionally, in the event of determination of an absence of temporal anomaly between the current critical chain and the following critical chain by the search module 46, the propagation module 48 is further configured to continue the propagation of the temporal quantization data from one critical chain to the following, and then to carry out a propagation operation by propagating the temporal quantization data from the critical chain L j+1 to the critical chain L j+2, and so on.

[0092] The operation of the electronic monitoring device 30 according to the invention will now be described with regard to the figure 5 representing a flowchart of the method, according to the invention, for monitoring the executable code 32 capable of being executed on the computer platform 34.

[0093] During an initial step 100, the electronic monitoring device 30 acquires, via its acquisition module 40, the sequence of software instructions forming the executable code 32 intended to be monitored. The sequence of software instructions acquired during this initial step 100 is typically a sequence of instructions expressed in machine language and which are then directly interpretable by the computer platform 34. These software instructions are for example RISC type instructions, as in the example described previously.

[0094] The monitoring device 30 then proceeds to the next step 110 during which the generation module 42 generates the first modeling structure modeling the execution path(s) of the sequence of instructions, the first modeling structure being generated from the sequence of instructions and comprising a respective first group of data for each of the software instructions of said sequence. Each respective first group comprises the identifier of the previous instruction and the identifier of the following instruction for the respective software instruction associated with said first group.

[0095] During this generation step 110, each first group generated further comprises the execution latency of the respective software instruction, this execution latency typically being expressed in the form of an interval of values ​​of numbers of clock cycles necessary for the execution of said instruction, or even in the form of a given number of clock cycles necessary for said execution.

[0096] As an optional addition, each respective first group further comprises the identifier of the execution unit associated with the respective software instruction, such as the identifier of the execution unit implemented among the first functional unit FU1 and the second functional unit FU2 for the computing platform 34 of the example of the figure 1 .

[0097] According to this addition, the execution unit identifier is used to model the execution of software instructions on a given execution unit, whereby the execution speed of the instructions by a respective execution unit, or correspondingly the execution time, or the execution latency, depends on the execution unit considered. According to this addition, the execution unit identifier is then further taken into account when solving the degree-constrained subgraph problem or DCSP, for the calculation of the respective critical chain.

[0098] In addition, each respective first group also includes information on possible dependency with other instructions, such as the identifier of each register in common between the respective software instruction and said other instructions and / or the identifier of each memory area common with said other instructions, i.e. of each memory area used in common by the respective software instruction and said other instructions.

[0099] According to this addition, the possible dependency information is used to further improve the modeling of the execution path, in particular by making it possible to indicate when software instructions are executed within the sequence of instructions.

[0100] Those skilled in the art will further observe that during the complete exploration of a critical chain, the sequence of instructions considered is executed according to the execution mode of the computing platform, for example according to an out-of-order mode (from the English out of order ), the order of execution of the sequence of instructions in the critical chain is, in other words, not necessarily a sequential order.

[0101] Also, when the execution mode of the computing platform is not a sequential execution mode, and the software instructions are then not executed in a sequential order, the information of possible dependency is taken into account in addition when solving the problem of subgraphs with constraints on the degree or DCSP, for the calculation of the respective critical chain, in order to allow the exploration of the different possible execution paths.

[0102] During the following step 120, the monitoring device 30 calculates, via its calculation module 44, the second modeling structure modeling the operation of the sequence of instructions, the second structure being calculated from the first modeling structure and comprising a second respective group of data for each of the software instructions of the sequence.

[0103] Each second group includes the membership indicator in particular is_localindicating a possible membership of the respective instruction in a corresponding critical chain of the sequence, i.e. indicating the membership or not of said software instruction in a respective hot point, this indicator being typically set to the true value if the respective software instruction belongs to a critical chain, and to the false value, such as the Boolean value 0 or the value FALSE, if said respective software instruction does not belong to any critical chain. Each second group further comprises, in the case of membership in a respective critical chain, the initial instruction identifier start, i.e. the identifier of the first software instruction in the respective critical chain.

[0104] During this calculation step 120, the second modeling structure is obtained from the first structure, by successively traversing the first groups of the first structure. Each respective critical chain corresponds to instructions of the same software function, and is typically calculated by solving a DCSP problem, i.e. a subgraph problem with constraints on the degree, as described previously.

[0105] In addition, for each software instruction belonging to a respective critical chain, the calculation module 44 further calculates the pre-context field for_v and the post-context field post_v, the pre-context field for_v including the identifier of each instruction preceding the respective software instruction and not belonging to the critical chain of which said instruction is part, and the post-context field post_vincluding the identifier of each instruction following the respective software instruction and not belonging to the critical chain of which said instruction is part.

[0106] In addition, the calculation module 44 calculates, during this step 120, at least one temporal quantization sh, lo of the execution path to the respective software instruction, and preferably both the first time quantization sh equal to the time quantization of the shortest execution path to the respective software instruction, and the second time quantization lo equal to the time quantization of the longest execution path to the respective instruction.

[0107] According to this complement, each execution path temporal quantization lo, sh is typically calculated from the pre-context field for_vand time quantifications of execution of the instructions identified in said pre-context field, and also from the execution latency of said respective instruction.

[0108] As an optional addition, during step 120, the calculation module 44 further calculates the extent field scope for each respective critical instruction chain, this scope field scope allowing in particular to carry out a prioritization between several possible critical chains associated with the same software function, in order to then select the critical chain with the highest priority for this software function, typically the critical chain for which the scope scope has the highest value, characteristic of greater use of the memory resources of the computing platform 34.

[0109] As an optional addition, the calculation module 44 also calculates, during this step 120, the variability field boil for each respective critical chain. This field of variability boil including for example the pre-context variable equal to the most frequent identifier among the instruction identifiers contained in the pre-context fields for_v for said critical chain and then making it possible to identify the software instruction most likely to be executed prior to said critical chain, and / or the post-context variable equal to the most frequent identifier among the instruction identifiers contained in the post-context fields post_v for said critical chain, making it possible in a similar manner to identify the software instruction most likely to be executed after said critical chain.

[0110] In a following optional step 130, the propagation module 48 propagates the time quantization data from a current critical chain of instructions to the next critical chain, and for example from the critical chain L j to the critical chain L j+1 . This propagation of time quantization data is for example carried out by first implementing the model verification algorithm for the current critical chain, such as the critical chain L j , in order to calculate the limit value(s) 70, 80, such as the first limit value 70, also denoted Lj.sh and corresponding to the shortest overall execution path to the critical chain L j , and the second limit value 80, also denoted Lj.lo and corresponding to the longest execution path up to the critical chain L j The propagation module 48 then propagates the limit value(s) 70, 80 thus calculated up to the next critical chain, such as the critical chain L j+1, by adding to them the execution latencies of the intermediate software instructions between the end of the current critical chain, such as the critical chain L j, and the start of the next critical chain, such as the critical chain L j+1.

[0111] The monitoring device 30 finally searches, during step 140 and via its search module 46, for one or more temporal anomalies from the critical chains of instructions determined via the second structure of the modeling during the calculation step 120. This search for temporal anomaly(ies) is typically carried out by searching for possible inconsistencies between the temporal quantifications associated with the current critical chain and those associated with the following critical chain, for example by searching for possible inconsistencies between the temporal quantifications of the critical chains L j and L j+1 , then during a following iteration between those of the critical chains L j+1 and L j+2 .

[0112] Additionally, when the time quantization data has been propagated from a current critical chain to the next during the optional step 130, for example from the critical chain L j to the critical chain L j+1 as shown in the figure 3 , the search module 46 will preferably search for the presence of possible time anomaly(ies) by checking whether the longest global execution path up to a respective critical chain, such as the chain L j+1 , contains the software instructions of the preceding critical chain, such as the critical chain L j , and then determines, if applicable, an absence of time anomaly. This verification is typically carried out via a comparison of a sorted list of the identifiers of the software instructions forming the longest global execution path up to the critical chain L j+1 with the list of software instructions forming the critical chain L j which precedes it.

[0113] According to this addition, if the search module 46 concludes on the contrary, following this verification, that the longest global execution path up to the critical chain L j+1 does not pass through the critical chain L j which precedes it, that is to say does not contain all the software instructions of said critical chain L j , then the search module 46 determines the presence of a time anomaly between the critical chains L j and L j+1 . If necessary, the search module 46 preferably generates an alert, in order to signal said time anomaly.

[0114] If no temporal anomaly has been found during the search step 140 between the critical chains L j and L j+1 , then the monitoring device 30 returns for example to the optional step 130 in order to carry out a new propagation of temporal quantification data from one critical chain to the next, in this case from the critical chain L j+1 to the critical chain L j+2 , then goes again to the search step 140 in order to search for the presence of possible temporal anomaly(ies) between the critical chains L j+1 and L j+2 , and so on.

[0115] Thus, the monitoring device 30 and the monitoring method according to the invention make it possible to automatically determine the critical instruction chain(s), also called hot spots, for the sequence of software instructions forming the monitored executable code 32, this from the second modeling structure calculated by the calculation module 44, this second structure itself being obtained from the first modeling structure generated by the generation module 42.

[0116] The monitoring device 30 and the monitoring method according to the invention then make it possible to further search for the presence of one or more possible temporal anomalies associated with the execution of the sequence of instructions forming said executable code 32, this from the critical chains of instructions determined via the second modeling structure, and typically from the temporal quantifications of the execution paths associated with each of these critical chains of instructions.

[0117] It is thus understood that the monitoring device 30 and the monitoring method according to the invention make it possible to automatically and easily detect possible temporal anomalies.

Claims

1. A method for monitoring an executable code adapted to be executed on a computer platform, the executable code comprising a sequence of software instructions, the method being implemented by an electronic monitoring device and comprising the following steps: - acquiring (100) the sequence of software instructions; - generating (100) a first modeling structure of an execution path of the sequence of instructions, with the first structure generated from the sequence of instructions and including a plurality of first groups of data, each first group being associated with a respective software instruction and including an identifier of a previous instruction and an identifier of a following instruction; - calculating (120) a second modelling structure of an operation of the sequence of instructions, the second structure comprising a plurality of second groups of data, each second group being associated with a respective software instruction and comprising an indicator of possible belonging to a critical chain of instructions, and in the case of belonging to a respective critical chain, an identifier of an initial instruction of said critical chain; the second structure being created from the first structure by successively going through the first groups of the first structure; a respective critical chain corresponding to instructions of a same software function, being computed by solving a subgraph problem with degree constraints, each critical chain corresponding to a subgraph, the number of instructions included in each critical chain being less than or equal to a predefined maximum number, and an optimization parameter being the number of relationships between the instructions of the respective critical chain, said number of relationships corresponding to a number of arcs in the related subgraph; and - searching for runtime anomaly / anomalies from critical chain(s) of instructions determined via the second modeling structure.

2. The method according to claim 1, wherein in the calculation step, for each software instruction belonging to a respective critical chain, each second group further comprises a pre-context and a post-context field, with the pre-context field including the identifier of each instruction preceding the instruction associated with said second group and not belonging to the critical chain of which said instruction is a part, and the post-context field including the identifier of each instruction succeeding the instruction associated with said second group and not belonging to the critical chain of which said instruction is part.

3. The method according to claim 2, wherein in the calculation step, a scope field is added for each respective critical chain of instructions in the second modeling structure, the scope field including a number of memory accesses from all instructions in said critical chain.

4. The method according to claim 2 or 3, wherein in the calculation step, a pre-context variable and a post-context variable are added for each respective critical chain of instructions in the second modeling structure, the pre-context variable being equal to the most frequent of the instruction identifiers contained in the pre-context fields for said critical chain, and the post-context variable being equal to the most frequent of the instruction identifiers contained in the post-context fields for said critical chain.

5. The method according to any one of the preceding claims, wherein each first group further comprises a runtime quantification of an execution of the respective software instruction, and each second group further comprises at least a runtime quantification of an execution path of the sequence to said respective instruction; the runtime quantification of the execution of the respective software instruction preferably being a number of clock cycles for said execution.

6. The method according to claims 2 and 5, wherein each runtime quantification of an execution path to the respective software instruction is calculated from the pre-context field for said instruction and the execution runtime quantifications for said respective instruction and for the instructions identified in the pre-context field.

7. The method according to claim 5 or 6, wherein the method further comprises a step of propagating runtime quantification data from a previous critical chain of instructions to a current critical chain of instructions, the runtime quantifications associated with the current critical chain being determined from those associated with the previous critical chain.

8. The method according to claim 7, wherein in the search step, a runtime anomaly is detected if there is an inconsistency between the runtime quantifications associated with the current critical chain and those associated with the previous critical chain.

9. The method according to any one of claims 5 to 8, wherein a first runtime quantification included in the second group is a runtime quantification of a shortest execution path between an initial instruction of the sequence and the respective instruction; and a second runtime quantification included in the second group is a runtime quantification of a longest execution path between said initial instruction and the respective instruction.

10. The method according to any one of the preceding claims, wherein the computer platform comprises a plurality of instruction(s) execution units (FU1, FU2), and each first group further comprises an identifier of the execution unit (FU1, FU2) associated with the respective software instruction.

11. The method according to any one of the preceding claims, wherein each first group further comprises information on possible dependency with other instructions, such as a common register identifier with said other instructions and / or a common memory area identifier with said other instructions.

12. The method according to any of the preceding claims, wherein the sequence of software instructions is a sequence of instructions expressed in machine language, directly interpretable by the computer platform.

13. A computer program comprising software instructions that implement a method according to any of the preceding claims when executed by a computer.

14. An electronic device (30) for monitoring an executable code (32) adapted to be executed on a computer platform (34), the executable code (32) comprising a sequence of software instructions, the device (30) comprising: - an acquisition module (40) configured to acquire the sequence of software instructions; - a generation module (42) configured to generate a first modeling structure of an execution path of the sequence of instructions, the first structure being generated from the sequence of instructions and including a plurality of first groups of data, each associated with a respective software instruction; each first group including an identifier of a previous instruction and an identifier of a following instruction; - a calculation module (44) configured to calculate a second structure for modelling an operation of the sequence of instructions, the second structure comprising a plurality of second data groups, each associated with a respective software instruction; each second group comprising an indicator of possible belonging to a critical chain of instructions, and in the case of belonging to a respective critical chain, an identifier of an initial instruction of said critical chain; the second structure being created from the first structure by successively going through the first groups of the first structure; a respective critical chain corresponding to instructions of a same software function and being computed by solving a subgraph problem with degree constraints, each critical chain corresponding to a subgraph, the number of instructions included in each critical chain being less than or equal to a predefined maximum number, and an optimization parameter being the number of relationships between the instructions of the respective critical chain, said number of relationships corresponding to a number of arcs in the related subgraph; and - a search module (46) configured to search for one or more runtime anomalies from critical chains of instructions determined via the second modeling structure.