The UUT Description can define errors associated with the UUT, each of the components, as well as any Built In Test (BIT) Status Codes. As part of design the ten switches are incorporated that cause specific failures when switched on. For the demonstration there were no BiT Status Codes no defined.

The use of Errors is at best confused and as such will need to be 'clarified' for future standards, today all, errors, faults and failures can only be expressed in UUT under Errors. As an alternative view consider the following statement:

Errors should not be faults they were intended to be BIT errors or something similar not component faults.  Maybe the revised standard should consider adding another element under UUT Description, such as “Faults” or “Fault List”.

The hc:error descriptions contain type, ID, source and Description, but there is little guidance on

  • how to use and define an error associated with a hardware Item
  • Relate errors identified in the UUT Description with Faults and failures identified in the test description

In the example I copied the Errors from the TPS failures and faults which meant their ID were that of the original TPS, this made it difficult to read and track and lost information.

- <hc:Error type="Error" ID="c5f1" source="C1">
- <hc:Error type="Fatal" ID="J1-3 to R5">



The UUT Description uses the Control field to identify the Firmware to be loaded on the controller. We could have extended this description to also reference the software used to download the firmware and program the UUT but chose not to.

One aspect I thought we should be able to do and was not able to was define that the UUT had a RS232 bus or parallel digital port and could be communicated with. We can define this kind of information with Instrument Descriptions, but not with UUT description.

- <hc:Control>
- <hc:Firmwares>
  <hc:Firmware name="Firmware_-_Alpha_3_Release_(for_2010).zip" version="Alpha 3" qualifier="Min" />


UUT description has several requirement type fields

  • CalibrarionRequirements - a list of SupportEquipment and calibration c:Documents
  • OperationalRequirements- a named value list
  • EnvironmentalRequirements - provide limits for A ltitude, Humidly, Shock Temperature and Vibration in Operation and Storage/transport
  • PowerRequirements - AC or DC

The only real requirements used were the power requirements. And the point to notice is really how they differ from the Test Descripion in two ways

  1. They are with reference to pins whereas Test Description is with ports
  2. The value is described as a limit whereas Test Description can define multiple aspects of the power e.g. typical and max


In the example we define a basic DC voltage limit between 11.9V and12.1V and an operating current expect around 1.5A. In retrospect i probably should have defined the  Amperage as a single limit less than 2.2 A, but since you can only define one value I opted for the expected value.

- <hc:PowerRequirements>
- <hc:DC>
- <hc:Voltage>
- <c:Expected comparator="EQ">
- <c:Datum xsi:type="c:double" standardUnit="V" value="12.0">
- <c:ErrorLimits>
- <c:LimitPair operator="AND">
- <c:Limit comparator="GE">
  <c:Datum xsi:type="c:double" standardUnit="V" value="11.9" />
- <c:Limit comparator="LE">
  <c:Datum xsi:type="c:double" standardUnit="V" value="12.1" />
- <hc:Amperage>
- <c:Expected comparator="EQ">
  <c:Datum xsi:type="c:double" standardUnit="A" value="1.5" />
- <hc:ConnectorPins>
  <hc:ConnectorPin connectorID="J1" pinID="5" />
  <hc:ConnectorPin connectorID="J1" pinID="6" />