requirements specification [draft] appendix 3.1 … requirements danpilot ver… · requirements...

1

Requirements Specification [DRAFT]

Appendix 3.1

Maritime Planning and Dispatch System (MPDS)

Danpilot

Version 0.7 – Aimed at Suppliers

[Disclaimer and note to the Supplier: This document is part of the K02 contract and

Appendix to K02. It is a draft version with inconsistent requirements. Danpilot hold

the right to add, change or delete requirements, use cases and/or other information.

The purpose of this document is to give the Supplier an opportunity to see the

preliminary requirements and specification to give their input in order to create the

best possible final requirement specification]

2

Table of content: Introduction to requirements specification ...................................................................................................... 4

0. Danpilot specific optimisation, planning, dispatching and execution requirements .................................... 4

Introduction ................................................................................................................................................... 4

0.1 Defining the Primary Actors and their relation to requirements and use cases ..................................... 5

Primary Actors ........................................................................................................................................... 5

Use Case Context Diagram ........................................................................................................................ 6

0.2 High level business processes and their relation to use cases ................................................................ 7

0.2 Requirements for System supporting the complexities in dispatching ................................................. 20

0.4 Requirements for System supporting the planning a transit pilotage within Route T .......................... 23

0.5 Optimization of resources ..................................................................................................................... 25

1. Other Requirements .................................................................................................................................... 37

1.1 Functional requirements orderprocess: ................................................................................................ 37

1.2 Functional requirements planning and dipatching: .............................................................................. 38

1.3 Functional requirements reporting: ...................................................................................................... 41

1.4 Functional requirements sales data: ..................................................................................................... 43

Functional requirements finance/ billing data: ........................................................................................... 44

Functional requirements wage data: .......................................................................................................... 44

2. Non functional requirements ...................................................................................................................... 45

2.1 Requirements for Architecture, Integration and Security ..................................................................... 45

2.1.1 Architecture .................................................................................................................................... 45

2.1.2 Integration ...................................................................................................................................... 47

2.1.3 Security ........................................................................................................................................... 51

2.1.4 Non- and functional requirements data management: ................................................................. 53

2.2 Non-Functional requirements master data including certificates: ....................................................... 55

2.3 Data management ................................................................................................................................. 57

2.4 Non-funtional requirements 2-way communication ............................................................................. 60

2.5 Integrations ........................................................................................................................................... 61

Integration: SeaWeb ................................................................................................................................ 61

Integration: GateHouse (AIS-data) .......................................................................................................... 64

Integration: Elektronisk Lodsseddel (ELS) / SafePilot .............................................................................. 66

Integration: GatShip ................................................................................................................................ 69

Integration: Navision ............................................................................................................................... 71

3

Integration: PDC ...................................................................................................................................... 76

Integration: Integration/ETL process for Data Warehouse and BI .......................................................... 78

Integration: Master Data Manager (MADAM) ........................................................................................ 80

3. Non-functional requirements - user experience: ........................................................................................ 81

General requirements ................................................................................................................................. 81

User interfaces should be adapted according to the Actor (and thereby role) .......................................... 82

User involvement ........................................................................................................................................ 83

Design guidelines ......................................................................................................................................... 83

Messages and help ...................................................................................................................................... 84

Technical requiremets regarding the UI ...................................................................................................... 85

4. Information Model ...................................................................................................................................... 86

Introduction ................................................................................................................................................. 86

Order-related Data .................................................................................................................................. 86

Certificate-related Data ........................................................................................................................... 87

Geographical Data Model ........................................................................................................................ 88

5. Business rules .............................................................................................................................................. 91

Current Union Agreements (rules) .............................................................................................................. 91

Pilots: ....................................................................................................................................................... 91

Boatmen 1: .............................................................................................................................................. 91

Boatmen 2: .............................................................................................................................................. 91

State agreements .................................................................................................................................... 92

Current Union Agreements (rules) and their interpretation ....................................................................... 93

Pilots ........................................................................................................................................................ 93

Possible changes to working rules for pilots ............................................................................................. 103

Standard Operating Procedures ................................................................................................................ 107

4

Introduction to requirements specification This requirement specification is a sub-appendix to the appendix for the K02 contract. This appendix will

explain the requirements to the new System based on the business needs of Danpilot.

For general understanding of Danpilot and it’s business please refer to Appendix 3.1.a

0. Danpilot specific optimisation, planning, dispatching and execution

requirements

Introduction The requirements consist of three different of sets of functional requirements:

1) Processoverview and detailed process descripstions (Both as-is and to-be)

2) Requirements specified in requirement specification boxes

3) Requirements specified in use cases

2) and 3) are linked to processes when possible so the Supplier can get a consistant overview of the

different processes, the business needs and the relation between processes, requirements and use cases.

5

0.1 Defining the Primary Actors and their relation to requirements and use cases

Primary Actors The following Actors will use the System or parts of the System:

Dispatcher, user: This is one of the most common users of the System. The dispatcher will have a

central role in using the System everyday and will use a wide range of the functionality of the

System, however with focus on dispatch and execution.

Dispatcher, superuser: This is like the dispatcher, user one of the most common user in the System.

The dispatcher will have a central role in using the System everyday and will use a wide range of

the functionality of the System. On top of the role as user, the superuser will have a role in testing

new functionality, communication with Dispatch Manager etc.

Dispatch Manager: This role will use parts of the System primarily as a mangement role seeking

information on execution, KPI’s, reports etc. Will not use the planning and dispatch functions, but

will have to have a general knowledge of the complete System.

Planning and Dispatch Manager: As the dispatch Manager

Superuser/Administrator: Will maintain e.g. optimsation parameters a long with correction of

materdata etc.

Pilots: Pilots will use the 2 way user interfaces to reporting i.e.change of ETA, bording times etc.

They will not use the planning and dispatch functions, but see reports, information about new and

completed orders and personally registered activities etc.

Boatmen: As the Pilots they will use the 2 way user interfaces to reporting, pilot boat sail plans,

bording times etc.

(Roster) Planners: This is one of the most common user in the System. The (Roster) Planner will

have a central role in using the System everyday and will use a wide range of the functionality of

the System, however with focus on Roster planning

Sales Department (Not shown in Use Case Context Diagram): The Sales Employee will use a limited

range of the functionality of the System, however with focus on order creation and shipping

information

All other personel : Will use 2 way communication part of the system in relation to holiday request

etc.

Business Analyst (Not shown in Use Case Context Diagram): Data access for ad-hoc analysis

6

Use Case Context Diagram Fejl! Henvisningskilde ikke fundet. below gives an overview of the context for the System exists and the

main use cases for each actor/role.

Figure 1. Use Case Context diagram for the Maritime Planning and Dispatch System (MPDS)

[This figure is not complete and use cases not part of published material]

7

0.2 High level business processes and their relation to use cases

In the following chapter Danpilots as-is and to-be the high level business processes are explained in order

to make the Supplier aware of the overall context that the requirement specification is relating to.

Furthermore the complexity in planning and dispatching is explained along with the requirements for

optimisation.

1. Introduction

Section 2 describes at a high level the as-is-processes for planning and dispatching of pilots at DanPilot. The

descriptions will not go into many details but are meant as an illustration of the as-is-workflow for the most

important processes. Section 3 describes which extensions there will be needed to include in the processes

in a near future with full liberalization of the Danish pilotage market in 2020.

It will be expected that planning and dispatching of others staff categories e.g. boatmen are easily

integrated with the processes described below. It is also assumed that the System is capable of allocating

pilot boats and company cars to the actual needs for transportation of boatmen and pilots.

Figure 1 below provides an overall overview of the described as-is-processes.

Figure 1: High-level processes for planning and dispatching pilots

5 months before

operation

3 months

before

operation

0-3 months

before

operation

Day of operation

(+/- 24 hours)After operations

Pilots

Rostering

Dispatching

Customers

Invoicing

Payroll

Demand of pilotage 11

Request for changes to ETA or ETD10

Calling in on overtime9

Allocating and reallocating pilots to orders.

Planning of rest periods for pilots.

Planning of travels for pilots.

Alarms for aw aken pilots and boatmen

8

Data for payroll15

Data for Invoicing14

Reporting

Analyzing

BI-data

15

Requests

for days off

and

vacation

1

Requests for time off, release to others tasks, and absence etc. 3

Execution of orders.

Updates and status of current pilotages.

2

Maintenance and update of rosters

6

Rostering

4

Announ-

cement

of roster

5

Ordering of

pilotage

12

Changes to orders

13

Available staff on duty or stand by 7

8

2. AS-IS processes

As shown in figure 1 the planning of rosters starts in 5 month advance of the last day in 3 month rosters.

The participants in the planning or dispatching processes are pilots, planners, dispatchers, customers, and

bookkeepers. For Primary Actors, please refer to section XX.

2.1 Time dimension

The rosters are announced quarterly. One half of the pilots is rostered for January-March, April-June, July-

September, and October-December. The other half of the pilots is one month staggered i.e. February-April,

May-July, August-October, and November-January.

Rosters are announced the 10th in the month before the first day in the roster, e.g. the roster for January-

March will be announced no later than 10th of December. Before the rosters are created the pilots may

submit request for days off, days of vacation1 etc. The deadline for submission of request to the roster are

typically 3 weeks before the 10th. That means that the deadline for request regarding the roster for

December-March will be the 20th of November, cf figure 2.

Figure 2: Example of deadlines in the rostering process

After the announcement of the rosters the planners will update the rosters with changes that might occur.

At the day of operation, the dispatchers receive orders from our customers. Orders are received with the

following notices

At least 18 hours prior to ETA for transit pilotage.

At least 4 hours2 prior to departure from port, and 24 hours if pilotage is requested to port.

1 Please notice that others deadlines may apply in accordance to the Danish Holiday Act regarding the summer and

winter holidays. 2 For a few ports the notice is only 1 hour

Deadline for

submission of requests

Deadline for

announcement Roster period

9

2.2 Pilots

Figure 3: Processes involving pilots

Process

no.

Description

1 Prior to the rostering pilots may submit request3 for dates where they want to have either

duty off, days off, or vacation. If possible the planners will respect those requests for avoiding

a day of duty. Please refer to use case ID XX

2 The executing of the orders is carried out in close dialogue with the dispatchers, meaning

coordinate and agree on

when to rest

when to be piloting on the bridge

how and when to travel on land between orders

when and where to be sailed in pilot boat

coordination of changes to ETA4 and/or ETD5

information about eventually changes of pilots along the route

3 Per year a pilot has 153 duty days, 12 standby duties, 51 off duty days, 119 days off and 30 days of vacation in total

365 days. 4 Estimated time of arrival for the ship which have ordered pilotage

5 Estimated time of departure for the ship which have ordered pilotage

5 months before

operation

3 months

before

operation

0-3 months

before

operation

Day of operation


Pilots

Rostering

Dispatching

Customers

Invoicing

Payroll








8

Data for payroll15


Reporting

Analyzing

BI-data

15

Requests

for days off

and

vacation

1




2


6

Rostering

4

Announ-

cement

of roster

5

Ordering of

pilotage

12

Changes to orders

13


10

Process

no.

Description

setting alarms if the pilot wants to be waked from his rest period before the next

executing the next order

Please refer to use case ID XX

The pilot will also continually update the dispatchers about the progress in the actual pilotage e.g.

when the did the executing of the pilotage start i.e. when boarded the ship

expected completion time of the pilotage

when the did the executing of the pilotage end i.e. when disembarked the ship

send message as soon the pilot is ashore again Please refer to use case ID XX

3 After the announcement of the rosters the pilots still can request for time off or other

changes to his roster. If possible those requests will be implemented in the roster.

The rosters will also be updated in accordance to sick leave and reported recovery.

It may also happen that pilot are allocated to internal projects, meetings etc. and therefore

not can be on duty.


11

2.3 Rostering

Figure 4: Processes involving planners

Process

no.

Description

4 The rostering is based on the received requests for days off etc. from the pilots and the rules

for the number of the different day types6 per year

duty days

off duty days

days off

vacation days

The duty days shall be given in periods of minimum 3 days and maximum 9 days in a row. it seems that the most optimal7 length is 7 or preferably 8 days. The rosters (inclusive a buffer for sick leaves) shall also ensure that the decided total number of pilots are on duty per date, which e.g. could be determined by a week or month profile.

6 This given list is the most common day types, but please take into consideration that there is numerous other day

types. Please also notice that DanPilot in cooperation with the trade union are experimenting with new day types e.g. a 24-hour duty starting with 12 hours of standby duty followed by 12 off duty hours. 7 In accordance to the rules for rest periods a sequence of 7 or 8 duty days in a row will be give the dispatchers the

most degrees of freedom.

5 months before

operation

3 months

before

operation

0-3 months

before

operation

Day of operation


Pilots

Rostering

Dispatching

Customers

Invoicing

Payroll








8

Data for payroll15


Reporting

Analyzing

BI-data

15

Requests

for days off

and

vacation

1




2


6

Rostering

4

Announ-

cement

of roster

5

Ordering of

pilotage

12

Changes to orders

13


12

Process

no.

Description

The pilots are depending on their certificates divided into several rosters, where the pilots in each roster has similar certificates. The smallest group in a roster is currently 5 pilots and the biggest is more than 30 pilots. The small roster-groups are those for port pilots8 and the biggest are those for transit pilots. Each roster shall ensure that at least the decided number of pilots will be on duty, e.g. in a 5 pilots roster there at least shall be given 2 duty days per date. All pilots in a roster shifts at the same time e.g. 12:00. The most common times for shifts are 12:00 and 24:00. At the time being DanPilot has 164 pilots, of which approximately 10 are on part-time employed. The planners shall also take into consideration that a period of duty days (including standby duties) may not start or end in the weekends or holidays. Please refer to use case ID XX

5 When the rosters are ready the are announced to the pilots by email and are in principle fixed for the coming period of 3 months.

6 Even though the rosters after announcement are fixed there will always be changes, cf.

process no. 3. Therefore, the planners on daily basis maintain the rosters to ensure that they

always are updated.

8 Please be aware of that port pilot also are capable for transit pilotages. But normally a transit pilot does not have

certificates to any ports. A port pilot does not have certificates to all ports but only to a limited number of ports.

13

2.4 Dispatching

Figure 5: Processes involving dispatchers

Process

no.

Description

7 The it-System for dispatching are always updated with the latest changes to the pilot rosters at the day of operation. This ensure that the dispatchers always9 are updated with the status per pilot i.e. who are on duty, off duty, day off, and vacation.

8 Based om the incoming orders (and changes to orders) the dispatchers allocate pilots to the pilotages. When doing that, dispatchers consider

where will pilots be located when the pilotages start?

where will the pilots end their pilotages?

what are the status of the pilots’ previous rest periods?

how can the pilots have their rest periods during and after the pilotage?

shall there be change of pilots during the pilotage?

which pilot boat will be in operation in connection to the pilotage?

