# Triggers

Some of the users of this standard will only have the requirement to
sample or apply data occasionally and the timing of those samples is
relatively unimportant. However, There is that other class of users that
are trying to create or measure a waveform and the timing of the samples
is critical. In addition, in many cases not only is the waveform
important but the phase relationship between different signals can also
be critical. In the past these requirements were met by using a single
Analog-to-Digital Converter (A/D) or Digital-to-Analog Converter (DAC)
so that all of the timing was centralized and controlled from a common
clock. With the advent of inexpensive A/D converters it has become more
common to have multiple A/D converters in a system. With the capability
to co-locate these components with the transducer the problem arises of
how does the system control the timing of all of these diverse devices.
Triggers are one of the two mechanisms in the standard that are designed
to allow a single TBC and multiple TBIMs to operate together to meet
these timing requirements. The other mechanism is the synchronization
Communications channel. Since each transducer bus must have one TBC and
one or more TBIMs, it was felt that the responsibility of providing the
bus timing should reside primarily in the TBC. This would make the TBIMs
simpler and thus less costly.

Triggers can be addressed to a particular transducer in a TBIM, to group
of transducers or to all transducers on a bus. The use of group or
global triggers is the mechanism that is used to cause multiple TBIMs to
take action at the same instant. Just how close to the same time this
action is performed is a function of the design of the TBIMs. For
example lets suppose that we have a group sensors that are designed to
be able to acquire data at a maximum rate of 100 samples per second. If
we use two on these sensors on a bus that is 100 meters long the
difference in the propagation delays between the TBC and either of these
two sensors is roughly 600 nanoseconds. This is 0.006 % of the sample
interval. In most cases this would not be a significant error and could
be ignored. However, as the sample interval becomes shorter the
propagation delay becomes a more significant factor. Another application
that is very concerned about these delays is systems that are used to
measure transient events. In these systems this is an important
parameter. There are basically two ways to address this issue. Both
require that the propagation delay between the TBC and each TBIM be
known. The standard provides a mechanism that can be used to measure the
delay. See section ?? for the details of this mechanism. Once the
propagation delay is known the system can use this information and
attempt to correct for the differences using interpolation or the TBIMs
can be designed to correct for the propagation delay. The standard does
not dictate which method shall be used so it does not require that the
TBIMs be able to correct for the propagation delay. However, care was
taken to allow the TBIM manufacturer to be able to build this capability
into the TBIM if it is desired.

Triggers normally originate at the TBC and are always executed by the
TBIMs. The exception to the rule that triggers originate at the TBC is
that the output from an event sensor can be used as a trigger for other
TBIMs. When using an event sensor to generate a trigger it is generally
important to cause some action to take place or to take a snapshot of
the conditions that were in place at the time of the event. This means
that waveform analysis is probably not very important but the time of
the event may be desirable. For example an event might be a door
opening. This might trigger a video camera to take a picture of who was
in the door and transmit the picture to a central location. The time of
the door opening and the picture would be the two critical pieces of
information. In another scenario an event sensor might be used to detect
an alarm condition. The issuing of the event by the event sensor could
then be used by actuators in the system to perform an orderly shutdown
of the system and sensors used to capture the conditions that caused the
problem.

In control systems it is often required that a TBIM send some form of
information back to the TBC to indicate that the trigger was received
and acted upon. In many data acquisition applications the system user
will not want to use part of the system bandwidth to close the loop in
this fashion. The approach taken in the standard to satisfy both of
these needs is to require some triggers to be acknowledged and others
not to require it. All TBIMs are expected to be able to support both
sets of trigger commands.

## Trigger Commands

At this time there are five different trigger commands that the TBC can
issue. Each of these commands can add the requirement that an
acknowledgement be returned making a total of ten trigger commands. The
following list identifies the five basic commands.

-   trigger a transducer

-   write with trigger

-   trigger with read

-   trigger a group of transducers (Group Trigger)

-   trigger all transducers on a bus (Global Trigger)

### Triggering a single transducer

There are three variations on the capability to trigger a single
transducer. The command to trigger a transducer is the simplest form of
this command. The trigger with write and the read with trigger commands
are also used to trigger a single transducer. There will be cases where
it is desirable to trigger sets of transducers within a single TBIM
using one of these trigger commands. An example of this would be a
sensor and an associated time interval counter. In these cases
consideration should be given to the desirability of being able to
trigger the devices separately for troubleshooting and diagnostic
purposes.

#### Trigger a transducer

This trigger command is followed by a single argument that is the
logical address of the transducer to be triggered as assigned by the
system.

#### Trigger with write

