Logix Interface
Note: Also known as the DPS or PTV Route Scheduling interface.
This document covers tactical trip planning requirement which is a version of LogiX installed on a cloud server and will automatically receive files and produce a corresponding outbound plan file.
Tactical Planning Solution
DPS Server Deployment
The DPS Logix Central application will be deployed as a server install in a partition alongside C-TMS.
DPS Logix Central system provides a user interface to manage and maintain plan profiles.
As with the PC version, DPS requires that the data parameters and optimisation configurations are set up within each profile. A profile can represent a series of successive operational days, however, each profile will be used to plan a single day or transport order demand. Each depot will be planned separately in a DPS profile.
Very like the PC version used for strategic planning, DPS Logix Central requires the following parameters to be configured. This covers all the basic setup to allow transport orders to be planned and scheduled and includes general road speed variations for time of day, loading times, depots and depot locations, products, vehicle types (including fleet size), shifts and hours controls, revenue and cost values and auto and advanced options to control the planning behaviour.
Although the profiles can be accessed and managed through the user interface screens, and all the information can be viewed, including the transport orders and generated routes, and all the report outputs; the install will be considered a supporting engine for C-TMS. The interface between C-TMS and DPS Logix Central will be developed to be automated with manual overrides and means DPS Logix Central can be considered a ‘black box’ tightly integrated with the C-TMS order well and planning functions.
DPS Integration
The C-TMS EDI maintenance screens will be used to configure automated jobs that will run at set frequencies to export data to create or update a DPS profile.
The example below illustrates the controlling parameters. A process will be setup to automatically export data for each depot on a set frequency interval, format an interface file for DPS and send to the DPS import folder
The processes setup will be further defined with parameters to control what data is exported to DPS.
The outbound file interface from C-TMS will be CSV format and three file formats will be generated for each interface covering;
- Profile instructions & Parameters – to automatically create a profile or identify a profile to update; all the necessary basic master data for the profile including general road speed variations for time of day, loading times, depots and depot locations, products, vehicle types (including fleet size), shifts and hours controls, revenue and cost values and auto and advanced options to control the planning behaviour.
- Existing Routes and Allocated Orders – exporting the existing trips from C-TMS for the selected schedule day and synchronise them in the DPS profile.
- Additional unallocated orders – new orders captured in the C-TMS order well that require planning.
The instructions file will cause DPS to automatically read in and upload the data files, optimise the data and generate an output file of the new and modified routes.
An inbound EDI process will be created to constantly check for new updates from DPS and will automatically upload the information and synchronise the route trips, drop sequence, time schedule, orders allocated, breaks and wait times.
Note that C-TMS will always be considered the master controlling dataset. The profiles in DPS will considered temporary / transient. The profiles will be retained for a number of days to allow planners to review the data, use the mapping tools to visualise the routes and take advantage of the reporting and outputs the DPS tool provides.
Forecast Plan Regular and Sessions
For each depot, a forecast plan will be generated automatically each evening starting 3 weeks ahead of the operational day using the C-TMS and DPS Logix integration.
This initial plan will comprise of the fixed route trips and will include the session collection work that transport is responsible for.
The forecast plan will be available for review and will provide an early view of the regular hospital re-supply and session work. There will be a planning assumption, for the forecast plan, that all the hospitals featuring in the fixed routes will eventually raise regular re-supply delivery requests and these will be allocated into the plan as they are interfaced from PULSE to C-TMS. The transport team will use the forecast plan to consider driver rosters, shifts and driver availability. The forecast plan will run each evening for the operational days rolling for the next 3 weeks and automatically plan any changes resulting from the session diary updates, changes to the fixed routes and actual transport order demand being received into C-TMS from PULSE, C-Portal or manually entered. The table below illustrates how the daily profiles for depot will be automatically managed by the interface and integration between C-TMS and DPS Logix Central.
For each depot, the forecast profiles (F) will be generated starting 21 days before an operational day (D) and the immediate past history (H) will be retained for 7 days.
| Depot | …. | H-3 | H-2 | H-1 | D-0 | F+1 | F+2 | F+3 | F+4 |
| CAMBRIDGE | 140604 | 140605 | 140607 | 140608 | 140609 | 140610 | 140611 | 140612 | |
| COLINDALE | 140604 | 140605 | 140607 | 140608 | 140609 | 140610 | 140611 | 140612 | |
| TOOTING | 140604 | 140605 | 140607 | 140608 | 140609 | 140610 | 140611 | 140612 |
The profiles are the work areas for the planning functionality in DPS and they will be automatically named using the depot and schedule day in the format YYMMDD. The content of each of the profiles will always represent a schedule in C-TMS, and as mentioned above C-TMS will always be considered the master, and each of the DPS profiles will be considered to be a temporary work area.
The DPS Route viewer below illustrates how routes are organised showing totals in the header and the details of the sequence and timing of collection and delivery activity for the route.
The integration between C-TMS and DPS will retain the synchronisation and the same details can be viewed in the C-TMS planning and execution control screens.
Functional Description
A nightly process will be automatically run in the C-TMS system which will generate the new profiles (per depot for the schedule 21 days in the future - including the master standing data).
It will then produce csv files (orders and trips) to be imported for the each schedule for the next 21 days including the newly created profile and then ftp them to the appropriate folder on the new LogiX server.
A command will then be issued from C-TMS to the server so that the LogiX software will then automatically import these files and produce a plan (it will configured to generate the UserOut export as part of creating the plan).
This file will then be picked up by C-TMS and used to create or update the trip plan in C-TMS to match the LogiX plan.
A manual run will also be available for a single depot and schedule (day zero only) which will send the orders and trips and wait for a new plan to be generated and imported back into C-TMS.
A manual run when resources are changed for all depots and schedules (up to 21 days in the future) to update resources and availability
Setup and Control
The LogiX software will be setup to have folders (Profiles) created per Depot and Schedule (called <DEPOT>_<SCHEDULE>).
NB) Folder names will contain both the depot and the schedule name.
A master profile (called <DEPOT>_MASTER) must be created manually on the windows server for each depot with all of the appropriate configuration settings.
The PL.INI file for the master profile will be manually configured to produce the correct information in the UserOut file.
Overnight Outbound Process
The overnight process will run for each depot and will be split into several sections :-
Create new profile for the new schedule (21 days into the future)
For the next 21 days schedules :-
- Send the orders and trips (including clear down of existing data)
- Run command to get LogiX to import the files and to Auto schedule
- Retrieve the updated UserOut.csv and Load new plan
The orders and trips file generation will be split into :-
- Delete existing orders and trips.
- Create orders file.
- Create trip file (not on fixed routes).
- Create dummy (placeholder) orders files (from fixed routes not trip) for any stops on existing fixed route trips with no real orders assigned.
- Create trip files (fixed routes trips).
- Instructions on how to run import files and produce plan (updates UserOut automatically).
- Import the new plan back into C-TMS.
New Folder and Initial Files
Proposed folder structure on LogiX server will be down to depot and schedule level.
The folders will be created by the overnight process (called <DEPOT>_<SCHEDULE>) for the new schedule (current day +21) for all of the active depots including copying all of the master profiles data (unique for each depot).
This will be achieved via a call to the windows server to copy (xcopy dos command so includes all files in the directory) the data from the master profile folder into the new folder.
Orders (Type blank as now but represents A and T)
We will be sending the orders from C-TMS to LogiX as tramping pairs (Order Type ‘B’) calling the file ORDERS.csv.
Sample of the existing LogiX order export (Collection and Delivery with order type ‘B’) :-
| LogiX Field | C-TMS Field | Description |
| TYPE | Blank (Represents ‘A’ and ‘T’) | Address and Task (order) |
| ACTION | ‘A’ | Add |
| CALLREF | FROM_LOC or TO_LOC | Collection or Delivery Location |
| ORDERREF | OMS_REF | Order Reference |
| ORDERTYPE | ‘B’ | Both - Load and Unload pair |
| CALLNAME | LOCATION_NAME | To Location |
| ADDRESS_1 | ADDRESS_1 | To Location |
| ADDRESS_2 | ADDRESS_2 | To Location |
| ADDRESS_3 | ADDRESS_3 | To Location |
| ADDRESS_4 | TOWN | To Location |
| ZIPCODE | POSTCODE | To Location |
| CALLNAMEC | LOCATION_NAME | From Location |
| ADDRESS_1C | ADDRESS_1 | From Location |
| ADDRESS_2C | ADDRESS_2 | From Location |
| ADDRESS_3C | ADDRESS_3 | From Location |
| ADDRESS_4C | TOWN | From Location |
| ZIPCODEC | POSTCODE | From Location |
| OPEN1 | EARLY_DEL | Early delivery time window |
| CLOSE1 | LATE_DEL | Late delivery time window |
| OPEN1C | EARLY_AVAIL | Early collection time window |
| CLOSE1C | LATE_AVAIL | Late collection time window |
| BOOKDAY | Calculated | Day of week (collect or delivery) |
| FIXTIME | Calculated | Time spent at loading stop |
| WORKTIME | Calculated | Loading time |
| FIXTIMEC | Calculated | Time spent at unloading stop |
| WORKTIMEC | Calculated | Unloading time |
| CUSTINFO1 | EXTERNAL_REF | Customer order reference |
| CUSTINFO2 | DELIVERY_TYPE_ID | Delivery Type (Service Level) |
| CUSTINFO1C | EXTERNAL_REF | Customer order reference |
| CUSTINFO2C | DELIVERY_TYPE_ID | Delivery Type (Service Level) |
| CUSTINFO3 | CONTACT_NAME | Contact Name |
| PHONE | PHONE | Contact Phone number |
| PREFDEP | FROM_LOC or TO_LOC | Depot Code |
| PROD1 | SUM(SOL.QUANTITY) | Uses the decodes for LOGIX_DU_TYPES to identify the DU_TYPE and then totals the ordered quantity from the order lines that match this type. |
| PROD2 | SUM(SOL.QUANTITY) | |
| PROD3 | SUM(SOL.QUANTITY) | |
| PROD4 | SUM(SOL.QUANTITY) | |
| PROD5 | SUM(SOL.QUANTITY) | |
| PROD6 | SUM(SOL.QUANTITY) | |
| PROD7 | SUM(SOL.QUANTITY) | |
| PROD8 | SUM(SOL.QUANTITY) | |
| PROD9 | SUM(SOL.QUANTITY) | |
| PROD10 | SUM(SOL.QUANTITY) | |
| PROD11 | SUM(SOL.QUANTITY) | |
| PROD12 | SUM(SOL.QUANTITY) | |
| PROD13 | SUM(SOL.QUANTITY) | |
| PROD14 | SUM(SOL.QUANTITY) | |
| PROD15 | SUM(SOL.QUANTITY) | |
| PROD16 | SUM(SOL.QUANTITY) |
This will contain all orders whether they are at status UNSCHEDULED or SCHEDULED.
Trips (Type J and S not Fixed Routes)
Trips will be sent to LogiX in a file called TRIPS.csv.
| LogiX Field | C-TMS Field | Description |
| Type | ‘J’ | Schedule (Trip) Summary |
| Action | ‘A’ | Add. |
| RouteName | ROUTE_CODE | From trip. |
| StartDepotName | LOCATION_NAME | Name for the SU Stop |
| FinishDepotName | LOCATION_NAME | As Start |
| VehicleName | TRAILER_ID | |
| Status | Use for locking entire trip |
To ensure that trips which are already in progress are not amended then they will be locked via Status column using 5 (Frozen).
| LogiX Field | C-TMS Field | Description |
| Type | ‘S’ | Schedule (Stop/SHA/Break) detail. |
| Action | ‘A’ | Add. |
| RouteName | ROUTE_CODE | Unique route. |
| Sequence | Count | Add stop and SHA level. (stop * 10 + SHA seq ) ? |
| CallType | Calculated | Separate record for SU and CL ? Breaks ? Load and Unload ? |
| Reference | OMS_REF | Add ‘C’ and ‘D’ suffix’s. |
| Order | OMS_REF | Add ‘C’ and ‘D’ suffix’s. |
| ArriveDay | Calculated | Day of week from stop arrive time (actual if set ?).
NB) Actual arrive after planned departure ? |
| ArriveTimeSecs | Calculated | As part of day. |
| DepartDay | Calculated | Day of week from stop depart. |
| DepartTimeSecs | Calculated | As part of day. |
| Status | Calculated | For locking data from update by when actual times already populated on the trip stop |
Dummy Orders and Fixed Route Trips
Fixed route trips (prefix ‘RTE-‘) will have been created by the scheduling engine process as detailed in the fixed routes specification (FS – 317772 – NHSBT Fixed Routes).
Some orders may have been scheduled onto these trips (either by the scheduling engine itself or on a previous run of the LogiX software) but some of the stops on these trips will not have any orders assigned yet (empty stops).
Another trip file
Another order file needs to be sent for every empty stop to generate a dummy (placeholder) order within LogiX.
NB) These orders must be ignored when returned to C-TMS so must be easily identifiable (ORDERREF set to ‘PLACE’<COUNT>).
Generate the dummy orders file and the fixed route trip files at the same time using the generated reference to write into both files.
Once these orders have been sent then in parallel the fixed routes trip can be sent.
Manual Outbound Order and Trips
On the actual day of execution of a plan for the current schedule then many changes (mainly last minute new orders) will be happening that will affect this plan so an option to manually update the plan (via LogiX) for this schedule and a single depot will need to be available.
This will be a button from the trip form.
This will be similar code as the overnight run for existing profiles (send orders and trips) but for a single depot (each user will be assigned to a single depot, based at ?) and a single schedule (the current schedule shown on the trip screen).
