<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Analysis of the Verification Approaches for the Cyber- Physical Systems</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Zaporizhzhia National Technical University</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Zhukovsky str.</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Zaporizhzhia</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Ukraine skorotunov@yahoo.com</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>galina.tabunshchik@gmail.com</string-name>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Ilmenau University of Technology</institution>
          ,
          <addr-line>Max-Planck-Ring str., 14, Ilmenau, 98693</addr-line>
          ,
          <country country="DE">Germany</country>
        </aff>
      </contrib-group>
      <fpage>0000</fpage>
      <lpage>0001</lpage>
      <abstract>
        <p>In the paper the possibility of utilization of the Kripke structures for applying linear-time temporal logic in problems of verification of reactive systems is considered. The definition and main characteristics of the cyberphysical systems, finite state machines, Kripke structures and temporal logics are considered by the authors. Example of modeling on the base of GOLDi is provided.</p>
      </abstract>
      <kwd-group>
        <kwd />
        <kwd>Verification</kwd>
        <kwd>parallel program</kwd>
        <kwd>reactive system</kwd>
        <kwd>cyber-physical systems</kwd>
        <kwd>Kripke structure</kwd>
        <kwd>finite-state machine</kwd>
        <kwd>temporal logic</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>With the high complexity of modern computer systems (millions of lines of code and
billions of transistors), it is impossible to completely avoid errors. It is not only
related to the application software developed in a short time in a competitive market
environment, but also to critical components, such as hardware (I/O devices,
microprocessors) and software (compilers, operating systems). It is obvious that the
systems, in the design and implementation of which mistakes are made, can in one or
another situation behave in unpredictable ways and lead to serious consequences. The
literature describes many cases of this kind. As vivid examples following can be
represented.</p>
      <p>
        In 1996, the launch vehicle Ariane 5, developed by the European Space Agency,
exploded at the 39th second after launch. As it turned out later, the onboard system
partially used the software of the previous version of the rocket, the Ariane 4, in
particular, the inertial navigation system control module [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ]. When converting from a
64bit floating-point number representing the inclination of the rocket to a 16-bit integer,
an overflow occurred that was not handled by the module. When developing the
module, it was assumed that overflow was impossible due to the physical limitations
of the rocket, but new engines which were used in the Ariane 5 surpassed those
limitations.
      </p>
      <p>
        Another notable example is the case of the medical device Therac-25 [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ], which
was launched in 1982 by the Canadian firm Atomic Energy of Canada Limited. The
device was intended for radiation therapy – irradiation of a cancer. In some situations,
the irradiation intensity increased by 2 orders or more due to a number of mistakes
made in the design and implementation of the built-in control system. At least two
patients died, and several people were disabled during the operation of the device (the
period from June 1985 to January 1987).
      </p>
      <p>
        It is important to understand that errors in computer systems are not exceptional.
According to statistics, the average number of errors per thousand lines of
undebugged code ranges in 10-505 [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ]. Moreover, there is a tendency to the degradation
of design quality (apparently, this is a consequence of the increasing complexity of
systems and optimization of the costs of their creation) [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ]. At the same time, our life
is increasingly dependent on computers. Therefore, ensuring the correctness and
reliability of computer systems (in other words, verification) is becoming increasingly
important.
2
2.1
      </p>
    </sec>
    <sec id="sec-2">
      <title>Program verification</title>
      <sec id="sec-2-1">
        <title>Verification approaches</title>
        <p>Verification is the process of checking of the compliance of a program (its model)
with the requirements placed on it. If the program meets the requirements, it is called
correct. Otherwise, the program is called incorrect, and the fact of non-compliance of
the program with the requirements is an error. Thus, verification is the analysis of the
program for the presence or absence of errors in it. An indefinite verdict is also
possible when errors are not found, but their absence has not been proven.</p>
        <p>It is necessary to take into account many nuances. First, the requirements, as a rule,
