WO2023058609A1 - Dispositif et procédé d'analyse de défauts - Google Patents

Dispositif et procédé d'analyse de défauts Download PDF

Info

Publication number
WO2023058609A1
WO2023058609A1 PCT/JP2022/037005 JP2022037005W WO2023058609A1 WO 2023058609 A1 WO2023058609 A1 WO 2023058609A1 JP 2022037005 W JP2022037005 W JP 2022037005W WO 2023058609 A1 WO2023058609 A1 WO 2023058609A1
Authority
WO
WIPO (PCT)
Prior art keywords
analysis
loop
function
loops
point
Prior art date
Application number
PCT/JP2022/037005
Other languages
English (en)
Japanese (ja)
Inventor
真澄 川上
康文 鈴木
和矢 安田
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Publication of WO2023058609A1 publication Critical patent/WO2023058609A1/fr

Links

Images

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

Definitions

  • the present invention relates to a failure analysis device and a failure analysis method.
  • test as a general method for detecting the above-mentioned defects.
  • the inputs and outputs described in the specification or expected by the developer are created as test cases.
  • test cases On the other hand, a large and complex program requires many test cases. More specifically, a huge number of test cases are required to cover all statements (lines/steps), branches, branch conditions, etc. of the program. Generating such a huge number of test cases is not realistic.
  • Patent Document 1 a method of evaluating how a failure propagates in a software component from the specifications of the software component.
  • This method includes a specification information acquisition step in which a computer having a model formal verification function acquires specification information including an input interface specification, an output interface specification, and an internal specification of a software component; A verification step of verifying the software component by the formal verification function according to the changed specification information other than the value; A fault propagation path storing step is executed to associate and store the changed input other than the value and the output that does not meet the output interface specifications.
  • an object of the present invention is to provide a technique that enables efficient failure analysis based on the loop structure of a target program.
  • each loop group With respect to the loop, it is characterized by parallel processing of symbolic execution for each value range of variables defined in the source code, and outputting the location and condition where the defect is detected.
  • FIG. 4 is an explanatory diagram of execution paths and path conditions in the embodiment; It is a figure which shows the example of a screen of the defect analysis apparatus in this embodiment. It is a figure which shows the example of the execution path display screen in this embodiment. It is a figure which shows the example of an analysis concept based on the loop structure in this embodiment. It is a figure which shows the flow example of the failure-analysis method in this embodiment.
  • FIG. 4 is an explanatory diagram showing the concept of failure analysis in a loop structure in this embodiment; It is a figure which shows the source code example in this embodiment. It is a figure which shows the output example in this embodiment.
  • the failure analysis device in this embodiment is an information processing device that enables efficient fault analysis based on the loop structure of the target program.
  • the failure analysis apparatus of the present embodiment particularly includes a symbolic execution engine and an SMT solver, sets a loop including a failure occurrence point as an analysis start point, and sets an analysis end point based on function calling relationships between a plurality of loops.
  • a reverse symbolic run can be performed to identify the function and parameters at which the SMT solver fails.
  • Inputs for such a failure analysis device include program source code, program execution logs, program specifications, and so on.
  • the source code is for the program that is subject to defect analysis.
  • the execution log also includes functions (methods) called during execution of the program. If an exception occurs during execution (for example, division by 0), the execution log ends with a call to the function in which the exception occurred (records a program stop).
  • the failure analysis device presents to the user the statement (source code line/step) of the program in which the exception occurred (for example, the division operation of 0 division) in the function in which the exception occurred, Accepts the specification of the analysis start point.
  • the problem analysis device inquires of the user (developer) to determine the maximum number of loops to be analyzed, with the above-mentioned analysis start point as the starting point and the series of loops connected to the function calling relation as the population. Set as a condition for ending analysis.
  • the analysis start point as a base point
  • a function of a predetermined loop based on the function calling relationship is set as the analysis end point.
  • the failure analysis device starts processing from the analysis start point and performs reverse symbolic execution in the opposite direction to normal program execution, up to the maximum number of loops specified in the analysis end condition.
  • the failure analyzer records execution paths and path conditions.
  • An execution path is a path (a sequence of statements/lines/steps) in a program that connects the analysis end point and the analysis start point, and processing proceeds along the execution path.
  • the execution path also includes function calls.
  • a path condition is a variable condition that causes an exception (for example, division by 0).
  • Variables include local variables within a function and input parameters of a function.
  • the trouble analysis device can assist the user in trouble analysis.
  • FIG. 1 is a diagram showing inputs, outputs, and the overall configuration of a failure analysis device 100 according to this embodiment.
  • the failure analysis device 100 includes a control section 110 , a storage section 120 and an input/output section 180 .
  • control unit 110 is a CPU (Central Processing Unit) that calls and executes a program 121 held in the storage unit 120 and implements necessary functions (function units 111 to 114). It also has a symbolic execution engine 115 and an SMT solver 116 .
  • CPU Central Processing Unit
  • the storage unit 120 is composed of RAM (Random Access Memory), ROM (Read Only Memory), SSD (Solid State Drive), and the like.
  • the storage unit 120 stores a program 121, a function call relation DB 122, analysis start/end point information 123, loop start point information 124, and the like.
  • the program 121 is a program for causing a computer to function as the failure analysis device 100, and includes a description of the procedure of failure analysis processing.
  • the function call relation DB 122 also stores data indicating the relation of which function calls which function between loops, in other words, a call relation graph (a control flow graph representing the call relation between functions). be.
  • the input/output unit 180 is a user interface such as a display, keyboard, and mouse.
  • the input/output unit 180 may further include a communication interface and a read/write device for recording media.
  • Inputs of the failure analysis apparatus 100 include source code 210 , program execution log 220 , and program specification 230 .
  • the source code 210 is source code of functions (methods) that constitute the software program to be analyzed.
  • the program specification 230 describes the names of functions, and the names, types and ranges of input parameter values and return values (return values) of the functions.
  • Program execution log 220 contains a record of function calls during program execution.
  • the program execution log 220 may include the name (identification information) of the called function, input parameter values at the time of calling, and return values at the time of returning from the call.
  • Program execution log 220 may also include exceptions that occurred during program execution. Exceptions include division by zero and violations of input parameter values or return values described in the program specification 230 (values outside the specification range).
  • ⁇ Output of failure analysis device The output of failure analysis apparatus 100 includes execution path 240 and input parameter values 250 .
  • Execution path 240 is the path through the program (a series of statements/lines/steps processed sequentially in source code 210) where the failure occurs.
  • One end of the execution path 240 is a statement/line/step at which an exception (failure) related to a problem occurs, and is referred to as an analysis start point, or simply a start point.
  • a parsing starting point is a statement containing a divide operation, for example, where a divide by 0 occurs.
  • the other end of the execution path 240 is a loop function that directly or indirectly calls the function containing the analysis start point, and is referred to as the analysis end point or entry point.
  • the input parameter value 250 is the input parameter value of the entry point function when a problem occurs.
  • the control unit 110 includes a CPU (Central Processing Unit), and includes a calling relationship generation unit 111, an analysis start point acquisition unit 112, an analysis end point acquisition unit 113, a loop start point acquisition unit 114, a symbol execution engine 115, and An SMT solver 116 is provided.
  • CPU Central Processing Unit
  • the calling relationship generation unit 111 acquires the function calling relationship between each of the multiple loops from the source code 210 and stores it in the function calling relationship DB 122 .
  • the analysis start point acquisition unit 112 accepts specification of the analysis start point from the developer based on the defect occurrence location indicated by the execution log 220, or acquires the analysis start point by analyzing the program execution log 220. (Details of the procedure for acquiring the analysis start point in that case will be described later).
  • the analysis end point acquiring unit 113 sets the maximum number of loops to be the analysis processing target with the above-described analysis start point as the base point and the series of loops connected in the function calling relationship as the population, and the developer accept from
  • a function of a predetermined loop based on the function call relationship is set as the analysis end point.
  • the function that calls the function including the analysis start point is acquired from the function call relation DB 122 and displayed on the display provided in the input/output unit 180 as an entry point candidate.
  • a user selects one or more entry points from the candidates.
  • the analysis end point acquisition unit 113 sets the selected function as an analysis end point (entry point).
  • the loop start point acquisition unit 114 receives designation from the developer, or searches and identifies the loop start point using a predetermined code as a key, for example, for the start point of each loop included in the source code 210 .
  • the symbolic execution engine 115 generates execution paths 240 and path conditions.
  • a path condition is a variable (local variable or input parameter) condition for the execution of the program to be analyzed to pass through the execution path 240 . Details of the execution path 240 and path conditions will be described later.
  • the symbol execution engine 115 starts from the loops that include the analysis start point among the loops included in the source code 210, and ends the analysis according to the caller direction in a series of loops based on the call relationship indicated by the function call relationship DB 122. Towards the point, parallelize symbolic execution for each range of common variables for each loop of the group of loops. As a result, the execution paths 240 and path conditions described above are generated.
  • FIG. 2 is a diagram for explaining execution paths and path conditions according to this embodiment.
  • FIG. 2 includes source code 210 for three functions: function apel10, function bar20, and function foo30.
  • Function apel10 calls function bar20, and function bar20 calls function foo30. The description is continued on the assumption that an exception of division by 0 occurred in function foo30 and function apel10 was designated as the entry point.
  • the program execution log 220 includes a record of calls to function apel10, a record of calls to function bar20, and a record of calls to function foo30, and ends with a record of occurrence of 0 division.
  • the analysis start point acquisition unit 112 By analyzing the program execution log 220, the analysis start point acquisition unit 112 detects that a division by 0 exception has occurred in the function foo30. Since line 3 of function foo is the only statement/line that includes a division operation, analysis starting point acquisition unit 112 sets the starting point to line 3 of function foo30. That is, the analysis start point acquiring unit 112 acquires the statement of the program in which the exception occurred from the execution log as the analysis start point.
  • a path condition is a condition/constraint that causes an exception.
  • the symbolic execution engine 115 searches through the program (source code 210) in a direction opposite to normal (forward) execution until an entry point is reached (also referred to as reverse symbolic execution). If there are multiple entry points, symbolic execution engine 115 searches until any one entry point is reached.
  • the symbolic execution engine 115 starts searching from line 3 of function foo30 and reaches line 1 (top line).
  • the execution path at this point is from line 3 to line 1 of function foo30.
  • the symbolic execution engine 115 determines that the function foo30 was called with the second input parameter b being 0, and searches for a statement that calls the function foo30.
  • the statement that calls function foo30 is line 3 of function bar20, and symbolic execution engine 115 continues the search from that line.
  • functions apel10, function bar20, and function foo30 each have variables a, b, and c with the same name, these are local variables of each function and are different variables.
  • the symbolic execution engine 115 starts searching from line 3 of function bar20 and reaches line 1.
  • the execution path at this point is line 3 to line 1 of function foo30 and line 3 to line 1 of function bar20.
  • the symbolic execution engine 115 determines that the function bar20 was called with the same value for the first parameter and the second input parameter, and searches for a statement that calls the function bar20.
  • the statement that calls function bar20 is line 3 of function apel10, and symbolic execution engine 115 continues the search from that line.
  • the symbolic execution engine 115 starts searching from line 3 of function apel10 and reaches line 1. Since the function apel10 is the analysis end point, the search ends here.
  • the path conditions include the input parameter value conditions for the entry point (analysis end point).
  • the symbolic execution engine 115 displays the execution path on the display provided in the input/output unit 180 (outputs the execution path). The user can understand how and under what conditions processing progresses and problems occur in the program. As a result, problems can be found and programs can be corrected.
  • the SMT solver 116 provides input parameter values 250 (input values of entry points (analysis end points) that satisfy path conditions), and users can use these values to test modified programs.
  • function apelA (not shown) calls bar(d+1, d ⁇ 2) and function bar20 on line 5.
  • Symbolic execution engine 115 searches up to line 5 of function apelA for the path condition.
  • the symbolic execution engine 115 may record each execution path and path condition. In such a case, there are multiple execution paths and multiple path conditions. In other words, it turns out that an exception occurs at the same point (analysis start point) under different conditions.
  • the search may result in multiple analysis end points, execution paths, and path conditions.
  • the symbolic execution engine 115 thus calculates and identifies execution paths and path conditions.
  • FIG. 3 is a configuration diagram of a screen 400 of the failure analysis device 100 according to this embodiment.
  • An analysis start point information display area 411 , an analysis end point information display area 412 , and an analysis result information display area 413 are arranged in the center on the left and right of the screen 400 from the top.
  • the analysis start point acquisition unit 112 sets the analysis start point
  • the function name including the analysis start point, the number of lines at the analysis start point, the condition under which an exception occurs, etc. are displayed in the analysis start point information display area 411 .
  • the information display area 411 displays a message prompting the user to select one of a plurality of candidates for the analysis start point.
  • the user presses a "specify" button 421 to select one analysis start point from a screen (not shown) displaying candidates for analysis start points.
  • the analysis start point acquisition unit 112 sets the selected analysis start point candidate as an analysis start point.
  • a message prompting selection of an analysis end point is displayed in the analysis end point information display area 412 .
  • the analysis end point acquiring unit 113 sets the selected candidate for the analysis end point as the analysis end point and displays it in the information display area 412 . When multiple selections are made, multiple analysis end points are displayed in the information display area 412 .
  • the symbolic execution engine 115 searches for an execution path, and the analysis end point and the path conditions related to the input parameters of the analysis end point are displayed in the analysis result information display area 413 . to be displayed. If there are multiple analysis end points or path conditions related to multiple input parameters, the information display area 413 displays multiple analysis end points and path conditions.
  • FIG. 4 is a configuration diagram of an execution path display screen 430 according to this embodiment.
  • the execution path display screen 430 displays the source codes of the function apel10, the function bar20, and the function foo30 through which the execution paths pass.
  • path conditions corresponding to statements are displayed as program comments.
  • start point, end point, and path conditions are displayed in the form of program comments, but other forms may be used as long as the correspondence between statements/lines can be grasped.
  • FIG. 6 is a flowchart of defect analysis processing according to the present embodiment.
  • FIG. 7 is an explanatory diagram showing the concept of failure analysis in the loop structure in this embodiment.
  • control unit 110 reads the input source code 210 (FIG. 8), program execution log 220, and program specification 230.
  • the calling relationship generator 111 extracts the function calling relationships from the read source code 210 (FIG. 8) and stores them in the function calling relationship DB 122.
  • the analysis start point acquisition unit 112 acquires and sets the analysis start point from the program execution log 220.
  • step s12 the analysis end point acquiring unit 113 inquires of the user to acquire and set an analysis end condition.
  • FIG. 7 shows an example in which the user sets the maximum number of loops as the processing upper limit to "200" and this is accepted.
  • the symbolic execution engine 115 starts searching (reverse symbolic execution) for each series of loops according to the function calling relationship from the loop at the analysis start point.
  • the reverse symbolic execution flow itself is substantially similar to that of FIGS. 2-4, except that the source code of FIG. However, it is characteristic that each time the source code shown in FIG. 8 is repeatedly executed, that is, each time the loop is executed, a search is performed to confirm whether the value of the common variable S exceeds the specified value range.
  • step 14 the symbol execution engine 115 determines whether the analysis termination condition has been reached. That is, it is determined whether or not the number of times of loop processing exceeds the upper limit of "200". As a result of this determination, if the number of loop processing times does not exceed the upper limit of “200” (s14: N), the symbol execution engine 115 determines in step s15 that the value of the common variable S in the loop is within the specified value range. determine if it is suitable.
  • step s15: Y the process transitions to s13.
  • step s15: N the symbolic execution engine 115 records the execution path and the path condition in step s16, and executes the process. Return to s13.
  • step s14 the determination of the value of the common variable and the recording of the execution path and path condition are repeated in each loop.
  • the symbolic execution engine 115 performs symbolic execution in parallel for each range of variables defined in the source code, and outputs the locations and conditions where defects are detected. Also, in symbolic execution and defect detection for each loop, if it is detected that the specified specification of variables is satisfied at the start point of the loop, the analysis for the loop is terminated.
  • control unit performs the symbolic execution and the fault detection for each of the loops toward the end point of the analysis according to the caller direction from the starting point, when detecting the fault: If it is detected that the variable satisfies a predetermined specification at the start of the loop, the analysis may be terminated with respect to the loop.
  • the storage unit holds information on the maximum number of loops to be processed as the information on the end of the analysis, and the control unit stores information from the starting point in the caller direction. Accordingly, in the symbol execution and the detection of the defect in each of the loops toward the end point of the analysis, the processing is terminated when the loop for which the analysis has ended reaches the maximum number of loops. Yes, you can.
  • the control unit uses a symbolic execution engine that outputs an execution path by performing reverse symbolic execution from the start point to the end point of the analysis, so that the failure is detected. calculating a path condition that is a condition that occurs, and using a predetermined solver when detecting and outputting the location and condition of the defect, the condition of the input parameter value of the function that is the end point of the analysis that satisfies the path condition; Alternatively, it may output an input parameter value of a function serving as an end point of the analysis that satisfies the path condition.
  • the information processing device performs the symbol execution and the fault detection for each of the loops toward the end point of the analysis according to the calling source direction from the starting point.
  • the analysis may be terminated for the loop when it is detected that the variable satisfies a predetermined specification at the start of the loop.
  • the information processing device holds information on the maximum number of loops to be processed as information on the end of the analysis in the storage unit, and , in the symbolic execution and the defect detection for each of the loops, the processing may be terminated when the number of loops for which the analysis has been completed reaches the maximum number of loops.
  • the information processing apparatus uses a symbolic execution engine that outputs an execution path by performing reverse symbolic execution from the start point to the end point of the analysis. is calculated, and when detecting and outputting the location and condition of the defect, a predetermined solver is used to determine the input parameter value of the function that is the end point of the analysis that satisfies the path condition.
  • a predetermined solver is used to determine the input parameter value of the function that is the end point of the analysis that satisfies the path condition.
  • an input parameter value of a function serving as an end point of the analysis that satisfies the path condition may be output.
  • Control unit 111 Calling relation generation unit 112 Analysis start point acquisition unit 113 Analysis end point acquisition unit 114 Loop start point acquisition unit 115 Symbolic execution engine 116 SMT solver (solver) 120 Storage unit 121 Program 122 Function call relation DB 123 analysis start/end point information 124 loop start point information 180 input/output unit 210 source code (program) 220 program execution log (execution log) 230 Program specification 240 Execution path 250 Input parameter value

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)

