Configuration management is one of the supporting processes of the hardware design life cycle. Configuration management starts during the planning phase, continues through the on-going production of the hardware, and into the long-term archive of life cycle data long after the hardware has ceased production. As with other aspects of design assurance, configuration management starts from the Federal Aviation Regulations: FAR 14 CFR 25.1301 states that installed equipment must be labeled as to its identification. For the purposes of configuration management, the identification of the hardware needs to be unique, that is each system should have a unique part number. FAR 14 CFR 21.31,1 21.41,2 and 21.493 lead to the long-term archival of life cycle data, as will be discussed further below.
The configuration management processes allow hardware manufacturers to make consistent copies of hardware items. This could be the manufacture of a line replaceable unit from parts lists and assembly drawings, fabrication of a particular revision of a printed circuit card, applying the programming file to an FPGA, or regenerating the programming file for an FPGA from the source hardware description language (HDL) files and yielding the same programming file checksum.
The configuration management processes also allow hardware developers to make orderly and controlled changes to hardware and hardware life cycle data. This could include modification or deletion of requirements or functions, resolving problems in hardware or hardware life cycle data, or updating versions of hardware installed on a circuit card.
Appendix C of DO-254 has a two-part definition of configuration management. The first part defines configuration management as dealing with configuration identification and the application of changes to items and their identities. The second part defines configuration management as a discipline for identifying and recording functional and physical characteristics of an item, controlling changes made to such characteristics, and reporting the status and implementation of change control. So in this two-part definition, the second part describes how to accomplish the first part.
The definition of configuration management in the introductory paragraph of Section 7 of DO-254 is actually a little more straightforward, and it has the added advantage of defining configuration management through a set of objectives. In plain English, these objectives can be paraphrased as:
(1) Give every configuration item a unique identifier and keep track of them;
(2) Make sure each of those configuration items can be recreated if needed; and
(3) Have a way to control and document every change to every configuration item.
These objectives, regardless of whether they are expressed in plain language or official-speak, are actually fairly simple once the basic concepts of configuration management are understood. These concepts can be summarized as follows:
(1) Each version of each item of life cycle data (files, documents, design data, verification test cases, test procedures, test results, etc., including collections of items) must be uniquely identified such that no other piece of data could ever be confused with it.
(2) Each uniquely identified configuration item must be documented with a paper trail (physical or electronic) that will allow it to be located whenever it is needed.
(3) Each piece of life cycle data must be kept in an environment that is safe from loss.
(4) Each piece of life cycle data must be protected (the level of protection depends on the data type and DAL) from unauthorized changes. This protection can be procedural, electronic, or both.
(5) Changes must be tracked and documented (as with protection, the level of tracking and documentation depends on the data type and DAL), and only the changes that are documented should be made.
Most engineers learn through first-hand experience how hard it can be to keep track of the versions of a design or document, and how painful it can be when versions get mixed up. The pain and difficulty are compounded when the pace of development is fast and multiple versions of an item are being worked at the same time. Ideally, a single bad experience is enough to convert an engineer to the gospel of configuration management.
When engineers are first introduced to formal configuration management, they may not fully appreciate the benefits, which can lead to resistance. This is both common and normal for engineers who are either new to the idea of configuration management or who have never experienced the cost of configuration errors; engineering is well known to be much more fun when unfettered by processes and activities such as configuration management. However, unrestrained development, while fun and usually faster as well, is not appropriate for high integrity design processes because of the higher probability of errors. As noted in the Introduction to DO-254 chapter of this book, it is the supporting processes such as configuration management that allow a design process to achieve and maintain the level of integrity that is requisite for airborne electronic systems.
Configuration management then is the supporting process that minimizes the probability of errors due to incorrect identification of configuration items and their versions, lost or misplaced configuration items, unauthorized changes, incorrectly implemented changes, and inadequately tracked issues. As such, it provides the following for a project and its data:
• Tracking and uniquely identifying each version of a configuration item.
• Provides a known state of the configuration item for development (including verification), delivered hardware, and production.
• Provides for repeatability for every version of the configuration item.
• Provides confidence that the configuration item is the right item, and that the configuration item is built right.
• Ensures that problems or issues with a configuration item are identified, tracked, documented, and properly resolved.
• Ensures that changes made to the configuration item are properly managed and controlled, including:
• Only authorized changes are made.
• The correct version of the configuration item is changed.
• The changes are tracked from beginning to end.
• The changes are made in a deliberate and controlled fashion.
• The changes are implemented as intended.
• The changes meet their intended goals.
• Ensures that every version of the configuration item is safely archived.
• Ensures that every version of the configuration item can be retrieved or recreated.
While not required by DO-254, an electronic file management system with built in version control can help organize project data. These systems often allow groups or sets of data to be tagged and retrieved as a collection. These features support the formation of baselines and the hardware build procedures. File management systems often allow back-end customization and integration with a problem reporting (change request) tool that ties changes to the specific version of a configuration item. Many such electronic tools have reporting features and search capabilities that help project management aspects. A standard project file directory structure can be set up so that new projects simply need to populate data as the project progresses. It is recommended that data be organized by: (1) project; then (2) the version of the release or baseline; and then (3) by configuration item(s) within each release. Given the large volumes of data that are generated during a DO-254 project, it behooves an organization to use tools to store and manage the data.
For traceability and ease of comprehension, a standard file naming convention can be used. The naming convention can be used in conjunction with the electronic file management system. An example of this type of data organization follows:
|
• Requirements document • Requirement • Test case file • Test case in test case file
• Testbench (simulation) • Test procedure (hardware test) • Test results log
• Requirements peer review • Test case reviews • Testbench reviews • Test procedure reviews • Test results reviews |
HRD-13579-RevA HRD-123-456-789 TC-HRD-123-456-789.xls TC-HRD-123-456-789 _001 TC-HRD-123-456-789 _002 TC-HRD-123-456-789 _003 TB-HRD-123-456-789.vhd TP-HRD-123-456-789.txt TR-HRD-123-456-789.log or TR-HRD-123-456-789.wav (waveform capture) PeerRvw-HRD-13579-RevA.doc PeerRvw-TC-HRD-123-456-789.xls PeerRvw-TB-HRD-123-456-789.vhd PeerRvw-TP-HRD-123-456-789.txt PeerRvw-TR-HRD-123-456-789.wav |
DO-254 recognizes that some configuration items are more critical to design assurance than others by defining two data control categories. These data control categories are essentially the same as those defined for software in DO-178, but adapted to hardware and its processes. In fact, inspection of the configuration management portions of DO-178 will show that there are significant similarities between hardware and software configuration management and activities.
Configuration items that are more critical to design assurance, and which therefore require tighter configuration management and control, are defined as being hardware control category one (HC1). Configuration items that are less critical, or in other words that will have less effect on design assurance if it becomes corrupted in some way, are defined as being hardware control category two (HC2).
CONFIGURATION MANAGEMENT ACTIVITIES
Section 7.2 in DO-254 describes the activities that may be used to achieve the configuration management objectives. As with all of the activities described in DO-254, the configuration management activities are recommendations on how to achieve the objectives, but are not required, nor are they the only acceptable way to achieve the objectives. However, when considering the objectives of configuration management against the basic concepts of what configuration management is and should accomplish, the activities in DO-254 are arguably the most reasonable means of implementing configuration management.
Five configuration management activities are defined in 7.2: configuration identification, baselines, problem reporting/tracking, change control, and release/archive/retrieval. Each of these activities is elaborated in sections 7.2.1 through 7.2.5 of DO-254.
Rather than analyze the activities in sections 7.2.1 through 7.2.5, a more useful approach for this discussion of configuration management is to examine Table 7-1 of DO-254. Table 7-1 identifies the specific configuration management activities (taken from sections 7.2.1 through 7.2.5) that must be applied against HC1 and HC2 configuration items. This table contains a great deal of information on the application of configuration management activities, and every DO-254 practitioner should make a point of carefully studying this table and its referenced paragraphs to understand exactly how configuration items must be managed. An understanding of DO-254 Table 7-1 will go a long way toward mastering the fundamental concepts and practices of configuration management.
DO-254 Table 7-1 lists 11 specific configuration management activities, references the DO-254 paragraphs that define them, and identifies the hardware control categories to which they apply. Or alternatively, since all 11 activities apply to HC1 data, the table defines whether each activity applies to HC2 data as well. Thus from DO-254 Table 7-1 it can be seen that the difference between HC1 and HC2 data is that HC1 requires the additional activities of baselines, problem reporting, records/approvals/traceability of changes, release, and archive media selection/refreshing/duplication.
Configuration Identification is the activity whereby each configuration item is unambiguously identified. This unambiguous identification means to assign each configuration item a unique identification (such as a name, number, or both) that identifies both the item and its version. As noted earlier, this identification (ID) must be unique, meaning that no other configuration item can have the same ID. The dissimilarity in configuration identification can take many forms, but when using most of the commercial computer-based configuration management tools it boils down to giving each data item a unique name (or number) and letting the configuration management tool preserve and manage the different versions of the item. In the configuration management tool the configuration item will normally look like a single item that has all of its versions stored in the tool’s database rather than appearing as multiple instances of the item that can all be seen at once. Alternatively, each version of the configuration item can be maintained as separate entities that are each assigned a unique name. Regardless of which approach is used, each version of each configuration item must be uniquely identified so that no two instances of any data items have the same ID.
Provisions should be made to provide unique configuration identifiers for each type of configuration item. While documents, drawings, and schematics traditionally have naming schemes and ensure a unique identity, the large number of other files and data in a DO-254 project also need to have unique names. The following list details the various types of configuration items that require unique identifiers:
• Plans (hardware management plans such as PHAC, HDP, etc.)
• Standards (requirements, design, archive and verification/validation)
• Requirements document
• Design document
• Design data—schematics, layout drawings and files, parts list, assembly drawings
• HDL files
• Programming files
• Test cases
• Test procedures
• Test results (hardware test)
• Testbenches (simulation)
• Test results (simulation)
• Trace data (if separate from requirements, design, or verification documents)
• Peer review forms (templates)
• Completed peer review forms
• Process assurance audit and review records
When using a file management or version control tool, the namespace (i.e., a unique name) is often used for ensuring that a file has a unique identification. In this case, the file name should include the complete directory specification of the file so that identically named files used on different projects can be distinguished. In general, file names can be project specific to help provide a unique identity. But for cases where a common name enhances the comprehension of a design, such as a top.vhd file, then the complete file name should be specified as the identifier. Files reused on another project can have the same file name with a new directory path.
It is not recommended that two configuration items be given the same name and then be stored in different locations on a workstation, laptop, or personal computer that is outside of a file or version control tool.
Baselines are like taking a snapshot of a configuration item and making that snapshot a formal version (configuration) of the item that is then given a unique configuration ID. Baselines should be established for each significant version of a configuration item, meaning each version that will be used for some form of certification credit. For example, a document should be baselined (stored in a configuration control system). For each formal peer review so there is no confusion or question about which version of the document or configuration item was reviewed. Any changes that must be made to the document or configuration item as a result of the review are then made to the same version of the document that was reviewed, ensuring that the review and update process maintains its integrity.
Baselines can also be implemented for groups of data, such as a group baseline of all of the requirements and traceability for all hierarchical levels of an LRU (LRU, circuit card, and PLD requirements, plus the requirements traceability between them). Note that in this example, creating a baseline of the HC1 item (the requirements) includes HC2 data as well (the requirements traceability), so while baselines are created for HC1 data, some of those baselines can include HC2 data.
Baseline traceability, which applies to both HC1 and HC2 items, is the activity in which two baselines of the same item are linked together, or in other words there is a documentation trail between the two baselines. This traceability should be adequate to establish the lineage or descent of the new baseline from the previous one, including the explicit documentation of any changes that were implemented when going from one to the other. As a goal, the changes captured in the traceability should be documented well enough to enable either baseline to be recreated from the other. DO-254 section 7.2.2-4 states that this traceability is one aspect of claiming certification credit for the design assurance artifacts from a previous baseline.
According to DO-254 Table 7-1, baselines apply only to HC1 data items, but baseline traceability applies to both HC1 and HC2. This apparent contradiction—after all, how can there be baseline traceability for HC2 items when HC2 items do not use baselines—is explained by Footnote 1 in Table 7-1, which states that just because an HC2 item is used as part of a new baseline does not mean that it has to be elevated to an HC1 item. What this means is that new baselines that contain HC2 data (such as the traceability in the group requirements baseline example above) have to include traceability between the old and new versions of both the HC1 and HC2 data items in both baselines. So while HC2 items are not subject to baseline traceability when taken as single items because HC2 items by themselves are not baselined, they do have to be traced when they are baselined as part of an HC1 item.
Baseline traceability can be established on two different levels. The first level is through a change history embedded in or associated with an HC1 configuration item. For instance, a PHAC can have its original release—Revision A. The next release is Revision B. The change history in Revision A of the PHAC will simply state that the document is being released for the first time. The change history in Revision B of the PHAC will list the changes (or reference the problem reports or change requests) to create Revision B from Revision A. The traceability between Revision A and Revision B of the PHAC is established through the change history and the problem reports or change requests.
Baseline traceability for an aggregate group of configuration items is established with a configuration index. The first release of the configuration index could be, for example, the –001 version of a PLD. The revision history of the configuration index will simply state that the document is being released for the first time. The change history sections of the configuration index will state that the −001 version is the first release of the hardware. The next release of the configuration index would be for the −002 version of the PLD. The change history in Revision B of the configuration index document will list the changes (or reference the problem reports or change requests) to create Revision B from Revision A. The change history section of the configuration index will list the problem reports or change requests that were incorporated in –002 version of the hardware.
Baseline traceability for an aggregate group of configuration items such as an LRU can be established with the top level drawing in a manner similar to a configuration index for PLDs.
Problem reporting is the formal process through which problems or changes to a HC1 controlled configuration item are documented, tracked, and resolved. A problem report is generally a structured record that is maintained electronically in a problem reporting system, but other ways of tracking problems are acceptable as well as long as the system has the necessary integrity to ensure that problems are tracked from discovery to resolution. However, whether the problem reporting system is implemented with an electronic tool or through index cards, its integrity will ultimately depend on the quality of the problem reporting procedures and whether the people who use them will conscientiously follow those procedures. Problem reports can also include change requests—changes that do not stem from an actual problem.
Problem reports are required for HC1 configuration items once the item is released. When a problem is discovered it should be immediately recorded in a problem report so the problem can be tracked to its eventual resolution. The problem reporting system should track problem reports (and therefore the problem itself) from initiation to closure to ensure that the problem is being worked and that it is eventually resolved.
Problem reports can also be an integral component in the change control activity, since they are an ideal mechanism for approving, documenting, and tracking changes to an item.
A sample work flow with the various phases of completion of a PR is shown in Figure 9.1.
FIGURE 9.1 Problem Report Work Flow
Problem reporting, regardless of the system or level of automation used, should adhere to some basic principles:
• The description of the problem should include all the information needed to accurately reproduce the problem
• The hardware item, including part number and serial number, if a hardware failure or error is reported
• The configuration identifier and version of all life cycle data involved in describing the problem
– Plans
– Standards
– Peer reviews
– Test procedure (if a test was run and failed)
– Test results that identify the problem
– Simulation results that identify the problem
• The PR should include a description of how the problem was found
• Through a review
• During a test
• Reported by a customer
• A root cause analysis that identifies the exact nature of the problem or error. The description of the analysis should be detailed enough to allow the analysis to be independently reproduced or reviewed.
• A change impact analysis that identifies the changes required for the hardware and/or life cycle data. The change impact analysis should clearly describe the change needed for each piece of life cycle data and the activities that need to be repeated, such as rework of peer reviews or a rerun of tests or simulations.
• A detailed description of the changes that were actually made, or a reference to where that information can be found.
The HCMP should define the phases or process flow for problem reporting. All data recorded in the problem report for each phase should also be clearly described. The administration of problem reports is usually performed by a change board. The change control board reviews new problem reports, ensures that the problem reporting system is being used correctly, determines when changes will be incorporated, authorizes changes or solutions to problems, and finally closes out problem reports when all is done. The change control board should also ensure that any problem reports deferred beyond the compliance approval are adequately analyzed for system level impact and determination of potential aircraft safety impact.
The PR starts with a complete description of the starting point of the problem. This should include the item identifier and revision of all life cycle data. The description should be complete enough to allow the problem to be reproduced. For example, if the problem is conflicting requirements, the PR would state the requirements document number and version, the identifier of the two requirements, and a description of the discrepancy. The problem description should be limited to describing the problem, and not contain information pertaining to the analysis and root cause, or to the solution or fix for the problem. If the problem is a test failure, then the PR should identify the hardware item under test, the test procedure that was run, and the test results obtained.
The PR is assigned and an analysis is performed to determine the exact nature of the problem and the underlying fundamental root cause. Once the root cause is known, the analysis can then expand to identify all life cycle data and activities that are impacted or invalidated by the problem.
The change impact analysis should describe the change needed to the hardware and the life cycle data. The analysis should also state which verification activities need to be repeated.
The closure phase of a PR should clearly list the final version of all life cycle data that was updated or reworked as a result of resolving the problem, and how the items were updated or reworked since the actual fix may not be precisely as described in the change impact analysis. This may include the requirements, design, test cases/procedures/benches/results, and all associated peer reviews. Some problems could extend as far as a rework of plans and standards as well as all subsequent life cycle data.
Recording and tracking how problems were found is an excellent way to identify how well the verification activities are performing. If peer reviews rarely find problems and all the problems arise in the test phase, then more training and emphasis could be put on the review process to catch and eliminate problems earlier in the life cycle.
DO-254 section 7.2.3 lists only two types of data that should be documented in problem reports: the configuration of the affected item (the complete identification of the item and its version), and a description of the action taken to fix the issue. However, that does not mean that those are the only types of information that should be recorded in a problem report. If using an electronic problem reporting system, merely documenting an issue and its resolution underutilizes much of the potential of such systems. To use a problem reporting system to its greatest potential, the problem reports can be used to document all aspects of the problem from discovery to resolution. This approach to problem reports has a number of benefits and allows the problem reporting system to be used in ways well beyond its basic purpose of reporting and tracking problems.
Consider the possibilities when problem reports contain the following information:
• A headline or title that contains keywords identifying important aspects of the problem, such as the project, the hardware item’s name and part number, the type of problem, how the problem was discovered, and a very brief description of the problem. Headlines filled out in this manner will make identifying problem reports significantly easier and faster, as well as make it possible to discern the topic of each problem report without having to open and read it. The keywords can be used with filters or searches to gather statistical data on problems and their characteristics, allowing users to identify trends and problem areas that would otherwise escape detection. They can also be used to locate all problem reports associated with each project, hardware item, problem type, etc., to gather statistics on performance and reliability for individual items. When creating standards for filling out problem reports, consider creating a standardized headline format with standardized keywords for the types of statistical data that may be valuable in the future, including post-project lessons learned.
• A problem description that documents everything that is known about the problem. This information should be detailed and comprehensive enough to allow someone other than the author to conduct an analysis and recreate the problem without having to ask the author for more information. This part of a problem report should include the explicit identification of the item that had the problem (including its name, part number, version, and location in the configuration management system, if applicable), what happened. (including the symptoms of the problem), how the problem was discovered. (including all relevant details about the conditions under which the problem appeared), and how to reproduce the problem. As a rule of thumb, if anyone has to ask the author questions about the problem, then the problem description is probably not thorough enough. The problem description should not contain a description of the analysis of the problem nor the solution—those should be documented elsewhere in the problem report to keep information partitioned according to topic. If the problem description is too large for the problem report’s description field, summarize the problem in the description field of the problem report and put the detailed description in a file that is then attached to the problem report. Most electronic problem reporting system•. A problem description that documents everything that is known about the problem. This information should be detailed and comprehensive enough to allow someone other than the author to conduct an analysis and recreate the problem without having to ask the author for more information. This part of a problem report should include the explicit identification of the item that had the problem (including its name, part number, version, and location in the configuration management system, if applicable), what happened (including the symptoms of the problem), how the problem was discovered (including all relevant details about the conditions under which the problem appeared), and how to reproduce the problem. As a rule of thumb, if anyone has to ask the author questions about the problem, then the problem description is probably not thorough enough. The problem description should not contain a description of the analysis of the problem nor the solution—those should be documented elsewhere in the problem report to keep information partitioned according to topic. If the problem description is too large for the problem report’s description field, summarize the problem in the description field of the problem report and put the detailed description in a file that is then attached to the problem report. Most electronic problem reporting systems allow documents and other files to be attached; if this feature is not included in the problem reporting tool, or if a non-electronic system is used, the problem description should be placed in a configuration management system and referenced from the problem report.
• A description of any analyses that were conducted to reproduce the problem and determine its root cause. The analysis should start with the information in the problem description and from there develop enough additional information to allow the problem and its root cause to be understood, and to allow potential solutions to be developed. The description of the analysis should be detailed and thorough enough to allow a reader to understand how the problem was analyzed, how the analysis was conducted, what the analysis revealed (including the root cause, if known), how to recreate the analysis if needed, and potential solutions to the problem. It should also analyze the impact of the issue and its resulting changes on all related items and processes, and identify and document all of the other items, documentation, and processes that will be affected as part of the ripple effect of the initial problem and its resolution. This includes any feedback that may be needed to other processes and activities. However, how the problem was actually fixed should not be documented in the description of the analysis, nor should the analysis only describe the possible solutions.
• A description of the resolution or disposition of the problem. This information should describe how the final solution was determined and how it would solve the problem, a detailed description of how it was implemented, the complete identification of the item and version in which the solution was implemented, and how the efficacy of the solution was independently verified.
The reason for including so much detail in the problem report is twofold: first, skimping on details will only increase the cost of the problem report as well as increase the chance of errors by forcing every reader to search elsewhere for the information they need; and second, putting every known fact into the problem report will make it a self-contained history of the problem, which means all information about the problem and its resolution will be documented in a single location.
Change control has two components: integrity and identification; and records, approvals, and traceability.
The first component of change control—integrity and identification—applies to both HC1 and HC2. This activity ensures that the integrity of a configuration item is preserved when changes are needed by ensuring that the item is changed only when actually necessary. This is accomplished through two mechanisms: first, each potential change to an item should be assessed to determine whether the item truly needs that change, and second, the item should be changed only when authorized. The end result of this activity is to make sure that all changes to a configuration item have been assessed to ensure that changing the item is acceptable in all respects.
Assessing changes to determine whether they are actually needed is a way to minimize the number of updates to an item. Updates can be time consuming and expensive for HC1 items, and for both HC1 and HC2 items, frequent or unnecessary updates can cause configuration problems if they are not managed well. It makes sense that all items should be updated only when necessary. The measurement of what is necessary will vary depending on the item, and there are no standardized guidelines on when a change should be implemented as opposed to deferred, but in general if a change will not alter the fundamental characteristics of the item then it is probably best deferred until a later date. For example, a typographical error that will not affect the linguistic or technical content of a document can be left in queue for a future release instead of forcing an immediate update.
Preventing unauthorized changes makes good sense for any type of information, and is essential for controlling the configuration of data. This applies to both HC1 and HC2 items, and while DO-254 provides no guidance on who should authorize changes nor on the criteria that should be used in the decision, the unwritten expectation is that the level of control in this activity should be considerably more stringent for HC1 items than it would for HC2. For HC1 items the authority to make a change is implicit in the approval of the change (part of the second component of change control, which applies only to HC1 items), so for HC1 items this activity can be tied to the problem reporting or change control activity by requiring that a problem report or change request be initiated for any change to the item, that the problem report or change request be reviewed and approved by a change control organization, and that the ensuing changes be managed and tracked by that problem report. In contrast, changing an HC2 item may simply require agreement from a technical lead or peer review. Whatever process and criteria will be used should be documented in the configuration management plan for the project.
The second component of change control—records, approvals, and traceability—applies only to HC1 items, and is intended to address the integrity of a change once the first component (integrity and identification) ensures that the change has been identified and authorized. HC1 items require a higher level of integrity during the change process, and this activity provides that integrity by requiring that changes be minutely managed throughout the evolution of the change.
DO-254 provides the following objectives for this activity:
• Changes should be recorded, approved, and tracked.
• Changes should be traced to the reason for the change.
• The impact of the change should be assessed to identify any ripple effects.
• Feedback is provided to affected processes.
This guidance is both explicit and ambiguous, in that it states fairly clearly what must be done to manage changes, but on the other hand it does not provide guidance on the level of integrity required for each activity and objective. While the level of integrity will certainly depend to some degree on the DAL of the hardware, even that guidance provides little tangible direction and leaves almost everything to the discretion of the reader.
Given that most HC1 items can affect the integrity of the configuration item, it makes sense that change control activities should have a high level of integrity regardless of the DAL.
Recording changes simply means that each change to a configuration item should be documented. Determining how well the changes should be documented can be determined by looking at the other configuration management activities, since this activity must be consistent with all of the other configuration management activities and their goals. One configuration management activity that is closely related to change control is baseline traceability. If the goals of baseline traceability and change recording are taken together, it follows that a suitable level of integrity for change recording is to document changes with enough detail to enable adjacent baselines to be recreated from each other.
Change approval is similar to, but different from, the authority to make changes that is part of the integrity and identification aspects of change control discussed above. The approval to make a change means a specific change has been approved and that someone has the authority to make the approved change. In contrast, the authority to make changes allows someone to change an item but does not specify what changes will be made. Nor does it guarantee that the changes that will be made are approved or desired. This is one important aspect of change control that provides greater integrity for the changes made to HC1 items.
So for change control for HC1 items, changes must be approved as opposed to just authorized. In practical terms, this means that all changes to an HC1 item must be approved before being made.
Tracking changes means managing and monitoring changes to an item through-out the evolution of the change, from initial inception to final disposition and verification of the change. Tracking can be accomplished through procedural means such as regular status meetings on changes and updates, or through the use of tools such as a problem reporting system. The goal of this activity is to make sure that all changes that are approved are implemented in the accepted timeframe and in the intended manner.
Tracing a change to the reason for the change is another tool in assuring the integrity of changes. It justifies every change that is made to ensure that they all have a valid reason and none are made randomly or arbitrarily.
Using problem reports for change control is highly recommended, if not implicitly required through the expectation of certification authorities. As stated previously, problem reports are ideally suited to recording, approving, tracking, and tracing changes, especially if they are used in the manner described earlier in this chapter. If the problem report guidance in this chapter is followed, and problem reports are created for all changes to HC1 items, then the recording, approving, tracking, and tracing aspects of change control never have to be addressed as a separate activity.
This interdependence between problem reporting and change control is not required by DO-254; the only reference to this tie-in is a note stating that there is a relationship between them because some changes may result from an issue that is managed by a problem report. However, using problem reports as part of the change approval process is a convenient means of satisfying the needs of both aspects of change control.
Release is the act or process of formally placing an item under configuration control and making it available for use by downstream processes and activities. It ensures that only authorized data is used, particularly for verification and manufacturing. Releasing data normally requires authorization, and once released, the item is typically stored in a configuration management system that allows the item to be retrieved when needed, but does not allow the item to be changed without the proper authorizations and approvals. Data items used for manufacturing must be released prior to use.
Releasing an item creates a baseline of the item, but it differs from the baseline activity in that it is a formal baseline and requires approvals, and the version that is released is placed under configuration/change control. Baselines can be created outside of configuration control and can be informal. For example, requirements can be baselined in a requirements management system, and an HDL design can be baselined in a configuration management system, but in both cases the baselines are informal until they go through a formal release process. There can also be multiple baselines of an item between releases, say for intermediate updates and peer reviews that may occur when a released item is being changed.
All configuration items must be retrievable from their archive location. This should be self-evident, since an archive is of no value if the information in it cannot be accessed, but at the same time there are no guidelines on how accessible the data has to be, and it is possible to envision an archive where the data can be retrieved but not without great effort and extended delays.
The accessibility of archived data takes on added significance when the data must be retrieved on short notice and under stressful conditions, such as when a piece of airborne equipment experiences a failure that is serious enough to ground a fleet of aircraft well after that aircraft has entered service. When such an event occurs, the entire project may need to be reconstituted very quickly to fix the problem, prove that the problem is fixed, and get the fixed hardware back in production. Any delays in retrieving data and reconstituting the project will translate into additional time that the fleet will be grounded. The financial liability that can be incurred from such an event can be enormous, so the time it takes to retrieve archived data can have a significant impact under the right conditions.
The type of data that is archived can also have an impact on the ease or timeliness of retrieval. For example, a development environment, including test stands that are used for both design and verification activities, can be archived as fully assembled and operational hardware or as a set of drawings from which those test stands are built. Archiving test stands can be expensive, space-intensive, and may require periodic calibration or maintenance, whereas archiving the drawings will be much easier and convenient. However, under the extreme conditions described in the aircraft fleet grounding scenario described above, the time needed to reconstruct the test stands from drawings could add many weeks to the recovery schedule, and therefore increase by many weeks the time that the fleet is grounded. If any of the original components of the test stands are obsolete—a likely scenario considering the rapid evolution of electronic hardware and computers—the delays could be much greater because it will necessitate that the test stands be redesigned as well as rebuilt. Either approach will satisfy the DO-254 objectives of archive and retrieval, but one comes with a significantly higher risk in the long run.
The data describing the configuration item being retrieved must also have adequate integrity, meaning that after retrieval the data must be identical to the data that was archived. So if data was compressed for archive, the archive and retrieval process must ensure that the decompression format will still be supported after an extended period of time, or that the decompression software is archived with the compressed data. The same concept applies to data that is archived off-site at a data storage facility, especially if that facility is owned by a different company: precautions should be taken to ensure that the data will be preserved and retrievable if the storage company should suffer damage or go out of business.
Guidelines and procedures for retrieving configuration items should be established for each method used to store and archive the configuration item. Local storage and retrieval on a workstation or personal computer is maintained by the user. Network servers can have access rights and permissions established for each account and for the directories accessed by that account. An electronic file management system will have user login credentials and permissions. In general, an electronic file management system retains a copy of all data that has been checked in and forces the version number to change when a new version is checked in. Production data systems typically only allow general users to see read-only versions of the data for a configuration item. The production data system will allow users to access a PDF copy or other formats that cannot be modified. Retrieving data from an off-site long-term storage or archive facility should use more formal requests for a configuration item, especially for older items that may still be in paper or a hard copy format. Retrieving data from a backup is typically handled in conjunction with an information services department and requires a documented request.
The Data Retention activity addresses the need to ensure that archived data is preserved intact for as long as the data is needed (typically as long as the hardware item is in service). It is not uncommon for modern aircraft to stay in service for more than 50 years, and there are still relatively ancient aircraft (such as the Douglas DC-3) still in commercial service throughout the world more than 75 years after they were built. If a piece of equipment on such an aircraft manages to survive without modification for the life of the aircraft, then the equipment manufacturer needs to archive that equipment’s life cycle data for generations after the equipment designers have retired or died. While this scenario may be uncommon for most pieces of electronic hardware, it is still probable enough to make planning for it a wise idea.
Data retention requirements can also be traced back to the regulations. Federal Aviation Regulation 14 CFR 21.49 states that the holder of a type certificate must make the certificate available for examination upon the request of the FAA or the National Transportation Safety Board (NTSB). A type certificate is defined in 14 CFR 21.41 as including the type design, the operating limitations, the certificate data sheet, the applicable regulations with which the FAA records compliance, and any other conditions or limitations prescribed for the product. 14 CFR 21.31 defines the type design to consist of:
• The drawings and specifications, and a listing of those drawings and specifications, necessary to define the configuration and the design features of the product shown to comply with the requirements applicable to the product;
• Information on dimensions, materials, and processes necessary to define the structural strength of the product;
• The Airworthiness Limitations section of the Instructions for Continued Airworthiness as required by parts 23, 25, 26, 27, 29, 31, 33, and 35 of the regulations, or as otherwise required by the FAA; and as specified in the applicable airworthiness criteria for special classes of aircraft defined in 14 CFR 21.17(b); and
• For primary category aircraft, if desired, a special inspection and preventive maintenance program designed to be accomplished by an appropriately rated and trained pilot-owner.
• Any other data necessary to allow, by comparison, the determination of the airworthiness, noise characteristics, fuel venting, and exhaust emissions (where applicable) of later products of the same type.
In summary the type design consists of the data (design assurance data in this case), the type certificate includes the type design, and the type certificate must be made available upon request. In other words, the design assurance data must be made available upon request.
PROTECTION AGAINST UNAUTHORIZED CHANGES
Protection against unauthorized changes may sound familiar, since this topic was already introduced in the discussion on the first component of change control, in which the integrity of data should be preserved through protection against unauthorized changes. However, in this incarnation the protection against unauthorized changes is taken within the context of archived data, whereas in the previous instance it was discussed within the context of current active data. While the concept is the same—protect the data from unauthorized changes to preserve its integrity—the setting and processes may be a little different.
Like the change control version of this topic, there is no formal guidance on the types and levels of control that must be implemented; the final determination of the adequacy of the protection, as well as how long the protection should be maintained, will be made by the certification authorities. However, the integrity of the data is just as important in an archive as it is with current data, so it makes sense to implement similar controls.
MEDIA SELECTION, REFRESHING, DUPLICATION
Protection against unauthorized changes is just one aspect of ensuring the integrity of archived data; it will prevent data from being changed when it should not be, but it will not ensure the integrity of the archive itself. It is the Media Selection, Refreshing, and Duplication activity that addresses the integrity of the archive and therefore its contents.
Media selection is the process of selecting the method of archiving data, such as using a commercial data storage facility, an in-house networked server, or optical storage disks. Each medium has its advantages and disadvantages, and the archive process should consider all of them when selecting which medium to use. The selected medium should satisfy all of the objectives of the configuration management processes as well as the airworthiness requirements. Of particular interest is the issue of data retention, since it is conceivable that the data for some hardware items could require archiving for decades.
Media refreshing addresses the issue of data retention when the selected archive media has insufficient storage life to satisfy the long-term data retention requirements for an archive. If a medium that does not have long-term stability is selected, the archive process should anticipate the need to refresh the archive to mitigate the shorter than needed storage life.
Media duplication ensures that the archived data will be safe from loss due to destruction or deterioration of the archive. It is similar in concept to redundancy in electronic hardware design. Duplication or duplicate archives should be independent as well to prevent a single-mode failure, or in other words, more than one copy of the archive should be independently maintained to prevent a single event from causing a loss of the archived data.
Consideration also needs to be given to migrating data from one media to a subsequent or next generation media. Years ago, paper drawings and documents were stored. Microfilm was next used to reduce storage space. These days, electronic media is used to store data. The media has evolved from floppy disk to tape to CD-ROM to BluRay-ROM to Flash drives, and so on. Proper management of archived data over the ensuing years will allow the data to be accessed when needed.
1. Code of Federal Regulations, Title 14: Aeronautics and Space, PART 21—CERTIFICATION PROCEDURES FOR PRODUCTS AND PARTS, Subpart B—Type Certificates, 21.31 Type design.
2. Code of Federal Regulations, Title 14: Aeronautics and Space, PART 21—CERTIFICATION PROCEDURES FOR PRODUCTS AND PARTS, Subpart B—Type Certificates, 21.41 Type certificate.
3. Code of Federal Regulations, Title 14: Aeronautics and Space, PART 21—CERTIFICATION PROCEDURES FOR PRODUCTS AND PARTS, Subpart B—Type Certificates, 21.49 Availability.