Mini-Project Specification [ ppt ]

Beer Factory

Introduction

The Beer Factory case study is an attempt to define a realistic industrial application. The Beer Factory has been inspired by a real factory in Germany and has previously been described and studied in several concurrency formalisms. In this assignment you are asked to study a version of the Beer Factory, model it in FSP, and implement it in Java.

Powerpoint project presentation: project.ppt
Report skeleton: group11.doc

---

Flow

The system: In the Beer Factory empty bottles are moved from the feed belt to the filler (which fills the bottles). When the bottles are full, they are moved from the filler to the deposit belt. Bottles are moved from the feed belt to the filler using arm A of the robot, and from the filler to the deposit belt using arm B of the robot.

The environment: A producer ('bottle boy') provides the feed belt with empty beer bottles, and a consumer (student) consumes the beer bottles.

---

Components

Producer: Repeatedly attempts to place bottles onto the feed belt.

Belt: Has a motor that advances the belt. The belt has 3 positions; bottles may be placed at position 1 and removed from position 3. Two problems may occur; a bottle can be placed on top of another (smashing it), and a bottle can fall off the edge from position 3 (smashing it). Two sensors detect the presence of bottles at positions 1 and 3, respectively.
[HINT: In reality, the sensors and the belt are physically positioned such that the sensors are triggered when bottles are at appropriate locations. In FSP and Java, you may let the belt turn the sensors on.]

Robot: Has a rotation motor and arms A and B which are fixed at an angle of 90 degrees. The arms of the robot are capable of rotating 180 degrees; arm A may move from the feed belt to the filler (at which point arm B will be at the deposit belt). The arms cannot move beyond these positions. The arms are equipped with 'grabbers' that may grab or drop bottles. The grabbers should never drop bottles on the floor.

Filler: The filler fills the bottles. A more detailed description is intentionally left out (this is part of the exercise and you need to include it in the report).

Consumer: Repeatedly attempts to take bottles from the deposit belt.

---

Safety issues

The erroneous behavior of the system (e.g. bottles smashing) should be explicit in both your model and your implementation, i.e. using ERROR in FSP and Exceptions in Java.

To ensure correct behavior of the system, a number of controllers are needed (you need to figure out which and model and program them). This image shows two example controllers (a feed belt controller and a robot controller).

Safe behavior of the system should be verified in the model using appropriate safety and liveness properties.

---

Notes

• There is no one "true" canonical solution (which processes are active/passive, the number and placement of controllers, ...)!
• The implementation should pass around actual Bottle objects:

  Bottle.java
  class Bottle { protected boolean full; Bottle() { full = false; } void fill() { full = true; } void drink() { full = false; } boolean isEmpty() { return !full; } }

---

2 Group presentations

Every group is required to do a max. 10 minute presentation of their project status on tuesday May 4 and on tuesday May 11 (12:00 - 16:00 at IHA, room #424). These presentations will be scheduled later. The idea is that you present to us what you have done so far (i.e., not a complete solution) and what you are thinking about doing next. This will make sure that you have thought enough about the project to be able to explain it to others. It is also a chance for you to get feedback and answers to specific questions you might have. This is not an exam (and will not count in the evaluation of your project).

---

What you are required to do and hand-in

Model+Implementation Deadline (May 17 at 12:00):

1. Design a model of the beer factory in FSP.
2. Draw a structure diagram.
3. Specify and check relevant safety and liveness properties.
4. Draw a UML class diagram.
5. Implement the model in Java.

The model+implementation hand-in must be sent to us by email (by one member of the group) with the subject "Group 11" and with one attachment in the form of an archive (in either ".zip" or ".tar.gz|.tgz" format) containing the following files:

group11.{zip|tar.gz|tgz}:
group11/ // directory with your group number - which is NOT 11 :) group11/factory.lts // including comments(!!!) and validated(!) safety and liveness properties! group11/structure_diagram.{gif|jpg} // cf. [MK 3.1.6], ignoring safety properties group11/class_diagram.{gif|jpg} // UML class diagram group11/*.java // only ".java" files (i.e. NOT ".class" files)

Report Deadline (May 21 at 14:00):

• Document your choices and experiences thoroughly in a report. The report should be based on the group11.doc report skeleton.

You are required to hand in three hardcopies and one electronic version sent by email to us (subject: Group 11) in PDF or Word format. We will be ready (= wish beer'n'chips :) to receive the hand-ins on Friday at 14:00 in the Turing.016 room (IT Parken). If you want to hand-in earlier, you can put the hardcopies into the red vote-box located in the hallway of the Babbage building (Babbage-101) near the information office (Ada-115), no later than May 21, 2004 (14:00).

---

Project evaluation

The project will be evaluated and graded (on the usual 13-scale) by us. However, it will only count as passed/not passed on your exam record.

---

Calendar

april/maj 2004 -------------------- M T O T F L S 26 27 28 29 30 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 // //

---

Deadlines

Model+Implementation: days hours minutes seconds Report: days hours minutes seconds