**I****EEE P1451.3 Proposal**

+-----------------+----------------------------------------------------+
| Proposal Title: | Transducer Block                                   |
+-----------------+----------------------------------------------------+
| Proposal        | P03-004                                            |
| Number:         |                                                    |
+-----------------+----------------------------------------------------+
| Revision        |                                                    |
| Number:         |                                                    |
+-----------------+----------------------------------------------------+
| Date:           | 01/27/2003                                         |
+-----------------+----------------------------------------------------+
|                 |                                                    |
+-----------------+----------------------------------------------------+
| Name:           | Mark Slack                                         |
+-----------------+----------------------------------------------------+
| Company:        | Boeing Commercial Airplanes                        |
+-----------------+----------------------------------------------------+
| Phone Number:   | 206-662-4771                                       |
+-----------------+----------------------------------------------------+
| Fax Number:     |                                                    |
+-----------------+----------------------------------------------------+
| Email Address:  | mark.b.slack@boeing.com                            |
+-----------------+----------------------------------------------------+
|                 |                                                    |
+-----------------+----------------------------------------------------+
| Proposal        | Initial Draft                                      |
| Status:         |                                                    |
|                 | Revised Draft                                      |
|                 |                                                    |
|                 | [X]{.underline} Ready for Vote                     |
+-----------------+----------------------------------------------------+
| Impacts:        | \_\_                                               |
|                 |                                                    |
|                 | \_\_                                               |
+-----------------+----------------------------------------------------+
| Action:         | \_\_ Approved                                      |
|                 |                                                    |
|                 | \_\_ Approved with changes                         |
|                 |                                                    |
|                 | \_[X]{.underline}\_ Rejected                       |
|                 |                                                    |
|                 | \_\_ Returned for revision                         |
+-----------------+----------------------------------------------------+
|                 |                                                    |
+-----------------+----------------------------------------------------+

**Background:**

Multiple comments related to Clause 9, draft D2.0, are summarized below:

**Lee-1**

> comment_type = Technical
>
> comment = For someone who is not familiar with the term \"dot3\", what
> does it mean?
>
> suggested_remedy = Somewhere in the document, the term "dot3" has to
> defined, for example, dot3 means .3, that is, IEEE 1451_dot3 means
> IEEE 1451.3

**Lee-2**

> comment_type = Technical
>
> comment = The term \"TOM\" should be replaced.
>
> suggested_remedy = All the terms "TOM" (Transducer Object Model) is
> requested to be changed to "TBOM" (Transducer Block Object Model).
> TBOM will make more sense according to the context.

**Lee-3**

> Comment Type: Technical
>
> File Format: Powerpoint file
>
> Original Name (can supply needed clues):
> D:\\kang\\Temp\\1451\\1451.3\\balloting\\NIST
> comments\\diagram-IEEE1451.3.ppt
>
> Description: Figure 25 on p128 should be the whole picture or big
> picture of class diagram of Transducer Block. It should be replaced
> with the diagram suggested in the attached file.

**Lee-4**

> page = p134 and others
>
> subclause = 9.x (varies \-- see page references)
>
> comment_type = Technical
>
> comment = TriggerSource is defined in Fig. 75 (p129). There is no
> TriggerGenerator class, but it is used in the document.
>
> suggested_remedy = TriggerGenerator should be changed to TriggerSource
> in Fig. 32 (p134), Fig. 42 (p140), Fig. 44 (p141), Fig. 45 (p141).

**Lee-5**

> page = p140
>
> subclause = 9.3.3
>
> comment_type = Editorial
>
> comment = editorial
>
> suggested_remedy = Figure 43. GenerateTriggerEvent\> should be
> GenerateTriggerEvent

**Lee-6**

> page = p133 and p137
>
> subclause = 9.2.4 and 9.2.7
>
> comment_type = Technical
>
> comment = In Fig. 30 (p133) and Fig. 37 (p137), the multiplicity
> between TBIM and TransducerChannel should be consistent, for instance,
> in Fig. 30 it is 1 to \*, whereas, in Fig. 37 1 to 1..\*
>
> suggested_remedy = Use the right convention.

**Catlin-54**

> page = p127
>
> subclause = 9
>
> comment_type = Editorial
>
> comment = Figure 24 -- This figure appears to be incomplete.

The IEEE P1451.3 Working Group is comprised of industry and government
participants with broad technical experience. However, we do not have
adequate representation in the area of Object Oriented Technology. The
content of Clause 9, as submitted for ballot, was a derivative of the
preliminary work originally submitted by Carlos Lopez-Reyna
(Scite-Fair). Although we gratefully acknowledge the original work, we
have lingering concerns regarding the scope of this standard.

We believe that this standard should not trespass on the detailed design
process. As balloted, Clause 9 appears to cross a threshold that is best
left to implementers, as illustrated by the abstraction layer called the
Common Object Interface (COI). Although this design concept has
significant merit, it is best viewed as a feature that will distinguish
the implementation in a free marketplace, in contrast to an essential
element of a standardized offering.

Our decision to seriously reduce the scope of Clause 9 is influenced by
several pragmatic observations:

1.  We are obligated to tie our model into the Dot 1 object model. What
    was previously balloted did not close that loop.

2.  A reference implementation of IEEE 1451.1 has yet to evolve. As a
    consequence, the adequacy of the IEEE1451_TransducerBlock abstract
    base class (and all specializations) has not been stressed by actual
    implementations. Until the development community embarks on a
    faithful (fully functional) T-Block implementation, we can do little
    more than re-articulate the interface & behavior already described
    in the 1451.1 Object Model. In the proposal that follows, we have
    attempted to provide a model to cover the basic features of the
    standard without dictating design of the fine details.

3.  There is current activity in the OMG to produce an object model for
    smart transducers. Dot 1 comes under periodic review in
    approximately one year. We anticipate reconciliation of these
    model(s).

4.  The 1451 family of standards are evolving. We anticipate that the
    1451.3 standard will be decomposed into an over-arching functional
    specification, supported by a several physical layers. Specification
    of a generic T-Block that addresses the needs of multiple physical
    layers is best deferred to that working group. It is our sincere
    hope that the new working group will have contributors with strong
    OOT credentials.

**Proposal \-- Part A**

Replace the entire body of draft D2.00 Clause 9 with the following text.
This text is formatted for inclusion into draft D2.03 using \"drag and
drop\" logic. Relative paragraph numbering and Figure/Table numbers will
adjust to the point of insertion. In D2.03, this topic should appear as
Clause 11. The editor will have to insert automated cross-reference for
all text highlighted with a [blue]{.mark} background.

# Transducer block specification

The Transducer Block is a software component that executes on an NCAP or
host processor, as depicted in Figure 1. It encapsulates all management
responsibility for the Transducer Bus Controller (TBC) and the
associated transducer bus.

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

Figure 1---Transducer block context diagram

## Introduction

IEEE Std. 1451.1-1999 provides the information model applicable to all
standards in the IEEE 1451 family. That standard specifies a
comprehensive object model in which the **IEEE1451_Dot3TransducerBlock**
class is introduced without supporting definition. This strategy
reserved space within the IEEE 1451.1 class hierarchy while deferring
its definition to this standard. Within the name of this class, the
substring **IEEE1451_Dot3** refers to IEEE Std. 1451.3 (this standard).

This clause defines the Transducer Block. Throughout the remainder of
this clause, the term Transducer Block (two words, each capitalized)
shall denote the collective logic required to manage the transducer bus
and all external components. All class names will be presented in
boldface type. When referring to an object instantiated from a class, a
fixed-space \"computer\" font is used. Therefore, the term
IEEE1451_Dot3TransducerBlock (one word, note typeface) shall denote an
object instantiated from the **IEEE1451_Dot3TransducerBlock** class.

The Transducer Block described herein may be extended or abbreviated to
support deployment in execution environments other than systems
compliant with IEEE Std. 1451.1-1999. If an IEEE 1451.1 compliant NCAP
is used, the use of the model described in this clause is required. If
the NCAP or host processor does not execute in a IEEE 1451.1
environment, the use of this model is optional.

### Functional Overview

The Transducer Block is a software component that provides logic for:

--- Configuring and managing the TBC

--- Configuring and managing TBIMs and their associated
TransducerChannels

The Transducer Block provides the required functionality of any IEEE
1451 transducer block by exposing TransducerChannels and TEDS as network
accessible objects. The Transducer Block also supports information
services unique to this standard (i.e., Virtual TEDS support.).

### Relationship to IEEE 1451.1