This trigger command is a specialized type of trigger that can be issued
to an actuator. It has the advantage of only requiring a single command
to write a data set to the actuator and to trigger it.

#### Read with trigger

This trigger command is a specialized type of trigger that can be issued
to a sensor. It has the advantage of only requiring a single command to
trigger the sensor and to read a data set from it.

### Triggering a group of transducers

This class of transducers establishes the ability of the TBC to control
the activity of a group of transducers on a bus with a single command.
The transducer groups are defined by the system and thus require that
each TBIM have the capability to be programmed to respond to group
triggers. In fact the standard allows each transducer to be a member of
more than one group but does not specify how many.

### Global triggers

This class of transducers establishes the ability of the TBC to control
the activity of all transducers on a bus with a single command. Unlike
group triggers this capability is required to be inherent in all
transducers and is not programmable. To prevent a transducer from
responding to a global trigger the transducer must be disabled.

## Events used as triggers

Systems are expected to use the outputs of event sensors to trigger
transducers in several ways. There are three possible ways that this
capability can be implemented each with a different reason for being
required. However, one feature that is common to all three uses of
events as triggers is that they never require an acknowledgement. A
forth possibility exists but since it does not require any special
features in the TBIM it is not discussed in a separate sub paragraph.
That possibility is that the TBC receives the event and issues the
necessary triggers to cause whatever actions are required.

This is one of two cases in this standard where the possibility of
collisions on a communication channel is allowed. It is allowed here so
that the number of communications channels that are required in a system
with many event sensors does not become overwhelming. In all cases the
TBC must read the status in the event sensor that detected the event or
issue a command that clears the event. If the TBC fails to take action
the event sensor should retransmit after a time interval that is based
upon its assigned transducer number. This places all requirements to
detect collisions on the TBC.

### Any transmission

This is an area where it is desirable to have many event sensors on a
bus but not use a separate data transfer communications channel for each
one. In this type of application many event sensors will be capable of
transmitting on the same channel and collisions are possible or even
probable. However, regardless of what device is transmitting a single
predefined action is required for all devices programmed to be able to
be triggered in this fashion. In this case the TBIM is programmed to
accept any transmission above a minimum length on the data transfer
communications channel as a trigger. This includes garbled transmissions
that occur as the result of a collision. The requirement that it be over
a minimum length is to minimize the effect of noise on the receiver.

As an example of this type of operation consider a system that uses a
number of hydraulic rams to load up a large, expensive structure like an
airplane wing. Each hydraulic ram is controlled by a separate actuator
and each has an associated event sensor that is used to detect when the
hydraulic ram is not responding properly and that the entire system
should be shut down immediately. Failure to shut it down immediately
could cause injury to operating personnel or damage to the test
specimen. A single data transfer communications channel could be
designated to be used by many event sensors as their output data
channel. In this case it is not immediately important to know which
device is causing the problem. The TBC can be used to read the status of
each event sensor to determine which device caused the alarm and
possibly when after the system is placed into a safe condition.

### Any valid transmission

This case is similar to the previous case except that the transmission
must be valid, i.e. the Format Check Sequence in the message must be
correct. The source address is not used to determine if the TBIM should
respond to this transmission. In this case if a collision occurs it is
the responsibility of the TBC to determine which event sensor detected
an event and to issue the appropriate trigger command on a different
communications channel. This approach will result in less false events
at the expense of response time. It should be used where not getting a
false indication of an event is more important than response time.

### A valid transmission with a specific source address

When only one event sensor is assigned to a given data transfer
communication channel or when there is little likely hood of multiple
event sensors detecting events at the same time then this method of
detecting an event used as a trigger can be used. It provides as much
protection as possible against false triggers.

## Transducer Trigger logic

Figure 1 and Figure 2 are taken directly from the standard. Table 1 is
derived from the standard. Figure 1 is a functional block diagram of the
trigger logic in a simple TBIM. Figure 2 is similar to Figure 1 except
that it shows a more complex device. Other logic is omitted for
simplicity in both figures. Table 1 gives an explanation of each of the
blocks in Figure 1 and Figure 2.

![](media/image1.wmf){width="5.504166666666666in"
height="2.691666666666667in"}

Figure 1 Simple transducer functional blocks

![](media/image2.wmf){width="5.566666666666666in"
height="5.566666666666666in"}

Figure 2---Complex transducer functional blocks

