From Natural Language to LTL: Difficulties Capturing Natural Language Specification in Formal Languages for Automatic An

1. From Natural Language to LTL:Difficulties Capturing Natural Language Specification in Formal Languages for Automatic Analysis Elsa L Gunter NJIT

2. Objective of Formal Methods • Goal: Prove system satisfies requirements when deployed in intended environment • Reality: • System exists in physical world, • Requirements exists in minds of designer / user • Collection of thoughts in natural language • Proof requires mathematical formalism • Keep gap on each end as small as possible

3. Common Approach for Embedded Systems • Model system (and environment) as concurrent processes • Each process modeled as finite automaton • Requirements stated in temporal logic • e.g. LTL, CTL*, μ-calculus • Apply model checking

4. Narrowing the Gap – System Side • Generate code for system automatically from formal model • What is best kind of automata • For modeling processes • For use in formal proofs • For automatically generating code • Usually some variant of finite state machine used • Generate model from code?

5. Narrowing the Gap – Requirements Side? • Generate logical formula from natural language requirements? • What is the best kind of language / logic • For capturing natural language requirements • For use in formal proofs • For capturing the necessary details of requirements of complex systems • Usually some variant of temporal logic used • Generate natural language requirements from logical formulae?

6. Requirements in Natural Language • Requirements begin as natural language expressions (thoughts) • Natural language is highly expressive • Problem for languages designed for use in automatic proofs • Requirements is natural language often quite ambiguous • Problem for any attempt to translate into formal language

7. Ambiguity – Example • “Once pump has been turned on, pressure display will be updated every 2 seconds” • What does “updated” mean? • Display made equal to actual value? • When? • Display made equal actual previous value? • How long ago? • What exactly does “every 2 seconds” mean? • (Did we really mean something else?)

8. Resolving Ambiguities • Fundamentally a human task • First ambiguities must be found • Formalizing requiremetns is a good way to find ambiguities • Automatic tools for translation can help • Must not build in a fixed interpretation when many are possible

9. LTL • Linear Temporal Logic is gives properties over sequences of states • Advantages • Simple syntax • Well-defined semantics • Admits model checking

10. LTL • Disadvantages: • No explicit time • No direct ability to compare values from different states • Operators assume closed-world assumption • Next is too strong

11. Example Always (seconds(cur_time – last_reading)  2)  Next (display = previous_pressure)) • May be true for monitor of pressure • Becomes false for pressure monitor run in parallel with other monitors

12. Dealing With Problems • No Explicit Time • Add time variable to formulae • Cannot state in logic basic properties of time, such as always increasing

13. Dealing With Problems • No comparison between states • Add history variables • Example: Always x  previous_x • Cannot state that history variable actually holds variable’s previous value

14. Dealing With Problems • Closed-world assumption • Replace Next P with Eventually P • Much weaker • Possibly can use Not Too_late Until P for some notion of Too_late

15. Automaton Support • No Explicit Time • Update time variable at every transition Or • Time variable controlled by environment, modeled by separate automaton • No comparison between states • Update at history variable at each transition (or at each assignment)

16. Automaton Support • Problem: these clutter automaton, distance it from implementation • Partial solution: • Express extensions to model in separate automata designed only for them • Product with original automaton for checking • Requires appropriate notion of automaton and product (mix of synchronous and asynchronous)

17. Future • Automated assistance for translating natural language • Design to highlight ambiguities, not hide them • Design better language / logic for expressing requirements • Stay within the realm of automated checking • Possibly incorporate constructs for heuristics given above • Tools for generating auxiliary automata and product

19. Product Definition • (S,T, ,A) • S states • T transitions (labeled pairs of states) •  alphabet of transition labels • A mapping from  to actions

20. Product Definition • (S1,T1,1,A1) * (S2,T2,2,A2) = (S1 S2,T*, 1  2 ,A*) where • T* = {((s1 ,s2),(s’ 1,s 2), l1) | (s1,s’ 1,l1)  T1 & l1  12 }  {((s1 ,s2),(s1,s’ 2), l2) | (s2,s’ 2, l2)  T2 & l2  2 1}  {((s1 ,s2),(s’ 1,s’ 2),l) | (s1 ,s’ 1 ,l)  T1 & (s2,s’ 2,l)  T2 } • A* merges actions on synchronization