Requirements Specification Appendix 3.1 Maritime Planning … 3.1 Danpilot- MPDS... · Non functional requirements ... • Boatmen: Like Pilots they will use the 2 way user interfaces

1

Requirements Specification

Appendix 3.1

Maritime Planning and Dispatch System (MPDS)

DanPilot

Version 2.2

2

Instruction for the Supplier

This is an Appendix to the K02 Appendix section 3. Therefore this Appendix is named Appendix 3.1.

The Supplier must read this Requirement Specification. Where required the Solution must be described in

“Appendix 3.1.A - DanPilot- MPDS - Solution Description - Template” and “Appendix 3.1.B overview of

requirements”

The Supplier must notice the specified Minimum Requirements (MR) that must be fully satisfied by the

System. There cannot be any reservations regarding the Minimum Requirements in the final offer.

The Supplier must note and refer to Tender Conditions – DanPilot regarding the evaluation criteria

regarding this Appendix.

3

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

0. DanPilot specific optimisation, planning, dispatching and execution requirements .................................... 5

Introduction ................................................................................................................................................... 5

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

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

Use Case Context Diagram ........................................................................................................................ 7

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

Further instructions to the Supplier .......................................................................................................... 8

Introduction to TO-BE processes for pilots ............................................................................................... 8

Examples of TO-BE-expansions to current processes for pilots .............................................................. 21

TO-BE processes for rostering and dispatching boatmen ....................................................................... 22

TO-BE processes for rostering dispatchers .............................................................................................. 29

0.3 Requirements for System supporting the complexities in dispatching ................................................. 32

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

0.5 Optimization of resources ..................................................................................................................... 39

0.6 Alternative use of logged data .............................................................................................................. 51

1. Other Requirements .................................................................................................................................... 53

1.1 Functional requirements orderprocess: ................................................................................................ 53

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

1.3 Functional requirements reporting: ...................................................................................................... 60

1.4 Functional requirements sales data: ..................................................................................................... 61

1.5 Functional requirements finance/ invoicing: ........................................................................................ 63

1.6 Functional requirements wage data: .................................................................................................... 66

General description of the wage-process................................................................................................ 66

Description of boatmen - pay .................................................................................................................. 68

Description of Pilots - pay ........................................................................................................................ 71

Description of boatmen - pay .................................................................................................................. 73

Registrations in the planning system ...................................................................................................... 74

1.7 The Suppliers requirements regarding test and operational environment for MPDS .......................... 77

2. Non functional requirements ...................................................................................................................... 79

2.1 Architecture ........................................................................................................................................... 79

2.2 Integration ............................................................................................................................................. 84

4

2.3 Security .................................................................................................................................................. 91

2.4 Data Management ................................................................................................................................. 95

2.5 Integrations ........................................................................................................................................... 99

3. Non-functional requirements – User Experience: ..................................................................................... 100

3.1 General requirements ......................................................................................................................... 100

3.2 User interfaces must be adapted according to the Actor (and thereby role) ..................................... 102

3.3 User involvement ................................................................................................................................ 103

3.4 Design guidelines ................................................................................................................................. 103

3.5 Messages and help .............................................................................................................................. 104

3.6 Technical requiremets regarding the UI .............................................................................................. 105

4. Information Model .................................................................................................................................... 106

4.1 Orders .................................................................................................................................................. 106

4.2 Certificates ........................................................................................................................................... 107

4.3 Locations .............................................................................................................................................. 109

5. Business rules ............................................................................................................................................ 111

Current Union Agreements (rules) ............................................................................................................ 111

Further instructions to Supplier ............................................................................................................ 111

Pilots: ..................................................................................................................................................... 111

Boatmen 1 and 2: .................................................................................................................................. 111

State agreements .................................................................................................................................. 111

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

Pilots ...................................................................................................................................................... 112

Minutes of workshop regarding interpretation of working rules for dispatching pilots ...................... 115

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

Introduction ........................................................................................................................................... 122

Possible changes for rostering of pilots ................................................................................................. 123

Possible changes for dispatching of pilots ............................................................................................. 124

Possible changes overtime remuneration for pilots ............................................................................. 125

Krak factor ................................................................................................................................................. 125

Standard Operating Procedures ................................................................................................................ 128

Rules of notice ........................................................................................................................................... 130

5

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 its 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) Process overview and process descriptions (TO-BE processes)

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 consistent overview of the

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

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 every day and will use a wide range of the functionality of the

System, however with focus on dispatch and execution.

• Dispatcher, super user: 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 every day and will use a wide

6

range of the functionality of the System. On top of the role as user, the super user 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 management role seeking

information on execution, KPI’s, reports etc. The dispatch manager 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

• Super user/Administrator: Will maintain e.g. optimization parameters along with correction of

master data etc.

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

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

completed orders, activities registered by themselves, etc.

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

boarding 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 every day 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 personnel : Will use Enterprise Instant Messaging 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

• Customers (Not shown in Use Case Context Diagram): Invoices are sent to customers

• Finance (Not shown in Use Case Context Diagram): Uses data for invoicing and payroll

7

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. The ID XX number refers to the unique number in use cases in Appendix

3.1.1.

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

8

0.2 High level business processes and their relation to use cases

In the following chapter DanPilot’s TO-BE 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 optimization.

Further instructions to the Supplier Due to the fact that the processes and use case’s relation to Pilots, Boatmen, Dispatchers and All other

personnel are somewhat overlapping it is important that the Supplier is describing the fulfillment of the

requirement in “Appendix 3.1.A - DanPilot- MPDS - Solution Description - Template” and if the process

covers more than one requirement the “Appendix 3.1.B overview of requirements” should be used to

emphasise that a certain described process is used for fulfilling several requirements.

Introduction to TO-BE processes for pilots The following section describes the high level TO-BE processes for planning and dispatching of pilots at

DanPilot. These descriptions are based on as-is but also future requirements to the TO BE processes

including 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. The descriptions will not go into many details but are

meant as an illustration of the required TO-BE workflow for the most important processes.

Figure 1 below provides an overall overview of the described TO-BE processes.

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

9

TO-BE processes rostering and dispatching pilots

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

The participants in the planning or dispatching processes are Pilots, Roster Planners, Dispatchers,

Customers, and Finance. For Primary Actors, please refer to section 0.1 Defining the Primary Actors and

their relation to requirements and use cases.

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, as seen in 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.

Please refer to all the notices in section Rules of notice

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

10

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.

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

11

Process

no.

Description

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

executing the next order

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

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.

Requirement#0.2.1: Processes - Support of processes 1 to 3 – Pilots

Category: Requirement Type: Functional

Description: The System must support the Actor in carrying out the processes 1 to 3 including the use

cases:

• 3.a. Long Term Roster Planning Pilots

• 7.a Short Term Pilots Planning before execution and dispatch including Instant

Messaging

• 25.a Enterprise Instant Messaging – Holiday, special holiday requests including

care days

• 25.b Enterprise Instant Messaging – Pilot Enterprise Instant Messaging.

The Supplier must describe how the System is supporting the processes and use cases in

Appendix 3.1.A - DanPilot- MPDS - Solution Description – Template.

Comment: The Actor is Pilot

12

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.

13

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.

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.




cases 3.a. Long Term Roster Planning Pilots, 3.a.1 Long Term Roster Planning: Approval of

vacation and days off for pilots, 3.a.2 Long Term Roster Planning: Planning of Christmas,

new year, and Easter for pilots, 7.a Short Term Pilots Planning before execution and

dispatch including Instant Messaging, 25. a Enterprise Instant Messaging – Holiday,

special holiday requests including care days and 25. b Enterprise Instant Messaging –

Pilot Enterprise Instant Messaging.



Comment: The Actor is Dispatcher

8 Please be aware of that port pilots also are capable for transit pilotages. But normally a transit pilots 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.

14

Dispatching

Figure 5: Processes involving dispatchers

Process

no.

Description

7 The 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?

9 However, DanPilot has some problems regarding updating the rosters in weekends as the planners only are working normal office hours (This is important in relation to the PDC interface if the Supplier is integrating to this. If the Suppliers own Roster module is used this is irrelevant).

15

Process

no.

Description

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

• 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 optimizer is rum and 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.

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 cannot 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.

16

Requirement#0.2.3: Processes – Support of processes 7 to 11 – Pilots



cases 5 Receiving Automatic Orders for Pilotage, 6 Receiving Manually Orders for

Pilotage, 7.a. Short Term Pilots Planning before execution and dispatch, 7.b Short Term

Pilot Execution, 10.a Short Term Travel Planning before execution and dispatch, 10.b

Short Term Travel Execution, 11 Optimization Pilots as part of Planning and Dispatching,

14 Optimization of Customer Type as part of Planning and Dispatching, 15 Optimization

of Travel Alternatives as part of Planning and Dispatching, 16 Scenario Optimization as

part of Planning and Dispatching, 25.a Enterprise Instant Messaging – Holiday, special

holiday requests including care days and 25.b Enterprise Instant Messaging – Pilot

Enterprise Instant Messaging.



Comment: The Actor is Dispatchers

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.

Requirement#0.2.4: Processes – Support of processes – Geographical global planning and dispatching


Description: The system must support the Actors global planning and dispatching for the entire

operation in Danish waters (instead of sub optimize 3 different areas)


There are other types of pilotages than mentioned before. 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.

Beside to pilotages DanPilot also offers service trips i.e. a pilot boat trip (without pilot onboard) providing

service to ships e.g. delivery of a package or crew exchange.

17

Requirement#0.2.5: Processes – Support of processes – service trips and two boatmen


Description: The Actor must be able to use the System to dispatch boatmen and pilot boats on service

trips. The System must support dispatching two or more boatmen in a pilot boat.

But also, other conditions can require more than one boatman in the pilot boat, e.g.

• When extremely windy or icy weather conditions (i.e. to ensure pilot safety)

• Certain boat sizes require this

• Certain locations of PilotMarks require this

• Guests on board require this (e.g. passenger entering or leaving ship)

Comment: The Actor is the Dispatcher

When a pilot is trained for a new certificate he/she as trainee must be paired with a certified pilot to

acquire the certificate after several trainee trips.

Requirement#0.2.7: Processes – Support of processes – Bunkering, STS


Description: The system must support the Actor in registering Pilotage e.g. bunkering, ship-to-ship

operations at a fixed position. This information is used to billing the customer.


Requirement#0.2.6: Processes – Support of processes - Trainee


Description: The System must support the Actor in planning and dispatching the following

• That an employee needs to be trained for one or more certificates.

• Assigning the “trainee” employee to a relevant order.

• Documenting which orders have had trainees on board, and information about the trainees i.e. How many more trips are required to be considered “trained”.


18

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 in the System.



Description: The System must support the Actor in carrying out the processes 12 to 13 including the

use cases 5 Receiving Automatic Orders for Pilotage, 6 Receiving Manually Orders for

Pilotage,



Comment: The Actors are Customers and Dispatchers

19

Finance

Figure 7: Processes involving Finance

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.

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.




requirements stated in section 1.5 Functional requirements finance/ invoicing, and

section

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

16

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

20

1.6 Functional requirements wage data

The Supplier must describe how the System supports the processes and requirements in

section 1.5 and 1.6 (this appendix) in Appendix 3.1.A - DanPilot- MPDS - Solution

Description – Template.

Comment: The Actor is Finance

Follow-up

Figure 8: Follow-up processes

Process

no.

Description

16 Reporting: On a regularly basis several 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 weekly basis, several KPI’s are reported both as figures and graphs to be used at the weekly performance meetings

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

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

16

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

21

Process

no.

Description

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. 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 date?

• How can we forecast the demand?

BI-data: As DanPilot historically has acquired many separate it-systems, data from the System are made available for our BI.

Requirement#0.2.10: Processes - Support of processes 16 – Pilots


Description: The System must support the Actor in carrying out process 16 including the use cases 25.c

Planned standard time on activities vs actual time spent on activities



Comment: The Actor is Data Manager

Examples of TO-BE-expansions to current processes for pilots

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. 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.

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.

Requirement#0.2.11: Processes - Subsidiaries

22


Description: The System must 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:

Groups of employees

Requirement#0.2.12: Groups of employees


Description: The System i.e. the planning and dispatching System must be capable to roster plan 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

according to the Union Agreements stated in 5. Business Rules under section “Current

Union Agreements (rules)”

Comment:

Standard system

Requirement#0.2.13: Standard system

Category: Requirement Type: Non-Functional

Description: The System must be a Standard System i.e. a System already developed, and with as little

changes as possible be able to meet DanPilots requirements

Comment:

TO-BE processes for rostering and dispatching boatmen

23

Introduction to TO-BE processes for boatmen

Even though boatmen are working according to another set of working agreements (in fact two different

sets) the rostering and dispatching process does not differ that much from the processes regarding the

pilots as those processes are more or less generic.

The following description is therefore based on the description of the TO-BE processes for the pilots.

Figure 9: High-level processes for planning and dispatching boatsmen

Rostering and planning of the boatsmen goes, as illustrated in figure 9, through the following 16 processes

1. Request for days off and vacation

2. Execution of orders and updates and status of current pilotages

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

4. Rostering

5. Announcement of roster

6. Maintenance and update of rosters

7. Available staff on duty or stand by

8. Allocating and reallocating boatmen to orders, planning of rest periods for boatmen, planning of

eventual travels for boatmen, and Alarms for awaken pilots and boatmen

9. Calling in on overtime

10. Request for changes to ETA or ETD

11. Demand of Pilotboats/boatmen

12. Ordering of pilotage

24

13. Changes to order

14. Data for invoicing

15. Data for payroll

16. Reporting, Analyzing, and BI-data

The following section describes how those processes must be for boatmen.

TO-BE processes for boatmen

Process

no.

Description

1 Prior to the rostering boatmen may submit request 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.

Boatmen have depending on the agreement 25 days or 185 hours vacation per year plus 37

hours special vacation days, in Danish særlige feriedage.

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

meaning coordinate and agree on

• when to rest

• when to carry out tasks as e.g.

o sail the pilot boat

o drive to/from boat station

o transport a pilot to/from pilot boat or station

o rigs and rigs of the pilot boat

o minor maintenance task on pilot boats

o service trips

o be second boatman onboard the pilot boat if that might be needed14

• coordination of changes to ETA15 and/or ETD16

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

executing the next order

3 After the announcement of the rosters the boatmen 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.

14 E.g. in case of passengers (not pilots) onboard, sailing more than 4 hours, rough weather conditions etc. 15 Estimated time of arrival for the ship which have ordered pilotage 16 Estimated time of departure for the ship which have ordered pilotage

25

Process

no.

Description

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

therefore not can be on duty.

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

current agreement about the rosters may be set up.

Duties last typically on 12 or 24 hours. Depending on the local place of employment a duty is

assigned a weigh meaning that e.g. a 24 hours duty only may be remunerated with a 17,33

hours salary.

How the duties are placed/combined into rosters depend on local customs at the stations.

On station with high weigh (i.e. station with high activity) the boatmen typically have few duty

days in a row and conversely boatmen at station with low activity tends to prefer more duty

days in a row.

Boatmen must have 30 Sundays and public holidays free, in Danish søn- og helligdagsfri, and

104 + x protected days off, where x is the number of public holidays per year.

Approval and placement of requested vacation are done in accordance to a prioritizing

system.

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 or 12 months depending on the agreements17.

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.

7 The System for dispatching are always updated with the latest changes to the boatmen

rosters at the day of operation. This ensure that the dispatchers always 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 tasks (and changes to orders and tasks) the dispatchers allocate boatmen to orders and tasks. When doing that, dispatchers consider:

• where will boatman be located when the task start?

• where will the boatman be located after the task?

• what are the status of the boatman’s’ previous rest periods?

• how can the boatman have his/her rest period after the task?

• which pilot boat will be in operation in connection to the task?

• Which company car (if any) shall be used

17 The agreement with 3F states that rosters are made for 3 month period and must be announce with 1 months’ notice. The agreement with Faglig Puls states that rosters are made for May-April and must be announce before the 1st of Febraury.

26

Process

no.

Description

• How robust is the assignments regarding changes to ETA18 and ETD?

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

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

• Is it possible19 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 boatmen to the actual tasks. If assigned 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

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

overtime.

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.

Orders are either manually entered into the dispatching system or received through the

OrderAPI and created automatically20.

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.

14 Based on data from the dispatching system customers are invoiced for pilotages.

18 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. 19 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. 20 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.

27

Process

no.

Description

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.

15 Based on data from the dispatching system the salaries for the boatmen are calculated. This

includes calculations of allowances for overtime, which depends on which day types the

overtime were performed.

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 weekly basis, several KPI’s are reported both as figures and graphs to be used at

the weekly performance meetings

• 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 boatmen on duty. 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 pilot boat sailing broken down to weekdays and hours looks?

• Can peaks or coincidences in the demand explain extreme much overtime at a certain 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.14: Processes - Support of processes 1 to 3 – Boatmen



cases 3.b. Long Term Roster Planning Boatmen 8.a Short Term Boatmens Planning before

execution and dispatch including Instant Messaging, 25. a Enterprise Instant Messaging –

Holiday, special holiday requests including care days and 25. c Enterprise Instant

Messaging – Boatmen Enterprise Instant Messaging.

28



Comment: The Actor is Boatman




cases 3.b. Long Term Roster Planning Boatmen, 8.a Short Term Boatmen Planning before

execution and dispatch, 8.b Short Term Boatmen Execution, including Instant Messaging,

25. a Enterprise Instant Messaging – Holiday, special holiday requests including care days

and 25. c Enterprise Instant Messaging – Boatmen Enterprise Instant Messaging.



Comment: The Actor is Dipatcher




cases 5 Receiving Automatic Orders for Pilotage, 6 Receiving Manually Orders for

Pilotage, 8.a Short Term Boatmen Planning before execution and dispatch, 8.b Short

Term Boatmen Execution, 10.a Short Term Travel Planning before execution and

dispatch, 10.b Short Term Travel Execution, 12 Optimisation of Boats as part of Planning

and Dispatching, 13 Optimisation of Boatmen as part of Planning and Dispatching, 14

Optimisation of Customer Type as part of Planning and Dispatching, 15 Optimisation of

Travel Alternatives as part of Planning and Dispatching, 16 Scenario Optimisation as part

of Planning and Dispatching, 25. a Enterprise Instant Messaging – Holiday, special holiday

requests including care days and 25. c Enterprise Instant Messaging – Boatmen

Enterprise Instant Messaging.






29


use cases 5 Receiving Automatic Orders for Pilotage, 6 Receiving Manually Orders for

Pilotage,



Comment: The Actors are Customers and Dispatchers




requirements stated in section 1.5 Functional requirements finance/ invoicing, and

section 1.6 Functional requirements wage data

The Supplier must describe how the System is supporting the processes and requirents in

section 1.5 and 1.6 (this appendix) in Appendix 3.1.A - DanPilot- MPDS - Solution


Comment: The Actor is Finance

Requirement#0.2.19: Processes - Support of process 16 – Boatmen


Description: The System must support the Actor in carrying out the process 16 including the use case

25.c Planned standard time on activities vs actual time spent on activities

The Supplier must describe how the System is supporting the processes and use case in



TO-BE processes for rostering dispatchers

The roster for the dispatchers are made manually and follow a pattern that are locally agreed between the

dispatchers and the management. The roster are made combined such that there will be a decided number

of dispatchers at duty depending of the hour of the day and the day of the week.

Currentligt the dispatching is staffed during the day and week as shown below.

30

In the scheme above the following abbrivations are used

M: Monday

T: Tuesday

O: Wednesday

T: Thursday

F: Friday

S: Saturdag

S: Sunday

Døs: Day - east area dispatching

Nøs: Night - east area dispatching

Dno: Day - north area dispatching

Eno: Afternoon - north area dispatching

Dsy: Day - south area dispatching

Nsy: Night - south area dispatching

Ser: Service job

Administrative: Administrative job

31

Requirement#0.2.20: Processes - Support of processes – Dispatchers


Description: The System must support the Actor in carrying out the process TO-BE processes for

rostering dispatcher including the use case 3.c Long Term Roster Planning Dispatchers

The Supplier must describe how the System is supporting the processes and use case in



Requirement#0.2.21: Processes - Support of processes – Enterprice Instant Messaging


Description: The System (Enterprice Instant Messaging) must support the Actor in carrying out a

number of functionalities for example:

• Instant Messaging communication between Dispatchers, Pilots, Boatmen

• Pilots can see the current/future job(s), create status messages, change depth of

ships

• Boatmen can see current/future job(s), sailplan for goups of boats, sailplan,

which pilot to be picked up by car etc.

• Dispatchers, Pilots, Boatmen and All other employees can handle holiday etc.

including the use cases 25.a Enterprise Instant Messaging – Holiday, special holiday

requests including care days, 25.b Enterprise Instant Messaging – Pilot Enterprise Instant

Messaging, 25.c Enterprise Instant Messaging – Boatmen Enterprise Instant Messaging

The Supplier must describe how the System is supporting the Enterprice Instant

Messaging use cases in Appendix 3.1.A - DanPilot- MPDS - Solution Description –

Template.

Comment: The Actors are Dispatchers, Pilots, Boatmen and All other employees

32

0.3 Requirements for System supporting the complexities in dispatching The dispatchers 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

- Minor maintenance of pilot boats

33

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 must 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 hub-structure it is possible to realize savings on trips by taxi as the pilots can often 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.3.1: Complexity of planning - Pilots


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

The System must support the Actor in Planning, Short Term Planning, Dispatching and

Executing pilots which includes:

- Plan pilotages

- Allocate pilot to pilotages

- Plan rest periods


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


34

o Taxi


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

o By airplane

The System must support the Actor in the following use cases 11 Optimisation Pilots as

part of Planning and Dispatching 12 Optimisation of Boats as part of Planning and

Dispatching, 13 Optimisation of Boatmen as part of Planning and Dispatching, 14

Optimisation of Customer Type as part of Planning and Dispatching, 15 Optimisation of

Travel Alternatives as part of Planning and Dispatching, 16 Scenario Optimisation as part

of Planning and Dispatching,




Requirement#0.3.2: Complexity of planning - Boatsmen


Description: The System must support the complexity mentioned in section 0.3

The System must support the Actor in Planning, Short Term Planning, Dispatching and

Executing pilots which includes:

- Allocate boatmen to sail plan (e.g. by utilising time-space-diagrams)

- Plan rest periods


- Allocate boatmen to transportation of pilot in company cars


o Taxi


o Company car (see above)

o (By airplane)

- Allocate boatmen to time block of e.g. 2 hours for minor maintenance of a pilot

boat at a given location. Time blocks and locations are defined by the dispatcher.


35

Requirement#0.3.3: Complexity of planning, shortterm planning, dispatching and execution – use cases


Description: The System must 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

The Supplier must describe how the System is supporting the Requirement#0.3.1 and

Requirement#0.3.2 and use cases in Appendix 3.1.A - DanPilot- MPDS - Solution


Comment:

36

0.4 Requirements for System supporting the planning a transit pilotage within

Route T

A pilotage from Allinge or Gedser to Skagen,

route T, or in the opposite direction 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 most constraining regarding Pilot utilisation. 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 may be higher.

Requirement#0.4.1: Transit pilotage – Non stop


Description: The System must support the Actor in Short Term Planning, Dispatching and Executing 2

pilots from the starting point to the ending point of the pilotage. The System must offer

this services to VIP customers automatically and make sure the Actor will offer this to

other customers as an add-on product

The Supplier must describe how the System is supporting the Requirement#0.4.1 in


Comment: The Actor is the type Dispatcher

37

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 change 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 must support the Actor in situations where there is only planned with 1 pilot

at the beginning e.g from Gedser to Korsør. After a while, e.g. at Korsør the System must

support the Actor to plan with that a second pilot will board the ship and the remaining

pilotage to Skagen must be carried out like a nonstop pilotage.

In the opposite direction the dispatcher will embark two pilots at Skagen, and may

disembark one of the two pilots at Korsør and let the remaining pilot take the ship to

Gedser.

But a lot of other combinations may be possible e.g. also to (dis)embark all pilots at

Korsør and embark new pilot(s) for the remaining pilotage.

For more details please also see the next requirement 0.4.3.




38

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


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

A to D (starting point and ending point) can be 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/off the ship based the most optimal plan.



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

39

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 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 must 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.

An often used terminology is for different modes of dispatching is

1. interactive manual dispatching

2. semiautomatic dispatching

3. automatic dispatching

By the first is understood a process where the dispatcher dispatch manually by e.g. drag and drop when

dispatching. So here all decisions are taken purely by the dispatcher supported by e.g automatically

displayed list of pilots that can be allocated to a given pilotage. The dispatcher the pick one pilot from the

list and the system automatically validate the allocation and gives a warming if any rules are violated.

40

By the second is understood a process where the dispatcher select a number of pilotages and the system

generate a number of cost-effective scenarios that ensure that alle the pilotages have pilots allocated.

By third is understood an automatic (and optimal) allocation af pilot to all pilotages.

Typically a dispatcher will switch betwwen those three modes of dispatching depending of the situation.

The same goes for rostering.

Requirement#0.5.0: Optimisation – Manual, semi-manual and automatic rostering


Description: The System must support the Actor in the following three modes of rostering

1. interactive manually rostering

2. semiautomatic rostering

3. automatic rostering




Requirement#0.5.1: Optimisation – Manual, semi-manual and automatic short term planning and

dispatching

Category: Minimum Requirement Type: Functional

Description: The System must support the Actor in the following three modes of short term planning

and dispatching

1. interactive manually dispatching

2. semiautomatic dispatching

3. automatic dispatching




41

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.

42

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

• Short term planning/Dispatching/Execution of travel of pilots

• Short term planning/Dispatching/Execution of travel of boatmen

• Short term planning/Dispatching/Execution company cars

• Short term planning/Dispatching/Execution pilot boats

: Requirements to the System

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


Description: The System must support the Actor in Short term planning/Dispatching/Execution as one

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

solution and thereby 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: The Actors are Dispatcher and Planner

43

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.3: Objective function for optimization – Rostering


Description: The System must 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

The System must support the Actor to set other goals that may also be conceivable.

Comment: The Actor is Planner

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

profile


Description: The System must support that profiles 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: The Actor is Planner and or Super User

44

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

Table 1

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


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

periods as illustrated in the table 1 below

Comment: The Actor is Planner

Number of duty days in a row Wanted percentage

3 0%

4 2%

5 15%

6 20%

7 25%

8 35%

9 3%

45

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 otherwise this will make it impossible to serve customers at Thursdays at 12:00.

5.1.4 Posibility to 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.6: Objective function for optimization – Equally distributed shifts in and out of duty

periods


Description: The System must support equally distributed shifts in and out of duty periods during the

hours of a day and days of a week.

The System must also support the exeption from the above requirement that 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.

Comment: The Actor is System

Requirement#0.5.7: Objective function for optimization – Posibility to meet request for days off


Description: The System must support the Actor in (as much as posibel) 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.8: Objective function for optimization – Multi-objective function


Description: The System must 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

46

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

5.2 Short term planning, Dispatching and execution

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.9: Objective function for optimization – Goals meet within the individual roster and

globally for all roster


Description: The System must 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.2 to 0.5.6.

Comment: The Actor is the Planner.

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

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


Description: The System must 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.


47

5.2.1 Minimizing the overall costs

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.11: Objective function for optimization – optimizing by minimizing the overall costs


Description: The System must 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)


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

the plan


Description: The System must 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.13: Objective function for optimization – Introduce as few changes as possible to

the existing plan


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

before executing

48

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.

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.


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

certificates


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

as possible among pilots who hold the considered certificate


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


Description: The System must support the Actor in maximizing customer satisfaction by minimizing

the inconvenience for customers by changing pilots.


Requirement#0.5.16: Objective function for optimization – Maximize customer satisfaction (ETA-ETD)


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

request changes to ETA or ETD


49

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.17: Objective function for optimization – Maximize the employee satisfaction


Description: The System must 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.18: Objective function for optimization – Distribute the workload equally among the

employees


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

pilots/boatmen over a selectable period of time


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

criteria


Description: The System must 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.8 to 0.5.16.

Comment: The Actor is the Dispatcher.

50

Requirement#0.5.21: Processes - Support of processes/ Complexity of optimization of planning,

shortterm planning, dispatching and execution - All other use cases (Catch all)


Description: The System must support the Actor in carrying out the rest of the use cases not

mentioned in Requirement#0.2.1 to Requirement#0.2.21. and Requirement#0.5.1 to

Requirement#0.5.20

The Supplier must describe how the System is supporting the use cases in Appendix 3.1.A

- DanPilot- MPDS - Solution Description – Template.

Comment: The Actors are different actors – please refer to the use cases

Requirement#0.5.20: Complexity of optimization of planning, shortterm planning, dispatching and

execution – Use cases


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

The Supplier must describe how the System is supporting the Requirement#0.5.1 to

Requirement#0.5.19 including the stated use cases in Appendix 3.1.A - DanPilot- MPDS -

Solution Description – Template.

Comment:

51

0.6 Alternative use of logged data

1. Introduction Logged data can be used for many purposes. DanPilot also want, what might be an alternative use, the

possibility to use logged data for training, simulation, and competition purposes.

2. Training purposes DanPilot want that is possible to use the new system to train dispatchers to make better decisions. The idea

is that it must be possible to evaluate real cases from the operation, where something went wrong,

typically became too costly. In such a case, it must be possible to turn back time, take another decision and

(re)play the situation and see if another decision improves the outcome. The “new” decision could one

taken manually by the trainee or done by the optimization-module to illustrate what the optimal decision

would have been.

It could also be used to train new dispatchers under realistic circumstances without having impact on the

real operation.

3. Rule simulation The agreed rules regarding working hours and rest periods (and interpretations of those) have essential

impact on the efficiency of the operation. Therefore, another use of logged data will be to analyze the

impact on the operational costs when rules are changed. A typical example of such a situation is when

DanPilot negotiate new agreements with the trade unions. But it could also be the impact of new customer

agreements with effect on the operation.

Requirement#0.6.1: Alternative use of logged data – Training purposes


Description: The System must enable the Actor to “replay” the planning, dispatching and execution

based on logged data. The purpose is evaluating real cases from the operation, where

something went wrong and to train new dispatchers under realistic circumstances

Comment: The Actor is Dispatcher or Super User

Requirement#0.6.2: Alternative use of logged data – Rule Simulation


Description: The System must enable the Actor to use logged data for analyzing the impact on the

operational costs when rules are changed


52

4. Competition simulation As the market for pilotage will change over the next years logged data could be used to simulate the impact

of changes in the market e.g. what happens if a competitor take x% of the transit market, x% of the port

pilotages in the main ports, or concentrate on a specific route etc.

5. In general

In general, DanPilot wants that the new system shall offer the possibility simulate the effect of changes

based on logged data for the operation. Beside the most obvious examples given in the sections above

other examples could be changes to the location of pilots and boatmen, changes to the number of pilots

and boatmen, changes to the certificate structure for the pilots etc.

Requirement#0.6.5: Logged data - description


Description: The System must support the Actor in carrying out use of logged data as described in

Requirement#0.6.1 to Requirement#0.6.4.

The Supplier must describe how the System is supporting these requirements in Appendix

3.1.A - DanPilot- MPDS - Solution Description – Template.

Comment: The Actors are different actors – please refer to the use cases

Requirement#0.6.3: Alternative use of logged data – Competition simulation


Description: The System must enable the Actor to use logged data for simulating the impact of

changes in the market


Requirement#0.6.4: Alternative use of logged data – In general


Description: The System must enable the Actor to use logged data for simulating the impact in relation

to changes to the location of pilots and boatmen, changes to the number of pilots and

boatmen, changes to the certificate structure for the pilots etc


53

1. Other Requirements

1.1 Functional requirements orderprocess:

Requirement#1.1.1: Orders – Receiving Automatic Orders for Pilotage


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

Comment: Orders comes via Gat.Ship

Requirement#1.1.2: Orders – Receiving Manually Orders for Pilotage


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

Comment: These be received via e-amil, telephone and VHF radio, however will always have to be

confirmed via e-amil

Requirement#1.1.3: Change of an order – before execution


Description: The System must 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.4: Change of an order – after execution


Description: When an order is executed the System must 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)

54

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

must be marked as deleted, together with metadata describing who and when the “delete” marking was

made.

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


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

data”

The System must support the Actor in not deleting data inputted manually, but must be

marked as deleted, together with metadata describing who and when the “delete”

marking was made.


Requirement#1.1.6: Orderproces – requirements


Description: The System must support the Actor in carrying out use of logged data as described in

Requirement#1.1.1 to Requirement#1.1.5.

The Supplier must describe how the System is supporting these requirements in Appendix

3.1.A - DanPilot- MPDS - Solution Description – Template.

Comment: The Actors are different actors – please refer to the requirements

1.2 Functional requirements planning and dipatching:

This section describes 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 must support the Actor in visual planning and dispatching functions by e.g.

drag and drop functions.

Comment: The Actors are Dispatcher, Planner or Super User

55

Requirement#1.2.2: Visual planning and dispatching – overview


Description: The System must support the Actor in visual planning and dispatching functions by e.g.

having the ability to individually (i.e. per user) design and save screensettings, how critical

planning and dispatching windows are shown


Requirement#1.2.3: Planning and dispatching – Alarms


Description: The System must support the Actor in setting of alarms in order to “remind” the actor on

certain tasks e.g. wake-up call of Pilot. The System must relate these to jobs, i.e.

automatically update alarms according to changes to orders


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


Description: The System must support the Actor in 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 Requirement#2.2.11:

Integration with Zylinc phone system/Ozeki SMS system. The Actors are Dispatcher or

Planner

56

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


Description: The System must support the Actor in 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

Requirement#2.2.11: Integration with Zylinc phone system/Ozeki SMS system. The

Actors are Dispatcher or Planner

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


Description: The System must 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 Requirement#2.2.11:

Integration with Zylinc phone system. The Actor is the System

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


Description: The System must 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

Requirement#2.2.11: Integration with Zylinc phone system. The Actor is the System

57

21 20-25 pilot boats.

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


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

transportation activity for a Pilot is prolonged the following activity of Pilotage must 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 must postpone both activity B and C,

hence Automatic updating of “chainactivities”. The Actor is the System

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


Description: The System must support the Actors in (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 or regarding to spit of functions i.e. short term planning and execution

Comment: The Actors will be Planners and Dispatchers

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


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

boatmen and pilot boats21 bringing pilots to and from ships. This must include that both a

Pilot and a Boatman is travelleling by car.

Comment: The Actors will be Planners and Dispatchers

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

views


Description: The System must support the Actor that “Retired Pilots” must be less prioritized in

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

58

Optimizing the use of resources when processing orders is essential to DanPilot, and it is important that the

System facilitates the optimal use of existing resources, and with different and varying constraints. To this

end, the System must be able to integrate with external optimizers that allows DanPilot to plan the use of

resources and processing of orders.

Requirement#1.2.13: Planning and dispatching – Use of External Optimizers


Description: The System must be able to integrate with one or more external optimizers, and must be

able to use the external optimizers to plan and schedule the use of all or parts of the

resources and orders in the System.

The System must not require more the use of more than one external optimizer.

The Supplier must describe:

• How the System is able to integrate with external optimizers

• How many external optimizers the System can integrate with at the same time

• How planning of locations, resources, orders, and other entities in the System can

be optimized using external optimizers

• How scheduling of locations, resources, orders, and other entities in the System

can be optimized using external optimizers

• What parts of the planning, scheduling, and other allocation operations by the

System that can not be optimized using one or more external optimizers.

Comment:

Requirement#1.2.14: Planning and dispatching – External Optimizer Supporting Use cases



Requirement#1.2.12: Planning and dispatching – Better travel time precision


Description: The System must support the Actor in planning 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 and company cars).


59

Description: The System must at least be able to optimize the following use cases with an external

optimizer as part of planning and dispatching:

• Use case 11

• Use case 12

• Use case 13

• Use case 14

• Use case 15

• Use case 16

• Use case 17

The Supplier must describe how the System supports optimizing each of those use cases

using an external optimizer.

Comment:

Requirement#1.2.15: Planning and dispatching – Receiving SMS Text Messages


Description: The System must provide an integration to an SMS text messaging gateway and be able

to receive SMS text messages.

The System must use the integration to receive SMS text messages from Customers with

new or updated status information about ships.

If the SMS is received from a phone number that is related to one or more ships that are

part of the current dispatch planning, the System must show the received SMS in the

context of the relevant ship or ships.

If the SMS text message contains the word “ETA” or “Estimated Time of Arrival”, a date

and/or time in a commonly occurring format, the System must suggest this date and time

as an update to the current expected ETA for the ship the sending phone number can be

related to.

The Supplier must describe how this integration is implemented in the System, and how

an Actor is made aware of a new message.

Comment:

60

1.3 Functional requirements reporting:

Requirement#1.3.1: Reporting– Certificates to Danish Maritime Authority


Description: The System must support the Actor in producing 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 for the Pilots reporting must be like use case 40

Reporting Certificates to Danish Maritime Authorities (DMA) in order to support the Pilot

in reporting to the Danish Maritime Authority in order to maintain the Pilots certificate.

Comment: The Actors are Pilots or Boatmen

Requirement#1.3.2: Reporting – Certificates - warnings


Description: The System must enable the Actor in producing reports stating the number of trips and

which certificates the Pilot or Boatman has participated in, and the System giving

warnings (X number of month before) about certifactes not being maintained. The

warnings must be communicated to the Actors. Warnings must be set by parameters and

rules.

Comment: Repports: The actors are Dispatchers, Dispatch Manager, Pilots and Boatmen

Warnings: The Actor is the System

Requirement#1.3.3: Reporting– Tracking of ressources


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

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

Pilotboats, DanPilot cars. The online report should should utilize GPS for Pilots,

Boatsmen and DanPilot cars, AIS signals for Ships en-route and Pilotboats for tracking.

Comment:

61

1.4 Functional requirements sales data:

Requirement#1.3.4: Reporting– Standard repports


Description: The System must enable the Actor in creating a number of relevant standard reports:

• Accumulated earned overtime per day type

• Accumulated earned overtime (DKK or hours)

• Accumulated earned overtime per Pilot

• Time on Bridge (in %)

• Distribution of work in Time on Bridge, Pilotboat, Standby and rest

• Number of contacts with emplyee per order

• Statittics regarding changes in ETA

• On-time measurements regarding

o The Sip arrives on expeted time

o Pilot meats deadline in regards to arrival at ship

• Order segmentation

• Pilotboat hours per order

• Pilotboat trips per order

Comment: The actors are Dispatchers, Dispatch Manager, Planning and Dispatch Manager

Requirement#1.3.5: Reporting– Logging


Description: The System must 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 helping tables.

That means that this log must 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.


62

Description: The System must enable the Actor to easily view the ship “note” information 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 must

know before going on board the ship

2. extra services (e.g. newspaper delivery)

Comment: The actors will be Dispatchers, 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: The System must enable the Actor in creations of orders , without 100% certainty that

DanPilot will be booked to execute the order.

Comment: Actor is Sales Employee

63

1.5 Functional requirements finance/ invoicing:

1.1 Order is received and is put into the dispatching system

The following data is registered per the "a-h list"

• Imo number - comes from SeaWeb • Order number - taken continuous in the dispatching system • Date of pilotage • Route • Payer • In or out of the harbor • Transit • Comment field • Ship information - call sign/ width/ length/ tonnage - comes from SeaWeb • Name of the pilot • Name of the dispatcher • Major customer deals

1.2 Pilot bill is generated

Data from the dispatching system is transferred to the pilot bill.

The pilot can edit the following data:

• Draft

• Route

• Severance pay

1.3 Pilot bill is completed

When the pilotage is completed, a pilot bill is signed by the captain and the pilot can complete the pilot bill. The data is transferred to Navision/ the invoice

1.4 The order is completed within the dispatching system

The order is completed and data is transferred to Navision/ the invoice

Requirement#1.5.1: Invoicing


Description: The System must support the Actor invoicing directly from Navision as explained in table 1 below, if all conditions are met at transfer from the dispatching system.

Comment: In the event of using automatic invoicing, some decisions about who owns data has to be made:

o Routes o Payer info

Data discipline is important in automatic invoicing as there might become too many corrections to the invoice and thereby nothing is gained. The Actor is Finance employee

64

1.5 Data is evaluated/ approved

The data is evaluated in Navision and all data is filled/ correct in connection with the rules. The invoice

is approved and send to the customer.

It should be possible to enclose the pilot bill as an attached document or as a gathered document with

the invoice.

1.6 The invoice data is put into a list

If the data does not match the rules, the invoice is put into a list in Navision.

Then the debit function examines the data and edits it, after which the invoice is send to the customer.

It has to be possible to enclose the pilot bill as an attached document or as a gathered document with

the invoice.

Service trips:

Should be transferred to Navision with a separate code, as they are not treated in the same way as

regular pilotage.

It is preferred that ordering mail is automatically enclosed with the invoice.

The following data is used for invoicing of service trips:

• Pilot on board

• Start and end time

• Commentary field

• Day of pilotage

The following could be those which aren't going through automatic invoicing.

Tow: Width and length The towed unit + possibly Imo number / dimensions Towers + Imo number / Dimensions Route Draft Be aware if it is a "Rig" (special task) Comment: Start and end time.

Slow tow

Special task: Pilot exemption (Giite creates in PB) Consultant – ie. Simulations Limfjord pilot (Maintenance of certificates – internal invoicing to be able to know the costs)

65

Table 1 Invoice process

66

1.6 Functional requirements wage data:

General description of the wage-process The planners put duties, BF-days, vacation, sickness etc. In to the duty planning system All boatmen must register their work in the duty planning system. These registrations are accounted for differently depending on what they are registered on; duty, vacation, BF, etc. (look at descriptions of registrations) Registrations and duties are the basis of the wage on the norm offset, time off and an extra hour. Everything must be calculated under the applicable agreements. An optimal wage generation would be for all wage data to go directly from the dispatching system in to the planning system and further in to the payroll system. Table 2 HR/ Wage

67

Requirement#1.6.1: Wages


Description: The System must handle the following payroll data 1. Vacation

a. Held vacation for all employees b. Held special vacation on all employees

1. Boatmen/substitutes a. Overtime b. Norm hours, substitutes have worked c. Overtime for substitutes

2. Pilots a. Hours of overtime

i. 50% hours ii. 100% hours

iii. FR-days b. Time off

i. Held time off 1. 50% hours 2. 100% hours 3. FR-days

ii. Possibly differentiated payment - how much and when 3. Part time pilots

a. Hours worked b. Overtime

The System must support changes to the setup/formula for wage calculations, and that the changes must be date managed, which means that if the changes are valid from the 1st of January, then everything on that date must not be changed as well. Print outs: • The System must support saving setups of print outs for later use (so we do not

have to make a setup each time) • The System must support all print outs to be saved in excel.

Comment:

68

Description of boatmen - pay

The following totals must be visible, to be able to check correct remuneration.

Boatmen - agreement Faglig Puls

Table 1 and 2 Vagtnorm = Number of duties the boatman must have in the norm period. Planlagt V = Number of duties the boatman has planned in the norm period. Udlign E t = Number of duties which have been offset with extra hours (earned in 0-days) - must be shown i both hours and duties Udlign A = Number of extra hours, which have been offset to time off. Ex tim M / ÅTD = extra hours earned in the current month/ extra time earned annually to date. Ex tim ej udl = Extra time which has not been offset to duties or time off.

Requirement#1.6.2: Wages – description of boatmen - pay


Description: The System must be able to produce the correct content described in tables shown below

in table 1,2, and 3 including the mentioned printouts and Boatmen - substitutes -

agreement 3F

Comment: The Actor is Finance employee

69

Primo = balance per the first in the month Udl / ikke god = Extra hours which has been offset as time off (must be shown in hours and number of duties) / hours which are earned BF-days in the current month / number of hours which are paid in the current month. Afsp / udbetalt = Time off held in the current month / number of hours which have been paid in the current month (the hours are calculated in the current month, but only paid and offset in the system next month. Ultimo = is the balance per the last in the month ("Primo" + "Udl" + "ikke good" deducted from "planlagt" and "udbetalt") Planlagt = Number of hours which has been planned for time off in the future. Kan plan / udb = Hours which can be paid or planned for time off (Primo-"afsp"–"planlagt") This is the column which needs a wage type to transfer in the payroll system. Boatmen - agreement 3F

Table 2 Norm (N) = Number of hours the boatman has to work in the norm period Periode = length of the norm period Arbejde = number of hours worked in the current month Fravær = number of hours where the boatman has held vacation or special vacation Planrest = Number of hours of work , which the boatman are missing to achieve the norm Beregnet = Number of hours the boatman has worked in total ("arbejde"+"fravær" Beregnet overtid = "arbejde" + "fravær" – "normen"

70

Prognose = Number of hours of work, which the boatmen are missing (or worked too much) to achieve the norm (the number of hours changes when the boatman works longer than the fixed duty) Samlet = a total calculated/forecasted - if the number in the parenthesis is positive, the boatman has worked more than the norm and the hours are offset and put into time off, when the norm period is finished.

Table 3 AFS primo = Number of hours the boatman has in the start of the month AFS optj nor = time off earned in relation to the norm AF afv / udb = number of hours which have been held as time off / number of hours which has been paid AFS ultimo = number of hours the boat has per the last in the month.

This is the column which needs a wage type to transfer in the payroll system. AFS planlagt = number of hours of time off which have been planned AFS rest = number of hours which are earned in the current month minus planned time off. Boatmen - substitutes - agreement 3F Registered on the same total as boatmen - agreement 3F, but has to have separated wage types to hours for the norm and overtime When the time registrations is accepted and the wage is put into the payroll system, the period must be closed in the planning system, so it is not possible to edit. If something is edited, this must come from the payroll system. It has to be possible to make offset duties, which moves hours from one balance to another - e.g.. from the total 'B: Registration - gathered to D/B: time off / extra time must be able to offset duties. There has to be a approval flow between the boatman registration and the wage is formed.

71

It has to be possible to comment on the registration, poss. edit data or forward edits to pay, which can then edit the registrations before the wage is formed. It has to be possible to make a marking of the employees that only wishes to take their time off, thus not getting the hours paid. Therefore, the hours should no be pulled into the payroll system. Possibility to differentiate the employees on the basis of when they want their time off paid. Marking should be both visual and root in the wage type. It must be possible to put a wage type on each payment possibility in the planning system. In connection with "Faglig Plus" the wage type for hours The wage type must be able to be pulled directly in to the payroll system, where the hours will be accounted for as the hourly rate +50%. No rates should be in the planning system. Printouts

• List of the boatmen/ substitutes overtime - per station / per employee / per agreement group in a given period

• List of the substitutes norm time in a given period

Description of Pilots - pay

Pilots - agreement Danske Lodser Pilots Totals: • Earned time off

o 50% hours - earned by work on availability days (must have a wage type) o 100% hours - earned by work on AF-days and FR-days (must have a wage type) o Compensations days off - earned by work on AF-days and FR-days (must have a wage type)

• The total must show: o Transferred from previous month o Earned in the current month o Held time off o Payout o Transferred next month

Requirement#1.6.3: Wages – description of Pilots - pay


Description: The System must be able to produce the correct content described in text shown below

including the mentioned printouts and Pilots - agreement Danske Lodser


72

• We must be able to see the dates for when the time off is earned (possibly a list or a total) in any given period per person or personnel group

Part time pilots Part time pilots have a three-month vesting period. Totals: • Vested working hours

o Must be able to see how many hours which have been worked o Must be able to see how many hours of missing work in the full-time norm o Hours vested besides the full-time norm o Krakfactor - must be able to see how many hours the pilot works, where the krakfactor applies

(the krakfactor must only be applied when there has been worked in the full norm) o 0-days (days where no working time are registered) (norm hours) o Number of duties o AF-days - days off work (krakfactor is applied) o Availability duties (krakfactor is applied

Special service/course/project (not in job) • Must be able to see if the pilot is in a job or not in a job • In a job, over time will be paid out - must be shown in the total

Helping pilots: • The first 5 hours are accounted for under one rate - must have a wage type for transfer in payroll

system • Remaining hours are accounted for under another rate - must have a wage type for transfer in payroll

system • Stand by time = 3 hours per day per weekend

Harbor days: • The pilot must be marked in the planning that he has harbor days • Must be able to see if the harbor days should be paid out or given as time off

Print outs: • Possibility to pull a list on the pilot overtime 50%/100%/EFR incl. The date the time off has been

earned • Possibility to pull a list on what the pilot have been paid and when • Possibility to pull a list on what the helping pilots have earned (what lies in the totals) • Possibility to pull a list on what the par time pilots have earned (what lies in the total) • Possibility to pull a list on the number of hours used on special service/course/project per person in a

given period

73

Description of boatmen - pay

Dispatchers - Faglig Plus – local agreement

AFS primo = Number of hours the boatman has in the start of the month AFS optj nor = time off earned in relation to the norm AF afv / udb = number of hours which have been held as time off / number of hours which has been paid AFS ultimo = number of hours the boat has per the last in the month.

This is the column which needs a wage type to transfer in the pay system. AFS planlagt = number of hours of time off which have been planned AFS rest = number of hours which are earned in the current month minus planned time off.

Supplements, which are granted to the dispatchers, when they take extra shifts in the standard workdays and in the weekends, has to be automatically registered at the same time as registered time.

The supplements must be transferred to the pay system with each of the wage types.

Requirement#1.6.4: Wages – description of dispathers - pay


Description: The System must be able to produce the correct content described in table shown below

in table 1 including the mentioned printouts and Dispatchers – Faglig plus – local

agreement


74

Registrations in the planning system Registrations boatmen

Table 1 below:

Text Old boatmen Local agreement Applies for both

Administration x Must count 1:1

Functional supplement x Must count 1:1

Course x Must count 1:1

Drive x Must count 1:1

Listening watch x % Must count 1:1

Man over board practice x Must count 1:1

Handover x Must count 1:1

Boatman meeting x Must count 1:1

Sailing x % Must count 1:1

Stand by x % Must count 1:1

Rigging x Must count 1:1

Requirement#1.6.5: Registrations -boatmen


Description: The System must ensure that the boatmen have the following possibilities for registration shown in table 1, when they register their working hours. The boatmen hours/wage is calculated from where the registration is entered in the roster plan. The system must support the mentionsed printouts below table 1. Within the registration there is also a calculation for, if the boatmen according to the agreement needs a minimum of 3 hours to come to work.

Comment:

75

Transport x Must count 1:1

Maintenance building x Must count 1:1

Maintenance boats x Must count 1:1

Waiting time x Must count 1:1

Stand by at home incl. drive x Must count 1:1

Stand by on station x Must count 1:1

Sailing incl. Readying and stripping x Must count 1:1

Drive with pilots x Must count 1:1

Maintenance duty car x Must count 1:1

Shopping of emergency provisions Must count 1:1

The activities/task carried out of boatmen and pilot have to be register such that the calculation can be done on the basis of work carried out. Furthermore, the registred data must be available for the rostering so that the planners always plan on the basis of updated data for e.g. days off, time off in lieu etc. The administrative personnel also registers their time in the planning system, but these aren't wage generating. Print outs: • Possibility to make a list over each registration per person or personnel group in a given period - the

list must be able to show pay number, name, registration text, time and comments Vacation

Pilots: Pilots earn 30 days of vacation per year The total must show:

Requirement#1.6.6: Vacation


Description: The System must ensure that the Actor can manage vacation for thePilots, Boatmen and administration including dispatchers as described below including printouts.

Comment:

76

• Number of day the pilot can hold • Number of days the pilot has earned with wages • Number of days the pilot has held • Number of days which are planned • Number of days which haven't been held yet/planned • Number of days which have been transferred from old vacation year

Boatmen: Boatmen earn 25 days of vacation per year and 37 hours of special vacation The total for vacation must show: • Number of days which can hold • Number of days earned with wages • Number of hours which have been held • Number of days planned • Number of days which haven't been held yet/planned • Number of days which have been transferred from old vacation year

The total for special vacation must show: • Number of hours earned with wages • Number of hours which have been held • Number of hours which have been planned • Number of hours which haven't been held yet/ planned • Number of hours which have been transferred from old vacation year • Number of hours which have been paid out from old vacation year

The administration: (incl. Dispatchers) The administration personnel earn 25 vacation days per year and 37 hours of special vacation The total for vacation must show: • Number of days which can hold • Number of days earned with wages • Number of hours which have been held • Number of days planned • Number of days which haven't been held yet/planned

77

• Number of days which have been transferred from old vacation year The total for special vacation must show: • Number of hours earned with wages • Number of hours which have been held • Number of hours which have been planned • Number of hours which haven't been held yet/ planned • Number of hours which have been transferred from old vacation year • Number of hours which have been paid out from old vacation year

Applicable for all groups, should there be an approval flow where the wanted vacation gets approved by the closest boss before the vacation can be held. The number of held days/ hours must be put directly into the pay system, which then automatically pulls them from the payroll systems vacation accounting. If an employee has held more vacation than he has earned in wages, there must be payed attention to this. Print outs: • Possibility to pull a list of held vacation in a given period for a given personnel group • Possibility to pull a list of held special vacation in a given period for a given personnel group • Possibility to pull a list of lack of held vacation and special vacation for a vacation year, for a given

personnel group

1.7 The Supplier’s system requirements for MPDS The Supplier must in cooperation with the Third Party Operational Supplier (TPOS) be responsible for the operation of MPDS. The Customer must ensure the creation of a server environment, regarding test and operations, that is created on the basis of the Supplier’s requirements.

Requirement#1.7.1: Test and operational environment – Supplier’s system requirements


Description: In cooperation with the TPOS the Supplier is required to, install and maintain both an

operational and a test environment.

The Supplier must describe the required it infrastructure (network, servers, operating

systems, storage, databases, middleware and other components including any software

licenses and license model if applicable) related to the Customer’s test and operational

environments in order to deliver and operate the MPDS after this has been delivered to

the Customer.

Comment:

78

In regards to servers and databases the TPOS offers the following standard it infrastructure services:

Microsoft SQL Server Enterprise with up to 4 cores, Cluster Active/passive. (underlying windows server is not included in service)

Microsoft SQL Server Enterprise with up to 4 cores

(underlying windows server is not included in service)

Microsoft SQL Server Standard with up to 4 cores

(underlying windows server is not included in service)

Windows Virtual server 1 vCPU 4 GB RAM



Windows Physical server 2 CPU 128 GB RAM

List of server and database services

Requirement#1.7.2: Test and operational environment – standard server and database services


Description: The Supplier must as a supplement to the above mentioned requirement describe on

which standard server and database services the offered system can be operated. The

Supplier must choose services from the list below and can supplement with other

required server and database services if needed.

Comment:

Requirement#1.7.3: Test and operational environment – development environment


Description: The Supplier must, in cooperation with the Customer’s TPOS, create and maintain a

development environment which has the same functionality as the Client’s operational

environment.

The development environment must be placed at the same hosting facilities as the test

and production environment.

The delopment environment must be present and functional during the entire period of

the agreement.

79

2. Non functional requirements 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. If specific

security requirements are needed for a certain service/component, these will be described for each

service/component in a later section. Finally, data management requirements to the System and to other

systems are described.

2.1 Architecture DanPilot is requesting a standard system to replace the current, custom developed solution.

DanPilot requires an open, extensible system that can scale and adapt to the changing requirements

DanPilot will see as the market evolves. The system should be based on current best practices, and should

be built in such a way, that the system can be adapted and modified as needed to the business

requirements, without having to change the chosen standard system.

The requested System must integrate and work together with a range of other business critical systems in

DanPilot. It is important that the system architecture effectively supports this level of integration, without

requiring significant work.

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.

General

Requirement#2.1.1: Architecture – Extensibility


Description: The System should have an open, extensible architecture that is easy to adapt and modify

to specific requirements without requiring changes to the underlying standard system.

The Supplier must describe how the System can be extended, adapted, and modified.

Comment: DanPilot prefers systems that can be extendend with plugins by DanPilot, and where the

look and feel of the user interfaces can be adapted and extendend by DanPilot.

Requirement#2.1.2: Architecture – Extensible Data Model


The Supplier must in the answer describe the needed server and database services

needed to support the development environment.

Comment:

80

Description: The System should have a data model that allows for adding new data elements such as

tables or fields with only minimal work required.

Minimal work in this context means that adding single data items, such as a new

database table or a new field in an existing database table, should not require any form

of significant system level changes.

The Supplier must describe how new data elemenst, such as tables or fields, can be

added to the System, and the process for doing so.

Comment:

Requirement#2.1.3: Architecture – Integration


Description: The System should have an architecture that allows the system to easily integrate with

other systems, and to work well together with other systems that DanPilot deem relevant

to their business and domain.

The Supplier must describe how the System architecture supports integrations with other

systems, and the process for integrating the System with other systems.

Comment: DanPilot prefers a system that uses standard interfaces, and open standards for

integrating with other systems.

Requirement#2.1.4: Architecture – Handling loss of network connectivity (CHANGED)

Category: Requirement Type: Non-functional

Description: The Enterprise Instant Mesaging part of the System must be robust against loss of

network connectivity, and must ensure that:

• An Actor can compose and send messages when there is no network connectivity

• All messages written by an Actor are sent immediately, when network

connectivity is restored.

• All messages sent to an Actor are received immediately, when network

connectivity is restored.

• No transactions or data are lost due to interruption of network connectivity

The Supplier must describe:

• How it is possible for an Actor to compose and send messages, when there is no

network connectivity.

• How the System ensures, that all unsent messages are sent when network

connectitivy is restored.

81

Usability

The System contains a user interface. This interface must be designed so that it supports the requirements

of the users of the System, and must ensure an enjoyable user experience, where users are able to solve all

relevant tasks effectively.

Requirement#2.1.5: Architecture – User Experience


Description: The System should have a single user interface with a consistent user experience

throughout the user interface.

The user experience should be designed around the domain and context in which users in

DanPilot work, and should effectively assist the users in solving all tasks relevant to their

work.

The users experience must be intuitive for the users and must be easy to navigate and

use.

The Supplier must describe how the System ensures this.

Comment: DanPilot prefers a System with a user friendly interface, and with a high degree of

consistency in the interface.

Requirement#2.1.6: Architecture – Process For User Involvement


Description: The vendor should document their process for involving users in the design of all parts of

the user interface and user experience.

Comment: DanPilot prefers the system with the user experience that is most oriented towards the

domain DanPilot operates in.

System Develepment And Maintenance

The standards and technologies used to build the System affect the expected lifetime and ease of

maintenance of the system. DanPilot requires a System that is easy to extend, maintain, and operate, and

which is based on modern and proven technologies that can be expected to be supported and relevant

during the lifetime of the system.

• How the System receives all pending messages when network connectivity is

restored.

• The measures and mechanisms that ensure, that no transactions or data are lost

due to interruption of network connectivity.

Comment: Enterprise Instant Messaging refers to the mobile part of the solution

82

Requirement#2.1.7: Use Of Standard Software


Description: If standard software exists that is capable of meeting all or parts of the requirements for

the system, the use of standard software is preferred over custom developed code.

The Supplier must describe which parts of the System are based on standard software,

and which parts of the System are based on custom developed code.

Comment:

Requirement#2.1.8: Use Of Modern And Proven Technologies


Description: The System must be built using standards and technologies that are modern and proven.

The Supplier must describe all relevant standards and technologies the System is based

on.

Comment:

Requirement#2.1.9: Code Examples For Integrating With The System (CHANGED)


Description: The Supplier must provide code examples that demonstrate how to integrate with all

services offered by the System.

The code examples should cover all common use cases for integrating with the services

provided by the System, including supporting sample data.

Code examples must be provided in c# as a Visual Studio solution that can compile

without requiring any additional steps.

The code examples must be pre-configured to work with the test environment. The Supplier must describe all code examples that will be delivered as part of the System, and how the delivered code examples cover all common use cases.

Comment: Danpilot prefers a system to which internal IT resources can build integrations

Requirement#2.1.10: Maintenance Of Code Examples (CHANGED)


Description: The code examples must be maintained so that they always support the current released

version of the System in the test-environment.

83

The Supplier must describe how the code examples will be maintained and versioned to

ensure that they always support the current released version of the System during the

contract period.

Comment:

84

2.2 Integration This chapter describes the integrations that must be provided by the System.

Existing Integration Points

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

solution is described in detail in Appendix 3.1.Q MPDS - Integrations.

Name Business goals Involved Solution Provider(s)

SeaWeb To get up-to-date ship data for the ships that we provide DanPilot’s pilotage services to, so DanPilot 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.

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.

Pilot messaging function and ”Elektronisk Lodsseddel” (ELS)

To send messages, including orders to the assigned pilots (smartphones and tablets running SafePilot). Enables the pilot to report an order completed.

Messaging function in System, and “Elektronisk Lodsseddel” (ELS) by Trelleborg, Sweden (formerly ”Marimatech” in Århus, Denmark)

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 DanPilot’s largest customers for the Regional segment.

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

Navision 2009 To be able to send completed orders to invoicing.

CGI is DanPilots current partner with respect to Dynamics Navision.

Roster Planning Function PDC To get current roster planning data for employees from new roster planning function or DanPilot’s current roster planning System (PDC).

Roster Planning Function or PDC (Prolog Development Center) in Brøndby, Denmark.

DataWarehouse / BI To provide DanPilots users with relevant, up-to-date data, reports and KPI’s, based on data coming from e.g. the System.

”Kapacity” in Denmark has assisted DanPilot a great deal with the setup and maintenance of DanPilot’s current BI solution. In-house Data Manager is the daily responsible here.

85

Name Business goals Involved Solution Provider(s)

HR System The integration must ensure that master data about employees in the HR system is automatically used to maintain master data about employees in the System.

MindKey, The Solution is under implementation

Order Service (API) The System must provide an API that can be used to created new orders in the System, and change existing orders before they are started.

Telephone System The System must provide an integration to the Telephone System Zyling to provide SMS/click-to-dial functionality within the System

Zylinc

Table 1. List of the integrations required by the System.

Requirement#2.2.1: Integration with SeaWeb


Description: The System must implement an integration to SeaWeb or similar service, as described in

Appendix 3.1.Q MPDS – Integrations in section “Fejl! Henvisningskilde ikke fundet.”


Comment:

Requirement#2.2.2: Integration with Gatehouse


Description: The System must implement an integration to Gatehouse, as described in Appendix 3.1.Q

MPDS – Integrations in section “Fejl! Henvisningskilde ikke fundet.”.


Comment:

Requirement#2.2.3: Integration with current pilot messaging function (ELS/FEDD)


Description: The System must implement an integration to the information regarding Elektronisk

Lodsseddel/FEDD, as described in Appendix 3.1.Q MPDS – Integrations in section “Fejl!

Henvisningskilde ikke fundet.”.

86

The integration must enable the System to receive updates to order details directly from

the pilot, during execution of the order such as “pilotage started”, ”ETA destination

updated” etc.

The integration must also enable the System to receive all relevant details about the

completed order, including changes to the route, comments, and signature from the

captain.


Comment:

Requirement#2.2.4: Integration with Gatship


Description: The System must implement an integration to Gatship, as described in Appendix 3.1.Q

MPDS – Integrations in section “Fejl! Henvisningskilde ikke fundet.”


Comment:

Requirement#2.2.5: Integration with Roster Planning Function PDC


Description: The System must implement an integration to PDC , as described in Appendix 3.1.Q

DanPilot- MPDS – Integrations section “Fejl! Henvisningskilde ikke fundet.”.

The System must send actual time spent for pilots to PDC for measuring and tracking

overtime.


Comment:

Requirement#2.2.6: Integration with Navision version 2009


Description: The System must implement an integration to Navision, as described in Appendix 3.1.Q

MPDS – Integrations in section “Fejl! Henvisningskilde ikke fundet.”

The integration must ensure that ship- and route data is automatically maintained in

Navision by the System, and provide near-real-time order completion process between

the System and Navision.

87


Comment:

DanPilot is in the process of performing an upgrade to it’s existing Navision system. DanPilot expects that

this upgrade will be completed during the implementation of the System. As such, the System must but

support integrating with the existing version of DanPilot’s Navision system, as well as the new version,

where integration is done differently.

Requirement#2.2.7: Integration with Navision version DynamicsNavision 2017


Description: The System must integrate with Navision version DynamicsNavision 2017 providing the

same business functionality as in Requirement#2.2.6


Comment:

Requirement#2.2.8: Integration with HR system


Description: The System must implement an integration with the HR system MindKey as described in

Appendix 3.1.Q MPDS – Integrations in section ” Integration: HR System MindKey”

When a new employee is create in the HR system, the System must ensure, that the

employee is also created in the system.

When an employee is terminated in the HR system, the System must ensure that the

employee is disabled in the System.

When master data about an existing employee is changed in the HR system, the System

must ensure that this change is synchronized.

The System must enuser that master data changes in the HR system are reflected in near

real time in the System.

User master data in the HR system includes e.g.:

- Full name

- Home address

- Phone numbers (landline, cell phone, etc.)

Se table 2 below for master data in in the System.

Pilot certificates (Please refer to datafields requirements in table 1)

88

The System must ensure that all additional, relevant user data is replicated. This includes:

- Illness (hours/days)

- Right to vacation (hours/days)

- Already held vacation (hours/days)


Comment:

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.9: Integration with Dataware House


89

Description: The System must implement an integration to Dataware House, as described in Appendix

3.1.Q MPDS – Integrations in section “Fejl! Henvisningskilde ikke fundet.”.


Comment:

Requirement#2.2.10: Order Service (API)


Description: The System must provide an order service API that can be used to created new orders in

the System, and change existing orders before they are started.

The order service must allow orders for all routes serviced by DanPilot, and must at least

include the same functionality as currently exist in the Gatship service (see section “Fejl!

Henvisningskilde ikke fundet.”) .

The order service must be designed to be called by external parties over the Internet, and

must be designed to support multiple external parties.


Comment:

Requirement#2.2.11: Integration with Zylinc phone system / Ozeki SMS System


Description: The System must provide an integration with Zylinc phone system as described in

Appendix 3.1.Q MPDS – Integrations in section “Integration: Telephone System Zylinc”

and an integration with the current Ozeki SMS System.

The Supplier can optionally include another SMS system than Ozeki for sending and

receiving SMS messages. In this case the Supplier must include related license and costs

in the proposal.

90

The System must use the integrations for Automated/SMS/click-to-dial functionality

within the System, so that an Actor can click-to-dial e.g. a pilot, and does not have to look

up the phone number in a separate system and dial.

The System must make the click-to-dial function using Zylinc in all user interfaces, from

which it is relevant to dial a contact, e.g. a pilot.

The System must use the SMS Integration so that an Actor can click-to-sms a pilot or

boatman. The System must shown received and sent message as conversations, one

conversation per remote party, and make it possible to delete messages and mark

received message as read/unread.


Comment: The Ozeki SMS system is based a single table in a Microsoft SQL database. In this table

outgoing messages are inserted as a row containing receiving number, message text and

direction (“O” for Outgoing). Incoming messages are written to the same table as sending

number, message text, received date/time and direction (“I” for Incoming).

91

2.3 Security DanPilot has strong security requirements for the system. System availability and the integrity of data in the

System is core to DanPilot’s business. The System is expected to be secure in all aspects of its use and

operation, and to provide the necessary controls to facilitate this.

The System is operated in a heterogeneous environment with internal users running the System on

Windows desktops, external users running the System on laptops, and integrations to external business

partners using web-based API’s. The System must be designed to be secure in all use cases.

Requirement#2.3.1: High Level Of Security And Best Practice


Description: The System must be implemented with a high level of security in all apsects, including

architecture, design, implementation, and access control.

The System must be implemented according to current best practices for protecting it-

systems, and the System implementation and functionality must not prevent DanPilot

from being able to meet ISO 27001 requirements.


Comment:

The use of cryptography and cryptographic security protocols is essential to securing the System. This must

be done in accordance with current best practices, to ensure that the use of cryptography accomplishes the

desired objectives.

Requirement#2.3.2: Use Of Cryptography


Description: Cryptographic algorithms, methods, and protocols used by the System must be publicly

recognized and proven to be currently secure. Employed algorithms and chosen key

lengths must be adequately strong to protect the System, and must be chosen in

accordance with the recommondations by Datatilsynet.

The Supplier must describe how cryptography is used by the System.

Comment:

All data sent to and from the System should be adequately protected against unauthorized access.

Requirement#2.3.3: Protection Of Information During Transport


92

Description: The System must protect all data sent to and from the System using cryptographic

security protocols. For HTTP traffic, the system must use TLS1.0.


Comment:

Requirement#2.3.4: Protection Of Sessions


Description: The System must protect all sessions from unauthorized access and session hijacking.


Comment:

Proper controls concerning users and how they access the System is important to the security of the

System while at the same time having a great user experience in the System, and reducing the amount of

manual maintenance of user accounts that is necessary.

Requirement#2.3.5: User Authentication (CHANGED)


Description: The System must authenticate users using integrated authentication with either Active

Directory or Azure AD.

In case of authentication with Active Directory users accesing the System from a domain

joined Windows computer, and with a domain account, must have single sign on to the

System, and must not be required to enter user credentials to access the System.

In case of authentication with Azure AD, users accessing the system from a Windows

computer with their correct Azure AD associated, must have single sing on to the system,

and must not be required to enter user credentials to access the System.

The supplier must describe which authentication system the System is integrated.

Comment:

Requirement#2.3.6: Describe The User Authentication


Description: Describe how user authentication is supported by the System.

Comment:

93

Requirement#2.3.7: User Authorization


Description: The System must authorize users to perform functions and accesss data in the System.

The user authorization must have a granularity to support separation of duties in all use

cases.

Comment:

Requirement#2.3.8: Describe The User Authorization


Description: Describe how user authorization is supported by the System.

Comment:

Logging is important to be able to troubleshoot issues occurring in the System, and to maintain a revision

history of all changes performed in the System.

Requirement#2.3.9: Logging

Category: Minimum Requirement Type: Non-Functional

Description: The System must log all relevant actions performed by all Actors.

The following actions are considered relevant: authentications, data changing actions,

communication actions (sms, automatic mails, dial-ups, instant messages), configuration

changes, solver requests.

All log events must have a timestamp that specifies when the event occurred, an the

event must include adequate information to support troubleshooting or investigation of

security related incidents.

It must not be possible for users to modify log events. The Supplier must describe how the System ensures this.

Comment: The actor can be a user, an external system or API.

Requirement#2.3.10: Change Logging


Description: The System must maintain an log of all changes performed in the System, including what

was changed, and how it was changed.

94

The change log must provide a complete audit trail of all actions performed in the

System, what data was affected, and how it was affected.

The change log must at least include the following information:

- What user performed a change

- What function was performed by the user

What data that was changed, including the value before the change

Time stamp for when the change was performed

The Supplier must describe the functionality for change logging provided by the System,

and what parts of the data model for the System change logging covers.

Comment:

Requirement#2.3.11: Access to change log in user interface


Description: The System must provide access to the chang log through the user interface.

The user interface must at least show the following:

- What user performed a change

- What function was performed by the user

- What data that was changed, including the value before the change

- Time stamp for when the change was performed


Comment:

Requirement#2.3.12: Access To Log Information


Description: All information logged by the System must be accessible in an open, structured format,

such as a database or a text log file.

All logs created by the System must be accessible in a single, centralized location.


Comment:

Requirement#2.3.13: Adherance to General Data Protection Regulation (CHANGED)

95


Description: The System must satisfy the requirements set forth by the General Data Protection

Regulation that is expected to take effect on May 25th, 2018.

Comment:

2.4 Data Management

This section describes non-functional requirements for the Actors when they use the System. These

requirements are related to user master data including pilot certificates. Several use case depend on these

requirements.

Requirement#2.4.1: Master Data Management


Description: The System must provide a user interface to manage all master data in the system.

The user interface must satisify the usability requirements for the system.

The Supplier must provide mockups or screenshots of the user interface to manage

master data in the System.

Comment:

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


Description: The System must allow external systems to periodically copy all relevant data including,

historical data and logs to an external database.

The periodic copying must not cause any noticeable performance degradation for the

primary Actors.


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.3: Access to data for ad-hoc queries


Description: The System must enable the Actor to:

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

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

96

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.


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.

Requirement#2.4.4: Access to data for ad-hoc queries - description


Description: Describe all methods for access to data including capabilities for ad-hoc queries and

methods for filtering data during access.

The Supplier must provide screenshots of all parts of System that are used for accessing

data and performing ad-hoc queries.

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.

Requirement#2.4.5: Documentation Of Data


Description: The Supplier must as part of the final delivery provide a detailed description of the data

model in the System.

The description of the answer to this requirement must include a sample of a E-R diagram

or similar graphical depiction of the data model.

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

requirement adds to the requirements stated in the K02 appendix

The System will store and process many different types of data related the domain in which DanPilot

operate.

Diagram 1 shows the System and the most significant interfaces to other systems, and the types of data

managed by each system.

• The blue framed boxes denote systems that feed master data to the existing DanPilot Pilotboard

system and which PilotBoard sends orders to. The System is expected to receive master data and

send order data from and to these systems also.

97

• The orange framed boxes denote the master data that is currently maintained in the existing

DanPilot PilotBoard system, and which the System is also expected to maintain.

• The black framed boxes denote production data created, maintained, and managed in Pilotboard,

and which the System is also expected to handle.

• The green filled-in boxes is information regarding roster planning.

• The blue filled-in boxes denote needed mapping tables between the System and external systems.

Requirement#2.4.6: Organisation of data


Description: Describe where different data-types and -mappings as defined in diagram 1 will be

placed and maintained in the System, and how data will flow between the System and

other systems including push, pull and time related to diagram 1.

Comment:

98

Diagram 1

Master data

The 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

Location Data (needed to

map Place of Employment to

Location, which includes other locations)

Ship Data

Boat Station Data (in

progress as addition to

PilotBoard due to hub)

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.

Change Reason Data

BI Access to Resource

Planning Data for analysis

Enterprice Instant

Messaging (i.e.

Salary Calc., vacation time

registrations, Activity

Management

Verification i.e. salary data before final

transfer of payroll system. Employee Ipad App

Boat Station Data

(ie. no. of rooms)

Data

Employee Registration Non “PilotPlan” activities i.e.

project work, which means not

available for Piloting work

Mapping Data

HR System

Employee Data and

Employee Certificate

Data, etc…

External Order User Data

Order Data

Standard Pay Rates incl.

overtime rates / work type

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

99

2.5 Integrations

Please refer to Appendix 3.1.Q DanPilot- MPDS - Integrations

100

3. Non-functional requirements – User Experience:

This section describes the requirements to the user experience, when Actors interact with the System. The

requirements must ensure a user friendly experience when using the System, and a user experience

suitable to the domain in which the System is used.

3.1 General requirements

Requirement#3.1.1: The planning and dispatching functionality must be effective

Category: Minimum Requirement Type: Non-functional

Description: The planning and dispatching functionality must be effective, and must enable the

experienced Actor to carry out frequently occurring processes and tasks in an effective

manner

The System must be as effective as the current planning and dispatching systems, i.e. the

use of the System must not require more Full Time Equivalents (FTE) employees than the

current situation for dispatching (18 FTE) and Roster Planners (2 FTE).

Comment: The Actor is the type Dipatcher and Roster Planner

Requirement#3.1.2: Easy to use


Description: The System must be perceived as user friendly by the Actor, and the Actor must perform

simple functions without reading a manual or online help.

Comment: The Actor is all the types of roles

Requirement#3.1.3: Describe the process for ensuring a user friendly system.


Description: The Supplier must describe their process for ensuring that the System is easy to use by

the Actors.

Comment: The Actor is all the types of roles

Requirement#3.1.4: Examples of User Interfaces (UI)


Description: The Supplier must provide screenshots of some user interfaces used by the Actors in the

System.

101

The screenshots must reference which use cases, as stated in Appendix 3.1.1 DanPilot-

MPDS - Complete set of Use, they relate to. The screenshots must demonstrate how the

Actor is expected to use the system.

The Supplier must provide screenshots of all user interfaces necessary to implement the

use cases supported by the System.

Comment: The Actor is the type Dipatcher,Roster Planner, Pilots and Boatsmen

Requirement#3.1.5: User Interfaces (UI) language


Description: The System must support Danish in all User Interfaces (UI) language in the System

including Enterprise Instant Messaging.


Comment:

Requirement#3.1.6: Responsive design


Description: The System user interfaces that are accessed using a browser, must be based on a

responsive design that scale according to the screensize and resolution supported by the

browser through which the System is accessed by an Actor.


Comment: The Actor is the type Pilot or Boatman

Requirement#3.1.7: Support for common browser versions


Description: The System must always support current versions of common browsers.

Common browsers are defined as Internet Explorer, Microsoft Edge, Mozilla Firefox, and

Google Chrome browser.

Current versions are defined as the most recent version including all minor versions, and

the previous major version including all common versions.

In addition, the System must support the following browser versions:

Microsoft Edge 38.14393.0.0

Microsoft Internet Explorer 10 and 11

102

Mozilla Firefox v51 and v52

Google Chrome v54 and v55

The Supplier must describe what browsers are supported by the System, and how it is

ensured that the System supports the current version of common browsers during the

contract period.


3.2 User interfaces must be adapted according to the Actor (and thereby role)

Requirement#3.2.1: User Friendly Messaging Functionality


Description: The messaging functionality provided by the System, to be used by pilots and boatmen,

must be user friendly and must be usable without requiring any form of user education or

reading manuals.

The Supplier must ensure that the primary users of this functionality are involved in the

design process, and that the users approved the final design.

The Supplier must describe the the design proces that ensures this, and how the results

of the design process are incorporated into the System.


Requirement#3.2.2: Support for Apple iOS


Description: The messaging functionality provided by the System, must be available as an application

that can be installed on Apple iOS devices using the Apple app store.

The application must support the current version of Apple iOS, including all minor

versions, and the previous major version including all minor versions.

The Supplier must make the application must be available to Actors free of charge in the

Apple app store.



Requirement#3.2.3: Support for Google Android

103


Description: The messaging functionality provided by the System, must be available as an application

that can be installed on Google Android devices using the Google Play store.

The application must support the current version of Google Android, including all minor

versions, and the previous major version including all minor versions.

The Supplier must make the application must be available to Actors free of charge in the

Google Play store.



3.3 User involvement

Requirement#3.3.1: User involvement


Description: The Supplier is required to involve the Customer in the adaptation of UI’s and user

friendliness. As part of the first phase after the contract is signed a detailed plan must be

created for this involvement. The involvement must be the Actors described below as a

minimum.



Comment: The Actor is the type Management, Dipatcher,Roster Planner, Pilots and Boatsmen

3.4 Design guidelines

Requirement#3.4.1: User Interfaces Follow DanPilot Design Guidelines


Description: All user interfaces in the System must satisfy the design guidelines provided by the

Customer in Appendix 3.1.T Design manual.



Comment: See Appendix 3.1.T Design manual for DanPilot design guide

104

3.5 Messages and help This section explains the Actors possibility to get help and understandable error messages that will enable

the Actor to resolve problems faster.

Requirement#3.5.1: Online help


Description: The System must contain an online help function, that describes navigation, functions

and user interfaces that are covered in the use cases.


Comment:

Requirement#3.5.2: Error Handling


Description: The System must 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.5.3: Error Messages


Description: The System must 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 must

correct it.


Comment:

Requirement#3.5.4: Feedback on responsetime


Description: The System must show it’s working on an answer wthin responsetime <2 seconds.

The System must show it’s working on an answer wthin responsetime >2 seconds and

must show a statusindicatior on remaining time for response.


Comment:

105

3.6 Technical requiremets regarding the UI

Requirement#3.6.1: Copy and insert


Description: The System must 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.6.2: Successive load of content


Description: The System must be able to successively load 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.6.3: Personalization of UI. (CHANGED)


Description: The Supplier must describe what and how parts of the user interface can be personalized

and include screenshots showing the results of different personalized set-ups. The set-up

can either be based on roles, or individual set-ups per role.


Comment:

Requirement#3.6.4: Support for Danish Localization and Globalization (CHANGED)


Description: The System user interfaces and reports must be available in Danish, and using Danish

localization as well as Danish globalization. This includes all labels, content, online help,

error messages as well as data input and output fields.


106

4. Information Model This chapter provides an overview of the domain, the terms used and how they are related. This provides

an understanding of the domain, and defines the scope of the System in terms of the information model

the System is expected to support.

The information model is split into three parts:

• Orders

• Certificates

• Locations

4.1 Orders Figure 2 below shows the most important order-related data, and how they are logically related.

OrderOrder CustomerCustomer

JobJob

RouteRoute

PilotMarkPilotMark

ShipShip

PlaceOfEmploymentPlaceOfEmployment

ActivityActivity

ActualActivityActualActivity PlannedActivityPlannedActivity

ResourceResource

PilotPilot BoatmanBoatman PilotBoatPilotBoat VehicleVehicle

EmployeeEmployee TransportTransport

2

Figure 2. Overview of the primary domain concepts; the Order-related entities and relationships.

• 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.

• 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. These activities can be referred to as ActualActivities, as shown in the diagram.

Comment:

Legend for the Crow's foot notation used.

107

• 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 up to 12 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 2.

• 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.

Requirement#4.1.1: Support information model for orders


Description: The System must support the information model shown in “Figure 2” and described in

section “4.1 Orders”

The Supplier must describe how the System supports the information model shown in

“Figure 2” and described in section “4.1 Orders”

Comment:

4.2 Certificates The System must 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)

(https://www.retsinformation.dk/Forms/R0710.aspx?id=144126)

Figure 3 below shows how certificates relate to other entities in the domain.

https://www.retsinformation.dk/Forms/R0710.aspx?id=144126

108

Figure 3. The information model for pilot certificates, and how they relate to other significant entities in the domain.

• 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.

Requirement#4.2.1: Support information model for certificates



section “4.2 Certificates”.


“Figure 3” and described in section “4.2 Certificates”.

Comment:

Job

Employee

JobCertificate-Level CertificateLevel

Certificate

Certificate-Category

Certificate-Type

Employee-Certificate

EmployeeCertificate-Level

PilotMark-Certificate

Area-Certificate

Legend for the Crow's

foot notation used.

109

4.3 Locations Figure 4 shows how location relates to other entities in the domain.

Figure 4. Geographical model for capturing the "location" needs in the System.

• 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 services. A Boatman is most often allocated to 1 boatstation,

but there are some which are allocated to more than one.

Job Route RouteArea

PlaceOfEmployment

Boatstation

Area

PilotMarkPilotMark-

Group

2

Activity

Boatman(Resource)

Hub

Legend for the Crow's

foot notation used.

110

• 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.

• The model ensures that the whereabouts of Pilots, Boatmen, Pilot Boats, and company cars is

tracked.

• Job plans take the current/last known location of an Employee into account 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.

Requirement#4.3.1: Support information model for locations



section “4.3 Locations”.


“Figure 4” and described in section “4.3 Locations”.

Comment:

111

5. Business rules

Current Union Agreements (rules) The enclosed union agreements are only available in Danish.

Further instructions to Supplier 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 3.1.W

Boatmen 1 and 2: Union agreements please refer to Appendix 3.1.X

Resting time agreements please refer to Appendix 3.1.Y

State agreements State agreements please refer to Appendix 3.1.Z

Requirement#5.1.1: Union Agreements – Pilots


Description: The System must support the union agreements for pilots described in Appendix 3.1.W

Comment:

Requirement#5.1.2: Union Agreements – Boatmen 1 & 2


Description: The System must support the union/resting agreements for Boatmen 1 & 2 described in

Appendix 3.1.X and Appendix 3.1.Y

Comment:

Requirement#5.1.3: Union Agreements – State agreements


Description: The System must support the agreement for the State described in Appendix 3.1.Z

Comment:

112

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 must 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”?

113

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

Rostering and working hour rules

Rostering

Rules for rostersDispatching

1) Actual demand

2) Rules for workinghours and rest periods

Expected demand

Actual demand and ETA / ETD-notice

114

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

- 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

115

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 must 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, must 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, must 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:

116

- 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.

- Must 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

117

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.

118

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 must 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 must 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 must 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?

119

- 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 must 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

120

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

121

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.

122

Possible changes to working rules for pilots

Introduction Even though agreements between DanPilot and Danske Lodser22 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.

22 The trade union for Danish pilots

123

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.

Every third month rosters for the following three

months are published.

Every month the rosters for the month two 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 standby duties are placed at the

beginning or at the end of a shift.

Standby duties may also be placed inside of a shift.

124

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.

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.

Currently the pilots are allowed to work in up to 13

hours per duty day as they must have at least 11

hours of rest.

The pilots are allowed to work in up to 13 hours

per duty day as they must have at least 11 hours of

rest.

Requirement#5.1.4: Union Agreements – Possible changes for rostering of pilots


Description: The System must be able to support possible changes for rostering of pilots according to

the section above

The System must support the Actor in an easy way of setting up new rules or altering

rules must be done by changing parameters

Comment: The Actor is Administrator or Super User

125


Per year that currently allows the pilot to work in

total up to

13 hours/duty x 153 duties = 1.989 hours

The yearly amount of working hours may not

exceed x hours, where x are less than 1.989 hours.

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.

Krak factor The following is DanPilot's procedure in connection with the so called "Krak-factor"

Requirement#5.1.5: Union Agreements – Possible changes for dispatching of pilots


Description: The System must support the the union agreement’s possible changes for dispatching of

pilots

Comment:

Requirement#5.1.6: Union Agreements – Possible changes overtime remuneration for pilots


Description: The System must support thethe union agreement’s possible changes for overtime

remuneration for pilots

Comment:

126

The Krak-factor only applies for work on R-days, AF-days, FR-days and FE days. It is stated in the instructions for the pilot agreement, pt. 8 at "The working time is accounted for from the time where the pilot leaves his residence and until he arrives home again, while deducting an average calculated transport time between residence and place of employment" This must be understood as; no matter where the pilot is asked to go, when the pilot is on overtime, "the relevant parties personal average calculated transport time between residence and place of employment" will be deducted from the working hours accounted for in each end of a pilotage. Krak-factor = The individuals transport time between residence and place of employment. The Krak-factor is as known applied through Krak, driving. This means that the Krak-factor is not always equals to the actual used travel time. The allowance can never be bigger than the Krak-factor. This means that if more time is used than the Krak-factor, the extra time will be rewarded as overtime. Example: Krak-factor 2 hours. Travel time from residence to place of employment 2 hours. Actual travel time 2 hours minus Krak-factor 2 hours = 0 (no overtime payment) Travel time from residence to place of employment 2 hours. Actual travel time 3 hours minus Krak-factor 2 hours =+1(1 hours of overtime payment) In the VPS the working time is registered, which is accounted for, not the time which have been deducted. Own place of employment: It is possible to be accounted for overtime from own place of employment to own place of employment, if the pilot is physically traveling to and from his place of employment. If the pilot is physically traveling to and from his own place of employment the Krak-factor shall be deducted from the actual travel from residence to unususal place of employment or from unusual place of employment to the residence. At the same time, this means that the payment for the transport between residence and place of employment must always happen at own expense. Example: Residence: Nordsjælland Own place of employment: Nykøbing Falster Pilotage on overtime: Gedser - Korsør The pilot travels by himself to own place of employment and the working hours are registered from Nykøbing Falster to Gedser. No Krak-factor is deducted from Nykøbing Falster to Gedser. At arrival to Korsør it is distinguished between if the pilot is physically traveling to own place of employment in Nykøbing Falster or home to residence in Nordsjælland. At physical travel to own place of employment in Nykøbing Falster, the working time is registered to Nykøbing Falster and no Krak-factor is deducted from this trip. The pilot makes his own way home from own place of employment. If the pilot is physically travelling to residence after the pilotage, the Krak-factor is deducted in relation to the duration of the trip to the residence.

127

In the VPS the working time is registered, which is accounted for, not the time which have been deducted.

Requirement#5.1.7: Krak-factor

Category: Minimum Requirement Type: Non-Functional

Description: The System must support the Krak-factor. The System must support; no matter where the pilot is asked to go, when the pilot is on overtime, "the relevant parties personal average calculated transport time between residence and place of employment" will be deducted from the working hours accounted for in each end of a pilotage. Krak-factor = The individuals transport time between residence and place of employment. The Krak-factor only applies for work on R-days, AF-days, FR-days and FE days.

Comment:

128

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 must 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 must in principle be performed with

change of pilotages.

129

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#5.1.8: SOPs for dispatching


Description: The System must support the above mentioned SOPs number 2.1 to 2.4 for dispatching

including possibility of seeting up future SOPs

Comment:

130

Rules of notice

1. Introduction

DanPilot have the following business term in relation to notice before entering or leving a habour or transit.

2. Rules

Regional inbound to habour 24 hours

Regional outbound from habour 4 hours

Transit: 18 hoursbefore start

Frozen: 18 hours regional inbound to habour

Frozen: 1 hours regional outbound from habour

Transit: 18 hours frozen

Requirement#5.1.9: Rules of notice


Description: The System must support the above mentioned Rules of notice

Comment:

Documents

Requirements Specification Appendix 3.1 Maritime Planning … 3.1 Danpilot- MPDS... · Non functional requirements ... • Boatmen: Like Pilots they will use the 2 way user interfaces