Validation activities with respect to the requirement baseline

specification with respect to the requirement baseline

This chapter focus on software validation with regard to the RB, and provides recommendations on how to do it.

RB validation aims at validating the software against the requirements of the requirement baseline. The ECSS-E-ST-40C clause 5.6.4.1 requires the 100 % validation of the RB.

The requirements of validation w.r.t. the TS and the RB are the same, except:

a. the 5.6.4.1 / a / 1 requirement: “testing against the mission data and scenario specified by the customer in 5.2.3.1”.

b. the 5.6.4.1 / a / 4: validation w.r.t. RB requires a "non-intrusive environment", meaning that the interface used is the real operational one (e.g. TC/TM for on-board software) without use of any intrusive means to exercise software functions.

c. the 5.6.4.2 / b: validation w.r.t. RB shall test software as unmodified "black-box" (also without patches/workaround).

The RB validation test definition is an activity on its own. The RB requirements are written from the Customer standpoint and must be validated with this spirit, whereas the TS requirements are written by the Supplier and define the detailed behaviour of the software. As RB requirements are fully covered by (a set of) TS requirements that are themselves fully validated by a set of tests, this traceability may contribute to the identification of the validation tests against the RB. This requires that the traceability RB/TS is checked from an engineering standpoint (not being granted by a table or a traceability tool).

Validation activities w.r.t. to RB should complement the ones w.r.t. to TS in particular in the following cases:

a. when many TS requirements cover a single RB requirement, and each test case w.r.t. TS test individual TS requirements, thus not testing the parent RB requirement as a whole.

b. when operational scenarios have been defined in the RB (taking into account expert knowledge of what the system does, and the technology the system uses).

c. or when operational data is not available for the TS validation , and the set of operational data requires a rerun of a subset of the validation tests.

d. or when the TS validation test environment is not representative enough w.r.t. the qualification objectives (computer target representativeness or open/closed loop tests).

Except for the case (b) which should be clearly identified inside the RB, the two others cases should be specified inside the SOW as a validation logic scheme.

For case (b), the objective will be reached in exercising operational scenarios, elaborated jointly between the supplier and the customer with the aim of anticipating system level tests in the supplier’s environment. The operational scenarios should be defined in the RB.

For case (d), ECSS-E-ST-E40C §5.8.3.9 specifies that the supplier is in charge to alert the customer. In this case, the activity will be performed on another test environment, either by the supplier or by another team (avionic integration team, system team, etc. …) under the responsibility of the customer. According to the alternative chosen, the validation w.r.t. to RB can be based on a subset of TS validation tests (same validation team using same test specifications , updating the program test according to the test mean configuration ) or can be a complete new set of tests (new validation team introducing new test scenarios ).

NOTE If the customer performs these tests, there could be a potential overlapping with the acceptance tests that is described in 5.7.3 software acceptance.

5.6.4.2

Conducting the validation with respect to the requirement baseline

-

5.6.4.3

Updating the software user manual

-

5.6.4.4

Conducting a qualification review

The qualification of the product is pronounced at the QR review, after the complete development and validation process has been conducted successfully by the supplier.

The qualification status is the evidence of a complete and compliant product to the requirement baseline (as per 5.6.4.1).

In case the supplier uses one single representative SVF (including closed loop) enabling to cover both RB and TS validation testing phases, and there is an adequate mapping of requirements between RB and TS (thanks to traceability), the supplier can conduct a combined phase test in order to validate the product simultaneously against TS and RB. In that context, it may be decided to have a single CDR/QR covering both objectives.

If the risk of finding errors late in the system testing is accepted, representative enough SVF may not be developed. It may be acceptable to perform software validation against RB directly on the real HW (BB, EM or even FM) during a dedicated phase, or combined together with system level integration / qualification. In that context, SW QR may be considered as part of the system QR.

Sometimes, the Customer defines himself the TS in form of detailed software requirements specifications SRS, which is then provided as part of the tendering material (ITT) as the base line for software development. In this case the software development starts directly from SRS, i.e. no RB exists. The supplier often amends and extends the SRS (TS) which is then reviewed by the Customer and finalised in SWRR. All verifications are then performed against this SRS (TS) and no RB is defined/maintained in this case. The QR is accordingly tailored out, with appropriate justification.

In the case of ground software developments, e.g. Mission Control System MCS and Operational Simulator developments, it is typical that the software is additionally validated by the software operator (Flight Control Team, FCT) in the context of so called Simulation Campaigns, using the Ground Operation Procedures and the Flight Operation Procedures. During these simulation campaigns all elements of the ground segment are either present as real software/hardware or simulated as part of the operational simulator, including the ground stations network and the constituting elements of each ground station as well as the communication between the Mission Control System and the ground stations. The Space to Ground link as well as the complete Space Segment are replaced (simulated) by the operational simulator, respecting the applicable space to ground ICD.