HBS Technical Specifications for Industrypublish/...VB CRC32 example code Sierra Systems 2003-05-16 4.0 Added Special Forest Products to descriptions for Piece Scale requirements

P R I C I N G B R A N C H

HBS Technical Specifications for Industry

Version 6.0 March 1, 2010

This manual is intended for the use of individuals or companies when conducting business with the British Columbia Government.

Permission is granted to reproduce it for such purposes. This manual and related documentation and publications, are protected under the They may not be reproduced for sale or for other purposes without the express

written permission of the Province of British Columbia.

Federal Copyright Act.

Revision History Date Version Description Author

2001-09-21 1.0 First Draft Sierra Systems

2002-03-05 1.1 Revised to include references to HBS Phase 2B – Appendix B: Submitted Scale Document Composition.

Sierra Systems

2002-03-08

1.2 Incorporated feedback from Scale Software Vendors

Sierra Systems

2002-05-08 1.3 Added - check digit for Authentication key - Report Specifications - Formatted Description for Defects - final VB and C CRC32 routines - process diagrams for formatting and submission processes

Removed - XML examples

Sierra Systems

2002-05-17

1.4 Added - compression definition for DDN - new version of Report Specifications - new terminology

Modified - Scenarios => Event Type - Refined / eliminated text based on reviews

Sierra Systems

2002-05-24 2.0 - Modified compression definition for DDN - Refined and eliminated text based on reviews

Sierra Systems

March 1, 2010 i

HBS Technical Specifications for Industry Ministry of Forests and Range

Date Version Description Author

2002-06-20 2.9 Additions - Dimension Reduction defect format (s 5.2) - Standard for HBS XML filename (s 7.3)

Errors - Fixed example in s 5.1 describing how to construct a DDN for a log tally. The example was incorrectly including an extra day in the day count presented.

Sierra Systems

2002-07-30 3.0 Added The list of Defect codes in Appendix G is now a standard that is expected to be across the province.

Enhanced VB CRC32 example code

Sierra Systems

2003-05-16 4.0 Added Special Forest Products to descriptions for Piece Scale requirements.

Sierra Systems

2008-06-11 5.0 Modified Table 5-1 to clarify DDN# definitions for weigh slips and log tallies, regarding time of scale , as well as a new section on ST vs DT for scale times.

Doug Gold - MFR

2008-06-13 5.1 Updated format, same content. Tyler Waters – MFR

ii March 1, 2010

Pricing Branch Revision History

Date Version Description Author

2010-03-01 6.0 Updated to reflect current scale data and system integrity requirements.

Some of the high level changes are as follows: - Authentication key must not be shared or

saved. - Mandatory data must be populated during

collection of data. - Document version number must start with

Version 1. - DDN is a 13 character field. - The first document version of every scale

return must be digitally signed by the scaler and submitted in HBS.

- Added Appendix M – Ministry Design Standards – Version Number Scheme.

- Added Appendix N – Scale Data Controls and Processing Conventions (was Chapter 7C of the Scaling Manual).

- Added Appendix O – definition of BOS Sampling algorithm.

Saunder Thom/C. Lidstone - MFR

March 1, 2010 iii


This page is intentionally left blank.

iv March 1, 2010

Pricing Branch Table of Contents

Table of Contents

1 Introduction

1.1 Background......................................................................................................... 1-1 1.2 Purpose................................................................................................................ 1-1

2 Drivers for Change

2.1 Business Environment Drivers ........................................................................... 2-2

3 HBS Scale Data Processes

3.1 Scale Document Submission Process ................................................................. 3-2 3.2 Corrections.......................................................................................................... 3-3 3.3 HBS Document Types ........................................................................................ 3-4

3.3.1 Weight Slip ................................................................................................ 3-6 3.3.2 Log Tally.................................................................................................... 3-9 3.3.3 Special Forest Products Log Tally........................................................... 3-13 3.3.4 Ledger Record.......................................................................................... 3-16

4 Scale Measurement Processing Changes

4.1 Definitions of Values Required to Enable Electronic Scale Data Capture......... 4-2 4.1.1 Detail Document Number .......................................................................... 4-2 4.1.2 Document Version ..................................................................................... 4-5 4.1.3 Hash Total.................................................................................................. 4-6

4.1.3.1 Hash Total Algorithm ....................................................................... 4-6 4.1.3.2 Hash Total Domain ........................................................................... 4-7

4.1.4 Digital Signature ........................................................................................ 4-7 4.1.4.1 Authentication Key ........................................................................... 4-7 4.1.4.2 Signing Scaler Licence ..................................................................... 4-9 4.1.4.3 Authentication Key Encrypted Hash Total ..................................... 4-10 4.1.4.4 Encryption Algorithm ..................................................................... 4-11

4.2 Other Definitions .............................................................................................. 4-12 4.2.1 Defect Record - Formatted Defect Measurement Description ................ 4-12

4.3 Edit Session....................................................................................................... 4-14 4.3.1 Edit Session on Existing Scale Returns – by Scaler ................................ 4-14 4.3.2 Edit Session on Existing Scale Return– by Industry Site

Administrator ........................................................................................... 4-14

March 1, 2010 i


5 Business Process Issues

5.1 Verifying Completeness of Data Submissions ................................................... 5-2 5.1.1 Control Sequence Summary ...................................................................... 5-2

5.1.1.1 Piece Scale ........................................................................................ 5-2 5.1.1.2 Weight Scale ..................................................................................... 5-3

5.2 Submission of Electronic Originals of Scale Data.............................................. 5-4 5.3 Administrative Document Processing Changes.................................................. 5-5

6 Scale Data Submission

6.1 File Transfers using Extended Markup Language (XML) ................................. 6-2 6.1.1 XML Definition ......................................................................................... 6-2 6.1.2 XML Schema Definitions .......................................................................... 6-3

6.2 HBS Scale Data Collection and Submission Process Overview ........................ 6-4 6.2.1 Scaler Submits Data Directly to the HBS.................................................. 6-5 6.2.2 Responsible Party Submits Data to HBS................................................... 6-6 6.2.3 Responsible Party Submits Data Formatted by Scale Site Software ......... 6-7 6.2.4 Responsible Party Submits Data Formatted by Industry Business

System........................................................................................................ 6-8 6.2.5 Industry Business System Formats and Submits Data in Batch ................ 6-9 6.2.6 Weight Scale Measurement Records ....................................................... 6-10 6.2.7 Log Parcel Tally Measurement Records (Including SFP) ....................... 6-11 6.2.8 Scale Site Events are Ledgered................................................................ 6-12 6.2.9 Scale Activity Ledgers are Collected into HBS....................................... 6-13

6.3 Transmission File Naming Standards ............................................................... 6-14 6.4 Scale Data Submission Mechanisms ................................................................ 6-17

6.4.1 HTTPS via Authenticated Login ............................................................. 6-17 6.4.2 FTP via IP Filtering ................................................................................. 6-17

7 Printed Scale Documentation

7.1 Weight Scale ....................................................................................................... 7-3 7.1.1 Safety Sheet ............................................................................................... 7-3

7.1.1.1 Print Expectations ............................................................................. 7-3 7.1.1.2 Submission and Retention Expectations........................................... 7-3

7.1.2 Weigh Slip ................................................................................................. 7-3 7.1.2.1 Print Expectations ............................................................................. 7-3 7.1.2.2 Submission and Retention Expectations........................................... 7-4

7.1.3 Daily Audit Log ......................................................................................... 7-4 7.1.3.1 Print Expectations ............................................................................. 7-4 7.1.3.2 Submission Expectations .................................................................. 7-4

7.2 Piece Scale .......................................................................................................... 7-5 7.2.1 Species Grade Summary Report ................................................................ 7-5

ii March 1, 2010


7.2.1.1 Print Expectations ............................................................................. 7-5 7.2.1.2 Submission and Retention Expectations........................................... 7-5

7.2.2 Log Tally.................................................................................................... 7-5 7.2.2.1 Print Expectations ............................................................................. 7-5 7.2.2.2 Submission and Retention Expectations........................................... 7-6

7.2.3 Daily Load Listing ..................................................................................... 7-6 7.2.3.1 Print Expectations ............................................................................. 7-6 7.2.3.2 Submission Expectations .................................................................. 7-6

7.3 Back Up Requirements ....................................................................................... 7-7 7.3.1 Electronic Back Up.................................................................................... 7-7

7.3.1.1 Re-submission and Print Expectations.............................................. 7-7 7.3.1.2 Retention Requirements.................................................................... 7-7

7.3.2 Paper Back Up ........................................................................................... 7-7 7.3.2.1 Resubmission Expectations .............................................................. 7-7 7.3.2.2 Retention Requirements.................................................................... 7-7

8 Scale Site Software

8.1 Policy for Scale Site Software ............................................................................ 8-2 8.2 Scale Software Vendor Approval Process .......................................................... 8-3

Appendices

Appendix A What is XML?..................................................................................... A-2 Appendix B Public Key Cryptography and Digital Signatures ............................... A-4 Appendix C VBA Authentication Key Check Digit Generation ............................. A-6 Appendix D VBA Integer to Base 36 Conversion................................................... A-7 Appendix E VB CRC32 Algorithm ......................................................................... A-8 Appendix F C CRC32 Algorithm .......................................................................... A-10 Appendix G Standard Defect Codes ...................................................................... A-13 Appendix H Multiple Scale Station Numbers for Weight Scale ........................... A-14 Appendix I Issue Addendum ................................................................................. A-15 Appendix J Validating XML Structure Using an XML Schema Processor .......... A-17 Appendix K Example Printed Scale Documentation............................................. A-21 Appendix L Version Numbering Scheme.............................................................. A-22 Appendix M Version Numbering Scheme............................................................. A-25 Appendix N Scale Data Controls and Processing Conventions............................. A-28 Appendix O BOS Sampling Algorithm ................................................................. A-60

March 1, 2010 iii


List of Figures

Figure 4.1 Process Diagram for Constructing Hash Total and AKEHT....................... 4-11 Figure 6.1 Scale Data Submission Process. .................................................................... 6-4 Figure 6.2 Process Diagram for when a Scaler Submits Data to HBS. .......................... 6-5 Figure 6.3 Process Diagram for when a Responsible Party Submits Data to HBS ........ 6-6 Figure 6.4 Process Diagram for when a Responsible Party Submits Data

Formatted by Scale Site Software.................................................................. 6-7 Figure 6.5 Responsible Party Submits Data Formatted by Industry Business System... 6-8 Figure 6.6 Process Diagram for when an Industry Business System Formats and

Submits Data in Batch Process ...................................................................... 6-9 Figure 6.7 Weigh Scale Measurement Records Process Diagram................................ 6-10 Figure 6.8 Log Parcel Tally Measurement Records Process Diagram ......................... 6-11 Figure 6.9 Process Diagram Showing the Scale Site Events being Ledgered. ............. 6-12 Figure 6.10 Process Diagram Showing Scale Activity Ledgers Collected into HBS... 6-13 Figure A.1 Open File Dialogue of XML Spy. ............................................................. A-18 Figure A.2 Assign Schema Dialogue of XML Spy. .................................................... A-18 Figure A.3 Tool-tip Showing the “Check well-formedness” function of XML Spy... A-19 Figure A.4 Tool-tip showing the “Validate File” function of XML Spy..................... A-19 Figure A.5 enter fig name here. ................................................................................... A-20 Figure A.6 Weigh Slip Example. ................................................................................. A-21 Figure A.7 Weigh Scale Safety Sheet Example........................................................... A-21 Figure A.8 Weight Scale Daily Audit Log Example. .................................................. A-21 Figure A.9 Log Tally Example – Piece Scale.............................................................. A-22 Figure A.10 Log Tally Example – Sample Scale (with Defects)(Page 1). .................. A-23 Figure A.11 Log Tally Example – Sample Scale (with Defects)(Page 2). .................. A-23 Figure A.12 Piece Scale Species Grade Summary Report. ......................................... A-24 Figure A.13 Piece Scale Daily Load Listing. .............................................................. A-24 Figure A.14 Version Numbering Scheme (Page 1). .................................................... A-25 Figure A.15 Numbering Scheme (Page 2)................................................................... A-26 Figure A.16 Self Assessment Questionnaire/Report (cover page). ............................. A-42 Figure A.17 Self Assessment Questionnaire/Report (page 17). .................................. A-54

iv March 1, 2010


List of Tables

Table 3.1 Event and XML Document Types by Document Type. ................................. 3-4 Table 3-2 Weigh Slip Measurement Record Event Types.............................................. 3-6 Table 3-3 Log Parcel Tally Measurement Header Event Types..................................... 3-9 Table 3-4 Log Parcel Tally Measurement Types.......................................................... 3-11 Table 3-5 Special Forest Products Tally Header Event Types. .................................... 3-13 Table 3-6 Special Forest Products Tally Measurement Types. .................................... 3-14 Table 3-7 Ledger Event Types...................................................................................... 3-16 Table 4.1 DDN Definition. ............................................................................................. 4-2 Table 4.2 Examples of DDN Construction. .................................................................... 4-4 Table 4.3 Check Digit Test Data and Returning Values................................................. 4-8 Table 4.4 Defect Measurement Description String Construction Scenarios ................ 4-12 Table 4.5 Defect Measurement Description Examples................................................. 4-13 Table 6-1 Required Events for Successfully Providing Data to HBS ............................ 6-4 Table 6-2 Events When Scaler Submits Data Directly to HBS. ..................................... 6-5 Table 6-3 Events When Responsible Party Submits Data to HBS. ................................ 6-6 Table 6-4 Events When a Responsible Party Submits Data Formatted by

Scale Site Software. ....................................................................................... 6-7 Table 6-5 Events When a Responsible Party Submits Data Formatted by

Industry Business System .............................................................................. 6-8 Table 6-6 Events When an Industry Business System Formats and Submits

Data in Batch Process. ................................................................................... 6-9 Table 6.7 Transmission File Naming Convention ........................................................ 6-15 Table 6.8 Transmission File Name Examples .............................................................. 6-16 Table 7-1 Paper Reports Defined for Weight Scale Sites............................................... 7-2 Table 7-2 Paper Reports Defined for Piece Scale Sites. ................................................. 7-2 Table 7-3 Additional Print Expectations for the Log Tally Report. ............................... 7-6

March 1, 2010 v



vi March 1, 2010

Introduction 1

March 1, 2010 1-1


1.1 Background

The Ministry of Forests and Range has been managing crown forests in British Columbia for the better part of a century. During this time, timber processing companies have arranged with the ministry to purchase timber from crown owned stands. From an invoicing perspective, measurement and reporting methods have evolved.

A new system, called the Harvest Billing System (HBS), was implemented in a phased approach. The functionality described in this document was available early in 2003. The vision of the Ministry of Forests and Range was to have a process where original scale site data could be collected electronically from the source computer systems via the Internet. This has eliminated significant overhead for both licensees and the ministry as labour intensive paper submission and verification processes has been largely eliminated.

1.2 Purpose

The purpose of this document is to outline, for software service providers to the forest industry, the processes performed by systems deployed at scale sites as well as systems changes necessary for submitting timber measurement or scale data to the HBS.

This document is to be used in conjunction with HBS Phase 2B - Appendix B: Submitted Scale Document Composition where more detail is supplied around documents and field definitions.

1-2 March 1, 2010

Drivers for Change 2

March 1, 2010 2-1


2.1 Business Environment Drivers

Greater public scrutiny of ministry business processes

● The ministry is under increasing public pressure to improve its regulatory environment and to conduct business in a more efficient manner.

Greater Number of Stakeholders

● The ministry has been encouraging smaller business participation in harvesting activities via small business programs and there are now more transfers of timber between forest product companies.

● All stakeholders rely on the official Ministry of Forests and Range authorized scale measurements as the basis for timber transfer transactions. The ministry has a responsibility to make the definition of measurement rules and the collection of measurement data as clear and as concise as possible.

Revenue Risk

● The current business process surrounding stumpage revenue collection, implemented in the HBS, had been recognized by several Auditor General reports to have deficiencies.

2-2 March 1, 2010

HBS Scale Data Processes 3 These general requirements exist for scale data submission:

● Completeness of Data Submissions: all applicable scale documents must be submitted to HBS.

● Original Documentation: the original document, signed by the scaler, is Version 1 and must be submitted to HBS.

● Scale Site Activity: the ministry must have an accurate record of all activities in which the ministry has an interest, that occur at a scale site. This includes providing an accounting to the ministry for void and stock scale documents.

Because measurement data is being collected electronically, and because the Internet enables data collection and data entry from any PC with a modem, the HBS is built to accept electronic versions of original scale measurements. This process will allow paper submissions to eventually be phased out.

The ministry requires that either signed copies of printed original scale returns or electronic copies of digitally signed original (described in section 4.1.4) scale returns must be retained by industry as the official backup documents.

