CA .docx Import Example

Success

Discipline Endorsed Practice - DELIVERABLE

Date: October 2020 Revision Ltr: -

Note: This document defines an endorsed standard practice that is recommended for assessment, adoption and/or adaptation by the applicable Collins Aerospace value streams.  The document was developed by subject matter experts in the identified engineering discipline and is endorsed by that discipline’s Senior Fellow Discipline Lead (SFDL).  This document does not contain any mandatory requirements, is not part of any Enterprise Quality controlled document repository, nor is it auditable.  SBUs/Sites/value streams that elect to adopt content from this document into their standard practices are responsible for document control.  Demonstration of adherence to or adaptation of this standard are the responsibility of the SBU/site/value stream. 

PURPOSE

DELIVERABLE DESCRIPTION

The deliverable for requirements validation is evidence that the Technical Requirements Dataset (TRD) for the system development is correct and complete. Validation evidence is the output and any relevant data resulting from the application of one or more validation methods to each requirement or a set of requirements in the TRD. Depending on the system development plan, the deliverable may include updates and disposition of the validation status through the relevant attributes data.

Error creating thumbnail: File missing

VALUE PROPOSITION

Ensuring that the technical requirements for the system development are correct and complete minimizes issues and problems that may not be uncovered until very late in the product lifecycle. These issues may have significant impact to cost, schedule, reliability, and company reputation.

APPLICABILITY

Requirements validation applies to all types of systems whenever requirements are modified, developed, decomposed, or derived.

TIMING

Requirements validation can start as soon as requirements are developed, decomposed, or derived. Validation should be completed before the requirements are handed off to the next responsible party – typically for implementation or further development of the requirements set. Validation should also be repeated whenever requirements are altered or modified, which can happen at any time during the development life-cycle.

DELIVERABLE(S) DETAILS

The deliverable is the validation evidence and applies to each requirement and/or the set of requirements and to every validation method applied (if more than one). The validation evidence consists of:

• All of the details necessary to repeat the application of a validation method
• The output from the application of a validation method
• The disposition (valid, invalid) and rationale for the resulting validation

APPLICABLE METHODS AND EXAMPLES

The applicable methods are:

1. Method for Developing Requirements Validation Strategy.docx
2. Method for Validation by Review.docx
3. Method for Validation by Modeling, Analysis, or Simulation.docx
4. Method for Validation by Test.docx
5. Method for Validation by Similarity.docx

Time Domain Stability Analysis Example

This section shows an example of extracting the AC loop gain of a circuit from multiple time-domain simulation runs. The circuit in Appendix C will be used again, even though the circuit is linear and can be simulated with an AC sweep. This example is performed in LTspice, but the same methodology can be applied in other simulation tools. PSpice has similar functionality built in to V16.6, hotfix S017 and later.

A floating sinusoidal voltage source will be used to inject sinusoids of varying frequencies as shown in the following figure.

Click to enlarge

The amplitude of the sinusoidal source should be carefully selected to not introduce undesired nonlinear effects into the simulation, such as clipping. Multiple frequencies will be simulated by stepping the {Freq} parameter using the following SPICE directive:

.step d param F 1Meg 10

The simulation type is transient (time domain). Startup transients should not be included in subsequent calculations, and the simulation time should be long enough to capture several periods of the lowest frequency that will be simulated.

The circuit’s loop gain is simply the ratio of the complex amplitudes of V(A) and V(B). However, since this simulation is being done in the time domain, those amplitudes must be extracted from the simulation output. Starting with the voltage at node A, the time domain representation (not including DC bias) is

${\textstyle Va_{(}t)=|A|sin(2\Pi ft+\angle A)}$

Where f is the sinusoidal frequency and A is a complex phasor defined as

Failed to parse (syntax error): {\textstyle A=|A|ea^j∠A =|A| cos (∠A) +j|A|sin (∠A) }

In order to calculate the real component of A, first multiply the time domain representation by a sinusoid of the same frequency to get:

Failed to parse (syntax error): {\displaystyle va_A(t) \centerdot sin (2πft) =|A|sin 2πft+∠A sin 2πft ={|A| \over 2} ∠A -cos 4πft+∠A }

Averaging this signal over the simulation time eliminates the cos 4πft+∠A term, leaving (1/2) |A|cos⁡(∠A), or half the real portion of A. The imaginary part of A and the real/imaginary parts of B can be extracted in a similar fashion. This is shown in the following SPICE measurement directives:

.MEASURE A AVG 2*(V(a)-A)*x(100*time*Freq)
.MEASURE A AVG 2*(V(a)-A)*x(100*time*Freq)
.MEASURE B AVG 2*(V(b)-B)*x(100*time*Freq)
.MEASURE B AVG 2*(V(b)-B)*x(100*time*Freq)

These real and imaginary parts of A and B can then be used to calculate the loop gain magnitude and phase, as shown in the following SPICE directives:

.MEASURE gain PARAM 20*log(h(A) / h(B))
.MEASURE gain PARAM mod(a(A) - a(B) + 360)-180

After running the simulation, the loop gain magnitude and phase can be plotted by performing the following steps in LTspice:

1. Click “View”->”SPICE Error Log”.
2. Right click in the log window
3. Click “Yes” to write the data as complex.
4. Right click in the new plot window and select “Add Trace”
5. Select “gain” and click OK.

REFERENCES

None

REVISION HISTORY

Revision Letter	Revision Description	Applicable Section
-	Initial Release

COLLINS AEROSPACE PROPRIETARY. 
Subject to the restriction on the title or cover page. This document does not contain any export controlled technical data.