are formulated informally, in natural language, so it is not always possible to
unambiguously determine whether the program corresponds to them or not. Secondly,
proving the absence of errors in the program is extremely difficult from a mathematical
point of view (because of the fact that this task is not fully amenable to automation).</p>
        <p>
          Verification methods can be divided into three main groups [
          <xref ref-type="bibr" rid="ref5">5</xref>
          ]:
─ formal methods, which utilize mathematically rigorous analysis of the program
model and requirements model;
─ testing methods that verify the actual behavior of the program on a certain set of
scenarios;
─ expertise performed by people based on their knowledge and experience directly
on the design results (for example, code inspection).
        </p>
        <p>Each of the specified groups of methods has its advantages and disadvantages,
each has its own area of applicability. Full verification of complex systems of
responsible purpose is impossible without the joint use of different approaches. This work
focuses on mostly formal methods of verification programs.
2.2</p>
      </sec>
      <sec id="sec-2-2">
        <title>Formal verification</title>
        <p>Formal verification is based on mathematical (logical) modeling programs and
requirements for them. The idea is exactly the same as when using models in other
areas of knowledge:
─ a model is created – an idealized description of the object or phenomenon under
study;
─ the model is investigated using mathematical methods;
─ research results are transferred to a real object or phenomenon.</p>
        <p>Of course, the applicability of this approach is determined by the models used – it
is necessary to clearly understand the conditions for their adequacy.</p>
        <p>
          The general process of formal verification [
          <xref ref-type="bibr" rid="ref6">6</xref>
          ] is shown in Fig. 1:
─ a formal program model is created;
─ a formal requirements model is created;
─ the compliance of the program model with the requirements model is formally
verified;
─ based on the results of the test, it is concluded that the real program does not meet
the real requirements (in other words, that there are no or no errors in the program).
        </p>
        <p>For the presentation of program models and requirements models, the languages of
the formal specification of programs (modeling languages) and the languages of the
formal specification of requirements are used respectively.</p>
        <p>Formal verification methods differ in the types of program models (state machines,
Petri nets, labeled transition systems), types of requirements models (software
contracts, production rules, temporal statements), correspondence relations (equivalence,
simulation, route inclusion) and compliance verification techniques (state space
research, symbolic analysis, deductive inference). In this paper we briefly consider one
of the most popular formal verification methods – model checking.
In model checking, requirements for programs are represented by logical formulas of
a certain type, and programs themselves are structures interpreting formulas of this
type; the correspondence relation is the truth of a formula on a structure (a program
satisfies the requirements if and only if the corresponding structure is a model of the
corresponding formula).</p>
        <p>Often, temporal logics are used to represent the requirements – logic that allows
one to define the relationship of events in time, for example, Linear-time Temporal
Logic or Computational Tree Logic. Accordingly, Kripke structures and related
formalisms (marked transition systems) are used to represent programs.</p>
        <p>
          Kripke structures are used to model reactive systems – systems operating in an
“infinite loop” and interacting with their environment. As an example of such systems
cyber-physical system can be seen. The behavior of the system is modeled by
calculation in the Kripke structure [
          <xref ref-type="bibr" rid="ref7">7</xref>
          ].
        </p>
        <p>Propositional temporal logic can be used to describe requirements, in particular
LTL. The main method for establishing the correctness or incorrectness of a model is
to search in the state space (bypassing the state graph).
3</p>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>Finite state machines</title>
      <p>
        A finite state machine (FSM) is a computation model that can be implemented with
hardware or software and can be used to simulate sequential logic (for example
computer program) [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ]. Finite state machine generates regular languages. Finite state
machines can be used to model problems in many fields including mathematics, artificial
intelligence, games, and linguistics.
3.1
      </p>
      <sec id="sec-3-1">
        <title>Deterministic and non-deterministic finite state machines</title>
        <p>There are two types of finite state machines: deterministic finite state machines
(deterministic finite automaton) and non-deterministic finite state machines
(nondeterministic finite automata).</p>
        <p>A deterministic finite automaton (DFA) is described by a five-element tuple:
Q, , , q0 , F .
(1)</p>
        <p>Where Q is a finite set of states,  is a finite, nonempty input alphabet,  is a
series of transition functions, q0 is the starting state, F is the set of accepting states.</p>
        <p>There must be exactly one transition function for every input symbol in  from
each state. DFAs can be represented by following diagrams:</p>
        <p>Similar to a DFA, a nondeterministic finite automaton (NDFA) is described by an
above five-element tuple. Unlike DFAs, NDFAs are not required to have transition
functions for every symbol in  , and there can be multiple transition functions in the
same state for the same symbol. Additionally, NDFAs can use null transitions, which
are indicated by  . Null transitions allow the machine to step from one state to
another without having to read a symbol. NDFAs can be represented by diagrams of this
form:</p>
        <p>One might assume that NDFAs can solve problems that DFAs cannot, but NDFAs
are just as powerful as DFAs. However, a DFA will require many more states and
transitions than an NDFA would take to solve the same problem. Converting from
DFA to NDFA and vice versa is possible which makes them equivalent.
A system where particular inputs cause particular changes in state can be represented
using finite state machines. This example describes the various states of a turnstile.
Inserting a coin into a turnstile will unlock it, and after the turnstile has been pushed,
it locks again. Inserting a coin into an unlocked turnstile, or pushing against a locked
turnstile will not change its state. Diagram of the turnstile FSM is following:</p>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>Kripke structure</title>
      <sec id="sec-4-1">
        <title>Definition of the Kripke structure</title>
        <p>
          Saul Aaron Kripke introduced structures named after him to the logical and
philosophical use in the late 1950s [
          <xref ref-type="bibr" rid="ref9">9</xref>
          ]. In general terms, the Kripke structure is a system of
possible worlds and transitions between them: each world is static and interpreted in
some traditional way. Its diagram can be seen at Fig. 5. The Kripke structure is the
quadruple S, S0 , R, L , where S is the set of states, S0  S is the set of initial states,
R  S  S is the transition relation, L : S  2AP is a labeling function which marks
each state of the structure with a set of atomic propositions.
Let a set of atomic propositions have the form locked, lock, unlock . Consider the
Kripke structure M  S0 , S1, S2 , S3,S0, R, L , which simulates a door with a lock
which can be seen at Fig. 6. The initial state is marked by an incoming arrow; next to
each state there are statements which are true in it. The states of the structure are
labeled as follows:
─ L  S0    – the door is open; no action is taken on the lock;
─ L  S1   lock – the door is open; it is being closed;
─ L  S2   locked – the door is closed, no action is taken with the lock;
─ L  S3   locked, unlock – the door is closed; it is being opened.
A parallel program is a finite set of sequential programs over a common set of
variables [
          <xref ref-type="bibr" rid="ref10">10</xref>
          ]. A separate program of this set is called a process. Programs running in the
"infinite loop" are considered in this paper. These are the so-called reactive systems.
        </p>
        <p>
          Such systems respond to environmental events by performing certain actions in
response. This is an extensive class of programs, including cyber-physical systems,
operating systems, device drivers, telecommunication environments, control systems,
etc. [
          <xref ref-type="bibr" rid="ref11">11</xref>
          ].
        </p>
        <p>
          Cyber-physical systems are the systems that provide the integration of computing,
physical processes and networks, or as systems where software and physical
subsystems are closely bounded, each of which works in a variety of temporal and spatial
dimensions, demonstrating clear and multiple behavioral patterns, and interacts in a
variety of ways [
          <xref ref-type="bibr" rid="ref12">12</xref>
          ]. Modern trends in productivity and complexity of requirements
for systems use require fundamentally new design approaches in which cybernetic
and physical components are integrated at different stages.
        </p>
        <p>In general, the qualitative properties of cyber-physical systems can be classified
into the following two broad categories:
─ reachability or guarantee properties that raise the question of whether a system can
achieve a configuration that satisfies a particular property;
─ security properties that raise the question of whether the system can remain forever
in configurations that satisfy a particular property.</p>
        <p>
          The main properties of cyber-physical systems include following [
          <xref ref-type="bibr" rid="ref13">13</xref>
          ]:
