**IEEE P1451.3 Proposal**

+-----------------+----------------------------------------------------+
| Proposal Title: | Removal of the Transducer Block                    |
+-----------------+----------------------------------------------------+
| Proposal        | 03-007                                             |
| Number:         |                                                    |
+-----------------+----------------------------------------------------+
| Revision        | A                                                  |
| Number:         |                                                    |
+-----------------+----------------------------------------------------+
| Date:           | 37666.38                                           |
+-----------------+----------------------------------------------------+
|                 |                                                    |
+-----------------+----------------------------------------------------+
| Name:           | Lee Eccles                                         |
+-----------------+----------------------------------------------------+
| Company:        | Boeing                                             |
+-----------------+----------------------------------------------------+
| Phone Number:   | 206-655-2824                                       |
+-----------------+----------------------------------------------------+
| Fax Number:     | 206-655-7724                                       |
+-----------------+----------------------------------------------------+
| Email Address:  | [lee.h.                                            |
|                 | eccles@boeing.com](mailto:Lee.h.eccles@boeing.com) |
+-----------------+----------------------------------------------------+
|                 |                                                    |
+-----------------+----------------------------------------------------+
| Proposal        | Initial Draft                                      |
| Status:         |                                                    |
|                 | Revised Draft                                      |
|                 |                                                    |
|                 | [X]{.underline} Ready for Vote                     |
+-----------------+----------------------------------------------------+
| Impacts:        | \_\_                                               |
|                 |                                                    |
|                 | \_\_                                               |
+-----------------+----------------------------------------------------+
| Action:         | \_ [X]{.underline}\_ Approved                      |
|                 |                                                    |
|                 | \_\_ Approved with changes                         |
|                 |                                                    |
|                 | \_\_ Rejected                                      |
|                 |                                                    |
|                 | \_\_ Returned for revision                         |
+-----------------+----------------------------------------------------+
|                 |                                                    |
+-----------------+----------------------------------------------------+

**Background:**

This proposal advocates removal of the existing clause covering the
Transducer Block. This position has evolved from several efforts to
reconcile the Transducer Block specification with the IEEE 1451.1
Information Model, without success. In an effort to expose the
background thinking that led to this proposal, related e-mail
discussions are included below. To follow the discussion in time
sequence, read from the bottom up.

**\*\*\* Discussion 1\*\*\***

From: Robert N. Johnson \[robertj@telemonitor.com\]

> Sent: Thursday, February 13, 2003 3:40 PM
>
> To: Slack, Mark B
>
> Cc: Malchodi, Larry A; Catlin, Wayne L; Eccles, Lee H
>
> Subject: RE: Dot0 meetings and T-block

Thrusting up into dot1? Thank you for that image.

> However, that is essentially what I think we need to do. Dot1 should
> support
>
> the interface as we conclude that it needs to be configured. How can
> we brag
>
> about a \"plug-and-play\" standard if we don\'t have a common way of
> handling
>
> discovery and dynamic configuration? At the network level I mean, not
> the
>
> transducer bus level.
>
> By the way, I believe that these issues have been addressed and solved
> by
>
> other network information transport services and I really think we
> need to
>
> review what they did. In particular I think we need to get up to speed
> on
>
> the Object Management Group (OMG) and COBRA. The OMG was working on
> their
>
> own standard for smart sensor a couple of years ago but I haven\'t
> kept up.
>
> \--Robert
>
> \-\-\-\--Original Message\-\-\-\--

From: Slack, Mark B \[mailto:mark.b.slack@boeing.com\]

> Sent: Thursday, February 13, 2003 5:59 PM
>
> To: robertj@telemonitor.com
>
> Cc: Malchodi, Larry A; Catlin, Wayne L; Eccles, Lee H
>
> Subject: RE: Dot0 meetings and T-block
>
> Do not lament tossing that material out. It doesn\'t bother me one
> whit,
>
> Robert. In fact, it is a relief. There is just no \"good\" way to do a
>
> partial job.
>
> My gripe with Dot 1 is that it side-steps the issue of configuring a
>
> programmable device at runtime. It provides the hooks to do so by
>
> implementing read() and write() methods at a primative level through
> the
>
> T-Block, but that decision guarantees that the application SW must
> have
>
> intimate knowledge of the DotX bus and the device. Many of the Dot0
>
> concepts need to be thrust \"up\" into the Dot1 model to achieve the
> goals you
>
> have articulated.

