Home Office Logo

Year 2000 Compliance Guidance Notes for the Fire Service

Research Report Number 10/97

J A Harwood 


FOREWORD

It is hoped that by now all Local Authority Fire brigades have been alerted to the potential hazard of the so-called "Millennium Time Bomb" and are taking precautionary measures. However such is the concern, particularly for emergency services, that it has been thought worthwhile for the Home Office to provide these notes, based on work undertaken by the Fire Research and Development Group, Mentis Management Consultants Ltd and the Police Information Technology Organisation, to supplement the guidance which brigades may already have had and to provide a check list..

A major task is the identification of where problems might arise, and this will depend on the extent and timing of individual brigades investment in IT. In consequence, all that central guidance can achieve is to emphasise the problem and to alert brigades both to the need to tackle it vigourously and to advise the public of their need to make assessments of IT based equipment, for example, in relation to automatic fire alarms and sprinklers, but particularly where the risk of malfunction may be very high such as in the petrochemical industry.   CONTENTS  

1. MANAGEMENT SUMMARY
2. INTRODUCTION
2.1 Pinpointing the Year 2000 Problem
3. RESPONSIBILITIES AND MANAGEMENT
4. YEAR 2000 COMPLIANCE ACTION PLAN
4.1 Introduction
4.2 Assessing the situation
4.3 Evaluating the options
4.4 By-products and additional benefits
4.5 Planning to tackle the problem
4.6 Managing the Change Programme
5. COMMENTARY ON SPECIFIC ISSUES
5.1 Relations with others
5.2 Risk Management
APPENDICES
1. Hardware/Platform risk assessment
2. Checklist for action (computer system)
3. Checklist for action (embedded systems)
4. British standards institution (BSI) definition

 

1. MANAGEMENT SUMMARY
 

Isn’t This Just a Technical Issue? No. Whilst the problem originates in the way technology has been designed and is used, the scale of the risk and the potential action required will necessitate it being addressed by a co-ordinated management and technical response. 

A modern brigade depends on computer systems and high-speed telecommunications to provide essential support to ensure operational effectiveness and run administrative systems efficiently and effectively. Within these systems dates are often essential triggers for action, such as the creation of rosters, generating alerts in planning systems or signalling forward dates for training. If these applications start to fail and public services are affected, it will not be a credible management response to say "it was just a technical issue". 

If devices with embedded systems, such as time-clocks, electronic locks and alarms malfunction or fail completely at the start of the new millennium, the resulting chaos will be an operational and business problem; it is up to operational and business people to ensure that the risks are minimised. 

The problem will cross functional and operational boundaries. Brigades will need to plan their actions according to priorities agreed across these, as resources will undoubtedly be stretched.

How Big is the Problem? The scale of the problem will vary from brigade to brigade, but evidence from commerce and industry suggests that its resolution may be expensive and time consuming. As it affects all systems in parallel during a short time period, it may represent the largest IT project a brigade has ever undertaken. 

A major independent research organisation, The Gartner Group, estimates that 90% of all systems will be affected in some way by Year 2000 problems. Although it is likely that fire service systems will not be the hardest hit, any major malfunction could have a major impact on public confidence in the service. 

As regards embedded systems, brigades are potentially very exposed, particularly with regard to automatic fire alarm systems. Appendix 4 to the Notes sets out a list (far from exhaustive) of typical everyday electronic devices which may contain date-dependent processors 

It is possible that brigades will have to divert resources from other projects to solve Year 2000 problems As the millennium approaches, external resources - such as consultants and contractors - will become scarcer. In some circumstances brigades may consider early replacement of existing systems, but a careful and conservative assessment of the risks of any malfunction or delay in implementation must be made.

When Will it Arise? Brigades have an ever increasing inventory of computer programs and systems, and all must be reviewed and altered if necessary to avoid errors, operational inefficiencies and putting the public at risk. There is very little time available to solve the problem, so clearly the earlier a brigade begins to work on its solutions the more chance it has of being successful. 

For systems which store forward dates, problems may start to manifest themselves as soon as dates after the end of this century are used or implied.

 Can We Fix the Problem by Buying Off-the-Shelf Software? 
 
Unfortunately there is no universal solution which can be applied. This Notes shows how a brigade can mobilise its resources in an effective way to tackle the problem, and ensure that alternative courses of action are thoroughly and rapidly evaluated having regard to practicality, robustness and affordability. 