March 1, 2010 3-1


3.1 Scale Document Submission Process

The HBS is capable of collecting original scale data (as approved by the scaler) and all subsequent corrections for all scale returns. Electronic scale submissions is formatted using Extended Markup Language (XML).

The first document version (Version 1) of every scale return must be digitally signed by the scaler and submitted in HBS.

3-2 March 1, 2010

Pricing Branch Proposed Scale Data Processes

3.2 Corrections

The responsibility for correcting scale information follows business practices in the forest industry (refer to section 4.3). Industry Site Administrators will consult with the scaler and do one of the following:

● Correct the scale return in HBS using data correction screens provided on the internet, or

● Correct the scale data in Industry Business Systems to be able to provide the data to the HBS and export the corrected data to the HBS in electronic form. Correction submissions must always be higher versions of the original scale returns. All versions must be stored in the IBS for auditing purposes. The latest corrected version of scale documentation will supersede previous document versions in the HBS.

Ministry staff will approve all post invoicing corrections. Pre invoicing corrections provided by industry will not require approval.

March 1, 2010 3-3


3.3 HBS Document Types

There are several document types submitted to the HBS in electronic form. These include Weigh Slips, Log Tallies (Piece Scales and Samples), Summary Scales (including Cruised Based) and Ledger Records.

Each document is used in multiple scenarios, which have been described as Event Types. Each Event Type is defined by having a slightly different set of identifying data fields (the field lists and their assignments to Event Types is described in the document HBS Phase 2B - Appendix B Submitted Scale Document Composition).

That document contains the specification for the HBS:

● Document Field Definitions (Size and Format)

● Document Event Types and associated field inclusion or exclusion.

● Document Event Types and associated with Hash Total Domain specification.

● XML Document Types and assignments of Document Event Types to XML Document Types

Each Event Type is assigned to an XML Document Type for the purpose of formatting data for the HBS.

Table 3.1 Event and XML Document Types by Document Type.

Document Type XML Document Type Event Type

Weight Slip WSB – Weight Slip Billable PS) Primary Scale

SS) Sample Scale

RS) Remote Sample

PD) Primary Departure

WSR – Weigh Slip Red Tag RT) Red Tag

RR) Remote Red Tag

WSO – Weigh Slip Other 4R) SB4 Rescale

DP) Departure

CU) Company Use

3-4 March 1, 2010


Document Type XML Document Type Event Type

Log Tally PPS – Piece Scale PS) Primary Scale

FD) From Site Deck

RT) Red Tag

RR) Remote Red Tag

CS) Piece Check Scale

PSS – Sample Scale SS) Sample Scale

RS) Remote Sample

CS) Sample Check Scale

POT – Other Tallies 4R) SB4 – Rescale

CU) Company Use

Special Forest Products Log Tally

SFP – Special Forest Products

PS) Primary Scale

CS) Piece Check Scale

Ledger Record ARL – Arrival Ledger PS) Primary Scale

B4) Scaled Before

4R) SB4 – Rescale

TD) To Site Deck

FD) From Site Deck

RS) Remote Sample

RR) Remote Red Tag

DPL – Departure Ledger DP) Departure

March 1, 2010 3-5


3.3.1 Weight Slip

Table 3-2 Weigh Slip Measurement Record Event Types

Sequence

Assigned to Document Type

Event Type Code

Event Type Name

Previous Description

Description

A WSB - Weigh Slip Billable

PS Primary Scale

Arrival from Harvest Area (Stratifiable – Not Sampled)

This is the default case: All timber that is harvested must have a Timbermark and must be reported to the ministry. This timber was stratifiable and was not selected for a sample.

This includes Cash Sale and Cruise Based marks. These must be submitted as a full returns and the HBS will NOT invoice these returns using the Timbermark’s attribute from the FTA system

Field Scale: If the Field Scale Flag is set to Y, the timber was previously billed on a field scale. The HBS will exclude this scale return from billing.

B WSB - Weigh Slip Billable

SS Sample Scale

Arrival from Harvest Area (Stratifiable – Sampled at this Site)

As PS above, plus:

The HBS requires a sample scale tally for this load to arrive from the same scale site. The sample may be a “grapple sample” in which case there will be three weighings recorded on the same weigh slip. The sample weight is the gross weight of the full truck less the sample deduction.

3-6 March 1, 2010


Sequence

Assigned Event Event Previous Description to Document Type

Type Code

Type Description Name

C WSB - Weigh Slip Billable

RS Remote Sample

Arrival from Harvest Area (Stratifiable – Sampled at Another Site)

As PS above, plus:

The HBS requires a sample scale tally for this load to arrive from another scale site. This weigh slip must include information about the destination scale site and the Load Destination Slip (LDS) from the weigh scale site to the sample yard.

D WSB - Weigh Slip Billable

PD Primary Departure

Arrival from Harvest Area (Stratifiable – Not Sampled)

Departing to Another Site

Combines PS and DP.

E WSR - Weigh Slip Red Tag

RT Red Tag Arrival from Harvest Area (Non-Stratifiable Measured at this Site)

This timber can NOT be assigned to a Billable stratum and must be excluded from the weight scale billing system.

The HBS requires a piece scale tally for this load to arrive from the same scale site.

F WSR - Weigh Slip Red Tag

RR Remote Red Tag

Arrival from Harvest Area (Non-Stratifiable Measured at Another Site)

As RT above except:

The HBS requires a piece scale tally for this load to arrive from another scale site. This weigh slip must include information about the destination scale site and the timber transport from the weigh scale site to the piece scale yard.

March 1, 2010 3-7


Sequence


Type Code


G WSO - Weigh Slip Other

4R SB4 Rescale

Arrival from Another Site (Previously Scaled)

All timber arrives that is previously scaled must have a Scaled Timber Brand and must be reported to the ministry. The HBS requires a corresponding departure record from the originating scale site.

H WSO - Weigh Slip Other

DP Departure Previously Scaled Departing to Non Scale Site Destination

This is a new specialized transaction. Weigh scale software may implement this feature. This transaction will be accepted by the HBS instead of a ledger entry.

I WSO - Weigh Slip Other

CU Company Use

Other This transaction allows for other company use measurements in which the ministry has no billing interest.

3-8 March 1, 2010


3.3.2 Log Tally

Log Parcel Tally Measurement Event Types are comprised of both piece scale tallies (FS 1211 or FS 1212) and weight scale sample returns (FS 1210).

Table 3-3 Log Parcel Tally Measurement Header Event Types

Sequence


Event Type Code

Event Type Name


Description

A PPS – Piece Scale

PS Primary Scale

Arrival from Harvest Area governed by Timbermark

(will be scaled)

This is the default case: All timber that is harvested must have a Timbermark and must be reported to the ministry. This load may be split into multiple parcels in which case the parcel count and parcel identifier must be provided.

This includes Cash Sale and Cruise Based marks. These must be submitted as a full returns and the HBS will NOT invoice these returns (using the Timbermark’s attribute from the FTA system)


Beachcomb is collected using this format

B PPS – Piece Scale

FD From Site Deck

Billable – from Scale Site Deck

This is a “Surge Pile Withdrawal”. The timber transport information is lost in this scenario.

C PPS – Piece Scale

RT Red Tag Weight Scale (Non-Stratifiable – from Local Site)

This is a Non-Stratifiable load that is measured at the originating weight scale site. The HBS will cross-reference this document with the original weigh slip.

March 1, 2010 3-9


Sequence


Type Code


D PPS – Piece Scale

RR Remote Red Tag

Weight Scale (Non-Stratifiable) – from Another Site

This is a red tag load that is transferred from a weight scale site to a piece scale site to be scaled. The HBS will cross-reference this document with the original weigh slip.

E PPS – Piece Scale

CS Piece Check Scale

Check Scale of an existing Piece Scale document

This is the record of a check scale that may replace an original scale. Non replacing check scales may also be submitted.

F PSS – Sample Scale

SS Sample Scale

Weight Scale Sample – from Local Site

This is a sample that is measured at the originating weight scale site the HBS will cross-reference this document with the original weigh slip.

Includes “Forced” samples (where weigh scale did not choose load for sampling)

G PSS – Sample Scale

RS Remote Sample Scale

Weight Scale Sample – from Another Site

This is like SS above with the exception that:

The sample is transferred from the original weight scale site to a piece scale site to be sampled. The HBS will cross-reference this document with the original weigh slip.

H PSS – Sample Scale

CS Sample Check Scale

Check Scale of an existing Sample Scale document


I POT – Other Tallies

=> no Logs

4R SB4 – Rescale

Previously Scaled from Another Site

(will be scaled)

This is a load that arrives at a scale site, consumes an arrival number, is scaled and is not billable (as stumpage has been already paid on the timber).

3-10 March 1, 2010


Sequence


Type Code


J POT – Other Tallies

=> no Logs

CU Company Use

Not Billable – from Stock

This timber is for other company use measurements in which the ministry has no billing interest.

Table 3-4 Log Parcel Tally Measurement Types.

Sequence

Name Description Process

N Net Scale Net Metric Scale

Timber is scaled using net metric measurements.

Parcel is designated as (N)et scale

Scaler records net dimensions

Handheld provides:

Net volume (to 3 decimal places) and dimensions

HBS verifies this according to the specifications in section 3.2 of the companion document HBS Phase 2B - Appendix B Submitted Scale Document Composition

March 1, 2010 3-11



Sequence

G Gross less Defect Scale

Deductions derive a Volume deduction

Timber is scaled using gross metric measurements. A defect calculator then derives a volume deduction recorded as a cubic measurement.

HBS accepts multiple defects per log each having a volume and defect code.

Parcel is designated as a (G)ross scale.

Scaler records gross dimensions and uses handheld calculator to record defect components of log.

Handheld provides:

Gross dimensions, net volume (to 3 decimal places) and zero or more defects. Each defect has a net volume (to 3 decimal places) and a description and defect code.

HBS verifies this according to the specifications in section 3.2 of the companion document HBS Phase 2B - Appendix B Submitted Scale Document Composition

Gross to Net Scale

Deductions derive a measurement deduction

Parcel is designated as either a (N)et scale or a (G)ross scale.

Scaler records gross dimensions and uses handheld calculator to record defect components of log or net measurements.

The parcel is submitted as either a (N)et scale or a (G)ross scale.

Beachcomb Beachcomb Scale Parcel is designated as either a (N)et scale or a (G)ross scale. The Beachcomb flag must be set on the parcel header.

In this scenario, an optional TimberMark field is populated on every log.

3-12 March 1, 2010


3.3.3 Special Forest Products Log Tally

Special Forest Products Tally Measurement Event Types are comprised of piece scale tallies, prorated piece scale tallies, stack scales and christmas tree scales (FS 1211, FS 222 and FS 200).

Table 3-5 Special Forest Products Tally Header Event Types.

Sequence


Event Type Code

Event Type Name


Description

A SFP – Special Forest Products Piece Scale

PS Primary Scale


(will be scaled)

This is the default case: All timber that is harvested must have a Timbermark and must be reported to the ministry. This load may be split into multiple parcels in which case the parcel count and parcel identifier must be provided.

This includes Cash Sale and Cruise Based marks. These are submitted as a full returns and the HBS will NOT invoice these returns (using the Timbermark’s attribute from the FTA system)


B SFP – Special Forest Products Piece Scale

CS Piece Check Scale

Check Scale of an existing Piece Scale document


March 1, 2010 3-13


Table 3-6 Special Forest Products Tally Measurement Types.

Sequence


L Log Scale Method For log-like products

Timber is scaled using net metric measurements.

Parcel is designated as “L”og scale

Scaler records net dimensions of each log-like product.

Handheld provides:

Net volume (to 3 decimal places) and dimensions

HBS verifies using Scale Method standard 7B.1

P Prorated PieceScale Method (piece sampling method)

For log-like products

Selected timber is scaled using net metric measurements.

Parcel is designated as “P”rorated Piece Log scale

For homogeneous products, a fraction of the pieces can be scaled, and an average volume per sampled piece computed.

Scaler records net dimensions of a select number of the log-like products in a parcel.

The total volume is estimated from the average volume per piece and the total piece count.

Handheld provides:

Net volume (to 3 decimal places) and dimensions of each log like product

Log like product record count

Total log like product in parcel

HBS verifies using Scale Method standard 7B.1

HBS calculates Parcel volume.

Prorated PieceScale Method is refered to in the Ministry scaling manual as piece sampling.

3-14 March 1, 2010



Sequence

K Stacked Scale Method

For stackable products.

Timber is scaled using dimensions of stack and a conversion factor.

Parcel is designated as a stac”K”ed scale.

Scaler records dimensions of the stack, and a fractional conversion factor, enabling the computation of the net volume for the stack.

HBS verifies computation.

Cannot be sampled.

C Piece Count Method

Used for Christmas trees only.

Parcel is designated as a piece “C”ount scale.

Scaler counts and records the number of Christmas trees of each grade.

Cannot be sampled.

March 1, 2010 3-15


3.3.4 Ledger Record

Table 3-7 Ledger Event Types.

Sequence

Event Type Code

Event Type Name


Description Event Type Usage


1 PS Primary Scale


(Will be Scaled)

This is the default case: All timber that is harvested must have a Timbermark and must be reported to the ministry. This timber is required to be scaled. Once scaled, the ledger must be updated with the scale information.

Site Ledger

ARL – Arrival Ledger

2 B4 Scaled Before


(Will NOT be Scaled)

All timber that is previously scaled must have a Scaled Timber Brand and must be reported to the ministry. The HBS will expect a corresponding departure record from the originating scale site.

Site Ledger or

Arrival Ledger


3 4R SB4 – Rescale


(Will be Scaled)

All timber that is previously scaled must have a Scaled Timber Brand and must be reported to the ministry. The HBS will require a corresponding departure record from the originating scale site. Once scaled, the ledger must be updated with the scale information.

Site Ledger


3-16 March 1, 2010


Event Event Previous Description Event Assigned

Sequence

Type Code

Type Name

Description Type to Usage Document

Type

4 TD To Site Deck


(Will NOT be Scaled)

This is a “Surge Pile Addition”. All timber that is harvested must have a Timbermark and must be reported to the ministry. This timber is required to be scaled at a later date.

Site Ledger or

Arrival Ledger


5 FD From Site Deck

Billable – from Scale Site Deck

This is a “Surge Pile Withdrawal”. This is the scale parcel that is recorded as the scale site deck is scaled. Once scaled, the ledger must be updated with the scale information.

Site Ledger


6 RS Remote Sample

Weight Scale Sample – from Another Site

This is a sample that is transferred from a weight scale site to a piece scale site to be sampled. Once scaled, the ledger must be updated with the scale information.

Site Ledger


7 RR Remote Red Tag

Weight Scale (Non-Stratifiable – from Another Site)

This is a Non-Stratifiable load that is transferred from a weight scale site to a piece scale site to be scaled. Once scaled, the ledger must be updated with the scale information.

Site Ledger


March 1, 2010 3-17


Event Event Previous Description Event Assigned

Sequence

Type Code

Type Name

Description Type to Usage Document

Type

8 DP Departure Departing from stock to another Destination

Departing from stock to another Scale Site

All timber that is previously scaled and travelling to another scale site or another destination of interest to the ministry must have a Scaled Timber Brand and must be reported to the ministry.

The HBS uses this record from the originating scale site to verify the source of timber that will be declared to have been previously scaled upon arrival at another scale site.

Site Ledger or Departure Ledger

DPL – Departure Ledger

3-18 March 1, 2010

Scale Measurement Processing

Changes 4

All systems capturing data for submission to the HBS must conform to the specifications contained in this guide.

March, 1, 2010 4-1


4.1 Definitions of Values Required to Enable Electronic Scale Data Capture

These values must be collected by the software on the original data collection equipment.

4.1.1 Detail Document Number

Purpose: Identifies a scale return across submissions of multiple revisions.

Process: The handheld or weigh scale computer generates this 13 character key when scale return is first created. This value will remain unchanged throughout subsequent revisions.

The Detail Document Number (DDN) must be on the original and all subsequent versions of the scale returns. Full replacements of scale returns generated in systems other than the HBS MUST include this DDN as a reference field in order to have the HBS recognize the two documents as related when replacements are performed.

The business key used are the first set used for the scale return. Even if the business key values change, the values in the DDN will not.

The algorithm uses a base 36 (0..9, A..Z) representation for the date values.

The benefits are:

● The DDN consumes less space than if the key value was generated without the base 36 representations

● Although it may be derived from initial values of natural keys, these keys will not be immediately recognizable in the DDN. So, users will not expect that if the business keys change that the DDN must also change.

Table 4.1 DDN Definition.

Data Type Key Element Composition Length

Weigh Slip DDN Candidate

1 Site

(Blank values are zero filled)

4

