Iteration 4 Deliverables

[withaspirit]

Milestone Description

For this iteration, you will be adding code for detecting and handling faults. To this end, you will have to add timing events so that if the timer goes off before an elevator reaches a floor, then your system should assume a fault (either, the elevator is stuck between floors, or the arrival sensor at a floor has failed). Similarly, you should detect whether a door opens or not, or is stuck open. In Iteration 5 below, your elevator status output should show these faults. A door which has not closed should be regarded as a transient fault, so your system should be able to handle this situation gracefully (unlike the LRT). However, the floor timer fault should be regarded as a hard fault and should shut down the corresponding elevator.

You must submit code to enable us to see that your elevator scheduler can deal properly with the faults shown above (i.e., you must be able to inject these faults into the system). I suggest that you inject these faults using the input file (so you will have to modify its format and be able to show to us how it works).

• Work Products for Iteration 4
  • “README.txt” file explaining the names of your files, set up instructions, etc.
  • Breakdown of responsibilities of each team member for this and previous iterations
  • Any unchanged diagrams from the previous iterations UML class diagram
  • Timing diagrams showing the error scenarios for this iteration
  • Detailed set up and test instructions, including test files used
  • Code (.java files, all required Eclipse files, etc.

Iteration 3 Leftovers

• Elevator Movement properties modification @Bnortron
  • [ ] Add JUnit tests for cases like stopping after reaching a correct floor, that Elevator is still moving at a certain point, etc.
  • [x] Update ElevatorMotorTest
• RequestQueue Update @julian-carleton
  • [ ] Ensure all JUnit Tests still work properly
  • [ ] Ensure Elevator still visits Floors in a proper order (see Elevator Request + ServiceRequest cases)
  • [ ] Change RequestQueue structure if necessary
• Elevator Service Algorithm Update
  • [ ] Fully implement and test the Elevator Service Algorithm for all types of requests.
  • [x] #156
  • [x] #157
• Testing Message Transfer
  • [ ] Test that transfer of each type of event between ElevatorSubsystem, Scheduler, FloorSubsystem, is succesful
• Optional Refactoring
  • [x] #111 - Add terminate thread condition to prevent lag after all requests have been processed
  • [ ] Change Elevator and Floor to have addSubsystem() methods or give them a constructor without subsystem instead of having their respective subsystems in their constructors (better for testing and could eliminate the need for the "toggleMessageTransfer()" method in Elevator by simply having a check for whether elevatorSubsystem is null)
  • [ ] Find new name for ElevatorSubsystem, FloorSubsytem
  • [ ] Rename Client -> ClientServer ???
  • [x] #164, BoundedBufferTest, SubsystemMessagePasser
  • [x] Fix ElevatorSelectionTest (currently bugged, loops infinitely) #155
• Multiple Elevator Functionality
  • [x] 3 Programs working #158
  • [ ] Add JUnit tests where Structure has a varying number of Elevators and they all fulfill all their requests
  • [x] README instructions on how to run program (order mains should be run) and how to run In IntelliJ with MultiRun plugin
• Elevator Monitor
  • [x] toString() method #160
  • [x] Insert sendElevatorMonitor method before elevator movement AND before approachEvent is sent (not clear when it should be sent)
  • [ ] queueTIme replace (???)
• Doors
  • [ ] Update Movement Algorithm with doors:
  • [x] Change State.CLOSE to State.CLOSED
  • [x] Add State.STUCK
  • [x] Change doors' default state to State.OPEN
  • [x] add areClosed(), areStuck(), areOpen() methods
  • [x] add doors.setToStuck() method
  • [x] Elevator: put doors.open(), doors.close() statements where appropriate (in commented out code)
  • [x] Elevator: update printStatus to also display doors state
  • [x] Doors: rename closedoors and opendoors to close() and open(), respectively
  • [ ] JUnit Tests:
    • Doors open:
    • [ ] after processing request whose floor is the elevator's current floor
    • [ ] after moving to a floor that is the request floor
    • [ ] after attempt to stop completes
    • Doors closed:
    • [ ] moved to floor that is not request floor
    • [ ] Moving, and received request that is the same as the request floor
    • [ ] After attempt to start moving completes

Iteration 4 Breakdown

Major Goals

• [x] Elevator has Travel time (time it is moving between floors)
• 2. Doors have open/close time
• [x] Determine how many faults / errors there should be
  • At Least
  • Arrival sensor Fail (Scheduler/ArrivalSensor fault) - (Elevator fails to receive ApproachEvent before its travel time has passed)
  • Doors Interrupted (Transient Fault) (Such as when someone sticks their foot in)
  • Elevator Stuck (Mechanical Fault) (could occur when an elevator is interrupted while it is MOVING between floors or is STOPPED)
  • Doors stuck (Mechanical Fault) Doors not opening or closing
• [x] Devise system / methods for handling faults
• [x] Implement fault handling behavior
• ArrivalSensors have list of ServiceRequests that it can compare any received ApproachEvent to, and then confirm whether the Elevator should stop accordingly

Work Breakdown

• [x] Determine fault handling method
  • [x] Tentative: using a mixture of Thread.interrupt, wait timeouts, and flag checking
  • [x] #186
• ArrivalSensor Integration
• [x] ArrivalSensor has a list of ServiceRequests/some data structure
  • After receiving an ApproachEvent, return true if the ApproachEvent's properties match one of the ServiceRequests in the list
  • [ ] Change the Movement Algorithm so that it relies on receiving an ApproachEvent with a true value to stop before it can stop at a floor
  • [x] Test that arrival sensor SystemEvent are being correctly compared to serviceRequests
  • [ ] Get Scheduler to remove all requests for an elevator from ArrivalSensors once the elevator has shut down
• Restructure Elevator
  • Elevator is 500+ lines - Generally, a class should be on average ~50-300 lines.
  • [ ] Determine if Elevator's acceleration and other constant properties should be moved out of the Elevator class to reduce clutter
• [x] Add #178
  • [x] ELEVATOR_STUCK
  • When an elevator car gets stuck between floors
  • [x] Elevator should shut down
    • [x] Determine behavior when Elevator MOVING #185
    • [x] Determine behavior when Elevator STOPPED
    • [x] Set MovementState to STUCK, inform Scheduler so no more requests are added
    • [ ] Ensure Scheduler does not select STUCK elevator
    • Implement Behavior
  • [x] DOORS_INTERUPPTED
  • Soft fault that occurs when doors are closing.
  • [x] If the doors are interrupted while closing, they should start opening again #185
  • [x] ARRIVAL_SENSOR_FAIL
  • Elevator fails to receive ApproachEvent before its TravelTime has expired
  • [x] Determine what happens (soft or hard fault?)
  • [x] DOORS_STUCK:
  • "Similarly, you should detect whether a door opens or not, or is stuck open."
  • [x] Determine what happens
  • [x] Implement Behavior #185
• Elevator Travel Time
  • Elevator’s time moving from one floor to another
  • [x] Make elevator TravelTime an attribute that can be modified #186
  • [x] Add the "Travel time off" toggle to JUnit tests where appropriate #176
  • [x] Add logic for Travel time into Elevator #176
  • [x] Add JUnit test for Travel Times
  • [ ] Incorporate into ElevatorSelectionAlgorithm
• Doors Open / Close Time Logic
  • [x] Make doorTime an attribute that can be modified #186
  • [x] Determine how an "Open / Close door" button press would affect Elevator
• *Doors Open / Close time Implementation
  • [x] Add a wait statement for opening / closing door methods #182
    • [x] Modify JUnit tests to include / exclude door loading time as necessary
• Elevator Travel Logic
  • [x] Identify what happens when, during time Elevator is moving
• Misc
  • Idea: When a request is added to an Elevator, it should be added to an arraylist. After each time an Elevator has reached a floor, it puts all the requests on the arraylist into the RequestQueue
  • Alt: Elevator Selection Algorithm: When the chooseElevator method sees that an Elevator is MOVING/ACTIVE, it considers the Elevator's nextFloor to be its "currentFloor"
  • [ ] Add Origin back to Client constructor: would increase compatibility for a possible many-to-one Elevator/Floor to Scheduler structure in the future
  • [ ] Delete FloorRequests, replace with ServiceRequests - no longer needed now that Systemevent has elevatorNumber
• Scheduler Refactor (Optional)
  • [ ] Move Elevator's serviceDirection and RequestQueue to Scheduler. From there, Scheduler should issue commands to Elevator.

Documentation

• [x] GitHub Release
• [x] ReadMe
  • [x] (update) Detailed set up and test instructions, including test files used
  • [x] Breakdown of responsibilities of each team member for this iteration
  • [x] General description of system
  • [x] Explaining the names of your files, set up instructions, etc
• [x] Diagrams
  • [x] Timing diagrams showing the error scenarios for this iteration
  • [x] Updated UML class diagram
  • [x] Insert into README
  • [x] State Machine Diagrams
  • [x] Insert into README

[withaspirit]

The requirements say "I suggest that you inject these faults using the input file (so you will have to modify its format and be able to show to us how it works."

I talked to one if we could do this instead, and they said it was reasonable:

• We could simply have test classes where we start the system normally, and then trigger failures through code in the test class.

It would require that we have whatever timers are relevant enabled for the Elevator.

[withaspirit]

• [ ] Find new name for ElevatorSubsystem, FloorSubsytem

The "Subsystem" name isn't accurate because it implies composition relationship between XSubsystem and X classes. What do you guys think? Should we do a more suitable name? Leave as is?

@ryandash @julian-carleton @RamitMahajan @julian-carleton