Safety cases have been used for many years in various industries, particularly nuclear power and aviation. The process industries have not used them as much, although they are a standard feature of offshore operations in offshore operations in Europe, Australasia and parts of Asia.
Following the Deepwater Horizon event (2010) it is possible that safety cases will be more widely used in other process industries, and for offshore operations in United States waters. This knol provides an introduction to safety cases, how they are developed and what they contain.
A safety case is simply the case that the management of a facility makes to demonstrate that the facility is as safe as can be reasonably expected. It is analogous to the case that management may have to make to a court following a serious accident. If the safety case is accepted then a safety case regime is implemented.
- A fire, explosion or the release of a dangerous substance involving death or serious personal injury to persons on the installation or engaged in an activity on or in connection with it;
- Any event involving major damage to the structure of the installation or plant affixed thereto or any loss in the stability of the installation;
- The collision of a helicopter with the installation;
- The failure of life support systems for diving operations in connection with the installation; or
- Any other event arising from a work activity involving death or serious personal injury to five or more persons on the installation or engaged in an activity in connection with it.
Principles of a Safety Case
A safety case is built upon the following three principles.
- Those who create risks are responsible for controlling those risks.
- Safe operations are achieved by setting and achieving goals rather than by following prescriptive rules.
- All risks must be reduced such that they are below a threshold of acceptability.
The Cullen report (1990) that analyzed the Piper Alpha disaster in detail stressed that the quality of the offshore safety cases in use at that time needed much improvement (indeed, it could be said that it was the Cullen report that initiated present day safety cases. The report stated,
Primarily the safety case is a matter of ensuring that every company produces a formal safety assessment to assure itself that its operations are safe.
Two aspects of the above quotation are particularly noteworthy.
Although the term “Safety Case” is not widely used in the United States, the safety case approach to the development and application of Safety Management Systems is, in fact, used in a wide range of American industries. For example, the nuclear and space industries prepare Safety Analysis Reports (SARs) and Mission Safety Evaluations (MSEs) respectively. These documents have the same intent and general structure as a safety case. One major oil and gas company develops “HSE cases” that are essentially the same as a safety case; they just choose to use a different name.
Safety Case Definition
A safety case can be defined as follows:
A documented body of evidence that provides a demonstrable and valid argument that a system is adequately safe for a given application and environment over its lifetime.
Another definition, provided by the UK Ministry of Defence (MOD 2004) is:
A structured argument, supported by a body of evidence that provides a compelling, comprehensive and valid case that a system is safety for a given application in a given operating environment.
Yet another definition is provided by the Government of Western Australia (Department of Consumer and Employment Protection 2005):
A safety case regime is an objective-based regime whereby legislation sets broad safety objectives and the operator, who accepts direct responsibility for the ongoing management of safety, develops the most appropriate methods to achieve those objectives.
It can be seen that, although the above definitions have much in common, there is not a single, agreed-upon definition as to what constitutes a safety case. Heiler (2005) states,
Arguably, then, the question is not what is a safety case regime — but rather what kind of safety case regime is being contemplated . . .
In other words, each operator and regulator must determine the nature of the safety case for their particular situation. There is no “one size fits all” safety case structure or design.
Types of Safety Case
An industrial facility will generally generate a series of safety cases — one for each of the major phases in its design, construction, operation and decommissioning/abandonment. Updates to safety cases may also be required if there is a significant change in conditions, such as follows a major expansion or the introduction of a new highly hazardous chemical.
A safety case should not focus on promoting a particular design or operations option. Instead it should provide a discussion on the merits of different options and a justification that the chosen option is indeed the one that reduces risk to a level that is acceptable. For facilities that are already operating the safety case should go beyond the original design information — it should incorporate actual operating experience.
Purpose of a Safety Case
The principal reason for developing and implementing a safety case is, of course, to ensure that the people on a facility are safe. However, a safety does have additional justifications, some of which are discussed by Maguire (2006). These additional reasons, particularly those that apply to offshore installations, are discussed below.
Defense in Law
If the worst happens, and the facility does have a serious accident then it is likely that litigation will follow. A well-constructed and maintained safety case provides the basis of an excellent defense. Even though an accident has occurred, the safety case can demonstrate that management had given serious consideration to understanding the risk that their system posed, and that an appropriate Safety Management System was in place.
Even if an accident has not occurred, it is useful to design and organize the safety case as if it were being used in a legal defense. The advantage of doing this before an accident takes place is that management has the time and flexibility that it would not have were it having to prepare a court defense.
A safety case is also a business case, i.e., it can be used to show investors, customers, insurers and corporate managers that the risk associated with an expensive facility, such as a deepwater offshore platform, has been analyzed, and that it is at an acceptable level.
This knol focuses on the development and use of safety cases within the offshore oil and gas industries. However, the general principles can be applied much more broadly. Safety cases were first developed in the nuclear and aerospace industries, and can, in principle, be developed for any type of complex industrial activity that poses a high risk to workers or the community. For example, in addition to nuclear and aviation, safety cases have been developed for pipelines, railways and mining operations.
The nuclear power industry was probably the first to use safety cases. In the United Kingdom the Nuclear Installations Act of 1965 required covered facilities to create and maintain a safety case in order to obtain a license to operate. The nuclear industry has placed particular emphasis on the use of Quantitative Risk Assessment (QRA) with the use of techniques such as Fault Tree and Event Tree Analysis. Because nuclear power plants are technically quite similar to one another, this industry has also been able to set up reliability data bases to which they most facilities contribute.
Within the onshore process industries the safety case approach was introduced in Europe to onshore process plants as part of the ‘Seveso Directive’ in 1986. It has since been replaced by the Seveso II Directive of 2003. The Seveso Directives apply to industrial establishments where dangerous substances are present in quantities exceeding their threshold levels.
In the UK the Directives led to the creation of the CIMAH (Control of Industrial Major Accident Hazards) regulations in 1984. These regulations required manufacturers of hazardous chemicals to create a safety report — in effect a safety case. They also had to show how the hazards were being effectively managed. CIMAH was replaced by COMAH (Control of Major Accident Hazards) in 1999.
Safety Cases in U.S. Waters
Companies operating in U.S. waters have not traditionally prepared safety cases. Following the Piper Alpha disaster of 1988 the offshore industries in the United States and Europe (primarily the UK) developed different approaches to the management of safety. The European approach, which was encouraged by the Cullen report (discussed above) was to develop and implement safety cases. In the United States the approach was to follow the relatively prescriptive guidance in documents such as API RP 75.
Following the Deepwater Horizon event the Bureau of Ocean Energy Management, Regulation and Enforcement implemented a requirement that safety cases be prepared for drilling operations. Companies can use the template from the International Association of Drilling Contractors (IADC) has a template that is widely used. It is possible that safety cases will also be legislated for deepwater production platforms, but no information about this possibility is currently available.
However, operators in the U.S. (primarily the Gulf of Mexico) raise the following objections and concerns regarding this potential trend.
- The Gulf of Mexico (GoM) has between five and six thousand platforms — many of them small and in shallow water. It is simply not economically feasible to write a safety case for each platform. Nor does it really make sense, since they are so similar to one another.
- The use of API standards and related documents has been proven successful. Although the Deepwater Horizon event was extremely serious, it was the first major blowout in U.S. waters since 1969 and the Santa Barbara blowout. The much more recent Montara event that occurred in 1999 occurred on a platform that operated under a safety case regime.
- The development of safety cases and the application of the subsequent safety case regimes is expensive, time consuming and creates a large amount of paper work. If it could be demonstrated that this investment truly improves safety then there would be no argument. However, as noted in the previous paragraph, there is no convincing evidence that either approach if clearly better than the other.
- When all platforms are designed and operated to the same standards (mostly from the API) it is relatively easy to audit them. The auditor simply has to look up the appropriate code or rule, and he or she can come to a quick conclusion. Such is not the case with a safety case system, where each platform has its own unique program against which it has to be evaluated.
Even if safety cases do become a regulatory requirement for production platforms it will not be necessary for the managers of facilities in U.S. waters to throw away all the work that they have done and to start again. Moreover, the legal requirements to meet the elements of API RP 14C, for example, will remain in place. A safety case will, however, provide operators with an opportunity to pull together all the work that has already been done into one, integrated document. If safety cases are introduced to U.S. waters it is essential that they are seen in this integration role rather than as an add-on activity that is perceived as being expensive, but adding no value.
Although different approaches to offshore safety have developed in the North Sea and the Gulf of Mexico (GoM) it is important to recognize that there has always been considerable overlap between them. In particular, many of the API standards are used in the development of safety cases. Moreover, the two cultures would appear to be moving toward one another. In the North Sea declining production has resulted in small companies taking over platforms from industry majors. These new owners do not have the financial depth to prepare elaborate safety cases — instead they simply want to be told what the rules are, and what they are expected to do, just like the smaller operators in the GoM.
In the Gulf of Mexico, on the other hand, the trend has been to deep water, high volume platforms. These platforms are expensive. Hence, as already noted, there is a tendency for the operators of these platforms to develop safety cases — often under a different name — so as to limit their financial risk.
Effectiveness of Safety Cases
A safety case had been prepared for the Nimrod. It turned out, however, that the quality of that safety case was gravely inadequate, leading to the following statements,
. . . the Nimrod safety case was a lamentable job from start to finish. It was riddled with errors. . . Its production is a story of incompetence, complacency, and cynicism.
The Nimrod Safety Case process was fatally undermined by a general malaise: a widespread assumption by those involved that the Nimrod was ‘safe anyway’ (because it had successfully flown for 30 years) and the task of drawing up the Safety Case became essentially a paperwork and ‘tickbox’ exercise.
Comments such as these emphasize that, for a safety case to be effective, the following three points must always be considered.
The development and on-going implementation of a safety case is expensive and time-consuming. It also requires the commitment of substantial amounts of time from key personnel — people whose services are always in demand elsewhere in the organization.
In addition, just as employee participation is the key element of process safety management systems, so worker involvement is crucial to the effective application of safety cases.
Once a safety case is complete there is a danger that no one will pay attention to it and that it may sit on a shelf gathering dust. A safety case is an operational tool that should be used on an on-going basis.
Up to Date
A safety case should be kept up to date. This is not too difficult when a major change to a facility is being made. However it is possible that a succession of minor changes over a period of years could materially affect the safety of a facility such that the safety case needs to be updated
Features of a Safety Case
- Duty-Holder Responsibility
- Participation and Commitment;
- Information Availability;
- Non-Prescriptive and Performance Based;
- Risk Management System;
- Management Systems;
- Living Document; and
- Auditor/Assessor Responsibility.
Participation and Commitment
The active participation of all employees and contract workers is the key to the success of any safety program — including safety cases. This means that not only are employees informed and trained about the safety case, but they also actively participate in its application and are encouraged to think of ways of improving system safety. Ideally the safety case will lead to the creation of a safety culture.
The commitment of management is also required. Given that the development and implementation of a safety case is expensive and time-consuming, management must commit the necessary funds and time of key personnel — people whose services are always in demand elsewhere in the organization — to the development and implementation of the safety case.
Although the goal of high employee participation is commendable, it has to be recognized that many sections of a safety case are highly technical; realistically these sections are only going to be understood by safety specialists.
The safety case contains within itself all the information that is needed to support the arguments that are presented. In some ways it is analogous to the case that attorneys make after an accident in which they make the case that the facility operator did or did not do an adequate job of managing safety.
Non-Prescriptive and Performance Based
Safety cases are largely non-prescriptive; that is, rather than listing the detailed regulations, codes and standards that have to be followed, they basically address the requirement, “Do whatever it takes on your facility not to have accidents”. It is up to the managers, technical experts and the operations/maintenance personnel to determine how this should be done. (Of course, detailed rules do have to be followed when they apply; the safety case is not a justification or excuse for avoiding compliance.)
Non-prescriptive management programs are always performance-based because the only measure of success is success. Hence success is only achieved by not having incidents. But, from a theoretical point of view, such a goal is impossible to achieve. No matter how well run a facility may be accidents will occur; risk can never be zero. Accidents can always occur.
The success of prescriptive programs is measured, at least in the short term, by compliance with relatively detailed rules. One difficulty that a prescriptive approach faces is that technology changes very fast, particularly in deep water work, whereas the writing of rules and regulations is a slow and painstaking process. This means that prescriptive standards may not be sufficiently up to date to address current issues. Such a problem does not occur with non-prescriptive programs, such as safety cases. The management of the risk is the responsibility of the organization that creates the risk. If the organization has developed the technology that creates the risk, then that same organization can create the risk management systems that are needed to control the risk.
The use of prescriptive standards does, however, offer a number of advantages. First, given that the standards were developed by experts in the field their use will ensure that high levels of safety will be achieved, even if the persons designing and running the platform are not themselves industry experts.
Second, the use of prescriptive standards increases efficiency and reduces design time. Rather than having to develop safety concepts and standards from scratch, the designers and operators of a platform can quickly and efficiently apply recognized rules.
Finally, a prescriptive system allows for facilities to be audited more quickly and more consistently. The quality of the audit does not depend as much on the training and knowledge of the auditor as it would in a non-prescriptive environment. Moreover, when all platforms are designed and operated to the same standards (mostly from the API) it is relatively easy to audit them. The auditor simply has to look up the appropriate code or rule, and he or she can come to a quick conclusion. Such is not the case with a safety case system, where each platform has its own unique program against which it has to be evaluated.
Risk Management System
The risk management system, which includes both technical and managerial systems, is generally organized as follows:
- Identify the hazards;
- Determine the level of risk associated with each hazard;
- Describe how the risks are controlled; and
- Describe the safety management system that ensures that the controls are effectively and consistently applied.
The risk management system usually includes a quantitative analysis, i.e., the risk associated with each of the hazards in a facility is estimated numerically and given a value — typically in the form of so many fatalities or environmental releases per thousand years. These individual risks are then added to one another to give an estimate of the overall risk.
Systems for controlling risk should concentrate on management systems rather than just on hardware and instrumentation. Therefore the safety case must show that the correct management system for controlling safety is in place. Such a system is often referred to as a Safety Management System (SMS). It is the system by which hazards are identified and risks are continually and systematically assessed. These risks can then be either eliminated or controlled at the appropriate points in the facility’s life, ranging from initial design through construction, commissioning, operation and abandonment of the facility. The SMS must be comprehensive, integrated and contain feedback loops that continually measure performance and drive change.
The components of an SMS have been defined by the UK Ministry of Defence (MOD 1996) as:
- Measuring; and
- Review and development.
An SMS will include items such as the following:
- Safety policies and the organizational and facility safety objectives;
- Organization reporting structures – roles and responsibilities;
- Risk assessment and risk management;
- Methods of employee involvement in risk management;
- Employee selection, competency, training and induction;
- Integration of contractor and support services in risk management;
- Design, construction and commissioning procedures;
- Safe operational procedures for normal and abnormal circumstances;
- Systems of maintenance, inspection and modification;
- Systems of managing change to ensure safety;
- Methods, systems and procedures for ensuring the occupational health of employees;
- Emergency response including controls, personnel evacuation , escape and rescue;
- Incident investigation and reporting, corrective and follow-up action; and
- The method of performance review and audit including review in the light of external experience.
The SMS should ensure that all necessary linkages between system elements are identified and, where appropriate, should draw on the principles of quality management.
A safety case is a living document that describes the safety of an operation from the initial concept design, all the way through normal operations, to the eventual termination and shut down/abandonment of the facility. The safety case needs to be modified and upgraded as needed in order to ensure that risk and safety are properly managed at all times.
It is relatively easy to update the safety case when a major change to a facility is being made. However it is possible that a succession of minor changes over a period of years could materially affect the safety of a facility such that the safety case needs to be updated.
Auditor / Assessor Responsibility
All management systems must be audited. As one plant manager said, “There is always news about safety — and some of that news will be bad”. The only way to find that bad news is to carry out audits and reviews.
Auditors fall into one of three types. The first is someone from within the immediate organization who is charged with checking the quality of the program. The second type of auditor works for the company or duty-holder that owns the facility but is in a separate (often corporate) organization. This type of auditor may also be a company hired by the facility management to mimic a regulatory audit. The third type of auditor is a government agency or other regulatory authority.
With respect to safety cases, the auditor or assessor, who can represent either a government agency or a non-governmental body, has three key roles:
- Provide guidance to the owner as to what is required in the safety case.
- Formally accept (or reject) the safety case after it has been prepared and presented by the operator. Not only must the safety case as written be accepted, the operator has to demonstrate that his organization has the ability, management commitment and resources to implement the safety case’s requirements.
- Ensure that the operator is actually doing what he said he would do in the safety case once operations commence. Such reviews should occur on a regular basis. The UK HSE (Health & Safety Executive), for example, requires that, “the duty holder must carry out a “thorough review” of the current safety case at least every 5 years or as directed by HSE”.
Implicit in the safety case regulatory approach is that the safety case be evaluated and accepted (or rejected) by the regulator. Having a regulator accept a safety case regime can be tricky because, if there is an accident, the company involved can claim that some of the responsibility for the event lies with the regulator. To get around this dilemma, the UK HSE states that,
. . . “acceptance” requires satisfaction with the duty holder’s approach to identifying and meeting health and safety needs. HSE “accepts” the validity of the described approach as being capable, if implemented as described, of achieving the necessary degree of risk control, but HSE does not confirm the outcomes of that approach.
The acceptance or rejection of a safety case implies that the regulator has personnel who are qualified to evaluate the complex and sophisticated analyses that are a part of any safety case.
The active participation of the regulator in this manner differs from other standards such as OSHA’s process safety management program or Recommended Practice 75 from the API. In these cases the regulator does not check or validate the program; it merely requires that a program exists. Only if there is an accident is the program scrutinized by the regulator.
Overall, the assessor’s job is to ensure that management systems are in place, that they are effective, and they are being followed. Rather than checking on the details of the safety program, the assessor will evaluate management systems, and their effectiveness.
Structure of a Safety Case
Section I Executive SummarySection II IntroductionSection III Policies, Objectives, Regulations and StandardsSection IV Facility DescriptionSection V Safety Management SystemSection VI Formal Safety AssessmentSection VII Audit and Review
Section I — Executive Summary
This section should provide the reader with an overview of why the safety case was developed, the facilities and operations that it covers and who it was written for. The summary should provide a brief statement as to the assumptions, conclusions and recommendations that were made.
Section II — Introduction
The safety case should start with a description of the systems and methods used in its development.
Section III — Policies, Objectives, Regulations and Standards
In this section of the safety case the company management outlines its goals, and the parameters within which it is working.
Objectives for the facility can include targets for the number of safety events, system reliability and maintenance costs. Such objectives can affect the structure of the safety case.
The use of the safety case approach does not mean that regulations, codes and standards can be ignored. A regulation is a legal requirement — no matter how sophisticated a risk analysis may be, the regulatory requirements must be met. Therefore the safety case should summarize those rules, show how they are being complied with and how they are integrated into the overall safety case management system.
Standards from the API and other professional bodies such as the American Society of Mechanical Engineers (ASME) and the Institute of Electrical and Electronics Engineers (IEEE) can be referred to by the safety case.
Section IV — Facility Description
The safety case need not contain detailed procedures, calculations, drawings or plans, but should contain sufficient information to allow the regulator to assess whether the systems and conclusions presented in the safety case are reasonable. General documentary evidence that supports the conclusions reached in the safety case should be referenced. An assessor or regulator should be given access to the relevant documentation as necessary.
For offshore platforms, the safety case will generally contain the following minimum information.
- An overview of the facility, highlighting key assumptions and phases of development and any unique features;
- A summary of key design parameters with cross references to key technical documents (covering storm/wave/current conditions, wind, seawater/air temperatures, earthquakes, cyclones/hurricanes, other extreme conditions and seabed stability);
- A description of the process flow and operations;
- Equipment layout for all decks;
- A description of the functions of the facility with reference to key processes, wellhead and utility systems, drilling, workover, wireline systems, and marine and helicopter operations;
- A summary of hazardous substances that are used or stored at the facility, along with an estimate of the inventory of these substances:
- A description of the design safety philosophy, features and systems provided on the installation with emphasis on safety philosophy.
Section V — Safety Management System
The management of safety can be divided into three broad categories: Technical Safety, Process Safety and Occupational Safety (there is a lot of overlap between them). The safety case should outline how each of these topics was addressed.
Technical safety is covered by the Formal Safety Assessment (FSA) described in the next section. Process Safety Management (PSM) is described in detail here. Occupational safety (and the related topic of Behaviour Based Safety) focuses on “trips and falls”. It would not normally be discussed in a safety case.
Section VI — Formal Safety Assessment
Once the facility description is finalized and guidance for allowable risk is provided, a Formal Safety Assessment (FSA) can commence. An FSA requires the identification and evaluation of hazards over the life of the project from the initial feasibility study through the concept design stage, to construction and commissioning, then to operation, decommissioning and abandonment of the facility.
As with everything else to do with safety cases, the content and scope of an FSA will depend on the facility in question and the goals that have been set. What is shown in Table 2 is representative.
- Project HSE Plan
- Safety in Design Philosophy
- Assumptions Register
- Hazards Register
- Hazard Identification
- Layout Hazard Review
- Major Accident Events/Safety Critical Elements
- MAE Register and Bow-Ties
- MAE Fire and Explosion Analysis (including gas and smoke dispersion studies)
- Non-hydrocarbon Analysis
- Emergency escape, evacuation and rescue analysis
- Emergency Systems Survivability Analysis (ESSA)
- Temporary refuge impairment analysis
- Environmental analysis
- Quantitative risk assessment
- Material Handling
- Health Risk Assessment
- Human Factors Engineering Analysis
Section VII — Audit and Review
Auditing a safety case is difficult. The requirement to demonstrate that an organization has successfully identified potential major accident events and assessed and demonstrated that risk has been reduced to as low as is reasonably practicable creates complex problems for drafters and assessors of safety cases.
Risk analysis, while it can employ scientific methodologies, is very much based in the experiences of those involved in undertaking the analysis, and, where qualitative analysis is undertaken, by the data used in the assumptions made about likelihood and consequences of events. Therefore, the high degree of uncertainty inherent in most risk analyses means that the results are most useful for comparing alternate strategies — not for coming up with an unequivocal measure of risk.
Factors that will be considered in the assessor’s reviews include:
- The operator’s incident/accident experience and causal factors, complaints, legislative compliance reviews and the operator’s internal audit results;
- The combined national experience of operators;
- National and international trends and experience;
- General industry experience and developing standards;
- The effectiveness with which the commitments in the safety case are being implemented;
- Monitoring the effectiveness of SMS and operator audits of them;
- The degree to which the work force is involved in implementing the safety case regime.
- Overall, the assessor’s job is to ensure that management systems are in place, that they are effective, and they are being followed. Rather than checking on the details of the safety program, the assessor will evaluate management systems, and their effectiveness.
Inspectors will be required to be involved in both in onsite appraisal of the delivery of improvements and assessing the complex technical arguments put forward for alternative approaches. They must be able to review and evaluate the quality and effectiveness of the safety case without duplicating the work.
Performance MeasurementPerformance standards are the key to an effective safety system. They specify what has to be done, when, by whom and to what extent and ensure that the system is operating as planned in the achievement of objectives through linking roles and responsibilities to actions in a measurable way.
Measurement of performance has traditionally been focused on ‘lag” indicators such as Lost Time Injury Frequency Rates. There are severe limitations in relying on such historical data, and instead is examining the use of ‘lead’ indicators. Lead indicators (such as the number and quality of safety audits conducted, the measurement of management commitment to safety through employee perception studies, and the quality of the facility safety plan), will hopefully provide a real-time measure of the effectiveness of the safety management arrangements. They measure pro-activity, represent management’s commitment to identify potential loss events, and signal the presence of management systems, which can uncover weaknesses before they develop into full-fledged problems.
Section VIII — References
Although a safety case will generally be large and comprehensive, not all the information that it uses can be included. Therefore a list of references is required. These references will generally be of three types:
- Supporting documentation and calculations for detailed items in the safety case such as blast and dispersion analyses.
- External references such as regulations and guidance from government agencies.
- Internal references such as company codes and standards.
When two or more installations have their own safety cases bridging documents help link them. For example, a floating production platform may have a floating drilling rig connected to it. Each facility has its own safety case, so a bridging document is needed to align them. The bridging documents needs to consider problems at the interfaces such as the possibility that the anchors from one platform may interfere with the subsea equipment from the other.
Bridging documents are also used to create facility-specific versions of generic safety cases. For example, it has already been noted that the International Association of Drilling Contractors (IADC) has prepared a safety case template for a wide range of drilling operations (both onshore and offshore). A bridging document can be prepared to match the needs of a particular facility to the general template structure.
The Update Process
The safety case can be updated in one of two ways. First, it can be linked to the facility’s Management of Change (MOC) program. A system can be put in place to review all MOCs on a regular basis. Those that are deemed significant are used to update the safety case.
The second way of updating the safety case is to implement a review cycle process — typically on an annual basis.