how and when shall the pilots travel on land. And will it be by taxi, company car, bus, train, or airplane?

How robust is the assignments regarding changes to ETA10 and ETD?

9 However, Danpilot has some problems regarding updating the rosters in weekends as the planners only are working

normal office hours.

5 months before

operation

3 months

before

operation

0-3 months

before

operation

Day of operation


Pilots

Rostering

Dispatching

Customers

Invoicing

Payroll








8

Data for payroll15


Reporting

Analyzing

BI-data

15

Requests

for days off

and

vacation

1




2


6

Rostering

4

Announ-

cement

of roster

5

Ordering of

pilotage

12

Changes to orders

13


14

Process

no.

Description

How well are ports covered when ports pilots are doing transit pilotages?

Which pilots are close to the end of their period of duty days?

Which pilots will start on their period of duty days in the next hours?

Is it possible11 to serve more than one ship with only one pilot boat trip? Based on such considerations the dispatchers choose the most cost effective assignments of pilots to pilotages. If assigned pilots (or boatmen operating the planned pilot boats) want to be waked or have notice x minutes/hours prior to their tasks the dispatcher will set an alarm in the dispatching System. Please refer to use case ID XX

9 If the pilots on duty not can cover the actual orders the dispatchers must call pilots in on

overtime. Calling in on overtime will happen in accordance to existing agreement, currently in

the following steps

1. calling in pilots with the needed certificates on standby

2. calling in pilots with the needed certificates on off duty

3. calling in pilots with the needed certificates on day off

4. calling in pilots with the needed certificates on vacation

Pilots on standby are obliged to accept overtime when asked. Pilots on off duty, day off, or vacation may refuse to accept overtime. If step 1-4 not are enough to cover the current demand the dispatcher may return to step 2 (pilots on off duty) and force them to accept overtime as they can not refuse the second call12.

10 If the incoming orders piles up to a peak which is impossible to cover either due to shortage

of pilots with the right certificates or due to shortage of boatmen or pilot boats the

dispatchers will try to influence the demand. This can be done by notifying the ships about

changes to requested ETA or ETD caused by shortage of resources at DanPilot.

11 The dispatcher receives incoming orders by DanPilot’s homepage, email, phone or directly in

the dispatching System by an API.

Incoming orders are (except orders received automatically13) manually entered into the

dispatching System.


10

ETAs and ETDs are continuously (re)calculated either manually or (as an experiment) automatically based on real time AIS-signals from the ships (AIS = Automatic Identification System). The AIS-based ETAs and ETDs are recently integrated in the current dispatching system. 11

To support such an overview and following decision DanPilot is currently experimenting with the use of real time AIS-updated time-space-diagrams for the pilotages in Great Belt. 12

That is why the day type not are day off but off duty. A pilot has 51 off duty days which often are place just before or after a period of duty days. 13

Currently DanPilot only can receive orders automatically from Blue Waters operations at the port in Esbjerg i.e. only a few orders per days. Next step will be to automatically receive all orders from Blue Water. Third step will be to offer this opportunity to all interested shipbrokers so that probably 50% of all port pilotages can be received automatically in the dispatching system.

15

Currently the dispatching of historically reasons are divided into three areas north, south, and east.

The north-dispatcher takes care of south-bound transit pilotages through Great Belt and

pilotages at the northern ports.

The south-dispatcher takes care of north-bound transit pilotages through Great Belt and

pilotages at the southern ports.

The east-dispatcher takes care of transit pilotages through Sound and pilotages at the

eastern ports.

In future we will prefer that the dispatching are done global for the entire operation in Danish

waters instead of sub optimize 3 different areas. Please refer to use case ID XX

There are other types of pilotages than mentioned in the table above. Those are bunkering and

ship-to-ship operations which involves 2 two ships and normally 1 pilot at a given position in the

open sea. This kind of pilotages are also handled in the dispatching System.

16

2.5 Customers

Figure 6: Processes involving customers

Process

no.

Description

12 Most commonly customers request for pilotages by mail or by our homepage. Orders can also be given by phone or entered directly into the dispatching System cf. process no. 11.

13 As orders are given with up 24-hour notice ETA or ETD may change due to weather conditions or unforeseen incidents when loading or unloading the ship in the port. When such circumstances occur, the customer will notify DanPilot and a new ETA or ETD will be entered into the dispatching System. Please refer to use case ID XX

5 months before

operation

3 months

before

operation

0-3 months

before

operation

Day of operation


Pilots

Rostering

Dispatching

Customers

Invoicing

Payroll








8

Data for payroll15


Reporting

Analyzing

BI-data

15

Requests

for days off

and

vacation

1




2


6

Rostering

4

Announ-

cement

of roster

5

Ordering of

pilotage

12

Changes to orders

13


17

2.6 Bookkeepers

Figure 7: Processes involving bookkeepers

Process

no.

Description

14 Based on data from the dispatching System customers are invoiced for pilotages. Today this process is almost 100% manually and are carefully controlled as it often happens that data received from the dispatchers (and/or the dispatching System) are incomplete. Please refer to use case ID XX

15 Based on data from the dispatching System the salaries for the pilots are calculated. This includes calculations of allowances for overtime, which depends on which day types the overtime were performed. Please refer to use case ID XX

5 months before

operation

3 months

before

operation

0-3 months

before

operation

Day of operation


Pilots

Rostering

Dispatching

Customers

Invoicing

Payroll








8

Data for payroll15


Reporting

Analyzing

BI-data

15

Requests

for days off

and

vacation

1




2


6

Rostering

4

Announ-

cement

of roster

5

Ordering of

pilotage

12

Changes to orders

13


18

2.7 Follow-up

Figure 8: Follow-up processes

Process

no.

Description

16 Reporting: On regularly basis a number of reports are made. Some reports are made almost automatically other report are made manually. Examples are

On monthly basis, several KPI’s are reported to the management.

On daily basis, the development in revenue and overtime are reported to both management and employees responsible for planning and dispatching

But many more reports will be requested if they can be made automatically, e.g. the daily number of pilots who shifts at 12:00 o’clock. Please refer to use case ID XX Analyzing: A lot of ad hoc analyzes are done based on data extractions from different databases, which may be expected to be fully integrated in the next generation of a planning and dispatching System. Some examples of ad hoc analysis could be

How does the distribution of pilotages in and out of ports broken down to weekdays and hours looks?

Can peaks or coincidences in the demand explain extreme much overtime at a certain

5 months before

operation

3 months

before

operation

0-3 months

before

operation

Day of operation


Pilots

Rostering

Dispatching

Customers

Invoicing

Payroll








8

Data for payroll15


Reporting

Analyzing

BI-data

15

Requests

for days off

and

vacation

1




2


6

Rostering

4

Announ-

cement

of roster

5

Ordering of

pilotage

12

Changes to orders

13


19

Process

no.

Description

date?

How can we forecast the demand?

BI-data: As DanPilot historically have acquired many stand-alone it-Systems data from the dispatching System are made available for our BI.

Requirement#0.2.1: Processes – Support of processes

Category: Requirement Type: Functional

Description: The System should support the above mentioned as-is processes including use cases ID 3,

ID 4.

Comment:

3. Examples of TO-BE-expansions to current processes

3.1 Subsidiaries and cooperation

As the pilotage market at Danish waters will be fully liberalized in 2020 it may be possible that DanPilot in

one form or another will cooperate with other pilot service companies.

Requirement#0.2.2: Processes - Subsideriaries


Description: The System should support more than one pilot service provider as DanPilot has

subsidiaries e.g.

our subsidiary (Limfjord Pilot) operating at Limfjorden

our subsidiary (Greenland Pilot Service) operating at Greenland

cooperation with other pilot service companies may also be possible

Comment:

The character of planning and dispatching at Limfjord Pilot can be compared with the processes at DanPilot

but in smaller scale (less than 10 pilots) and other working agreements with the unions are applied.

The pilot service at Greenland differs much from the processes at DanPilot as schedules for the cruise ships

are known with several month advances and two pilots will be provided to each ship for several days.

Furthermore, a pilotage e.g. begins at Iceland and ends in Canada. Therefore, also the working agreements

differs from the ones in DanPilot.

20

3.2 Groups of employees

Requirement#0.2.3: Groups of employees


Description: The System i.e. the planning and dispatching System shall be capable to deal with different

groups of employees, e.g.

Planning and dispatching of pilots, currently approximately 160 pilots

Planning and dispatching of boatmen, currently approximately 90 boatmen

Planning (and dispatching) of dispatchers, currently 18 dispatchers

Planning i.e. registration of holiday, absence etc. for administrative staff

Comment:

0.2 Requirements for System supporting the complexities in dispatching The dispatchers will in the future dispatch several resources

- Pilots

- Boatmen

- Pilotboats

- Company cars (or other travel)

Dispatching pilots and boatmen

Dispatching pilots includes:

- Plan pilotages

- Allocate pilot to pilotages

- Plan rest periods

- Call in for overtime (if needed)

- Make sail plans for pilotboats

- Plan travelling ashore (where to travel and how to travel)

o Taxi

o Public transport i.e. train and/or bus

o Company car i.e. picked up by a boatman

o By airplane

Dispatching boatmen includes:

- Allocate boatmen sail plan

- Plan rest periods


- Allocate boatmen to transportation of pilot in company cars

21

Making sail plans

Making sail plans for pilot boats includes:

- Define tasks for pilot boats e.g. by using time-space-diagrams (already developed and not part of

scope, hovewer the planning process should include these) to identify possibilities for saving a boat

trip if one boat trip can serve two or more ships

- Allocate pilot boats to boat trips in accordance to sail plan

Transportation of by company cars With the new hub-structure in place it will be possible to realize savings on trips by taxi as the pilots often

can travel with the boatmen between the boat stations and the hub.

It is assumed that the dispatchers are able to track the company cars and plan the use of the company cars

operated by the boatmen in order to reduce the overall cost for transportation.

Requirement#0.2.4: Complexity of planning - Pilots


Description: The System should support the complexity mentioned in section 0.2:

Short term planning, dispatching and executing pilots includes:

- Plan pilotages

- Allocate pilot to pilotages

- Plan rest periods


- Make sail plans for pilotboats (utilising time-space-diagrams)

- Plan travelling ashore (where to travel and how to travel)

o Taxi

o Public transport i.e. train and/or bus

22

o Company car i.e. picked up by a boatman

o By airplane

Comment: See use case XX

Requirement#0.2.5: Complexity of planning - Boatsmen


Description: The System should support the complexity mentioned in section 0.2:

Short term planning and dispatching executing boatmen includes:

- Allocate boatmen sail plan (utilising time-space-diagrams)

- Plan rest periods


- Allocate boatmen to transportation of pilot in company cars

Comment: See use case XX

Requirement#0.2.6: Complexity of planning, shortterm planning, dispatchingand execution -


Description: The System should support the use cases ID 7.a, ID 7.b, ID 8.a, ID 8.b, ID 9.a, ID 9.b, ID

10.a, ID 10.b

Comment:

23

0.4 Requirements for System supporting the planning a transit pilotage within Route T

A pilotage from Allinge to Skagen may last

for 30 hours. Such a long pilotage needs

more than one pilot.

Due to an unbalanced demand where 75% of

the pilotages within Route T are northbound

transit pilots often travel ashore from Skagen

to Gedser or maybe even to Allinge.

To address this, pilotages may be divided

into a number of legs where pilots can be

changed.

Non stop pilotage:

In the case of a nonstop pilotage DanPilot provides 2 pilots from the starting point to the ending point of

the pilotage. That makes it possible always to have one pilot on the bridge and let the other pilot rest. This

will be the fastest possible service but also the costliest. This service is per default offered to VIP customers

and can be requested by other customers as an add-on product.

1+2 pilotage: In the case of a 1+2 pilotage DanPilot at the beginning only provide 1 pilot. After a while the second pilot

will onboard the ship and the remaining pilotage may be carried out like a nonstop pilotage. When

changing pilot the ship must slow down to let the pilot boat come along and put on or take off pilots. The

effect of this is that the pilotage will last longer compared to a non-stop pilotage but the utilization of the

pilots is higher.

Requirement#0.4.1: Transit pilotage – Non stop


Description: The System should be able to support 2 pilots from the starting point to the ending point of

the pilotage. The System should offer this services to VIP customers automatically and

make sure the Actor will offer this to other customers as an add-on product

Comment: The Actor is the type Dispatcher

24

Planning a 1+2 pilotage means that the

dispatchers must divide the entire pilotage into

several legs (defined by fixed PilotMarks/

PilotMarkGroups at the water) where it is possible

to change pilots.

It might be possible to changed pilots more than

once along the route even though DanPilot as far

as possible avoid that this happens.

As there are several PilotMarks along Route T

there are many possible combinations

(PilotMarkGroups) to consider when planning one

or more 1+2 pilotages.

Requirement#0.4.2: 1 + 2 pilotage


Description: The System should be able to support the Actor only plan 1 pilot at the beginning. After a

while the second pilot will board the ship and the remaining pilotage may be carried out

like a nonstop pilotage

Comment: The Actor is the type Dispatcher

Requirement#0.4.3: Planning and dispatching – Division of orders in “PilotMarks”/”PilotMarkGroups”


Description: The System should support division of orders in “PilotMarks”. I.e. a given transit route from

A to D (starting point and ending point) can bee devided into a PilotMarkGroup A-B, B-C

and C-D. This means that the planning System can optimize/plan based on changing Pilots

on/of the ship based the most optimal plan.

Comment: Please refer to Information model to definition of “PilotMarks”/”PilotMarkGroups”

25

0.5 Optimization of resources

1. Introduction

Currently the dispatching at DanPilot are done without any kind of optimization and only covers the pilots.

The new it-system shall include facilities for optimization of the utilization of all types of resources, i.e.

pilots, boatmen, company cars, and pilot boats, based on real time data and mathematical methods.

The following sections provide an overview of the current situation and sketches of which optimizations

DanPilot thinks that should be delivered with a new planning and dispatching system.

2. Definitions/terminology

Manual decision support A list of possible choices/decisions that the planner or dispatcher can

take. The list is prioritized due to a rule of thumb or common sense but

not based on any kind of optimization.

Optimized decision support The system offers

A list of possible choices/decisions that the planner or dispatcher can take. The list is prioritized due optimized solutions.

A global optimization of the entire problem.

Continuously and global

optimization

The dispatching system optimizes in the background continuously the

utilization of resources. This means that

1. if the actual decision/solutions made be the dispatcher is more than “x DKK” from the optimal solution an alarm will notify the dispatcher.

2. If the dispatcher want to replan the current utilization of resources it is possible to upload an optimal solution.

Optimization of selected

subproblem

The dispatcher can select a subgroup of resources and a subset of tasks

to be (sub)optimized and letting the remaining part of the plan be

unchanged.

26

3. Optimisation: Current As-Is-situation

As illustrated in the table below all planning and dispatching of resources at DanPilot is done manually