Mark

> \-\-\-\--Original Message\-\-\-\--

From: Robert N. Johnson \[mailto:robertj@telemonitor.com\]

> Sent: Thursday, February 13, 2003 1:50 PM
>
> To: Slack, Mark B
>
> Subject: FW: Dot0 meetings and T-block
>
> Mark:
>
> Thanks for the support to my first epistle. Here is the recent
> discussion
>
> with Jay. I feel bad that we are proposing to toss out a bunch of your
> work,
>
> but save it for dot0!
>
> \--Robert
>
> \-\-\-\--Original Message\-\-\-\--

From: Robert N. Johnson \[mailto:robertj@telemonitor.com\]

> Sent: Thursday, February 13, 2003 4:39 PM
>
> To: jay_warrior@agilent.com; david.potter@ni.com;
> jwiczer@sensorsynergy.com;
>
> Kang.Lee@nist.gov; larry.a.malchodi@boeing.com;
> lee.h.eccles@boeing.com;
>
> stan_woods@agilent.com; chens@aeptec.com; TRLICHT@bk.dk
>
> Subject: RE: Dot0 meetings and T-block
>
> Jay:
>
> I think we agree on the ideals, but perhaps not on the practical issue
> of
>
> whether there should be a T-block specified in dot3. I say not. The
> dotx
>
> standards should include only the unique required extensions to the as
> yet
>
> undefined dot0 interface and T-block. And since dot3 will predate
> dot0, and
>
> is anticipated to be the model for a lot of its content, we can see to
> it
>
> that the dot0 interface covers everything that dot3 needs so there is
> no
>
> requirement for a unique extension.
>
> Dot0 won\'t identify the interface as dot3 however, I still feel
> strongly
>
> that the network side \"clients\" should generally not know or care
> which of
>
> the dotx interfaces are implemented.
>
> \--Robert
>
> \-\-\-\--Original Message\-\-\-\--

From: jay_warrior@agilent.com \[mailto:jay_warrior@agilent.com\]

> Sent: Thursday, February 13, 2003 4:18 PM
>
> To: robertj@telemonitor.com; jay_warrior@agilent.com;
> david.potter@ni.com;
>
> jwiczer@sensorsynergy.com; Kang.Lee@nist.gov;
> larry.a.malchodi@boeing.com;
>
> lee.h.eccles@boeing.com; stan_woods@agilent.com; chens@aeptec.com;

TRLICHT@bk.dk

> Subject: RE: Dot0 meetings and T-block
>
> Dear Robert,
>
> I think we are saying fundamentally the same things. If there isn\'t
> common
>
> agreement that we want a core \"tblock\" functionality that is mostly
> common
>
> across all the standards, dot0 won\'t succeed. (By implication, if we
> can get
>
> this agreement, then dot0 is a good place to try and develop the
>
> specification). The main sticking point I see will be that if we do
> put
>
> functionality into dot0, then there is relatively little reason for
> the
>
> individual standards to have their own interface specifications, and
> thats a
>
> bit hard to convince people of.

Regards,

> -jay
>
> Jay Warrior, Communication Solutions Department (T) 650-485-2086
>
> Agilent Laboratories, 3500 Deer Creek Road, Palo Alto, CA 94304-1392
>
> \-\-\-\--Original Message\-\-\-\--

From: Robert N. Johnson \[mailto:robertj@telemonitor.com\]

> Sent: Thursday, February 13, 2003 12:59 PM
>
> To: jay_warrior@agilent.com; david.potter@ni.com;
>
> jwiczer@sensorsynergy.com; Kang.Lee@nist.gov;
>
> larry.a.malchodi@boeing.com; lee.h.eccles@boeing.com;
>
> stan_woods@agilent.com; chens@aeptec.com; TRLICHT@bk.dk
>
> Subject: RE: Dot0 meetings and T-block
>
> Jay:

Thanks for your candor.

> I am very sensitive to this discussion because I spent a whole bunch
> of
>
> money (well, by my scale anyway) developing products based on dot2
> only to
>
> find out that nobody except academic research labs would buy them
> because
>
> there was no standard way to connect the NCAPs to anything over the
> network.
>
> I agree very strongly that we need to present a common interface to
> the
>
> network, not a hodge-podge, and that dot1 is a valid way to do that.
> Not by
>
> any means the only way, or maybe even the best way, but a valid way
> and one
>
> that I am willing to support.
>
> My point is that the best way to guarantee a hodge-podge of unrelated
>
> interfaces is to continue to attempt to include a dot1 T-block in each
> of
>
> the individual standards. Let\'s define one interface, agree on it,
> and be
>
> done with it. We can define that interface in dot0 and either include
> its
>
> T-block in dot0 or in dot1 when it comes up for review next year.
>
> And we had better be looking equally hard at information distribution
>
> middleware products like COBRA, XML, .NET, etc. that already have
> support
>
> instead of counting on device driver vendors to write new software for
> our
>
> products.
>
> If we don\'t change our approach to providing a path to integrate 1451
> into
>
> mainstream products, then I don\'t know how we can justify the effort
> that we
>
> are putting into it. Making 1451 relevant instead of an academic
> exercise is
>
> the only reason that I agreed to take on the dot0 challenge and I
> guess I
>
> have a higher expectation of its utility than you expressed.
>
> \--Robert
>
> \-\-\-\--Original Message\-\-\-\--

From: jay_warrior@agilent.com \[mailto:jay_warrior@agilent.com\]

> Sent: Thursday, February 13, 2003 2:45 PM
>
> To: robertj@telemonitor.com; david.potter@ni.com;
> jwiczer@sensorsynergy.com;
>
> jay_warrior@agilent.com; Kang.Lee@nist.gov;
> larry.a.malchodi@boeing.com;
>
> lee.h.eccles@boeing.com; stan_woods@agilent.com; chens@aeptec.com;
>
> TRLICHT@bk.dk
>
> Subject: RE: Dot0 meetings and T-block

Dear All,

Well, he did ask for an opinion\...\...

> Forgive my bluntness. There is unfortunately a common misapprehension
> that
>
> the dot1 \"tblock\" is some sort of dot1 imposed tax. Excuses are
> being made
>
> based on the \"non-adoption\" of dot1 to suggest that there is no need
> for a
>
> \"dot1 tblock\". I hope the individual dot standards realize that they
> need
>
> to provide a usable interface for a device driver vendor to write
> software
>
> that integrates their product into an application. Having a
> hodge-podge of
>
> \"command-codes\" and methods which are all different is not conducive
> to
>
> making your implementation easy to use, or indeed doing anything to
> leverage
>
> (if you believe there is something, from the 1451 family).
>
> The dot1 tblock was an attempt, looking towards the transducer
> interface, to
>
> find a common model or functionality that would support what are
> currently
>
> codified in the dot0 work as common principles. Of course we didn\'t
> have the
>
> dot0 work, but did have dot2 as a model. If you decide you don\'t want
> to use
>
> the common functionality you end up with a very fat driver and a lot
> of code
>
> to handle quirky states and interactions because it can\'t leverage
> the
>
> common behavioral principles captured in the common infrastructure. I
> have
>
> been consistent in saying that the right interface should come first
> and any
>
> mapping come later, the dot1 effort is a model or placeholder or
> guideline,
>
> however you want to consider it, towards achieving this common
>
> functionality.
>
> If we think that transferring the problem to a dot0 effort is going to
> make
>
> any difference until the underlying fundamental principles are
> accepted, we
>
> are kidding ourselves. From a process standpoint dot0 might buy some
> time
>
> to work towards this common functionality, but if the individual dot
> efforts
>
> aren\'t even willing to look at the relatively generic dot0 framework,
> I have
>
> little hope or expectation of anything useful coming from dot0.

Regards,

> -jay
>
> Jay Warrior, Communication Solutions Department (T) 650-485-2086
>
> Agilent Laboratories, 3500 Deer Creek Road, Palo Alto, CA 94304-1392
>
> \-\-\-\--Original Message\-\-\-\--

From: Robert N. Johnson \[mailto:robertj@telemonitor.com\]

> Sent: Thursday, February 13, 2003 9:51 AM
>
> To: David Potter; James Wiczer; Jay Warrior; Kang Lee; Larry A.
>
> Malchodi; Lee H. Eccles; Stan P. Woods; Steven C. Chen; Torben Licht
>
> Subject: Dot0 meetings and T-block
>
> The dot0 study group still is not holding meetings pending the
> completion of
>
> the dot3 balloting draft.
>
> I have noticed both in the dot3 working group and in the recent
> minutes of
>
> the dot4 group considerable confusion and concern about the
> requirement to
>
> include a dot1 T-block in each of the other standards. In both of
> these
>
> groups there has been speculation as to whether the T-block definition
>
> should be omitted from the individual specifications and somehow deal
> with
>
> in dot0. Let me say that I personally agree with that approach and am
>
> willing to take responsibility for sorting the T-block issue out as
> part of
>
> the dot0 activities.
>
> We have said that we want to move toward a common definition of the
> core
>
> functionality of a 1451 device and that functionality should be
> defined in
>
> dot0. This will provide intra-family interoperability and will free
> future
>
> individual dot groups to concentrate on the unique features of their
>
> implementations. There should be a common interface to all of these
> groups
>
> that supports dot1 and we shouldn\'t have to reinvent it for each
> physical
>
> layer. Actually, we definitely do not want to write custom T-blocks
> for each
>
> dot group because that implies that the client (on the other end of
> the
>
> network) has to know what flavor of device they are trying to reach.
>
> 1451 should try to present a common interface to network clients. We
> should
>
> not encourage differing approaches by having each dotx group write a
> custom
>
> T-block. If there are custom extensions to the common T-block required
>
> because of unique characteristics of the physical layer then that
> should be
>
> permitted, but it should be the exception, not the rule.

Just my opinion. Comments solicited.

> \--Robert

**\*\*\* Discussion 2 \*\*\***

While Discussion 1 occurred, there was a parallel effort to capture the
existing T-Block specification, transform it into an object model of for
the standard, and move the new material to an Annex. This effort arose
from suggestions offered during a special session of the T-Block
subcommittee on 02/10/03, primarily attributed to Charles Jones. To
follow the discussion in time sequence, read from the bottom up.

From: Jones Charles H Civ 412 TW/ENTI \[charles.jones@edwards.af.mil\]

> Sent: Friday, February 14, 2003 2:51 PM
>
> To: Catlin, Wayne L; Malchodi, Larry A; Eccles, Lee H; Slack, Mark B;
>
> Jones Charles H Civ 412 TW/ENTI
>
> Subject: RE: Telecon to discuss transition of p1451.5, D2.00, Clause 9
>
> to Annex K

All,

> I would really like to see the current object model in the standard.
>
> However, I am starting to lean towards excluding it completely at this
>
> point. The following points are to convince myself as much as anybody
> else
>
> but I think they summarize the situation.
>
> 1\. We need to get the standard out ASAP.
>
> 2\. Any presentation of the T-block must discuss the relation to the
> dot1.
>
> If it does not, and we specify something that is not compatible with
> the
>
> dot1 then we destroy the coherency of the family of standards. And
> probably
>
> seriously harm the overall acceptance and implementation of the
> standards.
>
> 3\. A cursory reference to dot1 or a disclaimer regarding our not
> fully
>
> stating a dot1 T-block specification: a) begs too many questions and
> b)
>
> makes the working group look incompetent (maybe a little blunt, but
>
> essentially the truth).
>
> 4\. The current object model is mostly meaningless if we try to remove
> the
>
> T-block object.
>
> 5\. The effort to fully specify the dot3 T-block in relation to the
> dot1 is
>
> best estimated in manmonths and would take 6-9 calendar months to work
> it
>
> through the committee.
>
> 6\. Among the working group as a whole, there is little interest in
> (or
>
> understanding of) this object model. This whole thing is controversial
> and
>
> even its utility has been debated.
>
> 7\. At least in my opinion, the proposal by Mark Slack to replace the
> current
>
> model is incomplete in that it does not define the relation of the
> T-Block
>
> to the TBC and TBIM. I also have concerns regarding its completeness
> in
>
> relating the dot3 T-Block to the dot1 model. Completion of this
> approach
>
> would also take significant mantime and calendar time.
>
> I\'ve now studied the problem enough for my subconscious to work on it
> over
>
> the weekend. Maybe I\'ll have a different take on Tues - but I doubt
> it.

Regards,

Charles

> \-\-\-\--Original Message\-\-\-\--

From: Catlin, Wayne L \[mailto:wayne.catlin@boeing.com\]

> Sent: Friday, February 14, 2003 12:01 PM
>
> To: Malchodi, Larry A; Eccles, Lee H; Slack, Mark B; Jones, Charles H,
>
> Ph.D.
>
> Subject: Telecon to discuss transition of p1451.5, D2.00, Clause 9 to
>
> Annex K
>
> When: Tuesday, February 18, 2003 8:00 AM-9:00 AM (GMT-08:00) Pacific
> Time
>
> (US & Canada); Tijuana.
>
> Where: Conf Rm 3-800.5, 53C6
>
> \*\~\*\~\*\~\*\~\*\~\*\~\*\~\*\~\*\~\*
>
> This is a meeting reminder for the subject telecon that we started
>
> discussion on earlier this morning.

Charles, we can call you from our conference room at 8:00 am.

Wayne Catlin

> \-\-\-\--Original Message\-\-\-\--

From: Slack, Mark B

> Sent: Wednesday, February 12, 2003 12:28 PM
>
> To: \'Jones, Charles\'
>
> Cc: Eccles, Lee H; Catlin, Wayne L; Malchodi, Larry A
>
> Subject: Annex K

Charles,

> Lee isolated the material from D2.00, Clause 9, and wrapped it as an
> Annex. The text is unaltered, although paragraph numbers, figures, and
> table numbers we updated. Attached is the result. I don\'t know how
> far you have gotten with this, but I send you this document with the
> hope that it might give you a jump start on the task at hand.
>
> I had an inclination to take a stab at the transitional text, but
> there is no sense in doing this work in parallel with your effort.
> I\'d like you to take the first cut here. Key concepts include: (a)
> this annex presents an object model of entities, functions, and
> services fully specified in the body of the standard, and (b) the
> annex is informative and shall not be interpreted as authoritative;
> i.e., if the information model appears to conflict with the standard
> in any manner, the body of the standard governs.
>
> I believe there is no requirement within this annex to use
> \"IEEE1451_Dot3\" prefixes on class names, because we are no longer
> attempting to promote this material as the
> IEEE1451_Dot3TransducerBlock.
>
> Good luck, Sir. After you get your teeth into this, I\'d be glad to
> act as a sounding board, or offer any assistance I can.

Mark Slack

> Associate Technical Fellow
>
> Seattle, BCAG, Org B-XZ31, Mailstop 19-MW
>
> 3-800.5 Bldg \-\-- 206-662-4771
>
> 2-122.3 Bldg \-\-- 206-662-4744
>
> ATTACHMENT: \<\<AnnexK.doc\>\>

**\*\*\* Conclusions \*\*\***

The proposal to remove of this clause is offered reluctantly. Many
pragmatic observations supporting this decision have been offered in the
discussions provided above. The Working Group feels that the best
interests of manufacturers and end-users will not be served by further
delays. The Transducer Block for IEEE p1451.3 and other family members
will be developed in conjunction with IEEE p1451.0.

Although the material will not be included in the Standard, the
contributions of Carlos Lopez-Reyna (Scite Fair) and Mark Slack (Boeing)
will be passed to the Dot0 working group as foundation. The P1451.3
Working Group gratefully acknowledges their efforts.

**Proposal:**

# 1. Overview

This standard introduces the concept of a Transducer Bus Interface
Module (TBIM) and a Transducer Bus Controller (TBC) connected by a
Transducer Bus. A TBIM is a module that contains the bus interface,
signal conditioning, Analog-to-Digital and/or Digital-to-Analog
conversion and in many cases the transducer. A TBIM can range in
complexity from a single sensor or actuator to units containing many
transducers (sensors and actuators). A TBC is the hardware and software
in the NCAP or host processor that provides the interface to the
Transducer Bus. The Transducer Bus provides the communications path
between an NCAP or host processor and one or more TBIMs. Three types of
transducers are recognized by this standard.

A TransducerChannel is denoted \'smart\' in this context because of
three features:

--- It is described by a machine-readable, Transducer Electronic Data
Sheet (TEDS).

--- The control and data associated with the TransducerChannel are
digital.

--- Triggering, status, and control are provided to support the proper
functioning of the TransducerChannel.

A transducer bus controller (TBC), that may be part of a Network Capable
Application Processor (NCAP) or a host processor, controls a TBIM by
means of a dedicated digital bus. The bus controller or NCAP mediates
between the TBIM and a higher-level digital network, and may provide
local intelligence.

This standard provides for TBIMs that can be plugged into a system and
be used without having to add special drivers, profiles or make any
other changes to the system. This is referred to as "plug and play"
operation. The primary features that enable plug and play operation are
the TEDS and the basic command set. A TBIM may be added to or removed
from an active Transducer Bus with no more than a momentary impact on
the data being transferred over the bus. "Hot swap" is the term used to
refer to this feature.

This standard is organized as follows: Clause 1: "Overview" provides the
scope of this standard. Clause 2: "References" lists references to other
standards and documents that are useful in applying this standard.
Clause 3: "Definitions" provides definitions that are either not found
in other standards, or have been modified for use with this standard.
Clause 4 "Data types" defines the data types used in the standard.
Clause 5: "Smart transducer functional specification" specifies the
functions required of a TBIM and of each TransducerChannel it comprises.
Clause 6: "Commands" provides the command syntax and the expected
replies. Clause 7: "Transducer Electronic Data Sheet (TEDS)
specification" specifies the transducer electronic data sheet structure.
Clause 8: "Upper layers of the ISO model (layers 3 through 7)" specifies
the protocols used for the interface between the TBIM and the bus
controller. Clause 9 "Standard services offered by the Data Link Layer"
specifies the services provided by the Data Link layer to the upper
layers of the protocol stack. Clause 10: "Lower layers of the ISO model
(layers 1 and 2)" specifies the physical transducer interface between
the TBIM and the bus controller and the lower layers of the protocol
stack

## 1.3 Conformance

The philosophy underlying the conformance requirements of this subclause
is to provide the structure necessary to raise the level of
interoperability of transducers and systems built to this standard,
while leaving open opportunity for continued technical improvement and
differentiation.

A TBIM implementation shall be deemed in conformance with IEEE P1451.3
provided the following three requirements are met:

The TBIM supports the required functional performance specified in
Clause 5

The TBIM supports the required commands specified in Clause 6

--- The TBIM supports TEDS which have the format specified in Clause 7

--- The TBIM's physical interface implements the interface and protocols
defined in Clause 9.

As a minimum, a compliant TBIM must implement the following protocols
specified in clause 8:

--- Datagram protocol

--- Trigger protocol.

Command services protocol

Reply Protocol

NOTE---There are several features that are highly desirable, and are
supported by this standard, but are not practical to make into hard
requirements. It is desirable that the sense element for a sensor be an
integral part of the TBIM but for sensing elements like structural
strain gages and thermocouples this is not practical so it has not been
made into a hard requirement. In addition, it is very desirable that the
TEDS be located within the TBIM but there are systems where the
environment and/or the physical size make this impractical so the
standard allows the TEDS to be located remote from the TBIM.

A Transducer Bus Controller (TBC) implementation shall be deemed in
conformance with this standard provided it supports the hardware and/or
software required by the physical interface defined in Clause 9 and the
following protocols specified in clause 8:

--- Datagram protocol

--- Trigger protocol.

--- Command services protocol

### 6.1.3 Query TEDS commands

The first four paragraphs are unchanged.

When the Virtual TEDS attribute is set, the Read-only attribute shall
also be set and the TBIM shall return a zero for the \"Current size of
the TEDS\" and the \"Maximum TEDS size\" field. It becomes the
responsibility of the NCAP or the host processor to determine the sizes
and attributes that are returned to the calling application. If the file
cannot be located, the Unsupported attribute shall be set and the TBIM
shall return a zero for the \"Current size of the TEDS\" and the
\"Maximum TEDS size\" fields. If the file is found, the Invalid and
Unsupported attributes shall be cleared and the Read-Only attribute, the
\"Current size of the TEDS\" field, and the \"Maximum TEDS size\" field
shall be determined from the file attributes of the remote file in which
the TEDS resides.

Remaining paragraphs and Tables 20 and 21 are unchanged.

Table 22---TEDS attributes

  ----------- -----------------------------------------------------------
  Bit         Definition

  0 (lsb)     **Read-only** -- Set to a one if TEDS may be read but not
              written

  1           **Unsupported** - Set to one if TEDS is not supported by
              this TBIM

  2           **Invalid** - Set to one if the current TEDS image is
              invalid

  3           **Virtual TEDS** - This bit is set to one if this is a
              virtual TEDS. (A virtual TEDS is any TEDS that is not
              stored in the TBIM. The responsibility for accessing a
              virtual TEDS is vested in the NCAP or host processor.

  4           **Text TEDS** -- Set to one if the TEDS is text based.

  5           reserved

  6           reserved

  7 (msb)     reserved
  ----------- -----------------------------------------------------------

# 7. Transducer Electronic Data Sheet (TEDS) specification

TEDS are blocks of information in one of the formats defined in one of
the following subclauses. They are intended to be stored in non-volatile
memory within a TBIM. However, there are applications where this is not
practical, so the standard allows them to be stored in other places in
the users system. When stored in some location other than the TBIM, they
are referred to as \"virtual\" TEDS. The manufacturer of the
TransducerChannel is expected to provide the virtual TEDS but not to
store them in the TBIM. It is the responsibility of the users system to
provide a link between the only information that is guaranteed to be
available from the TBIM, that is the UUID, and the file that contains
the virtual TEDS in the system. The NCAP or host processor provides this
service if it is used. A TBIM may provide a mix of TEDS stored in the
TBIM and virtual TEDS. The response to the [Query
TEDS](#_Query_TEDS_commands) command (see 6.1.3) contains flags that
indicate whether or not the TEDS is supported and whether or not it is
virtual. A virtual TEDS is considered \"supported\" if the manufacturer
provided a file on some suitable media containing the information,
regardless of whether or not the user loaded it into the system.

In the tables in this section, some enumerations are *reserved* for
future versions of this standard and shall not be used. Enumerations
designated as *open to manufacturers* may be used to designate
conditions not described by the standard.

## I.4 Reading a TEDS {#i.4-reading-a-teds .Annex-2}

If the TEDS is listed as \"Virtual\", it cannot be read using procedure
detailed below, because the TEDS does not reside in the TBIM. It becomes
the obligation of the NCAP or host processor to locate and read a
virtual TEDS.

For a resident TEDS, provided that it is supported and its current
contents are valid, entire TEDS may be read in a sequence of operations
summarized as follows:

issue a [Read TEDS block](#_Read_TEDS_block_1) command.

wait for the reply

repeat the previous two steps until the entire TEDS is read.

The NCAP or host processor determines when to terminate the read process
using the current TEDS size or some other mechanism. It is not necessary
to read TEDS sequentially or completely. This is particularly important
when reading text-based TEDS, from which the system may only be
interested in the text presented in a specific language. However, it
should be noted that except for text-based TEDS the reading of a partial
TEDS will not allow the checksum to be used to verify that the TEDS was
read correctly. For Text-based TEDS, the header and each language block
within the TEDS has a separate checksum. The TBIM shall not return
octets if data is requested beyond the end of the TEDS.

### Remove all of Clause 10 (Draft 2.02) Transducer Block.