In some areas off the shelf solutions may be a possibility, but each brigade must undertake the following actions: 

  • appointment of a manager or management team to take charge of the brigade’s response to the problem;
  • assessment of the current situation, and the risks the brigade faces if it hits Year 2000 problems within its business and operational processes and systems;
  • evaluation of the practicalities of the types of solutions being proposed, having regard to risk, cost and operational impact; development of a careful and thorough plan to tackle the problem;
  • arrangements to monitor closely the implementation of actions to overcome the identified problems, including the provision of comprehensive test facilities.
  • These Notes provide proposals for undertaking the tasks outline above. 
     

External Factors Fixing the problems in-house may be only part of the task. Brigades may have external systems and communications links to many outside organisations - service providers, business collaborators and others. To tackle the issue completely, these linkages and the risks inherent in them need also to be addressed. 

Another possibility which needs to be considered, or may be under consideration, is whether brigades may be able to gain from selective collaborations with each other to tackle common problems. This may be particularly appropriate where several brigades use the same system or facility from a single supplier.

Management Arrangements In tackling the Year 2000 problem, the Notes recommend a structure where: 
  • senior management accept clear responsibility for driving through a comprehensive assessment and action plan;
  • an adequately resourced programme or project ot match the scale of the issues expected is set up;
  • the range of possible solutions is considered in a holistic fashion, with proper business evaluation of the alternatives, rather than a knee-jerk technical reaction.
Conclusion A seemingly simple problem which has the capability to bring major corporations to their knees requires serious and concerted senior management commitment, thorough investigation and careful planning. Taking action immediately should allow the problem to be managed, although significant redeployment of manpower and financial resource may be necessary.

2. INTRODUCTION

2.1 Pinpointing the Year 2000 Problem
 

Exactly what is the problem? The problem is that we talk about, and store, date information in a convenient shorthand form. We use 01/12/96, knowing we mean 01/12/1996. However computers only know what they are told, and therefore cannot distinguish between the dates 01/12/1996 and 01/12/2096 and 01/12/1896 unless programmed to require input of the four-digit year. Many programs written over the last several decades used only the last two digits in order to save storage space. Equally, they will not treat the year 2000 as a leap year. 

This will cause problems with many computer systems which use date information and exchange it with other systems. Whilst at first glance this seems an easy problem to fix, it isn't. It will also affect computers outside the mainstream of IT, such as telephone switchboards, communications network equipment and labour time-clocks.

Obstacles to fixing the problem There are many popular assertions about the Year 2000 issue, which fail to recognise the type and nature of obstacles which will get in the way of a smooth solution to the problem, such as: 

"The problem could be easily fixed if each organisation only had a few systems and programs". 

The problem is they may have hundreds or thousands. 

"The problem would not be too bad if dates were always treated in the same way for input, storage, analysis and reporting". 

The problem is that one single computer program may handle dates in several different ways. 

"We shall be able to assess the problem after we have looked at the documentation".  

The problem is that most organisations had no standard way of recording date information and documentation of many systems is woefully out of date, or non existent. 

"The problem should not be too bad because we’ve only bought packaged software in recent years".  

What organisations often don’t realise is that many of today's packages were originally designed a decade or more ago - still in the age of shorthand dates. Additionally each package probably treats dates in different ways, so when information is swapped or compared between systems, even after being fixed by the supplier, there may still be problems. If anyone has done anything to them - programmed bespoke interfaces to other systems for instance - these add-ons could themselves not handle dates properly, and are probably not covered by any assurances the supplier may give.

Action is urgent You cannot wait - date problems are happening to businesses now. Some organisations have already begun to experience date difficulties. For example, consider what is (or was!) the earliest time at which your brigade will need to enter a date for something which will happen after 1999? 

The problem has been subject to considerable hype in the media. But for some organisations, it is moving rapidly from hype to reality and will quickly turn into a corporate threat, unless action is taken.

Purpose of these Notes This document provides a general overview which can be used by senior managers to assess the impact that Year 2000 computer system issues will have on their own brigade, including guidance for a consistent systematic approach to the Year 2000 problem;
Coverage The Notes concentrate on all types of operational and administrative computer systems, personal, departmental and brigade-wide. Embedded date-dependent electronic systems in technical devices such as wireless communications systems, telephone logging systems, time-clocks or CCTV recorders, which may have their own in-built processors, are not covered in specific detail, but additional guidance is given to tackling this area. 

Following the proposals will facilitate the development of local answers to the question "How vulnerable to disruption are the public services provided by the brigade as a result of computer system malfunction caused by Year 2000 date problems?" 

It will also suggests a framework within which the necessary actions can be taken to eliminate the main vulnerabilities and minimise the risks from the date change. 

It is clear that that the structure proposed in these Notes does not represent the only viable way of approaching the Year 2000 issue. Some brigades may have existing projects/ programmes under way. In this instance, it is hoped that the contents of the Notes will constitute a checklist and "sidelight" against which the structures set up can be validated and improved if necessary. 

3. RESPONSIBILITIES AND MANAGEMENT
 

Ownership and responsibility This section of the Notes considers the roles and responsibilities of officers and managers within fire service brigades for addressing the Year 2000 problem. The suggestions herein recognise that there will be different levels of responsibility and "ownership" of the issue, spanning business and technical domains. They also allow that there will be significant variations in detailed role allocation, dependent upon the size and complexity of a particular brigade and its IS/IT history. 
The developing general UK pattern for Year 2000 compliance management now points clearly to the chief executive and board of management of both private and public organisations as having clear top-level responsibility. Pending legislation may make this legally enforceable/actionable for corporate bodies. In the Fire Service, this translates in each brigade as direct responsibility by the Chief Fire Officer. 
Clearly, the principal officers cannot be expected to handle detailed compliance assessment/testing activity. The process must be managed as a project or a number of projects (referred to as a programme); for example as described in Home Office guidance for the acquisition of a mobilisation and control system; but the resources required will depend on each brigades assessment of its needs.
Other Bodies Brigades will also need to assess how far their responsibility should extend in alerting organisations which have fire risks which may be affected by computer malfunction. 

4. YEAR 2000 COMPLIANCE ACTION PLAN

4.1 Introduction
 

Overview This section describes a framework for brigades to use to enable them to overcome Year 2000 problems in a well managed, structured environment. The Framework is based on the operational and business use of systems, rather than starting from a technical-fix perspective. 

Comprising five phases, the framework defines a structure to assess the situation, evaluate the options to overcome problems, undertake the detailed planning and manage the system change programme:

Assessing the situation Through the use of focused working groups involving a mix of technical and user representatives, a set of risk questionnaires is completed. The results will pinpoint the scale and intensity of the Year 2000 problem and provide a snapshot of how vulnerable the brigade is to experiencing date-related problems. The level of effort required and the cost of remedial action can be better assessed at this point.
Evaluating the options A team approach considers the alternative courses of action available, this includes manual procedural change options as well as the technical fix alternatives. Evaluation will need to take full account of the skills required and overall costs (including indirect ones).
Seeking by-products or additional benefits In considering alternative options, the brigade should specifically review whether there may be opportunities to gain additional business benefits from the necessary change actions. Since there may be significant disturbance and cost in Year 2000 compliance actions, it may be worth "going the further mile" in order to add extra value - perhaps by undertaking functional or technical upgrades as add-ons to the primary work. 

In some instances, it will make more sense to accelerate replacement of legacy systems or sub-systems, rather than simply sink funding into making them compliant at the same level of capability and serviceability

Planning to tackle the problem For each option, the financial implications are analysed. This covers all costs of changes to systems, testing, additional computer facilities, implementation and integration with other systems and staff training issues. The selected options can then be planned in detail. This could be a complex exercise for some brigades with large numbers of systems.
Managing the change Programme In larger brigades a number of projects may be managed together under a Programme structure. The Programme should be designed to deliver positive progress at regular milestones, in order to provide ongoing assurance to senior management that the Year 2000 risk is being managed effectively. The management process also provides an opportunity to test whether other benefits have been achieved, such as process rationalisation or administrative task reduction. 

Year 2000 compliance work will inevitably affect some pre-existing programmes or projects. This phase of work will need to resolve conflicts arising from these.

Risk assessment When assessing the risks of their Year 2000 programmes, brigades should bear in mind a number of risk factors which will have greater weight than usual in IT projects
  Time deadline
  • The implementation date cannot be changed.
  • Different systems will be affected at different times up to the New Year 2000 as forward dates are entered. With some system it may be difficult to predict when this time will be.