without any kind of optimized decision support. Furthermore, dispatching of the many kinds of resources is

done separately without a global perspective.

Manual decision

support

Optimization

Selected sub problem Continuously and global

Rosters for pilots ÷

Rosters for boatmen ÷

Rosters for dispatchers ÷

“Rosters” for administrative staff ÷ ÷

Dispatching of pilots ÷ ÷

Dispatching of boatmen () ÷ ÷

Travel planning of pilots ÷ ÷ ÷

Travel planning of boatmen ÷ ÷ ÷

Dispatching company cars ÷ ÷ ÷

Dispatching pilot boats ÷ ÷ ÷

: Done today ÷ : Not done today

In the as-is-situation dispatching of boatmen and pilot boats is not really part of the dispatching process. As

there today always is at least one boatman at standby at each boat station the dispatcher simply calls the

boatman and tells him where and when there is need for at pilot boat. Afterwards the boatman himself

plans the pilot boat sailing.

27

4. Optimisation: To-Be situation

Optimized decision

support

Optimization

Selected sub problem Continuously and global

Rosters for pilots

Rosters for boatmen

Rosters for dispatchers

“Rosters” for administrative staff

Short term planning/Dispatching/Execution of pilots

Short term planning/Dispatching/Execution of boatmen

Travel planning of pilots

Travel planning of boatmen

Dispatching company cars

Short term planning/Dispatching/Execution pilot boats

: Requirements to the System

Requirement#0.5.1: Optimisation – Rosters, Short term planning, Dispatching and Execution of plans


Description: The System should support Short term planning/Dispatching/Execution as one big

integrated optimized (according to table shown in 4. Optimisation: To-Be situation) som

dispatching encompassing all resources, i.e. pilots, boatmen, company cars, and pilot boats

supplemented with travel planning for pilots and boatmen. Thereby, the Short term

planning/Dispatching/Execution is assumed to be carried out from a global perspective not

suboptimizing each resource individually.

Comment: See use cases XX

28

5. Objective function for optimization

5.1 Rostering

5.1.1 Distribute day categories due to a defined profile

Normally rosters are created to meet a given profile for a given day category. This profile can be e.g.

defined per hour of the day, per weekday, time of the month, or per month.

The most important day categories to control/optimize in accordance to s profile will be

Duty days

Off duty days

Days off

Vacation days

Requirement#0.5.2: Objective function for optimization – Rostering


Description: The System should support when optimizing that the Actor can define one/or more goal(s)

or (multi-)objective function. Some of the most obvious goals will be

1. Distribute day categories due to a defined profile

2. Optimize the length of duty period

3. Equally distributed shifts in and out of duty periods

4. As far as possible meet request for days off

But other goals may also be conceivable.

Comment:

Requirement#0.5.3: Objective function for optimization – Distribute day categories due to a defined

profile


Description: The System should support profile can be e.g. defined per hour of the day, per weekday,

time of the month, or per month and that important day categories to control/optimize in

accordance to profile:

Duty days

Off duty days

Days off

Vacation days

Comment:

29

5.1.2 Optimize the length of duty period

As the length of duty day periods are determining for the degrees of freedom when dispatching

Requirement#0.5.4: Objective function for optimization – Optimize the length of duty period


Description: The System should support that the Actor can define a wanted profile for the length of

periods as illustrated in the table below

Comment:

Number of duty days in a row Wanted percentage

3 0%

4 2%

5 15%

6 20%

7 25%

8 35%

9 3%

30

5.1.3 Equally distributed shifts in and out of duty periods

As the demand for long transit pilotages as well as for short port pilotages can occur at any point of time

DanPilot’s preparedness must be continuously distributed over the hour of the day and the day of the

week. This means that in a good roster shifts in and out of duty periods are spread as much as possible

over the day and the week avoiding that e.g. all pilots on duty goes in and out of their duty period Thursday

at 12:00. Because this will make it impossible to serve customers at Thursdays at 12:00.

An exception from this might be if a group of ports introduce opening hours, e.g. only are active at working

days from 06:00 to 18:00, then shifts could either be placed outside the opening hours at the ports or might

be equally distributed within the opening hours.

5.1.4 As far as possible meet request for days off

5.1.5 Multi-objective function.

Often it might be needed to optimize according to more than one criteria. Therefore, it might be possible to

define multi-objective function by combining/weighing two or more of the above mentioned criteria

together.

Requirement#0.5.5: Objective function for optimization – Equally distributed shifts in and out of duty

periods


Description: The System should support equally distributed shifts in and out of duty periods

Comment:

Requirement#0.5.6: Objective function for optimization – As far as possible meet request for days off


Description: The System should support the Actor in (as far as possible) meeting request for days off

Comment: It is important that the employees can have the request days of freedom and that the

allocation of vacation is perceived as fair.

The Actor is the Planner.

Requirement#0.5.7: Objective function for optimization – Multi-objective function


Description: The System should support the Actor in defining multi-objective function by

combining/weighing two or more of the leow mentioned criteria together:

1. Distribute day categories due to a defined profile

2. Optimize the length of duty period

31

5.1.6 Goals meet within the individual roster and globally for all roster

3. Equally distributed shifts in and out of duty periods

4. As far as possible meet request for days off

Comment: The Actor is the Planner.

Requirement#0.5.7: Objective function for optimization – Goals meet within the individual roster and

globally for all roster


Description: The System should support the Actor in letting it be possible to let all goals1 apply to the

individual rosters, a group of roster, all rosters, or even a combination of this.

1For all the examples of goal, or objective function, mentioned in above requirements in

#0.5.2to 0.5.7.


32

5.2 Short term planning, Dispatching and execution

5.2.1 Minimizing the overall costs

Requirement#0.5.8: Objective function for optimization – Short term planning, Dispatching and

execution optimizing by defining goal(s) or (multi-)objective function


Description: The System should support the Actor in optimizing by defining goal(s) or (multi-)objective

function. Some of the most obvious goals might be

1. Minimizing the overall costs

2. Maximize the robustness of the plan

3. Introduce as few changes as possible to the existing plan

4. Ensure that pilots can maintain their certificates

5. Maximize customer satisfaction

6. Maximize the employee satisfaction

7. Distribute the workload equally among the employees

But other goals may also be conceivable.

Comment: The Actor is the Dispatcher

Requirement#0.5.9: Objective function for optimization – optimizing by minimizing the overall costs


Description: The System should support the Actor in optimizing by minimizing the overall costs:

Overall costs include among others

overtime remuneration for pilots and boatmen

costs due to pilots’ rest periods outside DanPilot’s stations

costs due to boatmen’s rest periods outside place of employment (i.e. own station)

fuel consumptions for pilot boats

sailing hours for pilot boats

travel cost for pilots (i.e. taxi, bus, train, airplane, and km in company cars)

travel cost for boatmen (i.e. km in company cars)


33

5.2.2 Maximize the robustness of the plan

5.2.3 Introduce as few changes as possible to the existing plan

Requirement#0.5.10: Objective function for optimization – optimizing by maximizing the robustness of

the plan


Description: The System should support the Actor in optimizing by maximizing the robustness of the

plan due to:

changing ETAs and ETDs

sick leave for pilots and boatmen

unforeseen incoming orders both in transit and ports


Requirement#0.5.11: Objective function for optimization – Introduce as few changes as possible to the

existing plan


Description: The System should support the Actor in optimizing using the “correct level” of frozen zone1

before executing

1On one hand, it is important not to introduce to many changes to often after

announcement of an executing plan for the incoming orders as everyone will be confused

and/or frustrated. On the other hand, you also must change the announced executing plan

if it has become too expensive compare to the optimal solution.


34

5.2.4 Ensure that pilots can maintain their certificates

Pilot are maintaining their certificate by carrying out a minimum number (e.g. 5, 10 or 20) pilotages per

year per certificate.

5.2.5 Maximize customer satisfaction

It is inconvenient for customers to change pilots during a pilotage. Furthermore, changing pilot at some

pilot marks is more inconvenient than changing at other. Therefore, it is interesting to minimize the

inconvenience for customers by changing pilots.

It is important for customers that DanPilot is on time. Therefore, it is important that the number of cases

where DanPilot request changes to ETA or ETD are minimized.

Requirement#0.5.12: Objective function for optimization – Ensure that pilots can maintain their

certificates


Description: The System should support the Actor in optimizing pilotages must be distributed as equally

as possible among pilots who hold the considered certificate


Requirement#0.5.13: Objective function for optimization – Maximize customer satisfaction


Description: The System should support the Actor in maximizing customer satisfaction


Requirement#0.5.14: Objective function for optimization – Maximize customer satisfaction


Description: The System should support the Actor in minimizing the number of cases where DanPilot

request changes to ETA or ETD


35

5.2.6 Maximize the employee satisfaction

Some sequences or combinations of tasks may by the pilots/boatmen be considered as inconvenient.

5.2.7 Distribute the workload equally among the employees

To avoid envy the workload must be equally distributed on pilots/boatmen.

5.2.8 Multi-objective function.

Requirement#0.5.15: Objective function for optimization – Maximize the employee satisfaction


Description: The System should support the Actor in minimizing the number of those sequences or

combinations or at least distribute those equally among the pilots/boatmen.


Requirement#0.5.16: Objective function for optimization – Distribute the workload equally among the

employees


Description: The System should support the Actor in distributing the the workload equally amongst

pilots/boatmen over a selectable period of time


Requirement#0.5.17: Objective function for optimization – Optimize according to more than one

criteria


Description: The System should support the Actor in letting it be possible to define multi-objective

function by combining/weighing two or more of the mentioned criteria1 together.

1For all the examples of goal, or objective function, mentioned in above requirements in

#0.5.8to 0.5.16.


36

Requirement#0.5.17: Complexity of optimization of planning, shortterm planning, dispatchingand

execution -


Description: The System should support the use cases ID 11, ID 12, ID 13, ID 14, ID 15, ID 16, ID 17

Comment:

37

1. Other Requirements

1.1 Functional requirements orderprocess:

Requirement#1.1.1: Orders – Receiving Automatic Orders for Pilotage


Description: The System should support use case ID 5 Receiving Automatic Orders for Pilotage

Comment:

Requirement#1.1.2: Orders – Receiving Manually Orders for Pilotage


Description: The System should support use case ID 6 Receiving Manually Orders for Pilotage

Comment:

Requirement#1.1.1: Change of an order – before execution


Description: The System should support that the Actor is capable registrering “time of change” and

“reason for change” when the startdate/time and enddate/time of the order is altered

Comment: This requirement serves for input to Danpilots KPI’s (It is not a timestamp, but a manual

change process that the Actor must carry out)

Requirement#1.1.2: Change of an order – after execution


Description: When an order is executed the System should support that the Actor is capable registrering

“time of change” and “reason for change” when necessary at the same time to change the

startdate/time and enddate/time of the order.

Comment: This requirement serves for input to Danpilots KPI’s (It is not a timestamp, but a manual

change process that the Actor must carry out)

38

Requirement#1.1.3: Manually inputted order data may not be deleted


Description: Order data coming from the API (Use case ID5) is also considered “Manually inputted data”

In order to have an uninterrupted lifecycle of all records, data inputted manually may not

be deleted, but should marked as deleted, together with metadata describing who and

when the “delete” marking was made.

Comment:

1.2 Functional requirements planning and dipatching:

This section the primarily functional requirements for the Actors when they use the System. These are

described as requirements and not as use cases. Several of the use cases will imply that these requirements

are fulfilled as a part of the Systems capabilities.

Requirement#1.2.1: Visual planning and dispatching – drag and drop


Description: The System should support visual planning and dispatching functions by e.g. drag and drop

functions.

Comment:

Requirement#1.2.2: Visual planning and dispatching – overview


Description: The System should support visual planning and dispatching functions by e.g. having the

ability to individually design and save screensettings, how critical planning and dispatching

windows are shown

Comment:

Requirement#1.2.3: Planning and dispatching – Alarms


Description: The System should support setting of alarms in order to “remind” the actor on certain tasks

e.g. wake-up call of Pilot. The System should be able to relate these to jobs

39

Comment:

Requirement#1.2.4: Planning and dispatching – Click-to-dial


Description: The System should support click-to-dial i.e. that the Pilots name is shown and when mouse-

over is performed the System offers click-to-dial to that specific Pilot

Comment: This requirement requires integration to the Pilots and Boatmen names and telephone

numbers and a integration to the Danpilot telephone System. See section XX

Requirement#1.2.5: Planning and dispatching – Click-to-SMS


Description: The System should support click-to-SMS i.e. that the Pilots name is shown and when

mouse-over is performed the System offers click-to-SMS to that specific Pilot based on a

standard set of standard Short Message System messages

Comment: This requirement requires integration to the Pilots and Boatmen names and

mobiletelephone numbers and a integration to the Danpilot telephone System. See section

XX

Requirement#1.2.6: Planning and dispatching –Rules + Actomatic dialing


Description: The System should support automatic dialing and voiceSystem i.e. a rule can be set based

on a job and a Pilot/boatman. Execution of that rule results in a automatic dial to that

person with a prerecorded standard message

Comment: This requirement requires integration to the Pilots and Boatmen names and telephone

numbers and a integration to the Danpilot telephone System. See section XX

40

Requirement#1.2.7: Planning and dispatching – Rules + Automatic SMS


Description: The System should support automatic dialing and SMS System i.e. a rule can be set based

on a job and a Pilot/boatman. Execution of that rule results in a automatic SMS to that

person with a standard message

Comment: This requirement requires integration to the Pilots and Boatmen names and

mobiletelephone numbers and a integration to the Danpilot telephone System. See section

XX

Requirement#1.2.8: Planning and dispatching – Automatic updating of “chainactivities”


Description: The System should support automatic updating of linked or chained activities i.e. when a

transportation activity for a Pilot is prolonged the following activity of Pilotage should be

automatic updated in relation to the time.

Comment: If activity A (Pilot transportation) comes before activity B (Pilot enters Pilotboat to be sailed

to Ship for Pilotage) and activity C (Pilotage from point X to Y), postponing activity 30

minutes means that the System automatically should postpone both activity B and C,

hence Automatic updating of “chainactivities”.

Requirement#1.2.9: Planning and dispatching – Geographical split of management of jobs


Description: The System should support geographical split of management of jobs. This requirement

makes it possible for several Actors to use the System simutaniously, however each with a

geographical focus on the Straits, habours and waters souring Denmark

Comment: The Actors will be Planners and Dispatchers

41

1.3 Functional requirements reporting:

14

20-25 pilot boats.

Requirement#1.2.10: Planning and dispatching – Other types of ressources than pilots/boatsmen


Description: The System should support that the Actors can assign company cars for transportation of

boatmen and pilot boats14 bringing pilots to and from ships.

Comment: The Actors will be Planners and Dispatchers

See relation to use case XX

