Standard for the development of electronic logbook client applications (Version 6.0) - July 2022

PDF Version (721 KB)

1. Introduction

Subsection 61(3) of the Fisheries Act authorizes DFO to impose terms and conditions of any licence issued under this Act to require that fish harvesters keep a log of their catches and their fishing efforts and submit them to DFO. To date, fish harvesters have generally reported this information using paper documents.

This Department of Fisheries and Oceans (DFO) document specifies the requirements for the development of electronic logbook (ELOG) client applications. The ELOG client application will enable fish harvesters and service providers to enter and transmit information about catches and efforts of the fish harvester to DFO using XML electronic files.

ELOG client applications will be developed in two phases:

Phase 1: The purpose of the first phase is to make ELOG client applications available for use by fish harvesters directly. They will enter logbook data themselves and transmit data to DFO. The data will never be manually altered by the service provider. The data transmitted to DFO shall accurately represent what was entered by the fish harvester, even if an automatic or manual conversion took place. In phase 1, fish harvesters will be the only users of ELOG client applications.

Phase 2: The purpose of the second phase is to evaluate the possibility of integrating data provided via a service provider that had been instructed by fish harvesters to input, verify or correct their data. In phase 2, fish harvesters and service providers would both be e-logs users. Phase 2 will be carried out at a later date.

This standard therefore defines the characteristics, processes and best practices to be taken into account during the development of electronic logbook client applications.  This standard is intended to be used as a base document for the development of an ELOG applications qualification process.  This standard was developed with support from the Canadian General Standards Board (CGSB).

The standards document is being continually developed and revised as needed to clarify and/or to add new requirements that address a need in the development of ELOG client applications.

2. Standards Principles

The following guiding principles apply to this standard:

2.1 Affordability

It is essential that electronic logbooks applications be cost effective for all stakeholders involved in Canadian fisheries. Meeting the requirements of the standard should not create undue financial pressure on stakeholders. This principle should apply to all stakeholders involved in the DFO national electronic logbooks system, that is, fish harvesters, service providers, ELOG client application developers, and DFO.

2.2 Innovation

The standard should be developed to allow for innovation. Stakeholders should retain their innovative abilities when developing electronic logbooks applications. The standard should be developed to clearly identify the needs of DFO and stakeholders, without excessively limiting ways of meeting those needs.

2.3 Flexibility

The standard should be developed so as to present options which will make it possible to adapt the electronic logbooks applications to the diverse realities of the Canadian fisheries. The standard should meet the technical, socio-economic, practical, and scientific needs of all the Canadian fisheries.

2.4 Integrity

The standard should be developed to ensure that data integrity is maintained at all times throughout the data capture, storage, processing and transmission processes.

The standard should be developed to ensure that ELOG applications accurately record the data, and that the data transmitted from the fish harvester to DFO is an accurate representation of what was declared by the fish harvester, even if a data conversion or a file conversion took place.

The standard should be developed to ensure that the client application will not prevent users from submitting relevant information to DFO: ELOG client applications should allow users to declare, for example, all species caught by fish harvesters, without limiting the number of species that they can declare.

2.5 Security

The standard should be developed to ensure the security of information transmitted through the ELOG client application. The information transmitted is sensitive; hence, it is critical that all effort be made to ensure that no prejudice is caused to any stakeholders due to data loss or inappropriate access to data.

3. Electronic Logbook System XML Structure

Electronic logbook data shall be transmitted to the DFO national electronic logbook system using only XML files.  An alternate data format, however, can be used to transfer data between the fish harvester and an external infrastructure not owned by DFO. This infrastructure shall have to convert data received to an XML file and shall have to send this XML file to the DFO national electronic logbook system.

To maintain a certain uniformity in the manner of reporting between DFO regions and the different fisheries, all XML files shall be structured in a consistent manner.  The “hierarchy” of nodes making up XML files shall thus be the same for all XML files containing logbook data, regardless of the region or type of fishery.

Description for diagram: JBE Structure XML

3.1 XML nodes

In the diagram “ELOG – XML Structure” above, the nodes are represented by rectangles.

A node is a cluster of data elements, and can be linked to zero, one, or many child nodes.  When a child node is present in an XML file, all parent nodes of the child node must be present in the XML file.

For each type of fishery, each DFO region has identified the nodes and data elements that comprise its logbook.  It is possible that, within the same fishery, a node is part of a logbook for one region but not another.

3.2 Data elements

Generally, a data element is the smallest piece of information contained in an XML file.  Data elements contain information provided by the fish harvester (e.g., vessel registration number, soak time and departure date).

Each data element belongs to a specific node. 

Empty elements shall be omitted from XML files.

Units of measurement have been standardized for XML files as follows:

• dates and times shall be represented in UTC
• duration shall be represented in minutes
• positions using standard WSG84 shall be represented in degrees and decimals (carried out to four decimal places) 
• weights, lengths and volumes shall be represented in SI units.

The ELOG client application may allow to capture the value of a data element in a unit of measure that is different from the one required for the XML file, but, the value of this element, when registered in the XML file, must obligatorily be represented using the unit of measure identified in the XML data dictionary for that element.

3.3 Data dictionary

All data elements making up the electronic logbook have been defined in a data dictionary.  This dictionary describes in detail each data element (description, type, maximum length, value list, format, decimal placement, node membership, unit, etc.).  The data dictionary is available upon request in Comma separated Values (CSV) and .DOC file formats - both are available in English and French versions.  These documents will eventually be available on the DFO extranet site.

The ELOG client application should ensure that limits identified in the data dictionary are not exceeded during entry. For example, depths must be between 0 and 4,500 m.

Under certain circumstances, the fact sheets may define even stricter limits for valid data element values.

3.4 Forms

A form is a collection of nodes and data elements that make up a logbook. Each type of fishing gear has a corresponding form for each region.

The form indicates whether the data elements it contains are required or optional.

The list of elements making up a node may vary depending on the region, the type of fishery, and form version.

For each region, type of fishing gear and form version, a data element may be:

1. Required: Information in a data element that is “required” SHALL be entered by the user if the node to which the element belongs is used. If the node is being used, the ELOG client application SHALL ensure that the user provides a value for this element. For example, if the user wants to enter a “hail in,” he/she will use the HLIN node and must complete at least “required” elements of this node.
   If the node corresponding to the element is not used, the user does not have to enter this required information.
   This element must be available on the entry screen.
2. Optional: Information in a data element that is “optional” MAY be entered, but not doing so will not generate an error message.
   This element must be available on the entry screen.
   This element may become required under certain circumstances. Those cases will be documented in the fact sheets and/or licence conditions, as applicable.

Only the "optional" or "required" elements of a regional form may be included in the corresponding XML files.

Within the ELOG client application, all “optional” or “required” elements on the form must have the capability to be entered (or modified) and confirmed by the user.  However, this rule does not apply for data elements identified in Appendix B: Data elements the user cannot modify.

Following the specifications for the form will generally ensure that the XML file will be accepted by DFO and that it will successfully pass DFO’s validation process.

Except in cases of necessity (e.g. new policies, exceptional needs, problems, etc.), DFO will limit the number of changes made to forms (XML structure) as much as possible to minimize the impact on fish harvesters, service providers and client application developers.

The form names which presently exist are as follows:

• ELOG - Logbook - Barrel
• ELOG - Logbook - Dive (Pacific)
• ELOG - Logbook - Dive (except Pacific)
• ELOG - Logbook - Dredges
• ELOG - Logbook - Gillnet (salmon - Pacific region)
• ELOG - Logbook - Gillnets
• ELOG - Logbook - Handline, rod and reel, tended line
• ELOG - Logbook - Harpoon, hakapik, club, fire arm
• ELOG - Logbook - Longline
• ELOG - Logbook - Manual harvest
• ELOG - Logbook - Pots (except lobster)
• ELOG - Logbook - Seine, gillnet (surf smelt - Pacific region - annual report)
• ELOG - Logbook - Seines
• ELOG - Logbook - Trap (lobster)*
• ELOG - Logbook - Trap net, Fyke net
• ELOG - Logbook – Trawls*
• ELOG - Logbook - Troll, seine (salmon - Pacific region)
• ELOG - Logbook - Various gears (arctic char - C&A region)
• ELOG - Marine mammals sighting log

* Currently in use in pilot project

The details of the forms are available upon request and will be available in the near future on the DFO extranet website in CSV file format.

3.5 XSD

There is an XSD (XML Schema Definition) file for each version of the form enabling approximate validation of the XML file structure.  The XSD validation shall be limited to verifying that nodes and elements are in accordance with expectations, the type of data for each element is respected, certain value limits are respected, and the element registry order in the XML file is acceptable.

The ELOG client application must verify that the XML files that it generates adhere to specifications issued by XSD before transmitting the XML file to DFO.  A rejection produced by this validation should prevent transmission of the XML file to DFO.

XSD files are available upon request and will be available eventually on the DFO extranet site.

3.6 Data Groups

Logbook information can be transmitted using more than one XML file. Certain rules, however, shall be followed during XML file creation.  Some blocks of information cannot be broken up.  The XML structure has therefore been divided into various data groups which, when transmitted, must be complete and final.  This means that no information group will be retransmitted in order to add or change information in that group.

Description for diagram: Elog - XML Structure groups

When a node is present in an XML file, all parent nodes, up through the ELOG node, must also be present.

3.7 XML File Names

Example: 1006-8521-20150603221030.XML

3.8 Character Sets

XML files shall be generated using UTF-8 character sets. French accents must be correctly supported.

4. Data Recording

ELOG client application used by fish harvesters shall be able to store data entered by fish harvesters even if no external communication link is operational.

5. Data group closure

Data group closure is the process through which a fish harvester checks a data group’s information and confirms that it is complete and final and that it can be transmitted to DFO.

Data groups are identified in section 3.6 “Data groups”

Data groups that require a closure option will be identified in the fact sheet for each form.

For certain fleets, licence conditions may require certain parts of the logbook to be completed prior to docking.  In those cases, the ELOG client application shall allow users who are fish harvesters to close data groups for the parts of the logbook that must be completed prior to docking.

If changes to data in a closed data group are required, the user shall communicate directly with DFO to submit a change request.  The ELOG client application shall never automatically transmit a change made to a previously closed data group.

If required for that form, the date and time (UTC) that the data group was closed shall be indicated in the main node for that data group in the XML file.

5.1 Operating rules related to data group closure

1. A data group shall be closed only once.
2. The ELOG application shall enable users to view all the information of a data group that will be closed before they confirm the closure of the data group.
3. Possible data group’s  status are limited to:
4. Open: Data group has not been closed.
   Closed: Data group was successfully closed, but has not been transmitted to DFO.
   Transmitted: Data group was closed and successfully transmitted to DFO.
   Modified: Data group has been modified after its successful transmission to DFO. Update made to an “Open” data group will not trigger a change of status to “Modified”.
5. A data group’s status may only change from “Open” to “Closed”, from “Closed” to “Transmitted” and from “Transmitted” to “Modified”.
6. The ELOG client application shall mandatorily allow the user to modify the data of a data group while the status of the data group is “Open”.
7. The ELOG client application shall mandatorily prohibit the modification of the data of a data group while the status of the data group is “Closed”.
8. The ELOG client application may optionally allow the user to modify the data of a data group when the status of the data group is “Transmitted” or “Modified”.  The ELOG client application copyright holder will determine if their ELOG client software will allow the user to modify the local data of a data group having the status “Transmitted”.  DFO does not require the ELOG client application to allow modification of the data of a data group having the status “Transmitted”
9. If the user modifies the data of a data group after it was successfully transmitted to DFO, the status of the data group shall become “Modified” instead of “Transmitted”. The data of a data group having the status “Modified” shall never be transmitted to DFO using the application.  The user will have to contact DFO to request a correction of the data transmitted.  (See section 14 “Correction of transmitted data”)
10. The status of the data group shall be displayed and easily viewable.
11. Data group closure shall be possible even if there are no operational external communication links.

Appendix A shows diagrams illustrating how the data group closure process should work. These diagrams are shown to gain a better understanding of the data group closure process and the transmission of the closed data groups.

5.2 Data verification

At the data verification stage, the data shall be displayed using the same units of measurement that were used during data entry. The unit of measure used for the data verification may be different from the one specified in the XML data dictionary. However, the value written in the XML file shall be represented using the unit of measure specified in the XML data dictionary.

At the verification stage, it shall be possible for the user to view ALL data in the data group (and its parent group) before this data group is closed.

6. Default Values

Default values for certain data elements can be used in the ELOG client application. 

When default values are used, these values must be viewed, modified and confirmed by the user.  This rule does not apply to data elements identified in Appendix B: Data elements the user cannot modify.

Other than the data elements identified in Appendix B, no logbook data element shall be generated automatically without the user having the opportunity to confirm the logbook data element.

7. Generating a unique logbook identifier

The ELOG client application must generate a new logbook unique identifier as soon a new logbook is created.

The unique logbook identifier shall consist of a random set of six uppercase alphabetic characters from A to Z.  The logbook unique identifier shall always have six characters (e.g., ARJHYE).

The unique logbook identifier shall be generated randomly by the ELOG client application and entered into the LGBK_UID element of the TRIP node in the XML file.

The ELOG client application shall be tested by developers to confirm that no duplicates are produced during the generation of 50 000 logbook unique identifiers.

The identifier will be used to match documents from other sources (e.g., weighout summary, purchase slips, hails) to the logbook.  The logbook unique identifier shall therefore be easy for the fish harvester to locate.

8. Language and Accessibility

The development of applications is obligated to be in both official languages: English and French.

* See section 20 “Technical Support” in this document for technical support language requirements. 

* See section 21 “User’s Guide” in this document for user guide language requirements.  

Applications ideally should be made accessible to all persons including, but not limited to, persons with visual, auditory, and cognitive disabilities. Below are accessibility guidelines for developers to consider when building their applications: 

1. Plain language – it is recommended that all written information be provided in short sentences, using an active voice with everyday words that avoid technical jargon.  

2. Digitally Accessible – it is recommended that websites and applications be designed to be visually friendly and accessible. To enhance digital accessibility, developers may consider the following guidelines:  
• Visual accessibility – enabling  the use of screen readers, braille displays, zoom functions, high contrasts, etc. The use of style galleries provided by most word programs can help screen readers to navigate information;
• Auditory accessibility – including captions and transcripts;
• Cognitive accessibility – use of layouts that are highly organized and visually friendly. Fields included in forms should be clearly labelled; and 

For further information on guidelines for promoting accessibility of digital resources, please visit the following resource provided by Accessibility Standards Canada.

9. Logbook verification

ELOG client application users who are fish harvesters, or persons authorized by fish harvesters, shall be able to view at least all the data included in the two last logbooks created, regardless of whether they have been transmitted, and even if a communication link is not available. Any requirements to keep more logbooks available for verification (e.g., NAFO requirement) will be specified in the applicable fact sheet.

10. Interference

Interference consists of issues related to physical or software application compatibility with its environment.  Equipment required by the ELOG client application shall not interfere with vessel equipment. It shall not alter the functioning or stop the operation of the vessel or vessel equipment (e.g. GPS).

The ELOG client application must be designed to function in diverse physical, geographic and climactic conditions. Availability of the cellular coverage across the area to be served, adverse weather conditions, cloud cover, little or no cabin space, etc., are some examples. Some known constraints might be identified in the fact sheet.  These constraints shall have to be taken in account during the development of the ELOG client application.

11. Coordinates (latitude/longitude)

The ELOG client application shall allow each coordinate (latitude and longitude) to be entered manually.

Enabling the ELOG client application to read a coordinate directly from a GPS, although recommended, is optional. The ELOG client application may or may not include this functionality.

11.1 Manual entry

For all coordinates, the ELOG client application shall allow the user to type a value for latitude and longitude manually. The user shall be able to record a value for the two elements making up each coordinate (i.e., latitude and longitude).

Manual modification of coordinates by the user shall still be possible even if coordinates were initialized from a GPS.

11.2 Reading the GPS

Coordinates shall be read from a GPS only if the user is a fish harvester.

The ELOG client application may, in addition, include the capability to read the coordinate directly from a GPS after an action is performed by the fish harvester (e.g. the fish harvester presses a coordinate reading button). If this capability is included, the values returned by the GPS shall be automatically recorded in the appropriate fields by the ELOG client application. The ELOG client application shall have the capability to modify these fields manually by the fish harvester.

11.3 Attribute describing mode used

For each XML file element representing a coordinate, an XML attribute (MODE=«M» or MODE=«G») shall be juxtaposed with the XML element to indicate the mode used by the user to assign a value to the coordinate:

For example:

When a manual change is made to one of the coordinate’s elements, its mode becomes ‘M’ to indicate that this entry was modified manually.

When a coordinate is initialized from the GPS, its mode becomes ‘G’ to indicate that this entry was initialized from a GPS.

12. Start of trip

12.1 Data group verification

Section 12.1 applies for all users except service providers.

Users shall be required to close data groups for the previous trip before creating a new trip, but shall not be required to transmit their data to DFO before creating a new trip.

Before a new trip is created, the ELOG client application shall verify that the previous trip data groups are all closed. If this is not the case, an error message shall alert the user.

Before a new trip is created, the ELOG client application shall verify that the previous trip data groups were all transmitted to DFO. If this is not the case, a warning message shall alert the user. The ELOG client application shall never prohibit the creation of a new trip.

12.2 Basic information verification

When creating a new trip, users shall be able to verify and confirm that the basic information they use is accurate. This includes:

• Captain’s name
• Fisher Identification Number of the licence holder(FIN)
• Vessel registration number (VRN)
• Licence number
• Current date and time

13. Data Transmission

The data transmission process consists of securely transferring user logbook data to DFO and ensuring the transfer is successful. This function shall update the fish harvester’s register of transmissions. (See Section 13.3 “Transmission register”)

Electronic logbook data shall be transmitted to the DFO national electronic logbook system using only XML files. An alternate data format, however, can be used to transfer data between the fish harvester and an external infrastructure not owned by DFO. This infrastructure shall have to convert data received to an XML file and shall have to send this XML file to the DFO national electronic logbook system. (See Section 13.7 "Using a data format other than XML")

An electronic copy of each XML file shall be archived after it is successfully transmitted to DFO. (See Section 13.4 "Archives of XML files")

XML files shall be transmitted to DFO using a DFO web service available 24/7. More details about Web service will be available upon request to DFO.

The ELOG client application shall have an option for repeating a transmission that was not completed successfully. For example, if no operational communication link is available when the user is ready to transmit data, if the Web service does not respond or if it returns a transmission error message.

If a form includes a section for daily reports (i.e., the DAILY_REPORT node), the ELOG client application shall provide the option to transmit the "daily report" portion of the logbook only. Consequently, only the ELOG, TRIP, DAILY_REPORT, DR_GRP and DR_DETAIL nodes shall be included in this kind of transmission.

13.1 Obtaining an ELOG key

Before transmitting data to DFO for the first time, fish harvesters, or service providers, shall first identify themselves to DFO as an electronic logbook user and then create and configure their ELOG key.

Service providers shall be issued only one ELOG key to be used by all their employees.

To obtain an ELOG key:

1. The fish harvester, or the service provider, shall access the DFO website (/index-eng.htm, Fisheries tab, Commercial Fishing sub-menu, select the Electronic Logbook option). During this process, the fish harvester will have to identify himself/herself to DFO.
2. The fish harvester, or the service provider, will have to create an ELOG key by using options available on the DFO Internet site. The ELOG key will then be displayed on the screen.
3. The fish harvester’s, or the service provider’s, ELOG key shall be manually copied into his/her ELOG client application.

ELOG keys ensure that fish harvester, or service provider, have to authenticate themselves only once. The ELOG client application shall include the ELOG key within each data transmission to DFO. (see section “13.2 Web service”) 

The ELOG client application shall be able to securely store the ELOG key. When recorded in the ELOG client application, the ELOG key shall not be visible to the user anymore.

The ELOG key shall be replaceable in the application. If needed, a fish harvester, or service provider, may generate a new ELOG key through DFO’s web site. Therefore, the ELOG client application shall have the capability to replace the one recorded previously.

DFO shall automatically deactivate keys that have not been used in over one year.

13.2 Web Service

The ELOG client application will use a Web service when transmitting logbook data to DFO.

This Web service will use a secure HTTPS (Hypertext Transfer Protocol Secure) connection through which a SOAP envelope will transit. In addition to the XML file, the SOAP envelope shall include the ELOG key and the file name.

In order to reduce the amount of information transferred, the XML file can first be compressed using the 7-Zip utility. If compressed, the file name extension shall be .7z instead of .XML.

When a file will be received by the Web service, the Web service shall validate the SOAP envelope contents to ensure that the sender is indeed authorized to send ELOG files and that the contents are as expected: either an ELOG XML file or a compressed ELOG XML file. Some supplementary validations shall also be carried out by the Web service at this point.

If an error is detected, a message is returned by the Web service in an XML file containing the confirmation number of the transmission and an error code. No other information shall be returned. Messages corresponding to the error codes shall be made available by DFO to the developers for inclusion in their applications. 

If no error is detected, an XML file containing the following information shall be returned in response: confirmation number, error code, vessel number, fish harvester ID number (FIN) and the unique logbook identifier. Error code will be WS0000 if no error found by the Web service.

The application shall decode and communicate clearly the response received from the Web service to the user (i.e., success or failure).

13.3 Transmission register

The ELOG client application shall record the result of each transmission attempt in a transmission register. There are two types of transmission register: Transmission register for transmissions that use the Web service of DFO and Transmission register for transmissions that do not use the Web service of DFO.

13.3.1 Transmission register for transmissions that use the Web service of DFO

This type of register shall be used if the information is sent directly to DFO, thus, if the transmission is using immediately the Web service of DFO, e.g., direct transmission from the workstation to DFO without passing through an external infrastructure or in the case of a transmission from an external infrastructure to DFO.

The ELOG client application shall record the result of each transmission attempt that uses the Web service of DFO, in this type of register.

The register shall include at least:

• Transmission confirmation number
• Date and time of transmission attempt (UTC)
• Name of file transmitted
• Transmission status (“Fail” or “Success”)
• Error message (if applicable)
• Logbook unique identifier
• Trip number
• Vessel number
• XSD validation result (“Fail” or “Success”)

This information shall be stored by the ELOG client application so that it can be readily viewed by the user. Information concerning transmission failures shall also be stored in this registry by the ELOG client application.

Information in this type of transmission register shall be archived and remain accessible up to three years following the transmission attempt. The transmission register archives may be resident either on the application workstation or on a remote device.

13.3.2 Transmission register for transmissions that do not use the Web service of DFO

This type of register shall be used if the information transmitted from the workstation is not sent directly to DFO, thus, if the transmission is not immediately using the Web service of DFO.

Although the transmission to DFO is always done using the Web service of DFO, it remains possible that a transmission made from a workstation will have to pass through an external infrastructure before the data is retransmitted to DFO by the external infrastructure. As the transmission made from the workstation to the external infrastructure will not involve the Web service of DFO, the information returned by the Web service will be unavailable at the time of the transmission. In this case, the result of the transmission between the workstation and the external infrastructure shall be stored in the “Transmission register for transmissions that do not use the Web service of DFO” and the result of the transmission between the external infrastructure and DFO shall be stored in the “Transmission register for transmissions that use the Web service of DFO”.

If the Web service of DFO is not used directly during the transmission, the ELOG client application shall record the result of each transmission attempt in this type of register.

The register shall include at least:

• Date and time of transmission attempt (UTC)
• Transmission status (“Fail” or “Success”)
• Error message (if applicable)
• Logbook unique identifier
• Trip number
• Vessel number

Information concerning transmission failures shall also be stored in this registry by the ELOG client application.

Information in this type of transmission register shall remain accessible up to thirty days following the transmission attempt. No archiving of the results of transmissions attempts older than thirty days is required in this type of register.

13.3.3 Consultation of transmissions made during the last thirty days

The ELOG client application shall allow the user to display the results of the transmission attempts made during the previous thirty days based upon either one of these registries, even if a communication link is not available.

13.4 Archives of XML files

Archiving XML files consists of saving an electronic copy of the XML file after it is successfully transmitted to DFO. XML files shall never be updated or deleted by anyone or by any software for a period of three years after they have been archived.

In the event of a court case, these files may be required for verification of data transmitted by users.

Modification and destruction of archived XML files shall be prohibited for three years following transmission. After that time, archived XML files may be permanently deleted.

The archived XML files may be resident either on the application workstation or on a remote device.

Diagram in Section A-1.3 shows the archiving of XML files during the “transmission process”.

13.5 Transmission Frequency

The requirements regarding transmission frequency can vary depending on DFO’s needs or the limits imposed by technology in some regions (e.g., area with insufficient coverage regarding telecommunication, geomorphology, etc.). Needs in terms of transmission frequency will be stated in the fact sheets and fish harvester's licence conditions associated with their fishery.

The application shall meet the requirements imposed by the applicable fact sheets and licence conditions.
The same group of data (see Section 3.6 “Data Group”) shall only be transmitted once.

13.6 Transmission time

There shall be no unnecessary delays once the user has initiated the transmission process. DFO shall receive the data as soon as possible, barring any technological issues (e.g., communication link unavailable, bad communication link, broken equipment, electrical failure or Web services unavailable).

Use of an external infrastructure shall not cause lag time, i.e., delay prior to transmission to DFO, during which data is not processed.

13.7 Use of a data format other than XML

To minimize costs and/or improve data transmission performance, DFO shall authorize the use of a data format other than XML for transmitting data between the user and an infrastructure outside of DFO. If this alternative is chosen, the ELOG client application shall include a data conversion module to create XML files to be transmitted to DFO.

After the conversion, the resulting XML file must fully represent what was originally declared by the fish harvester. The data conversion module shall never create information not provided by the fish harvester, barring information identified in appendix B; interpret data that could give another meaning to the information provided by the fish harvester; or increase the precision of the information provided by the fish harvester.

The ELOG client application copyright holder shall be responsible for the development and maintenance of the data conversion module.

14. Correction of transmitted data

The ELOG client application shall never retransmit a data group that has already been transmitted with success to DFO (nor a copy of this data group containing the modifications).

When modification of a data belonging to a data group that has already been transmitted occurs, the ELOG client application shall advise the user that they must contact DFO to request a change to their data. Corrections in the DFO database will be made by DFO staff.

15. ELOG client application update

The ELOG client application and its components shall be updatable.

When code tables are modified at DFO, these changes shall be replicated in the ELOG client application. Update of client application code tables shall be done by the client application, and these updates shall not require approval from either DFO or the designated authority.

When the XSD files are modified by DFO, these changes shall be replicated in the client application. Update of client application XSD files shall be done by the client application, and these updates shall not require approval from either DFO or the designated authority.

A new version number shall be assigned to each release of the ELOG client application that is submitted for qualification (or migrated to production if no qualification of the new version is required).

The number of ELOG client application updates is not limited; however, new versions shall be issued sparingly, especially at the height of fishing season.

When a new version of a form becomes available, DFO will establish an expiration date for the older version(s) of the form. DFO will not accept files submitted that are based on expired versions of the form.

16. ELOG client application qualification

Qualification will consist of verification, by DFO, that an ELOG client application complies with this standard. Details of the qualification process will be described in a separate document.

A copy of or access to the ELOG client application shall be available free of charge upon request of DFO, in order to verify the application.

If the ELOG client application is partially or totally centralized on an external server, a test environment shall be configured and available to DFO.

17. Instructions

ELOG client application shall come with supplier instructions. Instructions shall be kept in a document separate from the user guide.

The ELOG client application copyright holder is responsible for producing this (these) document(s).

Supplier instructions are intended for users of ELOG client applications. The instructions detail how to complete the logbook as per DFO's directions. Licence conditions shall refer to these instructions as needed. The instructions may be presented in different formats (e.g., in document format or as help functions). However, the user must always be able to access the instructions even without access to the Internet.

The ELOG client application copyright holder must be able to provide supplier instructions in the same languages as those available in their application(s).

18. Fact sheets

Fact sheets provide ELOG client application developers with relevant information.

There is one fact sheet for each version of a form. Information in fact sheets includes but is not limited to certain operational rules specific to the form or to fleets that use the form.

The ELOG client application shall comply with operational rules set out in the fact sheet that corresponds to the version of the form being used.

Fact sheets will be available on the DFO extranet website.

19. Security

Security affects many aspects, but generally, the ELOG client application shall ensure implementation of the necessary infrastructure for protecting the data processed therein.

Electronic logbook data transmitted through the ELOG client application is confidential and subject to the provisions of the applicable federal and provincial legislation. As such, electronic logbook data must be protected from unauthorized disclosure or access by any party other than DFO or the fish harvester from whom it originated. Disclosure of or access to electronic logbook data by parties other than the fish harvester from whom it originated requires written approval from both the fish harvester and DFO.

Exception: Access to electronic logbook data is permitted where it is required by a person in charge of technical support or a person under his or her direction for the purpose of troubleshooting and resolving hardware and/or software issues related to the ELOG client application.

19.1 Application security

ELOG client application access shall be protected by a password or any other recognized means that would restrict usage only to the fish harvester or any person(s) the fish harvester has authorized to provide technical support. This restricted access must be managed by the application itself. Authentication through the operating system is not sufficient.

The ELOG key stored in the client application shall not be visible to anyone after it has been saved. It shall be possible to replace it by a new one but it shall never be accessible for viewing.

The transmission of sensitive or protected information shall take place via a secure link (e.g., HTTPS).

During satellite transmission between the vessel and the terrestrial infrastructure, encryption of some specific data elements is authorized instead of using a secured link. Elements that will have to be encrypted will be identified in the XML data dictionary.

19.2 Data security

Logbook data access shall be protected by a password or any other recognized means that would restrict access only to the fish harvester or any person(s) the fish harvester has authorized to provide technical support.

The data chain of custody shall be foolproof. For court cases, the copyright holder of the ELOG client application shall be able to explain how it works, especially concerning the management of the data. This would include the data converter, if applicable.

20. Technical Support

The ELOG client application copyright holder shall be able to provide technical support in the same language(s) as those available in the ELOG client application. Technical support shall include product installation and product use support.

In case of application problems (bugs), the ELOG client application copyright holder shall make corrections to the ELOG client application as quickly as possible. Depending on the severity of the problem, DFO may contact the copyright holder and set a deadline for the correction to be made.

The technician shall be the only person authorized to manipulate the content of electronic logbook application folders (add data, modify data, copy data or delete data) directly from the operating system or from a third party software, but always with the agreement of the user.

21. User’s Guide

Section 21 "User's Guide" applies for all users except service providers.

The ELOG client application shall have a user’s guide explaining the various features of the ELOG client application as well as the different steps for creating an electronic logbook and transmitting it to DFO.

The ELOG client application copyright holder shall be able to provide a user’s guide for its application in the same languages as those available in its application.

22. Authenticity and integrity

Data received by DFO must fully represent what has been entered by the user. By submitting a letter of interest for the development of an ELOG client application, the copyright holder agrees (if called upon to do so for court purposes and at no charge), to provide evidence, that describes how the application works and how it is known the information submitted to DFO through the use of the application accurately reflects what was declared by the user. 

This evidence may be given through the testimony of a witness in court or may take the form of an affidavit that complies with the provisions of the Canada Evidence Act or other relevant statutes.  The copyright holder shall also be able to give a detailed explanation of any transformation or alteration of data from the closure of data group to the transmission of this data group to DFO. This would include the data converter, if applicable.

23. Privacy notice statement and Harvester Attestation

Section 23 "Privacy notice statement and Harvester Attestation" applies for all users except service providers.

The privacy notice statement and harvester attestation can be found in Appendix C: Privacy notice statement and Harvester Attestation.

The ELOG client application will display the privacy notice statement and the harvester attestation when the application is launched. The application will prompt the user to confirm that they have read and understood this information. A harvester cannot proceed beyond this screen without a positive confirmation. Following this confirmation, the client application shall display a "Do not show this message again" option.  If the user checks the "Do not show this message again" checkbox, the ELOG client application shall no longer display the message when the application is launched.

If the privacy notice statement is updated at a later date, the new statement shall be displayed, once again with the "Do not show this message again" option.

24. Prerequisites

ELOG client application installation and/or usage prerequisites shall be clearly defined. The prerequisites describe the minimum hardware and application environment that the application needs in order to work properly.

25. Recommendations for ELOG client application developers

The following recommendations will not form part of the client application qualification. However, these will require careful consideration during development of ELOG client applications.

Compact code tables: Some code tables are huge. Users should be able to limit the content per their needs when configuring their ELOG client application. For instance, a port table contains about 4,000 fishing ports while fish harvesters generally use less than three. It would thus be helpful to limit the list of items to those they frequently use. Conversely, users should always be able to add items to their personalized list from the complete one. Fishing zones, species, fishing gear and community tables are good examples of this.

ELOG client application – Software architecture: The software architecture of the ELOG client application should be clearly defined at the early stage of development to ensure that various constraints associated with the functioning of the system are taken in account. For instance, fish harvesters should be able to input logbook data at all times, and conversely, they might not necessarily have an operational external communication link during fishing trips. Another example is the ease with which an update will be deployed or the way data groups will be closed.

As language requirements may vary by region, and over time, it is recommended that application developers design their applications so that they can easily be adapted for French and/or English clienteles.

Elog client application – Physical architecture: The physical architecture should also be clearly defined at the early stage of development. Fishing vessels are not all equipped with an ideal location for computer hardware; some fishing vessels do not even have a closed cabin for shelter from adverse weather.
Certain potential problems should also be taken in account—for instance, equipment malfunction (GPS, Internet connectivity, printers, secure copy materials, etc.).

Profiles (default values): Users should be able to configure their ELOG client application to define several values which they will use by default. Users should, however, always be able to change a value that has been initialized by a default value.

Demo (trial module): The ELOG client application should have a trial component enabling the user to try the application before using it under realistic conditions. Trial data should never be stored with real data.

Units of measurement: The Elog client application may offer the possibility of entering data using a unit different from the one specified in the data dictionary. For instance, some users are more familiar with imperial units than metric ones. The client application may provide the option of entering data in pounds, but, all weights written in the XML file shall be recorded in kilograms. Moreover, dates/times of XML files shall be recorded in UTC (Coordinated Universal Time) in the XML file, but the application could offer the option of capturing date and time as local dates/times.

If a data element is captured by the fish harvester using a different unit than the one defined in the data dictionary, it is very important that the representation of the data in the XML file be represented using the unit of measure identified in the data dictionary.

Data backup: Backup/restore option should be implemented to prevent data loss due to application or hardware malfunction (e.g. technical problems, theft, fire, loss of the vessel, etc.).

Extractions: The ELOG client application could generate some data extractions (e.g. a summary of data entered, a transmission report, etc.).

ELOG client application update: If the update requires a local installation at the user’s workstation, the installation program should be available over the Internet. The ELOG client application should notify the user when a new version of the application is available, and the user should then be able to authorize proceeding with the installation of the update.

Coordinate Validation: Experience shows that GPS systems sometimes return erroneous values. Inserting an algorithm to verify positions returned by the GPS could validate the accuracy of the values returned. For example, instead of reading one coordinate, the application could generate three readings and assess the three results in comparison with the others. 

For example:

Coordinate Validation:

• Coordinates shall be situated within the limits defined in the data dictionary, and if outside of them, the coordinates are invalid.
• GPS readings shall return longitude AND latitude; if they do not, the coordinates are invalid.
• GPS readings shall not return errors; if one is detected (e.g. GPS not activated), the coordinate is invalid.
• If the coordinate is further than one minute from the coordinates previously read among the three readings, the coordinate is invalid.

The three coordinates returned shall be valid (according to the rules stated above).

• If all three positions are valid, only the first will be retained and used to complete the coordinate requested (latitude and longitude).
• If at least one of the three positions is invalid, an error message will be displayed and no readings will be saved.

This method is an example of a validation process that enables minimum validation of the quality of the coordinates returned by the GPS.

26. Glossary

Code tables: Series of codes used by the ELOG client application. Most of the time, a code table will include many columns and many rows. Each row contains a unique identifier (the code) and some columns that refer to an attribute of the code (e.g. a French description, an English description, etc.). Example of code tables: Table of species, Table of gear types, Table of communities, Tables of regions, etc.

Data dictionary: Dictionary that contains a detailed description of each data element used in XML files of electronic logbooks.

Data element: Information component requested by DFO.

Data group: Indivisible data set formed by merging one or more XML nodes. (See Section 3.6 "Data Groups")

Developer: Person or group of persons who create or modify ELOG client applications.

Electronic logbook: Logbook completed by use of specialized software.

ELOG client application: Complete group of software and hardware used for the capture, the processing, the storage and the transmission to DFO of electronic logbook data. The client application includes all intermediary infrastructure not held by DFO and used by the ELOG client application.

ELOG client application copyright holder: Person or legal entity that owns the ELOG client application.

ELOG client application qualification: Process for verifying the compliance of a specific version of an ELOG client application with the requested specifications. Fish harvesters using a non-qualified client application will not be authorized to transmit their data to DFO.

Error message: Message informing the user of the ELOG client application that a specific situation has been detected. After a message of this type is displayed, the process in progress will be stopped.

Fact sheet: Technical document provided to ELOG client application developers. The document sets out certain operational rules that must be followed when developing ELOG client applications for each E-log form. The fact sheet consists of a list of general rules for a given form, and more specific rules for the fleets that use that form.

Fish harvester’s local database: Database (or part of a database) not owned by DFO and used to save information provided by the fish harvester.

Fishery: Harvesting of specific species using specific gear in a specific area.

Fleet: All the fish harvesters participating in a fishery.

Form: XML file structure to be used to transfer electronic logbook data to DFO. Forms contain the list of XML nodes and data elements required by a region for a certain fishing gear type.

Initialization: Attributing a value to a datum.

Instructions: Explanations provided by the ELOG client application copyright holders for users of their software. These instructions specify how to complete the electronic logbook as per DFO's directions.

Logbook: Record that DFO requires fish harvesters to keep and that describes the activities carried out during a fishing trip.

Paper logbook: Hard-copy version of a logbook in which the requested information was or will be entered by hand.

Region: DFO administrative region. These are:

Service provider: Company whose infrastructure houses certain (or all) components of an ELOG client application qualified by DFO. The fish harvester instructs this company to complete certain tasks, such as logbook data reception and/or entry, data verification, data conversion, and data transmission to DFO. The company acts as an intermediary between the fish harvester and DFO.

Standard: A set of technical specifications. It is developed by seeking a consensus building among interested stakeholders (e.g. fish harvester’s associations, DFO representatives, Software developers, etc.).

Technical support: Person or company commissioned by the fish harvester or service provider to help users resolve ELOG client application installation and/or operating issues.

User: Person who enters logbook information. This may be fish harvesters themselves or persons they have authorized to enter logbook data on their behalf (e.g., an acquaintance or service provider). In phase 1, fish harvesters will be the only users of ELOG client applications. In phase 2, fish harvesters and service providers will both be users.

User’s Guide: Document for users of an ELOG client application that explains how the application works.

Warning message: Information message for the user. These messages bring a specific situation to the user’s attention. After a message of this type is displayed, the process in progress will not be stopped.

Appendix A: Data group closure (informative)

A.1 Diagrams – General information

Diagrams of Appendix A are only shown to help understand the closure process and the transmission process.

In the following diagrams:

1. The diagram reads from top to bottom.
2. The pink background colour indicates that a response from the user is required.
3. The blue background colour indicates an automated process.
4. The green background colour indicates the user’s intention.
5. Messages in blue are information messages for the user.
6. Messages in red are error messages informing users that an operation they wanted to perform terminated abnormally.
7. Blue circles indicate the start and end of a process.
8. Data groups include all data elements that are part of this group.
9. Pseudo-XMLs are temporary XML files that contain only the data group itself and its parents. These pseudo-XMLs are used only to test the validity of an XML file generated from a data group in comparison with XSD.

Description for diagram: Process of creation or modification of a data group vs data group status

Description for diagram: Process of destruction of a data group vs data group status

Description for diagram: Transmission process for closed data groups

Appendix B: Data elements the user cannot modify

The data elements in the table below cannot be modified by the user.

Appendix C: Text of the privacy notice and harvester attestation

PRIVACY NOTICE STATEMENT

The information you provide through the electronic logbook client application is collected under the authority of the Fisheries Act and the Fishery (General) Regulations for the purpose of administering the commercial fisheries under DFO’s jurisdiction. The information may be used for compliance review, program planning or management, reporting, safety or security purposes, audit, evaluation, statistical, research, policy development, administration or enforcement of a law, the detection, prevention, or suppression of crime, and investigative purposes.  You have the right to the correction of, access to, and protection of your personal information under the Privacy Act and to file a complaint with the Privacy Commissioner of Canada over DFO’s handling of your information. Personal information collected through the e-log application is described in the Personal Information Bank (PIB) DFO PPU 410.  For more information, visit Info Source.

By submitting this electronic logbook to DFO, I attest to the following:

I declare I am the license holder or substitute operator appointed for the license provided in this electronic logbook. I attest that the information given is true, accurate and complete. I understand that the information I am providing to DFO is being collected as part of license conditions issued under the authority of the Fisheries (General) Regulations (SOR/93-53). I understand that making a false or misleading statement, whether orally or in writing, is a violation of the Fisheries Act (R.S.C., 1985, c. F-14)