─ high degree of automation,
─ reorganization / reconfiguration of the dynamics,
─ cybernetic capabilities in each physical component,
─ the ability of networks to work on multiple scales,
─ integration on different time and spatial scales.
        </p>
        <p>The behavior of cyber-physical systems is described in terms of sequences of
events distributed in time. So-called temporal logics are often used for the
specification of requirements for cyber-physical systems. Temporal logics are formal
languages that allow to define the interrelationships of events in time: causal
relationships, restrictions on the relative order, the magnitude of delays between events, etc.
The following examples can be cited as temporal properties: the system always works
without freezing; two users cannot simultaneously access shared data; a request with a
higher weight will be processed before constipation with a lower weight.
5.2</p>
      </sec>
      <sec id="sec-4-2">
        <title>Linear-time Temporal Logic</title>
        <p>
          Among number of temporal logics, two have become particularly popular in computer
science: Linear-time Temporal Logic (LTL) [
          <xref ref-type="bibr" rid="ref14">14</xref>
          ] and Computation Tree Logic (CTL)
[
          <xref ref-type="bibr" rid="ref15">15</xref>
          ]. In this paper LTL is considered.
        </p>
        <p>In LTL, two temporal operators are added to the syntax of classical propositional
logic: the unary operator X (next time) and the binary operator U (until). These two
operators form the LTL temporal basis.</p>
        <p>
          Let a set of elementary statements (Atomic Propositions) be given. The LTL
formula is given by the following grammar [
          <xref ref-type="bibr" rid="ref16">16</xref>
          ]:
 : p    X U .
(2)
        </p>
        <p>Here, p is an arbitrary elementary statement from the AP set. For convenience, in
LTL formulas it is possible to use:
─ derived logical connectives, for example,  and  ;
─ logical constants, true and false ;
─ derived temporal operators, for example F (in the Future), G (Globally), W
(Weak until) and R (Release).</p>
        <p>Temporal operators can be interpreted as following.
─ The formula  is true at the next point in time – X .
─ The formula  is true now or will surely become true in the future, but up to this
point (not inclusive) the formula  should be true – U .
─ The formula  is true now or will become true sometime in the future – trueU
which is also can be displayed as F .
─ The formula  is false now and will never become true in the future (always,
from now on, the formula  is true) –  F which is also represented as G .
─ The formula  is true until the formula  is not become true, without requiring
the formula  to ever become true in the future – U   G or  W .
─ The formula  is true until the moment (inclusive) when  becomes true the first
time; if such a moment never comes, the formula  is always true (it possible to
say that  frees  ) – U  or  R .</p>
        <p>Thus, the requirements for the system, which simulates a door lock and was
described above, can be expressed in LTL logic:
─ G lock  unlock  – for system it is impossible to open and close door at the
same time;
─ G locked  lock  – system should never close the closed door;
─ G lock  X locked  – if the door is closed, at the next moment in time it will
become closed.
6</p>
      </sec>
    </sec>
    <sec id="sec-5">
      <title>Experimental modeling on the base of GOLDi</title>
      <p>
        Integrated Communication Systems Group at the Ilmenau University of Technology
has many years of experience in integrated hard- and software systems and over 10
years of experience in dealing with Internet-supported teaching in the field of digital
system design [
        <xref ref-type="bibr" rid="ref17">17</xref>
        ]. Grid of Online Lab Devices Ilmenau (GOLDi) gives the students
the possibility to work on real physical systems without the need to stand in line at a
lab or the need to take care of opening hours and offers the students a working
environment that is as close as possible to a real world laboratory. Under real laboratory
conditions disturbances can appear and lead to failures of the control algorithm that
cannot be detected under virtual lab conditions.
      </p>
      <p>
        Online laboratories offer various features like visualization and animation, which