Abstract

Dispositif d'analyse de défauts 100 configuré de façon à comprendre : une unité de stockage 120 qui stocke des informations concernant l'initiation et l'achèvement d'une analyse, l'initiation de chaque boucle, et les relations d'appel de fonction dans le code source de logiciel à analyser ; et une unité de commande 110 qui définit la boucle comprenant le point d'intitiation d'analyse parmi lesdites boucles en tant qu'origine, et tout en progressant vers le point d'achèvement d'analyse, effectue une exécution symbolique en parallèle pour chaque plage variable stipulée par le code source pour chaque boucle dudit groupe de boucles selon la direction de la source d'appel dans une série de groupes de boucles dans la relation d'appel de fonction, et délivre en sortie la zone où un défaut a été détecté.
PCT/JP2022/037005 2021-10-08 2022-10-03 Dispositif et procédé d'analyse de défauts WO2023058609A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021-166472 2021-10-08
JP2021166472A JP2023056953A (ja) 2021-10-08 2021-10-08 不具合解析装置及び不具合解析方法

Publications (1)

Publication Number Publication Date
WO2023058609A1 true WO2023058609A1 (fr) 2023-04-13

Family

ID=85804285

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/037005 WO2023058609A1 (fr) 2021-10-08 2022-10-03 Dispositif et procédé d'analyse de défauts

