hyhorshuv - United Kingdom Hydrographic Office

ARCS Implementation Additional Notes for Licensed Developers Version 1.4 February 2000 

$5&6,PSOHPHQWDWLRQ 

$GGLWLRQDO1RWHV 

)RU/LFHQVHG 

'HYHORSHUV 

9HUVLRQ)HEUXDU\ 

‹&URZQ&RS\ULJKW 

1


THIS PAGE IS INTENTIONALLY BLANK 

2


ARCS IMPLEMENTATION - 

ADDITIONAL NOTES FOR LICENSED DEVELOPERS 

Introduction 

These guidance notes are provided to help you through the various stages of your ARCS development, 

from the granting of your Manufacturer’s Agreement to the final licensing of your ARCS compatible 

system. The notes are written in separate task specific sections that will hopefully cover all aspects of your 

ARCS development programme. They can be used together, or split into their relevant sections, for your 

own company wide distribution. 

Should you require additional copies of the whole document, or just individual sections, please contact 

Business Development (Product Applications). Please make your own copies of the document if you so 

wish but do not release them to any third party. Throughout the remaining text Business Development 

(Product Applications) will be abbreviated to BD(PA). 

Feedback 

Any comments or suggestions you have relating to this documentation or any other aspect of the support 

provided to you by BD(PA) would be welcomed as a means of continually improving the service we offer. 

Please contact BD(PA). 

Proprietary information 

All Proprietary Information supplied to you will be recorded in Schedule B of your Manufacturer’s 

Agreement. The schedule will be updated each time information is released to you; two copies of the 

amended schedule will be sent to you, one must be signed and returned to BD(PA). 

List of sections 

1. Stages in the ARCS Manufacturer Licensing and Development Process 

2. Product Support 

3. Software Implementation - Security 

4. Software Implementation - System Functionality 

5. Other Topics 

Annex A - Useful Contact Names and Numbers 

Annex B - Sample Security Implementation Report 

Annex C - UKHO Account Information 

3



4


SECTION 1 

STAGES IN THE ARCS MANUFACTURER LICENSING 

AND DEVELOPMENT PROCESS 

1.1 Developer’s pack contents 

You are now licensed to develop ARCS compatible systems. You should have been supplied with the 

following items in this package: 

ARCS Security - Manufacturer’s Specifications document; 

Encrypted sample data in HCRF Version 2.00 on CD-ROM; 

Promotional Pack including general ARCS brochures; 

Company specific manufacturer development codes (MIDs); 

Skipper Problem test pack (only OEMs developing for the Skipper service); 

This document. 

You should also have received a copy of your completed ARCS Manufacturer’s Licence Agreement for 

your records. 

1.2 Addition of your company’s details to UKHO promotional material 

Once you are licensed, your company’s details can be added to the main UKHO chart catalogue (NP131) 

and to the general ARCS brochures as an OEM developing ARCS compatibility. If you would like your 

company’s details added to these please let BD(PA) know. Examples of the general ARCS brochures are 

provided in the Promotional Pack and can be used as pro-formers for the data that we will require. 

1.3 Initial development using encrypted sample data 

Initial development work should involve the decryption and use of the test charts that are supplied on the 

sample CD. The document ‘ARCS Security - Manufacturer’s Specifications’ defines how to decrypt 

ARCS data and also details the licensing checks that are to be performed. Technical assistance on 

decryption and system functionality can be provided by BD(PA). (See Annex A). 

The sample CD contains only 4 charts. Please remain aware, during this initial stage, of the problems 

associated with handling larger numbers of charts. It is easy to design a system that works well with 4 

charts, but is very unwieldy with large numbers. 

Associated documents that you will need to consult during development are: 

HCRF Version 2.0 (NP 760) - the ARCS data format document; 

ARCS Systems Developer Implementation Guide (ASDIG) which gives some guidance on system 

functionality; 

These notes ‘ARCS Implementation - Additional Notes for Licensed Developers’. 

1.4 Development using commercial ARCS data 

5


Once your system can use the charts on the sample CD, to continue your development, you will need to 

access charts on the commercial CDs. To do this you will have to create a User Permit, as described in 

the Security Specifications, using the company specific manufacturer development MIDs supplied. This 

should be sent, with the PIN number and UID, to BD (PA). Normally, the UID is not to be disclosed. 

However if it is included with the first User Permit we will be able to check that your User Permit creation 

routine is correct. 

When we receive your User Permit, we will create a set of chart permits that contain all the ‘problem’ 

charts. These charts should allow you to test how your system handles all types of ARCS data. We will 

also include a selection of other charts. This will allow you to test problems associated with having large 

chart outfits and having chart outfits spread over a number of different CDs. Depending on the service 

types that you wish to develop, we will supply Navigator and / or Skipper versions of the chart permits. 

Should you require additional charts during your development please ask. It is unlikely that we will refuse 

any reasonable requests for chart permits for your development system. 

1.5 Demonstration charts 

All licensed ARCS manufacturers may use special versions of charts, 107, 109, 3497 (River Humber and 

Approaches) and 4000 (the World) for free display within either stand-alone demonstration software or 

as part of their product. 

If you wish to use these data please contact BD(PA). The security information needed to decrypt the charts 

will be released under the terms of your existing Manufacturer’s Licence and will be added to the list of 

Proprietary Information supplied to your company. The codes must be incorporated into your software so 

the user cannot access them. 

The conditions placed on the use of the data are: 

a) When the charts are displayed they must carry a prominent warning at all times: 

“NOT TO BE USED FOR NAVIGATION - DEMONSTRATION ONLY” 

b) The charts must not be usable with interfaced equipment such as GPS and Radar other 

than in simulation mode. 

c) The user is provided with the demonstration charts free of charge. 

d) The user gains access to the demonstration charts in a recognisably different way to any 

‘live’ ARCS chart stored in the system. 

e) It is made clear to the end user that the demonstration charts are not up to date. 

The conditions described above will be added to Schedule C of your ARCS Manufacturer’s Agreement. 

1.6 Product promotion during development 

Once your product is capable of using commercial ARCS data, you may wish to demonstrate it to 

prospective customers or at trade shows etc. There is no problem with this providing that it is made quite 

clear that what is being viewed is a development system. 

6


You must not ‘clone’ security devices. Hence you will have to create a different User Permit for each 

demonstration system. This in turn will require you to contact BD(PA) so as to obtain chart permits etc. 

Please keep the number of demonstration systems to a minimum. Unless you can provide us with sound 

commercial reasons why you need more, we will limit you to three (3) demonstration licences for any given 

period. 

We will be happy to supply permits for charts of the area local to the show etc (providing that ARCS charts 

currently cover the area). However, to avoid embarrassment, it is recommended that you allow three weeks 

notice to obtain such charts so that standard post can be used for delivery. If we have to courier them to 

you a charge may be levied. 

1.7 Vessel trials 

As your development continues, you may wish to conduct alpha or beta trials of your software on board 

vessels. Again, we will be happy to supply chart permits for these purposes. Please contact BD(PA) 

giving details of the User Permit, PIN, service type (Navigator / Skipper), vessel / shipping company 

details and charts required. The licence(s) will be made out to your company and it will be your 

responsibility to pass the data, including any update CDs etc, to your trial vessel as and when required. 

As with product promotion above, you must create a different User Permit for each system and obtain 

appropriate chart permits for each one. To avoid embarrassment, it is recommended that you allow three 

weeks notice to obtain such charts so that standard post can be used for delivery. If we have to courier 

them to you a charge may be levied. 

When the trial has finished, you must remove the system from the vessel, or at least provide the vessel with 

a different User Permit / PIN, so that the trial charts can no longer be used. The trial User Permit / PIN 

can then be re-used on a different vessel if required. 

Apart from in exceptional circumstances, we will not issue you with more than two (2) trial licences for 

any given period. 

1.8 Security implementation report 

The terms of the licence assume that you will exactly match the conditions set out in the document ‘ARCS 

Security Manufacturer’s Specifications’ and Schedule C of the Manufacturer’s Agreement. However, 

because of any specific ways that your software may handle data, it may prove impossible, or undesirable, 

for certain aspects to be followed exactly. Such proposed differences must be discussed with BD(PA). 

If your proposed method is considered to be adequate by BD(PA), consideration will be given to formally 

granting you a dispensation to use it. 

You are required by clause 10.1 of the Manufacturer’s Agreement to submit a security implementation 

report prior to attending the system evaluation. This report should contain details of the final method 

adopted for securing ARCS data within your system including details of any dispensations granted. A 

suggested layout for the report is attached at Annex B. 

