Focus^ff: A semantic extension of Focus^ßæ

A formal specification might be necessary to analyse and verify the safety and security properties of interactive systems, if we would like to achieve a higher level of quality assurance than might be achievable using testing-only approaches. While testing allows to check whether the system behaves correctly for a given point-wise scenario, verification allows us to check properties of the system. There are many types of formal languages and frameworks. The choice of what exactly formal language/frameworks should be applied in each particular case depends on many factors: what kind of system we are aiming to specify, what kind of properties we intend to analyse, etc.

In the case of interactive systems, one of the established approaches for formal specification and verification is to present the system as a composition of components, processing data and control streams, i.e., to apply the principle of modularity. However, the question is how exactly the streams should be specified, as the choice of the specification approach would impact the readability and verifiability of the specification.

Czepa et al. [4] conducted experiments with 216 participants to study the understandability of Linear Temporal Logic (LTL,[7]), Property Specification Patterns (PSP,[5]), and Event Processing Language (EPL,[17, paschke2010homogeneou]). Their study demonstrated that PSP, which is a highly abstract specification language, is generally easier to understand than LTL and EPL.

In this work, we would like to propose an a formal approach for modelling event-based streams, which we call Focus^ff. The proposed approach is based on a formal language Focus^ßæ  and can be seen as its semantic extension. Focus^ßæallows the creation of concise but easily understandable specifications and is appropriate for the application of the specification and proof methodology presented in our previous works.

The Focus^ßæ[14] language was inspired by Focus [3, 11], a framework for formal specification and development of interactive systems. In both languages, specifications are based on the notion of streams. However, in the original Focus input and output streams of a component are mappings of natural numbers ${\mathbb N}$ to single messages,whereas a Focus^ßæ  stream is a mapping from ${\mathbb N}$ to lists of messages within the corresponding time intervals. Moreover, the syntax of Focus^ßæ is particularly devoted to specifying spatial (S) and timing (T) aspects in a comprehensible fashion, which is the reason to extend the name of the language by ^ßæ. The Focus^ßæ specification layout also differs from the original one: it is based on human factor analysis within formal methods [16, 9, 10].

Focus^ßæ allows to create concise but easily understandable specifications and is appropriate for application of the specification and proof methodology presented in [8]. This methodology allows to specify components in a way that carrying out proofs is quite simple and scalable to practical problems. In particular, a specification of a system can be translated to a Higher-Order Logic and verified by the interactive semi-automatic theorem prover Isabelle [6] also applying its component Sledgehammer [2] that employs resolution-based [2, 1] first-order automatic theorem provers (ATPs) and satisfiability modulo theories (SMT) solvers to discharge goals arising in interactive proofs.

Focus^ßæ has been successfully applied in a number of case studies, e.g., for analysis of cryptographic properties [13], analysis of FlexRay [12] and CAN [15] protocols.

In Focus^ßæ  we specify every component using assumption-guarantee-structured templates. This allows us to avoid the omission of unnecessary assumptions about the system’s environment since a specified component is required to fulfil the guarantee only if its environment behaves in accordance with the assumption. In a component model, one often has transitions with local variables that are not changed. Also, outputs are often not produced, e.g., when a component gets no input or some preconditions necessary to produce a nonempty output are violated. In many formal languages, this kind of invariability has to be defined explicitly to avoid under-specified component specifications. To make our formal language better understandable for programmers, we use in Focus^ßæ so-called implicit else-case constructs. That means, if a variable is not listed in the guarantee part of a transition, it implicitly keeps its current value. An output stream not mentioned in a transition will be empty. Further, we do not require introducing auxiliary variables explicitly: The data type of a not introduced variable is universally quantified in the specification such that it can be used with any data value. The Focus^ßæ specifications are a special form of timed automata, so-called Timed State Transition Diagrams (TSTDs), which can be described in both diagram and textual form.

To deal with event-based systems, we suggest inheriting the Focus^ßæsyntax accompanied with different semantics. For simplicity, we call the new version of the language Focus^ff. In Focus^ff, input and output streams of a component are mappings of natural numbers ${\mathbb N}$ to lists of messages, like in Focus^ßæ. However, in Focus^ff these lists represent not the messages within the corresponding time intervals, but messages within the same causality intervals. We can see causality intervals as an abstract view of time intervals (cf. also Figure 1):

• •

  If messages belong to the same causality interval, this means that, according to the system’s clock, these messages come simultaneously.

• •

  If some message $a$ belongs to the causality interval $i$ (from the timed point of view, it belongs to some time interval $t$), and some message $b$ belongs to the causality interval $i+1$, this does not necessary mean that $B$ should belong to the time interval $t+1$, because the causality property insure only the fact “event $b$ happens after event $a$”. Thus, $b$ should belong to the time interval $t+\delta$, where $\delta>0$.

In a special case, the causality intervals of a stream can be equal to the time interval of this stream.

Each message can be seen as a single event, but we can also have an additional view on the streams, where a set of messages (single events) from the same causality interval can be denoted as a combined event. Let us name some of the operators used on Focus^ßæto specify time intervals in our streams: $\langle\rangle$ denotes an empty list, e.g., a single time interval without any events, and $\langle x\rangle$ a list consisting of the element $x$; $\textsf{ft}.l$ describes the first element of a list $l$; $s^{t}$ represents the $t$th time interval of the stream $s$. We suggest the following notation for Focus^ffan additional operator $s^{\llparenthesis\underline{i}\rrparenthesis}$ to represent the $i$th time interval of the stream $s$. For the example presented on Fig.1, we have that
$s^{0}=\langle\rangle$, $s^{1}=\langle a\rangle$, $s^{2}=\langle b,c\rangle$, $s^{3}=\langle\rangle$, $s^{4}=\langle d\rangle$, $s^{5}=\langle a\rangle$, and
$s^{\llparenthesis\underline{0}\rrparenthesis}=\langle a\rangle$, $s^{\llparenthesis\underline{1}\rrparenthesis}=\langle b,c\rangle$, $s^{\llparenthesis\underline{2}\rrparenthesis}=\langle d\rangle$, $s^{\llparenthesis\underline{3}\rrparenthesis}=\langle a\rangle$.
From purely syntactical point of view, if we take a timed (Focus^ßæ) stream and remove all empty timed intervals from it, we obtain an event (Focus^ff) stream. Correspondingly, we can define operators over events’ causality, e.g., to denote that the $i$th causality interval of a stream $s_{1}$ occurs before the $j$th causality interval of a stream $s_{2}$, to denote that events of some type should occur in the stream always before some instances of messages of another type, etc.