source: rtems-docs/eng/prequalification.rst

Last change on this file was bbb8b7a, checked in by Sebastian Huber <sebastian.huber@…>, on 05/19/23 at 05:34:36

Update company name

The embedded brains GmbH & Co. KG is the legal successor of embedded
brains GmbH.

  • Property mode set to 100644
File size: 5.1 KB
Line 
1.. SPDX-License-Identifier: CC-BY-SA-4.0
2
3.. Copyright (C) 2020 embedded brains GmbH & Co. KG
4.. Copyright (C) 2016, 2018 RTEMS Foundation, The RTEMS Documentation Project
5.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
6
7Introduction to Pre-Qualification
8*********************************
9
10RTEMS has a long history of being used to support critical
11applications. In some of these application domains, there are standards
12(e.g., DO-178C, NPR 7150.2) which define the expectations for the
13processes used to develop software and the associated artifacts. These
14standards typically do not specify software functionality but address
15topics like requirements definition, traceability, having a documented
16change process, coding style, testing requirements, and a user's
17manual. During system test, these standards call for a review - usually
18by an independent entity - that the standard has been adhered to. These
19reviews cover a broad variety of topics and activities, but the process
20is generally referred to as qualification, verification, or auditing
21against the specific standard in use. The RTEMS Project will use the
22term "qualification" independent of the standard.
23
24The goal of the RTEMS Qualification Project is to make RTEMS easier
25to review regardless of the standard chosen. Quite specifically,
26the RTEMS Qualification effort will NOT produce a directly qualified
27product or artifacts in the format dictated by a specific organization
28or standard. The goal is to make RTEMS itself, documentation, testing
29infrastructure, etc. more closely align with the information requirements
30of these high integrity qualification standards. In addition to improving
31the items that a mature, high quality open source project will have,
32there are additional artifacts needed for a qualification effort that
33no known open source project possesses. Specifically, requirements and
34the associated traceability to source code, tests, and documentation
35are needed.
36
37The RTEMS Qualification Project is technically
38"pre-qualification." True qualification must be performed on the
39project's target hardware in a system context. The FAA has provided
40guidance for Reusable Software Components (FAA-AC20-148) and this
41effort should follow that guidance. The open RTEMS Project, with the
42assistance of domain experts, will possess and maintain the master
43technical information needed in a qualification effort. Consultants
44will provide the services required to tailor the master information,
45perform testing on specific system hardware, and to guide end users in
46using the master technical data in the context of a particular standard.
47
48The RTEMS Qualification Project will broadly address two areas. The
49first area is suggesting areas of improvement for automated project
50infrastructure and the master technical data that has traditionally been
51provided by the RTEMS Project. For example, the RTEMS Qualification could
52suggest specific improvements to code coverage reports. The teams focused
53on qualification should be able to provide resources for improving the
54automated project infrastructure and master technical data for RTEMS. The
55term "resources" is often used by open source projects to refer to
56volunteer code contributions or funding. Although code contributions in
57this area are important and always welcome, funding is also important. At
58a minimum, ongoing funding is needed for maintenance and upgrades of
59the RTEMS Project server infrastructure, addition of services to those
60servers, and core contributors to review submissions
61
62The second area is the creation and maintenance of master technical
63data that has traditionally not been owned or maintained by the RTEMS
64Project. The most obvious example of this is a requirements set with
65proper infrastructure for tracing requirements through code to test
66and documentation. It is expected that these will be maintained by the
67RTEMS Qualification Project. They will be evaluated for adoption by
68the main RTEMS Project but the additional maintenance burden imposed
69will be a strong factor in this consideration. It behooves the RTEMS
70Qualification Project to limit dependence on manual checks and ensure
71that automation and ongoing support for that automation is contributed
72to the RTEMS Project.
73
74It is expected that the RTEMS Qualification Project will create and
75maintain maps from the RTEMS master technical data to the various
76qualification standards. It will maintain "scorecards" which
77identify how the RTEMS Project is currently doing when reviewed per each
78standard. These will be maintained in the open as community resources
79which will guide the community in improving its infrastructure.
80
81Stakeholder Involvement
82=======================
83
84Qualification of RTEMS is a specialized activity and only specific users
85of RTEMS will complete a formal qualification activity. The RTEMS Project
86cannot self-fund this entire activity and requires stakeholders to invest
87on an ongoing basis to ensure that any investment they make is maintained
88and viable in the long-term. The RTEMS core developers view steady
89support of the qualification effort as necessary to continue to lower
90the overall costs of qualifying RTEMS.
Note: See TracBrowser for help on using the repository browser.