allows to observe and to test all the properties of the design. In connection with
formal design techniques, simulation and prototyping are used to establish a foundation
for the development of a reliable system design. To check the functionality of the
whole design, some special simulation and validation features are included as integral
part of the GOLDI system. This offers various possibilities for the execution of
simulations [
        <xref ref-type="bibr" rid="ref18">18</xref>
        ], such as:
─ usage of simulation models of the physical system for visual prototyping,
─ step by step and parallel execution of these prototypes,
─ visualization of the simulation process with the tools also used for specification,
─ features for test pattern generation and
─ code generation for hardware and software synthesis.
      </p>
      <p>GOLDI offers a Web-based environment supporting the above mentioned features
to generate and execute a design by using simulation models.</p>
      <p>As an example of modeling it was decided to create Kripke structure of the
elevator which is located in the GOLDi. This elevator has ability to move upwards and
downwards from floor to floor and open or close its door.</p>
      <p>The atomic propositions for the Kripke structure representing the elevator are as
follows:
─ 1st – elevator is located at the 1st floor;
─ 2nd – elevator is located at the 2nd floor;
─ DO – door is open;
─ MU – elevator is moving in the upward direction;
─ MD – elevator is moving in the downward direction.</p>
      <p>For clarity, each state is labeled with both the atomic propositions that are true in
the state and the negations of the propositions that are false in the state. The labels on
the arcs indicate the actions that cause transitions and are not part of the Kripke
structure. Kripke structure of the elevator can be seen at Fig.7.</p>
      <p>This model can be used for further formal verification. For example one might
want to determine that “door of the elevator is closed and it is moving upwards”. S0 ,
p  1st  2nd  DO  MU  MD . Using Kripke structure this can be determined.
7</p>
    </sec>
    <sec id="sec-6">
      <title>Conclusions</title>
      <p>In the paper the authors considered the possibility of utilization of the Kripke
