Part A.1.1 Use case diagram

Part A.1.2 Short Use Case Descriptions

UC1 – Submit Job – when the WMS issues a storeLoad or a retrieveLoad request, a job is created and scheduled. The job is added to a crane’s job list, and a job number is returned to the WMS.

UC2 Cancel Job* – the WMS can issue a cancelJob request if a job has been scheduled but not yet completed. When a cancelJob request is received, the crane ceases its current activity, and returns its load to where it originated – either the loading bay if the job was a storeLoad, or the storage slot if the job was a retrieveLoad.

UC3 Track Job - as part of the monitoring the warehouse, the status of every job must be tracked. Also, if the optional job tracking service of the WMS is enabled, the WMS must be notified of every change in job status.

UC4 – Manual Store Load – when the crane driver selects a Store Load job, information about the job is displayed. The crane moves to the loading bay. If the load type is a pallet, the driver allows the crane to scan the pallet barcode and pick up the load. If the load type is cartons, the driver must manually scan the carton’s barcodes, and load the cartons onto the crane. The driver then signals the crane to transport the pallet to the designated storage slot. If the load type is a pallet, the crane then automatically insert it into the slot, but if the load type is cartons then the crane driver must again scan the barcodes on the cartons and manually load them into the storage slot. Finally the driver confirms that the job has completed, the storage slot’s usage is updated,\ and the crane’s joblist is redisplayed.

UC5 – Manual Retrieve Load – when the crane driver selects a Retrieve Load job, information about the job is displayed. The crane moves to the designated storage slot. If the load type is a pallet, the driver allows the crane to scan the pallet barcode and extract the load. If the load type is cartons, the driver must manually scan the carton’s barcodes, and load the cartons onto the crane. The driver then signals the crane to transport the pallet to the loading bay and the storage slot’s usage is updated. If the load type is a pallet, the crane then automatically sets the pallet down, but if the load type is cartons then the crane driver must again scan the barcodes on the cartons and manually unload them into the loading bay. Finally the driver confirms that the job has completed and the crane’s joblist is redisplayed.

UC6 – Auto Store Load – when the crane controller initiates a Store Load job, the crane moves to the loading bay. The crane scans the pallet barcode and picks up the load. The crane then transports the pallet to the designated storage slot, automatically inserts it into the slot, and the storage slot’s usage is updated. Finally the crane’s joblist is updated, and the crane controller is notified that the job is complete.

UC7 – Auto Retrieve Load – when the crane controller initiates a Retrieve Load job, the crane moves to the designated storage slot. The crane scans the pallet barcode, extracts the load, and the storage slot’s usage is updated. The crane then transports the pallet to the loading and automatically sets the pallet down. Finally the crane’s joblist is updated, and the crane controller is notified that the job is complete.

UC8 - Monitor Warehouse – when the operator is on duty, they continually monitor the warehouse. The system displays a list of pending jobs and information about each crane including its current status.

UC9 - Control Crane – if required, the operator can remotely interrupt a crane’s current activity and return it to the loading bay.

UC10 - Navigate Crane – as part of the storeLoad and retrieveLoad operations, a crane must navigate to and from the loading bay. The correct sequence of commands must be calculated and issued at the correct times.

*It is not clear from the case study whether a cancelJob request can be issued for a ‘retrieveLoad’ operation. It seems sensible that it could be, and so it is assumed this is possible.

Part A.2.1 Full Use Case Description

Full Use Case Description – UC1 Submit Job

Brief Description

When the WMS issues a storeLoad or a retrieveLoad request, a job is created and scheduled. The job is added to a crane’s job list, and a job number is returned to the WMS.

Actors

WMS: the WMS is an external system that submits requests to store or retrieve loads for the SCS to execute.

Preconditions.

The use case starts when the WMS submits a storeLoad or retrieveLoad request for the SCS to schedule. In order for this use case to execute, the storeLoad request must be in valid SOAP format and contain the following required information:

1. loadType – pallet or non-pallet
   1. if non-pallet – number of cartons
2. productAwareness - aware or non-aware iii) weight iv) license plate number / barcode number v) product code (optional) if product code specified
   1. batch number and batch date (optional)
   2. quantity (optional)

Flow of Events

Alternate flows

If at step 1 the job is a retrieveLoad request,

System extracts job information from request

System queries warehouse for location of load based on load barcode number Normal flow resumes at step 1.4.

If at step 1.4 the load type is Cartons,

The system selects a driver operated crane.

Full Use Case Description – UC4 Manual Store Load

Brief Description