Work pressures 
  • Large numbers of programs may be affected requiring amendment and testing. As a result there will be huge pressure on technical skills and computer resources.
  • Systems suppliers will be experiencing a major demand for either Year 2000 fixes, or new software to replace non-conformant systems. Therefore lead times to obtain supplier support may become extended.
  • The large demand for programmers caused by the Year 2000 issue and European Monetary Union (EMU) may well be an additional cause of resource scarcity, especially near large financial services centres.
Testing 
 
  • It may seem an obvious statement, but no one has ever been through a Year 2000 date change before. Whilst it is possible to mimic some aspects of Year 2000 problems, the complete interactions of programs, systems and manual procedures has never been experienced, so a body of informed expertise is not available.
  • Testing procedures are therefore at risk of being defective in some aspects, so contingency must be considered in the planning and resource allocation.

4.2 Assessing the situation
 

Context and business environment Each brigade has a responsibility to assess the extent to which its operations could be adversely affected by incorrect date processing around the Year 2000. 

Although the problem is technical, it can have fundamental effects on the way vital systems operate and interfere with working practices. Therefore the problem should be tackled from a business perspective. This will entail senior management involvement, setting a realistic budget, assignment of necessary personnel, ensuring sufficient computer resources are available, taking steps to ensure cross divisional working and implementation of project and change management procedures.

Setting assessment objectives The objectives for the assessment should be agreed by senior officers and then communicated to all levels. The assessment will establish the impact the Year 2000 date change could have on the operational capability of the brigade. 

Objectives should include: 

  • identification of date dependent activities;
  • cataloguing the standards currently used for date representation;
  • identification of date-related risks;
  • creation of a full inventory of all systems/programmes in use to ensure all are assessed;
  • creation of an inventory of all areas where date-dependent embedded systems in electronic devices may cause problems.
Undertaking the Assessment The actions needed to undertake an assessment will vary between brigades, and will be affected by the size of the brigade, extent of computerisation, and numbers of IT staff. To make the assessment brigades should: 
  • consider the use of workshops involving technical, management and user/business-side staff to identify the key processes and related systems;
  • develop a date impact analysis across all operational systems;
  • identify where date information is input to systems;
  • establish where date information is used on reports and other readable outputs;
  • define the date standard the brigade will move to;

  • establish where date information is received from or sent to other organisations.
The Assessment Results The assessment results will be in a document which contains information on: 
  • the processes which will be affected;
  • an assessment of the level of threat posed by each system;
  • the preferred standard date format to be used by the brigade;

  • the main issues which need to be resolved in conjunction with suppliers.

4.3 Evaluating the options
 

Context To decide on the most practical approach to the problem, management will wish to consider alternatives, and take into account the impact on the brigade as a whole, rather than each individual operational system in isolation.
Options of the Evaluation It is vital that senior management assess the practicality of each of the options being considered, taking a wide business view.
The evaluation will consider: 
  • the technical problems relating to both software and hardware;
  • the problems, costs and benefits of the option of doing nothing;
  • the earliest dates when problems will show up and the latest time fully tested changes will have to be proven for live use.
Undertaking the Evaluation To evaluate your system you will need to: 
  • document the hardware and software used by the brigade;
  • hold workshops with suppliers to understand their strategies and services they may be offering;
  • assess the risks the brigade faces;
  • develop an outline plan and preliminary cost estimate for making the changes.
    •  

Results from the Evaluation The results should demonstrate that a realistic assessment of the available options has been made. There should also be sufficient evidence to justify the recommended course of action. This evaluation evidence may include: 
  • a matrix showing how the options counter the risks identified;
  • comparative assessment of the options, including resource implications;
  • an assessment of the organisational impact of changes;
  • the recommended course of action;
  • assessments of earliest start and latest end dates. 

4.4 By-products and additional benefits
 

Seek business gain Simply fixing date problems in existing systems will eliminate risks and secure operations. However, it is an essentially sterile and unproductive investment, reactive in character. 

In developing action plans and specific tasks for specific problems, it is strongly recommended that brigades try to identify ways in which additional benefits can be obtained. The point is that if systems have to be "opened up" in order to tackle date issues, it may well be possible to achieve some additional improvements in their performance, reliability and/or functionality. In some instances, it may be possible cost-effectively to add sufficient enhancements to prolong the life of legacy systems.

Fix or replace? In deciding what to do about non-compliant systems, it will usually be appropriate to consider whether outright replacement is a viable and cost-effective option. Factors to bear in mind here include not only the direct costs, but also the trade-off between the extra functionality and fitness for purpose which a new procurement could deliver, set against the likely greater project effort required to specify and implement a complete replacement. 

Given the limited time available for date compliance, many otherwise viable replacement alternatives may be ruled out as too risky. 

 
4.5 Planning to tackle the problem
 

Importance of planning The failure of many IT projects can be traced back to inadequate project management - which is itself heavily dependent on the planning process. The degree of success of individual brigades in achieving their Year 2000 objectives will rest on the creation of appropriately detailed and comprehensive plans. Brigades with extensive computer systems, or those with large numbers of bespoke options are likely to be most at risk and will therefore derive most benefit from investment in the planning process.
Objectives of planning The planning phase will provide a structure for work within the brigade to achieve its Year 2000 compliance objectives. This will facilitate senior management monitoring of progress.
Key steps to develop a plan Each brigade should develop plans which contain the following elements: 
  • a project structure which demonstrates senior management commitment to the project; development and publication of project plans which cover critical aspects of the project including major milestones, interdependencies and risk management; 
  • provisions for work to identify opportunities to improve business processes.
Outputs from planning work A Project Initiation Document (This term derives from the PRINCE project management methodology) is needed at a realistic level of detail, including cost and time estimates, a list of the major work which has to be undertaken, target dates and responsibilities. This will incorporate: 
  • an outline plan for each business area;
  • cost profiles and budget holder definition;
  • business process opportunities report;
  • Year 2000 priorities report;
  • the date standards the brigade will work to achieve;
  • risk analysis and proposed management activities.
Contingency planning In many cases, Year 2000 projects cannot afford to slide back on delivery dates; the margin available is simply to tight. The planning process must explain what will happen if delivery timings prove impossible to meet in any critical areas. 
Contingency Actions Actions to be taken might need to include such options as drafting in temporary extra manual effort to keep business processes operating if systems fail. It may be possible to hand over some or all processing to an external supplier for a period. 

It must be recognised that some contingency actions could stand to incur significant costs if set in train. 

4.6 Managing the Change Programme
 

An iterative approach The immovable end-date for Year 2000 work (where forward-date processing requirements do not in fact impose a shorter deadline) means that there is little time available for getting projects wrong and restarting. 

In this context, it is all the more vital that the Year 2000 programme should incorporate a frequent re-examination of the inventory of systems to be assessed/dealt with. Experience to date has suggested that the numbers of systems, computer types and devices to be tested in organisations is far greater than at first meets the eye. 

It seems quite probable that any brigade is likely to overlook some of the systems at risk. Checking and re-checking the inventories and the conclusions of the assessment exercise is one way of tackling this.

Impact on other projects and programmes Year 2000 compliance work will inevitably affect some pre-existing programmes or projects. Managing the business and resource conflicts this may create could be an important part of the work 

It should be apparent that the severe potential business pressures that may be generated by such conflicts act as a further reason for brigades' ensuring that these key roles are filled by appropriately senior/experienced officers.

 
5. COMMENTARY ON SPECIFIC ISSUES

5.1 Relations with others
 

Interfaces When data is transferred between systems, or downloaded from a central system to a local personal computer, it is vital that the approaches to handling Year 2000 dates are compatible. Otherwise there may be real risk of a date fix in one system triggering unforeseen problems in dependent areas of other systems to which it passes data. 

Tackling this will require careful design and planning, especially when outside organisations such as Local Authorities are involved. 

It must be recognised that when two or more systems are interfaced, it will not be enough simply to test the compliance of each separately. In many cases, the interface(s) will have been built as a separate exercise (by a supplier or internally). The software standards/ structures used may well differ from both (or all) the systems interfaced. If any date-related data is passed between the systems, the interface may have been constructed to include a translation function, changing between different date formats in the different systems. 

The burden of this is that interfaces must be assessed for compliance in their own right. Testing routines must explicitly test the compliance of the interfaces in a comprehensive working scenario.

Outsourcing / FM Any brigade with systems provided or supported under an outsourcing or Facilities Management arrangement will need to assess these just as rigorously as in-house facilities. To the extent that legacy systems may have been handed over to an FM provider, these are perhaps by definition more likely to be of an age to suffer Year 2000 problems. 

Many brigades have legacy applications provided by related local authorities. These fall under the same rules as any other outsourced systems.

Supplier Assurances Probably a majority of fire service systems have been provided by external suppliers. If the supplier is still providing a maintenance/support arrangement, it will be important to examine very carefully whatever commitments or assurances are given about Year 2000 compliance. 

Statements that an application does not currently comply, but will do by a certain future date, should be assessed for various aspects of risk. 

  • How solid is the statement - are there any conditional comments or "weasel" words or phrases?
  • Are you confident in the solidity and reliability of the supplier - will it definitely be around in 2000?
  • Does the statement only apply to standard versions of the software (and has yours been modified in any way - by you or the supplier)?
  • Does the statement cover any special interfaces to other systems - and have you thoroughly assessed possible exposures in these?
  • What demonstrable proof of claims made is there, particularly for mission-critical applications?
  • Ultimately, brigades need to take tangible actions to test the compliance of systems on which they are dependent. A supplier assurance might (if solid enough) form a basis for subsequent legal action, but this could be poor comfort if brigade operations and the public had been severely impacted by a major systems failure. 

Brigades’s Major Risks Brigades will need to assess whether they should seek assurances from major risks, such as those in the petrochemical industry, that adequate measures are being taken to prevent Year 2000 related failures. 

5.2 RISK MANAGEMENT
 

Background Much of these Notes discusses various aspects and types of risk in Year 2000 rectification work. It should be recognised, however, that in one sense the Year 2000 Programme is itself an exercise in risk assessment and management.
Risk Areas Other areas of the Notes have pinpointed specific risks to be addressed. In formulating Programme structures, brigades should incorporate plans and structures for the main types of risk to be tackled. These will fall into several overlapping categories.
Business Risk For example, conflicts with other key organisational priorities or projects sapping effort from the Year 2000 Programme; or the strategic risk of organisational/structural change in the brigade effecting the realisation of additional/side benefits identified as supporting Year 2000 projects. 

A major potential source of business risk lies simply in the potential failure of a brigade to address the Year 2000 problem with a coherent approach, managed by an appropriately senior individual (who will still be on the establishment in 2000!).

Technical Risk Examples might include the Year 2000 fix/replacement projects incorporating new and unfamiliar/untested technologies or reliance on being able to turn existing technology facilities to uses and deployments not previously experienced.
Supplier Risk The scope, scale and track record of suppliers need to be considered. Does the supplier have a track record of delivering on promises on time? Are there known distractions impacting the supplier’s team - other major projects for instance? 

APPENDICES 1. Hardware/Platform Risk Assessment

The computing environment in most brigades will be a mixture which comprises proprietary and open systems, terminal and client server, centralised and decentralised systems.

When assessing risks consider, for each system:

For each of these areas you should discuss with your supplier:

2. Checklist for Action (Computer Systems)

The following provides a proforma for management responsible for the implementation of Year 2000 computer system changes
 

Area of Concern Yes No 
A full assessment of all business processes has been conducted to identify dependent systems    
All local and stand-alone systems have been identified and Year 2000 problems assessed    
All local departmental systems have been identified and Year 2000 problems assessed     
All ancillary systems (security, call logging etc.) systems have been identified and Year 2000 impacts assessed    
A Year 2000 date standard has been defined    
A Change Programme has been defined and responsibilities arranged    
Earliest/latest compliance dates have been identified for each system    
Liaison has been established with all manufacturers suppliers    
Budget estimates have been prepared and are authorised    
A plan containing key milestone dates and resource implications has been prepared    
Programme risks have been assessed thoroughly and independently checked    
A risk management plan has been prepared and responsibilities assigned    
Contingency arrangements have been identified     
A regular-interval programme progress reporting process has been established    

Checklist for Action (Embedded Systems)

Embedded systems - sometimes referred to as embedded processors - are computer-chip-based sub-systems built into many electronic devices. Concern has been growing that many of these have date functions built into them which may fail when dates change from 19xx to 20xx formats.

It is important to recognise that this risk may not depend upon whether the particular device has any explicit date-dependent functions to perform in the particular device concerned. As just one example, a major international burglar alarm supplier has estimated that approximately 20% of the alarm systems which it has supplied and which are still in use will suffer problems of greater or lesser severity at the date change.

The very breadth of the embedded-systems exposure makes it difficult to address. Brigades will need to undertake a general risk assessment to identify the areas where greatest risk to operations and public or officers’ safety may arise.

Where possible, this will mean obtaining unequivocal statements of the position from the suppliers of devices concerned. Where this proves impossible for any reason, the key alternatives are likely to be to bring forward planned replacements/upgrades, or to put in place manual contingency work-arounds to cope in the event that devices fail around the date change.

The following checklist of device types which might be affected is not, and cannot be, exhaustive.
 

electronic locks burglar and fire alarms heating and ventilation systems
lifts/elevators CCTV cameras/monitors sprinkler systems
vehicle management systems photo surveillance equipment time clocks/stamps
radios traffic light controllers faxes
radio sub-stations mobile phones telex machines
telephones & switches pagers car park barriers
remotely operated doors personal organisers schedule systems for maintenance (e.g. fire extinguishers)

4. British Standards Institution (BSI) Definition

INTRODUCTION

The BSI document PD 2000-1: 1998 which is quoted below contains the formal definition of the expression "Year 2000 conformity" developed by the British Standards Institution.
 
THE DEFINITION

Year 2000 conformity shall mean that neither performance nor functionality is affected by dates prior to, during and after the year 2000. In particular:
 
 

Rule 1  No value for current date will cause any interruption in operation.
Rule 2   Date-based functionality must behave consistently for dates prior to, during and after year 2000. 
Rule 3  In all interfaces and data storage, the century in any date must be specified either explicitly or by unambiguous algorithms or inferencing rules. 
Rule 4 Year 2000 must be recognised as a leap year.

AMPLIFICATION OF THE DEFINITION AND RULES
 

General Explanation Problems can arise from some means of representing dates in computer equipment and products and from date-logic embedded in purchased goods or services, as the year 2000 approaches and during and after that year. As a result, equipment or products, including embedded control logic, may fail completely, malfunction or cause data to be corrupted. 

To avoid such problems, organisations must check, and modify if necessary, internally produced equipment and products and similarly check externally supplied equipment and products with their suppliers 

The purpose of this document is to allow such checks to be made on a basis of common understanding. Where checks are made with external suppliers, care should be taken to distinguish between claims of conformity and the ability to demonstrate conformity.

Rule 1 1.1 This rule is sometimes known as general integrity. 

1.2 If this requirement is satisfied, roll-over between all significant time demarcations (e.g. days, months, years, centuries) will be performed correctly. 

1.3 Current date means today's date as known to the equipment or product

Rule 2 2.1 This rule is sometimes known as date integrity. 

2.2 This rule means that all equipment and products must calculate, manipulate and represent dates correctly for the purposes for which they were intended. 

2.3 The meaning of functionality includes both processes and the results of those processes. 

2.4 If desired, a reference point for date values and calculations may be added by organisations; e.g. as defined by the Gregorian calendar. 

2.5 No equipment or product shall use particular date values for special meanings; e.g. "99" to signify "no end value" or "end of file" or "00" to mean "not applicable" or "beginning of file".

Rule 3 3.1 This rule is sometimes known as explicit/implicit century. 

3.2 It covers two general approaches: 

(a) explicit representation of the year in dates: e.g. by using four digits or by including a century indicator. In this case, a reference may be inserted (e.g. 4-digit years as allowed by ISO standard 8601:1988) and it may be necessary to allow for exceptions where domain-specific standards (e.g. standards relating to Electronic Data Interchange, Automatic Teller Machines or Bankers Automated Clearing Services) should have precedence; 

(b) the use of inferencing rules: e.g. two-digit years with a value greater than 50 imply 19xx, those with a value equal to or less than 50 imply 20xx. Rules for century inferencing as a whole must apply to all contexts in which the date is used, although different inferencing rules may apply to different date sets.

General Notes For Rules 1 and 2 in particular, organisations may wish to specify allowable ranges for values of current date and dates to be manipulated. The ranges may relate to one or more of the feasible life-span of equipment or products or the span of dates required to be represented by the organisation's business processes. Tests for specifically critical dates may also be added (e.g. for leap years, end of year, etc.). 

Organisations may wish to append additional material in support of local requirements. Where the term century is used, clear distinction should be made between the "value" denoting the century (e.g. 20th) and its representation in dates (e.g. "19xx"); similarly, 21st and "20xx".



Fire Research & Development publications

Fire Research and Development Group (FRDG)

Fire and Emergency Planning Directorate (FEPD)

Home Office front page  



Crown Copyright 2000
Page last updated 18th January 2000