The relationships between the IEEE1451_Dot3TransducerBlock and
associated objects defined by IEEE Std. 1451.1-1999 are depicted in
Figure 2. The figure is presented using notation and semantics of the
Universal Modeling Language (UML). See \[A1\], \[A3\] and \[A5\] in the
bibliography for more information about UML. In this figure, classes
described in IEEE Std. 1451.1-1999 are shown shaded (grey background).

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

Figure 2---Class hierarchy

Each individual TransducerChannel and each proxy are exposed as a
Network Visible Object. These interface objects are instantiated from
various sub-classes of the **IEEE1451_Parameter** class, and throughout
this clause, these objects are referred to as Public Transducers. During
initialization, the IEEE1451_Dot3TransducerBlock establishes the mapping
between the individual channels of each TBIM and the Public Transducers.
Each Public Transducer represents information and data associated with a
TransducerChannel or a proxy. TransducerChannel number zero is reserved
for communication to the TBIM as a whole and shall not be represented as
a Public Transducer.

All TEDS information is represented by objects instantiated from the
**IEEE1451_PartitionedFile** class. During initialization, the
IEEE1451_Dot3TransducerBlock populates these objects before exposing
them as Network Visible Objects. The information content may be embedded
in the TBIM or located remotely (Virtual TEDS). In an implementation of
a Transducer Block that supports dynamic plug and play with periodic
discovery logic, there may be a need to derive a class from the
**IEEE1451_PartitionedFile** class to dynamically add partitions to the
image. Throughout the remainder of this clause, all references to the
**IEEE1451_PartitionedFile** class shall be interpreted to mean that
class or a derived sub-class.

During system operation, the user may elect to define address groups
(see [5.2]{.mark}). Creation & deletion of the address groups are
network visible operations on the IEEE1451_Dot3TransducerBlock. Creation
involves instantiation of an object from the **IEEE1451_ComponentGroup**
class, or more precisely, a sub-class thereof that is specialized for
the IEEE 1451.3 environment, and the Transducer Block exposes the empty
group as a Network Visible Object. The user (or host) then interacts
with the object directly to define group membership and perform
triggering operations.

### Conceptual model

IEEE Std. 1451.1-1999 advances a simple conceptual model. This model, as
applied to this standard, is provided in Figure 3.

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

Figure 3---Conceptual model

TBIMs are modeled to have a combination of inputs and/or outputs, each
associated with a \"register\". Within the context of this standard, a
register should be visualized as a buffer large enough to accommodate a
data set, as determined by information found in the Meta-TEDS, the
TransducerChannel TEDS, and the current value of the *TransducerChannel
Data Repetition Count*. These registers are accessed via the IEEE1451.3
physical interface as a result of actions taken by the
IEEE1451_Dot3TransducerBlock. These registers agree with the
corresponding physical world values only after a supported triggering
operation.

The Transducer Block is modeled to contain a set of registers, comprised
of one register for each register found on a TBIM, for all TBIMs extant.
Any register on the Transducer Block agrees with its corresponding
register on the TBIM only after an exchange of values over the
interface. The content of a register is expressed in a numeric
representation compatible with the *Data model* found in the
TransducerChannel TEDS. This value may or may not express engineering
units, depending on the value of the *Calibration key* in the
TransducerChannel TEDS.

The Transducer Block is modeled to contain a second set of registers
that contain values transformed from the first set of data registers
using the correction information provided by the Calibration TEDS, where
indicated by the *Calibration key* in the TransducerChannel TEDS.
Details related to behavior of the correction logic are provided in
1.2.2. The second set of registers shall be used as the 'currently held
values' of a Physical Parameter object exposed as the Public Transducer.

### Terminology

Throughout the remainder of this clause, certain terms defined in IEEE
Std. 1451.1-1999 are used. For brevity, these terms are not redefined
herein. Please consult that standard for definition of the following
terms:

Block Major State

Full Implementation

Interface Only Implementation

Network Visible Object

All Interface Definition Language (IDL) specifications within this
clause utilize data types defined in IEEE Std. 1451.1-1999.

## IEEE1451_Dot3TransducerBlock

**Class**: IEEE1451_Dot3TransducerBlock

**Parent Class**: IEEE1451_TransducerBlock

**Class ID**: 1.1.1.3.1.2

**Description**: The IEEE1451_Dot3TransducerBlock, instantiated from the
**IEEE1451_Dot3TransducerBlock** class, provides an interface to all
transducers supported by this standard. The global properties of the
Public Transducers are provided by operations on the Transducer Block
itself. The basic operations inherited from the
**IEEE1451_TransducerBlock** class provide for direct manipulation of
the IEEE1451.3 interface. These basic operations may be used to access
transducer properties or types not easily managed using **Component**
class objects.

**Network Visible operations:**

See recommendations below.

**Inherited operations with additional specifications:**

See recommendations below.

**Local operations:**

See recommendations below.

**Publications:** There are no publications defined for this class.

**Subscriptions:** There are no subscriptions defined for this class.

### Initialization behavior

During the initialization phase of the Block Major State life cycle, the
IEEE1451_Dot3TransducerBlock instantiates zero or more objects of class
**IEEE1451_Parameter** and **IEEE1451_PartitionedFile**. These objects
may be registered to create the Network Visible interface appropriate to
the specific transducer. This activity shall be successfully completed
before entering the BL_INACTIVE state defined for all objects in the
**IEEE1451_Block** class.

The selection of the interface objects to represent TransducerChannels
and the assignment of their names during registration shall be based on
information supplied in the TEDS and the following clauses.

#### Selection of components to represent TransducerChannels

Every implemented TransducerChannel address in a TBIM is associated with
a resource. During initialization, the Transducer Block will attempt to
represent each resource in each TBIM with an Object instantiated from a
sub-class of the **IEEE1451_Parameter** class. The decision regarding
the class of the Object relies on information acquired during the
discovery process, information found in the Meta-TEDS, and information
found in the TransducerChannel TEDS. An inability to access the TEDS or
inconsistent or incomplete information content in the TEDS shall cause
the Transducer Block to abandon the attempt to represent that resource
as a Public Transducer, and the TransducerChannel address will be
included in the list of unrepresented channels (see operation
GetUnrepresentedChannelNumbers, inherited from the
**IEEE1451_TransducerBlock** class).

Within the context of this clause,

--- the term **\'scalar\'** object is any object instantiated from class
**IEEE1451_ScalarParameter** or class
**IEEE1451_ScalarSeriesParameter**.

--- the term **\'vector\'** object is any object instantiated from class
**IEEE1451_VectorParameter** or class
**IEEE1451_VectorSeriesParameter**.

--- the term **\'singleton\'** object is any object instantiated from
class **IEEE1451_ScalarParameter** or class
**IEEE1451_VectorParameter**.

--- the term **\'series\'** object is any object instantiated from class
**IEEE1451_ScalarSeriesParameter** or class
**IEEE1451_VectorSeriesParameter**.

--- the term **'analog'**, as applied to **\'scalar\'** or
**\'vector\'** objects, shall be interpreted as one of the IEEE1451.1
Parameter types:

--- PP_SCALAR_ANALOG

--- PP_SCALAR_ANALOG_SERIES

--- PP_VECTOR_ANALOG

--- PP_VECTOR_ANALOG_SERIES

--- the term **'discrete'**, as applied to **\'scalar\'** or
**\'vector\'** objects, shall be interpreted as one of the IEEE1451.1
Parameter types:

--- PP_SCALAR_DISCRETE

--- PP_SCALAR_DISCRETE_SERIES

--- PP_VECTOR_DISCRETE

--- PP_VECTOR_DISCRETE_SERIES

--- the term **'digital'**, as applied to **\'scalar\'** or
**\'vector\'** objects, shall be interpreted as one of the IEEE1451.1
Parameter types:

--- PP_SCALAR_DIGITAL

--- PP_SCALAR_DIGITAL_SERIES

--- PP_VECTOR_DIGITAL

--- PP_VECTOR_DIGITAL_SERIES

Basic guidelines:

--- Individual sensors and actuators shall be represented by
**\'scalar\'** objects.

--- Event sensors shall be represented as objects in the
**IEEE1451_TimeParameter** class.

--- A proxy shall be represented by a **\'vector\'** object with N
members, where N is the *Number of TransducerChannels represented by
this proxy*, as found in the Meta-TEDS ([7.3]{.mark}).

Note---Using a **\'vector\'** object to represent a proxy presents a
potential semantics problem. The choice is dictated by data set
organization, and shall not be interpreted to mean that the members are
not to be treated as a mathematical vector. The choice of representation
is made without consideration for the definition of VectorGroups, as
found in the Meta-TEDS ([7.3]{.mark}). If desired, implementers are free
to preserve the semantic intent of the **\'vector\'** classes by
deriving new sub-classes from the **IEEE1451_PhysicalParameter** class
that have identical implementation and data structure as found in the
**\'vector\'** classes.

Pathological situations:

--- A proxy, when one or more proxy members are declared to be a member
another proxy.

--- A proxy, when one or more proxy members are declared to be an event
sensor.

--- A proxy, when one proxy member is declared to be a member of a
VectorGroup and at least one member of that VectorGroup is not a member
of that proxy.

--- A member of one VectorGroup is declared to be a member of another
VectorGroup, unless the proxy fully represents all members of both
groups.

The sole criteria for determining whether a TransducerChannel is
represented by a **\'scalar\'** object or a **\'vector\'** object is
whether the TransducerChannel is a proxy, as defined in the Meta-TEDS
([7.3]{.mark}). A proxy may be demoted to a **\'scalar\'** object when
the *TransducerChannel proxy data set organization* and the definition
of ControlGroups within the Meta-TEDS logically results in a scalar
parameter preceded by a single time-of-day reading.

Determination of whether a TransducerChannel is represented by a
**\'singleton\'** object or a **\'series\'** object is based on the
following rules:

--- For individual sensors and actuators, the decision shall be based
solely on the value of the *Maximum data repetitions* field in the
TransducerChannel TEDS ([7.4]{.mark}). If *Maximum data repetitions* is
one, the resource shall be represented by a **\'singleton\'** object.
Otherwise, the resource shall be represented by a **\'series\'** object.

--- For proxies, the proxy shall be a **\'series\'** object if any
individual member is a **\'series\'** object.

The final datum required to satisfy the information model is to finalize
the Physical Parameter Type, which is the value returned from operation
GetPhysicalParameterType. This determination is only required for
**\'scalar\'** and **\'vector\'** objects.

For individual sensors and actuators, the logic used to determine
Physical Parameter Type is summarized in Table 1. The logic is based on
the following information:

--- The *Physical units interpretation* code ([4.11]{.mark}) found in
field 1 of the *Physical units* structure in the TransducerChannel TEDS
([7.4.2.4]{.mark})

--- The *Data model* found in the TransducerChannel TEDS
([7.4.2.9]{.mark})

Table 1---Physical parameter type determination

+---------------------------------+---+---+---+---+---+---+---+------+
|                                 | * |   |   |   |   |   |   |      |
|                                 | * |   |   |   |   |   |   |      |
|                                 | N |   |   |   |   |   |   |      |
|                                 | - |   |   |   |   |   |   |      |
|                                 | o |   |   |   |   |   |   |      |
|                                 | c |   |   |   |   |   |   |      |
|                                 | t |   |   |   |   |   |   |      |
|                                 | e |   |   |   |   |   |   |      |
|                                 | t |   |   |   |   |   |   |      |
|                                 | i |   |   |   |   |   |   |      |
|                                 | n |   |   |   |   |   |   |      |
|                                 | t |   |   |   |   |   |   |      |
|                                 | e |   |   |   |   |   |   |      |
|                                 | g |   |   |   |   |   |   |      |
|                                 | e |   |   |   |   |   |   |      |
|                                 | r |   |   |   |   |   |   |      |
|                                 | * |   |   |   |   |   |   |      |
|                                 | * |   |   |   |   |   |   |      |
+---------------------------------+---+---+---+---+---+---+---+------+
|                                 |   | * |   |   |   |   |   |      |
|                                 |   | * |   |   |   |   |   |      |
|                                 |   | S |   |   |   |   |   |      |
|                                 |   | i |   |   |   |   |   |      |
|                                 |   | n |   |   |   |   |   |      |
|                                 |   | g |   |   |   |   |   |      |
|                                 |   | l |   |   |   |   |   |      |
|                                 |   | e |   |   |   |   |   |      |
|                                 |   | p |   |   |   |   |   |      |
|                                 |   | r |   |   |   |   |   |      |
|                                 |   | e |   |   |   |   |   |      |
|                                 |   | c |   |   |   |   |   |      |
|                                 |   | i |   |   |   |   |   |      |
|                                 |   | s |   |   |   |   |   |      |
|                                 |   | i |   |   |   |   |   |      |
|                                 |   | o |   |   |   |   |   |      |
|                                 |   | n |   |   |   |   |   |      |
|                                 |   | r |   |   |   |   |   |      |
|                                 |   | e |   |   |   |   |   |      |
|                                 |   | a |   |   |   |   |   |      |
|                                 |   | l |   |   |   |   |   |      |
|                                 |   | * |   |   |   |   |   |      |
|                                 |   | * |   |   |   |   |   |      |
+---------------------------------+---+---+---+---+---+---+---+------+
|                                 |   |   | * |   |   |   |   |      |
|                                 |   |   | * |   |   |   |   |      |
|                                 |   |   | D |   |   |   |   |      |
|                                 |   |   | o |   |   |   |   |      |
|                                 |   |   | u |   |   |   |   |      |
|                                 |   |   | b |   |   |   |   |      |
|                                 |   |   | l |   |   |   |   |      |
|                                 |   |   | e |   |   |   |   |      |
|                                 |   |   | p |   |   |   |   |      |
|                                 |   |   | r |   |   |   |   |      |
|                                 |   |   | e |   |   |   |   |      |
|                                 |   |   | c |   |   |   |   |      |
|                                 |   |   | i |   |   |   |   |      |
|                                 |   |   | s |   |   |   |   |      |
|                                 |   |   | i |   |   |   |   |      |
|                                 |   |   | o |   |   |   |   |      |
|                                 |   |   | n |   |   |   |   |      |
|                                 |   |   | r |   |   |   |   |      |
|                                 |   |   | e |   |   |   |   |      |
|                                 |   |   | a |   |   |   |   |      |
|                                 |   |   | l |   |   |   |   |      |
|                                 |   |   | * |   |   |   |   |      |
|                                 |   |   | * |   |   |   |   |      |
+---------------------------------+---+---+---+---+---+---+---+------+
|                                 |   |   |   | * |   |   |   |      |
|                                 |   |   |   | * |   |   |   |      |
|                                 |   |   |   | N |   |   |   |      |
|                                 |   |   |   | - |   |   |   |      |
|                                 |   |   |   | o |   |   |   |      |
|                                 |   |   |   | c |   |   |   |      |
|                                 |   |   |   | t |   |   |   |      |
|                                 |   |   |   | e |   |   |   |      |
|                                 |   |   |   | t |   |   |   |      |
|                                 |   |   |   | f |   |   |   |      |
|                                 |   |   |   | r |   |   |   |      |
|                                 |   |   |   | a |   |   |   |      |
|                                 |   |   |   | c |   |   |   |      |
|                                 |   |   |   | t |   |   |   |      |
|                                 |   |   |   | i |   |   |   |      |
|                                 |   |   |   | o |   |   |   |      |
|                                 |   |   |   | n |   |   |   |      |
|                                 |   |   |   | * |   |   |   |      |
|                                 |   |   |   | * |   |   |   |      |
+---------------------------------+---+---+---+---+---+---+---+------+
|                                 |   |   |   |   | * |   |   |      |
|                                 |   |   |   |   | * |   |   |      |
|                                 |   |   |   |   | B |   |   |      |
|                                 |   |   |   |   | i |   |   |      |
|                                 |   |   |   |   | t |   |   |      |
|                                 |   |   |   |   | s |   |   |      |
|                                 |   |   |   |   | e |   |   |      |
|                                 |   |   |   |   | q |   |   |      |
|                                 |   |   |   |   | u |   |   |      |
|                                 |   |   |   |   | e |   |   |      |
|                                 |   |   |   |   | n |   |   |      |
|                                 |   |   |   |   | c |   |   |      |
|                                 |   |   |   |   | e |   |   |      |
|                                 |   |   |   |   | * |   |   |      |
|                                 |   |   |   |   | * |   |   |      |
+---------------------------------+---+---+---+---+---+---+---+------+
| **Physical units                |   |   |   |   |   | * |   |      |
| interpretation**                |   |   |   |   |   | * |   |      |
|                                 |   |   |   |   |   | T |   |      |
|                                 |   |   |   |   |   | i |   |      |
|                                 |   |   |   |   |   | m |   |      |
|                                 |   |   |   |   |   | e |   |      |
|                                 |   |   |   |   |   | o |   |      |
|                                 |   |   |   |   |   | f |   |      |
|                                 |   |   |   |   |   | D |   |      |
|                                 |   |   |   |   |   | a |   |      |
|                                 |   |   |   |   |   | y |   |      |
|                                 |   |   |   |   |   | * |   |      |
|                                 |   |   |   |   |   | * |   |      |
+---------------------------------+---+---+---+---+---+---+---+------+
| PUI_SI_UNITS                    | 4 | 1 | 1 | 1 | x | 2 |   |      |
+---------------------------------+---+---+---+---+---+---+---+------+
| PUI_RATIO_SI_UNITS              | x | 1 | 1 | 1 | x | x |   |      |
+---------------------------------+---+---+---+---+---+---+---+------+
| PUI_LOG10_SI_UNITS              | x | 1 | 1 | 1 | x | x |   |      |
+---------------------------------+---+---+---+---+---+---+---+------+
| PUI_LOG10_RATIO_SI_UNITS        | x | 1 | 1 | 1 | x | x |   |      |
+---------------------------------+---+---+---+---+---+---+---+------+
| PUI_DIGITAL_DATA                | 3 | x | x | x | 3 | x |   |      |
+---------------------------------+---+---+---+---+---+---+---+------+
| PUI_ARBITRARY                   | 2 | 1 | 1 | 1 | x | x |   |      |
+---------------------------------+---+---+---+---+---+---+---+------+
| Symbols:                        |   |   |   |   |   |   |   |      |
|                                 |   |   |   |   |   |   |   |      |
| 1 = **\'analog\'**              |   |   |   |   |   |   |   |      |
|                                 |   |   |   |   |   |   |   |      |
| 2 = **\'discrete\'**            |   |   |   |   |   |   |   |      |
|                                 |   |   |   |   |   |   |   |      |
| 3 = **\'digital\'**             |   |   |   |   |   |   |   |      |
|                                 |   |   |   |   |   |   |   |      |
| 4 = ambiguous                   |   |   |   |   |   |   |   |      |
|                                 |   |   |   |   |   |   |   |      |
| x = illegal                     |   |   |   |   |   |   |   |      |
+---------------------------------+---+---+---+---+---+---+---+------+
| Any TransducerChannel using a   |   |   |   |   |   |   |   |      |
| *Data model* of Long integer or |   |   |   |   |   |   |   |      |
| a *Data model* Long fraction    |   |   |   |   |   |   |   |      |
| shall not be represented by a   |   |   |   |   |   |   |   |      |
| Public Transducer.              |   |   |   |   |   |   |   |      |
+---------------------------------+---+---+---+---+---+---+---+------+

An ambiguous case exists when the *Physical units interpretation* is
PUI_SI_UNITS and the *Data model* is N-octet integer. The ambiguity is
resolved by examining the units declared. If the parameter is unitless
(all remaining fields in the *Physical units* structure are set to 128),
the parameter shall be classified as **\'discrete\'**. Otherwise, the
parameter is classified as **\'analog\'**.

Illegal combinations shall cause the Transducer Block to abandon the
attempt to represent that resource as a Public Transducer, and the
TransducerChannel address will be included in the list of unrepresented
channels (see operation GetUnrepresentedChannelNumbers). Resources at
these addresses can only be accessed via operations on the
IEEE1451_Dot3TransducerBlock.

For proxies, the Physical Parameter Type is specified on a per element
basis, as determined by the Physical Parameter Type of each proxy
member. When a proxy has a member that cannot be represented as a Public
Transducer, the proxy shall not be represented as a Public Transducer.

#### Parameter naming conventions

The Object Name returned by the operation GetObjectName for a Parameter
serving as a Public Transducer shall be determined according to the
first of the following alternatives to apply:

If the Parameter represent a TransducerChannel or a TransducerChannel
proxy for which a Commissioning TEDS exists and if the string therein is
not null, the Object Name shall be the value specified in the
Commissioning TEDS.

Otherwise, the name of the Parameter shall consist of a sequence of
characters designating the Parameter class followed by an ordinal number
assigned starting with the value '0' for the first Parameter named.
Independent ordinals shall be maintained for each Parameter class. The
String shall be represented in the IEEE1451.1 character set.

#### Required files and their naming conventions

TEDS data structures shall be represented as objects of class
**IEEE1451_PartitionedFile**. The contents of these Files shall deliver
the exact representations and information as defined in clause
[7]{.mark} of this standard.

The Transducer Block is responsible for instantiating one File Object
per TEDS type. These Partitioned File Objects shall have fixed names, as
defined in Table 2.

Table 2---File object names

  ----------------------------- ---------------- ---------------------------------
  TEDS type                     Defining clause  Partitioned File Object name

  Module Meta-TEDS              [7.3]{.mark}     IEEE1451_3_MetaTeds

  Meta-Identification TEDS      [7.8.3]{.mark}   IEEE1451_3_MetaIdTeds

  TransducerChannel TEDS        [7.4]{.mark}     IEEE1451_3_ChanTeds

  TransducerChannel             [7.8.4]{.mark}   IEEE1451_3_ChanIdTeds
  Identification TEDS                            

  Calibration TEDS              [7.5]{.mark}     IEEE1451_3_CalTeds

  Calibration-Identification    [7.8.5]{.mark}   IEEE1451_3_CalIdTeds
  TEDS                                           

  End Users' Application        [7.9]{.mark}     IEEE1451_3_EuasTeds
  Specific TEDS                                  

  Frequency Response TEDS       [7.6]{.mark}     IEEE1451_3_FreqRespTeds

  Transfer Function TEDS        [7.7]{.mark}     IEEE1451_3_TransferFunctTeds

  Commands TEDS                 [7.8.6]{.mark}   IEEE1451_3_CommandsTeds

  Location and Title TEDS       [7.8.7]{.mark}   IEEE1451_3_LocationTitleTeds

  Commissioning TEDS            [7.10]{.mark}    IEEE1451_3_CommissioningTeds

  PHY TEDS                      [7.12]{.mark}    IEEE1451_3_PhyTeds

  Manufacturer defined TEDS     [7.11]{.mark}    ---
  ----------------------------- ---------------- ---------------------------------

File objects are abstractions of data resources, and they should be
conceptualized as blocks of memory that may be opened, closed, read, or
written. There is no logic within the File object to ensure that a write
operation propagates to the target TBIM. If persistence is desired, any
write to a File object must be followed by appropriate operations on the
IEEE1451_Dot3TransducerBlock .

Manufacturer defined TEDS are not accessible through the interface of a
Partitioned File Object.

### Correction engine behavior

For TransducerChannels with *Calibration key* values of CAL_NONE,
TBIM_CAL_SUPPLIED, TBIM_CAL_SELF, or TBIM_CAL_CUSTOM, there shall be no
corrections applied by the Transducer Block. The Transducer Block
correction logic shall pass the associated value without modification in
both the TB_CORRECTED and TB_UNCORRECTED states

For TransducerChannels with a *Calibration key* value of CAL_SUPPLIED,
the Transducer Block shall provide correction logic according to the
following rules. In the TB_UNCORRECTED state, the Transducer Block
correction logic shall pass the associated value without modification.
In the TB_CORRECTED state, corrections shall be applied using the
methods and coefficients specified in [7.5.1.2]{.mark}.

For TransducerChannels with a *Calibration key* value of CAL_CUSTOM, the
correction behavior is outside the scope of this standard.
TransducerChannels with this value of *Calibration key* shall not be
represented by Public Transducers. The channel number shall be returned
by the GetUnrepresentedChannelNumbers operation of the
IEEE1451_Dot3TransducerBlock.

### Read/write/update semantics

The Transducer Block conceptually supplies the highest layer of
abstraction in the ISO model. The fundamental Network Visible Read
functionality, on Data Communications Channel 0, shall map to the Reply
protocol ([8.x]{.mark}). The fundamental Network Visible Write
functionality, on Data Communications Channel 0, shall map to the
Command protocol ([8.x]{.mark}). All update operations shall translate
to messages issued using the Trigger protocol ([8.x]{.mark}). These
operations shall be Network Visible.

Transducer Block implementations may expose the concept of a Data
Communications Channel and require its specification as an argument to
the Network Visible read, write, and update operations. This approach
extends functionality to a knowledgeable host, but it has questionable
semantics in a IEEE1451.1 environment.

Alternately, the Transducer Block can encapsulate and hide the concept
of a Data Communications Channel defining local read/write operations to
utilize the Streaming data protocol ([8.x]{.mark}). If this approach is
taken, it is recommended that these operations be implemented as Local
operations, available to Public Transducers that have registered with
the Transducer Block as participants in a streaming session.

The recommended model for implementing a streaming session assumes that
all data will be exchanged via the publish/subscribe mechanisms defined
in IEEE Std. 1451.1-1999.

### Network Visible operations

Network Visible operations specific to this sub-class are not overtly
defined herein. Required functionality is discussed and recommendations
follow.

#### Correlation between a Parameter Object and the TEDS

The Transducer Block is responsible for instantiating Parameter Objects
that represent the TransducerChannels and registering these objects as
Network Visible. The Transducer Block is also responsible for
instantiating Partitioned File Objects that represent TEDS and
registering these objects as Network Visible.

In order to access the TEDS information, the user requires a correlation
between the TransducerChannel (or the Object Tag of the Object
representing that TransducerChannel) and the partition_id of the
partition in which the TEDS information resides. The Transducer Block
shall provide a translation service. Recommended Network Visible
operations are:

GetPartitionIdByObjectTag

GetPartitionIdByChannelAddress

Both functions return an array of UInteger16 values. Each element of
this array shall be interpreted as an appropriate partition_id argument
for operations on a specific Partitioned File Object that represent the
collections of all TEDS of a particular type. The array may be indexed
using the following enumerated list:

**IDL:** enumeration PartitionIdIndex;

  --------------------------- ----------- ----------------------------------
  **Manifest constant**       **Value**   **Partitioned File Object**

  PID_MetaTeds                0           IEEE1451_3_MetaTeds

  PID_MetaIdTeds              1           IEEE1451_3_MetaIdTeds

  PID_ChanTeds                2           IEEE1451_3_ChanTeds

  PID_ChanIdTeds              3           IEEE1451_3_ChanIdTeds

  PID_CalTeds                 4           IEEE1451_3_CalTeds

  PID_CalIdTeds               5           IEEE1451_3_CalIdTeds

  PID_EuasTeds                6           IEEE1451_3_EuasTeds

  PID_FreqRespTeds            7           IEEE1451_3_FreqRespTeds

  PID_TransferFunctTeds       8           IEEE1451_3_TransferFunctTeds

  PID_CommandsTeds            9           IEEE1451_3_CommandsTeds

  PID_LocTitleTeds            10          IEEE1451_3_LocTitleTeds

  PID_CommissioningTeds       11          IEEE1451_3_CommissioningTeds

  PID_PhyTeds                 12          IEEE1451_3_PhyTeds
  --------------------------- ----------- ----------------------------------

For example, element 4 of the returned array is the partition_id that
may be used when interacting with the IEEE1451_3_CalTeds object. The
objects referenced in this paragraph are defined in 1.2.1.3.

#### Support for plug and play

A system that supports the dynamic plug and play features of this
standard will be required to engage in the discovery process (see
[9.4]{.mark}) on a periodic basis. This is a system decision, not a
Transducer Block decision. To support the system that elects to
periodically probe for new bus participants, the
IEEE1451_Dot3TransducerBlock may support a Network Visible operation to
perform discovery. The recommended name for this operation is Discover.

Upon invocation of the Discover operation, the Transducer Block shall
orchestrate a discovery process that does not perturb the existing
complement of TBIMs. If a new participant is found, the Transducer Block
will perform the initialization steps described above (1.2.1) to expose
the resources of the new participant as Network Visible Objects. An
issue to be addressed during design is the ability to dynamically add a
new partition to the existing IEEE1451_PartitionedFile objects after the
object has been exposed as Network Visible. The new partitions are
required to support the TEDS information associated with the new
participant(s).

#### Support for address groups

The formation of address groups is a user domain issue. The Transducer
Block will support this feature with Network Visible operations to
create and delete address groups. Creation involves instantiation of an
object from the **IEEE1451_ComponentGroup** class, or more precisely, a
sub-class thereof that is specialized for the IEEE 1451.3 environment.
The Transducer Block exposes the empty group as a Network Visible
Object. The user (or host) then interacts with the object directly to
define group membership.

It is recommended that this object be endowed with read/write/update
logic similar to other Public Transducers from the
**IEEE1451_Parameter** class. The update operation shall be implemented
with a trigger message addressed to the address group. Read and write
operations would iterate through each member of the Component Group to
issue read and write operations addressed to a specific
TransducerChannel.

### Inherited operations with additional specifications

The following operations inherited from the
**IEEE1451_BaseTransducerBlock** class may have Interface Only
Implementations. As clarified in IEEE Std. 1451.1-1999, this means that
these operations have no meaning within this class, and any attempt to
invoke these operations shall return immediately with the major return
code of MJ_NOP_OPERATION.

--- IORead

--- IOWrite

--- SetIOControl

--- GetIOStatus

If IORead and IOWrite are provided as Full Implementations, they shall
provide the interface to the Reply protocol ([8.x]{.mark}) and the
Command services protocol ([8.x]{.mark}), respectively.

The following operations inherited from the **IEEE1451_TransducerBlock**
class shall all have Full Implementations:

--- EnableCorrections

--- DisableCorrections

The following operations inherited from the **IEEE1451_TransducerBlock**
class shall abide to the additional specifications provided herein:

--- GetChannelParameterObjectTags

--- GetParameterObjectChannelNumbers

#### Inherited operation GetChannelParameterObjectTags

Input argument channel_number has data type UInteger16. The most
significant octet in this UInteger16 shall specify the TBIM alias, and
the least significant octet shall specify the TransducerChannel number,
as defined in [5.2]{.mark}. A further constraint imposed by this class
is that channel_number shall resolve to an address in the
TransducerChannel Address Class.

Output argument parameter_object_tags has data type ObjectTagArray. Each
element of the array is an Object Tag that identifies a Public
Transducer that uses channel_number. A further specialization of this
operation within this class is that the 0^th^ element shall always be
the Object Tag of the Public Transducer that represents the data
resource interfaced through the specified channel_number. This operation
returns an array with multiple elements when channel_number specifies a
resource that is a component of a TransducerChannel proxy.

If channel_number does not resolve to an address in the
TransducerChannel Address Class (see [5.2]{.mark}), this operation shall
return MJ_FAILED_INPUT_ARGUMENT in the Major Field of OpReturnCode. If
channel_number resolves to an address in the TransducerChannel Address
Class and if the Transducer Block has no mapping to a Public Transducer
for that channel_number, this operation shall return
MJ_FAILED_OUPUT_ARGUMENT in the Major Field of OpReturnCode.

#### Inherited operation GetParameterObjectChannelNumbers

Input argument parameter_object_tag has data type ObjectTag and
specifies the Object Tag of a Public Transducer for which the
corresponding TransducerChannel number is desired.

Output argument channel_numbers has data type UInteger16Array. Each
element of the array is a TransducerChannel address (see [5.2]{.mark})
identifying a resource on the physical interface represented by the
Public Transducer. A further specialization of this operation within
this class is that the 0^th^ element shall always be the
TransducerChannel address of the data resource for that Public
Transducer. This operation returns an array with multiple elements when
the Public Transducer is a proxy. The 0^th^ element shall always be the
TransducerChannel address of the proxy, and subsequent elements define
the TransducerChannel address of the individual contributors to that
proxy.

If parameter_object_tag does not resolve to a known Public Transducer,
this operation shall return MJ_FAILED_INPUT_ARGUMENT in the Major Field
of OpReturnCode.

### Local operations

Local operations may only be invoked in the process space of the object.
Recommendations for Local Operations available from the
**IEEE1451_Dot3TransducerBlock** are defined herein.

#### Support for service requests

Service requests are conceptually similar to interrupts, as described in
[5.12]{.mark}, but the indication of the request is embedded in the
status octet found in every reply received. The Transducer Block shall
provide a mechanism to articulate the existence of a service request to
an object in the local process space. Recommended operations are:

--- RegisterServiceRequestNotification

--- DeregisterServiceRequestNotification

#### Support for streaming data

Whether a Public Transducer participates in a streaming data exercise is
decision in the user domain. The Transducer Block shall provide a
mechanism to enable a Public Transducer to register and deregister as a
streaming data consumer or a streaming data producer. This functionality
may be implemented through specialization of the RegisterNotifyOnUpdate
and DeregisterNotifyOnUpdate operations inherited from the
**IEEE1451_Block** class. Additional or alternative local operations may
be introduced to manage the streaming session.

## Public Transducers

Classes used to represent Public Transducers may require specialization
to use the full set of features implemented in the
IEEE1451_Dot3TransducerBlock. When specialization is required, class
names shall be formed by inserting the \"**Dot3**\" qualifier into the
class name, immediately following the \"**IEEE1451\_**\" sub-string. For
example, if a sub-class is derived from the **IEEE1451_VectorParameter**
class, it shall be named **IEEE1451_Dot3VectorParameter**.

**Proposal \-- Part B**

Incidental changes to draft D2.02 follow. (Microsoft Word \-- Revisions
ON)

Clause 3 \-- Definitions

::: definition
**3.2.11 Code-Division Multiple Access:** Code-Division Multiple Access
(CDMA) uses ...
:::

::: definition
**3.2.12 CommunicationsChannel:** For the purposes of this standard,
\...
:::

::: definition
**3.2.13** **ControlGroup:** ControlGroups are manufacturer
specifications that define the inherent relationships between the
TransducerChannels of a multi-channel TBIM. This ControlGrouping
information is not normally used by the TBIM itself. This information is
used to identify TransducerChannels that are used to control some
characteristic of another TransducerChannel. For example, a ControlGroup
could be used to identify an actuator that is used to set the threshold
of an analog event sensor.
:::

::: definition
**3.2.67 VectorGroup:** VectorGroups are manufacturer specifications
that define the inherent relationships between the TransducerChannels of
a multi-channel TBIM. This VectorGrouping information is not normally
used by the TBIM itself. This information is normally used by bus
controller applications to properly compose human readable displays or
in formulating other computations. For example, VectorGroupings may be
used to indicate which TransducerChannels represent the three vector
axes of a three-axis vector measurement.
:::

Clause 4 \-- Data types

Break Table 1 into 2 components to assign manifest constant. No change
to textual description

Table 1---Physical units data type structure

  ----------- --------------------------------------------------- -------- ----------
  **Field**   **Description**                                     **Data   **Number
                                                                  Type**   of
                                                                           octets**

  1           Physical units interpretation \-- see Table 2       U8E      1

  2           (2 \* \<exponent of radians\>) + 128                U8C      1

  3           (2 \* \<exponent of steradians\>) + 128             U8C      1

  4           (2 \* \<exponent of meters\>) + 128                 U8C      1

  5           (2 \* \<exponent of kilograms\>) + 128              U8C      1

  6           (2 \* \<exponent of seconds\>) + 128                U8C      1

  7           (2 \* \<exponent of amperes\>) + 128                U8C      1

  8           (2 \* \<exponent of kelvins\>) + 128                U8C      1

  9           (2 \* \<exponent of moles\>) + 128                  U8C      1

  10          (2 \* \<exponent of candelas\>) + 128               U8C      1
  ----------- --------------------------------------------------- -------- ----------

Table 2---Physical units interpretation

  ----------- -------------------------- ----------------------------------------
  **Value**   **Manifest constant**      **Definition**

  0           PUI_SI_UNITS               Unit is described by the product of SI
                                         base units, plus radians and steradians,
                                         raised to the powers recorded in fields
                                         2 through 10. Units for some quantities,
                                         such as the number of people through a
                                         turnstile, cannot be represented using
                                         these units. Enumeration zero, with
                                         fields 2-10 set to 128, is the
                                         appropriate enumeration for these cases
                                         when a quantity is being defined.

  1           PUI_RATIO_SI_UNITS         Unit is U/U, where U is described by the
                                         product of SI base units, plus radians
                                         and steradians, raised to the powers
                                         recorded in fields 2 through 10.

  2           PUI_LOG10_SI_UNITS         Unit is log~10~(U), where U is described
                                         by the product of SI base units, plus
                                         radians and steradians, raised to the
                                         powers recorded in fields 2 through 10.

  3           PUI_LOG10_RATIO_SI_UNITS   Unit is log~10~(U/U), where U is
                                         described by the product of SI base
                                         units, plus radians and steradians,
                                         raised to the powers recorded in fields
                                         2 through 10.

  4           PUI_DIGITAL_DATA           The associated quantity is digital data
                                         (e.g. a bit vector) and has no unit.
                                         Fields 2-10 shall be set to 128. The
                                         \"digital data\" type applies to data
                                         that does not represent a quantity, such
                                         as the current positions of a bank of
                                         switches.

  5           PUI_ARBITRARY              The associated physical quantity is
                                         represented by values on an arbitrary
                                         scale (e.g. hardness). Fields 2-10 are
                                         reserved, and shall be set to 128.

  6-255       ---                        Reserved
  ----------- -------------------------- ----------------------------------------

Clause 5 \-- Functional spec

New sub-clause, inserted before 5.6 (TransducerChannel Proxy)

**5.6 TransducerChannel groups**

There are two types of TransducerChannel groups defined in this
standard. They are VectorGroups and ControlGroups. They are similar in
implementation but are used for two different functions.

**5.6.1 VectorGroups**

VectorGroups are used to define relationships between TransducerChannels
within a single multi-channel TBIM that imply a display or mathematical
relationship between the TransducerChannels. For example, they can be
used to identify the relationships between the components of a
three-axis accelerometer. VectorGroups are used by the software in the
TBC/NCAP or host processor to group the outputs of the individual
TransducerChannels into vectors for display or computational purposes.

Note: VectorGroups are in some ways similar to TransducerChannel
proxies. TransducerChannel proxies are used to identify
TransducerChannels that are grouped together for reasons such as
efficient transmission of the data and/or simultaneous triggering.
Proxies may or may not represent a vector for display or computational
purposes. However, it is recommended that all vectors be implemented as
proxies, especially in spatial vector applications (like velocity or
acceleration), where the measurements of the three components at
different points in time could lead to misinterpretation.

**5.6.2 ControlGroups**

ControlGroups are used to define collections of TransducerChannels when
one TransducerChannel is the primary channel and the remaining
TransducerChannels in the group provide either additional information
about the primary TransducerChannel or are used to control some aspect
of the primary TransducerChannel. For example, a ControlGroup can be
used to define up to three additional TransducerChannels associated with
an analog event sensor. One is a sensor that is used to measure the
analog input to the event sensor. The second is an actuator that is used
to set the threshold for the event sensor. The third is an actuator that
can be used to set the hysteresis for the event sensor.

Change Meta-TEDS

**7.3.2 Data block**

Table [37]{.mark} summarizes the content of the data block. Subordinate
subclauses explain each data field in this data block.

Table 37---Structure of the Meta-TEDS data block

  ------- ---------------------------------------------- ---------- --------
  Field   Description                                    Type       \#
                                                                    octets

  ---     Length                                         U32L       4

  1       TEDS identifier                                U8E        1

  2       IEEE P1451 standards family number             U8E        1

  3       TEDS version number                            U8E        1

  ---     Timing related information                     ---        ---

  4       TEDS hold-off time (t~th~)                     F32        4

  5       Operational hold-off time (t~oh~)              F32        4

  6       Load current drawn from the transducer bus     F32        4

  7       Multi-range Capability                         U8E        1

  ---     VectorGroup information sub-block              ---        ---

  8       Number of VectorGroups (N~v~)                  U8C        1

  ---     Fields 9, 10, and 11 comprise a structure that ---        ---
          defines one VectorGroup. All VectorGroup                  
          structures (N~v~ occurrences) shall be                    
          specified consecutively.                                  

  9       VectorGroup type                               U8E        1

  10      Number of TransducerChannels in the            U8C        1
          VectorGroup (NT~v~)                                       

  11      VectorGroup member list                        array of   NT~v~
                                                         U8E        

  ---     ControlGroup information sub-block             ---        ---

  12      Number of ControlGroups (N~c~)                 U8C        1

  ---     Fields 13, 14, and 15 comprise a structure     ---        ---
          that defines one ControlGroup. All                        
          ControlGroup structures (N~c~ occurrences)                
          shall be specified consecutively.                         

  13      ControlGroup type                              U8E        1

  14      Number of TransducerChannels in the            U8C        1
          ControlGroup (NT~c~)                                      

  15      ControlGroup member list                       array of   NT~c~
                                                         U8E        

  ---     TransducerChannel proxy definition sub-block   ---        ---

  16      Number of TransducerChannel proxies (N~p~)     U8C        1

  ---     Fields 17, 18, 19, and 20 comprise a structure ---        ---
          that defines one TransducerChannel proxy. All             
          proxy definition structures (N~p~ occurrences)            
          shall be specified consecutively.                         

  17      TransducerChannel number of the                U8E        1
          TransducerChannel proxy                                   

  18      TransducerChannel proxy data set organization  U8E        1

  19      Number of TransducerChannels represented by    U8C        1
          this proxy (NT~p~)                                        

  20      TransducerChannel proxy member list            array of   NT~p~
                                                         U8E        

  ---     Checksum                                       U16C       2
  ------- ---------------------------------------------- ---------- --------

**7.3.2.8 Number of** **VectorGroups**

Data type: unsigned octet integer used for enumeration (U8C, 1 octet)

This field identifies the number of VectorGroups that follow.

**7.3.2.9** **VectorGroup type**

Data type: unsigned octet integer used for enumeration (U8E, 1 octet)

This field contains the relationship between the TransducerChannels
comprising the specific VectorGroup. It is defined by the enumeration in
Table [40]{.mark}.

Table 40---Enumeration of VectorGroup types

  --------- --------------------------------------------------------------
  Value     Meaning

  0         an arbitrary relation

  1         x, y, z right hand rectangular spatial coordinates

  2         ρ, φ, z right hand cylindrical spatial coordinates

  3         r, θ, φ right hand spherical spatial coordinates

  4         latitude, longitude, altitude planetary coordinates

  5         in-phase, quadrature temporal coordinates

  6         red, green, blue color coordinates

            

            

            

            

            

            

            

            

  7-127     Reserved

  128-255   open to manufacturers
  --------- --------------------------------------------------------------

The arbitrary relation, when the enumeration value is equal to zero,
shall be used to convey VectorGrouping semantics not specifically
enumerated by this subclause, but deemed necessary by the
TransducerChannel manufacturer, for the correct operation or
interpretation of the data related to the TransducerChannels that are
members of the VectorGroup.

The arbitrary relation may be used to convey that correct behavior of
TransducerChannels with coupling terms in the calibration assumes that
all TransducerChannels involved are triggered at the same time.

**7.3.2.10 Number of TransducerChannels in the** **VectorGroup**

Data type: unsigned octet integer used for enumeration (U8C, 1 octet)

This field identifies the number of TransducerChannels in the group,
which is the number of entries required in the list described in
7.3.2.11.

**7.3.2.11** **VectorGroup member list**

Data type: an array of unsigned octet integers used for enumeration
(U8E, 0 to 255 octets)

This field contains a one-dimensional array (list) of 1-octet elements.
Each element is the TransducerChannel number for a member in the
specific VectorGroup. The values of the elements in this list shall be
in the sequence specified by the *VectorGroup type* field.

An element with value zero shall indicate that the TransducerChannel
does not implement this particular element of the enumerated
relationship. For example, a two axis vector measurement implemented by
TransducerChannels 1, x, and 2, y, may be specified by designating the
*VectorGroup type* ([7.3.2.9]{.mark}) as 1 (x, y, z) with the
*VectorGroup member list* of (1, 2, 0). The value zero shall not appear
in the *VectorGroup member list* for a VectorGroup of *VectorGroup type*
'arbitrary relation.'

A TransducerChannel may not be represented in multiple VectorGroups.

7.3.2.12 Number of ControlGroups

Data type: unsigned octet integer used for enumeration (U8C, 1 octet)

This field identifies the number of ControlGroups that follow.

**7.3.2.13 ControlGroup type**

Data type: unsigned octet integer used for enumeration (U8E, 1 octet)

This field contains the relationship between the TransducerChannels
comprising the specific ControlGroup. It is defined by the enumeration
in [Table 41]{.mark}.

Table 41---Enumeration of ControlGroup types

+-----+-----+-----------------------------------------------------------+
| Va  | En  | Meaning                                                   |
| lue | try |                                                           |
+-----+-----+-----------------------------------------------------------+
| 0   |     | Reserved                                                  |
+-----+-----+-----------------------------------------------------------+
| 1   | 1   | Analog event sensor TransducerChannel,                    |
|     |     |                                                           |
|     | 2   | Analog input sensor TransducerChannel                     |
|     |     |                                                           |
|     | 3   | Upper threshold embedded actuator TransducerChannel       |
|     |     |                                                           |
|     | 4   | Hysteresis embedded actuator TransducerChannel            |
+-----+-----+-----------------------------------------------------------+
| 2   | 1   | Sensor TransducerChannel (any type)                       |
|     |     |                                                           |
|     | 2   | High pass filter embedded actuator TransducerChannel      |
|     |     |                                                           |
|     | 3   | Low pass filter embedded actuator TransducerChannel       |
|     |     |                                                           |
|     | 4   | Scale factor embedded actuator TransducerChannel          |
+-----+-----+-----------------------------------------------------------+
| 3   | 1   | TransducerChannel (any type)                              |
|     |     |                                                           |
|     | 2   | Sample interval embedded actuator TransducerChannel       |
+-----+-----+-----------------------------------------------------------+
| 4   | 1   | Digital event sensor TransducerChannel                    |
|     |     |                                                           |
|     | 2   | Digital input sensor TransducerChannel                    |
|     |     |                                                           |
|     | 3   | Event pattern embedded actuator TransducerChannel         |
+-----+-----+-----------------------------------------------------------+
| 5   | 1   | Time interval sensor TransducerChannel                    |
|     |     |                                                           |
|     | 2   | TransducerChannel number of the transducer that causes    |
|     |     | the output of the time interval sensor to be latched.     |
+-----+-----+-----------------------------------------------------------+
| 6   | 1   | Time-of-day sensor TransducerChannel                      |
|     |     |                                                           |
|     | 2   | TransducerChannel number of the transducer that causes    |
|     |     | the output of the time-of-day sensor to be latched.       |
+-----+-----+-----------------------------------------------------------+
| 7   | 1   | TransducerChannel number of an event sensor used to       |
|     |     | trigger other transducers.                                |
|     | 2   |                                                           |
|     |     | The number, N, of transducers triggered by the event      |
|     | --- | sensor.                                                   |
|     |     |                                                           |
|     |     | The remaining N entries give a list of TransducerChannels |
|     |     | triggered by the event                                    |
+-----+-----+-----------------------------------------------------------+
| 8   | 1   | TransducerChannel (any type),                             |
|     |     |                                                           |
|     | 2   | Embedded time delay actuator TransducerChannel            |
+-----+-----+-----------------------------------------------------------+
| 9-  |     | Reserved for future expansion                             |
| 127 |     |                                                           |
+-----+-----+-----------------------------------------------------------+
| 1   |     | open to manufacturers                                     |
| 28- |     |                                                           |
| 255 |     |                                                           |
+-----+-----+-----------------------------------------------------------+

Enumerations 1 and 4 may be used to identify the embedded actuator
TransducerChannels used to set up an event sensor. They also identify a
sensor TransducerChannel that may be used to read the level of the
signal in an analog event sensor or the current pattern input to a
digital event sensor.

Enumeration 2 may be used to identify the embedded actuator
TransducerChannels used to set the high pass filter, low pass filter,
and scale factor associated with a sensor of any type.

Enumeration 3 is used to identify an embedded actuator TransducerChannel
that may be used to set the *TransducerChannel sampling period*.

**7.3.2.14 Number of TransducerChannels in the ControlGroup**

Data type: unsigned octet integer used for enumeration (U8C, 1 octet)

This field identifies the number of TransducerChannels in the group,
which is the number of entries required in the list described in
[7.3.2.15]{.mark}.

**7.3.2.15 ControlGroup member list**

Data type: an array of unsigned octet integers used for enumeration
(U8E, 0 to 255 octets)

This field contains a one-dimensional array (list) of 1-octet elements.
Each element is the TransducerChannel number for a member in the
specific ControlGroup. The values of the elements in this list shall be
in the sequence specified by the *ControlGroup type* field.

An element with value zero shall indicate that the TransducerChannel
does not implement this particular element of the enumerated
relationship. For example, a ControlGroup describing an analog event
sensor that implements the ability to change the threshold and
hysteresis but does not implement a sensor to read the analog input
could be specified by (1,0,2,3), where the TransducerChannel number for
the event sensor is 1, for the threshold actuator is 2 and the
hysteresis actuator is 3.

NOTE---a TransducerChannel may be represented in multiple ControlGroups.

**7.3.2.16 Number of TransducerChannel proxies**

No change to text for the remainder of 7.3. Paragraph numbers and
Table/Figure numbers ripple.

Incidental change TransducerChannel TEDS

**7.4.2.2 Calibration key**

Data type: unsigned octet integer used for enumeration (U8E, 1 octet)

This field contains an enumeration that denotes the calibration
capabilities of this TransducerChannel. Table [43]{.mark} provides the
list of enumerated values and their meanings. The column labeled "Name"
defines manifest constants to symbolize the enumerated values, and these
names are used throughout the remainder of this standard.

Table 43---Enumeration of calibration keys

  ------------- --------------------------------------------- -------------------
  Value         Calibration capability                        Name

  0             No calibration information needed or provided CAL_NONE
                by the TBIM. This implies that there is no    
                Calibration TEDS associated with this         
                TransducerChannel. See Note.                  

  1             Calibration information provided as a         CAL_SUPPLIED
                Calibration TEDS, as specified in 7.5.        
                Correction is performed outside of the TBIM.  

  2             (reserved)                                    \-

  3             Calibration information is provided but in a  CAL_CUSTOM
                form that is not described in this standard.  
                Correction is performed outside of the TBIM.  
                See Note.                                     

  4             Calibration information is provided as a      TBIM_CAL\_ SUPPLIED
                Calibration TEDS, as specified in 7.5.        
                Correction is applied in the TBIM. See        
                7.5.1.2 for additional details.               

  5             Calibration information is provided as a      TBIM_CAL_SELF
                Calibration TEDS, as specified in 7.5, and is 
                applied in the TBIM. The calibration is       
                adjusted by a self-calibration capability.    
                See 7.5.1.2 for additional details.           

  6             Calibration information is provided but in a  TBIM_CAL_CUSTOM
                form that is not described in this standard.  
                It may be a manufacturer-defined TEDS.        
                Correction is performed in the TBIM. See      
                Note.                                         

  7-255         Reserved                                      ---

  Note---If the                                               
  Calibration                                                 
  TEDS is                                                     
  accessed, the                                               
  Calibration                                                 
  TEDS Length                                                 
  shall be zero                                               
  ------------- --------------------------------------------- -------------------

**7.4.2.2.1 System corrections**

*Calibration key* enumerations CAL_SUPPLIED or CAL_CUSTOM are to be used
when the correction is performed in the NCAP, a host processor or
elsewhere in the system.

**7.4.2.2.2 TBIM corrections**

*Calibration key* enumerations TBIM_CAL_SUPPLIED and TBIM_CAL_SELF are
to be used when the correction is performed in the TBIM using the
correction method specified in [7.5.1.1]{.mark} and information stored
in the Calibration TEDS ([7.5.3]{.mark}). TBIM_CAL_CUSTOM is used when
the correction method is **not** the one specified in [7.5.1.1.]{.mark}

**7.4.2.3 TransducerChannel type key \<\<*No change\>\>***

**7.4.2.4 Physical units**

Data type: physical units (UNITS, 10 octets).

The physical units that apply to the TransducerChannel data. If the
*Calibration key* is CAL_SUPPLIED or CAL_CUSTOM, the physical units
apply only to the TransducerChannel data *after* correction for the case
of sensors, or *before* correction for the case of actuators.

See [4.11]{.mark} for details on how to construct the value placed in
the *Physical units* fields.

**7.4.2.5 Design operational lower range limit \<\<*No change\>\>***

**7.4.2.6 Design operational upper range limit \<\<*No change\>\>***

**7.4.2.7 Worst case uncertainty \<\<*No change\>\>***

**7.4.2.8 Self-test key \<\<*No change\>\>***

**7.4.2.9 Data model**

Data type: unsigned octet integer used for enumeration (U8E, 1 octet)

This field describes the data model used when issuing [Read
TransducerChannel data](#_Read_TransducerChannel_data_1) or [Write
TransducerChannel data](#_Write_TransducerChannel_data) commands to this
TransducerChannel. Values are enumerated in [Table 46]{.mark}.

Table 46---Enumeration of data models

  ----------- -------------------------------- ---------------------------
  Value       Model                            Constraint on\
                                               data model length

  0           N-octet integer (unsigned)       0≤N≤8

  1           Single precision real            N=4

  2           Double precision real            N=8

  3           N-octet fraction (unsigned)      0≤N≤8

  4           Bit sequence                     0≤N≤255

  5           Long integer (unsigned)          9≤N≤255

  6           Long fraction (unsigned)         9≤N≤255

  7           Time of day                      N=8

  8 - 255     Reserved for future expansion    ---
  ----------- -------------------------------- ---------------------------

There are two differences between the integer forms (enumeration zero
and five) and fractional forms (enumeration three and six):

The radix point (which divides integer from fractional bits) is to the
right of the least significant bit for N-octet integer. It is
immediately to the right of the most significant bit for N-octet
fraction.

Justification of the significant bits differs, as explained in the
*Model significant bits* field ([xxx]{.mark}).

The use of enumerations 5 and 6 is expected to be rare. An NCAP is not
expected to process data with these enumerations but may pass them on
unprocessed to the entity requesting the data.

The N-octet fraction type may be used to keep the multinomial
coefficients (see [xxx]{.mark}) within representable bounds and to avoid
overflows when converting the data to physical units.

The bit sequence data model is for collections of bits that have no
numeric value. An example of this type is the position of each switch in
a bank of switches. Bit significance is user defined.

Boolean data (such as {0,1} or {false, true}) shall be represented as a
bit sequence with a length of one octet, in which the data resides in
the least significant bit.

**7.4.2.10 Data model length \<\<*No change\>\>***

**7.4.2.11 Model significant bits**

Data type: unsigned 16-bit integer used for counting (U16C, 2 octets)

When the *Data model* is N-octet integer (enumeration 0 or 5) or N-octet
fraction (enumeration 3 or 6), the value of this field is the number of
bits that are significant.

> *For example, if data from a TransducerChannel comes from a 12-bit
> ADC, then:*
>
> *Data model = 0 (N-octet integer)*
>
> *Data model length = 2 (the number of octets needed to hold 12 bits)*
>
> *Model significant bits = 12*

When the *Data model* is N-octet integer, N-octet fraction, long integer
or long fraction, the *Model significant bits* shall not exceed eight
times the *Data model length*.

When the *Data model* is N-octet integer or long integer, the data bits
shall be right justified within the octet stream. *Model significant
bits* specifies the number of bits that are significant. A value of zero
is illegal.

When the *Data model* is N-octet fraction or long fraction, the data
bits shall be left justified within the octet stream. *Model significant
bits* is ignored.

When the *Data model* is single or double precision real (enumerations
one or two), the value of this field is the number of bits in the
TransducerChannel's signal converter.

When the *Data model* is Time of day, *Model significant bits* is
ignored.

Incidental change Calibration TEDS

**7.5.1.2 Application**

If the value of the *Calibration key* field (7.4.2.2) in the
TransducerChannel TEDS is CAL_SUPPLIED, the correction algorithm shall
be performed in the NCAP, a host processor or elsewhere in the system.
It is recommended that it be performed in the NCAP.

If the value of the *Calibration key* field is TBIM_CAL_SUPPLIED or
TBIM_CAL_SELF, then the correction algorithm shall be performed in the
TBIM.

All remaining text in 7.5.1.2 remains unchanged.

Incidental change Commisioning TEDS

**7.10.2 Data block**

Table 63 shows the structure of the data block for this TEDS. The
content is user defined.

Table 63---Structure of the Commissioning TEDS data block

  ----------- --------------------------------- -------------- -------------
  **Field**   **Description**                   **Type**       **\# octets**

  ---         TEDS length                       U32L           4

                                                               

  1           Character set                     U8E            1

  2           Character code                    U8E            1

  3           Language                          U8E            1

  4           Length, in octets                 U8C            1

  5           Parameter name                    U8E            N

  ---         Checksum                          U16C           2
  ----------- --------------------------------- -------------- -------------

The manufacturer shall determine the size of this TEDS, but as a
minimum, the TEDS shall be at least 42 octets to accommodate a
32-character parameter name.

Incidental change to text that was located at 5.8.6 in D2.02, but moved
to Appendix J by Proposal P03-002

**J.4 Trigger logic based on event recognition**

The functional block diagram in Figure J.4 depicts a TransducerChannel
that is triggered by an event sensor. An event sensor may have
additional embedded actuators to implement features such as a
programmable analog threshold and hysteresis or a programmable digital
pattern.

> Figure J.4

The event sensor has a special hardware relationship to one or more
TransducerChannels. This should be identified as a ControlGroup with
enumeration 7 in the Meta TEDS. A trigger message issued to the event
sensor causes the event sensor to begin monitoring. The occurrence of
the event, which may cause the Data Transport Logic to issue a trigger
acknowledgment (if appropriate), may also be used to trigger the
associated TransducerChannel(s).

The manufacturer may not honor a trigger message addressed to the
TransducerChannels so configured.