EP4272106A1

EP4272106A1 - Apparatus and method for generating requirement specifications

Info

Publication number: EP4272106A1
Application number: EP21720224.1A
Authority: EP
Inventors: Gaétan Joseph Daniel Robert HAINS
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-04-16
Filing date: 2021-04-16
Publication date: 2023-11-08
Also published as: WO2022218549A1

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

[basic erm] ::= "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

[basicjormula] ::= "(" [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.