MIL-STD-882D
DEPARTMENT OF DEFENSE
STANDARD PRACTICE
SYSTEM SAFETY
FOREWORD
1. This
standard is approved for use by all Departments and Agencies of the
Department of Defense (DoD).
2. The
DoD is committed to protecting personnel from accidental death, injury,
or occupational illness; weapon systems, equipment, material, and facilities
from accidental destruction or damage; and the public from death, injury,
illness, or property damage as a result of executing its mission of
national defense. While meeting mission requirements, the DoD
will also ensure to the maximum extent practicable that the quality
of the environment is protected. The DoD has implemented environmental,
safety, and health efforts to meet these objectives. Integral
to these efforts is the use of a system safety approach to manage the
risk of mishaps associated with DoD operations. A key objective
of the DoD system safety approach is to ensure that mishap risk identification
and mitigation, consistent with mission requirements, are included in
technology development and designed into systems, subsystems, equipment,
facilities, and their interfaces and operation. The DoD goal is
zero mishaps.
3. This
standard addresses an approach (a standard practice normally identified
as system safety) useful in the management of environmental, safety,
and health mishap risks encountered in the development, test, production,
use, and disposal of systems, subsystems, equipment, and facilities.
The approach described herein conforms to the acquisition procedures
in DoD Regulation 5000.2-R and provides a consistent means of evaluating
identified mishap risks. Mishap risk must be identified, evaluated,
and mitigated to a level acceptable (as defined by the system user or
customer) to the appropriate authority, and compliant with federal laws
and regulations, Executive Orders, treaties, and agreements. Program
trade studies associated with mitigating mishap risk must consider total
life cycle cost in any decision. Residual mishap risk associated
with an individual system must be reported to and accepted by appropriate
authority. When MIL-STD-882 is required in a solicitation
or contract and no specific references are included, then only those
requirements presented in paragraph 4 are applicable.
4.
This current revision represents application of the tenets of acquisition
reform to the use of system safety in Government procurement.
A joint Government and industry integrated process team was formed to
oversee the revision. Industry was represented on the integrated
process team by the Government Electronic and Information Technology
Association (GEIA), G-48 committee on system safety. The system
safety tasks associated with previous versions of this standard have
been placed in the Defense Acquisition Deskbook (see 6.8). This
standard is no longer the source for any safety-related data item descriptions
(DIDs).
5. Beneficial
comments (recommendations, additions, deletions) and any pertinent information
that may be of use in improving this document should be addressed to:
HQ Air Force Materiel Command (SES), 4375 Chidlaw Road, Wright-Patterson
AFB, OH 45433-5006, by using the Standardization Document Improvement
Proposal (DD Form 1426) appearing at the end of this document or by
letter or electronic mail.
CONTENTS
PARAGRAPH PAGE
FOREWORD ii
1. SCOPE 1
1.1 Scope 1
2. APPLICABLE DOCUMENTS 1
3. DEFINITIONS 1
3.1 Acronyms used in this standard
1
- Definitions 1
- Acquisition program 1
- Developer 1
- Hazard 1
- Hazardous material 1
- Life cycle 1
- Mishap 2
- Mishap risk 2
- Program manager 2
- Residual mishap
risk 2
- Safety 2
- Subsystem 2
- System 2
- System safety 2
- System safety engineering 2
4. GENERAL REQUIREMENTS 3
- Documentation of
the system safety approach 3
- Identification of
hazards 3
- Assessment of mishap
risk 3
- Identification of
mishap risk mitigation measures 3
- Reduction of mishap
risk to an acceptable level 4
- Verification of
mishap risk reduction 4
- Review of hazards
and acceptance of residual mishap risk by the appropriate
authority 4
- Tracking of hazards
and residual mishap risk 4
- DETAILED REQUIREMENTS 4
6. NOTES 5
- Intended use 5
- Data requirements 5
- Subject term (key
words) listing 5
- Definitions used
in this standard 6
- International standardization
agreements 6
- Explosive hazard
classification and characteristic data 6
- Use of system safety
data in certification and other specialized safety approvals 6
- DoD acquisition
practices 6
- Identification of
changes 6
APPENDIXES
- Guidance for implementation
of system safety efforts 7
CONCLUDING
MATERIAL 24
TABLES
TABLE
PAGE
- Suggested mishap
severity categories 17
- Suggested mishap
probability levels 18
- Example mishap risk
assessment values 19
- Example mishap risk
categories and mishap risk acceptance levels 19
1. SCOPE
1.1 Scope.
This standard defines a standard practice for conducting system safety.
The
practice defined herein conforms to the acquisition procedures in DoD Regulation 5000.2-R
and provides a consistent means of evaluating identified risks.
Mishap risk must be identified, evaluated, and mitigated to a level
acceptable (as defined by the system user or customer) to the appropriate
authority and compliant with federal laws and regulations, Executive
Orders, treaties, and agreements. Program trade studies associated
with mitigating mishap risk must consider total life cycle cost in any
decision. Residual mishap risk associated with an individual system
must be reported to and accepted by appropriate authority. When
MIL-STD-882 is required in a solicitation or contract and no specific
paragraphs of this standard are identified, then only those requirements
presented in paragraph 4 are applicable.
2. APPLICABLE DOCUMENTS
No applicable documents are
specified in sections 3, 4, and 5 of this standard. This section
does not include documents cited in other sections of this standard
or recommended for additional information or as examples.
3. DEFINITIONS
3.1 Acronyms
used in this standard. The acronyms used in this standard are
defined as follows:
a. DoD Department
of Defense
b. ESH Environmental,
Safety, and Health
3.2 Definitions.
Within this document, the following definitions apply (see 6.4):
- Acquisition program.
A directed, funded effort that is designed to provide a new, improved,
or continuing system in response to a validated operational need.
- Developer.
The individual or organization assigned responsibility for a development
effort. Developers can be either internal to the government or
contractors.
- Hazard. Any
real or potential condition that can cause injury, illness, or death
to personnel; damage to or loss of equipment or property; or damage
to the environment.
- Hazardous material.
Any substance that, due to its chemical, physical, or biological nature,
causes safety, public health, or environmental concerns that would require
an elevated level of effort to manage.
- Life cycle.
All phases of the system's life including research, development, test
and evaluation, production, deployment (inventory), operations and support,
and disposal.
- Mishap.
An unplanned event or series of events resulting in death, injury, occupational
illness, damage to or loss of equipment or property, or damage to the
environment.
- Mishap risk.
An expression of the impact and possibility of a mishap in terms of
potential mishap severity and probability of occurrence.
- Program manager.
A government official who is responsible for managing an acquisition
program. Also, a general term of reference to those organizations
directed by individual managers, exercising authority over the planning,
direction, and control of tasks and associated functions essential for
support of designated systems. This term will normally be used
in lieu of system support manager, weapon program manager, system manager,
and project manager when such organizations perform these functions.
- Residual mishap
risk. The remaining mishap risk that exists after all mitigation
techniques have been implemented or exhausted, in accordance with the
system safety design order of precedence (see 4.4).
- Safety.
Freedom from those conditions that can cause death, injury, occupational
illness, damage to or loss of equipment or property, or damage to the
environment.
- Subsystem.
A grouping of items satisfying a logical group of functions within a
particular system.
- System. An
integrated composite of people, products, and processes that provide
a capability to satisfy a stated need or objective.
- System safety.
The application of engineering and management principles, criteria,
and techniques to achieve acceptable mishap risk, within the constraints
of operational effectiveness, time, and cost, throughout all phases
of the system life cycle.
- System safety engineering.
An engineering discipline that employs specialized professional knowledge
and skills in applying scientific and engineering principles, criteria,
and techniques to identify and eliminate hazards, in order to reduce
the associated mishap risk.
4. GENERAL REQUIREMENTS
This section defines the system
safety requirements that are to be performed throughout the life cycle
for any system, new development, upgrade, modification, resolution of
deficiencies, or technology development. When properly applied,
these requirements are designed to ensure the identification and understanding
of all known hazards and their associated risks, and that mishap risk
is eliminated or reduced to accepted levels. The objective of
system safety is to achieve acceptable mishap risk through a systematic
approach of hazard analysis, risk assessment, and risk management.
The requirements of this standard practice shall be applied without
tailoring. When MIL-STD-882 is required in a solicitation or contract
and no specific references are included, then only the requirements
in this section are applicable. System safety requirements consist
of the following:
- Documentation of
the system safety approach. Document the developer's and program
manager's approved system safety engineering approach. This documentation
will:
a.
Describe the program’s implementation of the requirements of this standard,
including identification of the hazard analysis and mishap risk assessment
processes to be used.
b.
Include information on how system safety will be integrated into the
overall program structure.
c.
Define how hazards and residual mishap risk are communicated to and
accepted by the appropriate risk acceptance authority (see 4.7) and
how hazards and residual mishap risk will be tracked (see 4.8).
- Identification of
hazards. Identify hazards through a systematic hazard analysis
process encompassing detailed analysis of system hardware and software,
the environment (in which the system will exist), and the intended usage
or application. Historical hazard and mishap data, including lessons
learned from other systems, are considered and used. Identification
of hazards is a responsibility of all members of the program.
During hazard identification, consideration is given to hazards over
the system life cycle.
- Assessment of mishap
risk. Assess the severity and probability of the mishap risk associated
with each identified hazard, i.e., determine the potential impact of
the hazard on personnel, facilities, equipment, operations, the public,
and the environment, as well as on the system itself.
- Identification of
mishap risk mitigation measures. Identify potential mishap risk
mitigation alternatives and the expected effectiveness of each alternative
or method. Mishap risk mitigation is an iterative process that
culminates when the residual mishap risk has been reduced to a level
acceptable to the appropriate authority. The system safety design
order of precedence for mitigating identified hazards is:
a.
Eliminate hazards through design selection. If an identified hazard
cannot be eliminated, reduce the associated mishap risk to an acceptable
level.
b.
Incorporate safety devices. If the hazard cannot be eliminated,
reduce the mishap risk to an acceptable level through the use of protective
safety features or devices.
c.
Provide warning devices. If safety devices do not adequately lower
the mishap risk of the hazard, include a detection and warning system
to alert personnel to the particular hazard.
d.
Develop procedures and training. Where it is impractical to eliminate
hazards through design selection or to reduce the associated risk to
an acceptable level with safety and warning devices, incorporate special
procedures and training. Procedures may include the use of personal
protective equipment.
4.5 Reduction
of mishap risk to an acceptable level. Reduce the mishap risk
through a mitigation approach mutually agreed to by both the developer
and the program manager. Residual mishap risk and hazards must
be communicated to the associated test effort for verification.
4.6
Verification of mishap risk reduction. Verify the mishap risk
reduction and mitigation through appropriate analysis, testing, or inspection.
Document the determined residual mishap risk. New hazards identified
during testing must be reported to the program manager and the developer.
4.7 Review
of hazards and acceptance of residual mishap risk by the appropriate
authority. Notify the program manager of identified hazards and
residual mishap risk. The program manager must ensure that remaining
hazards and residual mishap risk are reviewed and accepted by the appropriate
risk acceptance authority. The appropriate risk acceptance authority
must include the system user in the mishap risk review. The appropriate
risk acceptance authority must formally acknowledge and document acceptance
of hazards and residual mishap risk.
4.8 Tracking
of hazards and residual mishap risk. Track hazards, their closure,
and residual mishap risk. A tracking system for hazards, their
closure, and residual mishap risk must be maintained throughout the
system life cycle. The program manager must keep the system user
apprised of the hazards and residual mishap risk.
- DETAILED REQUIREMENTS
Program managers must identify
in the solicitation and system specification any specific requirements
for the system safety engineering effort including risk assessment and
acceptance, unique classifications and certifications (see 6.6 and 6.7),
or any unique mishap reduction needs for their program. Additional
information on developing specific requirements for a program is located
in Appendix A.
6. NOTES
(This section contains information
of a general or explanatory nature that may be helpful, but is not mandatory.)
- Intended use.
This standard establishes a common basis for expectations of a properly
executed system safety effort.
- Data requirements.
Hazard analysis data may be obtained from contracted sources by citing
DI-MISC-80508, Technical Report - Study/Services. When it is necessary
to obtain data, the applicable Data Item Descriptions (DIDs) must be
listed on the Contract Data Requirements List (DD Form 1423), except
where the DoD Federal Acquisition Regulation Supplement exempts the
requirement for a DD Form 1423. The developer and the program
manager are encouraged to negotiate access to internal development data
when hard copies are not necessary.
Currently
available DIDs that may be applicable to a system safety effort include
(check DoD 5010.12-L, Acquisition Management Systems and Data Requirements
Control List (AMSDL) or http://www.assist.daps.mil/, for the most current version before
use):
- Subject term (key
word) listing.
- Definitions used
in this standard. The definitions at 3.2 may be different from
those used in other specialty areas. One must carefully check
the specific definition of a term in question for its area of origination
before applying the approach described in this document.
- International standardization
agreements. Certain provisions of this standard are the subject
of international standardization agreements (AIR STD 20/23B, Safety
Design Requirements for Airborne Dispenser Weapons, and STANAG No. 3786,
Safety Design Requirements for Airborne Dispenser Weapons). When
amendment, revision, or cancellation of this standard is proposed which
will modify the international agreement concerned, the preparing activity
will take appropriate action through international standardization channels,
including departmental standardization offices, to change the agreement
or make other appropriate accommodations.
- Explosive hazard
classification and characteristic data. Any new or modified item
of munitions or of an explosive nature that will be transported to or
stored at a DoD installation or facility must first obtain an interim
or final explosive hazard classification. The system safety effort
should provide the data necessary for the program manager to obtain
the necessary classification(s). These data should include identification
of safety hazards involved in handling, shipping, and storage related
to production, use, and disposal of the item.
- Use of system safety
data in certification and other specialized safety approvals.
Hazard analyses are often required for many related certifications and
specialized reviews. Examples of activities requiring data generated
during a system safety effort include: Federal Aviation Agency airworthiness
certification of designs and modifications, DoD airworthiness determination,
nuclear and non-nuclear munitions certification, flight readiness reviews,
flight test safety review board reviews, Nuclear Regulatory Commission
licensing, Department of Energy certification. Special safety-related
approval authorities include USAF Radioisotope Committee, Weapon System
Explosive Safety Review Board (Navy), Non-Nuclear Munitions Safety Board
(USAF), Army Fuze Safety Review Board, Triservice Laser Safety Review
Board, and the DoD Explosive Safety Board.
- DoD acquisition
practices. Information on DoD acquisition practices is presented
in the Defense Acquisition Deskbook available from the Deskbook Joint
Program Office, Wright-Patterson Air Force Base, Ohio, or http://www.deskbook.osd.mil/. Nothing in the referenced information
is considered additive to the requirements provided in this standard.
- Identification of
changes. Marginal notations are not used in this revision to identify
changes with respect to the previous issue due to the extent of the
changes.
APPENDIX A
GUIDANCE FOR
IMPLEMENTATION OF
A SYSTEM SAFETY
EFFORT
A.1 SCOPE
A.1.1
Scope. This appendix provides rationale and guidance to fit the needs
of most system safety efforts. It includes further explanation
of the effort and activities available to meet the requirements described
in paragraph 4 of this standard. This appendix is not a mandatory
part of this standard. However, program managers may extract portions
of this appendix for inclusion in requirements documents and solicitations.
A.2 APPLICABLE DOCUMENTS
A.2.1 General.
The documents listed in this section are referenced in sections A.3,
A.4, and A.5. This section does not include documents cited in
other sections of this appendix or recommended for additional information
or as examples.
A.2.2 Government
documents.
A.2.2.1 Specifications,
standards, and handbooks. This section is not applicable to this
appendix.
A.2.2.2 Other
Government documents, drawings, and publications. The following
other Government document forms a part of this document to the extent
specified herein. Unless otherwise specified, the issue is that
cited in the solicitation.
(Copies
of DoD 5000.2-R are available from the Washington Headquarters Services,
Directives and Records Branch (Directives Section), Washington, DC or http://www.deskbook.osd.mil/).
A.2.3 Non-Government
publications. This section is not applicable to this appendix.
A.2.4 Order
of precedence. Since this appendix is not mandatory, in event
of a conflict between the text of this appendix and the reference cited
herein, the text of the reference takes precedence. Nothing in
this appendix supersedes applicable laws and regulations unless a specific
exemption has been obtained.
A.3 DEFINITIONS
A.3.1
Acronyms used in this appendix. No additional acronyms are used
in this appendix.
A.3.2
Definitions. Additional definitions that apply to this appendix:
- Development agreement.
The formal documentation of the agreed-upon tasks that the developer
will execute for the program manager. For a commercial developer,
this agreement usually is in the form of a written contract.
- Fail safe.
A design feature that ensures the system remains safe, or in the event
of a failure, causes the system to revert to a state that will not cause
a mishap.
- Health hazard assessment.
The application of biomedical knowledge and principles to identify and
eliminate or control health hazards associated with systems in direct
support of the life-cycle management of materiel items.
- Mishap probability.
The aggregate probability of occurrence of the individual events that
might be created by a specific hazard.
- Mishap probability
levels. An arbitrary categorization that provides a qualitative
measure of the most reasonable likelihood of occurrence of a mishap
resulting from personnel error, environmental conditions, design inadequacies,
procedural deficiencies, or system, subsystem, or component failure
or malfunction.
- Mishap risk assessment.
The process of characterizing hazards within risk areas and critical
technical processes, analyzing them for their potential mishap severity
and probabilities of occurrence, and prioritizing them for handling.
- Mishap risk categories.
An arbitrary categorization of mishap risk assessment values often used
to generate specific action such as mandatory reporting of certain hazards
to management for action, or formal acceptance of the associated mishap
risk.
- Mishap severity.
An assessment of the consequences of the most reasonable credible mishap
that could be caused by a specific hazard.
- Mishap severity
category. An arbitrary categorization that provides a qualitative
measure of the most reasonable credible mishap resulting from personnel
error, environmental conditions, design inadequacies, procedural deficiencies,
or system, subsystem, or component failure or malfunction.
- Safety critical.
A term applied to any condition, event, operation, process, or item
whose proper recognition, control, performance, or tolerance is essential
to safe system operation and support (e.g., safety critical function,
safety critical path, or safety critical component).
- System safety management.
All plans and actions taken to identify, assess, mitigate, and continuously
track, control, and document environmental, safety, and health mishap
risks encountered in the development, test, acquisition, use, and disposal
of DoD weapon systems, subsystems, equipment, and facilities.
A.4 GENERAL REQUIREMENTS
A.4.1
General. System safety applies engineering and management principles,
criteria, and techniques to achieve acceptable mishap risk, within the
constraints of operational effectiveness, time, and cost, throughout
all phases of the system life cycle. It draws upon professional
knowledge and specialized skills in the mathematical, physical, and
scientific disciplines, together with the principles and methods of
engineering design and analysis, to specify and evaluate the environmental,
safety, and health mishap risk associated with a system. Experience
indicates that the degree of safety achieved in a system is directly
dependent upon the emphasis given. The program manager and the
developer must apply this emphasis during all phases of the life cycle.
A safe design is a prerequisite for safe operations, with the goal being
to produce an inherently safe product that will have the minimum safety-imposed
operational restrictions.
A.4.1.1
System safety in environmental and health hazard management. DoD 5000.2-R
has directed that environmental, safety, and health hazard management
be integrated into the systems engineering process. While environmental
and health hazard management are normally associated with the application
of statutory direction and requirements, the management of mishap risk
associated with actual environmental and health hazards is directly
addressed by the system safety approach. Therefore, environmental
and health hazards can be analyzed and managed with the same tools as
any other hazard, whether they affect equipment, the environment, or
personnel.
A.4.2 Purpose (see 1.1). All DoD program
managers shall establish and execute programs that manage the probability
and severity of all hazards for their systems (DoD 5000.2-R). Provision
for system safety requirements and effort as defined by this standard
should be included in all applicable contracts negotiated by DoD.
These contracts include those negotiated within each DoD agency, by
one DoD agency for another, and by DoD for other Government agencies.
In addition, each DoD in-house program will address system safety.
This appendix is not intended for reference, use, or implementation
in contractual documents.
A.4.2.1
Solicitations and contracts. The requirements of paragraph 4 shall
be applied to acquisitions without tailoring. MIL-STD-882 should
be incorporated in the list of contractual compliance documents, and
the potential of a developer to execute paragraph 4 requirements should
be included as source selection evaluation criteria. Developers
are encouraged to submit with their proposal a preliminary plan that
describes the system safety effort required for the requested program.
When directed by the program manager, this preliminary plan may be attached
to the contract or referenced in the statement of work; it becomes the
basis for a contractual system safety program.
A.4.3
System safety planning. Prior to formally documenting the system
safety approach, the program manager, in concert with systems engineering
and associated system safety professionals, must determine what system
safety effort is necessary to meet program and regulatory requirements.
This effort will be built around the requirements set forth in paragraph
4 and includes developing a planned approach for safety task accomplishment,
providing qualified people to accomplish the tasks, establishing the
authority for implementing the safety tasks through all levels of management,
and allocating appropriate resources to ensure that the safety tasks
are completed.
A.4.3.1
System safety planning subtasks. System safety planning subtasks
should:
a.
Establish specific safety performance requirements (see A.4.3.2) based
on overall program requirements and system user inputs.
b.
Establish a system safety organization or function and the required
lines of communication with associated organizations (government and
contractor). Establish interfaces between system safety and other
functional elements of the program, as well as with other safety and
engineering disciplines (such as nuclear, range, explosive, chemical,
and biological). Designate the organizational unit responsible
for executing each safety task. Establish the authority for resolution
of identified hazards.
c.
Establish system safety milestones and relate these to major program
milestones, program element responsibility, and required inputs and
outputs.
d.
Establish an incident alerting/notification, investigation, and reporting
process, to include notification of the program manager.
e.
Establish an acceptable level of mishap risk, mishap probability and
severity thresholds, and documentation requirements (including but not
limited to hazards and residual mishap risk).
f.
Establish an approach and methodology for reporting to the program manager
the following information:
(1)
Safety critical characteristics and features.
(2)
Operating, maintenance, and overhaul safety requirements.
(3)
Measures used to eliminate or mitigate hazards.
(4)
Acquisition management of hazardous materials.
g.
Establish the method for the formal acceptance and documenting of residual
mishap risks and the associated hazards.
h.
Establish the method for communicating hazards, the associated risks,
and residual mishap risk to the system user.
i.
Specify requirements for other specialized safety approvals (e.g., nuclear,
range, explosive, chemical, biological, electromagnetic radiation, and
lasers) as necessary (reference 6.6 and 6.7).
A.4.3.2
Safety performance requirements. These are the general safety
requirements needed to meet the core program objectives. The more
closely these requirements relate to a given program, the more easily
the designers can incorporate them into the system. In the appropriate
system specifications, incorporate the safety performance requirements
that are applicable, and the specific risk levels considered acceptable
for the system. Acceptable risk levels can be defined in terms of: a
hazard category developed through a mishap risk assessment matrix; an
overall system mishap rate; demonstration of controls required to preclude
unacceptable conditions; satisfaction of specified standards and regulatory
requirements; or other suitable mishap risk assessment procedures.
Listed below are some examples of how safety performance requirements
could be stated.
a.
Quantitative requirements. Quantitative requirements are usually
expressed as a failure or mishap rate, such as "The catastrophic
system mishap rate shall not exceed x.xx X 10-y
per operational hour."
b.
Mishap risk requirements. Mishap risk requirements could be expressed
as "No hazards assigned a Catastrophic mishap severity are acceptable."
Mishap risk requirements could also be expressed as a level defined
by a mishap risk assessment (see A.4.4.3.2.3), such as "No Category
3 or higher mishap risks are acceptable."
c.
Standardization requirements. Standardization requirements are
expressed relative to a known standard that is relevant to the system
being developed. Examples include: "The system will comply
with the laws of the State of XXXXX and be operable on the highways
of the State of XXXXX" or "The system will be designed to
meet ANSI Std XXX as a minimum."
A.4.3.3
Safety design requirements. The program manager, in concert with
the chief engineer and utilizing systems engineering and associated
system safety professionals, should establish specific safety design
requirements for the overall system. The objective of safety design
requirements is to achieve acceptable mishap risk through a systematic
application of design guidance from standards, specifications, regulations,
design handbooks, safety design checklists, and other sources.
These are reviewed for safety design parameters and acceptance criteria
applicable to the system. Safety design requirements derived from
the selected parameters, as well as any associated acceptance criteria,
are included in the system specification. These requirements and
criteria are expanded for inclusion in the associated follow-on or lower
level specifications. Some general safety system design requirements
are listed below.
a.
Hazardous material use is minimized, eliminated, or associated mishap
risks are reduced through design, including material selection or substitution.
When potentially hazardous materials must be used, the materials that
pose the least risk throughout the life cycle of the system are selected.
b.
Hazardous substances, components, and operations are isolated from other
activities, areas, personnel, and incompatible materials.
c.
Equipment is located so that access during operations, servicing, repair,
or adjustment minimizes personnel exposure to hazards (e.g., hazardous
substances, high voltage, electromagnetic radiation, and cutting and
puncturing surfaces).
d.
Power sources, controls, and critical components of redundant subsystems
are protected by physical separation or shielding, or by other acceptable
methods.
f.
Safety devices that will minimize mishap risk (e.g., interlocks, redundancy,
fail safe design, system protection, fire suppression, and protective
measures such as clothing, equipment, devices, and procedures) are considered
for hazards that cannot be eliminated. Provisions are made for
periodic functional checks of safety devices when applicable.
g.
System disposal (including explosive ordnance disposal) and demilitarization
are considered in the design.
h.
Warning signals are implemented so as to minimize the probability of
incorrect personnel reaction to the signals, and should be standardized
within like types of systems.
i.
Warning and cautionary notes are provided in assembly, operation, and
maintenance instructions, and distinctive markings are provided on hazardous
components, equipment, and facilities to ensure personnel and equipment
protection when no alternate design approach can eliminate a hazard.
Use standard warning and cautionary notations where multiple applications
occur. Standardize notations in accordance with commonly accepted
commercial practice or, if none exists, normal military procedures.
Do not use warning, caution, or other written advisory as the only risk
reduction method for hazards assigned Catastrophic or Critical mishap
severities.
j.
Safety critical tasks may require personnel proficiency; if so, the
developer should propose a proficiency certification process to be used.
k.
Severity of injury or damage to equipment or the environment as a result
of a mishap is minimized.
l.
Inadequate or overly restrictive requirements regarding safety are not
included in the system specification.
m.
Acceptable risk is achieved in implementing new technology, materials,
or designs in an item’s production, test, and operation. Changes
to design, configuration, production, or mission requirements (including
any resulting system modifications and upgrades, retrofits, insertions
of new technologies or materials, or use of new production or test techniques)
are accomplished in a manner that maintains an acceptable level of mishap
risk. Changes to the environment in which the system operates
are analyzed to identify and mitigate any resulting hazards or changes
in mishap risks.
A.4.3.3.1
Some program managers include the following conditions in their solicitation,
system specification, or contract as requirements for the system design.
These condition statements are used optionally as supplemental requirements
based on specific program needs.
A.4.3.3.1.1
Unacceptable conditions. The following safety critical conditions
are considered unacceptable for development efforts. Positive
action and verified implementation is required to reduce the mishap
risk associated with these situations to a level acceptable to the program
manager.
a.
Single component failure, common mode failure, human error, or a design
feature that could cause a mishap of Catastrophic or Critical severity.
b.
Dual independent component failures, dual independent human errors,
or a combination of a component failure and a human error involving
safety critical command and control functions, which could cause a mishap
of Catastrophic or Critical severity.
c.
Generation of hazardous radiation or energy, when no provisions have
been made to protect personnel or sensitive subsystems from damage or
adverse effects.
d.
Packaging or handling procedures and characteristics that could cause
a mishap for which no controls have been provided to protect personnel
or sensitive equipment.
e.
Hazard categories that are specified as unacceptable in the development
agreement.
A.4.3.3.1.2
Acceptable conditions. The following approaches are considered
acceptable for correcting unacceptable conditions and will require no
further analysis once mitigating actions are implemented and verified.
a.
For non-safety critical command and control functions: a system design
that requires two or more independent human errors, or that requires
two or more independent failures, or a combination of independent failure
and human error.
b.
For safety critical command and control functions: a system design that
requires at least three independent failures, or three independent human
errors, or a combination of three independent failures and human errors.
c.
System designs that positively prevent errors in assembly, installation,
or connections that could result in a mishap.
d.
System designs that positively prevent damage propagation from one component
to another or prevent sufficient energy propagation to cause a mishap.
e.
System design limitations on operation, interaction, or sequencing that
preclude occurrence of a mishap.
f.
System designs that provide an approved safety factor, or a fixed design
allowance that limits, to an acceptable level, possibilities of structural
failure or release of energy sufficient to cause a mishap.
g.
System designs that control energy build-up that could potentially cause
a mishap (e.g., fuses, relief valves, or electrical explosion proofing).
h.
System designs where component failure can be temporarily tolerated
because of residual strength or alternate operating paths, so that operations
can continue with a reduced but acceptable safety margin.
i.
System designs that positively alert the controlling personnel to a
hazardous situation where the capability for operator reaction has been
provided.
j.
System designs that limit or control the use of hazardous materials.
A.4.3.4
Elements of an effective system safety effort. Elements of an
effective system safety effort include:
a.
Management is always aware, and formally documents this awareness, of
the mishap risks associated with the system. Hazards associated
with the system are identified, assessed, tracked, monitored, and the
associated risks are either eliminated or controlled to an acceptable
level throughout the life cycle. Actions taken to eliminate or
reduce mishap risk to an acceptable level are identified and archived
for tracking and lessons learned purposes.
b.
Historical hazard and mishap data, including lessons learned from other
systems, are considered and used.
c.
Environmental protection, safety, and occupational health, consistent
with mission requirements, are designed into the system in a timely,
cost-effective manner. Inclusion of the appropriate safety features
is accomplished during the applicable phases of the system life cycle.
d.
Mishap risk resulting from harmful environmental conditions (e.g., temperature,
pressure, noise, toxicity, acceleration, and vibration) and human error
in system operation and support is minimized.
e.
System users are kept abreast of the safety of the system and included
in the safety decision process.
A.4.4
System safety engineering effort. As stated in paragraph 4, a
system safety engineering effort consists of eight main requirements.
The following paragraphs provide further descriptions on what efforts
are typically expected due to each of the system safety requirements
listed in paragraph 4.
A.4.4.1
Documentation of the system safety approach. The documentation
of the system safety approach should describe the planned tasks and
activities of system safety management and system engineering required
to identify, evaluate, and eliminate or control hazards, or to reduce
the residual mishap risk to a level acceptable throughout the system
life cycle. The documentation should describe, as a minimum, the
four elements of an effective system safety effort: a planned
approach for task accomplishment, qualified people to accomplish tasks,
the authority to implement tasks through all levels of management, and
the appropriate commitment of resources (both manning and funding) to
ensure that safety tasks are completed. Specifically, the provided
documentation should:
a.
Describe the scope of the overall system program and the related system
safety effort. Define system safety program milestones.
Relate these to major program milestones, program element responsibility,
and required inputs and outputs.
b.
Describe the safety tasks and activities of system safety management
and engineering. Describe the interrelationships between system
safety and other functional elements of the program. List the
other program requirements and tasks applicable to system safety and
reference where they are specified or described. Include the organizational
relationships between other functional elements having responsibility
for tasks with system safety impacts and the system safety management
and engineering organization including the review and approval authority
of those tasks.
c. Describe specific analysis techniques and formats to be used
in qualitative or quantitative assessments of hazards, their causes,
and effects.
d. Describe the process through which management decisions will
be made (for example, timely notification of unacceptable risks, necessary
action, incidents or malfunctions, waivers to safety requirements, and
program deviations). Include a description on how residual mishap
risk is formally accepted and this acceptance is documented.
e. Describe the mishap risk assessment procedures, including the
mishap severity categories, mishap probability levels, and the system
safety design order of precedence that should be followed to satisfy
the safety requirements of the program. State any qualitative
or quantitative measures of safety to be used for mishap risk assessment
including a description of the acceptable and unacceptable risk levels
(if applicable). Include system safety definitions that modify,
deviate from, or are in addition to those in this standard or generally
accepted by the system safety community (see Defense Acquisition Deskbook
and System Safety Society’s System Safety Analysis Handbook) (see A.6.1).
f.
Describe how resolution and action relative to system safety will be
implemented at the program management level possessing resolution authority.
g.
Describe the verification (e.g., test, analysis, demonstration, or inspection)
requirements for ensuring that safety is adequately attained.
Identify any certification requirements for software, safety devices,
or other special safety features (e.g., render safe and emergency disposal
procedures).
h.
Describe the mishap or incident notification, investigation, and reporting
process for the program, including notification of the program manager.
i.
Describe the approach for collecting and processing pertinent historical
hazard, mishap, and safety lessons learned data. Include a description
on how a system hazard log is developed and kept current (see A.4.4.8.1).
j.
Describe how the user is kept abreast of residual mishap risk and the
associated hazards.
A.4.4.2
Identification of hazards. Identify hazards through a systematic
hazard analysis process encompassing detailed analysis of system hardware
and software, the environment (in which the system will exist), and
the intended usage or application. Historical hazard and mishap
data, including lessons learned from other systems, are considered and
used.
A.4.4.2.1
Approaches for identifying hazards. Numerous approaches have been
developed and used to identify system hazards. A key aspect of
many of these approaches is empowering the design engineer with the
authority to design safe systems and the responsibility to identify
to program management the hazards associated with the design.
Hazard identification approaches often include using system users in
the effort. Commonly used approaches for identifying hazards can
be found in the Defense Acquisition Deskbook and System Safety Society’s
System Safety Analysis Handbook (see A.6.1)
A.4.4.3
Assessment of mishap risk. Assess the severity and probability
of the mishap risk associated with each identified hazard, i.e., determine
the potential impact of the hazard on personnel, facilities, equipment,
operations, the public, or environment, as well as on the system itself.
A.4.4.3.1
Mishap risk assessment models. To determine what actions to take
to eliminate or control identified hazards, a system of determining
the level of mishap risk involved must be developed. A good mishap
risk assessment model will enable decision makers to properly understand
the level of mishap risk involved, relative to what it will cost in
schedule and dollars to reduce that mishap risk to an acceptable level.
A.4.4.3.2
Model development. Key to most mishap risk assessment models is
the characterization of mishap risks as to mishap severity and mishap
probability. Since the highest system safety design order of precedence
is to eliminate hazards by design, a mishap risk assessment procedure
considering only mishap severity will generally suffice during the early
design phase to minimize the system’s mishap risks (for example, just
don’t use hazardous or toxic material in the design). When all
hazards cannot be eliminated during the early design phase, a mishap
risk assessment procedure based upon the mishap probability as well
as the mishap severity provides a resultant mishap risk assessment.
The assessment is used to establish priorities for corrective action,
resolution of identified hazards, and notification to management of
the mishap risks. The information provided here is a suggested
model and set of definitions that can be used. Program managers
are allowed to develop models and definitions appropriate to their individual
programs.
A.4.4.3.2.1
Mishap severity. Mishap severity categories are defined to provide
a qualitative measure of the most reasonable credible mishap resulting
from personnel error, environmental conditions, design inadequacies,
procedural deficiencies, or system, subsystem, or component failure
or malfunction. Suggested mishap severity categories are shown
in Table A-I.
TABLE A-I.
Suggested mishap severity categories.
Description |
Category |
Environmental,
Safety, and Health Result Criteria
|
Catastrophic |
I |
Could result
in death, permanent total disability, loss exceeding $1M, or irreversible
severe environmental damage that violates law or regulation. |
Critical |
II |
Could result
in permanent partial disability, injuries or occupational illness that
may result in hospitalization of at least three personnel, loss exceeding
$200K but less than $1M, or reversible environmental damage causing
a violation of law or regulation. |
Marginal |
III |
Could result
in injury or occupational illness resulting in one or more lost work
days(s), loss exceeding $10K but less than $200K, or mitigatible environmental
damage without violation of law or regulation where restoration activities
can be accomplished. |
Negligible |
IV |
Could result
in injury or illness not resulting in a lost work day, loss exceeding
$2K but less than $10K, or minimal environmental damage not violating
law or regulation. |
|
NOTE: These mishap severity
categories provide guidance to a wide variety of programs. However,
adaptation to a particular program is generally required to provide
a mutual understanding between the program manager and the developer
as to the meaning of the terms used in the category definitions.
Other risk assessment techniques may be used provided that the user
approves them.
A.4.4.3.2.2
Mishap probability. Mishap probability is the probability that
a mishap will occur during the planned life expectancy of the system.
It can be described in terms of potential occurrences per unit of time,
events, population, items, or activity. Assigning a quantitative
mishap probability to a potential design or procedural hazard is generally
not possible early in the design process. At that stage, a qualitative
mishap probability may be derived from research, analysis, and evaluation
of historical safety data from similar systems. Supporting rationale
for assigning a mishap probability is documented in hazard analysis
reports. Suggested qualitative mishap probability levels are shown
in Table A-II.
TABLE A-II.
Suggested mishap probability levels.
|
|
|
|
|
|
|
|
Likely to occur often in
the life of an item, with a probability of occurrence greater than 10-1
in that life.
|
|
|
|
|
Will occur several times
in the life of an item, with a probability of occurrence less than 10-1
but greater than 10-2 in that life.
|
|
|
|
|
Likely to occur some time
in the life of an item, with a probability of occurrence less than 10-2
but greater than 10-3 in that life.
|
|
|
|
|
Unlikely but possible to
occur in the life of an item, with a probability of occurrence less
than 10-3 but greater than 10-6 in that life.
|
Unlikely, but can reasonably
be expected to occur.
|
|
|
|
So unlikely, it can be
assumed occurrence may not be experienced, with a probability of occurrence
less than 10-6 in that life.
|
Unlikely to occur, but
possible.
|
|
|
*Definitions of
descriptive words may have to be modified based on quantity of items
involved.
**The expected size of the
fleet or inventory should be defined prior to accomplishing an assessment
of the system.
A.4.4.3.2.3
Mishap risk assessment. Mishap risk characterization as to mishap
severity and mishap probability can be performed through the use of
the mishap risk assessment matrix. This assessment allows one
to assign a mishap risk assessment value to a hazard based on its mishap
severity and its mishap probability. This value is then often
used to rank different hazards as to their associated mishap risks.
An example of a mishap risk assessment matrix is shown at Table A-III.
TABLE A-III.
Example mishap risk assessment values.
SEVERITY
PROBABILITY |
Catastrophic |
Critical |
Marginal |
Negligible
|
Frequent |
1 |
3 |
7 |
13 |
Probable |
2 |
5 |
9 |
16 |
Occasional |
4 |
6 |
11 |
18 |
Remote |
8 |
10 |
14 |
19 |
Improbable |
12 |
15 |
17 |
20 |
|
A.4.4.3.2.4
Mishap risk categories. Mishap risk assessment values are often
used in grouping individual hazards into mishap risk categories.
Mishap risk categories are then used to generate specific action such
as mandatory reporting of certain hazards to management for action or
formal acceptance of the associated mishap risk. Table A-IV includes
an example listing of mishap risk categories and the associated assessment
values. In the example, the system management has determined that
mishap risk assessment values 1 through 5 constitute “High” risk while
values 6 through 9 constitute “Serious” risk.
TABLE A-IV.
Example mishap risk categories and mishap risk acceptance levels.
Mishap
Risk Assessment Value |
Mishap
Risk Category
|
Mishap
Risk Acceptance
Level |
1
– 5 |
High |
Component
Acquisition Executive |
6
– 9 |
Serious |
Program
Executive Officer |
10
– 17 |
Medium |
Program
Manager |
18
– 20 |
Low |
As directed |
|
*Representative
mishap risk acceptance levels are shown in the above table. Mishap
risk acceptance is discussed in paragraph A.4.4.7
A.4.4.3.2.5
Mishap risk impact. The mishap risk impact is assessed, as necessary,
using other factors to discriminate between hazards having the same
mishap risk value. One might discriminate between hazards with
the same mishap risk assessment value in terms of mission capabilities,
or social, economic, and political factors. This would be a program
management decision used to prioritize resulting actions.
A.4.4.3.3
Mishap risk assessment approaches. Commonly used approaches for
assessing mishap risk can be found in the Defense Acquisition Deskbook
and System Safety Society’s System Safety Analysis Handbook (see A.6.1)
A.4.4.4
Identification of mishap risk mitigation measures. Identify potential
mishap risk mitigation alternatives and the expected effectiveness of
each alternative or method. Mishap risk mitigation is an iterative
process that culminates when the residual mishap risk has been reduced
to a level acceptable to the appropriate authority.
A.4.4.4.1
Prioritize hazards for corrective action. To eliminate or otherwise
control as many hazards as possible, prioritize hazards for corrective
action. A categorization of hazards may be conducted according
to the mishap risk potential they present.
A.4.4.4.2
System safety design order of precedence (see 4.4). The ultimate
goal of a system safety program is to design systems that contain no
hazards. However, since the nature of most complex systems makes
it impossible or impractical to design them completely hazard-free,
a successful system safety program often provides a system design where
there exist no hazards resulting in an unacceptable level of mishap
risk. As hazard analyses are performed, hazards will be identified
that will require resolution. The system safety design order of
precedence defines the order to be followed for satisfying system safety
requirements and reducing risks. The alternatives for eliminating
the specific hazard or controlling its associated risk are evaluated
so that an acceptable method for mishap risk reduction can be agreed
to.
A.4.4.5
Reduction of mishap risk to an acceptable level. Reduce the system
mishap risk through a mitigation approach mutually agreed to by both
the developer and the program manager.
A.4.4.5.1
Communication with associated test efforts. Residual mishap risk
and associated hazards must be communicated to the system test efforts
for verification.
A.4.4.6
Verification of mishap risk reduction. Verify the mishap risk
reduction and mitigation through appropriate analysis, testing, or inspection.
Document the determined residual mishap risk. The program manager
must ensure that the selected mitigation approaches will result in the
expected residual mishap risk. To provide this assurance, the
system test effort should verify the performance of the mitigation actions.
New hazards identified during testing must be reported to the program
manager and the developer.
A.4.4.6.1
Testing for a safe design. Tests and demonstrations must be defined
to validate selected safety features of the system. Tests or demonstrations
must be performed on safety critical equipment and procedures to determine
the mishap severity or to establish the margin of safety of the design.
Induced or simulated failures will be considered to demonstrate the
failure mode and acceptability of safety critical equipment. Where
hazards are identified during the development effort and it cannot be
analytically determined whether the action taken will adequately control
the hazard, safety tests must be conducted to evaluate the effectiveness
of the controls. Where costs for safety testing would be prohibitive,
safety characteristics or procedures may be verified by engineering
analyses, analogy, laboratory test, functional mockups, or subscale/model
simulation. Tests of safety systems should be integrated into
appropriate system test and demonstration plans to the maximum extent
possible.
A.4.4.6.2
Conducting safe testing. The program manager must ensure that
test teams are familiar with mishap risks of the system. Test
plans, procedures, and test results for all tests including design verification,
operational evaluation, production acceptance, and shelf-life validation
should be reviewed to ensure that:
a.
Safety is adequately demonstrated.
b.
The testing will be conducted in a safe manner.
c.
All additional hazards introduced by testing procedures, instrumentation,
test hardware, and test environment are properly identified and controlled.
A.4.4.6.3
Communication of new hazards identified during testing. Testing
organizations must ensure that hazards and safety discrepancies discovered
during testing are communicated to the program manager and the developer.
A.4.4.7
Review and acceptance of residual mishap risk by the appropriate authority.
Notify the program manager of identified hazards and residual mishap
risk.
A.4.4.7.1
Residual mishap risk. The mishap risk that remains after all planned
mishap risk management measures have been implemented is considered
residual mishap risk. Residual mishap risk is documented along
with the reason(s) for incomplete mitigation.
A.4.4.7.2
Residual mishap risk management. The program manager must know
what residual mishap risk exists in the system being acquired.
For significant mishap risks, the program manager is required to elevate
reporting of residual mishap risk to higher levels of appropriate authority
(such as the Program Executive Officer or Component Acquisition Executive)
for action or acceptance. The program manager is encouraged to
apply additional resources or other remedies to help the developer satisfactorily
resolve hazards providing significant mishap risk. Table A-IV
includes an example of a mishap risk acceptance level matrix based on
the mishap risk assessment value and mishap risk category.
A.4.4.7.3
Residual mishap risk acceptance. The program manager is responsible
for formally documenting the acceptance of the residual mishap risk
of the system by the appropriate authority. The program manager
should update this residual mishap risk and the associated hazards to
reflect changes in the system or its use. The program manager
should keep the system users apprised of the residual mishap risk of
the system and the associated hazards.
A.4.4.8
Tracking hazards and residual mishap risk. Track hazards, their
closures, and residual mishap risk. A tracking system for hazards,
their closures, and residual mishap risk must be maintained throughout
the system life cycle. The program manager must keep the system
user apprised of system hazards and residual mishap risk.
A.4.4.8.1
Process for tracking of hazards and residual mishap risk. Each
system must have a current log of identified hazards and residual mishap
risk, including an assessment of the residual mishap risk (see A.4.4.7).
As changes are integrated into the system, this log is updated to incorporate
added or changed hazards and the associated residual mishap risk.
The Government must formally acknowledge acceptance of system hazards
and residual mishap risk. Users will be kept informed of hazards
and residual mishap risk associated with their systems.
A.4.4.8.1.1
Developer responsibilities for communications, acceptance, and tracking
of hazards and residual mishap risk. The developer (see 3.2.2)
is responsible for communicating information to the program manager
on system hazards and residual mishap risk, including any unusual consequences
and costs associated with hazard mitigation. After attempting
to eliminate or mitigate system hazards, the developer will formally
document and notify the program manager of all hazards breaching thresholds
set in the safety design criteria. At the same time, the developer
will also communicate the system residual mishap risk.
A.4.4.8.1.2
Program manager responsibilities for communications, acceptance, and
tracking of hazards and residual mishap risk. The program manager
is responsible for maintaining a log of all identified hazards and residual
mishap risk for the system. The program manager will communicate
known hazards and associated risks of the system to all system developers
and users. As changes are integrated into the system, the program
manager shall update this log to incorporate added or changed hazards
and the residual mishap risk identified by the developer. The
program manager is also responsible for informing system developers
about the program manager’s expectations for handling of newly discovered
hazards. The program manager will evaluate new hazards and the
resulting residual mishap risk, and either recommend further action
to mitigate the hazards, or formally document the acceptance of these
hazards and residual mishap risk. The program manager will evaluate
the hazards and associated residual mishap risk in the context of the
user requirements, potential mission capability, and the operational
environment. Copies of the documentation of the hazard and risk
acceptance will be provided to both the developer and the system user.
Hazards for which the program manager accepts responsibility for mitigation
will also be included in the formal documentation. For example,
if the program manager decides to execute a special training program
to mitigate a potentially hazardous situation, this approach will be
documented in the formal response to the developer. Residual mishap
risk and hazards must be communicated to system test efforts for verification.
A.5 SPECIFIC REQUIREMENTS
A.5.1
Program manager responsibilities. The program manager should:
A.5.1.1
Assure that all types of hazards are identified, evaluated, and mitigated
to a level compliant with acquisition management policy, federal laws
and regulations, Executive Orders, treaties, and agreements.
A.5.1.2
Establish, plan, organize, implement, and maintain an effective system
safety effort that is integrated into all life cycle phases.
A.5.1.3
Ensure that system safety planning is documented to provide all program
participants with visibility into how the system safety effort is to
be conducted.
A.5.1.4
Establish definitive safety requirements for the procurement, development,
and sustainment of the system. The requirements should be set
forth clearly in the appropriate system specifications and contractual
documents.
A.5.1.5
Provide historical safety data to developers.
A.5.1.6
Monitor the developer’s system safety activities and review and approve
delivered data in a timely manner, if applicable, to ensure adequate
performance and compliance with safety requirements.
A.5.1.7
Ensure that the appropriate system specifications are updated to reflect
results of analyses, tests, and evaluations.
A.5.1.8
Evaluate new lessons learned for inclusion into appropriate databases
and submit recommendations to the responsible organization.
A.5.1.9
Establish system safety teams to assist the program manager in developing
and implementing a system safety effort.
A.5.1.10
Provide technical data on Government-furnished Equipment or Government-furnished
Property to enable the developer to accomplish the defined tasks.
A.5.1.11
Document acceptance of residual mishap risk and associated hazards.
A.5.1.12
Keep the system users apprised of system hazards and residual mishap
risk.
A.6 NOTES
A.6.1
DoD acquisition practices and safety analysis techniques. Information
on DoD acquisition practices and safety analysis techniques is available
at the referenced Internet sites. Nothing in the referenced information
is considered binding or additive to the requirements provided in this
standard.
A.6.1.1
Defense Acquisition Deskbook. Wright-Patterson Air Force Base,
Ohio: Deskbook Joint Program Office. http://www.deskbook.osd.mil/.
A.6.1.2
System Safety Analysis Handbook. Unionville, VA: System Safety
Society. http://www.system-safety.org.
CONCLUDING MATERIAL
Custodians: Preparing activity:
Army
- AV Air Force - 40
Navy
- AS
Reviewing activities:
Army
- AR, AT, CR, MI
Navy
- EC, OS, SA, SH
Air
Force - 10, 11, 13, 19
Source: DoD
|
Copyright © 2000-2006 Geigle Communications. All rights reserved. Federal copyright law prohibits unauthorized reproduction by any means and imposes fines up to $25,000 for violations.
|
|