1.9 System evaluation (compliance test) 

System evaluation is performed to ensure compliance with the Security Specifications and mandatory 

7


system functionality. It is not a formal approval of your software. The bulk of the test mirrors the test laid 

out in Annex A of the document ‘ARCS Security – Manufacturer’s Specification’. During the evaluation 

we will also test the ‘Skipper Problem’ if appropriate (see Section 4.5 of these notes) and the overall 

system functionality. 

Please ensure that your system can pass all tests in Annex A of ‘ARCS Security – Manufacturer’s 

Specifications’ and, if relevant, the ‘Skipper Problem’ before applying for a system evaluation. 

Make sure you arrange for evaluation testing well in advance to ensure the availability of a date convenient 

to both organisations. Let us know in advance whether you require your system tested for compliance with 

Navigator and / or Skipper services. Note. If you have a system evaluation for only one service, if you 

then modify your software to include the other, you will have to attend another system evaluation. 

You should allow a full day for evaluation of each service type. Hence if your system will use both the 

Navigator and Skipper services 2 days will be required. Please ensure that your travel and accommodation 

arrangements allow this. Details of accommodation and a location map can be provided on request. 

System evaluations are to be carried out at UKHO. If, for special reasons, you consider it to be necessary 

for the evaluation to take place at your offices, this can be arranged. However, in these cases we will 

require that you pay for the travel and any accommodation costs incurred by the member of UKHO. No 

charge will be made for time etc. 

For the evaluation you will need to provide: 

a) A security device (dongle) programmed to use the sample encrypted data (i.e. MID1 = A1, PIN 

= 1234 etc.). 

b) A dongle programmed to use commercial ARCS data (i.e. User Permit created from your 

development MIDs). Please inform us in advance the User Permit and PIN numbers associated 

with this device so we can create the Chart Permits beforehand. 

Note. If your system does not use a hardware dongle please ensure that the test software can demonstrate 

use of both the initial sample data (using MID1 = A1, PIN = 1234 etc.) and commercial data using system 

User Permit and Chart Permits based on your development MIDs supplied. 

c) Although not mandated, it is useful if you bring the source code; this has often helped resolve 

issues during evaluations. 

We can make a PC (Windows 95 or NT 4.0) or Unix workstation (Sun SPARC running SOLARIS 2.x and 

OpenWindows) available if required but if special graphics cards or major re-configuration of the system 

is needed you must bring your own hardware. A 21-inch multiscan monitor is available for your use. 

During the evaluation, we will fill out a compliance test report. Upon completion, you will be given a copy 

of this document as a record of the system’s evaluation. 

Following the evaluation, we will write to inform you of any mandatory items that have to be corrected 

before the system can be sold as being ARCS compliant. We may also include some useful (hopefully!) 

suggestions as to possible additions or modifications to improve overall system functionality. Unless a 

large number of mandatory items need correcting, you will not normally have to attend another evaluation. 

Should another evaluation be considered necessary, we will inform you in the letter. 

Once you have corrected all of the mandatory items, you should write to us confirming that this has been 

done. We will then either complete the licensing procedure or arrange a date for the re-evaluation as 

appropriate. 

8


1.10 Completion of the ARCS licensing procedure 

Once any amendments that need to be carried out have been incorporated into your software, and we are 

satisfied that your product is fully compliant, you will be sent details of the Final Security System. This 

consists of the MIDs that are to be used to generate User Permits for production systems and completes 

the ARCS licensing procedure. 

1.11 Post Completion Support 

Following successful evaluation, the role of BD(PA) will be confined to the provision and maintenance 

of your R&D licences (including vessels where they are undertaking true development trials) and 

answering any technical questions resulting from continued development or operational use of your ARCS 

system. Existing licences for demonstration systems and vessels will be transferred to PM(ARCS), and 

new requests should be sent, to the ARCS Sales Office. (See Annex A). 

R&D Licence 

Once your system has been evaluated, and approval has been given for sales to begin, you will be provided 

with a full world outfit of ARCS charts for your R&D licence (Navigator service permits only). This will 

hopefully allow you to re-create any problems experienced by any of your customers. Note. Because of 

the complex nature of Skipper sales (i.e. users can hold an almost infinite combination of charts to various 

states of corrections) it is impractical to support Skipper in this way. Skipper permits to aid with customer 

problems can be requested as and when needed. 

R&D Trials Licences 

Where you are continuing to develop your software and wish to test its operation on a vessel, you will still 

be able to obtain R&D Trial Licences through BD(PA). Please contact us with details of the User Permit, 

PIN service type (Navigator / Skipper), vessel / shipping company details and charts required. To avoid 

embarrassment, it is recommended that you allow three weeks notice to obtain such charts so that standard 

post can be used for delivery. If we have to courier them to you a charge may be levied. 

As before, the licence will be made out to your company and all information despatched to you. It will be 

your responsibility to pass this onto the relevant vessel. 

Apart from in exceptional circumstances, we will not provide more than two (2) R&D Trial Licences for 

any given period. 

9



10


SECTION 2 

PRODUCT SUPPORT 

2.1 ARCS sales training 

The issues surrounding the use of electronic charts are complex. We are keen to increase the level of 

awareness of these issues by supporting you, your sales and marketing staff and your dealers / distributors 

in your marketing activities with appropriate training here at Taunton or at another mutually convenient 

location. This has been found to be a useful and effective way to learn about the important issues and 

concepts. Feedback from OEMs who have attended the ‘seminars’ so far have found them to be very 

worthwhile. Please contact BD(PA) to discuss training opportunities when you think this training would 

be appropriate. 

2.2 ARCS promotional support 

We are happy to provide you with a range of standard ARCS promotional material. A full explanation of 

the range of support available is found in the ‘Promotional Pack’. Please note that this pack is provided 

to help you in planning your promotional activities. Much of the support will become available only when 

you have completed the licensing process. Please contact PM(ARCS) for additional information. (See 

Annex A). 

2.3 Restrictions on use of promotional material 

Naturally, we are keen for you to associate your system with ARCS, and wish to allow you as much 

freedom as possible in your use of our material. Specific guidelines are outlined below, but in general 

terms any association you make between your product and the UKHO / ARCS should leave the end user 

in no doubt that: 

• The UKHO has not approved or endorsed your system, but has merely ensured compliance with 

ARCS security and error checking procedures. 

• ARCS is produced solely by the UKHO. 

• ARCS is a high quality product of the same pedigree as British Admiralty charts and publications. 

2.4 ARCS chart images 

These may be used in your promotional material where this is intended to promote the sale of ARCS 

compatible products. Charts shown should be of UK waters. Permission must be sought from HO 

Copyright Manager for use of charts of other areas. (See Annex A). 

2.5 Use of UKHO corporate and product images 

Details about the correct use of type styles, layout and colour tints are contained in the accompanying 

information pack ‘UK Hydrographic Office - Trademarks and Logos Design Guidelines’. 

In accordance with the general points above, and the guidance given in the Trademarks and Logos pack, 

you are permitted to use the ARCS logo (ARCS.TIF) solely to promote your ARCS compatible 

system(s). You may make use of the ARCS logo for the following: 

11


Within system / promotional software and on system hardware; 

On the Internet; 

In promotional literature and adverts; 

On exhibition panels; 

In brochures and flyers; 

In system documentation; 

On CD-ROM labels, but only where the completed artwork looks significantly different to an 

ARCS Chart or Update CD-ROM; 

On floppy disc labels, but only where the completed artwork looks significantly different to an 

ARCS chart permit floppy disc; 

Should you wish to use any promotional material that does not use the ARCS logo in the supplied 

designated formats, you must contact the Marketing Support Unit, submitting draft copies as clearance will 

be needed. (See Annex A). 

2.6 Permissible wording 

Care must be taken never to say or imply that your product has been ‘approved’ by the UKHO. Wording 

should go no further than to say that your system is ARCS compatible. As stated elsewhere, the system 

evaluation is to ensure correct implementation of the ARCS security and compliance with a few mandatory 

features - it is not a formal endorsement of your system. 

You may use the following style of phrase: 

‘Approved to sell ARCS compatible systems’ 

‘ARCS compliant / compatible’ 

...but you may not use wording such as: 

‘tested / trialed / licensed / accepted by the UKHO / Admiralty’ 

12


SECTION 3 

SOFTWARE IMPLEMENTATION - SECURITY 

3.1 General 

The information in this section is intended to clarify and, where necessary, to expand on the document 

‘ARCS Security Manufacturer Specifications’. As outlined below, some relaxations have been made to 

requirements as a result of feedback on the systems developed to date. 

3.2 Addendum and Corrigenda 

The following amendments should be made to ‘ARCS Security - Manufacturer Specifications (Version 

1.03)’. 

4.3.1. Delete the end of the paragraph from “Note:” onwards. 

4.3.2. Replace the second sentence with: “They are also to inform the user of User Permit and 

PIN numbers issued for his system to enable him to obtain ARCS charts from distributors and on a regular 

basis (as required in the ARCS manufacturer agreement) inform the HO of User Permits issued.” Also 

delete the end of the paragraph from “Note:” onwards. 

5.8.2.2.3 Screen messages associated with error codes 16,17 and 18 do not have to be permanent. 

The word “permanently” can be removed from pages 20 and 21 of the specification. 

Figure 2 PIN Entry (Page 24). Under ‘Reload Licence.GB file from original media’, remove ‘STOP’. 

Insert line from ‘No’ to vertical line by the word ‘Valid’ (under ‘Check validity of Licence.GB file’). 

7.1.2 Change Note: … to read ‘The input string to the AHF is 19 bytes long: 8 bytes for Chart#, 

8 bytes for Pcc….’ 

7.2.3 Change Note: … to read ‘The input string to the AHF is 20 bytes long: 8 bytes for Chart#, 

8 bytes for Pcc ….’ 

7.3.2 Change both Notes: … to read ‘The input string to the AHF is 21 bytes long: 8 bytes for 

Chart#, 8 bytes for Pcc ….’ 

9.3.1 Within sample source code for routine ‘introduce’, change ‘unsinged char xx;’ to ‘unsigned char 

xx;’ 

3.3 Relaxations to security specifications 

PIN number 

Each ARCS compatible system must be allocated a PIN Number and the user must be able to provide this 

number, along with the User Permit to the ARCS Outlet to be able to obtain ARCS Chart Permits. The 

security offered by the PIN is intended to be a user benefit (i.e. if the user’s dongle is stolen it is not easily 

usable) and is not part of the mechanism securing the ARCS data from copying. 

If you consider that a PIN is unnecessary or a nuisance for the user then you may ‘hard code’ a PIN of 

13


‘1234’ within your software. Thus the PIN will always be available to the application rather than needing 

the end user to type it in. In this case consideration should be given to providing a screen display showing 

both User Permit and PIN number so that the user cannot ‘loose’ this important information. 

The display of the User Permit, either at system start up or via an information display screen, is very useful 

to all users as the system documentation you supply to the user can sometimes get lost. The screen display 

of the User Permit number will enable the user to order chart permits without recourse to the system 

documentation. If your software supports several data types, it is possible for the user to want to buy his 

first set of ARCS charts some time after buying the system. Consequently, the system should be capable 

of displaying the User Permit without the user having loaded any ARCS charts. 

Invalid licence file (ARCS01) 

As with the PIN number above, the check sum on the licence file is not part of the mechanism securing 

the ARCS data from copying. Hence, although ARCS01 must be displayed whenever the system displays 

data from a modified licence file, its presence should not prevent the system functioning at other times. 

Systems should therefore be designed so that charts can be displayed even if the licence file is corrupt or 

missing altogether. However, the check sum (MAC) must be checked each time the licence file is accessed 

and, if corrupt (or missing), ARCS01 is to be displayed alongside the displayed information. 

Skipper service warnings 

ARCS 16, 17 and 18 (Loaded chart data not in line with Chart Permit): These messages do not now have 

to be permanently displayed. The messages were designed to alert users to the fact that the chart being 

used is out of date for Notices to Mariners. An existing Skipper user, when purchasing additional ARCS 

charts is given the latest available Update CD. If his system uses the entire CHART.CAT file on the 

Update CD when installing the additional charts he is likely to get ARCS 16 messages when using the 

original charts. Whilst such a message is informative it should not detract from the usability of the chart 

or system. Repeated display of this information each time a chart is viewed, especially if the error message 

is prominent or disrupts the area of chart display itself, can be annoying to the user. See also section 4.5 

below. 

Navigator service warnings 

ARCS 08 (Licence near to expiry): This message is to alert the user that the licence will have to be 

renewed by the end of the month. Feedback has indicated that the user does not want to clear a message 

every time a different chart is displayed but he should be alerted to the fact that the licence is in its final 

month at least twice a day. It is for manufacturers to decide how this error message is conveyed, although 

user feedback suggests that a clearable message prompted by a timer function is preferable. 

ARCS 09 (licence expired): This remains as the only permanent warning message that is displayed whilst 

charts are in use. Although the warning must be prominent it should not prevent sensible use of the charts. 

3.4 Null characters 

Null characters can occur in any of the encryption variables (e.g. UIDs, User Permit, chart keys etc). You 

should be aware that string-handling functions, especially within ‘C’ do not cope well with a null character 

within a string. This has resulted in the creation of invalid user permits and the incorrect decryption of 

certain charts. Since this aspect is not specifically tested during the system evaluation, please ensure that 

all software handling the encryption variables can cope with null characters in any location. 

14


3.5 Protection of manufacturer codes and chart keys at run-time 

Where a hardware security device (dongle) is being used the UID, PIN and MCDP values are generally 

stored in it. The application software must obtain this information to calculate the chart key. Once used 

to calculate the chart key this information should be cleared from RAM. The chart key may reside in RAM 

and can be used to decrypt additional tiles as required whilst the chart remains active. Please contact the 

UKHO if you wish to hold more than one chart key in RAM; this must be explained in your Security 

Implementation Report. 

The clearing of the UID etc from RAM after each use ensures that the dongle has to be present when a 

chart is loaded for display. Manufacturers must also ensure that the system ceases to operate if the dongle 

is removed after the application has been started. 

3.6 Network Implementations 

On a networked system, a ‘dongle’ or some other security device must control the number of concurrent 

users of the application. UKHO Proprietary Information stored in the dongle and required for chart 

decryption must be passed across the network in encrypted form. Within network systems, the local system 

must perform the decryption. It is not permissible for the server to undertake the decryption and then pass 

the decrypted image across the network. 

If you supply multi user versions of you software, you should include, with your 6 monthly User Permit 

returns, details of how many users each dongle allows. This will enable us to confirm that the customer 

actually ordered a similar number of licences. 

3.7 Speeding up Decryption - Storage of IVs 

The initialisation vectors (IVs) for the decryption algorithm are chart / tile specific but are not ‘sensitive’ 

like the chart key. You may therefore create IVs when loading chart data from CD. The values could be 

stored in a modified index (.CHI, .LOI) file or as a separate file of your choosing. By accessing ‘preprocessed’ 

IVs some processing time will be saved during decryption. IVs must be re-created when a new 

version of a base chart is loaded from either an Area or an Update CD, they remain valid for tiles corrected 

for notice to mariners on the Update CD. 

15


SECTION 4 

SOFTWARE IMPLEMENTATION - SYSTEM FUNCTIONALITY 

4.1 General 

This section is intended to expand upon the information contained in Section 3 of the ARCS Systems 

Developers Implementation Guide (ASDIG). During your system’s evaluation, its functionality will be 

assessed with particular attention being paid to the mandatory requirements and recommended features, 

that are outlined in the ASDIG. Where necessary, suggestions will be given which you may like to 

incorporate into your system. 

The points raised in the following paragraphs are designed to alert you to possible problems that can arise 

when loading and displaying ARCS data. You do not have to program your system exactly as described 

below. Other methods may be equally or more effective /efficient but you should ensure that the 

underlying problems associated with each paragraph are catered for within your program. 

4.2 Loading Navigator and Skipper permits on the same system 

If your system is capable of using both the ARCS Navigator and Skipper services there is a chance that 

the user will, at different times, buy and load both permit types. There are a number of problems with this 

which need to be addressed by your software. 

1 Because of the different conditions that relate to the different services, it is strongly recommended 

that you use entirely different directory structures for Navigator and Skipper data. This includes the permits 

and the chart data. Consequently, should a user have both a Navigator and a Skipper permit for the same 

chart, he will also have two versions of that chart loaded, one in the Navigator directory and one in the 

Skipper directory. Failure to do this may result in unpredictable results once the Navigator permit expires. 

2 The Licence file (GB.LCN) has the same name, but has a different content, for each service. You 

can detect which service the licence file is for from its contents, see ‘ARCS Security - Manufacturer’s 

Specifications’ section 10.2.2. Permit files can be identified by their names and / or by the length of the 

permits. These can then be copied to the appropriate directory structure. 

3 To ensure that the latest, most up-to-date version of a chart is displayed the viewer program should 

search first for Navigator permits. If a valid permit is found, the chart can be loaded. If there is no permit, 

or if it has expired, the viewer should search for a Skipper permit. Note. If the Navigator licence has 

expired but still allows the chart to be displayed (i.e. ARCS 09 condition), the viewer should also check 

for a Skipper permit since this may be more up to date than the Navigator permit. 

4.3 Licence File and Chart Permit Loading 

This is a deceptively complex subject that has been shown to need careful consideration. The following 

points should be considered: 

1 When loading new permits from a floppy disc (or any other media), the system should attempt to 

load the associated licence file. If a licence file is not present, the system should operate as for a corrupt 

licence file. (See below). 

2 Whenever licences are being loaded, the system should check that the check sum is correct as 

described at section 10.2.2.3 of the ARCS Security Specifications. If the check sum is valid, the system 

16


should copy the licence file onto the hard disc replacing any existing licence file. If the check sum is 

invalid (or the licence file is missing), the system needs to report the ARCS01 error message. However, 

the existence of this error does not prevent the continued operation of the system. The corrupt licence file 

should not replace any existing licence file on the hard disc, but if none exist, the corrupt file can be 

copied. 

3 When loading chart permits, the system should check that the check sum of each permit is correct 

as described at section 5.6 of the ARCS Security Specifications. If the check sum is valid the system can 

continue to load the permit. (See point 4 below). If the check sum is invalid, the system needs to report 

the ARCS02 error message. The existence of this error on a single or indeed multiple permits should not 

prevent the processing of further permits within the GB.NCP or GB.SCP files. Note. If a user attempts 

to load a set of permits created for a different system, every permit will be presented as being corrupt (i.e. 

ARCS02). Since a user may hold several hundred or even thousands of permits, the system must not 

require the user to acknowledge all ARCS02 errors unless an ‘OK to all’ or ‘Cancel’ option is available. 

A better way is for the system to process all permits and then present the user with a summary (e.g. 10 of 

10 permits successfully loaded / 287 out of 290 permits successfully loaded) and a scrollable list containing 

details of what happened. (See also point 4 below). 

The loading of a large number of permits, especially if all the checks mentioned here are 

incorporated, can take a substantial amount of time. System design should ensure that the user is aware 

of what is happening at all times. 

4 Permits should be merged with any that already exist on the system. Only valid permits should 

be stored on the hard disc. When merging permits, if a permit for the same chart already exists, the relative 

ages of the permits should be assessed before overwriting the existing permit. Three possibilities exist: 

existing permit is older than the ‘new’ one, they are identical or the existing permit is more recent than the 

‘new’ one. How these can be assessed is given below: 

Navigator Permits (GB.NCP). The expiry dates of the permits should be compared (note year 2000 

issues). 

Skipper Permits (GB.SCP). The notices to mariners numbers (PNM#) and the Pseq# values should be 

compared. The newer permit is the one with the higher Pseq# value. If the Pseq# values are identical, the 

PNM# numbers should be compared. The newer permit is the one with the more recent number. 

Normally, the system should only overwrite older permits. If the permits are identical or stored permits 

are newer, the system should not overwrite but report this to the user. (e.g. in the scrollable list as 

mentioned at point 3 above). Under exceptional circumstances, the user may wish to load an older set of 

permits into his system. This should not be prohibited but the user should be left in no doubt that this is 

what is happening. 

Manual entry of Chart Permits 

The check sum at the end of each permit is calculated using the ASCII values of the characters that make 

up the permit. Hence the check sum is case sensitive. Because users may type in permits that were read 

over a phone link or received via TELEX (i.e. all characters upper case), the system should allow upper 

and lower case letters to be entered in any location but correct them internally. Chart Permits (Navigator 

and Skipper) always use upper case letters for prefixes and suffixes to the chart number and lower case 

letters in the key itself. This means that any letter found in the first 8 character spaces of the permit will 

be upper case and any others will be lower case. You should ensure that the manual permit entry allows 

the user to enter any alphabetic character, the numbers 0-9 and the + symbol. 

Occasionally, a user may receive his first set of permits over the phone. In this case, he will not have a 

licence file. System design should allow the user to manually enter a permit without having a licence file 

available. 

17


Terminators between Chart Permits 

When produced by the UKHO, a new line character is used to separate individual Chart Permits in the 

.NCP / .SCP files. When permits are transmitted by electronic means or manually edited a carriage return 

character sometime gets inserted as well. To avoid users being unable to use transmitted or edited permits 

it is preferable for software to be able to cope with both types of separators, (i.e. NL and NL/CR). 

4.4 Chart and Update Loading 

Chart and update loading also requires careful consideration so as to avoid potentially serious problems. 

This is especially true of charts purchased under the terms of the Skipper licence so as to avoid the 

‘Skipper Problem’. (See also section 4.5). 

1 Because of the different conditions that apply to the Navigator and Skipper services, the way that 

chart data is stored differs between the two services. If different directory structures are used for Navigator 

and Skipper services this will be easy to achieve. Suggested ways of storing data for the two services are 

given below. 

General 

1 It is recommended that when loading charts, the user is first prompted to insert the update CD. 

(Note. The system should not fail to work if the user has no update CD. It is possible that this may have 

become lost/damaged and it could seriously disadvantage a user if, because of this, he can not load any 

additional charts). The system can then use the CHART.CAT file from this to display a list of those charts 

that are available. This list should be annotated to indicate those charts for which valid permits are held 

etc. A permit is considered to be valid if: ARCS02 does not apply and: 

Navigator permits: the expiry date is still valid (i.e. ARCS05, 09 or 10 error conditions do not apply); 

Skipper permits: the values of PNM# and UNM# are the same or PNM# is more recent than UNM# (Note. 

Additional checks need to be made between the permit and the chart data when loading the actual chart 

data; these are covered below). 

The system should not allow the user to select charts for which no or invalid permits are held. 

Because the PLAN.CAT file (also on the update CD) contains the vertices of the charts, it is possible to 

display a World map (possibly ARCS chart 4000) with chart limits superimposed. This can then be used 

to select which charts to load etc. 

Note. Because of copyright issues, certain charts will exist on the CDs (and therefore will appear in the 

PLAN.CAT file) which we do not sell. These are termed ‘shoats’ by the UKHO. A list of which charts 

are ‘shoats’ can be obtained from PM(ARCS). Shoats should be removed from the list. 

2 Because users can easily own more chart permits than they have space for charts on their hard disc, 

the system must allow the user to select a sub set of available charts for loading onto the hard disc. 

Conversely it must also allow the user to unload charts from the hard disc so as to make room for others. 

Navigator Service 

1 Once the user has selected those charts to be loaded, the system can use the location information 

from the CHART.CAT file to prompt the user to insert the appropriate Area CDs. It is recommended that 

the system only allows the user to load charts for which he has valid permits (i.e. can actually view); it is 

18


at this stage that the Penc# value can be checked against Enc# within the chart data as per section 5.8.2.1.4 

of the ARCS Security Specifications. If ARCS11 or 12 conditions arise, the chart data should not be 

loaded and the error reported to the user. Note. As for permits above, the system should not require the 

user to acknowledge each invalid permit / chart combination but should report any errors at the end. 

2 The system should copy the entire contents of each chart directory into a similar directory within 

the Navigator area of the hard disc. 

3 When all charts have been loaded (Note. This may involve the user inserting the update CD since 

certain base charts are stored on it), the user should be prompted to re-insert the update CD so as to update 

the charts. The user should not be given the opportunity of not updating the charts. This is to ensure that 

all Navigator charts are always updated. (Note. The system should not fail to work if the user has no 

update CD. It is possible that this may have become lost/damaged and it could seriously disadvantage a 

user if, because of this, he can not load any additional charts). Also, the update process should 

automatically update all Navigator charts. During the updating process, the system needs to perform the 

ARCS03 and 04 checks as described in the ARCS Security Specifications (5.7.3) for each chart. If 

ARCS03 or 04 apply, the user should be prompted to load the appropriate Area CD so that the revised base 

data can be copied. (Note. If an area CD has been re-issued it will affect all loaded charts that are 

identified as being on that CD. Hence all should be re-loaded once one out of date chart is detected) Once 

this has been done, the Update can be attempted again. 

As the updates for each chart are copied to the directory, the system should calculate the CRC of the 

updated image and compare this against the value stored in the CHART.CAT file. Because the CRC is 

calculated on the non-encrypted data, the system will have to decrypt the data first. If the CRC is incorrect, 

the data should either be removed from the directory or marked as being corrupt. The user must be warned 

of this in a similar way to ARCS11 or 12 above. 

Once the updates have been copied, the entire CHARTCAT directory contents should be copied to a 

suitable location, overwriting any data already stored. This ensures that the latest CHART.CAT file is 

always available for use by the system. The README.CDV file should also be copied so that the system 

can display the week to which all charts have been updated (e.g. WK35_98 as contained in the CD 

Number field of the README.CDV file). Finally, the system should copy in the entire TEMP_NM 

directory, again overwriting any data already stored. 

4 Each week, Navigator users should receive an Update CD. The system should make this as simple 

as possible to process. Hence, the user should, upon selecting ‘Update’, be prompted to insert the Update 

CD. The system then updates all charts as at 3 above including the copying of any complete charts that 

are on the Update CD (e.g. new editions or new charts). 

5 If users change their chart holdings when renewing their Navigator licences, it is possible for the 

system to retain out of date permits /chart data for now unwanted charts. It is helpful if there is an option 

to list all permits on a system annotated so as to indicate whether the permit is corrupt (users do sometimes 

edit permits stored on the system!), out of date, cancelled, chart is installed etc. This, together with the 

ability to delete chart data will allow the user to manage his data holdings. 

Skipper Service 

1 Once the user has selected those charts to be loaded, the system can use the location information 

from the CHART.CAT file to prompt the user to insert the appropriate Area CDs. It is recommended that 

the system only allows the user to load charts for which he has valid permits (i.e. can actually view); it is 

at this stage that the Pseq# value can be checked against Seq# within the chart data as per section 5.8.2.2.2 

of the ARCS Security Specifications. If ARCS13 or 14 conditions arise, the chart data should not be 

19


loaded and the error reported to the user. Note. As for permits above, the system should not require the 

user to acknowledge each invalid permit / chart combination but should report any errors at the end. 

2 The system should copy the entire contents of each chart directory into a similar directory within 

the Skipper area of the hard disc. 

3 When all charts have been loaded (Note. This may involve the user inserting the update CD since 

certain base charts are stored on it), the user should be prompted to re-insert the update CD so as to update 

the charts. The user should not be given the opportunity of not updating the charts (Note. The system 

should not fail to work if the user has no update CD. It is possible that this may have become lost/damaged 

and it could seriously disadvantage a user if, because of this, he can not load any additional charts) but the 

system needs to check each chart in turn to see if it can be updated. This is done by performing the 

ARCS03 and 04 checks as described in the ARCS security specifications (5.7.3) for each chart. If 

ARCS03 or 04 apply, the user should be prompted to load the appropriate Area CD so that the revised base 

data can be copied. (Note. Unlike Navigator, the ARCS03 / 04 errors will not necessarily affect all charts 

identified in the CHART.CAT file as being on the revised area CD. This is because the user may not have 

updated all charts. Hence the loading of revised base data must be done on a chart for chart basis). Once 

this has been done, the Update can be attempted again. Additionally, the system should perform the 

ARCS16 and 17 checks (ARCS Security Specifications 5.8.2.2.3). If ARCS16 applies, the updates are 

not to be loaded. If ARCS17 applies, the updates can be loaded but the user is to be informed that 

additional corrections can also be loaded. 

As the updates for each chart are copied to the directory, the system should calculate the CRC of the 

updated image and compare this against the value stored in the CHART.CAT file. Because the CRC is 

calculated on the non-encrypted data, the system will have to decrypt the data first. If the CRC is incorrect, 

the data should either be removed from the directory or marked as being corrupt. The user must be warned 

of this in a similar way to ARCS13 or 14 above. 

4 During the updating process, unlike in the Navigator service, the system should copy the portions 

of the CHART.CAT and PLAN.CAT files relevant to the chart into the chart’s directory. Also, the 

README.CDV file should be copied into each chart directory that is updated. The general principal here 

is to create a ‘time capsule’ of each chart that is correct to the time of sale. Subsequently, when viewing 

the chart, all checks can be performed on the encapsulated data that should be synchronised with the 

permit. Hence, the user will not receive any unwanted errors or warnings. 

A point to note with the ‘time capsule’ approach is the T&P Notices to Mariners. It is probably advisable 

to store the entire T&P file (from the TEMP_NM directory of the Update CD) in a directory named after 

the appropriate Update CD. When accessing T&P Notices from a chart, the system can detect to which 

week the chart is correct (using the README.CDV file in the chart’s directory) and access the correct 

version of the T&P files. Failure to do this may result in T&Ps being indicated in chart’s T&P record (See 

NP760 section 6.6.6) but not being available in the stored T&P file. Note. If operating in this way, the 

system should allow the user to determine which of these stored T&P directories are still needed since the 

user may have updated all charts that relate to a given directory. 

A problem also exists with the Square Index File (NP760 section 6.9). This file contains pointers to the 

entries within the CHART.CAT and PLAN.CAT files. If, you have only copied those portions of these 

files onto the hard disk, the pointers will be meaningless. Consequently, this file can not be used. If you 

wish to use it, it is recommended that within the directory created for the T&Ps above, you also store the 

entire contents of the CHARTCAT directory. You would then not store portions of the CHART.CAT and 

PLAN.CAT files in the chart’s directory. This will allow the pointers within the Square Index File to work 

but will require more disk space. 

5 When a user buys additional charts or updates any existing charts, the system must check to see 

20


if the stored chart data is compatible with the stored permit. The above process should allow the system 

to successfully load Skipper data and thereby avoid what has become known as the ‘Skipper problem’. 

(See below). 

6 Although the entire latest CHART.CAT file is of little use for accessing Skipper charts, it can be 

useful to store it. This can allow the user to check his loaded charts / permits against the latest information 

and therefor check which, if any, charts need updating. 

4.5 The ‘Skipper Problem’ 

ARCS Skipper customers pay a one-off fee for their charts, to which they then have unlimited access. They 

are able to purchase additional charts and chart updates, as and when they like. 

A common scenario occurs where the user purchases a first set of charts (Batch 1), and then, at a later date, 

purchases a second set of charts (Batch 2), without updating the Batch 1 charts for Notices to Mariners. 

Batch 1 and Batch 2 charts will be correct to different dates. Accordingly, the user will be accessing 

ARCS chart data from different Update CDs, and possibly from more than one release of certain Area 

CDs. 

This situation in itself is not a problem, but it does require careful chart management within your system, 

so that the user is in no doubt about which CDs he requires, to access the charts he has paid for. It is for 

this reason that it is recommended that when loading charts the system only copies charts to the hard disk 

that it can display and also creates the ‘time capsule’ of chart data. 

If your system does not manage the charts correctly, one or both of the following scenarios may occur: 

1 Upon purchase of Batch 2, the Batch 1 charts may still be displayed, but only in the state of 

correction in which they appear on the Chart CD. The system will deny access to the update 

information supplied on the Update CD at the time Batch 1 was purchased. As a result of this, the 

Batch 1 charts revert to being more out of date than when the user originally purchased them. 

2 If there has been a re-issue of a relevant Chart CD between the purchase dates of Batch 1 & Batch 

2, your system may deny access to the Batch 1 charts altogether. 

Both of these situations are obviously unacceptable to all concerned, and could even be dangerous, because 

the user could quite unwittingly be using charts which are more out of date than those he originally paid 

for. 

Test data, and a test plan should have been provided to you to allow you to test how your system copes 

with this situation. 

4.6 Cancelled charts 

Cancelled charts are normally replaced by a new chart of the same, or potentially, a different number. 

When a chart is cancelled and replaced by a new chart of the same number, the user’s existing chart permit 

will continue to work. However, in the case where a chart is cancelled and replaced by a chart of a 

different number, the Navigator user who was licensed for the withdrawn chart will automatically be sent 

an updated set of Chart Permits including a permit for the new chart. These will be sent along with the 

Update CD containing the replacement chart(s). 

Occasionally, charts are cancelled and withdrawn from issue without replacement. The number of a chart 

21


withdrawn without replacement will not be re-used in ARCS for 5 years. 

Cancelled charts are removed from the CHART.CAT file on the Update CD. When loading Update CDs, 

the application software should confirm (using the CHART.CAT file) that all charts loaded on the hard 

disc, or for which the user holds a permit, are still on issue. 

If a permit for a cancelled chart exists or a cancelled chart is loaded, the program should warn the user. 

If the chart is cancelled without replacement the user may continue to use the chart for the duration of the 

Navigator licence period. However the chart will be out-of-date and an appropriate warning message must 

be shown. 

4.7 X charts 

On rare occasions it is necessary to issue important navigational changes (e.g. details of a new traffic 

separation scheme) that are due to take effect on a specific changeover date by incorporating them in a new 

edition. To ensure the mariner has the new edition on board at the time of changeover we release it several 

weeks prior to the changeover date. This allows the user to see the extent of the changes in advance so that 

voyage plans can be amended. The mariner must however continue to use the old edition up until the 

changeover date. To minimise confusion in the period that both editions of the chart are available the old 

edition is renumbered by adding ‘X’ as a suffix (e.g. 1234 becomes 1234X) and the new edition has the 

correct number (e.g. 1234). The old edition (the X version) is cancelled as soon as the changeover has 

occurred. 

On the publication of new edition 1234, for example, the existing chart image on the Area CD is cancelled. 

It is replaced by a new image of that existing chart, now called 1234X, on the Update CD and the chart 

catalogue file is updated with chart 1234X accordingly. The new edition appears on the same Update CD 

as chart 1234 with its appropriate entry in the chart catalogue file. This new edition uses the same chart 

permit as the previous edition, as per normal practice, but the replacement of the original edition, now 

called 1234X, requires a new chart permit. This is issued to affected users with the weekly Updated CD. 

After the changeover date the X chart is cancelled and the image and chart catalogue file entry are 

removed from the Update CD. 

Note. If the user does not load the new permits and X chart image or does not amend the chart portfolio 

there is a risk that he may inadvertently use the new edition prior to the changeover date. 

User information about the change is carried in the explanatory text field in the file for 

both the new edition and the X version. The system software should allow the user to read this 

information. 

4.8 Use of enlarged or reduced images 

ARCS images should only be used for navigation when displayed at 1:1. This means 1 pixel of raster data 

occupies 1 pixel of screen display. The actual scale of the image if measured with a ruler will not be the 

same as the quoted scale of the chart (unless the screen resolution is the same as the scanned image i.e. 0.2 

mm). Because distances etc. are measured using electronic tools, and not by rulers, the actual scale of 

display is not considered to be important. What is important is the content of the displayed image and any 

zooming will potentially destroy this content. 

If you display the high resolution ARCS image (.CHR file) at any scale other than 1:1, you must warn the 

user that the display has either been ‘zoomed in’ (overscale) or ‘zoomed out’ (underscale) and is Unsafe 

22


for Navigation. 

ARCS images must not be ‘overscaled’ greater than x2 as the image quality becomes unacceptable. No 

limits are imposed for zooming out. 

If your system provides the user with a zoom function it is essential that you provide a facility to return to 

the correct scale of the chart (1:1) simply and quickly, preferably by a single operator action. 

4.9 Use of rotated images 

During navigation mode, systems must not rotate the ARCS images through any angle other than 90, 180 

or 270 degrees. This is to retain the 1:1 relationship mentioned at 4.8 above. The consequence of this is 

that ARCS charts can not be used in ‘course up’ mode but must be used in ‘chart up’ mode. 

The use of 90 degree rotations will allow a few panels, scanned at 90 degree rotations to be displayed 

North up. 

If required, charts can be rotated during planning mode. 

4.10 ‘Mosaicing’ of chart images (also termed quilting) 

This refers to the practice of using several charts to present the user with a seamless picture to navigate on. 

It is recommended that this practice is not used with ARCS charts in navigate mode; it can however be 

used during planning. 

As with 4.8 above, if any part of the image is not displayed at 1:1, the system must display a warning to 

the user stating that the image is over or under scale and is not safe for navigation. If mosaiced charts are 

being used, it is likely that this warning will always be displayed and thereby bring the accuracy of ARCS 

data and the system into question. 

Additionally to the above, systems may experience problems when attempting to mosaic together charts 

that are on different horizontal datums, especially if one or more of the charts do not have a shift to 

WGS84 datum. Potentially, there may be a case where two charts are to be joined which are on different 

datums with no common link between them. Finally, some charts (those at scales greater than 1:50,000) 

are on the Transverse Mercator projection while others are on the Mercator projection. To mosaic such 

charts together would require more complex processing than simply scale changes. 

4.11 Depth units 

Most charts in the British Admiralty series are now in metric units, although there are considerable areas 

still covered by fathoms charts, either because the charting has not yet been revised or because it has been 

redrawn with other government’s regulations in mind. Charted depths are subdivided as appropriate, using 

a subscript value to indicate the subdivision. Metric charts use decimetre subscripts whilst subscripts on 

fathoms charts refer to feet. Some large scale harbour charts show depths in feet while some older charts 

use fathoms and fractions. The depth units are clearly indicated by a bold magenta legend at the top and 

bottom of the chart. 

Depth unit information is provided in the panel header file within the General Data Record 

23


field. The system must use this information and permanently display the correct depth value of the active 

(i.e. the one in use) chart or chart panel. 

4.12 Chart information panel 

ARCS charts often comprise several different panels. If your system has a chart information panel, you 

must also ensure that the information contained in that panel refers to the active charted ARCS image. 

4.13 Horizontal datums 

Satellite positioning systems such as GPS and DGPS output their positions in WGS84 datum. Some charts 

in the British Admiralty series are referenced to WGS84 but a large number are on local datums. Most of 

the charts on local datums contain accurate shift value information which enables all geographical positions 

derived from GPS / DGPS to be converted to the local datum of the chart (and vice versa). However, 

approximately 40% of ARCS charts have no shift values as accurate shift information is not currently 

available for certain areas of the World. 

Your system must be aware of which horizontal datum the chart is referred and plot positions derived from 

GPS onto the electronic chart accordingly. The ARCS format (HCRF) contains polynomials to allow 

geographical co-ordinates to be converted to x and y values (and vice versa). Where possible, two sets of 

these polynomials are provided, one for local datum and one for WGS84 datum. Hence, positions received 

in WGS84 co-ordinates can be plotted directly on to the chart if the WGS84 polynomials are used. If you 

do not wish to use the polynomials, equivalent shift information is provided in the panel header file 

within the General Data Record field. This can be used with the standard projection 

equations. This allows WGS84 positions to be plotted onto charts where an accurate shift has been 

defined. However, as stated above, for about 40% of ARCS charts no accurate shift information is 

available. In these cases, the WGS84 polynomials and shift data will be 9 filled and all positions must be 

plotted as if they are on local datum. In these cases, the system must display a clear warning that positions 

derived from GPS can not be accurately referenced to the chart and that increased caution is needed. 

If the entire panel does not contain accurate shift information, the system should treat it as having no shift 

information. 

You are allowed to let the user define his own off set by fixing his position relative to the charted data 

(visual fixes / radar fixes etc.) and comparing this against the GPS output. In these situations, it must be 

made clear that a user offset is in operation and the user must be prompted to re-confirm it at regular 

intervals. If a user-defined shift is in operation and the user changes charts, to one that has a known 

WGS84 offset, the user-defined shift should be discontinued and the user notified. 

We strongly recommend that you advise your users to keep their GPS receivers set to out put positions 

in WGS84 datum rather than attempt to use the datum transformations built into many GPS receivers. 

Several users have experienced difficulties with receivers set to a local datum when this has been 

inadvertently left on as the vessel moves to other areas. 

4.14 Identification of update locations 

Updates are provided in the form of replacement tiles. It can be useful for the user if the system allows 

the locations of these to be identified. This can be done by, upon user request, highlighting the borders 

of all update tiles with a suitable colour. This allows the user to identify where updates have occurred and 

can be useful in route planning etc. (See below). 

24


4.15 Route / overlay creation and display 

Most systems will allow the user to create routes by placing way points upon the chart. Similarly, systems 

may allow the user to add vector overlays indicating areas of interest or danger. Typically, these may be 

stored for future use. 

When creating and storing routes / overlays etc, it is advisable to store the positions in WGS84 datum. This 

will mean that should the route be recalled for display on a different chart to the one on which it was 

created, it should be possible to position it correctly. However, not all charts have WGS84 shift 

information available. In these cases, any route data must be stored referred to local datum. It also likely 

that a long route may contain both types of positions. Systems should be aware of this. This may require 

the tagging of each way-point with references to its datum. This will also allow the user to be warned 

should way-points be plotted on a chart with an incompatible datum. 

Further to the above, charts may be updated after the route / overlay has been created. These updates may 

make the stored data unsafe. ECDIS systems allow the user to ‘check routes’ so as to confirm their safety. 

It is not possible to do this automatically with raster data so the user needs to be able to do it manually. 

Consequently, it is recommended that data are stored with a ‘last checked’ date. If the data is 

subsequently displayed and the charts have been updated more recently than the data was last checked a 

warning can be displayed. Once the data has been checked, the identification of update tiles can help here, 

the last checked date can be modified etc. 

When displaying routes, you should be aware that the polynomials used to convert between geographical 

co-ordinates and x / y co-ordinates are only checked internal to the relevant panel. Consequently, any 

positions that are plotted, using the polynomials, outside of the panel may contain un-quantifiable errors. 

This is likely to affect the plotting of ARPA targets should they fall off the current active panel. In these 

cases, the relationship between the plotted target and the ship may not be correct. A similar problem exists 

with the plotting of legs of routes if the way-points fall off the current plan. Here, if the system joins waypoints 

with a straight line, and the way-points are plotted inaccurately with respect to the current plan, the 

leg will be plotted in the wrong location on the plan. This can be dangerous to the user. To avoid this, the 

system should, when plotting legs, calculate the accurate entry and exit points for any leg with a way-point 

outside the current active panel. These points can then be used to draw the leg accurately over the panel. 

4.16 Charts, inset plans, continuation plans and sheets of plans 

British Admiralty charts vary from single panel charts with, or without, one or more inset plans, to multi 

panelled sheets of plans. HCRF recognises each chart and plan as a separate panel for the purposes of 

recording information and assigns this information to the various fields in the header and catalogue files. 

A detailed description of the various ways charts, inset plans, continuation plans and sheets of plans can 

be arranged is given in the NP 760 HCRF Version 2.00 document, pages 92 to 94. 

The configuration and geographical coverage of these multi-panelled charts means that it will be possible 

for the user to view an ARCS image which has, for example, two vessel icons displayed. This is because 

the own ship’s geographical position is common to more than one panel within the multi-panel ARCS 

chart. ARCS charts supply coefficients in the Panel Header (.Pxx) files to enable systems to convert 

geographic positions to pixel co-ordinates and vice-versa by use of a polynomial expression. As ARCS 

charts can be made up of inset plans and sheets of plans as well as single plans, your system must assess 

the configuration of each chart and plot positions accordingly. 

It is therefore essential that the user is not misled when using this type of chart. Geographical referencing 

and cursor / own ship’s position readouts must refer to the active chart panel. You must also ensure that 

25


these readouts, together with any overlay information such as way points, routes and bearing and distance 

lines that share the same geographical point and are common to more than one panel on a multi-panelled 

chart, are dealt with in a suitable way. 

4.17 Notes and diagrams 

Charts usually contain a number of items of ancillary information that are placed, as far as possible, on 

areas of the chart where no hydrographic detail exists. Sometimes this ancillary information is positioned 

outside the chart border. Information includes the chart title, textual notes, tables, source data diagrams, 

tidal stream information, port facility information, linear scales etc. The pixel co-ordinates of each item 

are contained in the .Nxx file. If any of these items obscure hydrography, and fall within the vertices of 

the chart, they are flagged within the .Nxx file so you can ensure that you do not plot an own ship icon on 

top of them. 

Systems can make further use of the pixel co-ordinates of these various ancillary information files as the 

appropriate portion of the raster image can be brought into view. If your system makes use of this ancillary 

information you will either bring the item to the own ship’s position or go to the particular item thus 

loosing your own ship position while the information is assessed by the user. If your system uses this ‘go 

to’ method you must ensure that it is possible to return to the own ship’s position simply and quickly, 

preferably by a single operator action. 

The information contained with many of these notes is of great importance to navigation. If you trim the 

active panel to the panel border, you must allow the user to view this data and so you must make use of 

the pixel co-ordinates. It is not permissible to prevent the user from viewing this information. 

4.18 Viewing information from the header file 

It is very useful for any user of an ARCS compatible system to have the ability to view information relating 

to the displayed chart. The information is contained in various fields in the header file and includes details 

such as chart title, chart scale, depth and height units, horizontal datum information, edition date, special 

remarks relating to the chart and any T & P (Temporary and Preliminary) Notices that are relevant to the 

displayed chart. You might like to consider displaying this information in a separate ‘Chart Information’ 

panel. 

Most users will also want to know the number of the last Notice of Mariner correction applied to each of 

their charts within the system. Professional mariners, who are operating vessels that are governed by 

SOLAS regulations, will need to check on a weekly basis that each chart is fully up to date and apply 

corrections accordingly. The state of correction of a chart is given by its edition date and Notice to 

Mariners correction number; these are detailed in the chart catalogue on the weekly ARCS Update CD. 

If your system has a chart information panel function it is essential that the information contained within 

that panel matches that of the displayed charted image (Notice to Mariner numbers are written at the 

bottom left of the chart). 

4.19 Chart backdrop 

All ARCS users are supplied with the world chart (BA 4000) free of charge with their first and subsequent 

ARCS chart orders. BA4000 is at a scale of 1:45,000,000 and is permanently placed on the Update CD. 

This chart may therefore be used as a backdrop for any graphical catalogue viewer you might wish to 

develop. It also ensures that the user never sails off the edge of his ARCS chart coverage. 

26


4.20 Combination of data types 

Systems may allow the user to use data from more than one data provider. Consequently, he may have 

data, for the same area, from more than one source. If one data set is vector based, it is possible that these 

data could be used as an ‘underlay’ to an ARCS chart so that automatic warnings etc. can be displayed 

based upon the ‘hidden’ vector data. This practice is considered to be unsafe and the combination of 

‘hidden’ vector and visible raster is strongly discouraged. 

The problems with this type of operation arise when the vector and raster data sets are to a different state 

of correction and therefore do not show the same ‘picture’. This can result in alarms being presented to 

the user based on data that is not obvious to him when viewing the display. Because of this, if data types 

are allowed to be combined, prominent warnings must be displayed on the viewer and the product’s 

handbook must contain details of the problems that can result in this type of operation. 

4.21 CRC check 

All ARCS compatible products must be able to use the CRCs following chart loading and updating to 

verify the ARCS data integrity. It should be noted that the CRCs apply to the non-encrypted image. Note. 

The CRCs in the CHART.CAT file are in reversed byte order to those in the .CHR file. 

4.22 Screen Hard Copy 

The ARCS user licence states that if the user equipment “is capable of producing hard copy, such hard 

copy must not be sold, hired or otherwise transferred to any third party, and shall not be used for 

navigation.”. Software may allow printing of the screen display (chart with accompanying overlay 

information) from video RAM. The software must however limit the user to printing one screen of data 

at a time. No facilities to encourage or allow printing of large portions of charts (e.g. by printing from a 

decrypted chart in RAM) are to be incorporated. 

A user who wishes to use screen printout in a way other than specifically allowed by the ARCS user 

licence must apply to the UKHO Copyright Manager. (See Annex A) 

4.23 Compliance with ‘Seafarer’ charts 

The Australian Hydrographic Office (AHO) produces digital charts in the same format, including the 

security scheme, as ARCS. These are marketed under the name Seafarer. Hence, your ARCS compatible 

system will, with only a few modifications, also be able to accept AHO Seafarer charts. 

If you would like to gain Seafarer compliance along with ARCS compliance, you must contact AHO. (See 

Annex A). You will also have to write to BD(PA) and request that we release your proprietary information 

to AHO. You are not permitted to pass this yourselves. 

27


SECTION 5 

OTHER TOPICS 

5.1 The Manufacturer’s Licence Agreement - points to note 

These informal notes are intended to highlight some aspects of the agreement that may otherwise be 

overlooked. They all refer to stages of your ARCS development or subsequent promotional activities, the 

clause numbers are included to guide you to the appropriate section of the agreement. 

Sub-licensing 

The ARCS Manufacturer Agreement gives your company the right to develop and sell ARCS compatible 

products to end-users. The Agreement also allows you to provide your software to another manufacturer 

for inclusion within their intended ARCS compatible product although the prior written permission of the 

UKHO is required. Typically, your software kernel would be used by the sub-licensed OEM to handle the 

ARCS decryption, display, updating, licensing and security routines and their additional functionality 

would be bolted onto that kernel. It is expected that the kernel will be provided in a compiled form so that 

the recipient can not determine the content of the security specifications. See Clause 4.1 and 4.2 of the 

Agreement. 

If you intend to provide your software kernel to other manufacturers, you must ensure that the security 

elements of the kernel are self-contained. Hence, it must not be possible for the recipient company to 

circumvent the security routines. Before permission is granted for this, you will have to submit details of 

the kernel to BD(PA). We will need to know what calls are possible and what data is provided to / by the 

kernel. Once we are satisfied, we will add the kernel product to your Schedule A. However, you must still 

request permission from UKHO for the sub-licensing of specific companies. Such permission will not be 

unreasonably withheld. 

If you need to provide another manufacturer with the source code of your product, we will have to enter 

into an ARCS Manufacturer Agreement with that manufacturer before the source code is released. This 

will involve that manufacturer paying the attendant fees etc. Depending on the use being made of the code 

by the manufacturer, they may or may not need to attend a system evaluation. Please contact BD(PA) on 

a case by case basis. 

Payment 

You will be invoiced by the UKHO for the fees outlined in Clause 5.1 of the manufacturer agreement. 

Please ensure the payment is made in Pounds Sterling otherwise we will have to charge an additional fee 

to cover bank charges. 

Supply of User Permit information 

You must provide, at six monthly intervals, a complete listing of all User Permits generated with associated 

recipient details. See Clause 6.2 of the Agreement. 

On-going System Development 

It is your responsibility to ensure that the security and licensing routines continue to function correctly 

following any revision or updating of your products. See Clause 7.3 of the Agreement. 

28


Schedule A 

The agreement grants permission to sell products listed in Schedule A. Any additional products that you 

wish to introduce at a later date must be included on the Schedule. It is likely that if the new product has 

similar functionality and employs the same security methodology as the previous product, that no further 

compliance testing will be necessary. It will be the responsibility of the company to ensure that the new 

or indeed any modified versions of the evaluated product meets the requirements of Schedule C to the 

agreement and correctly implements all the appropriate security and licensing routines. 

For each new product, you should submit a security implementation report. In its simplest form this can 

state that no differences exist between the new product and the tested product. However, any differences 

in the operation of the security system must be described. 

Schedule C - Duplicate UIDs / User Permits 

Under certain conditions you are allowed to provide duplicate ‘dongles’ to the end user, e.g. where a vessel 

is fitted with two navigation systems (the second as back-up). UKHO permission to produce these 

duplicates must be sought in advance of delivery. See notes on user licence below. 

5.2 ARCS user licences - points to note 

Currently there are three different types of end user licence available, Navigator Vessel, Navigator Shore 

and Skipper. 

Navigator Vessel 

This licence allows up to five VDUs to be run per vessel (for navigation purposes) for the cost of one 

Navigator Licence fee. Where a main and a back-up system are being used from the same manufacturer 

on one vessel, duplicate UIDs can be created to ensure that one set of Chart Permits will display the ARCS 

data on either system. Where two systems are being used from different manufacturers two sets of Chart 

Permits will be supplied to the vessel (again for the cost of one licence). 

Navigator Shore 

This licence allows only one stand-alone processor linked to one VDU per licence or one networked 

processor linked to several VDUs. A networked system will qualify for a multi-user licence discount 

depending on the amount of VDUs linked to the central processor. 

The manufacturer must ensure that individual elements of the network can not be isolated and used 

independently. To qualify for the discount all networked workstations must use a single User Permit. 

Manufacturers must let the UKHO know at the time of sale how many workstations are allowed on the 

network so that the appropriate level of discount can be given to the end user. 

Skipper 

This licence allows only one stand alone processor linked to one VDU per licence or one networked 

processor linked to several VDUs where a multi-user discount will be given as for Navigator shore above. 

29


ANNEX A 

USEFUL CONTACT NAMES AND NUMBERS 

UK Hydrographic Office - Tel +44 (0)1823 337900 

Business Development - (BD) 

Queries relating to ARCS chart distribution: 

Head of Business Development (HBD) Ken Burrows ext. 3279 

Fax number: +44 (0)1823 334917 

Business Development (Product Applications) - BD(PA) 

Queries on licences, implementation, and provision of charts for R&D and vessel trials, system evaluation 

etc. 

Business Development Manager (Digital Products) 

Chris Smith ext. 4184 

Digital Products Compliance Manager 

technical issues relating to ARCS development and operational use 

Richard Coombes ext. 3350 

ARCS Implementation & Vessel Trials Manager 

general issues relating to ARCS implementation and vessel trials 

Ian Husband ext. 3305 

Digital Products Support 

Mark Masters ext. 4265 

Fax number: +44 (0)1823 251816 

Email: bdpa@busdev.hydro.gov.uk 

Digital Products Helpdesk 

General customer/end user enquiry helpline 

ARCS Customer Services Unit 

+44 (0)1823 723366 

Chart Sales/Customer Support, demonstration licences (once your system has been accepted). 

Customer Orders Manager Sue Holloway ext. 5040 

Fax number: +44 (0) 1823 323753 

Email: sales@busdev.hydro.gov.uk 

Gina Lloyd ext. 4980 

30


Product Management (ARCS) 

For product support etc. 

Senior Product Manager (Digital Products) Hayley Jobson ext. 3328 

Product Manager (ARCS) Dave Ware ext. 3210 

Fax number: +44 (0)1823 334917 

Email: prodman@pd.hydro.gov.uk 

Marketing Support Unit 

For promotional support etc. 

Exhibitions & Graphics Manager Mike Skelsey ext. 4171 

Advertising & Promotions Manager Chris Bass ext. 3563 

Fax number: +44 (0)1823 334917 

Email: msu@pd.hydro.gov.uk 

Copyright 

Copyright Manager Rosemary Tuhey ext. 3644 

Fax number: +44 (0)1823 284077 

Email: ukho_copyright@dial.pipex.com 

Australian Hydrographic Office 

Seafarer charts 

Manager Business Co-ordination 

Australian Hydrographic Office 

Locked Bag 8801 

South Coast Mail Centre 

NSW 2521 

Australia 

Fax: +61 2 4221 8597 

Email: mbc.hydro@navy.gov.au 

31


ANNEX B 

ARCS SECURITY IMPLEMENTATION REPORT 

The following is a suggested layout for the ARCS Security Implementation Report required under the 

terms of the ARCS Manufacturer’s Licence Agreement. Wording shown in italic must be included 

somewhere in the report. The report should be made available at the time of system evaluation by the 

UKHO and must be approved by the UKHO prior to the granting of the Final Security System . 

1. Introduction 

This report has been produced in accordance with the terms of Clause 10.1 of the Agreement between The 

Secretary of State for Defence in Her Britannic Majesty’s Government of the United Kingdom of Great 

Britain and Northern Ireland, and XXXXXXXX dated xx/xx/xx. It specifies the way that the Initial Security 

System has been implemented within the Product. 

2. Conformity with Specifications 

The Product incorporates an ARCS capability in accordance with the ARCS Security - Manufacturer’s 

Specification (Version 1.xx). It is confirmed that the Product (Version xx.xx) complies with the conditions 

of use and the security and licensing routines specified in Schedule C to the Agreement. 

Any exceptions to this must be stated here and detailed at 4 below. 

3. Protection of UKHO Proprietary Information 

a) Within the Company: Storage of and access to UKHO Proprietary Information. Control of 

source code containing UKHO information. Production control of ARCS User Permits, 

preparation of dongles etc. Audit of UIDs/User Permits issued (and replaced / reissued due to 

component failure) - note requirement of licence (Clause 6.2) to provide HO with details of issues. 

b) Within the Product: Where are UKHO codes held? 

Where a dongle is used: What device is used? What are its general characteristics? What UKHO 

codes are held within it - are any held elsewhere? Is the device used for other purposes? Are 

communications between the dongle and the application protected in any way? 

Alternative methods (where a dongle is not used): Explain how the UKHO Proprietary 

Information is stored on the system; how is it protected? 

How does the software deal with UID / MCDP etc? UKHO codes should be overwritten once 

the chart key has been obtained. Is more than one chart key held in memory? Where a dongle 

is used - how often is its presence checked? 

How does the system prevent the user having access to navigator charts once the licence has 

expired? (GPS date, system date, software issue date and in what sequence are they checked? Are 

any not used? 

c) Network use: If the Product is to be used as a network application how is control of concurrent 

usage to be achieved? 

4. Exceptions or Other issues 

32


This is where any exceptions are to detailed. 

Name _____________________________ Signed _______________________________ 

Position _____________________________ Date ______________________________ 

33


ANNEX C 

ACCOUNT INFORMATION 

Bank Details 

Account Name 

The UK Hydrographic Office 

Account Number 2428026 

Sort Code 30 - 98 - 45 

Address 

Telephone Number 

Lloyds TSB plc 

31 Fore Street 

Taunton 

Somerset 

TA1 1HN 

01823 345600 (UK) 

+ 44 1823 345610 (Overseas) 

VAT Number 

GD 052 (Normal government department) 

GB 888 8052 64 (EC VAT) 

34

hyhorshuv - United Kingdom Hydrographic Office

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?