Signal Requirements
Signal Requirements provide an overview of all the signals needed to test the UUT. They represent the minimum set of signals needed so that a user or application can 'quickly' identify the type of signals and resources they may need to test the UUT. The core use-case for Signal Requirements comes from the TPS TRD documentation.
There are several 'potential' traps when using Signal requirements and Signal Operations, that are worth highlighting here
- A signal can only refer to a TSF Signal and not any basic signal e.g. Sinusoid or Measure. In the ATML demo signals were defined using a mixture of both. This is evident when comparing signals in Detailed Test Information Behavior and Signal Requirements, there may not be a one-to-one match.
- IEEE Std 1641 Signal Models, and therefore complex TSFs, do not necessarily fall into the specific role of Source, Sensor, Monitor or Load, where a signal uses mixed mode signals the priority in selecting roles should be Sensor, Monitor, Source, Load
- Not all TSFs support all attributes, note DC_DIGNAL can not define a maximum current, it needs to be combined with a Current Limit which is not then a TSF. One way around this is to build a UUT specific Signal Library. This is really a preferred approach, and can ensure that the Signal Requirements and test Description Signals always match and have the level of details required.
