WO2022218549A1 - Apparatus and method for generating requirement specifications - Google Patents
Apparatus and method for generating requirement specifications Download PDFInfo
- Publication number
- WO2022218549A1 WO2022218549A1 PCT/EP2021/059959 EP2021059959W WO2022218549A1 WO 2022218549 A1 WO2022218549 A1 WO 2022218549A1 EP 2021059959 W EP2021059959 W EP 2021059959W WO 2022218549 A1 WO2022218549 A1 WO 2022218549A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- term
- formula
- name
- expressed
- real
- Prior art date
Links
- 238000000034 method Methods 0.000 title description 14
- 238000012545 processing Methods 0.000 claims abstract description 57
- 230000002123 temporal effect Effects 0.000 claims abstract description 51
- 230000009466 transformation Effects 0.000 claims abstract description 7
- 238000003672 processing method Methods 0.000 claims description 10
- 238000004891 communication Methods 0.000 claims description 6
- 230000001131 transforming effect Effects 0.000 claims description 2
- 238000013519 translation Methods 0.000 description 14
- 238000012795 verification Methods 0.000 description 6
- 238000013459 approach Methods 0.000 description 5
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 238000003491 array Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000011002 quantification Methods 0.000 description 1
- 238000007670 refining Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 239000011800 void material Substances 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/20—Natural language analysis
- G06F40/205—Parsing
- G06F40/211—Syntactic parsing, e.g. based on context-free grammar [CFG] or unification grammars
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
- G06F40/12—Use of codes for handling textual entities
- G06F40/151—Transformation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/20—Natural language analysis
- G06F40/205—Parsing
- G06F40/226—Validation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/40—Processing or translation of natural language
- G06F40/55—Rule-based translation
- G06F40/56—Natural language generation
Definitions
- the present disclosure relates to information processing technology. More specifically, the present disclosure relates to a data processing apparatus and method for generating real time system requirement specifications.
- a first known approach puts requirements engineering at the level of automata or event systems, that are translated to code for simulation with computer assistance.
- the second known approach one supports the user in defining and refining a graphical form of precondition- postcondition constraints and produces elements for formal verification or testing. Both of those systems are a clear progress by comparison with classical natural-language management of requirements, because they reduce many sources of errors. But they do so at the expense of productivity and perfect intelligibility for lack of a purely natural- language interface.
- a data processing apparatus comprising a processing entity, for instance, one or more processors, configured to parse one or more real-time system requirement specifications expressed in a pseudo-natural language.
- the processing entity is further configured to transform, based on a set of transformation rules defined by a formal grammar, the one or more real time system requirement specifications expressed in the pseudo-natural language into one or more real-time system requirement specifications expressed using a temporal logic.
- the processing entity is configured to perform a consistency check of the one or more real-time system requirement specifications expressed using the temporal logic based on one or more formal models and generate a result of the consistency check expressed using the temporal logic.
- the processing entity is further configured to translate the result of the consistency check expressed using the temporal logic back into a result of the consistency check expressed in the pseudo-natural language.
- the formal grammar comprises for at least one of the one or more real-time system requirement statements expressed using the temporal logic at least two real-time system requirement statements expressed in the pseudo-natural language. In other words, redundant mapping is provided.
- the one or more real-time system requirement specifications comply with Montague semantics (also referred to as Montague grammar).
- Montague grammar is an approach to natural language semantics based on mathematical logic, especially higher-order predicate logic and lambda calculus, and makes use of the notions of intentional logic.
- the data processing apparatus further comprises a user interface and/or a communication interface configured to receive the one or more real-time system requirement specifications expressed in the pseudo-natural language and/or to output the result of the consistency check expressed in the pseudo-natural language.
- the temporal logic is a linear temporal logic, LTL.
- a computer-implemented data processing method comprises the steps of: parsing one or more real-time system requirement specifications expressed in a pseudo natural language; transforming, based on a set of transformation rules defined by a formal grammar, the one or more real-time system requirement specifications expressed in the pseudo-natural language into one or more real-time system requirement specifications expressed using a temporal logic; performing a consistency check of the one or more real-time system requirement specifications expressed using the temporal logic based on one or more formal models; generating a result of the consistency check expressed using the temporal logic; and translating the result of the consistency check expressed using the temporal logic back into a result of the consistency check expressed in the pseudo-natural language.
- the formal grammar comprises for at least one of the one or more real-time system requirement statements expressed using the temporal logic at least two real-time system requirement statements expressed in the pseudo-natural language.
- the one or more real-time system requirement specifications comply with Montague semantics.
- the computer- implemented data processing method further comprises the steps of receiving the one or more real-time system requirement specifications expressed in the pseudo-natural language, for instance, from a user and/or outputting the result of the consistency check expressed in the pseudo-natural language, for instance, to a user.
- the temporal logic is a linear temporal logic, LTL.
- a computer program product comprising a computer-readable storage medium for storing program code which causes a computer or a processor to perform the type matching method according to the second aspect, when the program code is executed by the computer or the processor.
- Fig. 1 shows a schematic diagram of a data processing apparatus according to an embodiment
- Fig. 2 is a flow diagram illustrating a data processing method according to an embodiment
- Fig. 3 is a table illustrating the differences between natural language requirements and temporal logic requirements.
- Figs. 4a and 4b show examples for the compliance of the grammar implemented by a data processing apparatus according to an embodiment with Montague semantics.
- a disclosure in connection with a described method may also hold true for a corresponding device or system configured to perform the method and vice versa.
- a corresponding device may include one or a plurality of units, e.g. functional units, to perform the described one or plurality of method steps (e.g. one unit performing the one or plurality of steps, or a plurality of units each performing one or more of the plurality of steps), even if such one or more units are not explicitly described or illustrated in the figures.
- a specific apparatus is described based on one or a plurality of units, e.g.
- a corresponding method may include one step to perform the functionality of the one or plurality of units (e.g. one step performing the functionality of the one or plurality of units, or a plurality of steps each performing the functionality of one or more of the plurality of units), even if such one or plurality of steps are not explicitly described or illustrated in the figures. Further, it is understood that the features of the various exemplary embodiments and/or aspects described herein may be combined with each other, unless specifically noted otherwise.
- Figure 1 shows a schematic diagram of a data processing apparatus 100 for generating real-time system requirement specifications.
- the data processing apparatus 100 may comprise a desktop PC or workstation 100 operated by a user 110.
- the data processing apparatus 100 comprises a processing entity 101, for instance, in form of processing circuitry 101.
- the processing entity 101 of the data processing apparatus 100 may be implemented in hardware and/or software.
- the hardware may comprise digital circuitry, or both analog and digital circuitry.
- Digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field- programmable arrays (FPGAs), digital signal processors (DSPs), or general-purpose processors.
- ASICs application-specific integrated circuits
- FPGAs field- programmable arrays
- DSPs digital signal processors
- the data processing apparatus 100 may further comprise a user interface and/or a communication interface 103 for interacting with the user 110 or other electronic systems, such as, by way of example, an automation control system 130, and a memory 105 configured to store data and executable program code which, when executed by the processing entity 101 causes data processing apparatus 100 to perform the functions, operations and methods described herein.
- a user interface and/or a communication interface 103 for interacting with the user 110 or other electronic systems, such as, by way of example, an automation control system 130, and a memory 105 configured to store data and executable program code which, when executed by the processing entity 101 causes data processing apparatus 100 to perform the functions, operations and methods described herein.
- the processing entity 101 of the data processing apparatus 100 is configured to parse one or more real-time system requirement specifications 111 expressed in a pseudo-natural language (see block 101a of figure 1 and step 201 of figure 2).
- Two exemplary real-time system requirement specifications 111 expressed in pseudo-English are illustrated in figure 1, namely (a) "if ERROR is false then ultimately SPEED is SYCHRONOUS" and (b) "The drift between MASTER_CLOCK and SLAVE_CLOCK is always bounded by threshold D".
- these real-time system requirement specifications 111 may be generated by the user 110 using a user interface, such as a keyboard or a mouse, an a text editor of the data processing apparatus 100.
- the processing entity 101 of the data processing apparatus 100 is further configured to transform, based on a set of transformation rules (also referred to as translation rules) defined by a formal grammar, the one or more real time system requirement specifications 111 expressed in the pseudo-natural language into one or more real-time system requirement specifications 121 expressed using a temporal logic.
- the temporal logic may be a linear temporal logic, LTL.
- the processing entity 101 of the data processing apparatus 100 is further configured to perform a consistency check of the one or more real-time system requirement specifications 121 expressed using the temporal logic based on one or more formal models 120 and to generate a result of the consistency check expressed using the temporal logic.
- the one or more formal models 120 may be provided by an external entity via the communication interface 103 to the data processing apparatus.
- the data processing apparatus 100 may implement a model checking tool for performing the consistency check of the one or more real-time system requirement specifications 121 expressed using the temporal logic based on one or more formal models 120.
- any of the formal models describes the intended real time system in its components and internal or external behaviour.
- the user 110 may request more and more requirement specifications to be checked to increase confidence in the intended real-time system. If a consistency error is found, the user 110 may modify the requirement specifications, if they are assumed to be imperfect, or modify the model if confidence in the requirement specifications is high.
- the processing entity 101 of the data processing apparatus 100 is further configured to translate the result of the consistency check expressed using the temporal logic back into the pseudo-natural language, i.e. a result of the consistency check expressed in the pseudo-natural language.
- the result may be that the two exemplary real-time system requirement specifications 111 expressed pseudo-English, namely (a) "if ERROR is false then ultimately SPEED is SYCHRONOUS" and (b) "The drift between MASTER_CLOCK and SLAVE_CLOCK is always bounded by threshold D", are consistent and valid.
- the data processing apparatus 100 may display this result to the user 110.
- the result of the consistency check is that one of the two exemplary real-time system requirement specifications 111 expressed in pseudo-English, for example the second one (b) "The drift between MASTER_CLOCK and SLAVE_CLOCK is always bounded by threshold D" is not valid for the given model, and a sufficient cause of invalidity is a counter-example such as F ⁇ 10 ⁇ (abs(MASTER_CLOCK-SLAVE_CLOCK) > D) when expressed in temporal logic, then the data processing apparatus 100 may translate this cause back to pseudo-English such as to make it readily understandable to the user 110 in the following form: “eventually the drift between MASTER_CLOCK and SLAVE_CLOCK shall not be bounded by D within 10 milliseconds.”
- Figure 3 is a table illustrating the differences between pseudo-natural language requirements and temporal logic requirements as implemented by a data processing apparatus according to an embodiment. The differences illustrate the tension between logical precision and non-ambiguity on one side, and simplicity and clarity on the other side, for which embodiments disclosed herein find a good balance.
- the formal grammar described above comprises for several of the real-time system requirement statements expressed using the temporal logic at least two real-time system requirement statements expressed in the pseudo-natural language.
- the data processing apparatus 100 may be configured to translate, i.e. map a given requirement statement expressed using the temporal logic into at least two (equivalent) pseudo-language requirement statements.
- Figures 4a and 4b show examples for the compliance of how the translation rules defined by the grammar described above and implemented by the data processing apparatus 100 according to an embodiment comply with Montague semantics (also referred to as Montague grammar).
- Montague grammar is an approach to natural language semantics based on mathematical logic, especially higher-order predicate logic and lambda calculus, and makes use of the notions of intentional logic.
- Figures 4a and 4b summarize a verification that provides additional confidence in the translation rules in the direction of English to LTL implemented by embodiments disclosed herein. As English is not a formal language, there is no unanimous and standard mathematical definition of sentence meanings as it exists for a programming language for example.
- Montague semantics does provide such a definition for a subset of the English language and a subset of Montague semantics has been used to validate some of the translation rules of pseudo-English to LTL implemented by embodiments disclosed herein.
- the verification is done in 3 steps that correspond to the 3 levels in syntax of the LTL target logic: the lower level is that of atomic statements that are either the name of a variable, the name of a formula or a comparison expression between two variables.
- the middle level is a boolean combination (and, or, implies etc.) of two such atomic statements.
- the upper level is the application of a temporal operation (within, until, ultimately etc.) to formulas of the lower levels.
- the translation rules implemented by embodiments disclosed herein confirm that what Montague semantics would conclude about their mathematical meaning.
- embodiments disclosed herein allow translating a subset of English-language for describing requirements directly to temporal logic suitable for automated formal verification of system models.
- embodiments disclosed herein combine the flexible, intuitive and productive use of English sentences with non- ambiguous translation to temporal logic.
- embodiments disclosed herein allow the reverse translation to make the output messages of formal verification clearly intelligible, thus reducing a common problem with error messages: either they are clear but ad-hoc (not formally linked to the verification formulas) or they are precise but cryptic (using explicit logical formulas).
- the reverse translation implemented by embodiments disclosed herein guarantees messages that are bot precise and intelligible because they are the English-translation of temporal logic formulas using the same correspondence as the forward translation.
- embodiments disclosed herein provide multiple input-English forms for the same temporal logic output, allowing multiple synonyms for the same requirement sentence. This frees the user of the memorization effort needed when learning a formal- or computer language.
- the disclosed system, apparatus, and method may be implemented in other manners.
- the described embodiment of an apparatus is merely exemplary.
- the unit division is merely logical function division and may be another division in an actual implementation.
- a plurality of units or components may be combined or integrated into another system, or some features may be ignored or not performed.
- the displayed or discussed mutual couplings or direct couplings or communication connections may be implemented by using some interfaces.
- the indirect couplings or communication connections between the apparatuses or units may be implemented in electronic, mechanical, or other forms.
- the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one position, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.
- functional units in the embodiments of the invention may be integrated into one processing unit, or each of the units may exist alone physically, or two or more units are integrated into one unit.
Abstract
A data processing apparatus (100) comprising a processing entity (101) is disclosed. The processing entity (101) is configured to parse one or more real-time system requirement specifications (111) expressed in a pseudo-natural language and transform, based on a set of transformation rules defined by a formal grammar, the one or more real-time system requirement specifications (111) into one or more real-time system requirement specifications (121) expressed using a temporal logic. Moreover, the processing entity (101) is configured to perform a consistency check of the one or more real-time system requirement specifications (121) expressed using the temporal logic based on one or more formal models (120) and generate a result of the consistency check expressed using the temporal logic. The processing entity (101) is further configured to translate the result of the consistency check expressed using the temporal logic back into a result of the consistency check expressed in the pseudo-natural language.
Description
Apparatus and method for generating requirement specifications
TECHNICAL FIELD
The present disclosure relates to information processing technology. More specifically, the present disclosure relates to a data processing apparatus and method for generating real time system requirement specifications.
BACKGROUND
Creating system specification requirements for real-time critical systems is a challenging task. A lot of conventional systems for this task have favored productivity at the expense of mathematical accuracy in that these conventional systems support the maintenance of requirements written in a natural language (such as English) or a pseudo-language version thereof without a direct translation to code or formal logic. This type of approach is prone to human errors in the design of the specification requirements, because the specification requirements may by, for instance, incomplete, ill-defined, or incoherent, or in their translation to systems as program code or systems formal descriptions using temporal logic.
There have been a few attempts to automate the task of creating system specification requirements and, thereby, reduce the possibility of human errors. A first known approach puts requirements engineering at the level of automata or event systems, that are translated to code for simulation with computer assistance. The second known approach one supports the user in defining and refining a graphical form of precondition- postcondition constraints and produces elements for formal verification or testing. Both of those systems are a clear progress by comparison with classical natural-language management of requirements, because they reduce many sources of errors. But they do so at the expense of productivity and perfect intelligibility for lack of a purely natural- language interface.
SUMMARY
It is an objective of the present disclosure to provide an improved data processing apparatus and method for generating real-time system requirement specifications.
The foregoing and other objectives are achieved by the subject matter of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.
According to a first aspect a data processing apparatus is provided. The data processing apparatus comprises a processing entity, for instance, one or more processors, configured to parse one or more real-time system requirement specifications expressed in a pseudo-natural language. The processing entity is further configured to transform, based on a set of transformation rules defined by a formal grammar, the one or more real time system requirement specifications expressed in the pseudo-natural language into one or more real-time system requirement specifications expressed using a temporal logic. Moreover, the processing entity is configured to perform a consistency check of the one or more real-time system requirement specifications expressed using the temporal logic based on one or more formal models and generate a result of the consistency check expressed using the temporal logic. The processing entity is further configured to translate the result of the consistency check expressed using the temporal logic back into a result of the consistency check expressed in the pseudo-natural language. Thus, advantageously, an improved data processing apparatus for generating and translating real-time system requirement specifications in a bidirectional way is provided.
In a further possible implementation form of the first aspect, the formal grammar comprises for at least one of the one or more real-time system requirement statements expressed using the temporal logic at least two real-time system requirement statements expressed in the pseudo-natural language. In other words, redundant mapping is provided.
In a further possible implementation form of the first aspect, the one or more real-time system requirement specifications comply with Montague semantics (also referred to as Montague grammar). Montague grammar is an approach to natural language semantics based on mathematical logic, especially higher-order predicate logic and lambda calculus, and makes use of the notions of intentional logic.
In a further possible implementation form of the first aspect, the data processing apparatus further comprises a user interface and/or a communication interface configured to receive the one or more real-time system requirement specifications expressed in the
pseudo-natural language and/or to output the result of the consistency check expressed in the pseudo-natural language.
In a further possible implementation form of the first aspect, the temporal logic is a linear temporal logic, LTL.
According to a second aspect, a computer-implemented data processing method is provided. The computer-implemented data processing method comprises the steps of: parsing one or more real-time system requirement specifications expressed in a pseudo natural language; transforming, based on a set of transformation rules defined by a formal grammar, the one or more real-time system requirement specifications expressed in the pseudo-natural language into one or more real-time system requirement specifications expressed using a temporal logic; performing a consistency check of the one or more real-time system requirement specifications expressed using the temporal logic based on one or more formal models; generating a result of the consistency check expressed using the temporal logic; and translating the result of the consistency check expressed using the temporal logic back into a result of the consistency check expressed in the pseudo-natural language.
In a further possible implementation form of the second aspect, the formal grammar comprises for at least one of the one or more real-time system requirement statements expressed using the temporal logic at least two real-time system requirement statements expressed in the pseudo-natural language.
In a further possible implementation form of the second aspect, the one or more real-time system requirement specifications comply with Montague semantics.
In a further possible implementation form of the second aspect, the computer- implemented data processing method further comprises the steps of receiving the one or more real-time system requirement specifications expressed in the pseudo-natural
language, for instance, from a user and/or outputting the result of the consistency check expressed in the pseudo-natural language, for instance, to a user.
In a further possible implementation form of the second aspect, the temporal logic is a linear temporal logic, LTL.
According to a third aspect a computer program product is provided, comprising a computer-readable storage medium for storing program code which causes a computer or a processor to perform the type matching method according to the second aspect, when the program code is executed by the computer or the processor.
Details of one or more embodiments are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description, drawings, and claims.
BRIEF DESCRIPTION OF THE DRAWINGS
In the following, embodiments of the present disclosure are described in more detail with reference to the attached figures and drawings, in which:
Fig. 1 shows a schematic diagram of a data processing apparatus according to an embodiment;
Fig. 2 is a flow diagram illustrating a data processing method according to an embodiment;
Fig. 3 is a table illustrating the differences between natural language requirements and temporal logic requirements; and
Figs. 4a and 4b show examples for the compliance of the grammar implemented by a data processing apparatus according to an embodiment with Montague semantics.
In the following, identical reference signs refer to identical or at least functionally equivalent features.
DETAILED DESCRIPTION OF THE EMBODIMENTS
In the following description, reference is made to the accompanying figures, which form part of the disclosure, and which show, by way of illustration, specific aspects of embodiments of the present disclosure or specific aspects in which embodiments of the present disclosure may be used. It is understood that embodiments of the present disclosure may be used in other aspects and comprise structural or logical changes not depicted in the figures. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims.
For instance, it is to be understood that a disclosure in connection with a described method may also hold true for a corresponding device or system configured to perform the method and vice versa. For example, if one or a plurality of specific method steps are described, a corresponding device may include one or a plurality of units, e.g. functional units, to perform the described one or plurality of method steps (e.g. one unit performing the one or plurality of steps, or a plurality of units each performing one or more of the plurality of steps), even if such one or more units are not explicitly described or illustrated in the figures. On the other hand, for example, if a specific apparatus is described based on one or a plurality of units, e.g. functional units, a corresponding method may include one step to perform the functionality of the one or plurality of units (e.g. one step performing the functionality of the one or plurality of units, or a plurality of steps each performing the functionality of one or more of the plurality of units), even if such one or plurality of steps are not explicitly described or illustrated in the figures. Further, it is understood that the features of the various exemplary embodiments and/or aspects described herein may be combined with each other, unless specifically noted otherwise.
Figure 1 shows a schematic diagram of a data processing apparatus 100 for generating real-time system requirement specifications. In an embodiment, the data processing apparatus 100 may comprise a desktop PC or workstation 100 operated by a user 110. As illustrated in figure 1, the data processing apparatus 100 comprises a processing entity 101, for instance, in form of processing circuitry 101. The processing entity 101 of the data processing apparatus 100 may be implemented in hardware and/or software. The hardware may comprise digital circuitry, or both analog and digital circuitry. Digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field- programmable arrays (FPGAs), digital signal processors (DSPs), or general-purpose processors. As illustrated in figure 1, the data processing apparatus 100 may further comprise a user interface and/or a communication interface 103 for interacting with the
user 110 or other electronic systems, such as, by way of example, an automation control system 130, and a memory 105 configured to store data and executable program code which, when executed by the processing entity 101 causes data processing apparatus 100 to perform the functions, operations and methods described herein.
As will be described in more detail below and under further reference to figure 2, which shows a data processing method 200 implemented by the data processing apparatus 100, the processing entity 101 of the data processing apparatus 100 is configured to parse one or more real-time system requirement specifications 111 expressed in a pseudo-natural language (see block 101a of figure 1 and step 201 of figure 2). Two exemplary real-time system requirement specifications 111 expressed in pseudo-English are illustrated in figure 1, namely (a) "if ERROR is false then ultimately SPEED is SYCHRONOUS" and (b) "The drift between MASTER_CLOCK and SLAVE_CLOCK is always bounded by threshold D". In an embodiment, these real-time system requirement specifications 111 may be generated by the user 110 using a user interface, such as a keyboard or a mouse, an a text editor of the data processing apparatus 100.
As illustrated by step 203 of figure 2, the processing entity 101 of the data processing apparatus 100 is further configured to transform, based on a set of transformation rules (also referred to as translation rules) defined by a formal grammar, the one or more real time system requirement specifications 111 expressed in the pseudo-natural language into one or more real-time system requirement specifications 121 expressed using a temporal logic. In an embodiment, the temporal logic may be a linear temporal logic, LTL.
In the exemplary embodiment shown in figure 1, the two exemplary real-time system requirement specifications 111 expressed pseudo-English, namely (a) "if ERROR is false then ultimately SPEED is SYCHRONOUS" and (b) "The drift between MASTER_CLOCK and SLAVE_CLOCK is always bounded by threshold D", are translated by the processing entity 101 into two formal logic real-time system requirement specifications 121, namely (a) "!(ERROR) -> F{infinity}(SPEED == SYCHRONOUS)" and (b)
"G{infinity}((abs((MASTER_CLOCK-SLAVE_CLOCK))) <= D)". An exemplary embodiment of a formal grammar defining the set of transformation rules implemented by the data processing apparatus 100 will be described in more detail further below.
As illustrated by block 101b of figure 1 and steps 205 and 207 of figure 2, the processing entity 101 of the data processing apparatus 100 is further configured to perform a
consistency check of the one or more real-time system requirement specifications 121 expressed using the temporal logic based on one or more formal models 120 and to generate a result of the consistency check expressed using the temporal logic. In an embodiment, the one or more formal models 120 may be provided by an external entity via the communication interface 103 to the data processing apparatus. As illustrated in figure 1, the data processing apparatus 100 may implement a model checking tool for performing the consistency check of the one or more real-time system requirement specifications 121 expressed using the temporal logic based on one or more formal models 120. As will be appreciated, any of the formal models describes the intended real time system in its components and internal or external behaviour. It is assumed to be available for the consistency check and is repeatedly used for checking the one or more real-time system requirement specifications. If no consistency error is found, the user 110 may request more and more requirement specifications to be checked to increase confidence in the intended real-time system. If a consistency error is found, the user 110 may modify the requirement specifications, if they are assumed to be imperfect, or modify the model if confidence in the requirement specifications is high.
As illustrated in figure 1 and in step 209, the processing entity 101 of the data processing apparatus 100 is further configured to translate the result of the consistency check expressed using the temporal logic back into the pseudo-natural language, i.e. a result of the consistency check expressed in the pseudo-natural language. In the example shown in figure 1 , the result may be that the two exemplary real-time system requirement specifications 111 expressed pseudo-English, namely (a) "if ERROR is false then ultimately SPEED is SYCHRONOUS" and (b) "The drift between MASTER_CLOCK and SLAVE_CLOCK is always bounded by threshold D", are consistent and valid. In an embodiment, the data processing apparatus 100 may display this result to the user 110. In response, the user 110 may trigger to use the corresponding two formal logic real-time system requirement specifications 121, namely (a) "!(ERROR) -> F{infinity}(SPEED == SYCHRONOUS)" and (b) "G{infinity}((abs((MASTER_CLOCK-SLAVE_CLOCK))) <= D)" for an automation control system 130 configured to control a plurality of robots.
If on the contrary, the result of the consistency check is that one of the two exemplary real-time system requirement specifications 111 expressed in pseudo-English, for example the second one (b) "The drift between MASTER_CLOCK and SLAVE_CLOCK is always bounded by threshold D" is not valid for the given model, and a sufficient cause of invalidity is a counter-example such as F{10}(abs(MASTER_CLOCK-SLAVE_CLOCK) >
D) when expressed in temporal logic, then the data processing apparatus 100 may translate this cause back to pseudo-English such as to make it readily understandable to the user 110 in the following form: “eventually the drift between MASTER_CLOCK and SLAVE_CLOCK shall not be bounded by D within 10 milliseconds.”
Figure 3 is a table illustrating the differences between pseudo-natural language requirements and temporal logic requirements as implemented by a data processing apparatus according to an embodiment. The differences illustrate the tension between logical precision and non-ambiguity on one side, and simplicity and clarity on the other side, for which embodiments disclosed herein find a good balance.
In the following a complete formal grammar is described, which may at least partially be implemented by the data processing apparatus 100 according to an embodiment for translating pseudo-English requirement specifications to linear temporal logic (LTL) requirement specifications (commentary is preceded by "//").
//(_): term
[basic_term] ::= <term_name>.
{term_name_of_arg1}
//(Number _): term [basic_term] ::= <number>.
{Number -1}
//(_): term
[basic_term] ::= "(" [term] ")". {Term_name $2}
//Fun 1 (_,_): term
[basic_term] ::= <term_name> "(" [term] ")".
{Fun1($1,(Term_name $3))}
[basic_term] ::= <term_name> "of" [term]
{Fun1($1,(Term_name $3))}
[basic_term] ::= <term_name> "applied" "to" [term]
{Fun1($1,(Term_name $4))}
//Fun2(_,_,_): term
[basic_term] ::= <term_name> "(" [term] [term]
{Fun2($1,(Term_name $3),(Term_name $5))} [basic_term] ::= <term_name> "applied" "to" "(" [term] [term]
{Fun2($1,(Term_name $5),(Term_name $7))} [basic_term] ::= <term_name> "applied" "to" [term] "and" [term] {Fun2($1,(Term_name $4),(Term_name $6))} [basic_term] ::= <term_name> "of" "(" [term] [term]
{Fun2($1,(Term_name $4),(Term_name $6))} [basic_term] ::= <term_name> "of" [term] "and" [term] {Fun2($1,(Term_name $3),(Term_name $5))}
//Abs(_): term
{Abs (Term_name $3)}
[basic_term] ::= "abs" "of [term]
{Abs (Term_name $3)}
[basic_term] ::= "absolute" "value" [term]
{Abs (Term_name $3)}
[basic_term] ::= "absolute" "value" "of" [term]
{Abs (Term_name $4)}
//lndexed(_,_): term
[basic_term] ::= <term_name> "[" [term] "]".
{Indexed($1 , (Term_name $3))}
[basic_term] ::= <term_name> "at" [term]
{lndexed($1 , (Term_name $3))}
[basic_term] ::= <term_name> "indexed" [term]
{lndexed($1 , (Term_name $3))}
[basic_term] ::= <term_name> "index" [term]
{lndexed($1 , (Term_name $3))}
[basic_term] ::= "element" [term] "of" <term_name>. {Indexed($4, (Term_name $2))}
[multerm] ::= [basic_term]
{Term_name $1}
//Times(_,_): term
[multerm] ::= [basic_term] "*" [multerm]
{Times((Ter _na e $1),(Ter _na e $3))} [multerm] ::= [basic_term] "x" [multerm]
{Times((Term_name $1),(Term_name $3))} [multerm] ::= [basic_term] "times" [multerm]
{Times((Term_name $1),(Term_name $3))} [multerm] ::= [basic_term] "multiplied" "by" [multerm] {Times((Term_name $1),(Term_name $4))}
//Div(_,_): term
[multerm] ::= [basic_term] "/" [multerm]
{Div((Term_name $1),(Term_name $3))} [multerm] ::= [basic_term] "over" [multerm]
{Div((Term_name $1),(Term_name $3))} [multerm] ::= [basic_term] "divided" "by" [multerm] {Div((Term_name $1),(Term_name $4))}
[term] ::= [multerm]
{Term_name $1}
//Plus(_,_): term
[term] ::= [multerm] "+" [term]
{Plus((Term_name $1),(Term_name $3))} [term] ::= [multerm] "plus" [term]
{Plus((Term_name $1),(Term_name $3))} [term] ::= [multerm] "added" "to" [term]
{Plus((Term_name $1),(Term_name $4))}
//Minus(_,_): term [term] ::= [term]
{Minus((Number 0),(Term_name $2))}
[term] ::= "minus" [term]
{Minus((Number 0),(Term_name $2))}
[term] ::= [multerm] [term]
{Minus((Term_name $1),(Term_name $3))} [term] ::= [multerm] "minus" [term]
{Minus((Term_name $1),(Term_name $3))} [term] ::= [multerm] "subtracted" "from" [term]
{Minus((Term_name $4),(Term_name $1))}
//(_): formula
{Formula_name $2}
//(Formula_name _): formula [basic_formula] ::= <formula_name>.
{Formula_name $1}
//Eq(_,_): formula
[basic_formula] ::= [term] "=" [term]
{Eq((Term_name $1),(Term_name $3))} [basic_formula] ::= [term] "is" [term]
{Eq((Term_name $1),(Term_name $3))} [basic_formula] ::= [term] "equals" [term]
{Eq((Term_name $1),(Term_name $3))} [basic_formula] ::= [term] "is" "equal" "to" [term] {Eq((Term_name $1),(Term_name $5))} [basicjormula] ::= [term] "is" "the" "same" "as" [term] {Eq((Term_name $1),(Term_name $6))} [basicjormula] ::= [term] "and" [term] "are" "equal". {Eq((Term_name $1),(Term_name $3))}
//Neq(_,J: formula [basicjormula] ::= [term] "!=" [term]
{Neq((Term_name $1),(Term_name $3))} [basicjormula] ::= [term] "is" "not" [term]
{Neq((Term_name $1),(Term_name $4))} [basicjormula] ::= [term] "does" "not" "equal" [term] {Neq((Term_name $1),(Term_name $5))}
[basicjormula] ::= [term] "is" "not" "equal" "to" [term] {Neq((Term_name $1),(Term_name $6))}
[basic_formula] ::= [term] "is" "different" "from" [term] {Neq((Term_name $1),(Term_name $5))}
[basic_formula] ::= [term] "and" [term] "are" "not" "equal".
{Neq((Term_name $1),(Term_name $3))}
[basic_formula] ::= [term] "and" [term] "are" "unequal".
{Neq((Term_name $1),(Term_name $3))}
[basic_formula] ::= [term] "and" [term] "are" "different". {Neq((Term_name $1),(Term_name $3))} formula
[basic_formula] ::= [term] "<" [term]
{Lt((Term_name $1),(Term_name $3))}
[basicjormula] ::= [term] "is" "less" "than" [term] {Lt((Term_name $1),(Term_name $5))}
// Leq(_,_): formula [basicjormula] ::= [term] "<=" [term]
{Leq((Term_name $1),(Term_name $3))}
[basicjormula] ::= [term] "is" "less" "than" "or" "equal" "to" [term] {Leq((Term_name $1),(Term_name $8))}
[basicjormula] ::= [term] "is" "no" "more" "than" [term] {Leq((Term_name $1),(Term_name $6))}
[basicjormula] ::= [term] "is" "at" "most" [term] {Leq((Term_name $1),(Term_name $5))}
// Gt(_, _): formula [basicjormula] ::= [term] ">" [term]
{Gt((Term_name $1),(Term_name $3))}
[basicjormula] ::= [term] "is" "greater" "than" [term] {Gt((Term_name $1),(Term_name $5))}
[basicjormula] ::= [term] "is" "more" "than" [term] {Gt((Term_name $1),(Term_name $5))}
// Geq(_,_): formula [basic_formula] ::= [term] ">=" [term]
{Geq((Term_name $1),(Term_name $3))}
[basicjormula] ::= [term] "is" "no" "less" "than" [term] {Geq((Term_name $1),(Term_name $6))}
[basicjormula] ::= [term] "is" "more" "than" "or" "equal" "to" [term] {Geq((Term_name $1),(Term_name $8))}
[basicjormula] ::= [term] "is" "at" "least" [term]
{Geq((Term_name $1),(Term_name $5))}
[conjjormula] ::= [basicjormula]
{Formula_name $1}
// f is true: formula
[conjjormula] ::= [basicjormula] "holds".
{Formula_name $1}
[conjjormula] ::= [basicjormula] "is" "true".
{Formula_name $1}
[conjjormula] ::= [basicjormula] "shall" "be" "true". {Formula_name $1}
[conjjormula] ::= "it" "is" "true" "that" [conjjormula] {Formula_name $5}
// NegationQ: formula [conjjormula] ::= "!" [conjjormula]
{Negation (Formula_name $2)}
[conjjormula] ::= "not" [conjjormula]
{Negation (Formula_name $2)}
[conjjormula] ::= [basicjormula] "does" "not" "hold".
{Negation (Formula_name $1)}
[conjjormula] ::= [basicjormula] "is" "false".
{Negation (Formula_name $1)}
// Conjunction^, : formula
[conjjormula] ::= [basicjormula] "&&" [conjjormula]
{Conjunction((Formula_name $1),(Formula_name $3))}
[conj_formula] ::= [basic_formula] "and" [conj_formula]
{Conjunction((Formula_name $1),(Formula_name $3))}
[conj_formula] ::= [basic_formula] "and" "also" [conj_formula] {Conjunction((Formula_name $1),(Formula_name $4))}
// Qconjunction(_,
formula, quantified conjunction A(x:[n1,n2] Phi(x)) [conj_formula] ::= "&&" "{" <term_name> "=" [term] [term] "}" [conj_formula]
{Qconjunction($3,(Term_name $5),(Term_name $7),(Formula_name $9))} [conj_formula] ::= "for" <term_name> "=" [term] [term] [conj_formula]
{Qconjunction($2,(Term_name $4),(Term_name $6),(Formula_name $7))} [conj_formula] ::= "for" "every" <term_name> "=" [term] [term] [conj_formula] {Qconjunction($3,(Term_name $5),(Term_name $7),(Formula_name $8))} [conj_formula] ::= "for" "all" <term_name> "=" [term] [term] [conj_formula]
{Qconjunction($3,(Term_name $5),(Term_name $7),(Formula_name $8))} [conj_formula] ::= "for" <term_name> "from" [term] "to" [term] [conj_formula]
{Qconjunction($2,(Term_name $4),(Term_name $6),(Formula_name $7))} [conj_formula] ::= "for" "every" <term_name> "from" [term] "to" [term] [conj_formula] {Qconjunction($3,(Term_name $5),(Term_name $7),(Formula_name $8))} [conj_formula] ::= "for" "all" <term_name> "from" [term] "to" [term] [conj_formula] {Qconjunction($3,(Term_name $5),(Term_name $7),(Formula_name $8))} [conj_formula] ::= [basic_formula] "&&" "{" <term_name> "=" [term] [term]
{Qconjunction($4,(Term_name $6),(Term_name $8),(Formula_name
[conj_formula] ::= [basic_formula] "for" <term_name> "=" [term] [term]
{Qconjunction($3,(Term_name $5),(Term_name $7),(Formula_name $1))} [conj_formula] ::= [basic_formula] "for" "every" <term_name> "=" [term] [term] {Qconjunction($4,(Term_name $6),(Term_name $8),(Formula_name $1))} [conj_formula] ::= [basic_formula] "for" "all" <term_name> "=" [term] [term]
{Qconjunction($4,(Term_name $6),(Term_name $8),(Formula_name $1))} [conj_formula] ::= [basic_formula] "for" <term_name> "from" [term] "to" [term]
{Qconjunction($3,(Term_name $5),(Term_name $7),(Formula_name $1))} [conj_formula] ::= [basic_formula] "for" "every" <term_name> "from" [term] "to" [term] {Qconjunction($4,(Term_name $6),(Term_name $8),(Formula_name $1))} [conj_formula] ::= [basic_formula] "for" "all" <term_name> "from" [term] "to" [term] {Qconjunction($4,(Term_name $6),(Term_name $8),(Formula_name $1))}
[disj_formula] ::= [conj_formula].
{Formula_name $1}
// Disjunction(_,_): formula
[disj_formula] ::= [conj_formula] "||" [disj_for ula]
{Disjunction((For ula_na e $1),(Formula_name $3))}
[disj_for ula] ::= [conj_for ula] "or" [disj_formula]
{Disjunction((For ula_na e $1),(For ula_na e $3))}
[disj_formula] ::= [conj_for ula] "or" "otherwise" [disj_formula] {Disjunction((For ula_na e $1),(For ula_na e $4))}
// Rules with empty output correspond with pseudo-English that is required but whose meaning is well-defined void.
[for_some] ::= "for" "some".
{ }
[for_some] ::= "for" "an".
{ }
[for_some] ::= "for" "a".
{ }
// Qdisjunction(_,
formula, quantified disjunction. E(x:[n1,n2] Phi(x)) [disjjormula] ::= "||" "{" <term_name> "=" [term] [term] "}" [disjjormula]
{Qdisjunction($3,(Term_name $5),(Term_name $7),(Formula_name $9))} [disj_formula] ::= [for_some] <term_name> "=" [term] [term] [disj_formula]
{Qdisjunction($2,(Term_name $4),(Term_name $6),(Formula_name $7))} [disj_formula] ::= [for_some] <term_name> "in" [term] [term] [disj_formula]
{Qdisjunction($2,(Term_name $4),(Term_name $6),(Formula_name $7))} [disj_formula] ::= [for_some] <term_name> "between" [term] "and" [term] [disj_formula] {Qdisjunction($2,(Term_name $4),(Term_name $6),(Formula_name $7))} [disjjormula] ::= [conj ormula] "holds" "||" "{" <term_name> "=" [term] [term] "}".
{Qdisjunction($5,(Term_name $7),(Term_name $9),(Formula_name $1))} [disjjormula] ::= [conjjormula] "holds" [for_some] <term_name> "=" [term] [term] {Qdisjunction($4,(Term_name $6),(Term_name $8),(Formula_name $1))} [disjjormula] ::= [conjjormula] "holds" [for_some] <term_name> "in" [term] [term] {Qdisjunction($4,(Term_name $6),(Term_name $8),(Formula_name $1))}
[disj_formula] ::= [conj_formula] "holds" [for_some] <term_name> "between" [term] "and" [term]
{Qdisjunction($4,(Term_name $6),(Term_name $8),(For ula_na e $1))}
// lmplication(_,_): formula [if] ::= "if"
{ }
[if] ::= "If"
[disj_formula] ::= [conj_formula] "=>" [disj_formula]
{lmplication((Formula_name $1),(Formula_name $3))}
[disj_formula] ::= [conj_formula] "whenever" [disj_formula]
{lmplication((Formula_name $3),(Formula_name $1))}
[disj_formula] ::= [conj_formula] "if" [disj_formula]
{lmplication((Formula_name $3),(Formula_name $1))}
[disj_formula] ::= [if] [conj_formula] "then" [disj_formula]
{lmplication((Formula_name $2),(Formula_name $4))}
[disj_formula] ::= [conj_formula] "implies" [disj_formula]
{lmplication((Formula_name $1),(Formula_name $3))}
[disj_formula] ::= [conj_formula] "implies" "that" [disj_formula] {lmplication((Formula_name $1),(Formula_name $4))}
// A (_): formula, Universal quantification.
// To do when the abstract syntax of formula will cover A.
// [formula] ::= [formula] "always".
{ }
// [formula] ::= [formula] "always" "holds".
{ }
// [formula] ::= "always" [formula]
{ }
// [formula] ::= "it" "always" "holds" "that" [formula]
{ }
// [formula] ::= "it" "is" "always" "true" "that" [formula]
{ }
[temporal_formula] ::= [disj_formula]. {Formula_name $1}
// Translation converts all time units to milliseconds, they are thus implicit in the LTL output.
[timejjnit] ::= "seconds".
{ }
[time_unit] ::= "miliseconds".
{ }
[timejjnit] ::= "mili-seconds".
{ }
[timejjnit] ::= "s".
{ }
[time_unit] ::= "ms".
{ }
[time_unit] ::= "time" "steps".
{ }
[timejjnit] ::= "time" "units".
{ }
// G(_,_): formula. The output values -3 and -4 are only for internal processing and do not appear in the LTL output.
[temporal_formula] ::= "G" [temporal_formula]
{G(infinity,(Formula_name $2))}
[temporal_formula] ::= "G" "{" [term] "}" [temporal_formula].
{G(-3,(Formula_name $5))}
[temporal_formula] ::= "G" "{" [term] [time_unit] "}" [temporal_formula].
{G(-3,(Formula_name $6))}
[temporal_formula] ::= "globally" [temporal_formula]
{G(infinity,(Formula_name $2))}
[temporal_formula] ::= "globally" [temporal_formula] "until" [term] [time_unit] {G(-4,(Formula_name $2))}
[temporal_formula] ::= [disj_formula] "globally".
{G(infinity,(Formula_name $1))}
[temporal_formula] ::= [disj_formula] "globally" "until" [term] [time_unit] {G(-4,(Formula_name $1))}
[eventually] ::= "F".
{ }
[eventually] ::= "eventually".
{ }
[eventually] ::= "Eventually".
{ }
[eventually] ::= "ultimately".
{ }
[eventually] ::= "Ultimately".
{ }
[eventually] ::= "finally".
{ }
[eventually] ::= "Finally".
{ } formula. The output values -3 and -4 are only for internal processing and do not appear in the LTL output.
[temporal_formula] ::= [eventually] [temporal_formula]
{F(infinity,(Formula_name $2))}
[temporal_formula] ::= [disj_formula] [eventually]
{F(infinity,(Formula_name $1))}
[temporal_formula] ::= [eventually] "{" [term] "}" [temporal_formula]
{F(-3,(Formula_name $5))}
[temporal_formula] ::= [eventually] "{" [term] [time_unit] "}" [temporal_formula] {F(-3,(Formula_name $6))}
[temporal_formula] ::= [eventually] [temporal_formula] "within" [term] [time_unit] {F(-4,(Formula_name $2))}
// N(_): formula
[temporal_formula] ::= "N" [temporal_formula]
{N (Formula_name $2)}
[temporal_formula] ::= "next" [temporal_formula]
{N (Formula_name $2)}
[temporal_formula] ::= [disj_formula] "next".
{N (Formula_name $1)}
[temporal_formula] ::= [disj_formula] "at" "next" "time" "step".
{N (Formula_name $1)} formula
[temporal_formula] ::= [disj_formula] "U" [temporal_formula]
{U((Formula_name $1), infinity, (Formula_name $3))}
[temporal_formula] ::= [disj_formula] "U" "{" [term] "}" [temporal_formula] {U((Formula_name $1),-4,(Formula_name $6))}
[temporal_formula] ::= [disj_formula] "U" "{" [term] [time_unit] "}" [temporal_formula] {U((Formula_name $1),-4,(Formula_name $7))}
[temporal_formula] ::= [disj_formula] "until" [temporal_formula]
{U((Formula_name $1), infinity, (Formula_name $3))}
[temporal_formula] ::= [disj_formula] "until" [temporal_formula] "but" "no" "longer" "than" [term] [time_unit].
{U((Formula_name $1),-8,(Formula_name $3))}
// Later: generalize "seconds", factorize, add more rules. formula
[temporal_formula] ::= [disj_formula] "R" [temporal_formula]
{R((Formula_name $1), infinity, (Formula_name $3))}
[temporal_formula] ::= [disj_formula] "R" "{" [term] "}" [temporal_formula] {R((Formula_name $1),-4,(Formula_name $6))}
[temporal_formula] ::= [disj_formula] "R" "{" [term] [time_unit] "}" [temporal_formula] {R((Formula_name $1),-4,(Formula_name $7))}
[temporal_formula] ::= [disj_formula] "release" [temporal_formula]
{R((Formula_name $1), infinity, (Formula_name $3))}
[temporal_formula] ::= [disj_formula] "until" "possibly" [temporal_formula] {R((Formula_name $1), infinity, (Formula_name $4))}
[temporal_formula] ::= [disj_formula] "until" [formula] "possibly" "happens".
{R((Formula_name $1), infinity, (Formula_name $3))}
[temporal_formula] ::= [disj_formula] "until" "possibly" [temporal_formula] "but" "no" "longer" "than" [term] [time_unit].
{R((Formula_name $1),-9,(Formula_name $4))}
[temporal_formula] ::= [disj_formula] "until" [temporal_formula] "possibly" "happens" "but" "no" "longer" "than" [term] [time_unit]
{R((Formula_name $1),-10,(Formula_name $3))}
[formula] ::= [temporal_formula]
{Formula_name $1}
[formula] ::= "when" [conj_formula] "do" [conj_formula]
{G(infinity,(lmplication((Formula_name $2),(F(infinity,(Formula_name $4))))))} [formula] ::= "when" [conj_formula] "do" [conj_formula] "shall" "be" "true".
{G(infinity,(lmplication((Formula_name $2),(F(infinity,(Formula_name $4))))))} [formula] ::= "when" [conj_formula] "do" [conj_formula] "within" [term] [time_unit] {G(infinity,(lmplication((Formula_name $2),(F(-6,(Formula_name $4))))))}
[formula] ::= "when" [conj_formula] "do" [conj_formula] "shall" "be" "true" "within" [term] [timejjnit]
{G(infinity,(lmplication((Formula_name $2),(F(-9,(Formula_name $4))))))}
///////////////////////
// Inverse translation is ambiguous but needs no backtracking or other parser:
// from LTL AST with constructors as in the right-hand sides, and whose root is symbol S, // match the left-hand side of any of one of the rules whose right-hand side has S as root, // apply this rule to produce a sequence of (Non-terminal | Terminal)† and replace the // non-terminals therein by the LTL subtrees given by $1, $2 etc.
// continue recursively the same non-deterministic algorithm until the complete sequence // is from (Terminal)†
// then output that sequence as the pseudo-English phrase corresponding to the LTL AST.
As will be appreciated, the formal grammar described above comprises for several of the real-time system requirement statements expressed using the temporal logic at least two real-time system requirement statements expressed in the pseudo-natural language. In other words, in an embodiment, the data processing apparatus 100 may be configured to translate, i.e. map a given requirement statement expressed using the temporal logic into at least two (equivalent) pseudo-language requirement statements.
Figures 4a and 4b show examples for the compliance of how the translation rules defined by the grammar described above and implemented by the data processing apparatus 100 according to an embodiment comply with Montague semantics (also referred to as
Montague grammar). As will be appreciated, Montague grammar is an approach to natural language semantics based on mathematical logic, especially higher-order predicate logic and lambda calculus, and makes use of the notions of intentional logic. Figures 4a and 4b summarize a verification that provides additional confidence in the translation rules in the direction of English to LTL implemented by embodiments disclosed herein. As English is not a formal language, there is no unanimous and standard mathematical definition of sentence meanings as it exists for a programming language for example. But Montague semantics does provide such a definition for a subset of the English language and a subset of Montague semantics has been used to validate some of the translation rules of pseudo-English to LTL implemented by embodiments disclosed herein. The verification is done in 3 steps that correspond to the 3 levels in syntax of the LTL target logic: the lower level is that of atomic statements that are either the name of a variable, the name of a formula or a comparison expression between two variables. The middle level is a boolean combination (and, or, implies etc.) of two such atomic statements. The upper level is the application of a temporal operation (within, until, ultimately etc.) to formulas of the lower levels. For all 3 levels, the translation rules implemented by embodiments disclosed herein confirm that what Montague semantics would conclude about their mathematical meaning.
As will be appreciated, embodiments disclosed herein allow translating a subset of English-language for describing requirements directly to temporal logic suitable for automated formal verification of system models. Thus, embodiments disclosed herein, combine the flexible, intuitive and productive use of English sentences with non- ambiguous translation to temporal logic.
Moreover, embodiments disclosed herein allow the reverse translation to make the output messages of formal verification clearly intelligible, thus reducing a common problem with error messages: either they are clear but ad-hoc (not formally linked to the verification formulas) or they are precise but cryptic (using explicit logical formulas). The reverse translation implemented by embodiments disclosed herein guarantees messages that are bot precise and intelligible because they are the English-translation of temporal logic formulas using the same correspondence as the forward translation.
Moreover, embodiments disclosed herein provide multiple input-English forms for the same temporal logic output, allowing multiple synonyms for the same requirement
sentence. This frees the user of the memorization effort needed when learning a formal- or computer language.
The person skilled in the art will understand that the "blocks" ("units") of the various figures (method and apparatus) represent or describe functionalities of embodiments of the present disclosure (rather than necessarily individual "units" in hardware or software) and thus describe equally functions or features of apparatus embodiments as well as method embodiments (unit = step).
In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus, and method may be implemented in other manners. For example, the described embodiment of an apparatus is merely exemplary. For example, the unit division is merely logical function division and may be another division in an actual implementation. For example, a plurality of units or components may be combined or integrated into another system, or some features may be ignored or not performed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections may be implemented by using some interfaces. The indirect couplings or communication connections between the apparatuses or units may be implemented in electronic, mechanical, or other forms.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one position, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.
In addition, functional units in the embodiments of the invention may be integrated into one processing unit, or each of the units may exist alone physically, or two or more units are integrated into one unit.
Claims
1. A data processing apparatus (100), comprising a processing entity (101) configured to: parse one or more real-time system requirement specifications (111) expressed in a pseudo-natural language; transform, based on a set of transformation rules defined by a formal grammar, the one or more real-time system requirement specifications (111) expressed in the pseudo-natural language into one or more real-time system requirement specifications (121) expressed using a temporal logic; and perform a consistency check of the one or more real-time system requirement specifications (121) expressed using the temporal logic based on one or more formal models (120) and generate a result of the consistency check expressed using the temporal logic; wherein the processing entity (101) is further configured to translate the result of the consistency check expressed using the temporal logic into a result of the consistency check expressed in the pseudo-natural language.
2. The data processing apparatus (100) of claim 1, wherein the formal grammar comprises for at least one of the one or more real-time system requirement statements (121) expressed using the temporal logic at least two real-time system requirement statements (111) expressed in the pseudo-natural language.
3. The data processing apparatus (100) of claim 1 or 2, wherein the one or more real time system requirement specifications (111, 121) comply with Montague semantics.
4. The data processing apparatus (100) of any one of the preceding claims, further comprising a user interface and/or a communication interface (103) configured to receive the one or more real-time system requirement specifications (111) expressed in the pseudo-natural language and/or to output the result of the consistency check expressed in the pseudo-natural language.
5. The data processing apparatus (100) of any one of the preceding claims, wherein the temporal logic is a linear temporal logic, LTL.
6. A data processing method (200), comprising: parsing (201) one or more real-time system requirement specifications (111) expressed in a pseudo-natural language; transforming (203), based on a set of transformation rules defined by a formal grammar, the one or more real-time system requirement specifications (111) expressed in the pseudo-natural language into one or more real-time system requirement specifications (121) expressed using a temporal logic; performing (405) a consistency check of the one or more real-time system requirement specifications (121) expressed using the temporal logic based on one or more formal models (120); generating (407) a result of the consistency check expressed using the temporal logic; and translating (409) the result of the consistency check expressed using the temporal logic into a result of the consistency check expressed in the pseudo-natural language.
7. The data processing method (400) of claim 6, wherein the formal grammar comprises for at least one of the one or more real-time system requirement statements (121) expressed using the temporal logic at least two real-time system requirement statements (111) expressed in the pseudo-natural language.
8. The data processing method (400) of claim 6 or 7, wherein the one or more real time system requirement specifications (111, 121) comply with Montague semantics.
9. The data processing method (400) of any one of claims 5 to 8, further comprising receiving the one or more real-time system requirement specifications (111) expressed in the pseudo-natural language and/or outputting the result of the consistency check expressed in the pseudo-natural language.
10. The data processing method (400) of any one of claims 5 to 9, wherein the temporal logic is a linear temporal logic, LTL.
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/EP2021/059959 WO2022218549A1 (en) | 2021-04-16 | 2021-04-16 | Apparatus and method for generating requirement specifications |
EP21720224.1A EP4272106A1 (en) | 2021-04-16 | 2021-04-16 | Apparatus and method for generating requirement specifications |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/EP2021/059959 WO2022218549A1 (en) | 2021-04-16 | 2021-04-16 | Apparatus and method for generating requirement specifications |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2022218549A1 true WO2022218549A1 (en) | 2022-10-20 |
Family
ID=75588216
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/EP2021/059959 WO2022218549A1 (en) | 2021-04-16 | 2021-04-16 | Apparatus and method for generating requirement specifications |
Country Status (2)
Country | Link |
---|---|
EP (1) | EP4272106A1 (en) |
WO (1) | WO2022218549A1 (en) |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7555742B2 (en) * | 2000-04-04 | 2009-06-30 | Sosy Inc. | Automatic software production system |
-
2021
- 2021-04-16 EP EP21720224.1A patent/EP4272106A1/en active Pending
- 2021-04-16 WO PCT/EP2021/059959 patent/WO2022218549A1/en unknown
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7555742B2 (en) * | 2000-04-04 | 2009-06-30 | Sosy Inc. | Automatic software production system |
Non-Patent Citations (3)
Title |
---|
KONUR SAVAS: "A survey on temporal logics for specifying and verifying real-time systems", FRONTIERS OF COMPUTER SCIENCE, HIGHER EDUCATION PRESS, BEIJING, vol. 7, no. 3, April 2013 (2013-04-01), pages 370 - 403, XP035373312, ISSN: 2095-2228, [retrieved on 20130401], DOI: 10.1007/S11704-013-2195-2 * |
PI XINGXING ET AL: "Automated Mining and Checking of Formal Properties in Natural Language Requirements", 22 August 2019, ADVANCES IN DATABASES AND INFORMATION SYSTEMS; [LECTURE NOTES IN COMPUTER SCIENCE; LECT.NOTES COMPUTER], SPRINGER INTERNATIONAL PUBLISHING, CHAM, PAGE(S) 75 - 87, ISBN: 978-3-319-10403-4, XP047517455 * |
RICHARD A FROST: "Realization of natural language interfaces using lazy functional programming", ACM COMPUTING SURVEYS, ACM, NEW YORK, NY, US, US, vol. 38, no. 4, 25 December 2006 (2006-12-25), pages 11 - es, XP058090581, ISSN: 0360-0300, DOI: 10.1145/1177352.1177353 * |
Also Published As
Publication number | Publication date |
---|---|
EP4272106A1 (en) | 2023-11-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Forcada et al. | Apertium: a free/open-source platform for rule-based machine translation | |
US11250842B2 (en) | Multi-dimensional parsing method and system for natural language processing | |
US6463404B1 (en) | Translation | |
Sturt et al. | Processing coordinated structures: Incrementality and connectedness | |
US8117022B2 (en) | Method and system for machine understanding, knowledge, and conversation | |
Burden et al. | Natural language generation from class diagrams | |
EP0473864A1 (en) | Method and apparatus for paraphrasing information contained in logical forms | |
Štajner et al. | Improving machine translation of english relative clauses with automatic text simplification | |
Sharp | CAT2–implementing a formalism for multi-lingual MT | |
Alegria et al. | Transfer-based MT from Spanish into Basque: reusability, standardization and open source | |
Brandt et al. | Apertium-IceNLP: A rule-based Icelandic to English machine translation system | |
EP4272106A1 (en) | Apparatus and method for generating requirement specifications | |
Mengyuan et al. | Automatic generation method of airborne display and control system requirement domain model based on NLP | |
Kaljurand et al. | Collaborative multilingual knowledge management based on controlled natural language | |
Krishnamurthy et al. | Ease: Enabling hardware assertion synthesis from english | |
US20180011833A1 (en) | Syntax analyzing device, learning device, machine translation device and storage medium | |
Paige et al. | Towards model transformation with TXL | |
Mishchenko et al. | New functionalities of the system for processing natural language specifications and its operating environment | |
Nederhof et al. | A customized grammar workbench | |
Alluhaibi | Simple interval temporal logic for natural language assertion descriptions | |
Agustini et al. | Selection restrictions acquisition for parsing improvement | |
Khelil et al. | A semi-automatically generated TAG for Arabic: Dealing with linguistic phenomena | |
Laki et al. | Syntax-Based Reordering in Phrase-Base English-Hungarian Statistical Machine Translation. | |
US20240028825A1 (en) | Device for syntactic parsing of natural language | |
Winiwarter | WETCAT-Web-enabled translation using corpus-based acquisition of transfer rules |
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: 21720224 Country of ref document: EP Kind code of ref document: A1 |
|
ENP | Entry into the national phase |
Ref document number: 2021720224 Country of ref document: EP Effective date: 20230801 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |