deterministic_automata.rst 6.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184
  1. Deterministic Automata
  2. ======================
  3. Formally, a deterministic automaton, denoted by G, is defined as a quintuple:
  4. *G* = { *X*, *E*, *f*, x\ :subscript:`0`, X\ :subscript:`m` }
  5. where:
  6. - *X* is the set of states;
  7. - *E* is the finite set of events;
  8. - x\ :subscript:`0` is the initial state;
  9. - X\ :subscript:`m` (subset of *X*) is the set of marked (or final) states.
  10. - *f* : *X* x *E* -> *X* $ is the transition function. It defines the state
  11. transition in the occurrence of an event from *E* in the state *X*. In the
  12. special case of deterministic automata, the occurrence of the event in *E*
  13. in a state in *X* has a deterministic next state from *X*.
  14. For example, a given automaton named 'wip' (wakeup in preemptive) can
  15. be defined as:
  16. - *X* = { ``preemptive``, ``non_preemptive``}
  17. - *E* = { ``preempt_enable``, ``preempt_disable``, ``sched_waking``}
  18. - x\ :subscript:`0` = ``preemptive``
  19. - X\ :subscript:`m` = {``preemptive``}
  20. - *f* =
  21. - *f*\ (``preemptive``, ``preempt_disable``) = ``non_preemptive``
  22. - *f*\ (``non_preemptive``, ``sched_waking``) = ``non_preemptive``
  23. - *f*\ (``non_preemptive``, ``preempt_enable``) = ``preemptive``
  24. One of the benefits of this formal definition is that it can be presented
  25. in multiple formats. For example, using a *graphical representation*, using
  26. vertices (nodes) and edges, which is very intuitive for *operating system*
  27. practitioners, without any loss.
  28. The previous 'wip' automaton can also be represented as::
  29. preempt_enable
  30. +---------------------------------+
  31. v |
  32. #============# preempt_disable +------------------+
  33. --> H preemptive H -----------------> | non_preemptive |
  34. #============# +------------------+
  35. ^ |
  36. | sched_waking |
  37. +--------------+
  38. Deterministic Automaton in C
  39. ----------------------------
  40. In the paper "Efficient formal verification for the Linux kernel",
  41. the authors present a simple way to represent an automaton in C that can
  42. be used as regular code in the Linux kernel.
  43. For example, the 'wip' automata can be presented as (augmented with comments)::
  44. /* enum representation of X (set of states) to be used as index */
  45. enum states {
  46. preemptive = 0,
  47. non_preemptive,
  48. state_max
  49. };
  50. #define INVALID_STATE state_max
  51. /* enum representation of E (set of events) to be used as index */
  52. enum events {
  53. preempt_disable = 0,
  54. preempt_enable,
  55. sched_waking,
  56. event_max
  57. };
  58. struct automaton {
  59. char *state_names[state_max]; // X: the set of states
  60. char *event_names[event_max]; // E: the finite set of events
  61. unsigned char function[state_max][event_max]; // f: transition function
  62. unsigned char initial_state; // x_0: the initial state
  63. bool final_states[state_max]; // X_m: the set of marked states
  64. };
  65. struct automaton aut = {
  66. .state_names = {
  67. "preemptive",
  68. "non_preemptive"
  69. },
  70. .event_names = {
  71. "preempt_disable",
  72. "preempt_enable",
  73. "sched_waking"
  74. },
  75. .function = {
  76. { non_preemptive, INVALID_STATE, INVALID_STATE },
  77. { INVALID_STATE, preemptive, non_preemptive },
  78. },
  79. .initial_state = preemptive,
  80. .final_states = { 1, 0 },
  81. };
  82. The *transition function* is represented as a matrix of states (lines) and
  83. events (columns), and so the function *f* : *X* x *E* -> *X* can be solved
  84. in O(1). For example::
  85. next_state = automaton_wip.function[curr_state][event];
  86. Graphviz .dot format
  87. --------------------
  88. The Graphviz open-source tool can produce the graphical representation
  89. of an automaton using the (textual) DOT language as the source code.
  90. The DOT format is widely used and can be converted to many other formats.
  91. For example, this is the 'wip' model in DOT::
  92. digraph state_automaton {
  93. {node [shape = circle] "non_preemptive"};
  94. {node [shape = plaintext, style=invis, label=""] "__init_preemptive"};
  95. {node [shape = doublecircle] "preemptive"};
  96. {node [shape = circle] "preemptive"};
  97. "__init_preemptive" -> "preemptive";
  98. "non_preemptive" [label = "non_preemptive"];
  99. "non_preemptive" -> "non_preemptive" [ label = "sched_waking" ];
  100. "non_preemptive" -> "preemptive" [ label = "preempt_enable" ];
  101. "preemptive" [label = "preemptive"];
  102. "preemptive" -> "non_preemptive" [ label = "preempt_disable" ];
  103. { rank = min ;
  104. "__init_preemptive";
  105. "preemptive";
  106. }
  107. }
  108. This DOT format can be transformed into a bitmap or vectorial image
  109. using the dot utility, or into an ASCII art using graph-easy. For
  110. instance::
  111. $ dot -Tsvg -o wip.svg wip.dot
  112. $ graph-easy wip.dot > wip.txt
  113. dot2c
  114. -----
  115. dot2c is a utility that can parse a .dot file containing an automaton as
  116. in the example above and automatically convert it to the C representation
  117. presented in [3].
  118. For example, having the previous 'wip' model into a file named 'wip.dot',
  119. the following command will transform the .dot file into the C
  120. representation (previously shown) in the 'wip.h' file::
  121. $ dot2c wip.dot > wip.h
  122. The 'wip.h' content is the code sample in section 'Deterministic Automaton
  123. in C'.
  124. Remarks
  125. -------
  126. The automata formalism allows modeling discrete event systems (DES) in
  127. multiple formats, suitable for different applications/users.
  128. For example, the formal description using set theory is better suitable
  129. for automata operations, while the graphical format for human interpretation;
  130. and computer languages for machine execution.
  131. References
  132. ----------
  133. Many textbooks cover automata formalism. For a brief introduction see::
  134. O'Regan, Gerard. Concise guide to software engineering. Springer,
  135. Cham, 2017.
  136. For a detailed description, including operations, and application on Discrete
  137. Event Systems (DES), see::
  138. Cassandras, Christos G., and Stephane Lafortune, eds. Introduction to discrete
  139. event systems. Boston, MA: Springer US, 2008.
  140. For the C representation in kernel, see::
  141. De Oliveira, Daniel Bristot; Cucinotta, Tommaso; De Oliveira, Romulo
  142. Silva. Efficient formal verification for the Linux kernel. In:
  143. International Conference on Software Engineering and Formal Methods.
  144. Springer, Cham, 2019. p. 315-332.