UC4 – Manual Store Load – when the crane driver selects the job, information about the job is displayed. The crane moves to the loading bay, the driver allows the crane to scan the pallet barcode and pick up the load, then the driver signals the crane to transport the pallet to the designated storage slot and insert it into the slot. Finally the driver confirms that the job has completed and the cranes joblist is redisplayed.

Actors

Crane Driver: the crane driver rides the crane, selects jobs, and signals the crane when to complete actions and move.

Preconditions.

The use case starts when the crane driver selects a job for the crane to execute. In order for this use case to execute, the job selection UI must be initialized and populated with a current joblist for the crane. This should occur during system initialization. Other preconditions are that a storeload job should have been submitted and allocated to the crane, the job type selected should be a storeLoad.

Flow of Events

Alternate flows

If before step 2.3 the job is cancelled, a ‘job cancelled’ message is displayed, the job status is changed to AVAILABLE,

Normal flow resumes at step 3.5.

If at step 2 the load type is Cartons,

While not all cartons in the load have been loaded

The crane driver selects a carton waiting to be loaded

The crane driver scans the carton barcode

The system checks the barcode

If the barcode is correct for the load

The crane driver loads the carton onto the crane

Otherwise

An error message is displayed Job error handling is invoked The use case terminates

Normal flow resumes at step 2.4

If at step 2.4 job tracking is enabled,

UC3 ‘track job’ is invoked (the WMS is notified of job status update) Normal flow resumes after step 2.4

If after step 2.3 but before step 3, the job is cancelled, a ‘job cancelled’ message is displayed, if the load type is Cartons

For each carton loaded

The crane driver selects a carton

The crane driver scans the carton barcode The crane driver unloads the carton otherwise

The system sets the pallet back down in the loading bay the job status is changed to AVAILABLE, Normal flow resumes at step 3.4.

If during step 3.1, the job is cancelled, a ‘job cancelled’ message is displayed,

The system returns the crane to the loading bay if the load type is Cartons

For each carton loaded

The crane driver selects a carton

The crane driver scans the carton barcode The crane driver unloads the carton otherwise

The system sets the pallet back down in the loading bay the job status is changed to AVAILABLE, Normal flow resumes at step 3.5.

If at step 3.2 the load type is Cartons,

While not all cartons in the load have been stored

The crane driver selects a carton waiting to be stored

The crane driver scans the carton barcode

The crane driver stores the carton in the storage slot

Normal flow resumes at step 3.3

If at step 3.3, job tracking is enabled, the WMS is notified that job status has changed to either STORED or AVAILABLE Normal flow resumes after step 3.3

Note – for simplicity I have assumed that a job cannot be cancelled during the process of loading cartons, or once the process of inserting a pallet into the storage slot, or loading cartons into the storage slot has commenced.

Full Use Case Description – Manual Retrieve Load

Brief Description

UC5 – Manual Retrieve Load – when the crane driver selects a Retrieve Load job, information about the job is displayed. The crane moves to the designated storage slot. If the load type is a pallet, the driver allows the crane to scan the pallet barcode and extract the load. If the load type is cartons, the driver must manually scan the carton’s barcodes, and load the cartons onto the crane. The driver then signals the crane to transport the pallet to the loading bay. If the load type is a pallet, the crane then automatically sets the pallet down, but if the load type is cartons then the crane driver must again scan the barcodes on the cartons and manually unload them into the loading bay. Finally the driver confirms that the job has completed and the crane’s joblist is redisplayed.

Actors

Crane Driver: the crane driver rides the crane, selects jobs, and signals the crane when to complete actions and move.

Preconditions.

The use case starts when the crane driver selects a job for the crane to execute. In order for this use case to execute, the job selection UI must be initialized and populated with a current joblist for the crane. This should occur during system initialization. Other preconditions are that a retrieveLoad job should have been submitted and allocated to the crane, the job type selected should be a retrieveLoad.

Alternate flows.

If before step 2.3 the job is cancelled, a ‘job cancelled’ message is displayed, the job status is changed to STORED, Normal flow resumes at step 3.4.

If at step 2 the load type is Cartons,

While not all cartons in the load have been loaded

The crane driver selects a carton waiting to be loaded

The crane driver scans the carton barcode

The system checks the barcode

If the barcode is correct for the load

The crane driver loads the carton onto the crane

Otherwise

An error message is displayed

Job error handling is invoked

The use case terminates

Normal flow resumes at step 2.4

If at step 2.4, job tracking is enabled,

UC3 ‘track job’ is invoked (the WMS is notified of job status update)

Normal flow resumes at step 2.5

If after step 2.3 but before step 3, the job is cancelled, a ‘job cancelled’ message is displayed, if the load type is Cartons

