ATML Test Description

1
ATML Test Description

• Santa Rosa, August 2006

2
Agenda

• Review changes in Draft 10
• Review results of evaluation by Indra
• Non-Test Action steps
• Parallel Tests - use cases
• Aggregate description of requirements
• Digital Bus Tests - feasibility with current
  schema
• Reference in ActionCompare the limits from a Test
  Result
• Other open issues, as time allows

3
Introduction

• Format for exchanging the test description
  information defining test performance, test
  conditions, diagnostic requirements, and support
  equipment to locate, align, and verify proper
  operation of a UUT.
• Purpose
• Support the development of TPSs that will be used
  in an automatic test environment
• Test Program generation
• Test Requirement Document development and
  maintenance
• Test Description analysis, etc.
• Promote and facilitate interoperability between
  components of ATSs where UUT test requirement
  definitions need to be shared.
• Ex. Rehosting test requirements between ATS
  platforms

4
Introduction

• Rehosting benefits
• Current TPSs are implemented with tight coupling
  between components. The components are typically
  developed specific to that particular
  architecture.
• Once the test program is fielded, the
  requirements and strategies used to initially
  develop the TPS typically become obsolete.
• As the ATS is replaced or achieves some level of
  obsolescence, it is typical to re-host the
  implementation of the TPS.
• This is a more expensive, time consuming task,
  than that if implementing the UUT test
  requirement on the newer Automatic Test Equipment
  (ATE) or as part of instruments replaced within
  the existing ATE.

5
Overview
6
Overview

• UUT Description
• UUT description by name and nomenclature
• Can be specified
• Inline - can we change the word?
• As reference to UUT Description instance document

7
Overview

• Changes in Draft 10
• Instance document either references UUT
  Description instance document, or contains the
  UUT description information (name, description,
  identification, physical characteristics). Change
  for coordination with UUT Description.
• PhysicalCharacteristics element moved from
  GeneralData to UUTDescription/Inline. To avoid
  duplication with similar data present in UUT
  Description schema.
• Added UUTDescription/Inline/Category. To support
  the TSR use case.

8
Overview
9
Overview

• Documentation
• References to all Documents, Drawings, Diagrams,
  Parts Lists associated with the UUT and its
  sub-assemblies (used to verify UUT operation).
• Theory of Operation
• Operating Instructions
• Test Strategy Report (TSR)
• FMECA
• Configuration Data, Drawings, etc.
• Documentation / Block Diagrams cardinality
  should be 0 1
• Support multiple documents for Operating
  Instructions (ex. for multiple languages)
• Create a new element of type document named
  Other cardinality 0 n.
• In written spec, add a rule for referencing
  external documents from free-form text fields
  reference by name attribute.

10
Overview
11
Overview

• General Data
• All of the General Data that may be of use in
  developing test scenarios
• Operational and Safety Requirements
• Power Requirements
• Special Electrical Components Tools

12
Overview

• Changes in Draft 10
• Added GeneralData / SpecialElectricalComponents
  and GeneralData / OperationalAndSafetyRequirements
  / AdjustmentAlignment. To support the TSR use
  case.

13
Overview
14
Overview

• Power Requirements

15
Overview

• Interface Requirements
• The characteristics of equipment and circuitry
  required to test the UUT, excluding the Test
  Equipment (e.g. UUT Connector information).
• Connectors
• Test Points
• EO Interfaces
• Fixtures
• Signal Conditioning

16
Overview

• Changes in Draft 10
• Results of coordination with UUT Description
• It is impossible to extend the interface-related
  types from Common
• Decided to leave a separate implementation in
  Test Description and to change it in order to
  improve consistency
• Changed MatingConnectorDescription element to
  string attribute matingConnectorType.
• Removed ReferenceDesignator child element. The
  designator attribute under Identification
  should be used for this purpose.
• Deleted element ConnectorDescription from
  ConnectorInformation type, as it had no
  additional contents. ConnectorInformation derives
  now directly from ItemDescription.
• Can we change Common now?

17
Overview

• Changes in Draft 10 (contd)
• Reorganized Connectors and Pins into a single
  hierarchical structure
• Combined Connector data in a single element under
  InterfaceRequirements
• Combined Fixture information in a single set of
  elements under InterfaceRequirements. For
  consistency.
• Flattened structure by moving Connectors,
  TestPoints, etc. under InterfaceRequirements.
• Replaced Pin/Identification with number
  attribute. For brevity.
• Replaced ReferenceDesignator child element of
  TestPoint with designator attribute. For
  terminology consistency with Connector.
• Deleted ConnectorPinGroups from
  InterfaceRequirements and moved pin references
  associated data to the definition of the type
  PortConnectorPinGroup. For simplification.

18
Overview

• Changes in Draft 10 (contd)
• Added child element DataAccess under Pin. To
  specify the command used to retrieve data from a
  virtual pin through firmware access (ex. JTAG)
• Deleted element PinDesignation from PinFunction
  type. The information is already accommodated by
  PinInformation/SignalInformation/SignalType
• Added usedForTest attribute under
  ElectroOpticalInterface and Fixture
• Renamed WireType to WireDescription and added
  annotation indicating that it may be use to
  specify wire type, wire size, etc.

19
Overview

• Interface Requirements

20
Overview

• Connector

21
Overview

• Connector / Pin Function

22
Overview

• Performance Characteristics
• Detailed description of the performance
  characteristics of the UUT.
• Inputs nominal values range tolerance
  characteristics
• Outputs nominal values range accuracy
  characteristics input-output relationships
• Controls range of control

23
Overview

• Changes in Draft 10
• Implemented details of complex type
  PerformanceCharacteristics according to
  description in Mil-Std-1519 Section 5.3
• Added _at_limitTo attribute to Range/Min and
  Range/Max
• Relative accuracy is expressed as ratio to
  nominal (not from nominal). This is described
  in annotation.
• Absolute relative accuracy are alternative (not
  additive).
• Control may be unnecessary, as Controls are in
  fact Inputs. Assess need during Candidate
  evaluation. Delete if not necessary.

24
Overview

• Performance Characteristics

25
Overview

• Performance Characteristics / Input

26
Overview

• Performance Characteristics / Output

27
Overview

• Performance Characteristics / Control

28
Overview

• Detailed Test Information
• All of the sufficient data for each UUT test to
  completely describe all input conditions and
  measurements required.
• Tests
• Parameters
• Test Results
• Outcomes
• Behavior,
• Test Groups
• Entry Points,
• Check if terminology for securityClassification
  is still consistent with Test Results

29
Overview

• Changes in Draft 10
• Deleted DetailedTestInformation /
  InitializationCondition. This is redundant.
  Initialization conditions can be included in the
  Initialization element of each Test Group
• Entry Point can now reference a Test Group a or
  Test

30
Overview

• Detailed Test Information

31
Overview

• Failure Fault Data
• UUT Design Fault Data (Faults and Failures)
• Failures
• Failure Mode
• Location (Connector / Pin)
• Faults
• Component
• Location (Pin)
• Failure Mode
• Failure Rate

32
Overview

• Changes in Draft 10
• Added Extension to RepairAction. Converted
  Description into element, as it may contain
  large amounts of text. The name attribute is
  now optional.

33
Overview

• Changes in Draft 10 (contd)
• FaultData/Components/Component inherits from
  ItemDescription. For coordination with Test
  Results.
• Added FaultFailureType_at_insertable. To support the
  TSR use case.

34
Overview

• Failure Fault Data

35
Overview

• Failure Fault Data / Failure

36
Overview

• Failure Fault Data / Fault

37
Overview

• ATPG
• All of systems level information sufficient to
  identify any Automatic Test Program Generation
  (ATPG) tool(s) (e.g. LASAR)
• Tools - translators, assemblers, or
  post-processors which may be used to derive a
  test program
• Data Formats - describe the format of data
  processed by the Tool (ex. DTIF, L200)
• Optional reference to compliance document
  applicable to the format (ex. IEEE 1445 DTIF)

38
Overview

• Changes in Draft 10
• Created tentative enhancements for the ATPG model
• Added description of data format supported by
  ATPG Tools and reference to compliance
  documentation (if applicable)
• Added ATPG as possible Behavior of Test

39
Overview

• ATPG

40
Detailed Test Information

• Detailed Test Information
• Test Groups
• Subtypes
• Sequence describes fault trees as sequence of
  steps
• Parallel, ...
• Contain calls to Tests
• Tests
• Describe stimuli, measurements, limits and
  behavior
• Behavior may be call to Test Group

Entry Point
Test Group
Calls (1 n)
Calls (0 1)
Entry Point
Test
41
Detailed Test Information

• Test
• Outcomes
• Outcome is a special output used for
  diagnostics (ex. sequencing)
• Parameters (inputs)
• TestResults (outputs)
• Check if terminology is consistent with Test
  Results schema
• Conditions (preconditions, postconditions)
• Behavior
• Free-form description
• Sequence of Actions
• Call to a Test Group
• Test generated by ATPG from data files
• User-defined

42
Detailed Test Information

• Changes in Draft 10
• Added Parameter/Reference element.
• The Parameter value is retrieved at run-time from
  an external document, instead of being specified
  in the Test Description instance document (or the
  test program). For coordination with Test
  Results.
• Enhanced Adjust model
• Possibility to specify action after Adjust
  (finish sequence return outcome, repeat test,
  execute a different step)
• Possibility to specify action if Adjust fails
  (finish sequence return outcome)
• Description can be specified for the overall
  Adjust operation and for adjusting individual
  components.
• See if keyref to state variable value can be
  splin in two. Do we still get validation.

43
Detailed Test Information

• Test

44
Detailed Test Information

• Test / Outcome

45
Detailed Test Information

• Test / Parameter

46
Detailed Test Information

• Test / Test Result

47
Detailed Test Information

• Test / Conditions

48
Detailed Test Information

• TestGroup
• Outcomes
• Optional diagnosed faults or failures
• Description of Parameters (inputs) and Test
  Results (outputs)
• Data type, unit, nominal value (optional)
• Conditions (preconditions, postconditions)
• No sure if these are still needed. Conditions can
  be specified for the Test that calls the Test
  Group. Question for Candidate evaluation.
• Open Issue do we want to support retrieval of
  state variables from the UUT? Maybe through an
  Action. See Anands proposal to add action for
  setting state variables the source of the value
  would be a measurement.
• Initialization Termination
• Execution of other Tests
• Free-form description
• Initialization test reference and free-form
  description should be alternative.
• Behavior
• Specific to each type of Test Group (sequence,
  parallel, etc.)
• Do we need multiple entry points inside
  TestGroupSequence? Question for Candidate
  evaluation.

49
Detailed Test Information

• Test GroupType (abstract base type)

50
Detailed Test Information

• TestGroupType / Outcome

51
Detailed Test Information

• TestGroupType / Initialization, Termination

52
Detailed Test Information

• TestGroupSequence

53
Detailed Test Information

• TestGroupSequence / Step

54
Detailed Test Information

• TestGroupSequence / Step / Adjust

55
Describing Test behavior through Actions

• Behavior is a linear sequence of Actions (no
  branches)
• Actions are signal operations defined by IEEE
  1641 Test Procedure Language (TPL)
• Setup - Create and setup a Signal
• Change - Change an existing Source signal
• Reset - Reset an existing signal
• Read - Measure attributes of an existing Sensor
  signal and creates a Measurement
• Compare - Compare a Measurement
• Connect - Create a Connection and connect an
  existing signal or a set of UUT pins
• Disconnect - Disconnect an existing Connection
• Enable - Enable event generation for an existing
  Monitor signal
• Disable - Disable event generation for an
  existing Monitor signal
• Wait For - Pause execution for the specified time
• Add actions for
• User Input (prompt description of user input
  what to do with it similar to mearurement
  result) Display Message - Anand
• possibly Repeat/Loop - Mark
• Under ActionSetup / Monitor, add choice Other,
  with free-form description of the condition that
  generates events - Ion
• Add action ActionOther, with free-form
  description of behavior Ion
• Add alternative for free-form behavior of Setup,
  Change, etc. - Anand

56
Describing Test behavior through Actions

• Actions reference signals created by other
  Actions
• Ex Reset a signal previously created by Setup
• Ex Disconnect a Connection previously created by
  Connect
• Parameters of Setup Change Action are signals
  defined in IEEE 1641 TSF (details later)
• Actions can be synchronized and gated through
  Monitor signals
• Signal-based (Ex signal attribute crosses a
  threshold)
• Time-based (Ex with a fixed period)
• Event-based (Ex From one event to another event)

57
Describing Test behavior through Actions

• Changes in Draft 10
• Added Timeout child elements to some Actions (as
  specified in 1641 TPS)
• Added Results/Result under ActionCompare. This
  establishes a connection between Compare
  results and Test Outcomes.
• Each Result element Identifies the Test Outcome
  to be returned for one result of the current
  Comparison.

58
Describing Test behavior through Actions
59
Describing Test behavior through Actions
60
Describing Test behavior through Actions
61
Describing Test behavior through Actions
62
Describing IEEE 1641 signals as Test parameters

• Test
• Parameter / Value
• Type StdSignalStimulus
• TestResult / ValueDescription
• Type StdSignalMeasurement
• TestGroupType
• ParameterDescription / ValueDescription
• Type StdSignalStimulusDescription
• TestResultDescription / ValueDescription
• Type StdSignalMeasurementDescription

63
Describing IEEE 1641 signals as Test parameters

• Changes in Draft 10
• Unified StdBscSignalStimulus and
  StdTsfSignalStimulus as StdSignalStimulus
• Unified StdBscSignalMeasurement and
  StdTsfSignalMeasurement as StdSignalMeasurement
• Created new types StdSignalStimulusDescription
  and StdSignalMeasurementDescription, for Test
  Groups
• For StdSignalStimulus, added support for
  referencing TSF signals from user-defined TSF
  Libraries, using cExtension

64
Describing IEEE 1641 signals as Test parameters

• StdSignalStimulus (derived from DatumType)
• Contents (alternatives)
• BSC signal definition
• Valid stimulus definition, including Source,
  Conditioning, Event and Connection BSCs, as
  applicable
• TSF signal definition conforming to 1641 TSF
  Library
• Valid stimulus definition
• TSF signal definition conforming to user-defined
  TSF Library
• Add support for referencing the XML files for
  extension TSF libraries. At a higher level, a
  mapping between XSD files (defining interface,
  required for validation) and XML files (defining
  behavior).
• This will change the way TSF libraries are
  referenced from StdSignalDescription,
  StdMeasurementDescription
• Usage
• Can be assigned to Test / Parameter / Value /
  Datum, to specify a stimulus signal as Test
  parameter

65
Describing IEEE 1641 signals as Test parameters

• StdSignalStimulus

66
Describing IEEE 1641 signals as Test parameters

• StdSignalStimulus - BSC signal definition

67
Describing IEEE 1641 signals as Test parameters

• StdSignalStimulus - TSF signal definition

68
Describing IEEE 1641 signals as Test parameters

• StdSignalStimulus - TSF signal definition
  referencing external TSF Library

69
Describing IEEE 1641 signals as Test parameters

• StdSignalMeasurement (derived from
  DatumDescriptionType)
• Contents (alternatives)
• BSC signal definition
• Valid measurement definition (intrinsic or
  generic), including Connection, Conditioning and
  Sensor BSCs, as applicable
• TSF signal definition conforming to 1641 TSF
  Library
• Valid measurement definition
• TSF signal definition conforming to user-defined
  TSF Library
• Usage
• Can be assigned to Test / TestResult /
  ValueDescription/ DatumDescription, to specify a
  signal measurement as Test Result

70
Describing IEEE 1641 signals as Test parameters

• StdSignalMeasurement

71
Describing IEEE 1641 signals as Test parameters

• StdSignalMeasurement BSC signal definition

72
Describing IEEE 1641 signals as Test parameters

• StdSignalStimulusDescription (derived from
  DatumDescriptionType)
• Contents (alternatives)
• STD signal (no description, just the tag)
• TSF signal
• TSF Library class name
• Usage
• Can be assigned to TestGroupType /
  ParameterDescription / ValueDescription to
  identify a 1641 signal as Test Group Parameter
• Note Does not provide a description for the
  signal.

73
Describing IEEE 1641 signals as Test parameters

• StdSignalStimulusDescription

74
Describing IEEE 1641 signals as Test parameters

• StdSignalMeasurementDescription (derived from
  DatumDescriptionType)
• Contents (alternatives)
• STD signal (no description, just the tag)
• TSF signal
• TSF Library class name
• Measured Attributes
• Usage
• Can be assigned to TestGroupType /
  TestResultDescription / ValueDescription to
  identify a 1641 signal as Test Group Test Result
• Note Does not provide a description for the
  signal

75
Describing IEEE 1641 signals as Test parameters

• StdSignalMeasurementDescription

76
Describing IEEE 1641 signals as Action parameters

• Note design not changed may want to change, for
  consistency with Test parameters
• StdTsfSignalStimulus
• Contents
• TSF class (TSF library class name)
• 0 n TSF class attributes
• Value (optional)
• Range (optional)
• Accuracy (optional)
• Connection (optional)
• Usage
• ActionSetup / Source / TsfSignalValue

77
Describing IEEE 1641 signals as Action parameters

• StdTsfSignalStimulus

78
Describing IEEE 1641 signals as Action parameters

• StdTsfSignalStimulus

79
Describing IEEE 1641 signals as Action parameters

• StdTsfSignalMeasurement
• Contents
• TSF class (TSF library class name)
• 1 n measured attributes (to be measured)
• Name
• Unit qualifier (optional)
• Nominal Value, Range, Accuracy (optional)
• 0 n TSF class attributes (measurement
  conditions)
• Nominal Value, Range, Accuracy (optional)
• Connection (optional)
• Usage
• ActionSetup / Sensor / TsfMeasurementDescription

80
Describing IEEE 1641 signals as Action parameters

• StdTsfSignalMeasurement

81
Describing IEEE 1641 signals as Action parameters

• StdTsfSignalMeasurement

82
Describing connections as Test parameters

• Connection (derived from DatumType)
• Contents
• 1 n Ports abstract base type PortType
• Each Port can be
• One connector pin derived type PortConnectorPin
• Group of n connector pins - derived type
  PortConnectorPinGroup
• One component pin derived type PortComponentPin
• Usage
• Child element of DCPowerRequirement and
  ACPowerRequirement
• Can be assigned to Test / Parameter / Value /
  Datum, to specify a connection as Test parameter

83
Describing connections as Test parameters

• Connection

84
Describing connections as Test parameters

• ConnectionDescription (derived from
  DatumDescriptionType)
• Contents
• Number of ports (optional)
• Usage
• Can be assigned to TestGroupType /
  ParameterDescription / ValueDescription/
  DatumDescription, to specify a connection as Test
  Group parameter
• The actual ports will be specified in the
  corresponding Parameter of the Tests representing
  calls to the Test Group

85
Describing connections as Test parameters

• ConnectionDescription

86
Describing connections as Test parameters

• Note definitions of IEEE 1641 connections are
  embedded in the signal definitions assigned to
  Parameters and Test Results
• Q Is there a need to support separate IEEE 1641
  connections as Test parameters?
• Note The type StdSignalConnection (see next) can
  be assigned to Test / Parameter / Value / Data.
  The feature only needs to be documented.
• Yes, because may be used in Connect actions. Also
  be able to refer connection Test Parameter from
  Connect Action Ion.

87
Describing connections as Action parameters

• StdSignalConnection
• Contents
• BSC signal definition
• Valid connection definition
• Usage
• ActionSetup / Source / TsfSignalValue / Datum (as
  StdTsfSignalStimulus) / Connection
• ActionSetup / Sensor / TsfMeasurementDescription
  / DatumDescription (as StdTsfSignalMeasurement) /
  Connection
• ActionSetup / Monitor / SignalBased /
  SignalConnection
• ActionConnect / Signal / SignalConnection
• ActionEnable / Connection

88
Describing connections as Action parameters

• StdSignalConnection

89
Describing connections as Action parameters

• StdSignalConnection

90
Describing transfers of parametric data to/from
Tests
Test Group
ValueFromTestGroupParameter
Parameter
Test
Parameter
Test
ValueFromTestResults
Test Result
Test
Parameter
Test Result
91
Describing transfers of parametric data to/from
Tests

• ValueFromTestGroupParameter
• Contents
• Reference to Test Group Parameter
• Usage
• Can be assigned to Test / Parameter / Value, to
  indicate that the value of the Test Parameter
  comes from a Parameter of the parent Test Group
• Note The actual value is specified for the Test
  whose Behavior specifies the Test Group call

92
Describing transfers of parametric data to/from
Tests

• ValueFromTestResults
• Contents
• References to 1 n Test Results
• Usage
• Can be assigned to Test / Parameter / Value, to
  indicate that the value of the Test Parameter
  comes from the Test Result(s) of other Test(s)
• Can be assigned to TestGroupType /
  TestResultDescription / ValueDescription, to
  indicate that the value of the Test Result comes
  from the Test Result(s) of Test(s) inside the
  Test Group
• Note If Test Results from multiple Tests are
  referenced, the value is obtained from the Test
  that was last executed

93
Describing transfers of parametric data to/from
Tests
94
Describing transfers of parametric data to/from
Actions
Test
ValueFromTestParameter
Parameter
Action
Signal, Attribute
Action (Read)
Measurement
Action
ValueFromActionMeasurement
Attribute
ActionRead / ValueToTestResult
Test Result
95
Describing transfers of parametric data to/from
Actions

• ValueFromTestParameter
• Contents
• Reference to Test Parameter
• Usage
• Can be assigned to ActionSetup / Source /
  TsfSignalValue to indicate that the signal
  description comes from a Parameter of the parent
  Test
• Can be assigned to TsfClassAttributeValue /
  Value, to indicate that the value of the
  attribute comes from a Parameter of the parent
  Test. TsfClassAttribute appears in
• ActionSetup / Source / TsfSignalValue (as
  StdTsfSignalStimulus) / TsfClassAttribute
• ActionSetup / Sensor / TsfMeasurementDescription
  (as StdTsfSignalStimulus) / MeasuredAttribute and
  TsfClassAttribute
• ActionSetup / Monitor / SignalBased /
  MonitoredAttribute and TsfClassAttribute
• ActionChange / TsfSignalValue (as
  StdTsfSignalStimulus) / TsfClassAttribute,

96
Describing transfers of parametric data to/from
Actions

• ValueFromActionMeasurement
• Contents
• Reference to Measurement
• Usage
• Can be assigned to TsfClassAttributeValue /
  Value, to indicate that the value of the
  attribute comes from a Measurement performed by
  another Action. TsfClassAttribute appears in
• ActionSetup / Source / TsfSignalValue (as
  StdTsfSignalStimulus) / TsfClassAttribute
• ActionSetup / Sensor / TsfMeasurementDescription
  (as StdTsfSignalStimulus) / MeasuredAttribute and
  TsfClassAttribute
• ActionSetup / Monitor / SignalBased /
  MonitoredAttribute and TsfClassAttribute
• ActionChange / TsfSignalValue (as
  StdTsfSignalStimulus) / TsfClassAttribute,
• Element ActionRead / ValueToTestResult indicates
  that the measurement result is transferred to a
  Test Result of the parent Test.

97
Describing transfers of parametric data to/from
Actions
98
Indra Evaluation

• 1. UUT is required to have at least one Connector
  with one Pin. Make this optional. Some
  applications (ex. Test executive) may not require
  an explicit description of the UUT Interface.
• OK. Feed back to UUT Description for consistency.
• 2. Test is required to have Behavior (at least as
  free-form text). Make this optional. Some
  applications (ex. test executive) may not require
  an explicit description of the Test Behavior.
• OK

99
Indra Evaluation

• 3. Test and Test Groups previous design was
  preferable. Instance documents are simpler. There
  may be a different solution for supporting Test
  Group Calls. José and Ion to discuss.
• Maybe discuss at ATC.
• 4. cstring has child element for data, while
  other types have attributes.
• The difference is by design. To accommodate
  larger amounts of data and impose less
  restrictions on contents.

100
Indra Evaluation

• 5. Octal values are required to start with a '0'
  (zero). There may be a problem with a leading
  zero when the number of digits is supposed to
  carry information about the word length (in this
  context octal 0110 is different from octal 110).
• Propose a change for 1671 revision?
• Propose change in Common, if still possible.
• 6. TestResult IDs and Outcome IDs are required to
  be unique throughout the document. This is
  cumbersome and may be unnecessary.
• Ion to review. Change scope if possible. If not,
  implement alternative solution (ex. two keys).
• Check if validation still works.
• 7. Other corrections

101
Digital Bus Tests

• Digital Tests with average complexity can be
  described using 1641 signals
• Generate one digital word, read one digital
  response (after programmable delay) and compare
  with expected value (including mask)
• Generate multiple digital words (with specified
  period), read digital responses (after
  programmable delay) and compare with expected
  values (including mask)
• Minor enhancements may be needed in 1641
  suggest for revision
• Bus Tests - TBD

102
Parallel Tests

• Analyze use cases

103
Non-Signal Action types

• See notes in previous slides.
• Sets state variables
• Looping
• Operator I/O
• Other sources of events for Action
  synchronization

104
Enhancement for Measurement Limits
Test
ActionCompare / MeasurementRef
Action (Read)
Measurement
Action (Compare)
Limits
ActionRead / ValueToTestResult
Test Result
Limits
105
Enhancement for Measurement Limits

• Enhancement Reference in ActionCompare the
  limits from a TestResult
• Multiple measurements / comparisons with separate
  limits
• Results of comparisons combined in a single
  Outcome
• Flexibility for the logical operation that
  combines Actions
• Note Test Results has something similar

106
Aggregate Description of Requirements

• Now exists for Power Requirements only
• May add for stimuli measurements
• Simplifies supporting the use case of matching
  TPS requirements with test station capabilities
• Should be optional not always available, may be
  difficult to obtain
• Ex. aggregating requirements for existing TPSs
  requires signal flow analysis

107
Open Issues

• Missing functionality
• Digital Tests
• Investigate use of Actions with 1641 digital
  signals
• Alternatively, may define specialized type
• Bus Tests
• Investigation needed
• Parallel Tests
• Use cases not discussed yet

108
Open Issues

• Functionality enhancements
• Change referencing of 1641 TSF signals in TPL
  Actions
• For consistency with referencing in Parameter and
  Test Result.
• Add support for Time Interval Measurement and
  Event Counter in Actions.
• This functionality is supported in IEEE 1641 TPL.
• Create composite action types
• Ex Apply Setup Connect Measure Setup
  Connect Read Verify Apply Measure
  Compare.
• Define Actions that are not signal-oriented
• Enhancement for measurement limits
• Add an entity equivalent to TestGroupAction.
• This may be a reduced version of Test, with a
  Done/Aborted Outcome. It would be member of Test
  Group (in which case it must be connected in
  sequence with other members).

109
Open Issues

• Functionality enhancements (contd)
• Support arbitrary parallel sequences of Test
  Actions.
• May want to implement for consistency with the
  specializations of Test Group.
• To be decided after the evaluation of the
  Candidate version.
• Add inter-conditions regarding execution of
  other Tests outcomes returned by other Tests,
  values of variables - if supported, etc.
• Note these conditions are meant to be checked at
  run-time and considered by reasoners when
  selecting a Test they are not meant to be
  fulfilled through automatic triggering of other
  Tests.
• Add support for variables.
• Note The main use case for this feature is
  exchanging test sequences between test
  executives. This use case is likely to face other
  serious limitations, because the models used by
  different test executives are significantly
  different.
• To be decided after the evaluation of the
  Candidate version.
• More (see Draft 10 Design Notes)

110
Open Issues

• Enhancement suggestion for IEEE 1641revision
• Include a set of rules that restrict the STD
  model that can be used when specifying a stimulus
  signal parameter, a signal measurement or a
  signal connection.
• The following should be defined
• Valid BSC-based stimulus definition, including
  Source, Conditioning, Event and Connection BSCs,
  as applicable
• Valid BSC-based measurement definition (intrinsic
  or generic), including Connection, Conditioning
  and Sensor BSCs, as applicable
• Valid BSC-based connection definition
• Valid TSF-based stimulus definition
• Valid TSF-based measurement definition

111
Referencing information in external documents

• Use cases
• Reference repair actions (already implemented)
• reference requirements
• Create type DocumentReference derived from
  cDocument, add 1n Tag child elements
• Add to Test, TestGroup, Repair (replacing current
  implementation)
• Add to Documentation elements that reference
  external documents with Requirements and
  RepairInstructions (to avoid repeated references
  from DocumentReference)

112
Manipulating signals created in other Tests

• Signals created by Actions are local to Tests
• There is a use case where power in applied in one
  Test and removed in a different Test
• Alternative 1 keep scope local, use non-Action
  mechanism to specify Test behavior (free form,
  ActionOther, )
• Alternative 2 make scope global this opens up
  the possibility to break Test encapsulation
• Keep as open issue during Candidate evaluation