Control Categories CC1 and CC2 in DO-178B

The aspect that I found most difficult to grasp in the DO-178B document is related to the CC1 and CC2 - to put it formally, Data Control Category 1 and Data Control Category 2. CC1 and CC2 define which of the 13  configuration management objectives are applicable to the software life cycle data. The map between CCx and Data is available in Annex A Tables.

But why this categorisation? Won't it be easier to just have one set of objective that applies to all data? After all every data has a reason to exist.

Even more puzzling is the fact that the same data can have different Control Category depending on the Level of the SW. How can the importance  of data reduce just because sw moves from Level A down to say Level C?  For example, Software Verification Cases and Procedures (SVCP) are CC1 for Level A and B, and CC2 for Level C and D. Does this mean that for  Level A and B, SVCP shall be subjected to Baselines and Control Change - Tracking, but not for Level C and D? Ditto for 4 PLANS (except PSAC)
and Standards, and surprise, surprise, Design Description (?????).

To add to the confusion, SVCP is CC1 for Level A in Table A-6 and CC2 for Level A in Table A-7. Fortunately, one quickly realises that there is a typo in Table A-7: it should be Software Verification Results instead of SVCP.

Ok here is another one that I figured out very recently. Problem Reporting is an objective that is covered under CC1. However, Problem Reports themselves are CC2 data. I eventually realised that all this means is that one does not require a Problem Report to modify a Problem Report! Fair enough.

Unfortunately, there is no explanation given in DO-178B as to why a particular Control Category applies. So, no logic can be applied.

However, there is a small reprieve. Paragraph 7.3.b indicates that "the SCM process objectives for software life cycle data categorized as CC2 should be applies according to Table 7.1 as a minimum. We at AKS take refuge in "as a minimum". 

To start with we treat all data at CC1, whatever be the categorisation specified in DO-178B and irrespective of the SW level. For example, we have figured out a way how we can have baselines for Problem Reports. For others we have decided that certain objectives cannot be applied and DO-178B is correct in specifying these at CC2. As a result, we have data at CC1 and CC1Minus. Of course, it helps if one has a configuration tool that is intuitive (which we have and is an in-house product and one that we are very proud of.)

I shall continue to dig into CC1/CC2 puzzles till I discover the underlying logic behind every aspect of the Control Categories.

Comments

[Harold]

I think that in the focus on understanding the CC1/CC2 mechanisms of DO-178, a fundamental principle of Aircraft System Design and Analysis Assurance is missed, namely the greater the hazard, the greater the need for prevention, detection, and removal of error. (see AC 25.1309B-Arsenal draft)

The correlation suggested between CC1/CC2 of DO-178 and the document/record controls of ISO9001/AS9100 is a poor one; the latter is not explicitly safety-oriented, rather poorly organized, non-sensitive to degrees of risk, and its requirements really don’t line up well against CC1/CC2 objectives.

I view control of critical data as a set of concentric rings, with the greatest control at the center and the least control at the fringes -- central controls are built upon the outer controls. As my first DER said, “You don’t review reviews and you don’t test tests.” (Well, you do, if it is really critical, but to a lesser extent.)

The simplest distinction I see between CC1 and CC2 is in the relative risk-driven need for independent verification. Most of the differences between CC1 and CC2 are to meet the needs of repeatable independent verification. If the function is catastrophic or hazardous, you need to remember what was independently verified, remember what problems verification found, and remember whether all of those problems were ever fixed. If the item is less than hazardous, it does not need (from a safety perspective) independent verification (no baselining or problem reporting). If the item does not need independent verification, then changes do not need independent verification (no change baselining or change review). Records are associated with CC2 only because error in records is presumed to be less hazardous than errors in requirements, design or code. At lower DAL, errors in requirements, design or code become less hazardous and so are subject to less control.

[bedroom furniture]

great man :D

[RMH]

It is hard to see why you are having trouble understanding the differences between the two categories. It is almost as though you have read the Annex A tables but not the text. In very simple terms, the required attributes of all data items controlled to CC1 are as follows:

Configuration Identification: In accordance with Section 7.2.1
Baselines: In accordance with Section 7.2.2a, b, c, d, e
Traceability: In accordance with Section 7.2.2f, g
Problem Reporting: In accordance with Section 7.2.3
Change Control - integrity and identification: In accordance with Section 7.2.4a, b
Change Control - tracking: In accordance with Section 7.2.4c, d, e
Change Review : In accordance with Section 7.2.5
Configuration Status Accounting: In accordance with Section 7.2.6
Retrieval: In accordance with Section 7.2.7a
Protection against Unauthorized Changes: In accordance with Section 7.2.5b(1)
Media Selection, Refreshing, Duplication: In accordance with Section 7.2.7b(2), (3), (4), c
Release: In accordance with Section 7.2.7d
Data Retention: In accordance with Section 7.2.7e

The required attributes of all data items controlled to CC2 are as follows:

Configuration Identification: In accordance with Section 7.2.1
Traceability: In accordance with Section 7.2.2f, g
Change Control - integrity and identification: In accordance with Section 7.2.4a, b
Retrieval: In accordance with Section 7.2.7a
Protection against Unauthorized Changes: In accordance with Section 7.2.5b(1)
Data Retention: In accordance with Section 7.2.7e

I hope this helps clarify matters for you.

[records management]

I am quite confused in between CC1 and CC2. What I am able to understand is that CC1 is just like analogous to controlled documents and CC2 is analogous to quality records. That's all.

[RMH]

This error was corrected in the Errata (number 12) to DO-178B/ED-12B published in DO-248/ED-94 ten years or so ago.

The error, obviously, does not appear in DO-178C/ED-12C.

[Amitabh]

Actually @CAMARA the error is not in the Control Categorisation. CC2 is correct. However, the SVCP is a typo. It should be SVR (Software Verification Result).

[CAMARA]

I think that the typo error in the table A-7 is that the SVCP must be in CC1 instead of CC2 for level A.

[Amitabh Mukherjee]

Thank you Agave for your response. I am in complete agreement with you. And you analogy is apt.
The inhouse tool is built around configuration management. It is an integrated suite of tools that helps us at AK Aerotek execute projects without using paper. It seamlessly merges all aspect of HR, Project Management and technical activities that are required to execute project.

[Agave]

The separation into CC1 and CC2 eases the burden of CM workload. If everything was CC1 it would be extremely time consuming to maintain all of the required documentation. CC1 is analagous to controlled documents in ISO 9001, and CC2 is analagous to quality records (evidence of work done) in ISO 9001. The analogy is not exact but useful to help to understand the split.

I'm interested in hearing about your in house tool? What is it and what can it do. We've created our own in-house tool as well.