For each carton loaded

The crane driver selects a carton

The crane driver scans the carton barcode

The crane driver puts the carton back in the storage slot otherwise

The system sets the pallet back down in the loading bay

the job status is changed to STORED, System updates storage slot usage Normal flow resumes at step 3.4.

If during step 3.1, the job is cancelled, a ‘job cancelled’ message is displayed,

The system returns the crane to the loading bay if the load type is Cartons

For each carton loaded

The crane driver selects a carton

The crane driver scans the carton barcode The crane driver unloads the carton otherwise

The system sets the pallet back down in the loading bay

the job status is changed to STORED System updates storage slot usage Normal flow resumes at step 3.4.

If at step 3.2 the load type is Cartons,

While not all cartons in the load have been stored

The crane driver selects a carton waiting to be stored The crane driver scans the carton barcode

The crane driver stores the carton in the storage slot

Normal flow resumes at step 3.3

If at step 3.4, job tracking is enabled, the WMS is notified that job status has changed to either STORED or AVAILABLE Normal flow resumes at step 3.4

Note – for simplicity I have assumed that a job cannot be cancelled during the process of loading cartons, or once the process of inserting a pallet into the storage slot, or loading cartons into the storage slot has commenced.

Full Use Case Description - Auto Store Load

Brief Description

UC6 – Auto Store Load – when the crane controller initiates a Store Load job, the crane moves to the loading bay. The crane scans the pallet barcode and picks up the load. The crane then transports the pallet to the designated storage slot and automatically inserts it into the slot. Finally the crane’s joblist is updated, and the crane controller is notified that the job is complete.

Actors

Crane Controller : the crane controller is a notional actor that represents the event of the system initiating a new job.

Preconditions.

The use case starts when a storeLoad job is selected by the system for the crane to execute. In order for this use case to execute, the current joblist for the crane must be initialized and populated. This should occur during system initialization. Another precondition is that a storeLoad job should have been submitted and allocated to the crane.

Alternate flows.

If before step 1.6 the job is cancelled,

The job status is changed to AVAILABLE, The use case terminates.

If during step 1.6 or 1.7 the job is cancelled,

The system sets the pallet back down in the loading bay the job status is changed to AVAILABLE, The use case terminates.

If during step 1.8 the job is cancelled,

The system returns the crane to the loading bay The system sets the pallet back down in the loading bay the job status is changed to AVAILABLE, The use case terminates.

If at step 1.10, job tracking is enabled,

the WMS is notified that job status has changed to STORED

Normal flow is resumes at step 1.11

Full Use Case Description - Auto Retrieve Load

Brief Description

UC7 – Auto Retrieve Load – when the crane controller initiates a Retrieve Load job, the crane moves to the designated storage slot. The crane scans the pallet barcode and extracts the load. The crane then transports the pallet to the loading and automatically sets the pallet down. Finally the crane’s joblist is updated, and the crane controller is notified that the job is complete.

Actors

Crane Controller : the crane controller is a notional actor that represents the event of the system initiating a new job.

Preconditions.

The use case starts when a retrieveLoad job is selected by the system for the crane to execute. In order for this use case to execute, the current joblist for the crane must be initialized and populated. This should occur during system initialization. Another precondition is that a retrieveLoad job should have been submitted and allocated to the crane.

Alternate flows.

If before step 1.6 the job is cancelled, The job status is changed to STORED, The use case terminates.

If during step 1.6 to 1.8 the job is cancelled,

The system sets the pallet back down in the loading bay

The job status is changed to STORED, The system updates storage slot usage. The use case terminates.

If during step 1.9 the job is cancelled,

The system returns the crane to the loading bay The system sets the pallet back down in the loading bay

The job status is changed to STORED, The system updates storage slot usage. The use case terminates.

If at step 1.11, job tracking is enabled, the WMS is notified that job status has changed to AVAILABLE Normal flow is resumes after step 1.11

Part A.3 Activity Diagrams

Schedule Job

Manual Store Load

Manual Retrieve Load

Auto Store Load

Auto Retrieve Load

Part B.1 Non-functional Requirements

Storage Control System

System-Wide Requirements Specification

Introduction

This document identifies system wide requirements that cannot be associated with any one use case, and nonfunctional requirements, otherwise known as ‘quality attributes’ or ‘constraints’.

The major non-functional requirements identified in the case study are:

1. Greater automation. It is desired that manual operation for storage and retrieval of pallet loads should be optional or eliminated.
2. Web service interface. The system must support a SOAP based web service interface according to standards specified by the Warehouse Automation Federation (WAF)
3. Improved job scheduling. It is desired that the system should optimize job scheduling to reduce time and energy requirements.

System-Wide Functional Requirements

The system has one obvious system-wide functional requirement: the ability to track jobs, and the position of cranes. This is required for the operator to monitor the warehouse, and must be supported in all storage and retrieval operations.

Other system wide requirements would be logging, persistence and recovery functions, necessary to support complete data recovery in the event of a system outage.

A further system wide functional requirement might be an ‘override’ capability for the operator which enables the operator can take remote control of a crane at any time and return it to the loading bay.

System Qualities

Usability

There are 3 major groups of stakeholders identified: users of the WMS who wish to store and retrieve loads (and occasionally cancel jobs), the warehouse operator who oversees the operation of the SCS, and the crane drivers who man the cranes in a manual system.

The user interface provided to users of the WMS are outside the scope of this system.

The user interface provided to the warehouse operator is going to be quite complex and sophisticated. It has to monitor the entire warehouse in real time providing clear information to the operator, and presumably alerting them to any safety or mechanical issues. It has to allow them to take control of a crane, while not obscuring monitoring of the rest of the operations. I imagine this interface would require a considerable amount of training and require a skilled operator.

On the other hand, the crane driver’s job is pretty simple. The crane driver is really only there to lift and stack carton type loads. Their task is to select a job, and tell the crane when to move. The interface is likely to be very straightforward, not allow many options, and should be very simple so that an unskilled worker can be quickly and easily shown how to operate it.

Reliability

First of all, this is not a life critical system such as an air traffic control system, or a railway control system, so some failure is tolerable. However, it seems unlikely that weekly or even monthly software failures would be acceptable.

Given the timescales involved in transportation, it seems likely that short outages (on the scale of minutes) would not be disastrous. On the other hand, the system is probably business critical. Trucking schedules are known to be extremely tight, so any long delays (minutes to hours) would be serious. Also, since many businesses would use the warehouse (that’s what the WMS interface is for) extended outages (days) could be disastrous for a lot of customers, and hence the warehouse business.

Given that the system involves mechanical components, some failures are likely. However, it is unlikely that a failure in a single mechanical component would be an acceptable reason for a complete system shutdown.

Scheduled downtimes in the range of minutes to hours at low demand periods would be a way of managing preventative maintenance to avoid outages at peak periods.

Reliability in terms of data would be extremely important. No-one would want to lose track of their stuff, and any jobs in the system, and the location of anything stored in the warehouse should be maintained across any sort of system outage.

Performance

Performance requirements are not clearly specified in the case study. However, if the system requires the capability of cancelling jobs between the time a new load is delivered to the loading bay and the time it is inserted in a storage slot, then clearly jobs need to be tracked on the second-10s of second scale.

Throughput, and capacity would vary with the size of the warehouse, and this suggests that scalability might be another quality that is important. The system probably needs to scale from controlling 1 or 2 cranes, to controlling many more.

Startup and shutdown times are unlikely to be an issue, with the provisos mentioned above in terms of availability. 10s of seconds to a few minutes are probably going to be all right – 10s of minutes to hours probably not.

Supportability

Once again this isn’t addressed particularly in the case study. However, one imagines that not all warehouses use the same transportation systems, and it would probably be good to isolate hardware control from the logical operations of job scheduling.

As mentioned above, scalability could be an issue, however, no upper limit on number of transporters and aisles was mentioned.

Warehouse control systems manage a lot of fairly capital intensive goods and hardware so it is likely that every installation would be customized and carried out and tested by staff from the software developer. Given the systems business criticality and amount of capital involved, one would also imagine that any buyer of the system would probably want round-the-clock on-call support in the 10’s of minutes to hour timescale.

System Interfaces

User Interfaces

There are two user interfaces specifically mentioned in the case study:

1. The operators interface
2. The crane drivers interface.

Warehouse Operators interface: There are two functional requirements mentioned:

1. The ability to monitor the status of the warehouse and in particular the positions of cranes.
2. The ability to take remote control of a crane and return it to the loading bay One imagines that there might also be a requirement for an ‘emergency halt’ capability.

Crane Driver’s interface: There are several aspects of this interface specified:

1. The ability to display jobs assigned to a crane and allow the driver to select a job.
2. The ability to display details of a job, when a job is selected.
3. The ability to display load details when a barcode is scanned.
4. The ability to confirm the match of physical and job specified barcodes.
5. The ability to allow the driver to tell the crane when they are ready to move.
6. The ability to allow the driver to tell the crane when the job is complete.

Interfaces to External Systems or Devices

Software Interfaces

