|
The term COTS, or Commercial-Off-The-Shelf, applies to equipment, components or items that are developed separately from the program on which they are to be used. The generic term COTS and discussion herein also apply equally to Non-Developmental Items (NDI), Government-Off-The-Shelf (GOTS) items, Military-Off-The-Shelf (MOTS) items and Government Furnished Equipment (GFE). Reused software is also considered as COTS in a system acquisition program.
Items that are available from existing inventory are considered COTS equipment. They are generally commercially developed and require no unique modifications or maintenance over the lifecycle of the product to meet the needs of the system. COTS items are purchased by the program for as-is use in the system, as opposed to being designed and developed as part of the acquisition program. In some cases, they are modified for use in the system. In other cases, they cannot be modified. An example of COTS hardware would be the use of existing electronic power supplies that can be purchased from a catalog, and an example of COTS software would be the use of an existing operating system that can be purchased for computer systems.
The intent behind COTS is an admirable one — to save development time and cost, programmatic risk and supportability costs by using existing equipment. However, the procurement of a COTS item — along with its operational support and maintenance — poses potential significant safety problems for a program. These problems usually result from the fact that most COTS items generally have an unknown pedigree (or history). An item may not have been built to a set of commercial standards, may fail to satisfy program safety requirements, or may lack the data necessary to verify safe system implementation. Also, since the COTS item already exists, the program usually cannot change the design without greatly increasing the cost or impacting the schedule. There may not be enough data available on such an item for the safety engineer to fully understand it. The program often has little or no control in affecting changes to enhance the item's level of safety rigor. Therefore, the standard System Safety Program is often unable to address the COTS portion of the total system with the same degree of safety rigor that was applied to the rest of the system. A special COTS safety approach must be applied during the system acquisition and development process in order to ensure safe overall design with COTS hardware and software in the system.
An example of COTS hardware use with potential safety implications would be the direct application of an existing Porsche steer-by-wire system to a new Ford Explorer SUV auto development. An example of COTS software reuse with potential safety implications would be the employment of an existing 747 flight-control software package on a new 787 aircraft. In each case, the COTS item may work, but the systems have safety-critical implications, and safety blowback must be considered.
Some of the unique inherent characteristics of COTS are summarized in the following list of advantages and disadvantages of COTS usage:
COTS Advantages:
- Cost savings (no development costs)
- Schedule/programmatic risk reduction
- Rapid insertion of new technology
- Proven product/process (technology risk reduction)
- Possible broad user base
- Possible technical support
- Possible logistics support
COTS Disadvantages:
- Unknown development history or pedigree (standards, quality assurance, test, analysis, failure history, etc.)
- Unavailable design and test data (drawings, test results, etc.)
- Unavailable or inapplicable safety analyses
- Proprietary design (prohibits sharing of information)
- Unable to modify (contractual, proprietary)
- Out of current production, but overstocked in inventory
- May not be supported (configuration control, technical support, updates, etc.)
- Unknown limitations (operational, environmental, stress, etc.)
- Unnecessary capabilities and/or functionality
- Unknown part-obsolescence factor
- May require increased test and analysis for safety verification
- Newer versions may be revised by vendor without notice
- May require special design factors to trap and work around potential problems
The advantages and disadvantages of a COTS item should be carefully weighed against the program requirements before determining its usage — against safety requirements in particular — and it must be evaluated for safety as an integral part of the entire system. The decision to use COTS does not eliminate or reduce the necessity to meet all existing safety requirements for the system.
Most of the safety concerns and problems associated with COTS are a result of the unique characteristics of the particular item involved, and its impact on the new system design and operating environment. COTS data, or specifically the lack of it, is the prime contributor to safety problems and concerns. Similarly, the lack of design, test and qualification information and knowledge makes the safety assessment process more difficult.
There are many aspects to COTS safety, but in general, the safety issues revolve around several key concerns. As these particular concerns are answered, the steps to be taken in a COTS safety program will naturally evolve. The key concerns include:
- Does the COTS item have any inherent hazards?
- Is the item part of a safety-critical function?
- Does it meet all system development requirements involving safety?
- Can the COTS item contribute to any system hazards when integrated into the system?
- Can it be changed or modified without notice or safety review?
- Does the COTS item contain unneeded functionality?
- Can it present new hazards within the system design?
In an ideal acquisition development program, COTS items would not be included where safety is an issue. The problem is that program management usually sees COTS items as shoo-ins that don't require safety substantiation because the promised cost savings are so great. However, the safety effort required may significantly diminish the promised cost savings.
A special COTS safety program is recommended whenever COTS items are used in the acquisition process. This safety program should be centered on the following basic considerations:
- Establish program safety precepts for COTS items
- Incorporate these items into the System Safety Program Plan and the System Safety Program
- Assess the potential mishap risk of such items in the system design
- Incorporate COTS items into the system Preliminary Hazard Analysis (PHA), Subsystem Hazard Analysis (SSHA) and System Hazard Analysis (SHA)
- Classify the COTS item as Safety Critical (SC), Safety Related (SR) or Non-Safety Related (NSR)
- Ensure that these items meet or support all design system safety requirements (SSRs)
- Determine if, and how much, special testing is necessary to verify COTS safety
- Build a Safety Analysis Report (SAR) or safety case for the COTS item to prove and verify its safe use in the system design
- Maintain a higher level of safety rigor for COTS in a safety-critical function
- Design and build a special safety fence or wall around the COTS item when necessary to ensure a desired level of mishap risk
Note that these are generic steps for developing a safety case for a COTS item. Tasks may vary for different COTS items, depending on the amount of data and information that are available to support the safety case and the level of safety criticality involved.
Each COTS item has a unique development history that must be thoroughly evaluated to determine its effect on the safety of the new system. COTS items are generally built to commercial standards, but the particular standards followed can vary or be unknown. Information on all of the standards that were used in the development and manufacture of the COTS item is relevant for system integration. System requirements (environmental, operational, performance and reliability) may exceed those under which the COTS item was initially developed. Knowing what qualification tests were performed is also essential to determining the safety of the overall system. Operational capability of the item is a factor that must be known. It may provide more capability than desired or less capability than required. The system developer must know and include the effects of integrating the COTS item into the system when it has a different set of capabilities than required.
A key safety aspect of a COTS item is whether it is used in a safety-critical system function. If it is part of such a function, then it becomes a key system player, and all of its design, operation and test attributes must be known and evaluated. If it is part of a safety-related function, then its safety sensitivity is a little lower (than with a safety-critical function). If a COTS item is part of a non-safety-related function, then there will likely be very little safety concern about the item; however, this does not waive the need for COTS safety analysis. If the item is used in a safety-critical function, a considerable amount of design and test data on the item is required to assist the system safety engineer in assessing COTS mishap risk potential. The environment for which the COTS item was originally designed must be known, in order to determine whether it can meet the new system operational environment.
In summary, remember that the use of COTS does not absolve the acquisition program from meeting safety requirements or conducting a safety program on a COTS item. In fact, the use of COTS demands that extra safety effort be applied. The amount of detailed safety analysis and testing of the COTS item is based on its functional safety criticality rating. For safety-critical items, more stringent testing and analysis are necessary to provide confidence in the safety of the system with the COTS item integrated into it.
Parting question: Should the human operator be considered as COTS in a system design?
Please send me your comments on these thoughts.
Regards,
Clif
Copyright © 2006 by Clifton A. Ericson II. All rights reserved. |
