# The Virtual Environment

## Boolean algebra

We all know Boolean algebra. We use its rules all the time while programming. For the purpose of this note let’s write down some basics:

- a Boolean variable takes values
**true**or**false** - a Boolean expression uses three operators:
**AND**,**OR**and**NOT** - any Boolean expression can be represented by an OR combination of AND expressions
- logical statements can be expressed by Boolean expressions or truth tables.

### Example

The Boolean condition:

and its equivalent table representation:

x \ y | false | true |
---|---|---|

false | true | false |

true | false | true |

## Why use another algebra?

In software, Boolean algebra is used in control statements (`if`

, `while`

, `for`

) to determine the execution path. Boolean algebra is fine while working with 2-value (*true*, *false*) logic variables. Then, we write for instance (x is a Boolean variable):

Control statements with pure Boolean values can be replaced by tables. For instance, the condition `f`

in the above example can be replaced by a table. In the code, the table may look for instance like this:

But in software we often need to use non-Boolean variables in our logic expressions.

If the variables have more than the two possible values of *true* and *false* we have to work out the logic value using, for instance, comparison operators. We would write:

The problem which arises is that control statements with non-Boolean values cannot be replaced by tables.

We need to adapt the logic algebra that have to allow any control statement be replaced by a table.

## Definitions

### Virtual environment

VFSM concept requires a specific environment which we call a *Virtual environment*.

Variables used in software are of several types. A variable that represents a digital input stores a Boolean value (*true*, *false*). A variable that represents an analog input stores a number (for instance: *float*). A parameter stores a value that could be of any numerical type (*integer*, *float*, *string*, …). Software uses also more complex structures or objects for which the behavior or value is used in control statements. For instance, a timer or a counter stores a number which changes when it runs or counts.

Let’s analyze the true character of some variables or objects from the control statement viewpoint.

- Digital input: both its values (
*true*or*false*) are used in control statements as a direct Boolean value. For consistency with variables discussed below let’s name the two values:`DI_ON`

and`DI_OFF`

(in a specific application we will use more expressive names, reflecting their true meaning, for instance:`END_SWITCH_REACHED`

,`END_SWITCH_NOT_REACHED`

). - Analog input (a
*float*number): only a small fraction of all possible float values are used in control statements, for instance in the form:- We may “describe” the used input ranges as follows (in parentheses are examples of some application specific names):

- Timer: whether it is running or not is less interesting. The true interesting moment occurs when the timer expires after the timeout elapses. Let’s call this information
`TIMER_OVER`

, the other situations being named`TIMER_RUN`

,`TIMER_RESET`

and`TIMER_STOPPED`

.

We may say that in all cases the names represent the true control values of the above variables. The names have two interesting features. First, they are of the same “type”, they are just names. Second, the names are not Boolean values as there are, in general, several names which represent the variable control value. The value, which we name `UNKNOWN`

. The `UNKNOWN`

value is especially important for signals which are delivered from the outside world. For instance, digital or analog inputs are coming from peripheral devices. If the devices or drivers which make the link between the peripheral devices and the control software are inactive or if they malfunction the corresponding control variables have the value `UNKNOWN`

. It means that effectively, there are no true Boolean values in control software, as even the digital inputs have 3 values: `DI_ON`

, `DI_OFF`

and `DI_UNKNOWN`

.

The names of control relevant values define a *Virtual environment*.

### Operators

Control statements need Boolean values. Hence, the names must be used to produce Boolean results. To achieve this we want to combine them together using Boolean operators. There is nothing wrong with usage of AND and OR operators with their Boolean meaning. For instance, we may write:

to express the control situation: **digital input is on** or **analog input is larger than 8.1** and **timer is over**.

We cannot use the NOT operator, because the result of the Boolean negation makes sense only for true Boolean values. The result of, for instance,

would be ambiguous.

### Complement control value

To simplify the logical conditions VFSM uses the concept of complement (control) value. The complement as known in mathematics, especially in set theory defines unique values in comparison in relation to another set. In our case we use a complement of a name that belongs to the set of names that define all control values of a given input variable; the complement of a name means then “all other names”.
For example, the set of all timer control values contains: `RUN`

, `RESET`

, `STOPPED`

and `OVER`

. If we want to express all values that define the situations before the timer elapses we may use the complement value of `OVER`

: `~OVER`

. Per default the complement value gets in StateWORKS Studio the prefix `NOT_`

. The use of a name defined for a complement value leads evidently to simpler conditions than using names defined on all control values as:

Of course, you may overwrite the default name by any name that is more suitable for your application.

For more details, refer to Complement control values in the VFSM concept.

### Processing

The intention of the virtual environment is to replace software control statements with decision tables.

First of all, we assume that names of all those control values which are currently valid are held in a variable called VI (*Virtual Input*). VI is a set of all currently valid names.

On the other hand, the specification which describes the behavior of the application is represented by tables. The following representation of the logical conditions is required for the tables:

- A logical multiplication (AND operation) is represented by a set of conditions.
- A logical addition (OR operation) is represented by a table (group) of sets.

Thus, if we limit the notation to classical OR_of_AND_expressions (the term “disjunctive form” is used in Automata Theory) the processing of the control statements is done in the following way:

- Test whether a set represented by the first AND condition is a subset of the
*VI*. - Repeat this test for all sets until the answer is TRUE.
- If any AND condition is a subset of the VI the condition is fulfilled (
*true*), otherwise, it is*false*.

### Example

The following condition:

specifies some action and will be presented as a table of 2 sets:

Assume that a current VI contains the following:

Processing of VI results in a *false* result and no action is taken.

## Summary

The concept of a *Virtual environment,* as expressed by the *virtual input* and *logic algebra*, is the basis of the VFSM (virtual finite state machine) specification method in StateWOKS. We cannot use the NOT operator, but it is compensated by the availability of a complement value.

The article was originally written by author F. Wagner in April 2003

Here you can view the unedited file directly from the author: PDF