FS 318050 SCR20 NHSBT C-EPOD Vehicle Defect - Prevent Use
NHSBT
C-EPOD Vehicle Defect - Prevent Use
CALIDUS ePOD
19th June 2014 - 1.0
Reference: FS 318050 SCR20
Contents
Functional Overview
Client Requirement
The following changes from the Solution Design document are included in this specification:
- SCR-316403-100 - Vehicle Checks
- Vehicle unavailable - driver not allowed to depart.
Solution Overview
On starting the application, or when choosing to Change Vehicle or Re-login through the Job List menu, the driver will be requested to Log In through this screen.
The device requests entry of the User ID, Vehicle and Password that the driver has been provided with.
Login Screen
The list of vehicles presented will be all available and unavailable vehicles for that depot only.
If there is any error regarding the values entered, the application will inform them of the error. If the vehicle is unavailable (i.e. C-TMS has told C-EPOD that the vehicle is unavailable through the interface), then an error will be shown here. The user will not be allowed to continue.
When successfully logged in and with a data connection, the application will download all of the latest configuration data from the server, and a load to be completed. This will include the latest details of which vehicles are available or not, from C-TMS.
If the vehicle checks have not been completed recently, the application will direct the driver to complete the Vehicle Checks.
If vehicle checks are not completed, the driver will not be allowed to continue (SCR-316403-100). This will be achieved by not providing the driver an option to skip vehicle defect checks - they may only be completed, or backed out of.
Scope
Note: This functionality will be developed in the Android application only and will not be available in the Windows Mobile application. Note: It was requested that Vehicle Checks instigate the unavailability of the vehicle in C-TMS (through Resource Availability) (SCR-316403-15). This automatic change is out of scope of the project. In order to achieve this process manually, the driver will phone the transport office (as they are currently required to) and inform them that the vehicle should be marked as off the road. The transport office will then do this in the Resource Availability screens. The transport office also has the responsibility of reactivating a vehicle once defects have been resolved.
Set-up
Pre-requisites
- A working CALIDUS ePOD system.
CALIDUS TMS Interface Changes
The interface of jobs through to C-EPOD will include the following details and changes:
- The interface will include details of the availability of vehicles, through the existing C-EPOD EPOD_IMPORT tag EPOD_VEHICLES. It is assumed that the availability of vehicles will be based on the Status field against the vehicle record in CTMS, expected to be values:
- Y/A - Available
- N/U - Unavailable
- X - Deleted/Invalid for this depot.
All changes regarding the EPOD interface will be completed under reference 317907/SCR01.
Menu Structure
None
Data
- Device configured to NHSBT style
- Sites set up for each depot (carrier), with the following PDA options:
- Vehicle Checks configured as required.
Functional Description
Import/Export Messages
The PDA web request server (Calidus_ePOD.asmx, both the XML and JSON versions) will be modified to explicitly check for the availability of the vehicle sent through to the server at driver login and Vehicle Change (i.e. LOGON_REQUEST and VEHICLE_CHANGE_REQUEST respectively).
If the vehicle is unavailable (i.e. EPL_STATUS of "U", "N" or "X"), the LOGON_RESPONSE and VEHICLE_CHANGE_RESPONSE messages will be sent back with a specific error to the device, which will be recognised. The error should be tagged in the logon response with the following tags:
- RESULT - set as "NAK"
- ERROR - "VEHICLE UNAVAILABLE"
No changes are necessary to the dataservice import or export. However, for clarity for the specification, it should be noted that both the dataservice webservice (ePOD_DataService.asmx, ePOD_DataService2.asmx) and the AutoImport application will need to import vehicles through the EPOD_VEHICLE tag of the EPOD_IMPORT webservice. The expected format is as follows:
<EPOD_VEHICLES>
<EPOD_VEHICLE>
<EPL_SITE_ID></EPL_SITE_ID>
<EPL_VEHICLE_ID></EPL_VEHICLE_ID>
<EPL_VEHICLE_REG></EPL_VEHICLE_REG>
<EPL_DESCRIPTION></EPL_DESCRIPTION>
<EPL_VEHICLE_MILEAGE></EPL_VEHICLE_MILEAGE>
<EPL_STATUS></EPL_STATUS>
<ACTION></ACTION>
</EPOD_VEHICLE>
</EPOD_VEHICLES>
A full mapping document is available, along with an XSD (XMLUpload.xsd)
PDA Changes
Login
When a driver logs in to the application, or Re-logs in or changes vehicle (through the Job List menu), the application will show the Login screen.
In all cases, the driver is required to enter a vehicle from a drop-down list. This will be validated that the vehicle is available for use.
Note: Developer Notes:
- When a logon request message is sent (through Webservices.LogonRequest) or a Vehicle Change is requested (through Webservices.VehicleChangeRequest), the message processor in the server will check the availability of the vehicle.
- If the vehicle is unavailable, the response messages will be sent back with a specific error to the device - the error should be tagged in the response messages with the following attributes:
- RESULT - set as "NAK"
- ERROR - "VEHICLE UNAVAILABLE"
- In this instance, the message processors (Webservices.ProcessResponse) will recognise this error message and return an error code specific to the Login process. This will be returned to the Login process (Login.js) and the process will display an alert error message
The alert displayed is "Login"/"Vehicle is unavailable"
If at the time of the login request an internet connection is not available, the login and vehicle change messages will be queued to be sent back to the server. The application will instead attempt to validate the login or vehicle change based on the information on the device (though a LocalLogin process). This process will validate the availability of the vehicle selected based on the data on the device and issue the same warning as before.
Note: Developer Note:
- The availability of the vehicle should be checked that the field EPL_STATUS of the vehicle selected is "Y" or "A". If neither, the error should be issued.
In all cases, once clearing the error, the device will return to the login prompt.
Vehicle Checks
When vehicle checks are started, the configuration will be checked. If the vehicle checks contain an attribute "REQUIRED" and the value is "Y", no Postpone button will be displayed, meaning that the driver MUST complete vehicle checks before continuing.
Additionally, the Android Back button will not postpone the checks, but will simply offer the user the option to exit the application.
Appendix A: TEST PLAN
| Test Script / Scenario Reference | C-EPOD Vehicle Defect - Prevent Use | Call Number(s): 318050 SCR20 |
| Test Script / Scenario Description | Test the C-EPOD Vehicle Checks changes made for NHSBT. | PASS / ISSUES / FAIL |
| Menu Access | None | |
| Pre-requisites | Data set up as per Data Setup section. | Tested By: |
| Test Objective | To test that a vehicle may not depart if it is marked as unavailable. | Date: |
| Step | Action | Result | Remarks | P/F |
| 1 | PDA Tests | |||
Vehicles should be configured as follows:
|
||||
| 1.01 | Login to the application. | Only vehicles 1 and 2 should be shown. Note that this is dependent on changes to the interface specified in 318084/SCR17 and . If not yet complete, Vehicle 3 should be shown in the list but may not be selected. | ||
| 1.02 | Login using vehicle 1. | An error should be shown, saying that the vehicle is unavailable. The login screen should be redisplayed. | ||
| 1.03 | Choose Vehicle 2 and log in. | Vehicle Checks should be started. | ||
| 1.04 | Press the Back button. | The device should offer to exit the application. | ||
| 1.05 | Complete the vehicle checks and press Confirm | The Job List should be displayed. | ||
| 1.06 | Choose to Re-login from the menu. Choose Vehicle 1. | An error should be shown, saying that the vehicle is unavailable. The login screen should be redisplayed. | ||
| 1.07 | Choose Vehicle 2 and log in. | The Job List should be displayed. | ||
| 1.08 | Choose to Change Vehicle from the menu. Choose Vehicle 1. | An error should be shown, saying that the vehicle is unavailable. The login screen should be redisplayed. | ||
| 1.09 | Choose Vehicle 2 and log in. | The Job List should be displayed. |
Appendix B: Quote & Document References
| Cost Details | ||||
| Activity | Estimate No. of Days |
No. of Days | Rate per Day (£) | Cost (£ Exc. VAT) |
| Requirements | 0.00 | 0.00 | 0 | £0.00 |
| Change Request Evaluation | 0.00 | 0.00 | 0 | £0.00 |
| Functional Specification | 0.25 | 1.00 | 0 | £0.00 |
| Technical Specification | 0.00 | 0.00 | 0 | £0.00 |
| Development | 1.00 | 1.00 | 0 | £0.00 |
| Testing and Release | 0.25 | 0.50 | 0 | £0.00 |
| Implementation | 0.00 | 0.00 | 0 | £0.00 |
| Project Management | First argument to "number_format" must be a number. | First argument to "number_format" must be a number. | 0 | £First argument to "number_format" must be a number. |
| TOTAL | First argument to "number_format" must be a number. | First argument to "number_format" must be a number. | £First argument to "number_format" must be a number. | |
| Estimate excludes training, release to live and go live support. |
B.1 References
| Ref No | Document Title & ID | Version | Date |
| 1 | NHSBT High Level Solution Design v2.0.doc | 2.0 | 21/05/2014 |
| 2 | FS 317907 SCR01 EPOD-TMS Interface | ||
| 3 | FS 317761 SCR15 NHSBT C-EPOD Collection Changes | 0.4 | 04/06/2014 |
B.2 Glossary
| Term | Definition |
|---|---|
| EPOD | Electronic Proof of Delivery. The OBS EPOD system is CALIDUS ePOD. |
| CALIDUS eSERV | The OBS mobile system to complete Service functionality in the field. This is part of the CALIDUS ePOD system. |
| PDA | The mobile device on which the C-ePOD system will run in the field. This can be a Phone, EDA or industrial PDA, running Android. |
| DAL | Data Access Layer. A mechanism for accessing data by the system that is removed from the application, allowing for simplified access and providing protection to the data, as only approved DAL methods can be used to modify it. |
| GPS | Global Positioning System. A mechanism of retrieving accurate positioning information in the form of Latitude and Longitude (Lat-Long) co-ordinates from a device. |
| GPRS, 3G, HSDPA, Data Service | All terms referring to mobile device network connectivity, and the speed at which the device connects to the internet. |
B.3 Authorised By
Julie Scott | Project Manager | _____________________________ |
Ed Bond | Client Representative | _____________________________ |