Table 1---Transducer Functional Blocks

  ----------------- -----------------------------------------------------
  **Function**      **Description**

  Data Transport    Data transport is a separate function that is
                    discussed in sub-clause ??. Triggers can be received
                    from the Bus Management, the TBIM or the Trigger
                    communications channels. Triggering may or may not be
                    possible during data transport depending upon the
                    number of communications channels in the TBIM.
                    Commands to alter the state of the machine, such as
                    "abort trigger" or "initialize transducer," are
                    received using the data transport.

  Time Delay        In some systems with stringent requirements for
  Virtual Actuator  simultaneous processing of inputs or outputs it may
                    be necessary to place a programmable delay between
                    the time the trigger is sensed by the Data Transport
                    Logic in the TBIM and when it actually takes effect.
                    This actuator provides for this capability. A virtual
                    actuator is recommended to be used to control the
                    delay. The use of a virtual actuator instead of a
                    control command allows TEDS to contain the
                    description of the delay logic and removes some of
                    the requirements for the system to know the
                    characteristics of the delay logic. This is one of
                    three blocks that are shown in Figure 2 but not
                    Figure 1.

  Transducer Logic  This logic contains the signal conditioning, data
                    conversion logic and buffering logic for the
                    transducer.

  Sample Control    This function is part of the transducer but for the
  Generator Logic   purposes of this standard it is treated as a separate
                    state machine. See Figure 4 and Table 3 for details
                    of operation. The Sample Control Generator logic may
                    be part of one or more transducers depending upon the
                    operating modes and design requirements of the TBIM.

  Time Interval     This is a separate transducer with a special
  Sensor            relationship to the transducer being described. As
                    shown in Figure 2 it is initialized by the trigger
                    signal for the transducer and triggered by the Sample
                    Processed signal from the transducer. Except for
                    possible diagnostic modes it does not receive
                    triggers directly from the data transport. Although
                    the standard does not prohibit the use of both a Time
                    Interval sensor and a Time-of-Day sensor it is
                    unlikely that both would be used in the same TBIM.
                    This is one of three blocks that are shown in Figure
                    2 but not Figure 1.

  Time--of-Day      This is a separate transducer with a special
  Sensor            relationship to the transducer being described. It is
                    triggered by the Sample Processed signal from the
                    transducer. Except for possible diagnostic modes it
                    does not receive triggers directly from the data
                    transport. Although the standard does not prohibit
                    the use of both a Time Interval sensor and a
                    Time-of-Day sensor it is unlikely that both would be
                    used in the same TBIM. This is one of three blocks
                    that are shown in Figure 2 but not Figure 1.
  ----------------- -----------------------------------------------------

#### Triggering a sensor

