Lifecycle data

Definition of SAV Development Assurance objectives as they relate to the SAV hfecycle processes, including the relationship between DAL, applicable objectives, independence, and SAV lifecycle data. 

In essence, the DAL Objectives provide a way for the certification authority to evaluate the applicant s product lifecycle data and processes to establish if the data supports the assertion that the system is assured. It provides a measureable way to deal with evidence that may have qualitative properties (e.g., human review evidence) and/or quantitative properties (e.g., test results of an algorithm). By using an objective-based approach, these guidelines/standards provide the developer with some flexibility in choosing methods and techniques that best suit their needs, provided that the evidence (i.e., output or deliverables or data items) satisfies these objectives. 

Hardware design lifecycle data produced complies with the approved plans. o o Hardware Process Assurance Plan 10.1.6 HC2 HC2 NA NA... 

The hardware item used for conformance assessment is built to comply with the associated lifecycle data. o o Hardware Process Assurance Records 10.8 HC2 HC2 HC2 NA... 

Hardware design lifecycle data produced comphes with the approved plans. 

The hardware item used for conformance assessment is built to comply with the associated lifecycle data. 

Milestones where applicable Objectives should be satisfied by the lifecycle data being produced. 

Evidence of the acceptability of any lifecycle data provided by SAV or hardware processes to the system processes, including evaluations of derived requirements for impact on SSA and system reqnirements and issues raised by SAV or hardware processes in relation to system requirements allocated to SAV or hardware. 

Lifecycle data to snpport integration of the SAV or hardware into the system. 

RTC A/DO-254 defines Functional Failure Path (FFP) as the specific set of interdependent circuits that could cause a particular anomalous behaviour in the hardware that implements the function or in the hardware that is dependent upon the function. FFP Analysis (FFPA) is used to iteratively decompose the hardware functions into a hierarchy of subfunction to determine if it will be possible to fulfil completely the objectives of RTCA/DO-254 for each subfunction. If the assurance lifecycle data available or expected to be available is complete, correct and acceptable per the RTCA/DO-254 objectives and guidance, then no further decomposition is necessary. If it is not, then decomposition continues until such a stage as the FFP feasibly maps to one of the Development Assurance methods (and associated data set) as described in the previous section. For FFPs that are not Levels A or B, their interrelationships with the Level A or B FFPs should be evaluated using an F-FMEA, common mode analysis or dependency diagram to ensure that the Level A and B FFPs cannot be adversely impacted by the FFPs which are not Level A or B. 

Table 9A.1 shows each RTCA/DO-254 objective mapped to the corresponding lifecycle data (evidence) required to satisfy it. This table is not explicitly included in RTCA/DO-254, however it has been produced consistent with the RTCA/DO-178C table format in order to show the relationship between objectives and lifecycle data, and the synergies that exist between the standards. RTCA/DO-254 provides further definition of the lifecycle data outputs/evidence, which the reader should refer to understand the information requirements of the lifecycle data outputs. 

Requirements, designs, implementation or documentation are reviewed by another individual. This individual should be intellectually independent on the development of the lifecycle data. 

B9.1 Configuration Management Recall from Section 9.3.4.3 that one of the objectives of SAV assurance was configuration consistency. Essentially, does the evidence produced throughout the SAV lifecycle have traceability to the delivered SAV product For example, what is the relevance of a safety case claim made from SAV lifecycle data that cannot be traced or be shown to be consistent with the version of SAV being delivered Clearly the relevance is low, and would not form a robust argument in the safety case. 

The starting point for any robust configuration management system of SAV lifecycle data is a SAV CMP. The typical contents of a SAV CMP are as follows ... 

SAV conformity review - is the lifecycle process complete Is the lifecycle data complete Is the executable object code controlled and can it be regenerated nsing the SAV lifecycle data Is there any evidence that the SAV product does not conform to its documentation ... 

A prototype system framework of PEEE has been developed using Java and Visual Basic as object-oriented programming languages, while SQE server and MS-Access are used as RDBMS for data repository for the plant model elements. Such prototype solution will enable all plant users to utilize a standard user interface to manipulate plant lifecycle data/information/knowledge. The prototype system can be used as the framework to develop CAPE-SAFE as well as other components within PEEE. 

---