structures for applying linear-time temporal logic in problems of verification of reactive
systems. Review of the main characteristics of the cyber-physical systems, finite state
machines, Kripke structures and temporal logics was carried out by the authors.
Example of modeling on the base of GOLDi was provided in the paper.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Garfinkel</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Goode</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Barrett</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Pardes</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>History's Worst Software Bugs</article-title>
          , https://www.wired.com/
          <year>2005</year>
          /11/historys-worst
          <string-name>
            <surname>-</surname>
          </string-name>
          software-bugs/?currentPage=
          <fpage>2</fpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Leveson</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Turner</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>An investigation of the Therac-25 accidents</article-title>
          .
          <source>Computer</source>
          .
          <volume>26</volume>
          ,
          <fpage>18</fpage>
          -
          <lpage>41</lpage>
          (
          <year>1993</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>McConnell</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <article-title>Code complete, second edition</article-title>
          . Microsoft Press, Redmond (Washington) (
          <year>2004</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Lloyd</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <article-title>Programming the universe</article-title>
          . Knopf, New York (
          <year>2006</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Habra</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Abran</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lopez</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Sellami</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>A framework for the design and verification of software measurement methods</article-title>
          .
          <source>Journal of Systems and Software</source>
          .
          <volume>81</volume>
          ,
          <fpage>633</fpage>
          -
          <lpage>648</lpage>
          (
          <year>2008</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Tuch</surname>
            ,
            <given-names>H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Klein</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Heiser</surname>
            ,
            <given-names>G.: OS</given-names>
          </string-name>
          <string-name>
            <surname>Verification -- Now</surname>
          </string-name>
          !, https://www.usenix.org/legacy/event/hotos05/final_papers_backup/tuch/tuch_html/index.h tml.
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Subbotin</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <article-title>Methods of data sample metrics evaluation based on fractal dimension for computational intelligence model buiding</article-title>
          .
          <source>2017 4th International Scientific-Practical Conference Problems of Infocommunications. Science and Technology (PIC S&amp;T)</source>
          .
          <article-title>(</article-title>
          <year>2017</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Grant</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          : Elementary Computability,
          <source>Formal Languages and Automata. Software &amp; Microsystems. 1</source>
          ,
          <issue>171</issue>
          (
          <year>1982</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <surname>Gabbay</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          :
          <article-title>Kripke Saul A</article-title>
          ..
          <article-title>Semantical considerations for modal logics</article-title>
          .
          <source>Proceedings of a Colloquium on Modal and Many-valued Logics</source>
          , Helsinki,
          <fpage>23</fpage>
          -
          <issue>26</issue>
          <year>August</year>
          ,
          <year>1962</year>
          ,
          <source>Acta Philosophica Fennica</source>
          <year>1963</year>
          , pp.
          <fpage>83</fpage>
          -
          <lpage>94</lpage>
          .
          <source>The Journal of Symbolic Logic</source>
          .
          <volume>34</volume>
          ,
          <issue>501</issue>
          (
          <year>1969</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Oliinyk</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Skrupsky</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Subbotin</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <article-title>Parallel Computer System Resource Planning for Synthesis of Neuro-Fuzzy Networks</article-title>
          .
          <source>Recent Advances in Systems, Control and Information Technology</source>
          .
          <fpage>88</fpage>
          -
          <lpage>96</lpage>
          (
          <year>2016</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>Müller-Olm</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Schmidt</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Steffen</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          :
          <string-name>
            <surname>Model-Checking</surname>
          </string-name>
          .
          <source>Static Analysis</source>
          .
          <fpage>330</fpage>
          -
          <lpage>354</lpage>
          (
          <year>1999</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>Korotunov</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Tabunshchyk</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Wolff</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>Cyber-Physical Systems Architectures and Modeling Methods Analysis for Smart Grids</article-title>
          .
          <source>2018 IEEE 13th International Scientific and Technical Conference on Computer Sciences and Information Technologies (CSIT)</source>
          .
          <article-title>(</article-title>
          <year>2018</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>Miclea</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Sanislav</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          :
          <article-title>About dependability in cyber-physical systems</article-title>
          .
          <source>2011 9th EastWest Design &amp; Test Symposium (EWDTS)</source>
          .
          <article-title>(</article-title>
          <year>2011</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <string-name>
            <surname>Pnueli</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>The temporal logic of programs</article-title>
          .
          <source>18th Annual Symposium on Foundations of Computer Science</source>
          (sfcs
          <year>1977</year>
          ).
          <article-title>(</article-title>
          <year>1977</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15.
          <string-name>
            <surname>Clarke</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Emerson</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Sistla</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Automatic verification of finite-state concurrent systems using temporal logic specifications</article-title>
          .
          <source>ACM Transactions on Programming Languages and Systems</source>
          .
          <volume>8</volume>
          ,
          <fpage>244</fpage>
          -
          <lpage>263</lpage>
          (
          <year>1986</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          16.
          <string-name>
            <surname>Tonetta</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <article-title>Linear-time Temporal Logic with Event Freezing Functions</article-title>
          .
          <source>Electronic Proceedings in Theoretical Computer Science</source>
          .
          <volume>256</volume>
          ,
          <fpage>195</fpage>
          -
          <lpage>209</lpage>
          (
          <year>2017</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          17.
          <string-name>
            <surname>Henke</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Fäth</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hutschenreuter</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Wuttke</surname>
          </string-name>
          , H.:
          <article-title>Gift - An Integrated Development and Training System for Finite State Machine Based Approaches</article-title>
          .
          <source>International Journal of Online Engineering (iJOE)</source>
          .
          <volume>13</volume>
          ,
          <issue>147</issue>
          (
          <year>2017</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          18.
          <string-name>
            <surname>Henke</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Vietzke</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Wuttke</surname>
            ,
            <given-names>H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ostendorff</surname>
            ,
            <given-names>S.:</given-names>
          </string-name>
          <article-title>Safety in Interactive Hybrid Online Labs</article-title>
          .
          <source>International Journal of Online Engineering (iJOE)</source>
          .
          <volume>11</volume>
          ,
          <issue>56</issue>
          (
          <year>2015</year>
          ).
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>