There are two software interfaces specified. The first is an interface the SCS provides that must adhere to the WAF standard. This interface supports at least the following operations:

1. storeLoad
2. retrieveLoad
3. cancelJob

These operations are provided using the Simple Object Access Protocol (SOAP) which is based on HTTP and XML. There are several required parameters to the storeLoad and retrieveLoad operations:

1. loadType – pallet or non-pallet
2. if non-pallet – number of cartons

• productAwareness - aware or non-aware viii) weight

1. ix) license plate number / barcode number x) product code (optional) if product code specified
2. batch number and batch date (optional)
3. quantity (optional)

Both operations return a job number.

The cancelJob operation includes a job number as a parameter.

The second interface specified is a job tracking interface that the WMS supports. This supports an operation called updateJobStatus which takes a job number and a job status (Waiting, Loaded, Stored, Available) as parameters.

Hardware Interfaces

The system is primarily aimed at controlling the movement and operation of ‘cranes’ designed to transport pallets or cartons. The interface for crane control could consist of perhaps 5 operations:

1. navigateToLocation(coordinates) – coordinates are expressed as a tuple: (aisle, vertical position, horizontal position)
2. pickUpPallet – for picking up a pallet from the loading bay iii) setDownPallet – for delivering a pallet to the loading bay iv) insertPallet – for pushing a pallet into a storage slot
3. v) extractPallet – for removing a pallet from a storage slot

Communications Interfaces

The communication interface specified in the case study is a SOAP based web service interface. The system as described assumes that there is a remote Warehouse Management system that communicates with the SCS using standard web based protocols – ie HTTP over TCP/IP

Business Rules

Storage Rules

Rule STR1: Heavy Loads Low

Heavy loads are to be stored on lower shelves. Note – this requires more information on what constitutes ‘heavy’ and which shelves are classed as ‘lower’.

Rule STR2: Fast Moving Products at the Front

Faster moving products are to be stored closer to the loading bay. Note – this requires more information on what constitutes ‘fast moving’ and which shelves are classed as ‘closer to loading bay’.

Retrieval Rules

Rule RTR1: Older Products First

When a product-aware retrieval request is received, retrieve the pallet/cartons with the oldest batch number first.

Rule RTR2: Optimize Storage

When a product-aware retrieval request is received with a quantity specified, retrieve the product from the storage slot which maximizes the number of free storage slots.

Scheduling Rules

Rule SCR1: Optimize Time and Energy

When a new job is received, schedule the job in a way that minimizes the time and energy used in either storing or retrieving it. Typically: schedule a retrieval job nearby in the same aisle to follow a storage job in that aisle

Operation Rules

Rule OPR1: No Passing

Cranes are not allowed to pass each other in an aisle.

System Constraints

The only constraint mentioned in the case study is that the crane driver’s interface has to fit on the crane platform (and still leave room for the crane driver). The cranes are mobile

System Compliance

Licensing Requirements

None specified.

Legal, Copyright, and Other Notices None specified.

Applicable Standards

The interface to the SCS has to adhere to the relevant WAF standard.

System Documentation

The system could require a manual and possibly an online help system for the warehouse operator, and also an instruction sheet for the crane driver. Some documentation of the WAF specified interface could also be required.

Part C.1 Domain Model

Part C.2 Use Case Realization

Submit Job

Manual Store Load (Pallet)

Manual Store Load (Carton)

Auto Store Load

Part C.3 Sequence Diagrams

Submit Job

Manual Store Pallet

Manual Store Carton

Auto Store Load

Part D Summary Analysis Class Diagram

Part E Operation Specification

Operation: Crane: navigateToLocation

Intent: cause a crane to move to a particular location

Signature: void navigateToLocation(Coordinate : location) Where Coordinate is a 3 element tuple consisting of

Aisle: a character specifying which aisle the location is in

Vertical: an integer specifying the vertical position of the storage slot

Horizontal: an integer specifying the horizontal position of the storage slot

Context: Crane

Pre-conditions: location is a valid coordinate for the warehouse

Post-condition: crane is positioned at slot or loading bay

Attributes set: position

Response to exceptions: if a crane tries to pass another crane within an aisle, the crane will stop

Non-functional requirements: the crane must notify the system of its current position in real time.

Operation: Crane: insertPallet

Intent: cause a crane to insert a pallet in a storage slot

Signature: void insertPallet()

Context: Crane

Pre-conditions: crane is positioned at a valid storage slot

storage slot is empty

Post-condition: pallet is stored

Attributes set: none

Response to exceptions: if the storage slot is obstructed the operation stops and an exception is thrown

Non-functional requirements: none specified

Part F – State Diagram