Country Status (2)

Country Link
JP (1) JP2023056953A (fr)
WO (1) WO2023058609A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012099107A (ja) * 2010-10-29 2012-05-24 Fujitsu Ltd 知的且つ動的なロードバランシングによる、分散コンピューティング環境におけるソフトウェアの解析の効率的な並列化の手法
JP2018190219A (ja) * 2017-05-09 2018-11-29 株式会社日立製作所 ソフトウェア仕様分析装置、及びソフトウェア仕様分析方法
US20210019250A1 (en) * 2019-07-16 2021-01-21 Baidu Online Network Technology (Beijing) Co., Ltd. Method, device and computer-readable storage medium for guiding symbolic execution

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012099107A (ja) * 2010-10-29 2012-05-24 Fujitsu Ltd 知的且つ動的なロードバランシングによる、分散コンピューティング環境におけるソフトウェアの解析の効率的な並列化の手法
JP2018190219A (ja) * 2017-05-09 2018-11-29 株式会社日立製作所 ソフトウェア仕様分析装置、及びソフトウェア仕様分析方法
US20210019250A1 (en) * 2019-07-16 2021-01-21 Baidu Online Network Technology (Beijing) Co., Ltd. Method, device and computer-readable storage medium for guiding symbolic execution

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JIBIKI HISASHI, HARADA KENICHI: "A Method for Generation of Declarative Specification from a Program, and Application to Source Code Reading Support.", PROCEEDINGS OF THE 50TH ANNUAL CONFERENCE OF THE INFORMATION PROCESSING SOCIETY OF JAPAN; SOFTWARE ENGINEERING; MARCH 15 TO 17, 1995, INFORMATION PROCESSING SOCIETY OF JAPAN, JP, 15 March 1995 (1995-03-15) - 17 March 1995 (1995-03-17), JP, pages 5 - 5-288, XP009547164 *