The trigger signal causes a sensor to execute a process to collect a
data set. The actual time that each sample is acquired can be determined
by the TBC using information acquired from the TBIM. If the time between
the trigger and the acquisition of the first sample is constant, within
acceptable limits, then this value and its uncertainty can be in the
transducer specific TEDS (*specify name & field number when it is
known*) (Action Item -- trig #2). If the time between the trigger and
the acquisition of the sample is variable then a Time Interval Sensor in
the TBIM may be used to determine the time difference between the
receipt of the trigger and the acquisition of the sample. The TBC or
another processor may compute the sample time from the time that the
trigger was sent to determine the actual time that the sample was
acquired. An alternate method of determining the time of a sample is to
use a time-of-day sensor that can store the time of day that the sample
was taken. If a Time Interval Sensor or time-of-day sensor is used to
determine the sample time there should be one cycle count or time value
for each data sample in the data set. This requirement would not be
necessary if the units on the sample interval was always seconds but
that is not the case. This requirement is to make the operation of the
system consistent regardless of the units on the sample interval. If the
user knows that there is a uniform time between samples the choice can
be made to read only the first time value and add the sample interval to
that value for each subsequent sample. The Time Interval Sensor and
time-of-day sensor are in a special class of sensor in their operation
is slaved to the operation of the another transducer. They require a
separate transducer number and respond to separate read commands. See
subclause 1.3.2 for more details on this subject.

[If a trigger acknowledge is required by the trigger command, the TBIM
shall send a trigger acknowledgment coincident with the time the first
sample in a data set is acquired. Subsequent to this trigger acknowledge
and the additional duration specified by the Transducer Read Setup Time,
plus the sample interval times the number of samples in the data set
minus one the data set shall be available to the TBC. The Transducer
Read Setup Time is specified in the Transducer Specific TEDS (*specify
field number when it is known*).]{.mark}

[NOTE\-- The preceding paragraph is a holdover from dot 2 and it is very
clumsy. Having the trigger acknowledge occur after the first sample
doesn\'t leave a good way to determine when the data set is complete
particularly if the sample interval is not time related. How do we want
to address this????]{.mark}

Irrespective of the time needed to read the transducer data, the TBC
must wait for at least the duration of the Transducer Sampling Period
between successive triggers. The standard does not specify what should
happen if this requirement is violated. However, in the interest of
consistent behavior it is probably best that triggers that are received
before the sensor completes the collection of the data set required by
the previous trigger should be ignored. If they are not ignored the
question of what to do with the data set that was started by the
previous trigger needs to be answered. In addition what to do with any
associated Time Interval or Time-of-Day sensors needs to be answered. If
the sensor has the buffered attribute active then the answer could be
just to switch to the next buffer after completing the data set
presently being collected. However, if the early trigger is a result of
a timing error in the system the problem will still occur when the third
trigger is received before the data set collection is complete for the
previous two triggers. If this mode of operation is desirable a
streaming mode sensor should be used. The Transducer Sampling Period is
in the Transducer Specific TEDS.

#### Triggering an event sensor

An event is defined as a transition of state. A trigger normally arms an
event sensor to detect a single occurrence of an event. If the streaming
attribute is set in the event sensor then the first trigger arms the
event sensor to report all events that are detected by the device. The
trigger acknowledgement is used to notify the system, through the TBC,
that an event has occurred. If a trigger command is used which does not
require an acknowledgement then the TBC must poll to determine if an
event has occurred. The acknowledgement consists of a single frame of
data transmitted from the TBIM to the TBC. As a minimum the frame of
data will contain the source address of the event sensor. The frame may
include other data such as the output of an associated Time Interval or
Time-of-Day sensor. The TBC must then acknowledge the receipt of the
event by performing a status read ?? to the logical address of the event
sensor. If the event sensor fails to receive the status read command
within a fixed period of time it shall retransmit the acknowledgement.

[We need to do more work on this acknowledge/ retransmit and the timing
because it is not defined anywhere.]{.mark}

If the TBIM does not use a Time Interval Sensor or a Time-of-Day Sensor,
and the time of the event is desired, then the TBC must be able to
detect the time of arrival of the frame of data and use that to
determine the time of the event. In this case, the TBIM must have
immediate access to a communications channel otherwise variations in the
time of arrival of the signal at the TBC will occur. This communications
channel must be reserved for this one task at the time of the event. In
Tier 0 or Tier 1 systems using an event sensor in this manner limits the
availability of the transducer bus when an event sensor has been
triggered until the acknowledgement is received.

An enabled event sensor sets the transducer data/event status bit
(Action Item - trig #12) whenever an event is detected regardless of
whether or not it has been armed by a trigger. The transducer missed
data or event status bit (Action Item - trig #11) is set when an event
is detected if a trigger has not armed the event sensor. The exception
is that the transducer missed data or event status bit shall not be set
until after the first trigger cycle after it is cleared.

#### Triggering an actuator

For an actuator without the buffered attribute set the trigger command
causes an actuator start a process that applies the last data set
received to its output. If a trigger acknowledge is required the
acknowledgement is sent when the first sample in the data set is applied
to the output. For actuators that have a single sample in the data set
this process is to apply the sample to the output and send the
acknowledge if it is required. For devices with larger data sets the
process is more complex. In most cases the actuator will apply the first
sample in the data set and return the acknowledgement if it is required
and then wait for a time interval. This time interval is specified in
the series increment field of the transducer specific TEDS. When the
time interval has elapsed, it will apply the next sample in the data set
and again wait for the specified time interval. This operation will
continue until all data samples in the data set have been applied to the
output. What happens next is a function of the End of Data Set
attribute. If this attribute is set to HOLD then the actuator will
simply wait until the next trigger is received. If this attribute is set
to RECIRCULATE then the unit will wait for the time interval specified
in the series increment field and then reissue the first data sample in
the data set. This process will continue until another data set is
received followed by another trigger. However, the standard does not
require the series increment field in the Transducer Specific TEDS to be
in units of time. It is actually in the units specified in the series
units field of the same TEDS. This makes the possible operation even
more complicated. With time the units may only increase but with many
other units they may increase or decrease. So if, for example, the
series units were degrees Kelvin then it would be possible to move
backwards and forwards through the data set. In this case the
acknowledgement would still be sent when the first sample in the data
set was applied to the output. In cases like the one just described the
actuator may move back and forth within that data set until it is
disabled. In other cases it will eventually get to the end of the data
set and it will be desirable to issue another data set before continuing
operation. However, there is no mechanism within the standard
specifically set up to alert the TBC when the TBIM has applied all or
most of a data set and requires more data. The designer of this type of
TBIM has some choices available. A virtual event sensor could be used to
notify the TBC that the data set has been used and new data is required.
Another possibility is that a virtual sensor could be used to monitor
where in the data set the actuator is operating and the TBC can decide
by reading this sensor when a new data set is required. It is also
possible that a new data set will never be required and that problem can
be ignored.

It is also possible to have an actuator that has a built in data set. A
simple example would be a display that was to be incremented by one for
each trigger that was received. In this case the trigger could be used
to increment a counter and no data set would be required. The Channel
Data Repetitions field in the Transducer Specific TEDS for this actuator
would need to be set to zero. A more complex example could be an
actuator that was to be used to cause a device to go through an
emergency shutdown procedure. The necessary steps to shut down the
system could be permanently stored in the actuator and each time a
trigger was received the procedure would be followed to shut down the
device. For devices without a data set received from the TBC the
acknowledgement should be issued immediately after the trigger is
recognized if it is required.

Irrespective of the time needed to write the transducer data, the TBC
must wait for at least the duration of the Transducer Sampling Period
between successive triggers. The Transducer Sampling Period is in the
Transducer specific TEDS (Action Item - trig #6). The standard does not
specify what should happen if a trigger is issued before the actuator is
ready to receive another trigger. The discussion on this topic in
subsection 1.3.1.1 is relevant here as well.

### Determination of the time of a sample

The determination of when a sample was taken in the case of a sensor or
applied in the case of an actuator (i.e. a sample is processed) is
shared between the TBC and the TBIM. The TBC knows the time that the
trigger was issued. The TBIM will determine the time difference between
when it receives the trigger and when the sample is processed or
determine the time of day when the sample was processed and can provide
this information to the TBC. If the TBIM supports this capability it can
be accomplished in one of three ways. If the time delay is constant then
the Transducer Specific TEDS entry that defines the fixed delay between
the receipt of a trigger and the start of processing (see subclause ??)
may be used to define the time difference between the trigger and the
time the sample was processed. The second method is to use a Time
Interval sensor as described in subclause 1.3.2.1. The third method is
to use a Time-of-Day sensor as described in subclause 1.3.2.2. An
enumeration in the Transducer Specific TEDS (see subclause ??)
identifies which method is being used by a TBIM.

[The enumeration has four possible values as shown in Table 2. The
single precision real field is required to define the period of one
cycle of the clock when enumeration 1 is used. The operation with
enumeration's 2 and 3 require a virtual sensor to provide the same
information as the TEDS field does for enumeration 1. For enumeration 4
the TBIM provides the time of day that the sample was taken.]{.mark}

[Table 2]{.mark}---Enumeration of sample time sources

+---------+------------------------------------------------------------+
| **[V    | **[Function]{.mark}**                                      |
| alue]{. |                                                            |
| mark}** |                                                            |
+---------+------------------------------------------------------------+
| [0]     | [No facilities in the TBIM are available to support        |
| {.mark} | determination the time that a sample was                   |
|         | processed.]{.mark}                                         |
+---------+------------------------------------------------------------+
| [1]     | [The time interval between the receipt of the trigger and  |
| {.mark} | the processing of the sample is not measured. The default  |
|         | delay between the trigger and the processing of the sample |
|         | is found in field xx of the transducer specific            |
|         | TEDS.]{.mark}                                              |
+---------+------------------------------------------------------------+
| [2]     | [The time interval between the receipt of a trigger and    |
| {.mark} | the processing of the sample is measured using a Time      |
|         | Interval Sensor. The Calibration TEDS for the Time         |
|         | Interval Sensor will provide the method of converting the  |
|         | output of the virtual sensor to time.]{.mark}              |
+---------+------------------------------------------------------------+
| [3]     | [The time interval between the receipt of the trigger and  |
| {.mark} | the processing of the sample is measured using a Time      |
|         | Interval Sensor with a clock derived from the              |
|         | synchronization communications channel and made available  |
|         | to the TBC using a virtual sensor. The Calibration TEDS    |
|         | for the Time Interval Sensor will provide the method of    |
|         | converting the output of the virtual sensor to             |
|         | time.]{.mark}                                              |
+---------+------------------------------------------------------------+
| [4]     | [A Time-of-Day Sensor supplies the time of day that the    |
| {.mark} | sample was processed. The characteristics of this sensor   |
|         | are defined in the TEDS for this sensor.]{.mark}           |
+---------+------------------------------------------------------------+
| [5 --   | [Reserved]{.mark}                                          |
| 127]    |                                                            |
| {.mark} |                                                            |
+---------+------------------------------------------------------------+
| [128 -  | [Available for use by manufacturers.]{.mark}               |
| 255]    |                                                            |
| {.mark} | [Note---The use of these enumeration\'s will affect the    |
|         | interoperability of the transducer. Special software will  |
|         | be required in the system to use it.]{.mark}               |
+---------+------------------------------------------------------------+

Action Item - trig #1 (TEDS Subgroup) Provide a TEDS entry for the
enumeration defined in Table 2.

Action Item - trig #2 (TEDS Subgroup) Provide a TEDS entry to define the
default time interval between the receipt of a trigger and the
acquisition of a data sample.

#### Time Interval Sensor operation

A Time Interval Sensor is a sensor as described in subclause 4.3.2 with
the \"Trigger Initiated\" attribute set but it has some other special
characteristics. Figure 3 is a derivative of Figure 2 showing the
differences. The trigger that is issued to another transducer, shown as
the primary transducer in Figure 3, within the same TBIM initializes a
Time Interval Sensor and starts it running. The Sample Control Generator
function becomes a pass through function that converts the Sample
Processed signal from the primary transducer into the Initiate an
Operation signal in the Time Interval sensor. The use of a separate
transducer address for the Time Interval Sensor is to allow it to have a
different set of TEDS. A trigger issued to the Time Interval Sensor\'s
transducer address from the transducer bus would only be used for this
device in a system diagnostic mode.

![](media/image3.wmf){width="6.004166666666666in"
height="4.816666666666666in"}

Figure 3---Time Transducer Functional Blocks

##### Determination of the Sample Time using the Time Interval Counter

If the Time Interval Sensor is used to determine the time a sample was
processed, there should be one time interval value for each data sample
in the data set. If the interval between samples in the data set is a
uniform time interval only the first time is required. However, the
standard allows for the interval to be in units other than time and in
these cases a time interval sample is required for each sample in the
data set. In the interest of always working the same way a time interval
sample is required for each sample in the data set. A Calibration TEDS
that defines how to convert the output of the counter to a time interval
and the uncertainty for this measurement may be used. To convert this
information to the time that the sample was taken requires knowledge of
when the trigger was issued. This information is known by the TBC. The
processing of a sample implies when the sample was taken for a sensor or
when it was applied in the case of an actuator.

NOTE---Assuming the use of a Time Interval sensor with the data set for
a transducer the following process could be used to determine the time
any sample in the set was processed assuming the triggers are not
periodic.

T~∆~ is the counts measured by the interval counter.

T~t~ is the time of the trigger that initiated processing of the buffer.

m is the constant used to convert the counts from the Time Interval
Sensor to time.

T~s~ is the time of day when the sample was processed. (It could be
local time, GMT or whatever the user wants.)

$$T_{s} = T_{t} + m \ast T_{\Delta}$$

This process requires that the TBC remember when each trigger is issued
and to be able to correlate them with the buffer being read.

Assuming the use of a \"Virtual\" sensor with the data set for the Time
Interval Sensor the following process could be used to determine the
time any sample in the set is processed assuming the triggers are
periodic.

T~i~ is the time interval between triggers. (For an unbuffered
transducer T~i~ would be = 0.)

T~∆~ is the counts measured by the interval counter.

T~t~ is the time of the most recent trigger.

m is the constant used to convert the counts from the Time Interval
Sensor to time.

T~s~ is the time of day when the sample was processed.

$$T_{s} = T_{t} - T_{i} + m \ast T_{\Delta}$$

This process only requires the TBC to remember the time of the most
recent trigger.

#### Time-of-Day Sensor operation

A Time-of-Day Sensor is a sensor as described in subclause 4.3.2 with
the \"Free Running\" attribute set but it has some special
characteristics. Figure 3 is a derivative of Figure 2 showing the
differences. The trigger that is issued to another transducer, shown as
the primary transducer in Figure 3, within the same TBIM is ignored by
the Time-of-Day sensor because it is free running. The Sample Control
Generator function becomes a pass through function that converts the
Sample Processed signal from the primary transducer into the Initiate an
Operation signal in the Time-of-Day sensor. The use of a separate
transducer address for the Time-of-Day Sensor is to allow it to have a
different set of TEDS. A trigger issued to the Time-of-Day Sensor\'s
transducer address from the transducer bus would only be used for this
device in a system diagnostic mode.

##### Determination of the Sample Time using a Time-of-Day Sensor

If the Time-of-Day sensor is used to determine the time a sample was
processed, there shall be one time recorded for each data sample in the
data set.

NOTE---A time-of-day sensor measures the term T~s~ in the note for
subclause 1.3.2.1 directly using some method that is beyond the scope of
this standard.

### Triggering a transducer

The following subclauses describe the expected functionality for the two
blocks within the dotted line in Figure 1 or Figure 2 labeled
\"Transducer.\"

#### Sample Control Generator Logic

Figure 4 and Table 3 give a description of the Sample Control Generator
Logic state machine. The Initialize state is the default state for this
machine. The state machine stays in this state until it the Enable
Command or Start Generator signal causes it to advance to the Running
State. When advancing to the running state with the \"Trigger
Initiated\" attribute set it will issue an \"Initiate an Operation\"
signal. In the Running State it will wait until the conditions required
for operating on another sample are met and then issue another
\"Initiate an Operation\" signal. The conditions for operating on
another sample will normally be an elapsed time but variables other than
time are allowed by the standard.

![](media/image4.wmf){width="5.191666666666666in"
height="2.191666666666667in"}

Figure 4---Sample Control Generator State Machine

Table 3---Sample Control Generator State Machine description

+----------------+--------+--------------------------------------------+
| **Entity**     | **     | **Definition**                             |
|                | Type** |                                            |
+----------------+--------+--------------------------------------------+
| Initialize     | State  | In this state the clock is started. If the |
|                |        | "Free Running" attribute is set it occurs  |
|                |        | when the sensor is enabled. If the         |
|                |        | "Trigger Initiated" attribute is set each  |
|                |        | trigger restarts it.                       |
+----------------+--------+--------------------------------------------+
|                |        |                                            |
+----------------+--------+--------------------------------------------+
| Running        | State  | In this state the "Initiate an Operation"  |
|                |        | signal is sent to the Transducer Logic     |
|                |        | each time the sampling criterion is met.   |
+----------------+--------+--------------------------------------------+
| Enable or      | Con    | If the Free Running attribute is set this  |
| Start          | dition | transition takes place when the transducer |
| Generator      |        | is enabled. If the Trigger Initiated       |
|                |        | attribute is set then the Start Generator  |
|                |        | (Delayed Trigger) signal causes this       |
|                |        | transition.                                |
+----------------+--------+--------------------------------------------+
| Start Running  | Action | The state machine goes to the running      |
|                |        | state.                                     |
+----------------+--------+--------------------------------------------+
| Issue Initiate | Action | The Initiate an Operation signal is sent   |
| an Operation   |        | to the Transducer logic.                   |
| signal         |        |                                            |
+----------------+--------+--------------------------------------------+
| Sample         | Con    | The conditions for issuing an Initiate an  |
| Condition Met  | dition | Operation signal have been met.            |
|                |        |                                            |
|                |        | Note---In most cases this will mean a time |
|                |        | interval has elapsed, however units other  |
|                |        | than time maybe used to control the        |
|                |        | interval between samples.                  |
+----------------+--------+--------------------------------------------+

#### Transducer Logic States

Figure 5 and Table 4 give a description of the Transducer Logic state
machine. The quiescent state is common to all transducer types. The Data
Set Processing State however is different for each different transducer
type. See subclause ?? through ?? for details of the operation in the
Data Set Processing State for the different transducer types.

![](media/image5.wmf){width="5.066666666666666in"
height="2.066666666666667in"}

Figure 5---Transducer Logic States

Table 4---Transducer Logic State Machine description

  ----------------- ----------- --------------------------------------------
  **Entity**        **Type**    **Definition**

  Quiescent         State       This is the state that the transducer will
                                enter after initialization.

  Data Set          State       This is the state of the transducer logic
  Processing                    that processes the data. This state machine
                                is different for each different transducer
                                type.

  Disabled and      Condition   The transducer is disabled and a trigger is
  Trigger Received              received

  Acknowledge       Action      The trigger acknowledge is sent to the data
  Trigger                       transport logic to be transmitted to the
                                TBC.

  Abort or Disable  Condition   An Abort command or a Disable Command has
  Received                      been received while in the Data Set
                                Collection state machine. The Data Set
                                Collection state machine is exited and the
                                transducer returns to the quiescent state.

  Issue Stop        Action      The Stop signal is issued to the Sample
                                Control Generator logic.

  Delayed Trigger   Condition   The transducer has received the trigger. The
  Received                      machine moves to the data set processing
                                state.

  Initialize Data   Action      Initialize Data Set Processing signal is
  Set Processing                sent to the data set processing state
                                machine.
  ----------------- ----------- --------------------------------------------

##### Data Set Processing State Machine for a Sensor

Figure 6 and Table 5 give the response of a sensor to a trigger. The
operations in the Data Set Collection state in response to operational
commands, such as disable transducer or abort trigger that interrupt
normal operation, are recognized but not defined in this standard. The
TBIM shall return to the quiescent state after receiving a command that
interrupts normal operation. The availability of partial data sets and
access to those data sets are the responsibility of the TBIM
manufacturer.

[Action Item - trig #20 - How do we handle partial data sets.]{.mark}

Figure 6 is intended to help in the description of the functions the
standard expects in a sensor. The standard does not require that the
functions must be implemented as implied in the diagram.

![](media/image6.wmf){width="5.66875in" height="4.629166666666666in"}

Figure 6---Data Set Processing States for a Sensor

Table 5---Data Set Processing State Machine Description for a Sensor

  ----------------- ----------- --------------------------------------------
  **Entity**        **Type**    **Definition**

  Wait for Clock    State       This is the state that the Data Set
                                Processing machine will enter after
                                initialization.

  Sampling          State       In this state the data is being sampled

  Converting        State       In this state the data is being digitized
                                and converted to put it into the final
                                output form.

  Sample Signal     Condition   The Sample Signal has been received from the
  Received                      Sample Signal Generator

  Acquire Sample    Action      The state machine advances to the sampling
                                state.

  Sample Acquired   Condition   The process of acquiring a sample of the
                                input is complete.

  Acknowledge       Action      The trigger acknowledge signal is sent to
  Trigger                       the data transport logic and the state
                                machine advances to the converting state.

  Sample Converted  Condition   The sample has been digitized and converted
                                to the final output form.

  Store Converted   Action      The data sample is stored in the appropriate
  Sample                        location and the machine advances to the
                                Wait for Clock state
  ----------------- ----------- --------------------------------------------

Irrespective of the time needed to read the transducer data, the TBC
shall wait for at least the duration of the Transducer Sampling Period
between successive triggers. The Transducer Sampling Period is in the
Transducer Specific TEDS.

##### Data set processing state machine for an event sensor

The state diagram in Figure 7 illustrates the normal behavior of the
Data Set Processing State Machine for an event sensor. Table 6 is
intended to help in the description of the functions the standard
expects in an event sensor. The standard does not require that the
functions must be implemented as implied in the diagram.

![](media/image7.wmf){width="5.91875in" height="2.441666666666667in"}

Figure 7---Data set processing states for an event sensor

Table 6---Data set processing state machine description for an event
sensor

  ----------------- ----------- --------------------------------------------
  **Entity**        **Type**    **Definition**

  Disarmed State    State       This is the quiescent state for this state
                                machine. It enters this state during the
                                initialization state and remains in this
                                state until the Delayed Trigger is received.

  Wait for the      State       In this state the machine is waiting for the
  Event                         event to occur.

  Event Happens     Condition   The logic within the state machine
                                determines that an event has occurred.

  Issue Sample      Action      The Sample Processed signal is issued to any
  Processed                     associated Time Interval or Time-of-Day
                                sensors to cause a time stamp to be
                                acquired.

  Acknowledge       Action      The trigger acknowledge signal is sent to
  Trigger                       the data transport logic.

  Data Set Complete Condition   The data set complete conditions have been
                                met. This is probably the same as Event
                                Happens in most applications. However, if
                                the Streaming attribute or the Buffers
                                attribute is set this will change this
                                condition.

  Disarm the Event  Action      Return the state machine to the Disarmed
  Sensor                        State.

  Delayed Trigger   Condition   The delayed trigger is received.

  Arm the Event     Action      Move the state machine to the Wait for Event
  Sensor                        state.
  ----------------- ----------- --------------------------------------------

##### Data set processing state machine for an actuator

Figure 8 and Table 7 give the response of an actuator to a trigger. The
operations in the Data Set Processing state in response to operational
commands, such as disable transducer or abort trigger that interrupt
normal operation, are recognized but not defined in this standard. The
TBIM shall return to the quiescent state after receiving a command that
interrupts normal operation.

![](media/image8.wmf){width="6.10625in" height="4.784722222222222in"}

Figure 8---Data Set Processing States for an Actuator

Table 7---Data Set Processing State Machine Description for an Actuator

  ----------------- ----------- --------------------------------------------
  **Entity**        **Type**    **Definition**

  Converting        State       This is the state that the Data Set
                                Processing machine will enter after
                                initialization.

  Wait for Clock    State       In this state the machine is waiting for the
                                Initiate an Operation signal.

  Outputting        State       In this state the data is being output

  Sample Converted  Condition   The Sample has been converted to the form
                                required for the output.

  Initiate an       Condition   The process of acquiring a sample of the
  Operation                     input is complete.

  Output Sample     Action      The sample is being output.

  Sample Output     Condition   The sample has been output.

  Recover the next  Action      The next sample in the data set is recovered
  sample                        from storage or the Data Transport logic.

  Acknowledge       Action      The trigger acknowledge signal is sent to
  Trigger                       the data transport logic if it is required
                                and the state machine advances to the
                                converting state.

  Initialize Data   Condition   The trigger has been received.
  Set Processing                

  Recover the first Action      The first sample in the data set is
  sample                        recovered from storage or the Data Transport
                                logic.
  ----------------- ----------- --------------------------------------------