2 Last 6 digits of the Weigh Slip Ticket Number (zero filled if the value has less than 6 significant digits)

6

4-2 March, 1, 2010

Pricing Branch Scale Measurement Processing Changes


3 Day Count

Count of days since Jan 1, 2000, including Jan 1, 2000, and the current day, formatted in a base 36 representation

100 years at 365 days per year becomes 36500 (this is => S5W base 36)

Example: 927 => 0PR base 36

(zero filled if the value has less than 3 significant digits)

3

Weigh Slip Final DDN

Move characters from candidate to final by character position

Candidate 1-2 => Final 1-2


Candidate 11 => Final 5






13

Log Tally DDN Candidate

1 Primary Scaler Licence Number

(Blank values are zero filled)

4

2 Primary Scaler Return Number


4

3 Minute Count

Count of minutes since 00:00, Jan 1, 2000, not including 00:00 Jan 1, 2000, but including the current minute, formatted in a base 36 representation

100 years at 365 days per year at 1440 minutes per day becomes 52,560,000

(this is => VAJK0 base 36)


5

March, 1, 2010 4-3



Log Tally Final DDN

Move characters from candidate to final by character position



Candidate 11-12=> Final 4-5







13

Scale Time (Standard Time vs. Daylight Savings Time)

Always uses Standard Time when calculating Log Tally and Sample Tally DDN #s, regardless of whether or not Daylight Savings Time was in effect at the date of scale.

Table 4.2 Examples of DDN Construction.

Data Type

Composition Value

Weigh Slip

Scaled at Site 123, weigh slip number 2192375, on Jan 15, 2002

Site 1230

Weigh Slip Number: 2192375 192375

Day Count: Jan 15, 2002

366 days in 2000

365 days in 2001

15 days in 2002

= 746 days (becomes 0KQ base 36)

0KQ

DDN Candidate 12301923750KQ

Final DDN 121903023K75Q

Log Tally Scaled by scaler 4R23, using return number 73 on Mar 15, 2002 at 1:05pm

4-4 March, 1, 2010


Data Composition Value Type

Scaler Number 4R23

Return Number (73) 0073

Minute Count: Mar 15, 2002 at 1:05pm

366 days in 2000

365 days in 2001

73 days in 2002 (to Mar 14 at 23:59:59)

= 804 days

804 days * 1440 minutes / day =

1,157,760 plus the minutes used so far on Mar 15

13 * 60 + 5 = 785 minutes

in total we have

1,158,545 minutes (becomes 0OTXT base 36)

0OV1T

DDN Candidate 4R2300730OV1T

Final DDN 4R0V100O7233T

4.1.2 Document Version

Purpose: Identifies an iteration of a DDN. This version number must be greater than zero. The most recent version of the document is used for billing purposes.

Process: The Document Version number must be incremented at the end of each edit session either in the source data collection device or Industry Business Systems.

Technically, the unique key of a document in the HBS must be the combination of DDN and Document Version. The HBS uses this combination for its duplicate document edit. There is no process constructed in HBS for sequence verification of submitted document versions. The intent of this field is to provide a purely technical method for generating a unique document key.

Document version number must start with version 1. Version 1 must be digitally signed by the scaler. Subsequent versions corrected using IBS systems must be stored in the IBS systems for auditing purposes.

March, 1, 2010 4-5


4.1.3 Hash Total

Purpose: This value ensures that the data has not been modified with utilities.

Process: A published algorithm must be run on every character of required data in the detailed scale return to generate a numeric value. HBS Phase 2B - Appendix B: Submitted Scale Document Composition contains specifications for hash total domains for each Event Type combination that must be submitted.

The HBS must re-execute the same algorithm on the scale return data before the document is updated into the HBS. If the two hash totals (the hash total contained on the submitted return and the HBS generated hash total) do not match the scale return is rejected on the assumption that the scale data has been modified by an unapproved process.

This algorithm must be executed at the end of each edit session in the source data collection equipment.

If licensees modify data in business systems and intend to submit the corrections to HBS via XML file transfers, the appropriate hash total value for the new data must also be computed and submitted with the scale data.

4.1.3.1 Hash Total Algorithm

The ministry has chosen a variant of the CRC32 algorithm. The CRC 32 algorithm has a basis in theoretical mathematics, which will not be documented here. The algorithm is simple to implement, well documented and free. Typically this algorithm is executed on a set of data one character at a time and always returns a 32-bit integer.

The CRC of a domain of data is computed in this way:

Iterate through all characters in the data domain. Let n represent the index of the current character where n varies from 1 to the number of characters in the domain

Apply the CRC algorithm to the previous resultant CRC (of the n-1th character) and the nth character in the data domain to yield the CRC for the first n characters in the domain.

When n=1 (the first character in the domain), 0 is used as the value for the previous CRC.

The ministry has selected an implementation of the CRC algorithm and has coded and tested the implementation in C, Visual Basic and Java.

Please see the appendices to this document for the C and Visual Basic versions of the CRC32 algorithm

4-6 March, 1, 2010


4.1.3.2 Hash Total Domain

The domain for the hash total is fully defined in HBS Phase 2B - Appendix B Submitted Scale Document Composition. There are also two detailed examples of the specifics of computing an HBS hash total for both a weigh slip and a log tally document

4.1.4 Digital Signature

4.1.4.1 Authentication Key

Purpose: This is a character string that may be up to ten characters long (including a check digit) that is used to ensure that the scale return was provided by the scaler.

Authentication key is a condition of the site authorization which is a legally binding document for site owners.

There will be one value assigned to each ministry licensed scaler. Each scaler must:

● Keep his or her authentication key confidential.

● Enter this authentication key during the finalization process for every scale return document he or she is approving.

The HBS authentication key assignment process operates in the following manner:

● A scaler requests (or be assigned) an initial authentication key value.

● The HBS adds one character to the end of the requested authentication key. The character added is a Check Digit value.

● The HBS provides the actual authentication key to the scaler and records the value with the scaler’s licence information on the HBS.

4.1.4.1.1 Scale Site Software Processing

The ministry standards for authentication keys in scale site software are as follows:

● The authentication key must not be saved in scale collection software.

● The authentication key must be used to generate the Authentication Key Encrypted Hash Total value (described in the next section).

● The scale site software must confirm that the authentication key value is formed properly by verifying the check digit. The algorithm used by the HBS must be included in this specification for this purpose.

March, 1, 2010 4-7


Authentication key must be kept confidential and must not be shared with anyone.

4.1.4.1.2 Authentication Key Check Digit Validation

A Check Digit value must be appended to the requested authentication key to yield the actual authentication key issued by the ministry. These values serve two purposes.

● The Check Digit must ensure that there is an uniqueness for authentication key values.

● The Check Digit must allow the scale site software to inform the scaler whether or not the authentication key value entered is formed properly. This should minimize digital signature errors on scale returns and save Ministry and Industry staff the labour of approving and verifying scale returns with digital signature errors.

4.1.4.1.3 Check Digit Algorithm

The Check Digit algorithm must operate in this manner:

The signing Scaler’s licence number and the first n-1 characters of his published authentication key must be combined into the Check Digit domain value. The Check Digit must be computed in the following manner and must become the last (or nth) character of the published authentication key.

The ASCII value of each character in the Check Digit domain must be multiplied by its location / ordinal value. The results are then summed and divided modulus 26. This must produce a value that ranges between 0 and 25. The result is then transformed into an ASCII character from A to Z. Please see Appendix C for a VB implementation of this algorithm.

Table 4.3 Check Digit Test Data and Returning Values

Scaler Licence Number

Requested Authentication Key

Check Digit Domain

Check Digit Value

Ministry Issued Authentication Key

A345 MikeSmith A345MikeSmith D MikeSmithD

123H JoeBloggs 123HjoeBloggs T JoeBloggsT

9874 2355555 98742355555 Z 2355555Z

2234 2222222 22342222222 J 2222222J

P987 2222222 P9872222222 C 2222222C

4-8 March, 1, 2010


Scaler Requested Check Digit Check Ministry Issued Licence Number

Authentication Key Domain Digit Authentication Key Value

567U 2222222 567U2222222 I 2222222I

A345 Site123 A345Site123 W Site123W

123H Site123 123HSite123 Z Site123Z

123F Site123 123FSite123 R Site123R

9874 Site123 9874Site123 D Site123D

2234 Site123 2234Site123 Y Site123Y

P987 Site123 P987Site123 R Site123R

567U Site123 567USite123 X Site123X

Note that the values in the last column in the above table are those that must be used by the scalers to digitally sign their scale returns.

4.1.4.2 Signing Scaler Licence

Purpose: This value provides the identity of the scaler who signed the scale return. When the signing scaler signs a scale return, the scale software must record his ministry licence in this field. This is only provided when there must be a digital signature present on the return, otherwise, this value must be blank or null value for the purposes of scale data submission and hash total domain inclusion.

In both business scenarios that follow, either the primary or the secondary scaler must digitally sign the scale return.

4.1.4.2.1 Weight Scale

There are several measurements collected on a weigh slip.

1) Full weight of the truck. At the time the full weight of the truck is collected, the stratification decision is also made. The ministry has stated that the scaler of record for a weigh slip must be the scaler making the timber stratification decision. This person is referred to as the Primary Scaler by HBS Phase 2B - Appendix B Submitted Scale Document Composition.

2) Tare weight of the truck. The tare weighing may occur much later than the original weighing and be performed by a person other than the original weigher. This person is referred to as the Secondary Scaler by HBS Phase 2B - Appendix B Submitted Scale Document Composition.

March, 1, 2010 4-9


As the Primary Scaler may NOT be available to “digitally sign” the completed scale return, either the Primary or Secondary Scaler may “Digitally Sign” the scale return.

4.1.4.2.2 Piece Scale

There may be a primary secondary scaler associated with scaling a parcel or load of timber. For efficiency, scalers may work in tandem measuring the length of each log and each will measure the radius class at their own end of each log. One long standing goal of the ministry is to record the licence of all scalers who participate in the scaling of a load of timber for scale data accountability and check scaling purposes.

As happens today, the scale return is required to be associated primarily with one ministry-licensed scaler. The return number provided on the detailed scale return will be associated with that licence holder who is referred to as the Primary Scaler. The scaler licence of the other scaler on the scale return is referred to as the Secondary Scaler Licence.

4.1.4.3 Authentication Key Encrypted Hash Total

Purpose: This value provides the ministry with an assurance that the electronic version of the scale return data came from the person claimed, and that the file has not been tampered with since this value was affixed to the data. This value may also be called the “Digital Signature” of the scale return.

● The Ministry Business and Audit Model has dictated the use of the Authentication Key Encrypted Hash Total (AKEHT) to enable paperless scale submission.

If the HBS verification of the AKEHT fails, the scaler must provide a paper copy or another electronic copy of the original scale return to the Ministry of Forests and Range.

Process: There are several steps involved in constructing the encrypted hash total.

● During scale collection, the signing scaler must digitally sign the return. The software will record his ministry licence number.

● The hash total is generated as previously described (the signing scaler licence must be included in the hash total domain). The hash total provides a “snapshot” of the data state that can then be encrypted.

● The signing scaler will then be prompted for his authentication key.

● As described in the previous section, the scale collection software must verify that the authentication key value is an acceptable HBS authentication key.

4-10 March, 1, 2010


● Once he enters his authentication key, the hash total algorithm will then be executed with the hash total and authentication key as input. This algorithm will generate the AKEHT value that must be saved on the scale return and provided to the ministry.

● The scale collection software must NOT save the authentication key electronically.

● Once received in the HBS, the hash total must be recomputed and then encrypted with the authentication that the HBS has on file for the signing scaler. If the value computed does not match the value provided on the scale return, the AKEHT must be deemed invalid. This situation is called a Digital Signature Failure.

4.1.4.4 Encryption Algorithm

The ministry has elected to use the same algorithm for computing both the Hash Total and the AKHET. The benefit of using two different algorithms was deemed to be negligible

Figure 4.1 Process Diagram for Constructing Hash Total and AKEHT.

March, 1, 2010 4-11


4.2 Other Definitions

4.2.1 Defect Record - Formatted Defect Measurement Description

As defined in HBS Phase 2B - Appendix B Submitted Scale Document Composition defects computed by handheld computers must be submitted to the HBS as formatted description fields. This section details the specification for populating this data field.

The maximum possible size of this field is 40 characters.

Table 4.4 Defect Measurement Description String Construction Scenarios

Data Collected Method 1

Cylinder

Method 2

Cone

Method 3

Frustum of a Cone

Method 4

Ring

Method 5

Square Prism

Method 6

Triangular Prism

Method 7

Dimension Reduction

Designator CY CN FC RG SQ TR DR

Top radius in Rads TR Yes Yes Yes

Butt radius in Rads BR Yes Yes Yes Yes

Defect length in Decimeters

L Yes Yes Yes Yes Yes Yes

Percentage % Yes Yes

Inside top radius in Rads

ITR Yes

Inside butt radius in Rads

IBR Yes

Top height in Rads TH Yes Yes

Top width in Rads TW Yes Yes

Bottom height in Rads

BH Yes Yes

Bottom width in Rads

BW Yes Yes

Length Deduction in Decimeters

LD Yes

Top Deduction in Rads

TD Yes

Butt Deduction in Rads

BD Yes

4-12 March, 1, 2010


Table 4.5 Defect Measurement Description Examples

Method Example Description

1. Cylinder CY TR1 BR8 L100 %75

75% of a cylinder with a top radius of 1 rad, a butt radius of 8 rads, 100 decimeters in length

2. Cone CN B10 L70 A cone with a butt radius of 10 rads and a length of 70 decimeters

3. Frustum of a Cone

FC TR5 BR8 L10

A frustum of a cone with a top radius of 5 rads, a butt radius 8 rads and a length of 10 decimeters

4. Ring RG TR15 BR21 L100 %50 ITR12 IBR18

50% of a ring with an outside top radius of 15 rads, an outside butt radius of 21 rads, an inside top radius of 12 rads, an inside butt radius of 18 rads 100 decimeters in length

5. Square Prism

SQ L8 TH10 TW15 BH20 BW17

A Square Prism with a top height of 10 rads, a top width of 15 rads, a bottom height of 20 rads, a bottom width of 17 rads, 8 decimeters in length

6. Triangular Prism

TR L8 TH5 TW3 BH3 BW4

A Triangular Prism with a top height of 5 rads, a top width of 3 rads, a bottom height of 3 rads, a bottom width of 4 rads, 8 decimeters in length

7. Dimension Reduction

DR LD0 TD2 BD1

A Dimension Reduction comprised of a length deduction of 0 decimeters, a top deduction of 2 rads and a bottom deduction of 1 rads

March, 1, 2010 4-13


4.3 Edit Session

An edit session occurs each time an approved person opens, modifies and closes a scale return in HBS or industry business systems. The following abstracts describe two scenarios of edit sessions envisioned plus the required processing in each scenario.

4.3.1 Edit Session on Existing Scale Returns – by Scaler

● Scaler chooses to modify an existing scale return,

● System opens existing scale return,

● Scaler edits scale return,

● Scaler elects to finalize edit session,

● enters Authentication Key,

● System finalizes edit session,

● Increments Version – must be greater than version 1,

● Computes Hash Total from Data (includes Document Version and Detail Document Number),

● Computes Authentication key Encrypted Hash Total.

4.3.2 Edit Session on Existing Scale Return– by Industry Site Administrator

● ISA chooses to modify an existing scale return,

● System opens existing scale return,

● ISA edits scale return,

● ISA finalizes edit session,

● System finalizes edit session,

● Increments Version – must be greater than version 1,

● Computes Hash Total from Data (includes Document Version and Detail Document Number)

4-14 March, 1, 2010


Note: the ministry does not require a digital signature in this scenario as a version digitally signed by the scaler MUST have been submitted to HBS previously. Accordingly, updating the Document Version and Hash Total MUST be performed by the routine that builds the XML data export for HBS. In this scenario, the Signing Scaler Licence must be null or blank.

March, 1, 2010 4-15



4-16 March, 1, 2010

Business Process Issues 5

March 1, 2010 5-1


5.1 Verifying Completeness of Data Submissions

The Ministry invoices the mark holders with a copy to site owner from document records that demonstrably originate from scale site data collection equipment. In the past, site owner verified that all applicable scale returns had been included in computed summaries. With the move to detailed data collection, licensees are required to provide a record of all measurements. In cases, where the Ministry does not need a record of the measurement information on a scale return, only a partial record of the measurement will be required.

The primary issue is this: If a scale return is expected but is not received in the HBS, was it a stock scale or a billable scale return that has been lost?

The Ministry will invoice on the best information it has, in accordance with approved schedules.

5.1.1 Control Sequence Summary

5.1.1.1 Piece Scale

● Load Arrival Number: All arriving loads must be assigned an arrival number, regardless of the source. Not all arriving loads will be scaled (e.g.: previously scaled timber from another scale site). Some arriving loads are split into parcels to ease scale measurement. In these cases each parcel is assigned a parcel identifier. Where a load has been split, each parcel must also be expected to have a parcel count field that contains the count of all parcels that comprise the load.

● Scaler’s Return Number: All scale measurements in which the Ministry has an interest must consume a sequential return number. The scaler must remember and update his return number appropriately.

Verifications

● Load Arrival Number: the sequence of load arrival numbers provided on the scale returns will be inspected for gaps and duplications. The only valid duplication of a load arrival number will be where arriving loads are split into parcels to ease scale measurement. In these cases each parcel scaled is assigned a parcel identifier field which must be validated against parcel count collected on each scale return.

Arrivals not scaled must be accounted for in a ledger that must be submitted to the Ministry.

5-2 March 1, 2010

Pricing Branch Business Process Issues

● The sequence of scaler return numbers provided by a scaler on scale returns will be inspected for gaps and duplications.

5.1.1.2 Weight Scale

● Weigh Slip Number: All scale measurements must consume a sequential weigh slip number. This includes arrivals, stock measurements and departures. Data collection equipment must provide a non-duplicated, sequential weigh slip number.

Verifications

● The sequence of Weigh Slip Numbers provided must be inspected for gaps and duplications.

Ministry staff will investigate any anomalies found in the sequence of weigh slip numbers.

March 1, 2010 5-3


5.2 Submission of Electronic Originals of Scale Data

Either the scaler digitally signs the data or personally logs onto the HBS and provides unsigned data. Under either scenario, the only data submitted to the HBS on an ongoing basis must be the electronic copies of the scale returns. Licensees will still be required to maintain backups (electronic or paper) of the scale returns submitted.

5-4 March 1, 2010

Pricing Branch Business Process Issues

5.3 Administrative Document Processing Changes

The HBS accepts scale ledger documents electronically via electronic file transfer.

Licensees may also submit ledgers on paper to the Ministry.

Please see HBS Phase 2B - Appendix B: Submitted Scale Document Composition for details on the composition of ledger documents.

March 1, 2010 5-5



5-6 March 1, 2010

Scale Data Submission 6

March 1, 2010 6-1


6.1 File Transfers using Extended Markup Language (XML)

6.1.1 XML Definition

The following text has been distilled from a high level summary of XML published by the World Wide Web Consortium web site. The full text is included in Appendix A.

XML is a method for putting structured data in a text file. XML is a set of rules, guidelines, conventions for designing text formats for data, in a way that produces files that are easy to generate and read (by a computer), XML data formats are:

● Unambiguous,

● Extensible and

● Platform-independent

XML makes use of tags (words bracketed by '<' and '>') and attributes (of the form name="value"). XML uses the tags to delimit pieces of data, and leaves the interpretation of the data completely to the application that reads it.

XML files are text files but aren’t meant to be read by humans. They are text files, because that allows experts (such as programmers) to more easily debug applications, and in emergencies, they can use a simple text editor to fix a broken XML file.

The Hash Total field described above will ensure that the scale data in XML format will be secure from this kind of unexpected manipulation.

Since XML is a text format, and it uses tags to delimit the data, XML files are nearly always larger than comparable binary formats. Communication protocols such as modem protocols and HTTP (the core protocol of the Web) can compress data on the fly, thus saving bandwidth as effectively as a binary format.

XML originated from SGML, which was developed in the early '80s, became an ISO standard in 1986, and is widely used for large documentation projects.

XML is license-free, platform-independent and well supported

For file transfers, the HBS will accept scale measurement data formatted using the industry standard Extended Markup Language (XML). Because each software package has a different native data storage format, individual vendor offerings will have to be able to generate XML versions of scale data for the HBS.

6-2 March 1, 2010

Pricing Branch Scale Data Submission

6.1.2 XML Schema Definitions

The companion document HBS Phase 2B - Appendix B Submitted Scale Document Composition contains the schema definition necessary to prepare formatted scale data for the HBS.

That document contains:

● Pictorial Representations of the HBS XML Schema

● Text layout of the HBS XML Schema in an XSD format

● Several examples of documents formatted for the HBS

March 1, 2010 6-3


6.2 HBS Scale Data Collection and Submission Process Overview

Figure 6.1 Scale Data Submission Process.

Table 6-1 Required Events for Successfully Providing Data to HBS

Event Discussion

Collect Scale Measurements in data collection device

This must be performed by the Primary Scaler.

Digitally Sign Data Each electronic document submitted must be digitally signed by either the primary or secondary scaler.

Format to HBS Standards A Responsible Party can perform this activity

Submit to HBS A Responsible Party can perform this activity

The diagrams on the following pages depict possible implementations of this basic process presented above:

● Scaler Submits data to HBS

● Responsible Party Submits Data to HBS

● Responsible Party Submits Data Formatted by Scale Site Software

● Responsible Party Submits Data Formatted by Industry Business System

6-4 March 1, 2010


6.2.1 Scaler Submits Data Directly to the HBS

In this scenario, the scaler submits the scale data to the HBS directly.

Figure 6.2 Process Diagram for when a Scaler Submits Data to HBS.

Table 6-2 Events When Scaler Submits Data Directly to HBS.

Event Discussion




Format to HBS Standards Performed by the Signing Scaler.

Submit to HBS Performed by the Signing Scaler.

March 1, 2010 6-5


6.2.2 Responsible Party Submits Data to HBS

In this scenario, the scaler formats the scale data to HBS standards. He or she then forwards it to a responsible party who submits it to the HBS directly.

Figure 6.3 Process Diagram for when a Responsible Party Submits Data to HBS

Table 6-3 Events When Responsible Party Submits Data to HBS.

Event Discussion




Format to HBS Standards Performed by the Original Scaler.

Data Transfer from Scale site to Responsible Party

In XML format

Submit to HBS Performed by Responsible Party.

6-6 March 1, 2010


6.2.3 Responsible Party Submits Data Formatted by Scale Site Software

In this scenario, the scaler sends the data in native format to a responsible party. The responsible party then uses a copy of the scale site software to format the scale data to HBS standards. The responsible party then submits the scale data to the HBS directly.

Figure 6.4 Process Diagram for when a Responsible Party Submits Data Formatted by Scale Site Software.

Table 6-4 Events When a Responsible Party Submits Data Formatted by Scale Site Software.

Event Discussion




Data Transfer from Scale site to Responsible Party

In native format

Format to HBS Standards Performed by Responsible Party.


March 1, 2010 6-7


6.2.4 Responsible Party Submits Data Formatted by Industry Business System

In this scenario, the scaler sends the data in native format to industry business systems. The responsible party then uses the industry business system to format the scale data to HBS standards. The responsible party then submits the scale data to the HBS directly.

Figure 6.5 Responsible Party Submits Data Formatted by Industry Business System

Table 6-5 Events When a Responsible Party Submits Data Formatted by Industry Business System

Event Discussion




Data Transfer from Scale site to Industry Business System

In native format

Format to HBS Standards Performed by Responsible Party using Industry Business System


6-8 March 1, 2010


6.2.5 Industry Business System Formats and Submits Data in Batch

In this scenario, the scaler sends the data in native format to industry business systems. The industry business system formats the scale data to HBS standards. The industry business system then submits the scale data to the HBS directly.

Figure 6.6 Process Diagram for when an Industry Business System Formats and Submits Data in Batch Process

Table 6-6 Events When an Industry Business System Formats and Submits Data in Batch Process.

Event Discussion




Data Transfer from Scale site to Industry Business System

In native format

Format to HBS Standards Performed by Industry Business System

Submit to HBS Performed by Industry Business System

March 1, 2010 6-9


6.2.6 Weight Scale Measurement Records

Figure 6.7 Weigh Scale Measurement Records Process Diagram.

6-10 March 1, 2010


6.2.7 Log Parcel Tally Measurement Records (Including SFP)

Figure 6.8 Log Parcel Tally Measurement Records Process Diagram

March 1, 2010 6-11


6.2.8 Scale Site Events are Ledgered

Figure 6.9 Process Diagram Showing the Scale Site Events being Ledgered.

6-12 March 1, 2010


6.2.9 Scale Activity Ledgers are Collected into HBS

Figure 6.10 Process Diagram Showing Scale Activity Ledgers Collected into HBS

March 1, 2010 6-13


6.3 Transmission File Naming Standards

There are various combinations of submission scenarios described in the previous section. Several examples are:

● the HBS data submission file is generated at the scale site by a scaler using scale site software

● the HBS data submission file generated within an industry business system in a batch.

If the file is generated at the scale site, it may be either directly submitted to the HBS or may be moved electronically across various platforms until it is submitted to the HBS.

Accordingly, it is necessary to define a transmission file-naming standard that will ensure that a file of HBS data will not overwrite a previously constructed HBS file.

One constraint on this naming standard is that it should be implementable on the most primitive of operating systems. Constraints considered in developing this specification include

● DOS limits filenames to being only 8 characters in length.

● Some operating systems do not allow filenames to begin with numeric characters or contain lower case characters

6-14 March 1, 2010


Table 6.7 Transmission File Naming Convention

Data Type Key Element

Composition Examples Length

Submitted HBS Filename

1 Year Designator:

chosen from the values A through Z. Resets to A after Z

= ASCII Character Value for (Current Year Numeric Value-1977) modulus 26 + 65

2003 = A

2004 = B

…

2028 = Z

2029 = A

2030 = B

…

2054 = Z

2055 = A

2066 = B

Value for 2010

CHR$((2010-1977) mod 26 + 65)

Becomes H

1

2 Minute Count

Count of minutes between midnight, Jan 1 on the current year and the time the file is prepared for the HBS by the submitting software

formatted in a base 36 representation

zero filled if the value has less than 4 significant digits

365 days per year at 1440 minutes per day becomes 525,600

becomes B9K0 base 36

4

3 Scale Site

The lowest Scale Site value contained in the current transmission file (sorted in ASCII)

Truncated to three characters

Blank values are zero filled

113 becomes 113

11 becomes 110

1145 becomes 114

3

March 1, 2010 6-15


Table 6.8 Transmission File Name Examples

Data Type Composition Value

Submitted HBS Filename

File is generated on July 31, 2017 at 8:12 p.m., and the lowest valued Scale Site contained in the file is 18XZ

Year Designator

2017 becomes

CHR$ ((2017-1977) mod 26 + 65)

= O

O

Minute Count:

July 31 at 8:12 p.m.

211 Days Elapsed so far * 1440 minutes / day = 303,840

+ minutes today = 20 * 60 + 12 = 1212

= 305,052 (becomes 6JDO base 36)

6JDO

Scale Site

18XZ becomes 18X

18X

Final Submitted HBS Filename Value O6JDO18X

6-16 March 1, 2010


6.4 Scale Data Submission Mechanisms

Currently the MoF has the following submission mechanisms for providing data to the HBS.

Clients have these two submission methods available:

● HTTPS via Authenticated Login (preferred method).

● FTP via IP Filtering.

6.4.1 HTTPS via Authenticated Login

The intent of this is to provide secure HTTPS file transfer services for users who wish to provide attended submission of scale data. This submission method has these attributes:

● A given user by virtue of their employment relationship with a given licensee or scale site operator requires a BCeID and a current password to log into the HBS application.

● Security around the submission process will be implemented by the user providing their current password. Passwords are aged and users are responsible for managing their own passwords via the BCeID user site.

6.4.2 FTP via IP Filtering

The intent of this is to provide FTP file transfer locations to selected clients who implement batch or non-attended submission of scale data. This submission method has these attributes:

● A given client will be given a directory location corresponding with their client location code on the MoF FTP server.

● Security around the assigned director location will be assigned by using IP Filtering.

● Files will be allowed to be written to the submission directory from a given set of IP addresses. Typically this will be the IP address of the client’s firewall server. It is not believed that this will be implemented by IP submask. That is, a fully qualified IP address must be provided. The MOFR will record several allowable IP addresses for each mailbox directory on the FTP server.

● The process writing data to the FTP directories will NOT be required to be authenticated. No password will be necessary.

● FTP submission will not typically be available to those wishing to provide attended data submission.

March 1, 2010 6-17



6-18 March 1, 2010

Printed Scale Documentation 7

Reports must be generated from scale site software for four main reasons:

1) Re-creation of scale information in the event of computer breakdown;

2) Provide a record of changes made to scale data;

3) Provide a summarized record of scale for check scale purposes; and

4) Provide an accounting of documents required to be submitted to the Ministry or retained on site for Ministry use.

The required model for weigh scale must generate a “Safety Sheet” for (1) above and an “Daily Audit Log” for (2) and (4). The model for piece scale must generate a “Species Grade Summary Report” for (1) and (3) above and an “Daily Load Listing” for (2) and (4).

Back ups of scale data submitted to the Harvest Billing System must also be retained in electronic (preferably) or paper form.

This chapter provides draft report specifications and layout for scale data software. These report specifications will be used to evaluate the scale site software that will be submitting data to the HBS.

Please see the examples at the end of this document in Appendix K.

Back up requirements of the digitally signed scale data that is electronically submitted to the Ministry are described in Chapter 3.

March 1, 2010 7-1


Table 7-1 Paper Reports Defined for Weight Scale Sites.

Report Name

Report Purpose Disposition Section

Safety Sheet

Recreate the scale information in the event of computer breakdown

Retained for period at scale site

7.1.1

Weigh Slip Recreate the scale information in the event of computer breakdown


7.1.2

Daily Audit Log

Record of changes to scale data.

Printed daily and matched to paper LDS documents

Submitted to the ministry

7.1.3

If the Safety Sheet is being used then weigh slips will not be expected to be printed.

Table 7-2 Paper Reports Defined for Piece Scale Sites.

Report Name Report Purpose Disposition Section

Species Grade Summary Report

Recreate the scale information in the event of computer breakdown and provide a summarized record of scale for check scale comparisons


7.2.1

Log Tally Recreate the scale information in the event of computer breakdown


7.2.2

Daily Load Listing

Printed daily and matched to paper LDS documents

Submitted to the ministry

7.2.3

If the Species Grade Summary Report is being used then log tallies will not be expected to be printed.

7-2 March 1, 2010

Pricing Branch Printed Scale Documentation

7.1 Weight Scale

The ministry requires that the Safety Sheet is used, however, if this report is not supported by the scale site software, weigh slips must be printed after every load is finished and gross weights must be written on the Load Description Slip.

7.1.1 Safety Sheet

This report will contain a record of all events that occur at the scale site in chronological order. It is expected that the record of events is printed at the same time as the event’s occurrence. The purpose of this report is to be able to recreate the scale information in the event of computer breakdown.

7.1.1.1 Print Expectations

The “Safety Sheet” is printed on a continuous basis. This means that for every weighing (weigh in, tare, company use) a line is generated on the report as the event is recorded in the computer. This means that two printers may be required at a scale site that also prints weigh slips for their own purposes. If two printers are not available then Weigh Slips will be suitable if an interim version of the slip is printed after the weigh in event.

7.1.1.2 Submission and Retention Expectations

When used, the paper “Safety Sheet” is not expected to be submitted to the ministry; however, it must be retained by the scale site operator for a period of six months. During this time this report must be provided to a forest officer upon request.

7.1.2 Weigh Slip

The Weigh Slip will contain all elements defined in the document HBS Phase 2B - Appendix B: Submitted Scale Document Composition field lists. It is recognized that there will be company use information included on the documents as well. The purpose of this report for the ministry is to be able to recreate the scale information in the event of computer breakdown.

If the Safety Sheet is not being used then the weigh slip is suitable if an interim version of the slip is printed after the weigh in event.


The tare weighing occurs shortly after the weigh in event. A Weigh Slip is expected to be printed for each arriving load at the time of the tare weighing if the Safety Sheet is not being used. The following table describes additional events and their print requirements:

● Tare Weighing and Weigh In are separated - typically in this situation, the timber on the truck is sent to another scale site (e.g. sample to be measured

March 1, 2010 7-3


elsewhere). The truck must then return to the original scale site for the tare weighing. A Weigh Slip is expected to be printed for each arriving load after the tare weighing if the Safety Sheet is not being used.

● Corrections - At any point after the tare weighing, a scaler may correct data.

● Digital Signing - will most likely occur as a batch process. Each electronic log tally submitted must be digitally signed by either the weigh in scaler or the weigh out scaler. The Weigh Slip is not expected to be ‘printed and physically signed’ after the digital signing event.


When used, the paper weigh slip is not expected to be submitted to the ministry; however, it must be retained by the scale site operator for a period of six months, during which time the report must be provided to a forest officer upon request.

7.1.3 Daily Audit Log

This report must contain a record of all arriving loads at the scale site in weigh slip ticket number order. This report must detail all changes made to data in which the ministry has an interest. The last version of the data on the weigh slip must match the data submitted. If a weigh slip has been deleted this report must highlight that event.


The Daily Audit Log is printed on a nightly basis from the weigh scale computer. The report is sorted in weigh slip ticket number order and shows the audit trail of modifications for each weigh slip. There are several scenarios for representing the audit trail for a weigh slip:

● When no edits were made to the weigh slip, the report must contain just one line for each weigh slip listing the data required to be on the electronically submitted weigh slip.

● When the weigh slip has been edited one or more times, the last line for each weigh slip must list the data required to be on the electronically submitted weigh slip. For each edit session, there must be a line of data provided that lists the original values of the modified fields and the date / time of the modification. When multiple edits are made during a session, all original values must be provided on the edit line.

7.1.3.2 Submission Expectations

This report must be submitted to the ministry. As stated previously, the report must be printed once a day. All signed paper LDS original forms must be attached to that report in chronological order for the date of original weighing and also submitted.

7-4 March 1, 2010


7.2 Piece Scale

The ministry prefers that the Species Grade Summary Report is used, however, if this report is not supported by the scale site software, log tallies must be printed after every load is complete.

7.2.1 Species Grade Summary Report

This report must contain a record of all events that occur at the scale site in chronological order. The record of events must be printed at the time the scale data on the handheld is uploaded to the scale site computer.

The purpose of this report is to be able to recreate the scale information in the event of computer breakdown and to provide the necessary summarized data for check scale comparisons.


The Species Grade Summary Report is printed on a continuous basis. This means that for every load scaled, a report section is generated on the report as the event is uploaded to the scale site computer.

This means that two printers may be required at a scale site that also prints log tallies for their own purposes. If two printers are not available then a Log Tally would be suitable so long as the summarized data is available immediately from the software upon request of a forest officer for check scale purposes.


When used, the paper Species Grade Summary Report need not be submitted to the ministry; however, it must be retained by the scale site operator for a period of six months, during which time the report must be provided to a forest officer upon request.

7.2.2 Log Tally

The Log Tally must contain all elements defined in the document HBS Phase 2B - Appendix B: Submitted Scale Document Composition field lists. It is recognized that there must be company use information included on the documents as well.

The purpose of this report for the ministry is to be able to recreate the scale information in the event of computer breakdown.


Appendix B contains 9 Event Types of Log Tally documents that are classified into 3 broad groupings:

March 1, 2010 7-5


● Piece Scale - The log tally document is used as the basis for billing. A full set of scale measurements must be printed.

● Sample Scale - The log tally document is used as the basis for weight scale sampling. A full set of scale measurements must be printed.

● Piece Scale – Other - The log tally document is used for company use. A partial record of the scale measurement must be printed.

Table 7-3 Additional Print Expectations for the Log Tally Report.

Event Description Print Expectation

Correction At any point after measuring, a scaler may correct data

Log tally must be ‘printed and physically signed’.

Digital Signing

Each electronic log tally submitted must be digitally signed by either the primary scaler or the secondary scaler.

The paper log tally is not expected to be ‘printed and physically signed’


The paper log tally is not expected to be submitted to the ministry; however, it must be retained by the scale site operator for a period of six months, during which time the report must be provided to a forest officer upon request.

7.2.3 Daily Load Listing

This report must contain a record of all scaled loads at the scale site in load arrival number order. The last version of the data on the load listing must match the data submitted. For small sites (less that 50 loads / month) this report should be selectable by month as opposed to selectable by day.


The Daily Load Listing is printed on a nightly basis from the scale site computer or licensee’s computer system or the HBS. The report is sorted in load arrival number order and shows the final state of the scale documentation submitted electronically to the HBS.

7.2.3.2 Submission Expectations

This report may be replaced with a copy of the piece scale site’s Site Ledger document or an HBS generated load listing. This report must be submitted to the ministry.

As stated previously, the report must be printed once a day. All signed paper Load Description Slip (LDS) original forms must be attached to this report in chronological order for the original date of scale and also submitted.

7-6 March 1, 2010


7.3 Back Up Requirements

This section describes the back up requirements for scale data submitted to the HBS. The requirements for both weight scale and piece scale data are the same.

7.3.1 Electronic Back Up

The electronic back up of scale data must contain the latest version of the scale data submitted to the HBS.

7.3.1.1 Re-submission and Print Expectations

The data must be able to be retrieved from the back up source and resubmitted electronically to the HBS in the format described in the document HBS Phase 2B - Appendix B: Submitted Scale Document Composition.

The data must also be able to be printed in the event that electronic resubmission is not possible. The printed data format must comply with the specifications in the document HBS Phase 2B - Appendix B: Submitted Scale Document Composition.

7.3.1.2 Retention Requirements

The back up of the data must be retained at either the scale site office or the industry office. The back up must be retained for a period of six months. During this time the data must be able to be retrieved from the back up source upon request of a forest officer.

7.3.2 Paper Back Up

The paper back up of scale data must contain the latest version of the scale data submitted to the HBS.

7.3.2.1 Resubmission Expectations

The printed back up must comply with the data format specifications in the document HBS Phase 2B - Appendix B: Submitted Scale Document Composition.

The printed back up must be able to be retrieved from the back up location and resubmitted to the HBS in the format described in the document HBS Phase 2B - Appendix B: Submitted Scale Document Composition.

7.3.2.2 Retention Requirements

The back up of the data must be retained at either the scale site office or the industry office. The back up must be retained for a period of six months. During this time the data must be provided to a forest officer upon request.

March 1, 2010 7-7



7-8 March 1, 2010

Scale Site Software 8

The Ministry currently has a self-assessment policy regarding systems update and data handling policies for scale data collection equipment at industry sites.

March 1, 2010 8-1


8.1 Policy for Scale Site Software

As data must now be collected directly from the scale site data collection equipment, the scale site software approval and deployment process requires modifications. The HBS implementation requires this policy to be more detailed than it has been previously.

The market for scale site software is very small and tends to be serviced by a small number of vendors. For efficiency, the software approval process must focus first on vendor offerings and then on scale site installations of the vendor offerings.

8-2 March 1, 2010

Pricing Branch Scale Site Software

8.2 Scale Software Vendor Approval Process

The following steps must be followed in the quality assurance of scale site software:

1. Software vendors independently verify their software against Ministry specifications through the vendors internal quality assurance process.

2. Ministry verifies that Industry software is in compliance with the specifications. The Ministry reserves the right to visit software vendor sites to review requirement and design documents and to test the software. Software vendors must prove that they have the “BOS” Sample Algorithm incorporated in their software.

3. Ministry records the Product Name, Version Number and Revision Number of compliant software in a list of "Software Approved for Use" located on the HBS website.

The HBS must provide the following functions to assist in steps 1 and 2:

● The HBS can provide on-line Test Case Data, which the ministry will revise on a regular basis. Industry must use this data as input to Scale Site Software when performing quality assurance and generating test transmissions. These Test Cases will cover the core data requirements for each scenario, or Event Type.

● The HBS must provide an on-line test transmission function to verify the XML file format, hash total and AKEHT produced by the Industry software. HBS must provide format validations, and must store a record of the transmission in the database.

● The HBS must provide a function to allow Ministry to search test transmissions for a particular Software Product, Version and Revision.

Additional quality assurance processes must be performed by Industry and Ministry, but are outside the scope of the HBS system:

● Software vendors perform internal testing of their software using HBS-supplied test data, in addition to internally generated test data.

● Software vendors must submit the results of internal quality assurance testing to the Ministry for review, in addition to compiled software.

● Ministry must perform quality assurance on all received software, including, for example, software controls relating to the scaler's Authentication Key.

The Ministry has updated Scale Site Authorizations to include a condition stating that each site must use Ministry approved scale site software.

The process for ensuring ongoing compliance, once a given scale location has been converted to paperless electronic submission, must be:

March 1, 2010 8-3


● The HBS accepts and invoices all valid scale data

Scale data submitted that was collected by unknown scale software must be handled in this manner:

● If the software product is unknown to the ministry, it cannot be used. The site operator will be contacted and the program must be reviewed by the ministry. Presumably this is a product that has never been presented to the ministry for review.

● If the Software Product is known to the ministry and the Software Version is unknown, the ministry must contact the software vendor and the program must be reviewed by the ministry. Presumably this is a release of major functionality for an existing product that must be reviewed.

● If the Software Product and Software Version are both known to the ministry and the Software Revision in unknown, the ministry must contact the software vendor. The ministry will not review the program. Presumably this is a minor enhancement release to an already known product.

Ministry conducts spot audits of scale sites where reviewed software is being used, in order to verify that:

● The actual version being used matches the version that is reported (on scale return data sent to HBS) as being used.

● Automated procedures specified in Appendix N, but which do not interface to HBS, are being followed.

● Non-automated procedures specified in Appendix N are being followed.

8-4 March 1, 2010

Appendices

March 1, 2010 A-1

HBS Technical Specification for Industry Ministry of Forests and Range

Appendix A What is XML?

The following text describes XML from a high level and is reprinted from:

http://www.xml.org/sml/xmlfaq

What is XML (The Extensible Markup Language)? XML, XLink, Namespace, DTD, Schema, CSS, XHTML,... If you are new to XML, it may be hard to know where to begin. This summary in 7 points attempts to capture enough of the basic concepts to enable a beginner to see the forest through the trees.

1. XML is a method for putting structured data in a text file For "structured data" think of such things as spreadsheets, address books, configuration parameters, financial transactions, technical drawings, etc. Programs that produce such data often also store it on disk, for which they can use either a binary format or a text format. The latter allows you, if necessary, to look at the data without the program that produced it. XML is a set of rules, guidelines, conventions, whatever you want to call them, for designing text formats for such data, in a way that produces files that are easy to generate and read (by a computer), that are unambiguous, and that avoid common pitfalls, such as lack of extensibility, lack of support for internationalization/localization, and platform-dependency.

2. XML looks a bit like HTML but isn't HTML Like HTML, XML makes use of tags (words bracketed by '<' and '>') and attributes (of the form name="value"), but while HTML specifies what each tag & attribute means (and often how the text between them will look in a browser), XML uses the tags only to delimit pieces of data, and leaves the interpretation of the data completely to the application that reads it. In other words, if you see "<p>" in an XML file, don't assume it is a paragraph. Depending on the context, it may be a price, a parameter, or a person.

3. XML is text, but isn't meant to be read XML files are text files, but even less than HTML are they meant to be read by humans. They are text files, because that allows experts (such as programmers) to more easily debug applications, and in emergencies, they can use a simple text editor to fix a broken XML file. But the rules for XML files are much stricter than for HTML. A forgotten tag, or a an attribute without quotes makes the file unusable, while in HTML such practice is often explicitly allowed, or at least tolerated. It is written in the official XML specification: applications are not allowed to try to second-guess the creator of a broken XML file; if the file is broken, an application has to stop right there and issue an error.

4. XML is a family of technologies There is XML 1.0, the specification that defines what "tags" and "attributes" are, but around XML 1.0, there is a growing set of optional modules that provide sets of tags & attributes, or guidelines for specific tasks. There is, e.g., Xlink (still in development as of November 1999) which describes a standard way to add hyperlinks to an XML

A-2 March 1, 2010

http://www.xml.org/sml/xmlfaq

Pricing Branch Appendices

file. XPointer & XFragments (also still being developed) are syntaxes for pointing to parts of an XML document. (An Xpointer is a bit like a URL, but instead of pointing to documents on the Web, it points to pieces of data inside an XML file.) CSS, the style sheet language, is applicable to XML as it is to HTML. XSL (autumn 1999) is the advanced language for expressing style sheets. It is based on XSLT, a transformation language that is often useful outside XSL as well, for rearranging, adding or deleting tags & attributes. The DOM is a standard set of function calls for manipulating XML (and HTML) files from a programming language. XML Namespaces is a specification that describes how you can associate a URL with every single tag and attribute in an XML document. What that URL is used for is up to the application that reads the URL.

5. XML is verbose, but that is not a problem Since XML is a text format, and it uses tags to delimit the data, XML files are nearly always larger than comparable binary formats. That was a conscious decision by the XML developers. The advantages of a text format are evident (see 3 above), and the disadvantages can usually be compensated at a different level. Disk space isn't as expensive anymore as it used to be, and programs like zip and gzip can compress files very well and very fast. Those programs are available for nearly all platforms (and are usually free). In addition, communication protocols such as modem protocols and Hypertext Transfer Protocol 1.1 (HTTP/1.1 the core protocol of the Web) can compress data on the fly, thus saving bandwidth as effectively as a binary format.

6. XML is new, but not that new

Development of XML started in 1996 and it is a W3C standard since February 1998, which may make you suspect that this is rather immature technology. But in fact the technology isn't very new. Before XML there was SGML, developed in the early '80s, an ISO standard since 1986, and widely used for large documentation projects. And of course HTML, whose development started in 1990. The designers of XML simply took the best parts of SGML, guided by the experience with HTML, and produced something that is no less powerful than SGML, but vastly more regular and simpler to use. Some evolutions, however, are hard to distinguish from revolutions... And it must be said that while SGML is mostly used for technical documentation and much less for other kinds of data, with XML it is exactly the opposite.

7. XML is license-free, platform-independent and well-supported By choosing XML as the basis for some project, you buy into a large and growing community of tools (one of which may already do what you need!) and engineers experienced in the technology. Opting for XML is a bit like choosing SQL for databases: you still have to build your own database and your own programs/procedures that manipulate it, but there are many tools available and many people that can help you.

March 1, 2010 A-3


Appendix B Public Key Cryptography and Digital Signatures

The following except from “How PGP Works” by Phil Zimmermann describes Public key Cryptography. The full text can be found at: http://www.pgpi.org/doc/pgpintro/

Public Key Cryptography

The problems of key distribution are solved by public key cryptography, the concept of which was introduced by Whitfield Diffie and Martin Hellman in 1975. (There is now evidence that the British Secret Service invented it a few years before Diffie and Hellman, but kept it a military secret — and did nothing with it. [J H Ellis: The Possibility of Secure Non-Secret Digital Encryption, CESG Report, January 1970])

Public key cryptography is an asymmetric scheme that uses a pair of keys for encryption: a public key, which encrypts data, and a corresponding private, or secret key for decryption. You publish your public key to the world while keeping your private key secret. Anyone with a copy of your public key can then encrypt information that only you can read. Even people you have never met.

It is computationally infeasible to deduce the private key from the public key. Anyone who has a public key can encrypt information but cannot decrypt it. Only the person who has the corresponding private key can decrypt the information.

The primary benefit of public key cryptography is that it allows people who have no preexisting security arrangement to exchange messages securely. The need for sender and receiver to share secret keys via some secure channel is eliminated; all communications involve only public keys, and no private key is ever transmitted or shared. Some examples of public-key cryptosystems are Elgamal (named for its inventor, Taher Elgamal), RSA (named for its inventors, Ron Rivest, Adi Shamir, and Leonard Adleman), Diffie-Hellman (named, you guessed it, for its inventors), and DSA, the Digital Signature Algorithm (invented by David Kravitz).

Because conventional cryptography was once the only available means for relaying secret information, the expense of secure channels and key distribution relegated its use only to those who could afford it, such as governments and large banks (or small children with secret decoder rings). Public key encryption is the technological revolution that provides strong cryptography to the adult masses. Remember the courier with the locked briefcase handcuffed to his wrist? Public-key encryption puts him out of business (probably to his relief).

Digital signatures

Digital signatures enable the recipient of information to verify the authenticity of the information's origin, and also verify that the information is intact. Thus, public key digital signatures provide authentication and data integrity. A digital signature also provides non-repudiation, which means that it prevents the sender from claiming that he

A-4 March 1, 2010

http://www.pgpi.org/doc/pgpintro/


or she did not actually send the information. These features are every bit as fundamental to cryptography as privacy, if not more.

A digital signature serves the same purpose as a handwritten signature. However, a handwritten signature is easy to counterfeit. A digital signature is superior to a handwritten signature in that it is nearly impossible to counterfeit, plus it attests to the contents of the information as well as to the identity of the signer.

March 1, 2010 A-5


Appendix C VBA Authentication Key Check Digit Generation '// all variables must have the right type Option Explicit Option Compare Text ' This function takes a string (domain) and generates returns a check digit for that string ' Algorithm Description ' The ASCII value of each character in the string will be multiplied by it's ' location / ordinal value. ' The results will summed and divided modulus 26. ' This will produce a value that ranges between 0 and 25. ' The result is then transformed into an ASCII character from A to Z. ' VBA functions used ' Mid$(string, start, length) is a substring function ' Asc(character) returns the value for a given character in the ASCII collating sequence ' Chr$(integer) transforms an integer into its corresponding character value in the ‘ ASCII collating sequence Function AKChkDgt(domain As String) As String Dim x As Integer Dim sum As Long sum = 0 For x = 1 To Len(domain) sum = sum + Asc(Mid$(domain, x, 1)) * x Next x = sum Mod 26 ' ASCII 65 = 'A' ' So 0..25 will be transformed into A..Z AKChkDgt = Chr$(65 + x) End Function

A-6 March 1, 2010


Appendix D VBA Integer to Base 36 Conversion Function Convert_DecToBase36(lngNumber As Long, intDigits As Integer) As String ' Converts integer to base 36 ' ' In: ' lngNumber: ' The number to be converted ' intDigits ' The number of digits to convert ' Out: ' Return Value: ' The base 36 value as a string ' VBA functions used ' Asc(character) returns the value for a given character in the ASCII collating sequence Dim strTemp As String, x As Integer, intQuotient As Long, intRemainder As Integer intQuotient = lngNumber For x = 1 To intDigits intRemainder = intQuotient Mod 36 intQuotient = intQuotient \ 36 'VB DIV operator = \ If (intRemainder < 10) Then strTemp = Chr$(48 + intRemainder) & strTemp ' ASCII 48 = '0' ' So 0..9 will be transformed into '0'..'9' Else strTemp = Chr$(65 + intRemainder - 10) & strTemp ' ASCII 65 = 'A' ' So 10..35 will be transformed into A..Z End If Next Convert_DecToBase36 = strTemp End Function

March 1, 2010 A-7


Appendix E VB CRC32 Algorithm Option Explicit Option Compare Text Private Crc32Table(255) As Long 'Public function to build polynomial table (don't touch!!) Public Function InitCrc32( _ Optional ByVal Seed As Long = &HEDB88320, _ Optional ByVal Precondition As Long = &HFFFFFFFF) As Long 'Declare counters Dim iBytes As Integer, iBits As Integer, lCrc32 As Long, lTempCrc32 As Long On Error Resume Next For iBytes = 0 To 255 lCrc32 = iBytes For iBits = 0 To 7 'Right shift unsigned long 1 bit lTempCrc32 = lCrc32 And &HFFFFFFFE lTempCrc32 = lTempCrc32 \ &H2 lTempCrc32 = lTempCrc32 And &H7FFFFFFF 'Now check if temporary is less than zero and then mix Crc32 checksum with Seed value If (lCrc32 And &H1) <> 0 Then lCrc32 = lTempCrc32 Xor Seed Else lCrc32 = lTempCrc32 End If Next 'Put Crc32 checksum value in the holding array Crc32Table(iBytes) = lCrc32 Next 'After this is done, set function value to the precondition value InitCrc32 = Precondition End Function 'CRC computation function Public Function AdDDNc32(ByVal Item As String, ByVal Crc32 As Long) As Long 'Declare following variables Dim bCharValue As Byte, iCounter As Integer, lIndex As Long Dim lAccValue As Long, lTableValue As Long On Error Resume Next 'Iterate through the string that is to be checksum-computed For iCounter = 1 To Len(Item) 'Selects the current character and converts it to an ASCII value bCharValue = Asc(Mid$(Item, iCounter, 1)) 'Only update CRC for valid ASCII characters, 32 to 126 If (bCharValue > 31) And (bCharValue < 127) Then 'Right shift an Unsigned Long 8 bits lAccValue = Crc32 And &HFFFFFF00 lAccValue = lAccValue \ &H100 lAccValue = lAccValue And &HFFFFFF 'Now select the right adding value from the holding table lIndex = Crc32 And &HFF lIndex = lIndex Xor bCharValue 'inverts the byte lTableValue = Crc32Table(lIndex) 'Then mix new Crc32 value with previous accumulated Crc32 value Crc32 = lAccValue Xor lTableValue End If Next 'Return new Crc32 checksum AdDDNc32 = Crc32 End Function Public Function GetCrc32(t As String)

A-8 March 1, 2010


Dim lCrc32Value As Long Dim InputFile, fs, InputTextStream On Error Resume Next 'Set initial CRC value Call InitCrc32 lCrc32Value = 0 lCrc32Value = AdDDNc32(t, lCrc32Value) GetCrc32 = lCrc32Value End Function ' The following function (which uses the examples from Appendix B) ' uses the code above to generate the HT and AKEHT values Public Sub Demonstrate_HBS_CRC32_Usage() Dim t As String Dim lCrc32Value As Long On Error Resume Next 'Set initial CRC value Call InitCrc32 Debug.Print "Output from Demonstrate_HBS_CRC32_Usage" Debug.Print "New Example: Weigh Slip", "(from section 1.5 of Appendix B)" lCrc32Value = 0 ' Build EC_HT t = "PS123111228920020515142272X2245T1595276420592EB998310N70011202NWeigher200212121103022O892”& _ "1X23434R234R2" lCrc32Value = AdDDNc32(t, lCrc32Value) Debug.Print "HT ", lCrc32Value, t ' Build EC_AKEHT using HT and Scaler's AK as input t = "Site123K" lCrc32Value = AdDDNc32(t, lCrc32Value) Debug.Print "AKEHT", lCrc32Value, t Debug.Print "New Example: Log Tally", "(from section 4.3 of Appendix B)" lCrc32Value = 0 ' Build EC_HT t = "PS321021009P227897854GAEB76453210N20020510279Y5212G3Tally200212270L200Q59Y2823987279YN1CE"& _ "J100101230611BR77CY T1 B8 L100 %752CEH1001521104621SR883RG T15 B21 L100 %50 IT12 IB182BR" & _ "7CN B8 L503CEH100203020420" lCrc32Value = AdDDNc32(t, lCrc32Value) Debug.Print "HT ", lCrc32Value, t ' Build EC_AKEHT using HT and Scaler's AK as input t = "Site321O" lCrc32Value = AdDDNc32(t, lCrc32Value) Debug.Print "AKEHT", lCrc32Value, t End Sub

The above example generates this output in the debug window of the VB IDE

Output from Demonstrate_HBS_CRC32_Usage New Example: Weigh Slip (from section 1.5 of Appendix B) HT -294802886 PS123111228920020515142272X2245T1595276420592EB998310N70011202NWeigher200212121103022O8921X23434R234R2 AKEHT -1432109244 Site123K New Example: Log Tally (from section 4.3 of Appendix B) HT -1225395824 PS321021009P227897854GAEB76453210N20020510279Y5212G3Tally200212270L200Q59Y2823987279YN1CEJ100101230611BR77CY T1 B8 L100 %752CEH1001521104621SR883RG T15 B21 L100 %50 IT12 IB182BR7CN B8 L503CEH100203020420 AKEHT -688355463 Site321O

March 1, 2010 A-9


Appendix F C CRC32 Algorithm #include <stdio.h> #include <string.h> #include <stdlib.h> /* * CRC32.C * * This file contains the two routines needed to perform 32 bit CRC * calculations. One is used for calculating CRCs on a block, the * other one is used on a character by character basis. * * Contains: CalculateBlockCRC32() * CalculateCharacterCRC32() * CalculateCharacterCRC32VB() * */ /* * This is the lookup table used when performing the CRC calculation. */ static unsigned long ccitt_32[ 256 ] = { 0x00000000L, 0x77073096L, 0xee0e612cL, 0x990951baL, 0x076dc419L, 0x706af48fL, 0xe963a535L, 0x9e6495a3L, 0x0edb8832L, 0x79dcb8a4L, 0xe0d5e91eL, 0x97d2d988L, 0x09b64c2bL, 0x7eb17cbdL, 0xe7b82d07L, 0x90bf1d91L, 0x1db71064L, 0x6ab020f2L, 0xf3b97148L, 0x84be41deL, 0x1adad47dL, 0x6ddde4ebL, 0xf4d4b551L, 0x83d385c7L, 0x136c9856L, 0x646ba8c0L, 0xfd62f97aL, 0x8a65c9ecL, 0x14015c4fL, 0x63066cd9L, 0xfa0f3d63L, 0x8d080df5L, 0x3b6e20c8L, 0x4c69105eL, 0xd56041e4L, 0xa2677172L, 0x3c03e4d1L, 0x4b04d447L, 0xd20d85fdL, 0xa50ab56bL, 0x35b5a8faL, 0x42b2986cL, 0xdbbbc9d6L, 0xacbcf940L, 0x32d86ce3L, 0x45df5c75L, 0xdcd60dcfL, 0xabd13d59L, 0x26d930acL, 0x51de003aL, 0xc8d75180L, 0xbfd06116L, 0x21b4f4b5L, 0x56b3c423L, 0xcfba9599L, 0xb8bda50fL, 0x2802b89eL, 0x5f058808L, 0xc60cd9b2L, 0xb10be924L, 0x2f6f7c87L, 0x58684c11L, 0xc1611dabL, 0xb6662d3dL, 0x76dc4190L, 0x01db7106L, 0x98d220bcL, 0xefd5102aL, 0x71b18589L, 0x06b6b51fL, 0x9fbfe4a5L, 0xe8b8d433L, 0x7807c9a2L, 0x0f00f934L, 0x9609a88eL, 0xe10e9818L, 0x7f6a0dbbL, 0x086d3d2dL, 0x91646c97L, 0xe6635c01L, 0x6b6b51f4L, 0x1c6c6162L, 0x856530d8L, 0xf262004eL, 0x6c0695edL, 0x1b01a57bL, 0x8208f4c1L, 0xf50fc457L, 0x65b0d9c6L, 0x12b7e950L, 0x8bbeb8eaL, 0xfcb9887cL, 0x62dd1ddfL, 0x15da2d49L, 0x8cd37cf3L, 0xfbd44c65L, 0x4db26158L, 0x3ab551ceL, 0xa3bc0074L, 0xd4bb30e2L, 0x4adfa541L, 0x3dd895d7L, 0xa4d1c46dL, 0xd3d6f4fbL, 0x4369e96aL, 0x346ed9fcL, 0xad678846L, 0xda60b8d0L, 0x44042d73L, 0x33031de5L, 0xaa0a4c5fL, 0xdd0d7cc9L, 0x5005713cL, 0x270241aaL, 0xbe0b1010L, 0xc90c2086L, 0x5768b525L, 0x206f85b3L, 0xb966d409L, 0xce61e49fL, 0x5edef90eL, 0x29d9c998L, 0xb0d09822L, 0xc7d7a8b4L, 0x59b33d17L, 0x2eb40d81L, 0xb7bd5c3bL, 0xc0ba6cadL, 0xedb88320L, 0x9abfb3b6L, 0x03b6e20cL, 0x74b1d29aL, 0xead54739L, 0x9dd277afL, 0x04db2615L, 0x73dc1683L, 0xe3630b12L, 0x94643b84L, 0x0d6d6a3eL, 0x7a6a5aa8L, 0xe40ecf0bL, 0x9309ff9dL, 0x0a00ae27L, 0x7d079eb1L, 0xf00f9344L, 0x8708a3d2L, 0x1e01f268L, 0x6906c2feL, 0xf762575dL, 0x806567cbL, 0x196c3671L, 0x6e6b06e7L, 0xfed41b76L, 0x89d32be0L, 0x10da7a5aL, 0x67dd4accL, 0xf9b9df6fL, 0x8ebeeff9L, 0x17b7be43L, 0x60b08ed5L, 0xd6d6a3e8L, 0xa1d1937eL, 0x38d8c2c4L, 0x4fdff252L, 0xd1bb67f1L, 0xa6bc5767L, 0x3fb506ddL, 0x48b2364bL, 0xd80d2bdaL, 0xaf0a1b4cL, 0x36034af6L, 0x41047a60L, 0xdf60efc3L, 0xa867df55L, 0x316e8eefL, 0x4669be79L, 0xcb61b38cL, 0xbc66831aL, 0x256fd2a0L, 0x5268e236L, 0xcc0c7795L, 0xbb0b4703L, 0x220216b9L, 0x5505262fL, 0xc5ba3bbeL, 0xb2bd0b28L, 0x2bb45a92L, 0x5cb36a04L, 0xc2d7ffa7L, 0xb5d0cf31L, 0x2cd99e8bL, 0x5bdeae1dL, 0x9b64c2b0L, 0xec63f226L, 0x756aa39cL, 0x026d930aL, 0x9c0906a9L, 0xeb0e363fL, 0x72076785L, 0x05005713L, 0x95bf4a82L, 0xe2b87a14L, 0x7bb12baeL, 0x0cb61b38L, 0x92d28e9bL, 0xe5d5be0dL, 0x7cdcefb7L, 0x0bdbdf21L, 0x86d3d2d4L, 0xf1d4e242L, 0x68ddb3f8L, 0x1fda836eL, 0x81be16cdL, 0xf6b9265bL, 0x6fb077e1L, 0x18b74777L, 0x88085ae6L, 0xff0f6a70L, 0x66063bcaL, 0x11010b5cL, 0x8f659effL, 0xf862ae69L, 0x616bffd3L, 0x166ccf45L, 0xa00ae278L, 0xd70dd2eeL, 0x4e048354L, 0x3903b3c2L, 0xa7672661L, 0xd06016f7L, 0x4969474dL, 0x3e6e77dbL, 0xaed16a4aL, 0xd9d65adcL, 0x40df0b66L, 0x37d83bf0L, 0xa9bcae53L, 0xdebb9ec5L, 0x47b2cf7fL, 0x30b5ffe9L, 0xbdbdf21cL, 0xcabac28aL, 0x53b39330L, 0x24b4a3a6L, 0xbad03605L, 0xcdd70693L, 0x54de5729L, 0x23d967bfL, 0xb3667a2eL, 0xc4614ab8L, 0x5d681b02L, 0x2a6f2b94L, 0xb40bbe37L, 0xc30c8ea1L, 0x5a05df1bL, 0x2d02ef8dL }; /* * unsigned long CalculateBlockCRC32( unsigned int count, * unsigned long crc, * void *buffer ) * * ARGUMENTS * * unsigned int count : The number of bytes in the buffer * * unsigned int crc : The initial value of the crc * * void *buffer : The buffer whose CRC is to be calculated. * * DESCRIPTION * * This routine is called to calculate the CRC-32 value of a block of

A-10 March 1, 2010


* data. The CRC-32 is the block error checking mechanism used by * Zmodem. * * SIDE EFFECTS * * * RETURNS * * A crc value. * */ unsigned long CalculateBlockCRC32( unsigned int count, /* Tag: Misc public */ unsigned long crc, void *buffer ) { unsigned char *p = buffer; unsigned long temp1; unsigned long temp2; while ( count-- != 0 ) { temp1 = ( crc >> 8 ) & 0x00FFFFFFL; temp2 = ccitt_32[ ( (int) crc ^ *p++ ) & 0xff ]; crc = temp1 ^ temp2; } return( crc ); } /* * unsigned long CalculateCharacterCRC32( unsigned long crc, * unsigned char c ) * * ARGUMENTS * * unsigned int crc : The root value of the crc * * unsigned char c : The character to be added to the CRC * * DESCRIPTION * * This routine is used to update a crc after a new character has been read * in. It calculates the cumulative CRC for the entire block so far. * * SIDE EFFECTS * * * RETURNS * * A new crc value. * */ unsigned long CalculateCharacterCRC32( unsigned long crc, /* Tag: Misc public */ unsigned char c ) { unsigned long temp1; unsigned long temp2; temp1 = ( crc >> 8 ) & 0x00FFFFFFL; temp2 = ccitt_32[ ( (int) crc ^ c ) & 0xff ]; return( temp1 ^ temp2 ); } int main() { /* Declarations */ int FileByteLength = 0; unsigned int InitialCRCValue = 0; unsigned long NewCRCValue = 0; char CurrentChar; unsigned int intCurrentChar; int i = 0; int off = 0; FILE * InputFile; // Open file InputFile = fopen ( "c:\\Sample_Input_File.txt", "r" ) ; // Get Byte length fseek (InputFile, 0, SEEK_END);

March 1, 2010 A-11


FileByteLength = ftell(InputFile); printf("The file length in bytes is %d\n", FileByteLength); // Move pointer to beginning of file fseek (InputFile, 0, SEEK_SET); // Loop through file and update CRC32 value for each character in the file for (i=off; i<FileByteLength; i++) { intCurrentChar = fgetc(InputFile); CurrentChar = intCurrentChar; // Only recalculate the CRC value for supported characters, Ascii 32 to 126 if ((intCurrentChar >= 32) && (intCurrentChar <= 126)) { NewCRCValue = CalculateCharacterCRC32(NewCRCValue, CurrentChar); } } printf("\nNew CRC Value is %d\n", NewCRCValue); // Close File fclose(InputFile); } /* * void build_table_32( unsigned long table[] ) * * ARGUMENTS * * unsigned long table[] : A 256 element array. * * DESCRIPTION * * This function can be used to build a table used to calculate CRC * values. The table shown above was built once using this table, * then stored away so we don't have to call it every time CommLib * starts up. The code is included here for the terminally curious. * * SIDE EFFECTS * * * RETURNS * * Nothing. * */ #if 0 // will never compile....... #define CRC32_POLYNOMIAL 0xEDB88320L void build_table_32( unsigned int table[] ) /* Tag: Misc private */ { int i; int j; unsigned long crc; for ( i = 0; i <= 255 ; i++ ) { crc = i; for ( j = 8 ; j > 0; j-- ) { if ( crc & 1 ) crc = ( crc >> 1 ) ^ CRC32_POLYNOMIAL; else crc >>= 1; } table[ i ] = crc; } } #endif

A-12 March 1, 2010


Appendix G Standard Defect Codes

Deduction Type Checks (Ministry Check Scaling Program)

Standard Abbreviation

Ring Count A RC

Butt Rot B BR

Star Check C SC

Straight Check D ST

Sun Check E SU

Fire Damage F FD

Goiter G GO

Heart Rot H HR

Pitch Pockets I PP

Knots K KN

Hole L HO

Missing Wood M MW

Conk Rot O CK

Pocket Rot P PR

Ring Shake Q RS

Ring Rot R RR

Sap Rot S SR

Twist T TW

Sweep U SW

Crook V CR

Water Shake W WS

Cat Face CF

Bark Seam BS

This list of codes is expected to be used consistently across the province

March 1, 2010 A-13


Appendix H Multiple Scale Station Numbers for Weight Scale

Virtual Scale Site

The HBS has been specific that a given scale platform will be identified uniquely with one scale station code. For a given scale station number, weigh slips are expected to be provided in an unbroken ascending (non-duplicated) sequence.

A given weight scale computer (per current practice) may be configured to assign weigh slips to more than one Ministry station number. This practice has been referred to as either “Virtual” or “Multi Use” Sites. These rules have been defined for vendors of weigh scale software for these situations.

● Corrections to the Ministry station number on weigh slips are NOT allowed. Where scale platforms are configured with multiple station numbers, if data is scaled against one scale station code (in error) that must then be changed for submission, this must be a two step business process. The original ticket will be voided (and submitted to the HBS to account for the ticket) and the weigh slip re-entered as a manual ticket against the proper scale station number.

Restated, the station number is NOT editable once the HBS ticket number is assigned.

● Scale Station Maintenance will be a Ministry function. Because of the Ministry reliance on the computer’s assignment of weigh slip numbers, the addition of Ministry station codes in the scale software to be a ministry function. Whatever software controls exist for sampling frequencies today, those controls must be duplicated for site maintenance.

There are two reasons currently for allowing a given scale platform to have data scaled into multiple station numbers:

● Reporting: where mills share a scale platform, populations and Timbermarks, it is currently only possible to determine deliveries to a given mill when each has its own station code. In this scenario, scale site operators will be asked to use the Primary Departure weigh slip type to record the destination mill (encoded as a scale site) in the Destination Comment field. The published definition of this field will be modified to become a valid scale site code (for all applicable weigh slip scenarios).

● Multiple licensees share a scale and each wants to be responsible for submitting their scale data to the ministry. In this scenario, multiple scale site numbers will be used for a given scale platform.

A-14 March 1, 2010


Appendix I Issue Addendum

Ensuring All Required Identifiers are Provided

There are many values on weigh slip and log tally headers that must be submitted for a given event type or business scenario. Many of these new fields are not required for the computation of an invoice but are required by the Ministry for scale control and audit purposes.

If required data elements are not provided, the HBS will reject scale returns being submitted with format errors. This may happen even if the scale data can successfully be formatted according to the XML rules provided.

Vendors must take steps to ensure that the required non-null data is submitted to the Ministry by clients in a given event type. This data MUST be finalized before digital signing occurs. Data can not be cleansed by industry business systems after the fact.

For example, the Incoming LDS Number is required for most billable piece scale and weigh slip data formats. This field is a text field that is expected to be submitted but will not be edited against a set of data yet a value must be provided to the Ministry. The value to be submitted must be collected BEFORE the scale return is digitally signed as the value to be submitted is included in the computation of the hash total field.

In the example, if a scaler does not know the Incoming LDS Number or forgets to enter it and then digitally signs the scale return, the submitted XML scale data will NOT be electronically updateable to the HBS. The required data (the Incoming LDS Number) is not provided, which will cause the document to fail on a Format edit. Further, if the XML provided is modified after being formatted for the HBS (to add the Incoming LDS Number), the Hash Total computation, also a Format edit, will fail, as the data used to originally build the XML for the HBS has been modified.

Vendors must ensure that scale data submission Format errors are minimized.

For example:

● Edit Before Signing: edit processes could ensure that all data is collected according to defined inclusion rules before scalers are allowed to sign documents.

Destination Field on Weigh Slips

It has been decided to change the definition of the Destination Comment Field to be a Destination Scale Site. The XML Schema will be modified to so that the Destination field can only contain 4 characters. Also, a cross-reference edit will be added against this field which will ensure that this field contains a valid scale site code (for all weigh slip scenarios). The original definition of this field was actually a scale site code, but this was relaxed during the HBS working committee meetings. The HBS Test Case package reflects this new definition of the field.

March 1, 2010 A-15


DDN Definition for Log Tallies

There have been several queries about the algorithms published for generating the DDN for both tallies and weigh slips. As the HBS is using the DDN, a 13 character field to identify scale documents uniquely, it is important that everyone implement the standard defined for DDN.

Regarding the treatment of the DDN for tallies, this issue has been raised. The tally DDN is dependent on the initial value of three user-entered values. Technically, it is possible that the initial values of the scale date and time, scaler number and scaler return number that will be used to assign the DDN for tallies can all be initially populated with null, default or garbage values. It is recommended that the DDN be assigned later in the process or vendors implement a reasonableness check for the contents of the DDN.

Examples of reasonableness checks include:

● Verify that the newly computed DDN does not exist in the set of data on the current handheld

● Confirm the business keys that the DDN is based on at the time the DDN is assigned.

E.g.: Please confirm licence: X123, Raft 92 and Scale Date: 02/10/18 Y or N? N would return the user to the header update screen without initially populating a DDN.

A-16 March 1, 2010


Appendix J Validating XML Structure Using an XML Schema Processor

Scale data submitted to the Ministry of Forests and Range must follow exactly the format defined in the published XML schema. Scale data submitted via XML must be formatted to exactly the rules specified by the published XSD schema – HBS XML Schema for Detailed Scale Returns (Version 5). The first validation performed by the HBS is to validate the XML against the published schema. This validation is a singular operation. If one element in the XML file has the incorrect format or is positioned incorrectly, the entire file is deemed invalid and will be rejected as having the improper format.

All parties submitting XML examples to the Ministry for verification should first ensure that their XML example files will validate against the published XSD schema file. This validation is performed by using an XML Schema Processor product.

The following example outlines one possible set of steps for performing this validation. The following example is not meant to be an endorsement or recommendation to purchase the referenced product. It is just presented to show the necessary steps. Any equivalent product could be used.

1. Install an XML Schema Processor. For example, download and install XML Spy:

http://link.xmlspy.com/download.html

This is a XML IDE product that allows you to build XML schemas and XML data files and validate the latter against the former. This product has a 30-day evaluation license that can be used for this scenario. For this example, evaluating the XML Spy Home Edition, Version 5 is sufficient.

2. Save the HBS latest Schema file locally (e.g., to c:\hbs\xml\HBS_Schema_V5.xsd)

3. Start XML Spy. Open the XML file to be validated (generated by your software) in XML spy using the File | Open… dialog (for this step it is recommended the XML file have an extension of "xml".

March 1, 2010 A-17

http://link.xmlspy.com/download.html


Figure A.1 Open File Dialogue of XML Spy.

4. Inform XML Spy that this file must be validated using the latest version of the published schema. Use the DTD/Schema | Assign Schema… dialog to perform this assignment.

Figure A.2 Assign Schema Dialogue of XML Spy.

Select OK.

5. Verify that the XML file is well formed by using the "Check well-formedness" button (with the yellow checkmark) or pressing F7.

A-18 March 1, 2010


Figure A.3 Tool-tip Showing the “Check well-formedness” function of XML Spy.

6. Next verify that the XML file validates against its schema by using the "Validate file" button (with the green checkmark) or pressing F8.

Figure A.4 Tool-tip showing the “Validate File” function of XML Spy.

March 1, 2010 A-19


7. Ensure that all errors like the example presented below are not present in the XML submission file:

Figure A.5 enter fig name here.

A-20 March 1, 2010


Appendix K Example Printed Scale Documentation

Figure A.6 Weigh Slip Example.

Figure A.7 Weigh Scale Safety Sheet Example.

Figure A.8 Weight Scale Daily Audit Log Example.

March 1, 2010 A-21


Appendix L Version Numbering Scheme

Figure A.9 Log Tally Example – Piece Scale.

A-22 March 1, 2010


Figure A.10 Log Tally Example – Sample Scale (with Defects)(Page 1).

Figure A.11 Log Tally Example – Sample Scale (with Defects)(Page 2).

March 1, 2010 A-23


Figure A.12 Piece Scale Species Grade Summary Report.

Figure A.13 Piece Scale Daily Load Listing.

A-24 March 1, 2010


Appendix M Version Numbering Scheme

Figure A.14 Version Numbering Scheme (Page 1).

March 1, 2010 A-25


Figure A.15 Numbering Scheme (Page 2).

A-26 March 1, 2010


Major Software Revisions

Major revisions require vendors to submit test data to the Ministry for validation.

Vendors are required to follow the processes for software approval described in the document. On successful validation of the vendor supplied XML test transmissions, the Ministry will issue a letter to the vendor stating approval of the current software version / revision and note any acceptable exceptions.

A major revision is classified as a modification to the software that has the potential to impact the following HBS requirements:

● DDN Construction,

● Document versioning,

● XML Formatting,

● Event Type assignment,

● Volume calculation.

Minor Software Revisions

Minor revisions will not require vendors to submit test data to the Ministry for validation. Vendors are permitted to release minor revisions to Ministry licensed scale sites and must inform the Ministry of an incremental release.

A minor revision is classified as a modification to the software that corrects a deficiency or provides an enhancement without compromising routines for HBS critical functions.

March 1, 2010 A-27


Appendix N Scale Data Controls and Processing Conventions

1. Introduction.

2. How to Use this Appendix.

3. General and User Control Requirements.

4. Weight scale Controls.

5. Piece scale Controls.

6. Audit and Self-assessment Procedures.

7. Standards

1. Introduction

All parties collecting, processing, or submitting scale data must ensure there is an adequate level of internal control in place to ensure all scale data are complete, accurate and secure. Internal control includes scale data controls, processing conventions and administrative processes. This appendix outlines the scale data control requirements and practices which would be in place whenever information is processed using a handheld computer, a personal computer, a mainframe or hand compilation.

All systems used to process scale data are subject to periodic audit by the Ministry. Licensees and other parties processing scale data may be required to assess and report their own compliance with control requirements. Section 6 of this appendix outlines self assessment procedures. Where the ministry considers internal controls to be deficient, it may disallow parties from processing scale data.

2. How to Use this Appendix

This appendix identifies control requirements and their intent in meeting the overall objective of complete, accurate, and secure scale data. Control practices are described as essential or desirable.

Control practices which are described as essential are viewed as fundamental to maintaining a complete and accurate reporting of revenue. These or alternative processes which meet the same objectives are mandatory.

Desirable practices are viewed as less fundamental, however, they constitute sound business practice and contribute to improved data control. These or similar approaches should be included in any mix of data controls and processing conventions to satisfy internal control needs.

A-28 March 1, 2010


Section 6 of this appendix outlines procedures for any party to assess their compliance with those guidelines.

This appendix is technical in content and is directed at persons who develop data processing systems and conduct system audits. For clarification on any aspect of this appendix, please contact Revenue Branch.

3. General and User Control Requirements

Control Requirements Control Practices Rating

1. Audit Trail Objective: Required to provide data continuity from source documents to final summary and ability to verify the completeness and accuracy of transactions.

i. ii. iii. iv. v.

The unique scale site number assigned by the ministry must be captured and appear on all reports and data submissions generated from that site. All changes made to scaling information after a scale return has been prepared and signed must be logged. This Audit Change File must be maintained and available for review by the ministry. Where initial data has been changed by a manual entry, the system must capture the userID of the person performing the change in the Audit Change File. Users will have the capability to view and print the Audit Change Log File, but will be prevented from changing or deleting any data. Instances of data input being overridden by a manual entry must be clearly indicated on all the data output forms.

E

D

D

D

E

E = Essential

D = Desirable

March 1, 2010 A-29



2. Logical Security Objective: Access to confidential files restricted to authorized persons.

i. ii. iii. iv.

Access to the following files must be retricted through user identification and password to Ministry of Forests and Range personnel.

Sampling Plans,

List Data File,

Purge Data File, and

Ministry Passwords. After software installation, master passwords must be removed and functional passwords enabled. Master files and data critical to scale data compilation must be protected through a checksum authentication method. The checksum detects files that have been altered by any means. Installed program code must be limited to object code only. Source and object code must be version controlled and placed in trust for safekeeping by the software vendor and not accessible to users.

E

E

E

E

3. Data Transmission Objective: Controls to ensure transmissions are complete.

i. ii. iii.

Data transmission must be completed through standard software protocols which support cyclical redundancy checking and other forms of data integrity control. The application system must provide control total verification on the number of records sent and received. During or after transmission of scale data the number of pieces and total volume must be confirmed by the sending and receiving software system.

E

E

E

A-30 March 1, 2010



iv.

As part of the transmission for scale data, the following information must be retained in a data transmission audit file:

original data source,

scaler number,

scale site number,

date(s) of scale,

number of returns,

timber mark(s),

first return number, and

last return numbers

E

4. Backup and Recovery Objective: Routine procedures designed to accurately and quickly recover lost or destroyed data.

i. ii.

Backup procedures must be documented and then tested every six (6) months to ensure they provide the intended recovery. Evidence of testing must be retained. Where data is known to be lost, the procedures outlined in Section 11.7 of the Scaling Manual must be followed.

E

E

March 1, 2010 A-31



5. User Training and Documentation Objective: Skilled and well trained operators supported with user and system documentation to reduce risk of operator error and ensure data accuracy.

i. ii. iii. iv.

Staff must be adequately trained and must be conversant with procedures to follow in the event of software or hardware failure included in Chapter 11 of the Scaling Manual. Each software application must be supported by a user manual. Application programs should make provision for help facilities. Documentation must highlight user security procedures, such as:

Equipping their PC with virus scanning systems, and

Scanning diskettes prior to use.

E

E

E

E

6. Support Facilities Objective: Timely technical support to users for problem resolution.

i. ii.

Users must be able to contact a named resource during normal business hours to obtain support for both hardware and software. Suitable user and system documentation must be retained and be available to Ministry of Forests and Range.

E

E

7. Data Integrity Objective: Ensure the data is complete, safe and secure during data entry and processing.

i. ii. iii.

A user must be prevented from exiting the program in a manner which leads to incomplete information being recorded to files which create scale returns. Users are responsible to ensure that proper procedures are in place for the timely and secure submission of source documents to the ministry. Safe and secure storage procedures must be in place.

E

E

E

A-32 March 1, 2010



iv. v.

The program should perform an internal data integrity review to ensure that the databases are complete and accurate. The data integrity review includes reprogramming edits, checking control totals against detail values and reviewing data indices. After a scaler has completed a scale return the electronic version of the scale return must be marked to indicate the return is final. Any changes to the return after this point must be recorded into the Audit Change Log File.

D

E

8. Physical security over computer assets Objective: To protect hardware and software against theft, tampering and physical destruction.

i. ii. iii.

All non-portable computing devices must be configured in a manner that will provide protection in the event of a loss of power. For portable computing devices, redundancy in the form of stand-by battery packs and internal “dual” power strategies must be in place. Security procedures should be designed to limit the probability of theft. These may include limited access to non-portable equipment, locking cabinets or similar safeguards for unattended portable equipment. Computing devices must be designed to operate in the conditions they will be subjected to. Provisions must be made for:

operation in ambient temperatures between -40c and 35c.

dust and other contaminants,

rain and snow,

the risk of being dropped,

E

D

E

March 1, 2010 A-33



vibration, static electricity, shock or other adverse operating condition, and

floating or retrieval if used on a water sort.

4. Weight Scale Controls


1. Audit Trail Objective: Required to provide data continuity from source documents to final summary and ability to verify completeness and accuracy of transactions.

i. ii. iii.

The load arrival number must be in sequence and cannot be changed or modified by the users. Instances of the weight scale input being overridden by a manual entry must be recorded in the Audit Change Log File. The weight scale load slip must indicate that the input has been manually entered. The weight scale load slip must include the identity of the scale site generating the information.

E

E

E

2. Data Retention Objective: Ability to recreate previous data in the event of loss and for audit confirmation.

i. ii.

The current and previous twenty-four (24) months of weight scale load slips and any changes must be accessible in computer readable magnetic form. Backup and recovery procedures must be in place to secure data and minimize downtime. Procedures must be documented and available for review by the ministry.

E

E

A-34 March 1, 2010



3. Stratum Control Objective: Requirement to maintain the unique identity of all weight scale data and ensure the integrity of sampling plans.

i. ii.

All billable data collected under weight scaling must carry the unique eight (8) digit identity assigned by the ministry (i.e., population/stratum/year). Changes to the strata file must be recorded in an Audit Change Log File. This file must identify:

the user making the change,

date and time, and

a record of the data before and after the change.

E

D

4. Weigh-in/Weigh-out Objective: To enable a complete and accurate record of all weightings.

i. ii. iii. iv.

All weighings (gross, net and tare weights) must be recorded. Weightings not contributing to the weight scale population are to be noted, “For record purposes only”. If a weight scale load slip must be edited, voided or changed, the original must contain an explanation and the initials of the scaler/weigh master making the change. This must be attached to the reprinted load slip. The accuracy and completeness of the FS 1217 is the exclusive responsibility of scaling personnel and must be clearly indicated by either a manual or electronic signature. Manual entry or override of the weight must be recorded to an Audit Change Log File. This file must contain the before and after weight and user identification.

E

E

E

E

March 1, 2010 A-35



5. Data Input Objective: To ensure the completeness of data

i. ii.

Where “batches” of information are processed, the following batch controls are in place:

the total volume, number of loads and number of documents in the batch are matched to totals processed, and,

an audit trail links the source data or the batch to the processed result.

E

5. Piece Scale Controls


1. Data Retention Objective: Ability to recreate previous data in the event of loss and for audit confirmation.

i. The scaler must obtain a printout and perform a backup of all scale returns after each load has been scaled and before it has been moved. Retention of scale returns must be as per the scale site authorization.

E

2. Data Editing Objective: Designed to confirm data validity of various processing stages.

i. ii.

Piece scale details are to be edited against valid species and grade combinations. Error messages are displayed at the time of entry and cannot be by-passed without correction. If editing can be disabled to streamline the data entry function, the editing process must be completed before any reporting or transmission takes place.

E

E

A-36 March 1, 2010



iii. iv. v. vi.

Any changes made to scaling information after a scale return has been prepared and signed must be logged by the software. This Audit Change Log File is to contain the following:

User making the change,

Date and time, and

Before and after image of the modified data. The Audit Change Log File must be maintained and available for review by the ministry. Species and grades should be edited against valid dimensions for each species and grade comination. The computing program should provide a facility for data elements to be displayed and reviewed. Data elements include:

log dimensions,

log species and grade,

number of pieces,

total volume,

date of scale,

scale site,

timber mark, and

weight, if applicable.

D

D

D

D

E

E

D

March 1, 2010 A-37


6 Audit and Self Assessment Procedures

All parties processing scale data are subject to periodic audits by the ministry. Licensees and other parties developing software or processing scale data may also be required to assess and report their own compliance with this appendix.

Periodic audit and self assessment fulfil several objectives:

● to provide a standard means to assess the risk that scale data may not be accurate, complete or secure,

● to help isolate any internal control deficiencies which should receive attention, and

● to help satisfy all users that the data is reliable.

Figure A.17 shows the self assessment questionnaire/report format. This document is available in both hard copy and disk. This questionnaire is to be completed:

● at the request of the ministry, and

● upon the introduction of a new version of scaling software and/or hardware.

Where either ministry audits or the self assessment procedures identify internal control deficiencies, it is the responsibility of the licensee and the person processing or submitting scale data to ensure they are remedied. In all instances, the ministry must be advised in writing of the changes made to remedy the deficiencies.

If ministry audits or self assessment reveal major deficiencies which may impact the integrity of scale data, the ministry may:

● rescind or suspend its approval to process scale data, and/or

● cancel the scale site authorization.

7. Standards

Ministry of Forests and Range standards are in place for:

a. Data Input:

● species codes (see Table N-1),

● valid species and grade combinations (see Table N-2),

● edit conventions to assess gross top diameter against each species/grade combination (see Table N-3), and

A-38 March 1, 2010


b. Data Processing:

● computation of Scaling Volumes inclusive of rounding conventions (see Appendix 1 of the Scaling Manual).

c. Reporting:

● deadlines – as specified in the scale site authorization, and

d. Emergency Procedures:

● emergency procedures in the event of a weight scale breakdown (see Chapter 14 of the Scaling Manual), and

● procedures to reconstruct scale data which is lost (see Section 11.7.2 of the Scaling Manual).

Table N-1 Species Codes

Alder AL

Arbutus AR

Aspen AS

Balsam fir BA

Birch BI

Cedar CE

Cypress CY

Cottonwood CO

Douglas-fir FI

Hemlock HE

Larch LA

Lodgepole Pine LO

Maple MA

Spruce SP

White Pine WH

Whitebark Pine WB

Willow WI

Yellow Pine YE

Yew UU

March 1, 2010 A-39


Table N-2 Valid Species/Grade Combinations

Coast

Species Valid Grades

All Z (species code R for Weight Scale data)

BA and HE D, F, H, I, J, U, X, Y, Z

CE D, F, H, I, J, K, L, M, U, X, Y, Z

CY D, F, H, I, J, U, X, Y, Z

FI B, C, D, F, H, I, J, U, X, Y, Z

LO, WH, YE, WB D, F, H, I J, U, X, Y, Z

SP D, E, F, G, H, I J, U X, Y, Z

Broadleaf and UU (Blank), Y, Z

Interior


All 1

2

4

6

Z (species code R for Weight Scale data)

A-40 March 1, 2010


Table N-3 Species/Grade Edit by Minimum Gross Top Radii

Validation checks:

● Check that numeric data fields only contain digits, and

● Check that the top radius for the species and grade combination is not less than the minimum value specified in parentheses.


CY D(30), F(25), H(19), I(19), J(8), U(5), X(5), Y(5), Z(0)

BA D(33), F(25), H(19), J(8), U(5), X(5), Y(5), Z(0)

CE D(25), F(25), H(19), J(8), K(25), L(19), M(13), U(5), X(5), Y(5), Z(0)

SP D(50), E(38), F(38), G(30), H(19), J(8), K(25), L(19), M(13), U(5), X(5), Y(5), Z(0)

WH, LO, YE, WB D(38), F(30), H(19), J(8), U(5), X(5), Y(5), Z(0)

FI B(30), C(19), D(38), F(30), H(19), I(19), J(8), U(5), X(5), Y(5), Z(0)

HE D(33), F(25), H(19), I(19), J(8), U(5), X(5), Y(5), Z(0)

AL, UU, AS, BI, CO, MA, OT

Blank(5), Y(5), Z(0)

March 1, 2010 A-41


Figure A.16 Self Assessment Questionnaire/Report (cover page).

A-42 March 1, 2010


General and User Control Requirements

Control

Requirements

Control Practices

Compliance

Y/N

Describe Practices in Place to Meet Control

Requirements

1. Audit Trail i. The unique scale site number assigned by the ministry must be captured and appear on all reports and data submissions generated from that site.

ii. All changes made to scaling information after a scale return has been prepared and signed must cause reversioning to occur. The Audit Change Log file must be maintained and available for review by the ministry.

iii. Where initial data has been changed by a manual entry, the system must capture the userID of the person performing the change in the Audit Change Log file.

iv. Users will have the capability to view and print the Audit Change Log File, but will be prevented from changing or deleting any data.

v. Instances of data input being overridden by a manual entry must be clearly indicated on all the Audit Report Log.

2. Logical Security

i. Access to the following files must be restricted through user identification and password to Ministry of Forests and Range personnel.

Sampling Plans,

List Data File,

Purge Data File, and

Ministry Passwords.

March 1, 2010 A-43


Control

Requirements

Control Practices

Compliance

Y/N


Requirement

Logical Security cont.

ii. After software installation, master passwords must be removed. The master password used to install must not be available to the user.

iii. Master files and data critical to scale data compilation must be protected through a checksum authentication method. The checksum detects files that have been altered by any means.

iv. Installed program code must be limited to object code only. Source and object code must be version controlled and placed in trust for safekeeping by the software vendor and not accessible to users.

3. Data Transmission

i. Data transmission must be completed through standard software protocols which support cyclical redundancy checking and other forms of data integrity control.

ii. The application system must provide control total verification on the number of records sent and received.

iii. During or after transmission of scale data the number of pieces and total volume must be confirmed by the sending and receiving software system.

A-44 March 1, 2010


Control

Requirements

Control Practices

Compliance

Y/N


Requirement

iv. As part of the transmission process for scale data, the following information must be retained in a data transmission audit file:

original data source,

scaler number,

scale site number,

date(s) of scale,

number of returns,

timber mark(s),

first return number, and

last return number.

4. Backup and Recovery

i. Backup procedures must be documented and then tested every six (6) months to ensure they provide the intended recovery every six months. Evidence of testing must be retained.

ii. Where data are known to be lost, the procedures outlined in Chapter 11 of the Scaling Manual must be followed.

5. User Training and Documentation

i. Staff must be adequately trained and must be conversant with procedures to follow in the event of software or hardware failure included in Section 11.7 of the Scaling Manual.

ii. Each software application must be supported by a user manual.

March 1, 2010 A-45


Control

Requirements

Control Practices

Compliance

Y/N


Requirement

iii. Application programs should make provision for help facilities.

iv. Documentation must highlight user security procedures, such as:

Equipping their PC with virus scanning systems, and

Scanning diskettes prior to use.

6. Support Facilities

i. Users must be able to contact a named resource during normal business hours to obtain support for both hardware and software.

ii. Suitable user and system documentation must be retained and be available to Ministry of Forests and Range.

7. Data Integrity

i. A user must be prevented from exiting the program in a manner which leads to incomplete information being recorded to files which create scale returns.

ii. Users are responsible to ensure that proper procedures are in place for the timely and secure submission of source documents to the ministry.

iii. Safe and secure storage procedures must be in place.

A-46 March 1, 2010


Control

Requirements

Control Practices

Compliance

Y/N


Requirement

iv. The program should perform an internal data integrity review to ensure that the databases are complete and accurate. The data integrity review includes re-programming edits, checking control totals against detail values and reviewing data indices.

v. After a scaler has completed a scale return the electronic version of the scale return must be marked to indicate the return is final. Any changes to the return after this point must be entered into the Audit Change Log File.

8. Physical security over computer assets

i. All non-portable computing devices must be configured in a manner that will provide protection in the event of a loss of power. For portable computing devices, redundancy in the form of stand-by battery packs and internal “dual” power strategies must be in place.

ii. Security procedures should be designed to limit the probability of theft. These may include limited access to non-portable equipment, locking cabinets or similar safeguards for unattended portable equipment.

March 1, 2010 A-47


Control

Requirements

Control Practices

Compliance

Y/N


Requirement

iii. Computing devices must be designed to operate in the conditions they will be subjected to. Provisions must be made for:

operation in ambient temperatures between -40C and 35C,

dust and other contaminants,

rain and snow,

the risk of being dropped,

vibration, static electricity, shock or other adverse operating condition, and

floating or retrieval if used on a water sort.

A-48 March 1, 2010


Weight Scale Controls

Control

Requirements

Control Practices

Compliance

Y/N


Requirement

1. Audit Trail i. The load arrival number must be in sequence and cannot be changed or modified by the user.

ii. Instances of the weight scale input being overridden by a manual entry must be recorded in the Audit Change Log File. The weight scale load slip must indicate that the input has been manually entered.

iii. The weight scale load slip must include the identity of the scale site generating the information.

2. Data Retention

i. The current and previous twenty four (24) months of weight scale load slips and any changes must be accessible in computer readable magnetic form.

ii. Backup and recovery procedures must be in place to secure data and minimize downtime. Procedures must be documented and available for review by the ministry.

3. Stratum Control

i. All billable data collected under weight scaling must carry the unique eight (8) digit identity assigned by the ministry (i.e., population/stratum/year).

March 1, 2010 A-49


Control

Requirements

Control Practices

Compliance

Y/N


Requirement

ii. Changes to the strata file must be recorded in an Audit Change File. This file must identify:

the user making the change,

date and time, and

a record of the data before and after the change.

4. Weigh-in /Weigh-out

i. All weighings (gross, net and tare weights) must be recorded. Weighings not contributing to the weight scale population are to be noted “For record purposes only”.

ii. If a weight scale load slip must be edited, voided or changed, the original must contain an explanation and the initials of the scaler/weigh master making the change. This must be attached to the reprinted load slip.

iii. The accuracy and completeness of the FS 1217 is the exclusive responsibility of scaling personnel and must be clearly indicated by either a manual or electronic signature.

iv. Manual entry or override of the weight must be recorded to an audit change file. This file must contain the before and after weight and user identification.

A-50 March 1, 2010


Control

Requirements

Control Practices

Compliance

Y/N


Requirement

5. Data Input i. Where “batches” of information are processed, the following batch controls are in place:

The total volume, number of loads and number of documents in the batch are matched to totals processed, and

An audit trail links the source data or the batch to the processed result.

March 1, 2010 A-51


Piece Scale Controls

Control

Requirements

Control Practices

Compliance

Y/N


Requirement

1. Data Retention

i. The scaler must obtain a printout and perform a backup of all scale returns after each load has been scaled and before it has been moved.

2. Data Editing

i. Piece scale details are to be edited against valid species and grade combinations.

ii. Error messages are displayed at the time of entry and cannot be by-passed without correction. If editing can be disabled to streamline the data entry function, the editing process must be completed before any reporting or transmission takes place.

iii. Any changes made to scaling information after a scale return has been prepared and signed must be logged by the software. This Audit Change Log File is to contain the following:

User making the change,

Date and time, and

Before and after image of the modified data.

iv. The Audit Change Log File must be maintained and available for review by the ministry.

v. Species and grades should be adited against valid dimensions for each species and grade combination.

A-52 March 1, 2010


Control

Requirements

Control Practices

Compliance

Y/N


Requirement

vi. The computing program should provide a facility for data elements to be displayed and reviewed. Data elements include:

log dimensions,

log species and grade,

number of pieces,

total volume,

date of scale,

scale site,

timber mark, and

weight, if applicable.

March 1, 2010 A-53


Figure A.17 Self Assessment Questionnaire/Report (page 17).

A-54 March 1, 2010


Appendix O BOS Sampling Algorithm

Ministry of Forests and Range was advised to replace the current Block Random Sampling algorithm because it was predictable. In 2008, the Ministry had reviewed algorithms used to select samples for weigh scaling operations. After careful statistical comparison of several sampling algorithms, the Ministry had decided to implement the BOS sample algorithm.

The value of ‘c’ must be calculated for each strata and displayed on the screen. ONLY Ministry staff can edit the value of ‘c’.

BOS Sampling Algorithm

For a given stratum, let denote the target sample size, and denote the total number of loads expected in the population. Therefore the sampling frequency is

n NnNF = (i.e.

about one out of every F loads are to be sampled). Define the tuning parameter as [ ]1,5max Fc = .

When the kth load arrives ( ), draw an independent random number K,2,1=k kε from the Uniform(0,1) distribution. Define as the number of loads selected among the first

loads in the population (kn

1−k 01 =n ).

If ( )⎥⎦⎤

⎢⎣⎡ −

+< kk n

Fk

c11ε then load is selected, otherwise it is not. k

The procedure terminates when the last load is given the opportunity to be sampled.

This algorithm endeavours to spread out the n sampled loads so that they match the sampling frequency (F) with high probability. The tuning parameter c controls the regularity (i.e. predictability) of the samples. For small values of c (e.g. just above its lower limit of zero), the samples will perfectly coincide with the sampling frequency, and hence become completely predictable. For large values of c (e.g. just below its upper limit of nN ), the samples may deviate dramatically from the sampling frequency, and hence the resultant ‘flow’ of samples is little different than a simple random sample. Analysis has shown that to maintain a reasonable flow of samples without compromising predictability, the recommended approach is to preset c for each stratum as the larger of the sampling frequency divided by 5 or one.

Once c is predetermined and applied separately for each strata, the algorithm involves generating an independent uniformly distributed random number kε at the arrival of each and every load in the population. For each load, the random number is compared to a value (i.e. the right hand side of the above inequality) to determine whether the load should be designated as a sample.

The algorithm is accommodating in that if more (or less) loads arrive than estimated, the algorithm will still sample according to the sampling frequency.

March 1, 2010 A-55



A-56 March 1, 2010

Documents

HBS Technical Specifications for Industrypublish/...VB CRC32 example code Sierra Systems 2003-05-16 4.0 Added Special Forest Products to descriptions for Piece Scale requirements