Requirement#1.2.11: Planning and dispatching – “Retired Pilots” should be less prioritized in planning

views


Description: The System should support that “Retired Pilots” should be less prioritized in planning

views in way that Pilots are managed in the System according the rules

Comment: See relation to use case XX

Requirement#1.3.1: Reporting– Certificates to Danish Maritime Authority


Description: The System should be able to produce reports stating the number of trips and which

certificates the Pilot or Boatman has participated in from a start date to an enddate of own

choice. The layout should be like XX in order to support the Pilot in reporting to the Danish

Maritime Authority in order to maintain the Pilots certificate.

Comment:

42

Requirement#1.3.2: Reporting– Certificates - warnings


Description: The System should be able to produce reports stating the number of trips and which

certificates the Pilot or Boatman has participated in, and giving warnings about certifactes

not being maintained. The warnings should be communicated to the Actors

Comment: The actors will be Dispatchers, Dispatch Manager, Pilots and Boatmen

Requirement#1.3.3: Reporting– Tracking of ressources


Description: The System should be able to create a online repport (map) where all available ressources

are shown. The following ressources shall be included: Pilots, Boatsmen, Ships en-route,

Pilotboats, Danpilot cars

Comment:

Requirement#1.3.4: Reporting– Standard repports


Description: The System should be able to show a number of relevant standard reports

Comment:

Requirement#1.3.5: Reporting– Logging


Description: The System should be able to create a log based on Jobs hence the Actor can see which

decisions and actions that the Dispatcher made and the consequences related to these

choises. It is important that this log is understandable without reading codes or order

43

1.4 Functional requirements sales data:

helping tables. That means that this log should be readable and understandable to simple

user

Comment: The actors will be Dispatch Manager and Planning and Dispatch Manager

Requirement#1.4.1: Sales - Important information can easily be inputted for each ship, i.e. when

inputting and order, for later use.


Description: This ship “note” information should be easily available to the pilot when presented with

1. order information

2. ship information

This information could be:

1. something a pilot observes something that the next pilot on the same ship should

know before going on board the ship

2. extra services (newspaper delivery)

Comment: The actors will be Dispatchers and Sales Employees and Pilots and Boatmen

Prerequisite that the maintance of shipdata is done in the System

Requirement#1.4.2: Sales Employees can create orders, with the expectation that they will become

“definite” orders in the near future, after contact with the en-route ship.


Description: Order creation in the System, without 100% certainty that DanPilot will be booked to

execute the order.

Comment: Actor is Sales Employee

44

Functional requirements finance/ billing data:

Not defined yet

Functional requirements wage data:

Not defined yet

45

2. Non functional requirements

2.1 Requirements for Architecture, Integration and Security In this chapter, requirements and expectations regarding the architecture for a future Pilot Planning

System are described. In addition, requirements and expectations for integration with other Systems in

DanPilot are described. Finally, requirements and expectations regarding security are described, at a high

level. If specific security requirements are needed for a certain service/component, these will be described

for each service/component in a later section. At last the data management reqirements to the System and

to other systems is described.

2.1.1 Architecture Since DanPilot is requesting a standard solution to the widest extent possible, the solution architecture will

be determined by the proposed solution. DanPilot is flexible with respect to the specific application

architecture, but expect the proposed solution to fulfill most of the following architectural principles.

In terms of the environment in which the new System must “fit in” and the integration with existing

Systems, requirements will be defined in the sections that follow.

Principles

Requirement#2.1.1: Architecture – Loosely-coupled architecture

Category: Requirement Type: Non-Functional

Description: The architecture to the proposed solution should be supporting a loosely-coupled

architecture

Comment: Danpilot prefer loosely coupled services and components over large monolithic Systems.

This to make future changes easier and faster.

Requirement#2.1.2: Architecture – Logical in Danpilot domain/context


Description: The architecture to the proposed solution should be supporting a logical user interface

easy to understand, logical in our domain/context and it have to be consistent throughout

the application

Comment: User-focused solution. This is supporting the user friendliness refered to in section XX

46

Requirement#2.1.3: Architecture – Isolated databases


Description: It is a requirement that databases must be isolated. Databases are an implementation

detail and as such should not be exposed to external Systems or services.

Comment: Are API’s in place at relevant points, where integration through a shared database would

otherwise be another possibility?

Requirement#2.1.4: Architecture - Documentation


Description: It is a requirement that the current System documentation is describing the overall

architecture, the most important components and their interaction.

Comment:

47

2.1.2 Integration This chapter describes all integration solutions that are in place today at DanPilot. Possible future

integration solutions are also included, to ensure that a new Pilot Planning System either includes these or

can be extended to include these.

Existing Integration Points Table 1 provides an overview of the existing integration solutions in place currently. Each integration

solution is described in detail in a separate section following this section.

Name Purpose Involved Solution Provider(s)

Integration with SeaWeb To get up-to-date ship data for the ships that we provide our pilotage services to, so we do not have to enter these data manually.

IHS/Fairplay in England. We currently have a year-based contract with a ”pay-per-download” agreement.

Integration with PDC To get current roster planning data for employees from our current roster planning System (PDC).

PDC (Prolog Development Center) in Brøndby, Denmark.

Integration with Navision To be able to send completed orders to invoicing.

CGI is our current partner with respect to Dynamics Navision.

Integration with GateHouse services.

To be able to track ships so we get the most precise ETA at each start pilot mark and a precise ETA at the destination pilot mark, once a pilotage has started.

GateHouse provides these API-based services and data.

Integration with ”Elektronisk Lodsseddel” (ELS)

To send orders to the assigned pilots (smartphone or – soon - to an iPad running SafePilot). Enables the pilot to report an order completed.

Trelleborg, Sweden (formerly ”Marimatech” in Århus, Denmark)

Integration with GatShip To be able to receive Orders directly from the Norwegian System ”GatShip” (and possibly other external Systems). This System is used by many Danish brokers, to control their tasks in a port for a customer. This includes some of our largest customers for the Regional segment.

GatShip in Oslo, Norway is the solution provider for this System. DanPilot have developed our own API-based integration with GatShip in close cooperation with GatShip.

Integration/ETL process for DataWarehouse and BI

To provide our users with relevant, up-to-date data, reports and KPI’s, based on data coming from e.g. the Pilot Planning System.

”Kapacity” in Denmark have assisted us a great deal with the setup and maintenance of our current BI solution. In-house Data Manager is the daily responsible here.

Master data manager tool (aka. “MADAM”).

To allow non-IT employees to maintain core data such as our

DanPilot has an internally developed ASP .NET website in

48

Name Purpose Involved Solution Provider(s)

routes, pilot marks, boatstations, travel times and contact info for pilots and boatmen.

place for the current database behind the Pilot Planning System.

Table 1. List of the existing integration solutions.

Requirement#2.2.1: Integration – Requirement for present integration


Description: The System should be able to integrate with all interfaces/systems mentioned in table 1

Comment:

Requirement#2.2.2: Integration – Integration with PDC


Description: As it is a requirement that the Supplier makes Roster planning this integration will possibly

will not be needed. However the Supplier should clearly state if this is a part of the offered

System or not

Comment:

Requirement#2.2.3: Integration – Integration with ”Elektronisk Lodsseddel” (ELS)


Description: As it is a requirement that the Supplier will supply 2 way communication this integration

will possibly will not be needed. However the Supplier should clearly state if this is a part of

the offered System or not

Comment:

49

Future Integration Points Table 2 below lists the integration solutions that DanPilot have discussed earlier and see as valuable

integration points in the future. Note: These are additional integrations, and not a total list.

Name Purpose

Employee Data/HR System To avoid having to update employee data in the Pilot Dispatch System.

More complete integration between SafePilot and the Pilot Planning System.

To be able to receive updates to order details directly from the pilot, during execution of the order. E.g. “pilotage started”, ”ETA destination updated” etc. “SafePilot” is the next version of “Elektronisk Lodsseddel” (ELS), expected release currently in Q1 2017. Today, only the “order completed”, including changes to the route, comments, and signature from the captain are received from the Pilot’s device.

Integration with the Danish Maritime Authority (DMA) known as “Lodstilsynet” certificate statistics and maintenance for pilots.

To automatically report completed orders for a pilot to the DMA in order to track the pilots certificate-data.

Integration with PDC (the current roster planning System) with respect to time spent for pilots (and potentially boatmen as well).

Send actual time spent for pilots to PDC for measuring and tracking overtime and ultimately input the results to the salary process.

Better integration with Navision Abandon the need to maintain e.g. ship- and route data and separately in Navision, and to provide a more “near-real-time” order completion process. (Currently this is a flat-file based, batch-based process).

Better travel time precision The Pilot Planning System must be able to plan for pilots including any travel time needed between two jobs (or to/from home). Currently, this is based on lookup-tables in the database. To improve the precision of these travel times, an integration with an external travel time provider is needed. This should include detailed travel data for Denmark for the relevant means of transportation (bus, train, flights and taxi).

Integration to external System regarding creation of new orders.

We expect to be able to create orders via an API to the new System so that orders can either be created manually or electronically from an external System.

Integration with the Payroll System Currently we send files, we have manually made to a provider that loads the data into an in-house System “Lessor”.

Table 2. Future integration points for the System.

50

Requirement#2.2.4: Integration – Requirement for future integration


Description: The System should be able to integrate with all possible new interfaces/systems mentioned

in table 2

Comment:

Requirement#2.2.4: Integration – Requirement for future integration Navision


Description: The System should be able to integrate with Navision version XX mentioned in table 2

Comment:

51

2.1.3 Security This section describes all requirements related to security.

The Nature of Our Data in General The data DanPilot handles is in general not classified. All data regarding our orders, employee data and the

planning regarding these is not classified information. However, the following information is part of our

dataset in use by the Pilot Planning System, and not something we want to expose:

Email addresses of employees and customers/ships.

Social security numbers for employees (“CPR-nr”).

Time registrations (activities and whereabouts) for employees.

Private addresses for employees.

Security Requirements

The current planning System runs internally, as a Windows Desktop solution, and is not exposed to the

internet. It is not accessible from outside the DanPilot firewall solutions.

The current System uses authentication against Active Directory when a user logs into the System. In

addition, database-level security is applied, again by using AD groups and associations. Beyond this, no

further security measures are in place for the current System. The System has a very basic user model, that

allows a few super users access to certain features.

Depending on the specific solution offered, the same security model could be valid in the future as well.

The following list of requirements is valid for both cloud- and non-cloud based solutions:

Requirement#2.3.1: Security – Login-method


Description: The System should be able to integrate with Active Directory, to minimize user data

maintenance.

The login-method for the System must be described.

Comment: In case of no AD integration, the model for user data maintenance must be described. E.g.

how are new users added and how are their data maintained?

Requirement#2.3.2: Security – Authentication


Description: The specific authentication mechanism provided by the System must be described. E.g. if a

role-based authentication model limits access to certain areas of the System.

Comment:

52

Requirement#2.3.3: Security – Use of use SSL for traffic encryption


Description: If the System depends on components/services that are served from public-accessible

webservers (via the internet), these services must use SSL for traffic encryption

Authentication mechanisms used by each service must be described. Basic or Windows

Integrated authentication is acceptable, if SSL is used

Comment:

Requirement#2.3.4: Security – Danish legislation


Description: Any data that is governed by Danish legislation must be handled accordingly. E.g. sensitive

data such as “CPR”-numbers.

Descriptions on how the proposed System adheres to these regulations must be provided,

when applicable

Comment: Please also refer to Appendix K02 for documentation requirements

53

2.1.4 Non- and functional requirements data management:

Requirement#2.4.1: Access to data from an external it-System

Category: Minimum Requirement Type: Non-Functional

Description: It is a requirement that the architecture of the System supports an external System

copying all relevant data (including historical data) to an external datawarehouse SQL

database without noticeable performance degradation for the primary Actors.

The Supplier should describe what documentation is necessary and deadlines for changes

in what data is copied from the System.

Comment: Today the necessary “production data” is first copied to the datawarehouse server’s sql

database. After that, the data is then transformed, etc. such that the connection to the

production System is as short as possible. Only data used in the datawarehouse is copied

today, which is just a small percentage of the total production data.

Requirement#2.4.2: Access to data for ad-hoc queries

Category: Minimum Requirement Type: Functional

Description: The system should enable the Actor to:

- Access to production data or a copy of production data (including “master data”,

which is at most 1 hour old, without noticeable performance degradation for the

primary actors, and without having to contact the supplier regarding access rights

to new types of data.

- All data which is necessary (including changes made to data) for planning and

executing (including master data) an order must be made available.

- If the UI for this type of access is proprietary:

o the data must be able to be exported via max. 2 mouse clicks, into an excel

spreadsheet. Each record must contain an “export” timestamp.

o Filtering possibilities must be available to limit the amount of data

exported, i.e. by number of rows.

The supplier must document :

which access method(s) will be available and if proprietary access, examples of how this

looks and is used today by other customers, and what filters can be used

Comment: This is a requirement because only a portion of the production data is copied to an external

database, and because it is difficult to predetermine what questions about production will

be asked in the further.

54

Requirement#2.4.3: Data Documentation

Category: Minimum Requirement Type: Non-Functional

Description: It is a requirement that a detailed description of the data including the data model (i.e. E-R

diagram) must be available to aid the Analyst and DataManager in order to copy only the

necessary data to the Datawarehouse.

DanPilot needs to be informed of planned changes to the model to the mail address

[email protected] at least one month before the planned implementation of the change.

Comment: Please refer to the description in the K02 appendix regarding documentation. This

requirement adds to the requirements stated in the K02 appendix

Requirement#2.4.4: Requirement to what types of data DanPilot needs to have access to, and data about

data that needs to be available to DanPilot


Description: The system should enable the Actor to acces the following types of data:

1. information about synchronization or communication with external Systems. Ie.

We must be able to distinguish which data comes from an external System and

when it was last updated by the external System.

2. information about who inputs directly into the System, what, and

when(timestamps) into the System. (manually inputted data)

3. information about the type of action – data creation, change of existing values,

adding of information to existing records, changing of status of data. See example

below of how we look at this type of information today at the bottom of this

document.

4. Data values before and after the changes are made to the data

The Supplier must document how new data and changes to data is registered in the

production System.

Comment:

mailto:[email protected]

55

2.2 Non-Functional requirements master data including certificates:

This section is non-functional requirements for the Actors when they use the System. There are related to

master data including certificates. These are described as requirements and not as use cases. Several of the

use cases will imply that these requirements are fulfilled as a part of the Systems abilities.

Table 1: Example of certificate data:

Employee Certificate Data: Certificate Name/ID, Certificate Level, Date Valid From, Date Valid To

Table 2: Example of HR Employee Data:

Company Address Statistics Group Code Number of Hours employed

Salary ID Address2 Employment Date Next of Kin Name

Blocked City Status Relationship (Parent, child,

spouse, cohabitant)

First Name Post Code Termination Date Next of Kin telefon nr.

Middle Name Phone No_ Company E-Mail EmployeeGroup(1=Pilot,2=Pilot

temp ,3=Boatman, 4=Boatman

temp,5=Dispatcher,6=Dispatcher

temp,7=not defined yet)

Last Name Mobile Phone No_ Place of Employment Pilottype (Harbor, Transit,

Distance, Both) (havn,transit,

begge)

Initials Private E-Mail

DWCreatedDate

Job Title Birth Date Dimension for Salary

(StedKode)

Requirement#2.2.1: Master data – New employees created in HR System will be created in System

Category: Requirement Type: Non-functional

Description: The System should support the transfer of new employees/termination of retired

employees created in HR System will be created/updated in System of data. The data

related to a new employee will be name, adresse, telefonenumber, mobilenumber etc. but

also information about certificates (Please refer to datafields requirements in table 1 and

2)

Comment: Certificates are critical in relation to business rules for both Actors Pilots and Boatmen

56

Requirement#2.2.2: Master data – Data should be updated real time


Description: The System should support the transfer the information real time

Comment:

Requirement#2.2.3: Master data – All accounts related to employees should be replicated to and from HR

System


Description: The System should support the replication of all accounts related to employees should be

replicated to and from HR. Account consist information about illness (hours/days), right to

vacation (hours/days), already held vacation (hours/days) and so on

Comment:

Requirement#2.2.4: Master data – Maintance of (more “static”) data in System


Description: The System should provide easy access to maintanace of (more static) masterdata e.g. Pilot

Marks and PilotMarkGroups including hierarchy, locations etc.

Comment:

Requirement#2.2.5: Master data – Maintance of (more “dynamic”) data in System


Description: The System should provide easy access to maintanace of (more dynamic) data e.g.

traveltime, certificates, SOPs, union agreements in relation to alle business rules. See

section XX for all business rules

Comment:

57

2.3 Data management Here is the expected picture of the primary it-systems which have interfaces to the System and the types of data which each system manages.

Starting from the left side of the diagram with blue framed boxes:

In order to invoice a customer automatically at some point in the future, it will be required that the billing customer number is available in the

new system. This is the reason for the box “Navision - Billing Customer”.

DanPilot is in the process of purchasing a HR system and therefore the new box “New HR System” and at the end a list of expected data

stored there.

The Orange boxes show the “Master Data” which presently an integrated part of the existing System called PilotBoard

The MPDS box consists:

Production data in black boxes

The filled in green boxes are information needed regarding Roster Planning

The filled in blue box is to illustrate the need for new “mapping tables” linking the System to the data in external systems

Requirement#2.3.6: Data – Organisation of data in the System- datatypes will be maintained


Description: It is a requirement that the Supplier specifies where (new system, DanPilot’s systems) the

different datatypes will be maintained, and how the data will flow between the external

systems to the new system including push, pull and time related to diagram 1

Comment:

58

Requirement#2.3.7: Data – Organisation of data in the System - mapping data will be maintained


Description: It is a requirement that the Supplier specifies where the mapping data will be maintained

(new system, DanPilot’s system), and how the data will flow between the external systems

to the new system including push, pull and time related to diagram 1

Comment:

Requirement#2.3.8: Data – Organisation of data in the System - Explanation for placement of datatypes


Description: It is a requirement that the Supplier specifies the following:

For the datatypes the supplier wishes that DanPilot continues to maintain as we do today,

describe why this is so, and if it will be possible to continue using the datatypes that are

already used today in our existing system related to diagram 1

Comment:

59

To-Be (Diagram 1)

Master data

Maritime Planning and Dispatching System

VIP Customer Data and

Advantages

Actual Activity Data (who/what resource and

what activities completed,

where and start&end

dates/times)

Route, PilotMark and

Certificate Data

including Invoice

Ship Data

Boat Station Data (in

progress as addition to

PilotBoard due to hub)

Location Data (needed to

map Place of Employment to

Location, which includes other locations)

Logfiles – incl. External

Communication and

Changes to data over

time (historic data)

Rules used to calculate

salary per agreement

Pilot boat Data

Pilot Order App (info the

pilot inputs at i.e. beginning

and end of the order, i.e.

Change to order which

affect billing)

Roster Planning Who and what resources are

available to work, when and

which type of absence. BI Access to Resource

Planning Data for analysis

2 way communication (i.e. Salary Calc., vacation

time registrations, Activity

registration)

Management

Verification i.e. salary data before final

transfer of payroll system. Employee Ipad App

(i.e. Salary Calculation, time

registrations)

Boat Station Data

(ie. no. of rooms)

Data

Change Reason Data

Employee Registration Non “PilotPlan” activities i.e.

project work, which means not

available for Piloting work

Mapping Data

External Order User Data

New HR System

Employee Data and

Employee Certificate

Data, etc…

Standard Pay Rates incl.

overtime rates / work type

Order Data

Company Car Data

Travel Data

(water & land)

Copy of Master Data ie. from Navision and HR

Navision

Billing Customer

Standard Alarm Data

Business rules

External Orders

Data - sent

electronically

60

2.4 Non-funtional requirements 2-way communication

Requirement#2.4.1: 2-way communication – Offline buffering of information

Category: Minimum Requirement Type: Non-functional

Description: The system should support offline buffering of information when theres no contact to

mobile network/wireless connection

The information should be bufferet and sent as soon as possible when there is a

connection

Comment:

61

2.5 Integrations

[Diclaimer: This section is not consistent due to the fact that it has not been revised and corrected so all

information is consistent with the rest of the requirement specification. The Supplier should only consider

this information on a high level in order to get som more information regarding existing and possible

integrations]

Integration: SeaWeb

Purpose To get up-to-date ship data for the ships we provide pilotage services. E.g. the name, IMO-number (a

globally unique identifier), length and width of the ship.

Without this integration, we would need to enter approx. 1.000 new ships each year, complete with all

info. This is time-consuming and error-prone. In addition, updates to ship data would have to be input

manually, and are likely to be forgotten/missed.

62

Interface description SeaWeb provides a WSDL-based web service that has the following definition:

Figure 2. Snippet of the WSDL definition for the SeaWeb Web Service. APSShipDetail is the response object that contains ship details (approx. 100 properties of the ship). Request key is the IMO-number of the ship.

Click here for a link for viewing the complete WSDL online.

Availability

This service needs to be highly available, since we cannot proceed with creating an order without a ship

assigned. Currently, we have a “fallback” implementation, such that if the external web service (SeaWeb)

does not respond, we try to look up the ship in our internal ship database. If not found here, the user will

need to create a new ship, using the provided IMO-number. Next time the same IMO-number is used, we

will most likely get an update to the ship, and the ship data will be complete and up-to-date.

Data Volume and Throughput We process approx. 60 orders/day. This gives a need for approx. 100 ship data lookups/day.

http://maritimewebservices.ihs.com/MaritimeWCF/APSShipService.svc?singleWsdl

63

Ship data is only requested and stored when a user requests it – there is no continuous/background flow in

place.

Use Cases

Although SeaWeb is currently our main provider of the “official” ship data, at times we need to create a

new ship and enter the needed details. E.g. when SeaWeb does not have the ship (some ships do not have

an IMO-number – these are not available from SeaWeb) or if the service is down.

In addition, we currently have the option to add notes of our own, for each ship. This allows us to input e.g.

important defects reported by the pilot, which will then be displayed to the dispatcher for the next order

for the same ship.

Alternatives Marinetraffic.com (online ship data provider).

64

Integration: GateHouse (AIS-data)

Purpose The Pilot Planning System must include AIS-based data, in order to track the ships that request pilotage

services. This allows the dispatchers to obtain up-to-date, reliable info on the start- and end time for a

pilotage job. This in turn improves the quality of the plans produced by our dispatchers.

Provider GateHouse is a Danish company, specialized in software solutions for optimizations, flexibility and mission

critical operations within tracking, monitoring and satellite communication. They provide an API that is

currently used in DanPilot for tracking ships (our customers) in order to obtain accurate POB (Pilot-On-

Board) time and ETA’s for destinations.

Interface description

The API currently in use in publicly accessible from:

https://maritime.gatehouse.dk/pub/api-doc/portserver/reference/index.html

It is an HTTP-based, resource-oriented API. We currently use the “Track” resource, specifically these

operations:

Operation Description

POST /ship/track Start a track of a ship towards a predefined destination

GET /ship/track Get status of a track for all ships towards predefined destinations

PUT /ship/track/{id} Update arrival with ERP information

GET /ship/track/{id} Get status of a track of a ship towards a predefined destination

DELETE /ship/track/{id} Stop and delete a track.

Data Volume and Throughput Estimates:

60 orders per day yields 60 POST calls to the API.

Currently we send approx. 150 updates (PUT) every 5 minutes. GateHouse needs the currently entered

start- or end time in order not to stop a track for ship “too early”, if that ship is expected e.g. the day after.

We developed the API in close coordination with GateHouse, and at one point we saw cases where a track

would be stopped/deleted too early. GateHouse uses our manually entered “expected time” to determine

whether to stop a track.

60 orders per day yields 60 DELETE calls to the API as well.

In total: approx. 300 calls are made to the API per day.

Use Cases

Create Order/Job When a new Job is created, a new track is also created. A POST is sent to the GateHouse API.

Updates Every time a Job is updated, we also update any existing track, previously created with the GateHouse API.

This causes a PUT request to be issued.

https://maritime.gatehouse.dk/pub/api-doc/portserver/reference/index.html

https://maritime.gatehouse.dk/pub/api-doc/portserver/reference/index.html#operation--ship-track-post

https://maritime.gatehouse.dk/pub/api-doc/portserver/reference/index.html#operation--ship-track-get

https://maritime.gatehouse.dk/pub/api-doc/portserver/reference/index.html#operation--ship-track--id--put

https://maritime.gatehouse.dk/pub/api-doc/portserver/reference/index.html#operation--ship-track--id--get

https://maritime.gatehouse.dk/pub/api-doc/portserver/reference/index.html#operation--ship-track--id--delete

65

Complete Order/Job Finally, when a Job is completed, any associated track can be deleted by issuing a DELETE request to the

GateHouse API. This is a required operation, to “clean up” data usage at GateHouse (if not done properly,

too many “running” tracks will degrade the service with GateHouse).

Availability This service does not need to be highly available, since it “only” provides additional information on top of

what we already know for a Job/Order. However, service downtime should be monitored, so we at least

know when the service is down, and can take appropriate action.

Alternatives

No alternatives have been considered.

66

Integration: Elektronisk Lodsseddel (ELS) / SafePilot

[This integration (ELS) is probably not relevant and therefore probably not consistent with the rest of the

requirement specification.]

Purpose The Pilot Planning System must be integrated with the mobile solution used for Pilots. Pilots currently use

their smartphone (Android-based) to report Orders as “completed”. In May 2015, this solution replaced a

tedious paper-based workflow that had been in operation in DanPilot for as long as the company had

existed (in fact, even before “DanPilot” was formed).

To enable this, a workflow has been set up that sends Orders to Pilots when they are assigned (or re-

assigned). A Pilot then completes the form available in an app on the device and form data is sent to a

“broker” server. This broker sends the completed Order to a back-end server in DanPilot, which stores the

received data for later invoicing.

Interface description The current integration is based on four different components:

1. Database triggers, that fires whenever a Job has been updated or a Job assignment has been

changed.

2. A Windows Service that polls for “pending updates” as recorded by the triggers.

3. A server known as “MPX Port Server” (part of the SafePilot product) which receives updates from

the Windows Service. This server also sends messages to each Pilot’s device/app. The Port Server

very much acts like a specialized message broker, for receiving and dispatching the specific

messages that SafePilot uses.

4. A web service for receiving “Billing Data” from MPX Port Server whenever a Pilot completes an

Order.

The following sequence diagram shows the interaction:

67

Figure 3. Interaction between the various components of the current ELS integration.

Use Cases There are multiple use cases to consider here, and they span across the sequence diagram on Figure 3.

Each use case is detailed further below.

New Pilot Assigned Whenever a new Pilot is assigned to a Job, ELS must be notified so the details can be sent to that Pilot’s ELS

device. If more than one Pilot has been assigned, all pilots receive the same Order assignment on their

device.

Pilot Assignment Changed When an assignment of pilot(s) is changed for a Job, that change must trigger an update to ELS, so that all

Pilot’s ELS state is eventually updated accordingly.

Job Updated

Whenever a Job is updated (e.g. a new start time is received/entered by dispatchers), an update to ELS is

triggered. Not all changes are strictly required to be published, although the current solution triggers a

publish on every change. E.g. a change to the “Notices” field on the Job does not have any impact for the

Pilot/ELS status, but such change triggers an update today anyway. Recall that our data volume and

throughput is relatively low, and we have not seen any performance issues yet due to this.

Order Completed

When an Order is completed by a Pilot, he uses the app on his device to report the Order completed. This

message is sent to the MPX Port Server, which in turn processes and forwards the message/event to a

DanPilot web API.

Provider Trelleborg in Aarhus (main office in Sweden) is the main provider of the SafePilot solution, and the

integration partner for the MPX Port Server and associated iPad app(s).

68

Data Volume and Throughput

Availability The data flows involved in this integration are not required to be near-real-time, and as such does not

require high availability. If Pilots get their assigned orders within max. 10 minutes after assignment and we

receive completed Orders within 30 minutes, things will work for us.

However, if/when an expanded integration is considered, things change a bit. E.g. if it is decided that Pilots

must be able to report updates to the expected end time for an Order, while they are executing the Order.

Here, we need to reconsider how often such updates must be processed (and obviously also ensure the

order in which such updates are processed). In this case, we may need to move to e.g. 99,7 uptime (a total

daily downtime of 2min 53secs).

Alternatives

SafePilot (the navigation part) is a unique product on the world market currently, to our knowledge. No

alternatives have been considered.

69

Integration: GatShip

Purpose To allow pilotage Orders to be sent to DanPilot electronically, which saves DanPilot the time of having to

create/enter order data manually, and remove sources of possible errors due to manual data entry.

Also, to allow DanPilot’s customers to keep their Orders up-to-date, by e.g. changing the expected time for

start of the pilotage job.

Interface description The API is an HTTP-based web service written in .NET. Complete online documentation is available here.

GatShip is a custom-built desktop System used by the most important customers of DanPilot currently,

when considering the Regional segment. The integration has been developed in close cooperation with

GatShip – the Norwegian company behind the System.

Use Cases Three use cases are currently supported by the API, and they map to the HTTP verbs POST, PUT and

DELETE.

New Order (POST) To place a new Order, a client uses a POST to the API. When the request is received, validation steps are

taken to ensure that the posted data is valid. E.g. the format of the IMO-number for the Ship is verified.

If all validation checks succeed, the Order is stored in the local database for the API, and a “success”

response is returned immediately to the calling client. The response includes a unique identifier for the

newly created Order. Otherwise, and error HTTP status is returned.

Update Order (PUT) To update a previously placed Order, the client sends a PUT request to the API, including the unique

identifier received in the POST response.

Again, validation of the update operation proceeds and a success/failure response is returned immediately.

Cancel Order (DELETE) Finally, to cancel a previously created Order, the client sends a DELETE request to the API. The Order is not

deleted, but marked as cancelled. This since our dispatchers could have started planning for the Order, and

may even have assigned Pilot(s) for the Order. So, re-planning may need to happen internally at DanPilot

when order cancellation occurs. Cancelled orders are marked with special highlighting in the Pilot Planning

System, so dispatchers can quickly see that an order has been cancelled.

Order Completed This event occurs when a DanPilot dispatcher chooses to complete the Order in the Pilot Planning System.

The event is published to an event bus, and a “synchronizer server” subscribes to this event. Whenever an

Order is completed, and that order originated from the customer directly (via the API), the Order is marked

as completed, in the local database use by the API. This allows the API to “bounce” update request for

Orders that have been completed.

Provider DanPilot has developed an API for receiving “external” Orders, and the GatShip System is the first System to

use this API.

https://order.danpilot.dk/swagger/ui/index#/Order

70

Data Volume and Throughput Current volume and throughput is low, since only one customer is actively using the API. (Approx. 5

pilotage request per week so far).

When fully rolled out to all possible customers, 5000-6000 pilotage requests are expected to be processed

by the API each year.

Availability This service must increasingly become highly available, as DanPilot will most likely add more customers to

the service during 2017. Currently, only one customer is “connected” and using the service. Monitoring is in

place, so DanPilot IT will catch any unexpected errors. However, this will most likely not be good enough

when multiple customers are using the API.

Alternatives

The description above fits the current setup and use of the Order API. There are several approaches to

connect GatShip to a new Pilot Planning System:

1. If the proposed Pilot Planning System has an existing API for receiving Orders, this should be

considered. Adapting GatShip to use a completely different API will require close coordination with

GatShip, but if the API’s are not widely different, this could be an approach.

2. Alternatively, the existing API can be adapted to integrate with the new Pilot Planning System. This

leaves the integration “intact”, from a GatShip perspective.

3. A third approach could be to rewrite/adapt the API of the new Pilot Planning System to fit the

existing API as closely as possible.

71

Integration: Navision

Purpose The Pilot Planning System (PPS) must include integration with our current ERP/financials solution – Navision

(2009 version). When Orders are completed in the PPS, they must be sent to Navision for invoicing.

Provider CGI is our current Navision provider, and responsible for maintaining the custom “Pilot module” in place in

our Navision setup. They are also responsible for the “Navision end” of the integration between the PPS

and Navision.

Interface description Today, we have an integration that is based on a batch run each night, that produces a flat file (CSV) which

is place in an “import folder” from where Navision can read the file. When the file is successfully imported

into Navision (a user-triggered action, directly from the Navision UI), the file is archived to a different

folder. If the file is present at the time the batch job runs, the file is not overwritten, but appended to, in

order to keep all orders in the file. Navision handles if an Order is found more than once in the file (it simply

overwrites the data in Navision with the most current version).

Finally, when the Navision user at some later point in time decides to produce an invoice for an Order, that

invoice draft is picked from the “pending” list, and the Invoice is produced, verified and sent (via email

directly from Navision).

Figure 4 gives an overview of this flow in the integration.

72

Current CSV File Contents The CSV file contains all order-related data needed to produce an invoice. Do note, that we plan and

dispatch pilots and boatmen in terms of Jobs – but invoices are produced and sent as entire Orders. (An

Order can be composed of several Jobs – refer to page 86 for details).

The following table describes all columns found in the current CSV file that is produced and sent to

Navision.

The column “Only ELS data” marks fields that are only populated with data coming directly from a Pilot, in

terms of data from the “Elektronisk Lodssedel” (ELS or soon, SafePilot) app. Some fields are deliberately left

Figure 4. How invoice drafts are written to the CSV file and then imported into Navision for final invoicing afterwards.

73

for the Pilot to fill – we cannot proceed with invoicing until the ELS billing data has been received from the

Pilot.

All other columns are filled as precisely as possible, based on data from either the dispatches System, or

ELS data (when present).

Also, note that an Order can very well be written to the CSV file (since the Order has been completed by

dispatchers), but before any billing data has been received from a Pilot. This causes a new Order-line to

appear in Navision – but with missing data in the ELS-based columns. In a subsequent batch run, that data

will most be likely be received from a Pilot and merged into the same Order line. If not, the Pilot can be

“poked” to request him to complete the Order.

Index Name Datatype Description Only ELS

data

1 OrderNo int The Order No of the Order

2 AssignedPilots string All names of the assigned Pilots

3 OrderId int Primary key of the Order

4 ImoNo int The IMO number of the Ship

5 CallSign string Call sign of the Ship (a short, text-based identifier)

6 Name string The ship name

7 Loa double Length overall

8 Woa double Width overall

9 ExternalId string The Route id to be used for invoicing (the unique identifier

for Routes, in Navision).

X

10 FromPilotMark string Name of the start PilotMark for the entire Order (there

may be more than one Job involved)

11 ToPilotMark string Name of the end PilotMark for the entire Order (there may

be more than one Job involved)

12 CompletedAt string The completion date/time of the Order

13 Draft double Draft of the ship

14 PilotOrderDateTime string NOT USED

15 PilotArrivedDateTime string The completion time, as reported by the Pilot (the last pilot

on the ship, in case more than one Pilot is assigned).

16 CustomerNo string NOT USED

17 Vat bool Field indicating whether Danish VAT is to be applied (comes

directly from the Pilot ELS).

X

18 ImoRecommendation bool NOT USED

19 PdfLocation string A string containing a link to PDF version of the ELS, as

received from the Pilot.

X

20 PilotingMandatory string Field indicating whether the ship is required to take a Pilot

onboard, for the specific passage. Comes directly from the

X

74

Index Name Datatype Description Only ELS

data

Pilot’s ELS.

21 RouteNo string The Route id to be used for invoicing. Only set when the

ELS has been received from a Pilot.

X

22 GRT int Gross tonnage of the ship.

23 TugFixedPrice bool [??? - TODO]. X

24 InvoiceDetails string Details of the customer/debtor for the Order, as entered by

dispatcher’s.

25 RouteComment string All via-info for the Route (or all involved Routes, in case of

multiple-Job Orders).

26 Notes string Any notes from the dispatchers (Job notes).

27 PilotNotes string All notes from all Pilots assigned (concatenated into one

string)

X

28 OwnerDetails string ??? TODO

29 LastPortOfCall string ??? TODO

30 BoundFor string ??? TODO

31 CustomerNoFromNav string NOT USED

32 JobType string NOT USED

33 JobInvoiceInfo string Concatenated strings of “invoice info” log statements from

the dispatcher’s System.

34 OrderType int 1 = Regional, 2 = Transit

35 RegionalType int 0 = Blank, 1 = Outbound, 2 = Inbound, 3 = Shifting

36 OrderStatus int 1 = Completed, 2 = Cancelled

37 PO string Purchase Order – external ref. no from our customer

(required on the invoice for some customers)

38 NonstopPurchaseStatus int 0 = N/A, 1 = Nonstop was purchased, 2 = Nonstop paid by

DanPilot

39 IsPremiumCustomer bool Whether the customer is marked as “premium”, which

gives certain benefits.

40 IsSystemGenerated bool NOT USED

Table 3. The complete CSV file format currently used for sending completed Orders to invoicing in Navision.

75

Data Volume and Throughput

Use Cases

Availability

Alternatives A service-oriented approach to integration with Navision was desired for, at the time of this integration.

However, the 2009 version of Navision does not allow an easy way to handle a web-services oriented

approach and DanPilot was advised not go that route. Hence, the decision was made to base the

integration on a “flat-file” integration.

If a different solution is proposed, please note that the Navision “endpoint” (module) will most likely have

to be changed in order to continue with the same workflow. There is a tight coupling between the file

format described above and the Navision module.

76

Integration: PDC [This integration is probably not relevant and therefore probably not consistent with the rest of the

requirement specification.]

Purpose The Pilot Planning System (PPS) must include integration with our current roster planning System – PDC.

Vagtplan (or simply “PDC”). The System is used for:

Planning and releasing roster plans for Pilots. Pilots can input their “wishes” for future plans, and a

planning employee is responsible for producing satisfactory plans. These are typically published for

a three-month period.

Planning and releasing roster plans for Boatmen. As for the Pilots. In addition, Boatmen use PDC

(online) for registering time spent. In comparison, the dispatchers are responsible for registering

the actual time spent for Pilots.

Provider PDC (Prolog Development Center in Denmark) is the developer and provider for this System. The System

includes a web API, which is what we primarily use for reading data from PDC, as described below.

Currently, data is never written back to PDC from other Systems (but that is one future use case as well).

Interface description The System is not publicly available and is installed locally on DanPilot servers.

We currently use the web service known as “AvailabilityService”. The API can be accessed on DanPilot’s

network and produces the following page upon request:

Figure 5. The operations page, as returned from the PDC Availability.asmx web service.

The GetAvailabilitiesSimple operation is the most important one. Sending this request gives an XML

response containing complete “timelines” for a specific collection of Employees. Currently there is no way

to request this for a single employee – requests are made for groups of employees (called Units in PDC).

The operations GetUnits and GetPersons can be used for collection info on groups and group members.

For a more complete description of this API, please refer to this document, written by PDC.

http://broen.int.frv.dk/projekter/vps-sysdok/Documents/Rådighedssnitflade%20-%20PDC%20Vagtplan.pdf

77

Data Volume and Throughput Data volume and throughput is low. The total number of planned activities for a single Pilot is approx. 30

for each three-month period. This gives 7.200 records to import, if we assume 285 Pilots and Boatmen in

total.

Use Cases There are three distinct use cases for this integration: Batch run, ad-hoc runs and data warehousing runs.

Batch Run At present, we decided to import all planned activities as a single batch every night. The batch job – a .NET

console app – calls the various operations of the API to read all current data from the API. It then stores the

results in temporary tables, and once all data has been collected, merges these into the “live”, production

data, on a row-by-row basis.

Ad-hoc Runs for Publishing Urgent Changes Relying on the single batch run every night is not enough. Pilots and Boatmen occasionally report in as sick,

and we need some way of pushing this information to the Pilot Planning System. The current solution for

this includes an in-house developed desktop app, that can “push” changes for a given employee directly to

the Pilot Planning System database. In a new System, it is important to include such feature as well – how

to publish ad-hoc changes to plans so the Pilot Planning System always has up-to-date information.

Data Warehousing Purposes Finally, we also use the information regarding roster/duty plans for Pilots and Boatmen in our current data

warehouse setup. Currently, we import PDC data into our data warehouse using the same method as in the

batch run as described above.

Availability

High availability is not critical here. Data is published for a rather long period of time ahead, so should a

single of the batch runs fail, most likely, the run will succeed next time. (And retries could also be

configured, if need be).

For the ad-hoc changes it is also the case that if one “run” fails, we can wait for the service to become

available and then simply try again.

Alternatives If the proposed Pilot Planning System includes a roster/duty planning System, that is capable of

recording/planning duty schemes for Pilots and Boatmen, this could be an alternative.

78

Integration: Integration/ETL process for Data Warehouse and BI

Purpose DanPilot has a data warehouse and BI solution setup, where the BI reports and interfaces are considered as

a “one-stop shop” for data. All the most important Systems are in one way or another used as sources for

the data warehouse. This includes the current Pilot Planning System, and it is expected that a new planning

System must also be an important source of data for many BI purposes.

Provider DanPilot has a full-time Data Manager responsible for all data and reporting tools used in the BI stack

(currently Microsoft-based - SSIS, SSAS and SSRS).

The company Kapacity has assisted DanPilot with setting up the entire ETL-process and BI model.

Interface description Currently, data is read mostly using SSIS (SQL Server Integration Services) packages, directly from the

various data sources.

Data Volume and Throughput [Not available yet]

Use Cases N/A

Availability The current BI solution has been set up on a dedicated server. This is not configured to be highly available,

and we can live with

Alternatives

No alternatives have been considered for the data warehouse and BI model.

Power BI as a new data reporting tool has been considered, and was found to be attractive and a low-cost

solution.

Dynamic Tables

Activity

DomainEventLog,Job JobEmployee

Ship

The rest are “master data” and changes occur not that often, and mostly to Employee, EmployeeCertificate

and EmployCertificateLevel tables.

Log, RouteKeySegment, RouteSegment, and RouteSubSegment no longer used.

80

Integration: Master Data Manager (MADAM)

Purpose

DanPilot has developed an in-house website for maintaining the various data classified as “master data”.

The websites go under the name MADAM (short for “Master Data Manager”).

Master data includes e.g. the geographical model (Routes, PilotMarks, Areas etc.) and Certificates (for

Pilots). The tool allows non-developers to modify and keep the master data up-to-date.

Provider DanPilot (in-house developed tool).

Interface description The website exposes no API or endpoints. It is directly connected to the PilotBoard database, so all changes

are immediately visible in PilotBoard (unless that data is cached, in which case a restart of PilotBoard may

be required.

Data Volume and Throughput N/A

Use Cases

The website is essentially a “forms over data” application and allows insert and update operations to the

data it exposes. There is typically no delete operation for each data type, since we most often invalidate

data rather that delete it (typically by setting e.g. a “ValidTo” DateTime value).

Currently, the following data can be modified using MADAM:

Employees (basic contact information for Pilots).

Routes.

PilotMarks.

Certificates (for Pilots).

Places of Employment (Locations).

VIP Customers.

Travel- and transit time tables.

Availability Not required to be highly available.

Alternatives N/A

81

3. Non-functional requirements - user experience:

This section explains the primarily non-functional requirements for the Actors when they use the System.

The requirements shal ensure an user friendly experience when using the System based on roles and the

frequency that the Actors will use the System.

This section is devided in requirements related to 6 areas:

1. General requirements

2. User interfaces should be adapted according to the Actor (and thereby role)

3. User involvement

4. Design guides

5. Messages and help

6. Technical requiremets regarding the UI

General requirements

Requirement#3.1.1: The Systems planning and dispatching part should be effective


Description: The Systems planning and dispatching part should be effective, and should enable the

experienced Actor to carry the frequently processes and tack in an effective manner

The Actor should be able to dipatch an order or a number of orders within XX minutes, or

for the Actor to Roster plan within YY minutes

Comment: The Actor is the type Dipatcher and Roster Planner

Requirement#3.1.2: Ease of use


Description: The System should be regarded as easy to use by the Actor, and the Actor should be able to

perform simple functions without reading a manual or online help.

Comment: The Actor is alle the types of roles

Requirement#3.1.3: Examples of User Interfaces (UI)


Description: The Supplier should describe a number of UI’s based on use case number XX to YY. These

82

should show how Actors are using the UI’s.

The suppliers should via 5-10 UI’s describe the process of flow use case number XX to YY

Comment: The Actor is the type Dipatcher,Roster Planner, Pilots and Boatsmen

Requirement#3.1.4: User Interfaces (UI) language


Description: The System should support Danish in all User Interfaces (UI) language in the System

including 2 way communication

Comment:

User interfaces should be adapted according to the Actor (and thereby role)

Requirement#3.1.5: Intuitively 2 way communication module


Description: The Actor should be able to use the Systems 2 way communication part intuitively, without

reading a manual or online help.

Comment: The Actor is the type Pilot or Boatman

Requirement#3.1.6: Responsive design


Description: The UI’s used in 2 ways communication should be either APP or webbased. If webbased it

should be scalable depending on device therefore based on responsive design

Comment: The Actor is the type Pilot or Boatman

Requirement#3.1.7: Devices used for 2 way communication

Category: Minimum Requirement Type: Non-functional

Description: The System for 2 ways communication should be able to function installed on/running on

the Actors Apple smart phone/tablet devices using iOS version XX or later

Comment: The Actor is the type Pilot or Boatman and all other personel

83

Requirement#3.1.8: Devices used for 2 way communication



the Actors Android or Microsoft smart phone/tablet devices using iOS version XX or later


Requirement#3.1.9: Browsers used for 2 way communication



the Actors browsers using Firefox, GoogleCrome, MS Explorer version XX or later


User involvement

Requirement#3.1.10: User involvement


Description: The Supplier is required to involve the Customer in the adaptation of UI’s and user

friendnliness. As part of the first phase after the contract is signed a detailed plan should

be created for this involvement. The involvement should be the Actors described below as

a minimum.

Comment: The Actor is the type Management, Dipatcher,Roster Planner, Pilots and Boatsmen

Design guidelines

Requirement#3.1.11: Danpilot design guidelines


Description: The Supplier is required to use official designguidelines provided by the the Customer

Comment: See appendix XX for Danpilot design guide

84

Messages and help This section explains the Actors possibility to get help and explanetative error messages that will enable the

Actor to resolve problems faster.

Requirement#3.1.12: Online help


Description: The System shall contain online help function, that describes navigation, functions and UI’s

that are covered in the use cases.

Comment: See use cases mentioned in section XX.

Requirement#3.1.13: Validation


Description: The System shall enable processes where errors are self-explanatory and do not require a

click on a “OK” box before continuing unless there is a specific purpose of this.

Comment:

Requirement#3.1.14: Error text


Description: The System shall enable processes where errors are shown in a way that the are easy to

understand and where the error is a text explaining the error and how the user should

correct it.

Comment:

Requirement#3.1.15: Feedback on responsetime


Description: The System shall show it’s working on an answer wthin responsetime <5 seconds.

The System shall show it’s working on an answer wthin responsetime >5 seconds and shall

show a statusindicatior on remaining time for response.

Comment:

85

Technical requiremets regarding the UI

Requirement#3.1.16: Copy and insert


Description: The System shall be able to handle copy and insert in all fields (both only readable = copy,

and readable/writable =Copy/insert)

Comment: Both only readable fields = copy, and readable/writable fields=Copy/insert

Requirement#3.1.17: Successive load of content


Description: The System shall be able to successive load of content in order to ensure that information

is presented as it is loaded

Comment: E.g. an Actor is presented for a Dashboard succescively (and not until all content and

widgets are loaded)

Requirement#3.1.18: Personalization of UI.


Description: The Supplier should describe what and how can be personalized and include screen shots

showing the results of different personalized set-ups.

Comment:

86

4. Information Model

Introduction This chapter provides an overview of the domain, the terms used and how they are related. The goal is two-

fold:

1. To convey an understanding of the domain, and

2. to define the scope of the new Maritime Planning and Dispatch System, in terms of the information

expected to be handled in the System.

The chapter is split into three sections, where each section first describes a part of the domain and then

concludes with specific requirements for a new Pilot Planning System. The sections are:

Order-related data.

Certificate-related data.

Geographical data model.

Order-related Data Figure 6 below shows the most important order-related data, and how they are logically related. Please

note the following:

An Order consists of one or more Jobs. In terms of the domain context: A pilotage Order can be

split across several “legs”, each one is what we refer to as a Job. Each Job is then typically a

continuous stretch from location (PilotMark) A to B to C to D etc.

The main task of the Pilot Dispatcher is to ensure that all Jobs are assigned one or more pilots and

one or more boatmen plus pilot boats. The pilots are the most “important” ones here, since

typically pilot boats and boatmen are always available, as things are today. Do note, that this may

change in the future though, when a “Hub” structure is in place.

A Route consists of exactly two PilotMarks. A PilotMark is either a port or a designated point in

Danish waters, where pilots can embark or disembark a ship for pilotage.

Activities are what dispatchers plan when assigning Jobs to Pilots or Boatmen. It is effectively the

time registration done for Pilots, from the central dispatchers. Therefore, we can also refer to these

activities as ActualActivities, as shown in the diagram. A PlannedActivity is a period where the Pilot

or Boatman has a designated plan, basically “on duty” or “off duty”, coming from the roster

planning System today (PDC). These plans are currently produced typically 3 months ahead.

A single Activity is always linked to exactly one Employee (we use the term “Resource” below, to

refer to either a Pilot or Boatman). Activities are subject to rest-time validation as well. Pilots have

a unique set of rest-time regulations that must be validated whenever a Job is assigned (new

activities are created) or something changes to an existing plan (e.g. a Job is moved in time – all

Activities must be adjusted accordingly and re-validated).

PlaceOfEmployment is currently used as the name of a physical location on ground - a point with

postal address - in general. Pilots have a designated “home” place of employment. As can be seen

from Figure 6 below, PilotMarks are also linked to such locations, via links to the same

PlaceOfEmployment entity. An Activity can also have an “end” PlaceOfEmployment set. This is

currently used for tracking the location of an Employee.

87

Figure 6. Overview of the primary domain concepts; the Order-related entities and relationships.

Certificate-related Data

A Pilot Planning System for use in Denmark must also handle pilot certificates. The current regulations

governing pilot certificates are the responsibility of the Danish Maritime Authority (DMA), and can be found

here:

Pilot Certificate Regulations (Retsinformation)

(only available in Danish).

Figure 7 below gives an overview of how these certificates can be modelled in a Maritime Planning and

Dispatch System. The following describes the various entities involved in the proposed model.

A Certificate is coupled either to an Area (a named part of Danish waters) or to a port.

(AreaCertificate and PilotMarkCertificate, respectively. A port is also a PilotMark).

The Certificate model handles the fact that the current certificate System maintained by the DMA is

level-based. A pilot typically starts out at level 1, after his time as “aspirant” has been completed.

Periodically, a status is done for each pilot’s certificates, and the pilot is possibly moved to the next

level.

A CertificateLevel defines the “size” of ships, which the pilot is allowed to handle. Parameters are

typically: Length, Beam, Draught and Gross Tonnage. Each level then defines the max. value for

each parameter that a pilot holding that level is allowed to board.

Each Job must be matched with the minimum certificate-requirements. I.e. depending on the size

of the Ship and the Route for which pilotage is ordered, a set of minimum certificate levels can be

collected (JobCertificateLevel). To be a valid “match”, any Pilot assigned to a Job must have at least

the required level per Certificate required by the Job. This is critical in order not to plan and

dispatch a Pilot to a Ship which he is not allowed to board.

Order

Job

Route Ship

PilotMark PlaceOfEmployment

Resource

Employee

PilotBoat VehiclePilot Boatman

Activity

ActualActivity PlannedActivity

2

Transport

Legend for the Crow's foot notation used.

https://www.retsinformation.dk/Forms/R0710.aspx?id=144126

88

Figure 7. A conceptual model for capturing requirements for Pilot Certificates. Data regarding the certificates tend to more static. Data regarding the requirements for a given Job (JobCertificateLevel) is more dynamic. These could vary for each passage of a given Ship, typically depending on the Route and draught.

Reporting Completed Jobs to the DMA Each Pilot is currently required to report his completed pilotage jobs to the DMA periodically. This so the

DMA can keep track of certificate renewals/withdrawals. One possible future integration is to do this

reporting automatically. For details on this, see XX

Geographical Data Model The Pilot Planning System must include a geographical data model, to support the following:

Display/tracking of whereabouts for Pilots and Boatmen and (possibly also) Pilot Boats. Not

necessarily as a plot on a geographical map, since DanPilot already has a System specifically for this

(GAD). It could be as a simple on-screen status “Current location” for each Employee. Using this,

dispatchers can easily determine the last known location for each Employee.

The ability to produce “Job plans” for Pilots and Boatmen, that take the current/last known location

of an Employee into account. E.g. in order to suggest/produce a travel plan (on ground) for each

employee.

The ability to validate rest time rules. E.g. for the Pilots we currently need to account for how long

time (hours and minutes) a Pilot has been “away” from his home Place of Employment (the so-

called 96-hours rule (See Rules for Rest). This is one out of eight rules that apply today for Pilots. To

validate this rule, the System needs to track Pilots’ locations with at least a precision as described

above.

Figure 8 is one possible model for tracking the location of the needed resources and activities. The

following describes the diagram further:

A Job always has a single Route associated. The Route always has exactly two PilotMarks (a start and end,

with a known distance etc.). Each PilotMark is associated with one or more PlaceOfEmployments (~ a

location on ground). Each PilotMark is also associated with one or more Boatstations, since occasionally a

PilotMark can be services from multiple Boatstations. A Boatstation always has a single

PlaceOfEmployment (a Boatstation is a physical location, on ground). A Hub has one or more Boatstations it

Job

Employee

JobCertificate-Level CertificateLevel

Certificate

Certificate-Category

Certificate-Type

Employee-Certificate

EmployeeCertificate-Level

PilotMark-Certificate

Area-Certificate


89

services. A Boatman is most often allocated to 1 boatstation, but there are some which are allocated to

more than one.

A Resource (Pilot, Boatman, Pilot boat etc.) typically has a set of Activities, representing Jobs that are

assigned to that Resource, the rest periods in-between Jobs (for Pilots and Boatmen) plus travel time over

ground. An Activity can be associated with a single PlaceOfEmployment. As a minimum requirement, the

Activities that move a Resource from one location to another, must all have a designated end-location.

Figure 8. Geographical model for capturing the "location" needs in the System.

Job Route RouteArea

PlaceOfEmployment

Boatstation

Area

PilotMarkPilotMark-

Group

2

Activity

Boatman(Resource)

Hub


90

Requirement#4.1.1: Order-related entities and relationships


Description: The System should support the use of the information model of order-related entities

and relationships in figure 6

Comment:

Requirement#4.1.2: Certificates -related entities and relationships


Description: The System should support the use of the information model of certificates -related

entities and relationships in figure 7

Comment:

Requirement#4.1.3: Tracking the location -related entities and relationships


Description: The System should support the use of the information model of tracking the location-

related entities and relationships in figure 8

Comment:

91

5. Business rules

Current Union Agreements (rules) The enclosed union agreements are only available in Danish. [If the Supplier do not understand the wording

of these agreements it is the Suppliers own responsibility to ensure translation of these]

Pilots: Please refer to appendix XX

Boatmen 1: Please refer to appendix XX

Boatmen 2: Please refer to appendix XX

Requirement#5.1.1: Union Agreements – Pilots


Description: The System should be able to support the union agreement for pilots

Comment:

Requirement#4.1.2: Union Agreements – Boatmen 1


Description: The System should be able to support the union agreement for Boatmen 1

Comment:

Requirement#4.1.3: Union Agreements – Boatmen 2


Description: The System should be able to support the union agreement for Boatmen 2

Comment:

92

State agreements Please refer to appendix XX

Requirement#4.1.4: Union Agreements – State agreements


Description: The System should be able to support the union agreement for the State

Comment:

93

Current Union Agreements (rules) and their interpretation

Pilots This section based on a workshop regarding the business issues that Danpilot has regarding current Union

Agreements primarily based on the agreement with Pilots. The Supplier should regard this a interpretation

of the current Union Agreement with Pilots.

General overview: Rostering and dispatching of pilots

1. Today’s processes

2. Todays challenges

3. Rostering

4. Dispatching

As-is processes for rostering and dispatching

1. Forecast of demand:

For present not any long-term forecast, i.e. 3-12 months forecast.

Experimenting with “watch dog” for early detecting of possible incoming orders 72 hours in

advance.

Experimenting with 12-24 hours forecast of ETA based on real time AIS-data for known orders

2. Rostering:

Rosters are made 3 months in advance for pilots

Rosters are made 3-12 month in advance for boatmen

3. Dispatching:

Real time dispatching of pilots and boatmen handles incoming orders with

o 4-hour notice for pilotage from port

o 24-hour notice for pilotage to port

o 18-hour notice for transit pilotage

As-is tools

1. Forecast of demand: Real time monitoring of AIS-data for vessel traffic used for calculation of ETA (estimated Time of

arrival) for known orders.

2. Rostering: - IT-System with control of rules and calculation of simple statistics of different kinds supporting the

manual rostering.

3. Dispatching: - IT-System with decision support based on different kinds of filtering and sorting of data supporting

the manual dispatching.

Main challenges for the time being 1. Lack of reliable forecast of demand for pilotage based on AIS-data

2. We do not know how well rosters fit to the demand and how well we exploit the working hour

rules. The main issue is ”how can we reduce the generation of overtime by improving our rostering

(and forecast?) procedures”?

94

3. We do not know how well the processes for dispatching work and how the many different working

rules interact with each other.

4. We do not know if we are the right number of pilots in order to minimize the operating costs at

DanPilot.

Overtime is created in the process

3 steps to reduce overtime

Some important rules for rostering

- 153 duties per pilot per year

- 12 standby duties pr pilot pr year

- At maximum 20 duties per month

- Rosters are made for 3 months and announced at the latest the 10th in the month before the first

duty

- A duty last for exact 24 hours, e.g. from 12:00 to 12:00

- At least 3 duties in a row

- At maximum 9 duties in a row

- A sequence of duties may not start or end in a weekend

95

- At maximum 23 ”duty-weekends” per year

Some important rules for dispatching - A pilot have to have in average 11 hours of rest per day, i.e. duty of 24 hours, interpreted as

o At least 8 hours of rest during the first 24 hours on duty



- A period of rest is at least 8 hours, but can be divided into 2 periods of which one must be at least 6

hours

- After 3 nights in a row with pilotage the pilot must rest at least in the full interval from 22:00 to

06:00

- After 96 hours of pilotage the pilot must rest at least 8 hours at home or at his own pilot station

- Travel time must be considered as working hours

96

Minutes of workshop regarding interpretation of working rules for dispatching pilots

Rules in PilotBoard The figure to the right shows the rules implemented in

PilotBoard.

All rules are derived from the current agreements.

Since there are found examples indicating that some rules

may have been interpreted more restrictively than the

wording in the agreements, there is a need to discuss what

we believe is the correct interpretation for dispatching in

PilotBoard.

In addition, there is a rule of "lost rest", implemented on

request of a former pilot manager, but there seems to be

no justification of this within the agreements.

The purpose of the presented cases

The following slides are based on the most important rules regarding the rest periods as agreed in working

rules between DanPilot and the trade union.

For each rule, several cases are set up (or questions if you like). Each of these cases require a discussion to

decide if the case is legitimate or not per the text of the current agreements.

It should be emphasized that it is legality, not the appropriateness of the individual cases we desire to

discussed.

I am aware that the given cases are extreme and "on the edge". But it is precisely through discussions of

extremes, where things are put at stake, we can get the full understanding of how the frames in the

agreement legally can be exploit in daily dispatching.

Next step? Whatever we might find out during the discussion of individual cases, it will not lead to any change “right

now". Any change in relation to today's practice, where applicable, should be assessed

- assessed in relation to the law

- assessed in management terms in relation to the consequences

- discussed with the trade union

But having said that, we of course also must deal with the conclusions of the debate, should it turn out that

today's policies are more restrictive than the applicable agreements.

Rest periods over several days Wording of the agreement:

§3. The provision in section 1, paragraph a. may be waived, provided that the individual pilot within any

three-day period in total has 33 hours rest distributed as follows:

97

- Duty day 1 the pilot must have had a minimum of 8 hours of total rest.



Section 2. For duties that exceeds three days, the provision of 33 hours of total rest in the past 72 hours

must be fulfilled at any time after the third duty day.

Section 3. Within each duty day the pilot must have at least one rest period of continuous 6 hours. The

hours of rest within a duty day may at maximum be divided into 2 rest periods, and the pilot must not work

more than 13 hours between 2 rest periods.

Comments to the discussions on rest periods over several days BP do not allow that pilots are more than 6 hours on the bridge without a rest.

- It may conflict with our desire to optimize the work and rest periods for pilots.

- Should it cost extra (possibly free via special discount for large customers?)

The rule of a maximum of two periods of rest per day is problematic for ships in transit,. In those cases, we

have to distinguished between started and completed the rest periods. There setup of rules in PilotBoard

regarding this was done in dialogue with former pilot manager Poul Christensen.

- In Sound, where "often" occurs three rest periods, there has been a practice in which the third rest

period is called "various work". It is also in PilotBoard decided not to "make pilots red" in case of

Current practice generally follows the setup of the

PilotBoard

98

more than 2 rest periods as the dispatchers manually control it. More than 2 rest periods also

appear in Esbjerg, where a pilotage typically takes 1½-2 hours. To a lesser extent, we have similar

challenges at Kalundborg / Stigsnæs.

Shall work be divided equally between the pilots on a non-stop transit pilotage? Or is it OK to optimize it, if

it gives an unequal distribution of the pilotage?

Some (few?) pilots are convinced that there is a rule saying that after the third duty day they shall be given

at least 11 hours of rest per day. However, the agreement does not contain such a clause.

99

Rest periods gives over several periods

Wording of the agreement: §3. The provision in section 1, paragraph a. may be

waived, provided that the individual pilot within any

three day period in total has 33 hours rest distributed

as follows:

- Duty day 1 the pilot must have had a minimum

of 8 hours of total rest.





Section 2. For duties that exceeds three days, the

provision of 33 hours of total rest in the past 72 hours

must be fulfilled at any time after the third duty day.

Section3. Within each duty day the pilot must have at least one rest period of continuous 6 hours. The

hours of rest within a duty day may at maximum be divided into 2 rest periods, and the pilot must not work

more than 13 hours between 2 rest periods.

“Lost rest”

Wording of the agreement Wording of the agreement:

§3. Section 3. Within each duty day the pilot must

have at least one rest period of continuous 6

hours. The hours of rest within a duty day may at

maximum be divided into 2 rest periods, and the

pilot must not work more than 13 hours between

2 rest periods.

*) Former pilot manager Poul Christensen

introduced back in 2009/10 a practice saying that

a rest period should be at least 2 hours.

Comments to the discussions on the setup of rest periods in PilotBoard The whole setup of rest periods in Pilot Board should be regarded as a "total package", as there are several

"grey areas" in the agreements, which are difficult to handle in practice, for instance

- How do you determine if a day has more than two rest periods when you constantly should look at

rolling 72 hours?

- Is it practice possible to plan the transit pilotages if you never must have more than two rest

periods per 24 hours?

100

- What is the minimum allowable period of rest in practice?

- In Sound, you need to plan with more than two rest periods per day

When we in the past implemented many of the above things a "total package" over time occurred in

dialogue with among others the former pilot manager Poul Christensen. So, if or when we make changes to

the “total package" we should carefully consider the pros and cons.

Rest period in connection with night piloting

Wording of the agreement §3. Section 4: After 3 consecutive days of duty where night

pilotage occurred, the subsequent night at minimum must

include a rest period in the full-time interval 2200-0600.

§5. Travel time in connection with night pilotage is

considered as work.

The instructions regarding night pilotage (page 7): Night

pilotage defined as piloting a minimum of 3 hours in the

period 22-06.

The instructions regarding rest time (page 9): After 3

consecutive duty days where night pilotage occurred

(which must be understood as three consecutive nights,

each with piloting of at least 3 hours in the period between

22 and 06), the pilot must have a rest period covering the

full time interval from 2200 to 0600 the following night

101

Rest periods after more than 4 days of piloting

Wording of the agreement §3.Section 5. Since the quality of rest facilities, as well

as bed conditions, toilets etc. are of widely varying

standard, and that on ships are highly variable noise

and heat / cold, the pilots can not be imposed to be

piloting, for more than four consecutive day, without

having had the opportunity to hold a rest at home /

place of employment. If the pilot himself find he is

ready for further piloting this is the pilot's own

decision.

The instructions regarding rest time (page 9): Since

the quality of rest facilities, as well as bed conditions,

toilets etc. are of widely varying standard, and that on

ships are highly variable noise and heat / cold, the

pilots can not be imposed to be piloting, for more

than four consecutive day, without having had the

opportunity to hold a rest at home*. If the pilot

himself find he is ready for further piloting this is the

pilot's own decision

Clarification of the rest Agreement "4 days of rule":

The above provision must be understood such that the pilot only after 4 days of pilotage have the

possibility to rest at home / place of employment.

The length of the rest period at home / place of employment after 4 days of piloting shall be at minimum of

8 hours.

Within the four days, a rest period of at least 6 hours in the home / place of employment will interrupt "4

days of rule", so that the "counter will be reset.“

My own comment:

*) Note that this is not stated as home / place of employment, in opposite to the wording of §3 paragraph 5

102

Comments to the discussion on rest after 4 days of piloting 1. A significant part of the discussion was about whether one can distinguish between working and

pilotage. The expectation was that Danish Pilots (the trade union) probably thinks that we cannot

distinguish between working and piloting, while DanPilot rightly can argue that there must be a

reason there in the agreements have been used two different words.

2. If the pilot must be reset with 6 hours of rest at place of employment / home, shall then all 6 hours

be kept within the 4-day period of 96 hours - or shall the 6-hour rest period just begin before the 96

hours have passed?

3. If the pilot “is reset" at the home, travel time also counted as working time, so it may be a trade-off

if you rest in your home or place of employment.

4. Some (few) pilots “claim" that they must rest at the home.

5. If at some point of time we may consider to change the rule so that pilots can be "reset" at a

“foreign” place of employment, one must consider how the pilots then can manage to wash

clothes, etc. since a pack with sleeping bag, clothing for 9 days including winter clothing seems

unrealistic for transit pilots.

Anything else?

Finally, there was a long-lasting discussion of various issues in relation to travelling in cases where the pilot

does not check in at the place of employment when he starts a period of duty days. There seems to be

numerous advantages and disadvantages of the current practice, including some glaring examples of how

bad things sometimes went compared to intensions in the agreements regarding work and rest periods.

Perhaps this issue could be suitable for another workshop on how to setup the rules in the PilotBoard.

103

Possible changes to working rules for pilots 1. Introduction

Even though agreements between DanPilot and Danske Lodser15 seems to be permanent or static it is

important to bear in mind that there continuously will be a need for easy access to make changes to the

rules. Changes to rules can be caused by for example

New interpretations of the wording of the rules

Updates to best practice for dispatching

New agreements

The purpose with the following sections are to give an impression of possible changes to the rules in the

future. The following examples may not be considered as a complete list as it only is meant as illustrative

examples of the wanted flexibility that shall enable the super users to define, cancel, and maintain working

rules on their own.

15

The trade union for Danish pilots

104

2. Possible changes for rostering of pilots

Current rule (or interpretation) Possible new rule (or interpretation)

A roster for 3 month shall contain a certain number

of duty days (3x12.75 = 38.25) and standby days

(3x1 = 3)

The number of duty days and standby day can vary

depending of the time/month of the year. Per

calendar year there shall be at maximum 153 duty

days and 12 standby days.

Shift changes are not allowed in weekends, i.e. at

Saturdays or Sundays.

Shift changes are allowed in weekends, or at least

in a limited number of weekends per year.

Duty days are always 24 hours. Duty days can be less than 24 hours, for example

12 hours.

A day in a roster consist of only one type of duty,

for example on duty, standby, nonworking or

vacation.

Days in a roster can consist of more than one type

of duty, for example 12 hours of duty followed by

12 hours of nonworking day.

Days in a published roster cannot be changed. Standby days in a published roster cannot be

changed, i.e. cancelled, or assigned, with 72 hours’

notice.

Currently standby duties are placed at the

beginning or at the end of a shift.

Standby duties may also be placed inside of a shift.

105

3. Possible changes for dispatching of pilots


The call in order for pilots on overtime is

1. pilots on standby 2. pilots on nonworking day 3. pilots on day off 4. pilots on vacation

In case of none pilots on standby duty and nobody

accept to be called in on overtime DanPilot can

force pilots on nonworking days to be called in on

overtime.

The call in order for overtime is

1. pilots on standby 2. pilots on nonworking day 3. pilots on day off 4. pilots on vacation

In case of none pilots on standby duty and nobody

on nonworking days accept to be called in on

overtime DanPilot can force pilots on nonworking

days to be called in on overtime without first

calling pilots on day off or vacation.

The starting time of a shift is fixed and given by the

roster.

The starting time of a shift can be staggered with

e.g. +/- 2 hours in relation to the time given by the

roster without triggering overtime payment.

After 96 hours of pilotage without resting at place

of employment or at home the pilot shall be

offered the opportunity to rest at place of

employment or at home.

After 96 hours of pilotage without resting at a

DanPilot station or hotel the pilot shall be offered

the opportunity to rest at a DanPilot station or at

hotel.

Every third month rosters for the following three

months are published.

Every month the rosters for the month 2 month

ahead are published.

Days in a published roster cannot be changed. Duty days can be cancelled with short notice and

be given as an extraordinary duty day in the first

coming roster in addition to ordinary duty days.

Currently some rules are implemented more

restrictive than the wording of the agreements. An

example of this is “lost rest”, which means that

rest periods less than 2 hours are considered as

work and not rest.

For example, we would like to consider the “2

hours” as a soft rule (or parameter) that can be

relaxed or set to something lesser, e.g. 1:50

depending.

Requirement#4.1.5: Union Agreements – Possible changes for rostering of pilots


Description: The System should be able to support the the union agreement’s possible changes for

rostering of pilots

Comment:

106

4. Possible changes overtime remuneration for pilots


Pilots are remunerated for all overtime hours

including resting periods

Pilot are remunerated for all overtime hours

excluding resting periods or alternatively at

maximum for 16 hours per day.

As the days in rosters are fixed so are the

remuneration in case of overtime as the hourly

salary is determined by the type of the day.

Nonworking days are not fixed in the rosters but

considered as “floating nonworking days”. This

means that the 51 yearly nonworking days are

assigned when the pilot is called in for overtime.

Thereby DanPilot do not have to pay for

replacement days as it is the case for overtime

carried out on a day off or a vacation day.

Requirement#4.1.6: Union Agreements – Possible changes for dispatching of pilots



dispatching of pilots

Comment:

Requirement#4.1.7: Union Agreements – Possible changes overtime remuneration for pilots



overtime remuneration for pilots

Comment:

107

Standard Operating Procedures

1. Introduction

DanPilot have several Standard Operating Procedures (SOP) for e.g.

Rostering of pilots

Dispatching of pilots

Customer service instructions

Safety instruction for pilotage

Safety instructions handling of pilot boats

Maintenance instructions for pilot boats

Some of those SOPs will be relevant for dispatching of pilots and boat men other will be irrelevant for

dispatching.

The following sections provides some examples relevant for dispatching and customer service. The purpose

of this is not to give a complete list of relevant SOPs or detailed descriptions of the SOPs but simply to

illustrate the interaction between SOPs and especially dispatching.

2. SOPs for dispatching

Some dispatching SOPs can be considered as interpretation of agreed working rules, some as “best

practice” and others rather as rules of thumb.

2.1 Regional pilotage to or from Skagen or Gedser

Regional pilotages to/from Skagen: Pilotages to/from Kalundborg, Fredericia, Aabenraa of Stigsnæs should in principle be performed as

non-stop pilotages. Change of pilots at Grenaa is not allowed as the ship will derivate from Route T. If

there for operational reasons is a need to deviate from this, contact the head of Dispatching.

Regional pilotages to/from Gedser Pilotages to/from Kalundborg, Fredericia, Aabenraa of Stigsnæs should in principle be performed

with change of pilotages.

108

2.2 Northbound transit pilotages to Skagen

VIP customers: All VIP customers are, notwithstanding draft, offered non-stop pilotages.

All other customers: For all other customers pilotages will, notwithstanding draft, have change of pilot underway. Change

of pilots is not allowed at Grenaa for customers a draft of 11 meter or more. If there for operational

reasons is a need to deviate from this, contact the head of Dispatching.

2.3 Southbound transit pilotages to Gedser or Allinge

VIP customers: All VIP customers are, notwithstanding draft, offered non-stop pilotages.

All other customers: All other customers will, notwithstanding draft, have change of pilot underway. We will provide 2

pilots on the stretch from Skagen to Korsør. After Korsør pilots can be changed underway. Change of

pilots is not allowed at Grenaa except in exceptional circumstances. If there for operational reasons

is a need to deviate from this, contact the head of Dispatching.

2.4 Purchase of non-stop pilotage

Non VIP customers: For non VIP customers non-stop transit pilotages can be requested at a fixed price. If DanPilot not

can provide this service without calling pilots in at overtime, the dispatcher is allowed to refuse to

offer this service.

Requirement#4.1.8: SOPs for dispatching


Description: The System should support the above mentioned SOPs number 2.1 to 2.4 for dispatching

Comment: