18649 - Behavioral Requirements I
System Objects and Message Dictionary
18649 Spring, 2010
Group 7 - Justin Ray/justinr2
Table of Contents
Soda Machine High-Level Requirements
R1.
Pushing a button shall vend a soda of the type corresponding to that
button.
R2. The machine shall permanently retain exactly SODACOST coins for
each
can of soda vended.
R3. Coin return shall return all deposited coins since the last vend
cycle.
R4. The machine shall return all deposited money in excess of SODACOST
coins
before a vend cycle.
R5. The machine shall flash the button light for a selected item
while
vending is in progress to indicate acceptance of a selection to the
buyer.
R6. In a quiescent state, the machine shall illuminate the light for
any in-stock item
Soda Machine Description
The soda machine can hold up to 8 different types of soda in separate
chutes. The chutes are arranged side-by-side and each is 100mm
wide.
The vend unit is mounted on a track which moves it between the
chutes. The vend unit must be centered on the track, thus the
track is only 700mm long and is positioned so that the left-most end is
aligned with the center of the first chute.
The coin counter accepts only quarters and automatically returns any
coin not recognized as a quarter.
Soda refill and money collection is done manually.
Notation
Replication Notation
- s - soda index, 1-8.
- d - motor direction, LEFT, RIGHT, STOP.
"[...]" indicates an array of objects or values. There
are 8 valid positions, so there are 8 separate and distinct Empty[p]
sensors, one at each soda chute.
"(...)" indicates a list of values associated with a
sensor/actuator. Single-valued inputs/outputs can have the "("
and ")" omitted as a notational convenience.
The suffixes "_up", "_down", "_front", and "_back" may be used in
lieu of a direction subscript, to make things more readable. e.g.:
Empty_1 means Empty[1]
and so on...
Multi-attributed items may have a particular state referred to by
concatenating elements, although this system has no multiattribute
objects.
Single attributes of a multi-attribute item are referred to using
"." notation. For example DesiredFloor.f refers to attribute "f"
of "DesiredFloor".
If a letter instead of a value is used in a subscript, it is
assumed that it can take any valid value. If the same letter is
used in multiple clauses within a single requirement element, it is
assumed that the letter takes the same value in all instances.
For example, in the phrase:
"Empty[s] ... ButtonControl[s] ... VendPosition[t]"
The Position p for Empty and ButtonControl can be any valid
position, but would have to be the same position. However, the
position for VendPosition might or might not be
the same since it is a different
symbolic letter.
In the context where the 's' value denotes a type of soda, the value
NONE may be used to indicate that no soda is present or no type
selected.
Replication in Sequence Diagrams
Replication is a problem in UML Sequence Diagrams. Rather than
introducing an attempt at formal notation (which gets very confusing
quickly), we will resort to using comments when multiple instances of
something are supposed to be coordinated (e.g., "wait for all doors to
close" will be a text comment in Sequence Diagrams, but shall be
represented rigorously in behavioral requirements).
Replication in Behavioral Requirements
Because the controllers are written in a generic way, it's
important to pay attention to the way the replication notation is used
in the behavioral requirements. Here are some general guidelines:
- "if all VendPosition[*] are false" - This statement is considered
false if every VendPosition sensor (1-8) is false.
- The "if any" semantic is not used in the soda machine because
there are no sensors where two or more can be true simultaneously.
Misc Notation
SODACOST is an integer value that represents the number of coins
needed to purchase a soda. In this case, the value of SODACOST is
2.
Initialization
Because ultimately we will do this all in simulation, we're going
to make your life easy by telling you the initial state of the system
(the "initialization" state) such as putting the VendMotor at position
1 at startup and no coins being held in the system.
System Elements
This section describes the elements of the system that are already
provided
The VendCarriage
The notation "VendCarriage" (or VC) refers to the part of the soda
machine that moves left and right to align the Vend actuator with a
particular soda chute. The movement of the VC itself is hidden
within the
environment model, so it can only be observed through sensors and
controlled through actuators.
Physical State Sensors
These objects are instantiated in the system but do not have a network
interface. These objects must be read through the physical
interface of a controller.
- Button[s](v): Soda
selection button.
- v={True, False}.
- One button per type of soda. All are False at
initialization. S is an integer 1..8
- Button[s](True) is sent when button s is depressed;
Button[s](False) is sent when button s is released.
- The button sensors have a physical interlock that prevents more
than one being pressed at a time.
- CoinIn(v): Pulsed True
when a
quarter has been put into the soda machine.
- v={True, False}.
- A pulse (False-True-False) occurs ever time a coin is inserted
into the machine. This pulse shall last for a minimum of 200ms.
- Initialized to be False.
- Note that the machine will
permanently
retain any inserted coin unless the CoinOut(v) actuator is activated
(this is a
simplification of real soda machine operation).
Smart Sensors
These sensor values are available for use by the control system.
The below-listed values will correspond to network messages in the
implementation phase.
Note: If an object that sends a network message is not
instantiated (such as a chute s that is removed for maintenance),
then no network message with that CAN id is ever sent.
- Empty[s](v): Item empty
sensor.
- v={True, False}.
- One empty sensor per type of soda vended. True when out
of stock. S is an integer [1]..[8]
- One per type of soda. Initialized to be False.
- CoinReturn(v): The coin
return button or switch
- v={True, False}.
- True when coin return switch is activated. Remains true
for a minimum of 200ms.
- Initialized to be False.
- VendPosition[s](v):
indicates the location of the VC.
- v={True, False}.
- One smart sensor positioned at teach soda chute. The
sensors are arranged in order with index 1 on the left-most chute.
- True when the VC is within 20mm of the corresponding soda
chute center.
- Only one VendPosition sensor can be true at a time.
Environmental-Only System State:
These values keep track of current system state. They are not
accessible to the
control system, but have been used in the specifications for building
the simulation system.
- SodaCount[s](n): The
number of sodas in each chute.
- Each count is set to 50 at startup.
- CatchBinContents(s): The
CatchBin models the tray that vended sodas drop in to.
- The
value 's' denotes the soda in the catch bin. NONE denotes an empty
catchbin.
- The
CatchBin can hold one soda. If the catchbin is not empty when a
vend occurs, the new soda displaces the old one and old soda falls on
the
"floor" (out of the system).
- CoinTrayContents(n): the
number of coins in the coin return tray.
- CoinTrayContents takes a value n >= 0.
- VCPosition(x): Position of VC on its track. x
= {integer 0..600 } in millimeters
- Tracks the position of the vc.
- Set to 0 at initialization
System Actuators
The below-listed values will correspond to network messages in the
implementation phase. All actuators are assumed to "remember"
their last commanded value and stay there unless commanded otherwise or
forced otherwise by system/environment constraints.
- ButtonLight[s](v): this
is the
light that illuminates the entire button with the soda logo on it
- v={True, False}.
- One per type of soda. When set to True turns on the light in
the button for soda s; when set to False turns that light off. S
is an
integer 1..8
- All lights set to False at initialization.
- CoinOut(v): Returns
exactly one coin per pulse.
- v={True, False}.
- Initialized to be False.
- pulse (false-true-false) must be at least 150ms in duration.
- Vend(v): Vend soda if
True.
- v = {True, False}.
- One per type of soda. When set to True vends a single can of
soda. S is an integer 1..8
- Initialized to be False.
- v must remain true for at least 500ms to completely actuate the
vend mechanism.
- We assume the vend actuator is self-centering and can operate
correctly if positioned within 20mm of the chute center.
- VendMotor(d): Moves the
VC between the chutes.
- Values of d are {LEFT, RIGHT, STOP}.
- The track for the VC is constructed in such a way that the
left-most extreme position is aligned with chute 1 and the rightmost
extreme position is aligned with chute 8.
- A physical interlock prevents damage to the motor when the VC
reaches the end of the track.
- When activated (LEFT or RIGHT), the Vend Motor moves at a
constant speed of 200 mm/s.
- We assume that the motor can start and stop instantaneously
when
commanded to do so.
Environmental-Only Actuators
No environment-only actuators in this system.
Control System Objects
In addition to the objects described above, there are several complex
control system objects. These objects are summarized below.
The detailed specification of these objects can be found in the Behavioral Requirements II
document.
Environmental objects have already been designed and are provided by
the system. The other control objects will be the primary focus
of your design effort.
- ButtonControl[s]
- One per soda selection (S is an integer [1]..[8])
- Controls button lights
- Controls sending button selections to VendControl
- CoinControl
- Controls coin return dispenser
- VendControl
- Controls dispensing the soda cans
- VendPositionControl
- Controls the movement of the VC
Network Message Dictionary
This section defines the network messages that may be sent. The
design MUST follow the message dictionary. Following the message
dictionary means:
- Every message defined in the message dictionary is sent.
- No message not defined
in the message dictionary is sent.
- Each message carries the information described in the dictionary.
Environmental Object Messages
These messages are sent by environmental objects and smart sensors
provided in the system
Source Node Name
|
Message Name |
Replication
|
Number of fields
|
Description
|
Empty
|
mEmpty |
s
|
1
|
See Object Description |
| Coin_Return |
mCoinReturn |
none
|
1
|
See Object Description |
VendPosition
|
mVendPosition
|
s
|
1
|
See Object Description |
Controller Messages
These messages are sent by the controllers that you will design.
In the later projects, you will be allowed to modify the message
dictionary for the controllers in a limited way, but for the time
being, you must implement the message dictionary given below:
Source Node Name
|
Message Name |
Replication
|
Number of Fields
|
Description |
| ButtonControl |
mButton
|
s |
1
|
State of the soda selection button
|
VendControl
|
mVend |
none
|
1
|
True when vending a soda
|
CoinControl
|
mCoinCount
|
none
|
1
|
Integer number of coins received
|
VendPositionControl
|
mVendMotor
|
none
|
1
|
State of the vend motor
|