Also Published As

Publication number Publication date
JP2023056953A (ja) 2023-04-20

Similar Documents

Publication Publication Date Title
US6173440B1 (en) Method and apparatus for debugging, verifying and validating computer software
Zhang et al. Locating faults through automated predicate switching
US20080126867A1 (en) Method and system for selective regression testing
CN111026601A (zh) Java应用系统的监控方法、装置、电子设备及存储介质
Calvagna et al. A formal logic approach to constrained combinatorial testing
CN109255240B (zh) 一种漏洞处理方法和装置
CN108009085B (zh) 渠道包测试方法
Ribeiro et al. Evaluating data-flow coverage in spectrum-based fault localization
US20120216023A1 (en) Processor testing
CN111797006A (zh) 一种线程测试的方法、装置、设备以及存储介质
CN106294109B (zh) 获取缺陷代码的方法及装置
WO2023058609A1 (fr) Dispositif et procédé d'analyse de défauts
Wong et al. An execution slice and inter-block data dependency-based approach for fault localization
CN109101355B (zh) 一种提取错误现场特征测试激励的处理器调试方法
CN111984524A (zh) 故障注入方法、故障模拟方法、故障注入装置及存储介质
CN111666200A (zh) 一种pc软件冷启动耗时的测试方法及终端
CN115659345A (zh) 一种代码漏洞的修复方法、装置、可读介质及电子设备
CN115168131A (zh) 一种故障注入的cpu异常功能验证方法
JP4957521B2 (ja) ソフトウェア部分テストシステム、それに用いる方法およびプログラム
WO2022044376A1 (fr) Dispositif d'analyse de défaillance, programme, et procédé d'analyse de défaillance
WO2023058611A1 (fr) Appareil d'analyse de défaillance de logiciel et procédé d'analyse de défaillance de logiciel
CN114138669A (zh) 一种基于函数级选择符号化混合执行的软件自动测试方法
JP4253056B2 (ja) テスト装置、テストケース評価装置、およびテスト結果解析装置
Zhyhulin et al. Combined method of prioritization and automation of software regression testing
Andrés et al. Formal correctness of a passive testing approach for timed systems

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22878478

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE