CIF 3

Sensors and actuators

Except for some limit switches and the emergency buttons, no button or other sensor controls anything directly. There is very little hard-wired logic in the workstations. Control has to be done through the supervisor that you synthesize, and works directly on the low level sensors and actuators.

Each of the systems has a user interface, with several sensors and actuators. Other common actuators include pneumatic cylinders, and electromotors. Each pneumatic cylinder usually has two binary digital sensors to show its current state (retracted, moving, extended). Depending on the type of cylinder it has one or two (independent) digital binary actuators. Electromotors are usually controlled by two binary digital actuators: one that turns the motor on or off, and one that determines the direction of movement (up/down or left/right).

Most of the sensors are digital binary sensors, so they will always be in one of two possible states: on or off. The test station is the only workstation with an analog sensor, with which the thickness of the product is measured.

Names

Each sensor and actuator has its own specific name. If you look at the physical workstations more closely, you will see labels attached to both the sensors and the actuators of the system. When you are modeling your plants and requirements, you should use the correct names of the events associated with the sensors and actuators. If you don’t use the correct names, you can’t use the scripts and other course files to automatically couple your synthesized supervisor to the simulation model, hardware description, etc. The descriptions of each of the workstations have more detailed information on the available sensors and actuators, and the names of their corresponding events. Event names (and almost all other names) are case sensitive!

The event names are composed of the name of the automaton in which they are defined, and the name of the actual event. For instance, for the Button1.u_pushed event, you should create a plant automaton named Button1 with an uncontrollable event named u_pushed. This is an example of a digital binary sensor. For more information, and an example of a whole plant automaton, see below.

Digital binary actuators

All digital binary actuators (or just digital actuators) have two corresponding controllable events: one to turn the actuator on (enable it), and one to turn the actuator off (disable it). An actuator will remain on until its corresponding off event occurs, and vice versa. As long as none of its two events occurs, the actuator will remain in its current state.

The semantics of the events of the digital actuators is so that it is not possible to turn on an actuator, while it is already on. That is, turning the actuator on and off occur in alternating sequences. An alternative semantics would be to always allow the actuator to be turned or off, and event allow it to be turned on (or off) multiple times in a row. Turning the actuator on or off, while it is already respectively on or off, would then have no effect.

When modeling the plant for a digital actuator however, it is better to choose the former semantics. This fits better with the intuition: an actuator (such as a lamp) can be turned on, and it can be turned off, but it cannot be turned on while it is on, since it is then already on. More importantly, it fits with the semantics of events: they signal a change in state (turning the actuator on or off), and not that an actuator is in a certain state (the actuator is on or off).

Here is an example of a lamp plant modeled in CIF 3:

plant Lamp:
  controllable c_on, c_off;

  location Off:
    initial; marked;
    edge c_on goto On;

  location On:
    edge c_off goto Off;
end

Digital binary sensors

All digital binary senors (or just digital sensors) have two corresponding uncontrollable events: one that indicates the sensor has gone on (has been enabled), and one to that indicates the sensor has gone off (has been disabled). That is, the event for the sensor going on, means that the sensor was off and is now on. The event represents the ‘off to on’ state change. Similarly, the event for the sensor going off, means that the sensor was on and is now off. Each inversion of the sensor signal corresponds with a single event transition.

A sensor will remain on until its corresponding off event occurs, and vice versa. As long as none of its two events occurs, the sensor will remain in its current state. Thus, the semantics of the events of the digital sensors is so that it is not possible for the sensor to go on, while it is already on. That is, the sensor goes on and off, in alternating sequences. This semantics is called sensor tracking semantics, as an uncontrollable events occurs each time the sensor changes value, thereby keeping track of the current value of the sensor. It is also called pushing semantics, as events occur whenever the value of the sensor changes, and the controller has to handle such events, whether it wants to or not.

An alternative semantics involves one controllable event to request the sensor status, and two possible uncontrollable response events. This semantics is called request/response semantics. The controller needs to request the value of the sensor, and gets one of the two responses (on or off), depending on the current value of the sensor. If the sensor is on at the time of the request, the event corresponding to the sensor going on will be enabled, otherwise, the event corresponding to the sensor going off will be enabled. Each request results in exactly one of the two uncontrollable response events. This semantics is also called the polling semantics, as the controller actively asks for the status of the sensor.

For each digital sensor, one of the semantics must be used, but not both of them. You may however choose different semantics for different digital sensors. Note that for most sensors, the first semantics is the best choice, as it fits better with the intuition: a sensor (such as a button) can go on (be pushed), and go off (be released), but it cannot go on while it is on, since it is then already on. More importantly, it fits with the semantics of events: they signal a change in state (the sensor going on or off), and not that a sensor is in a certain state (the sensor is on or off). The second semantics can be useful if the uncontrollable events occur frequently, causing the computer to be behind on processing the incoming signals, possibly leading to missing events (and thus state changes). In such a case, the request/response semantics makes sure that the sensor signal has to be checked only after a request, which significantly reduces the bookkeeping needed by the computer or software or hardware implementation.

However, when modeling the plant for a digital sensor for the 4K420 course, always use the first semantics (sensor tracking), as that allows the provided hardware mapping to be used.

Here is an example of a button plant modeled in CIF 3, using sensor tracking semantics:

plant Button:
  uncontrollable u_pushed, u_released;

  location Released:
    initial; marked;
    edge u_pushed goto Pushed;

  location Pushed:
    edge u_released goto Released;
end

Analogue thickness sensor

The thickness measurement probe of the test station is connected to an A/D-converter, which delivers a 12-bit value as a measure for the height of the product. Conversion to millimeters is done in the hardware mapping provided as part of the 4K420 course files.

The thickness sensor is modeled by means of a controllable event to request the sensor status, and three possible uncontrollable response events: one for too low or too thin (less than 24 mm), one for OK or correct thickness (24 mm to 26 mm), and one for too high or too thick (more than 26 mm). This semantics is similar to the request/response semantics of the digital binary sensors, only with three instead of two possible responses.