**IEEE P1451.3 Proposal**

+-----------------+----------------------------------------------------+
|                 |                                                    |
+-----------------+----------------------------------------------------+
| Proposal Title: | Self Identification Protocol                       |
+-----------------+----------------------------------------------------+
| Proposal        | 99-002                                             |
| Number:         |                                                    |
+-----------------+----------------------------------------------------+
| Revision        |                                                    |
| Number:         |                                                    |
+-----------------+----------------------------------------------------+
| Draft Version:  |                                                    |
+-----------------+----------------------------------------------------+
| Date:           | 11/01/99                                           |
+-----------------+----------------------------------------------------+
|                 |                                                    |
+-----------------+----------------------------------------------------+
|                 |                                                    |
+-----------------+----------------------------------------------------+
|                 |                                                    |
+-----------------+----------------------------------------------------+
| Name:           | L. Malchodi                                        |
+-----------------+----------------------------------------------------+
| Company:        | Boeing                                             |
+-----------------+----------------------------------------------------+
| Phone Number:   | 206 655-5695                                       |
+-----------------+----------------------------------------------------+
| Fax Number:     | 206 655-7724                                       |
+-----------------+----------------------------------------------------+
| Email Address:  | larry.a.malchodi@boeing.com                        |
+-----------------+----------------------------------------------------+
|                 |                                                    |
+-----------------+----------------------------------------------------+
|                 |                                                    |
+-----------------+----------------------------------------------------+
|                 |                                                    |
+-----------------+----------------------------------------------------+
| Proposal        | [\_x\_]{.underline} Initial Draft                  |
| Status:         |                                                    |
|                 | [\_\_\_]{.underline} Revised Draft                 |
|                 |                                                    |
|                 | [\_\_\_]{.underline} Ready for Vote                |
+-----------------+----------------------------------------------------+
| Action:         | [\_\_\_]{.underline} Approved                      |
|                 |                                                    |
|                 | [\_\_\_]{.underline} Approved with changes         |
|                 |                                                    |
|                 | \_\_\_ Rejected                                    |
|                 |                                                    |
|                 | \_\_\_ Returned for revision                       |
+-----------------+----------------------------------------------------+
|                 |                                                    |
+-----------------+----------------------------------------------------+

Summary of Issue:

A method must be provided to uniquely identify a specific TBIM from many
others on the same transducer bus. This proposal uses the same Universal
Unique Identification (UUID) number that is defined in IEEE 1452.2. The
UUID will allow transducer manufacturers to identify their devices
without a regulatory committee.

The self-identification process can be divided into an identification
part and a configuration part. The configuration part will not be
addressed until the transducer-addressing scheme is developed.

The proposed protocol is based on a bit dominant approach. It assumes
that a zero is the dominant bit but could just as easily use one. This
proposal will not define the mechanism for transmitting or detecting the
dominant bit. That method must be defined as part of the physical layer.
It must include a method whereby multiple TBIMs can simultaneously
output the dominant bit without interference from other TBIMs. It also
assumes that the TBC can reliably detect when one or more TBIMs are
outputting a dominant bit. This method can be the dominant bit event
that lasts longer than the normal bit time. It is acceptable if a
dominant bit event is described as a tone of a given frequency for a
given time. Both the dominant bit event and the detection scheme used by
the TBC will not be specified at this time.

Discussion:

Proposed solution:

This protocol creates two commands for the identification part. A *START
ID* command is used to initialize the identification process. A
*TRANSMIT NEXT BIT* command will sequentially transmit a UUID from the
TBIMs to the TBC.

The *START ID* command causes the TBIM to prepare for a identification
cycle. If the TBIM has one or more transducer assigned with a transducer
address, it will ignore both the *START ID* command and subsequent
*TRANSMIT NEXT BIT* commands. The TBIM can delay the identification
process by outputting a dominant bit event on the bus. The TBC must wait
for the dominant bit event to be cleared before proceeding with the
identification cycle. The maximum amount of time that a TBC must wait
before checking to see if a TBIM is delaying and the maximum amount of
time that a TBIM can delay must be specified. These times are not
currently defined and depend on the definition of a dominant bit event.
An abort mechanism must also be defined.

Upon receiving the *TRANSMIT NEXT BIT* command, all TBIMs will transmit
their UUIDs (one bit per command). If the current bit is a one (not
dominant), the TBIM will not transmit anything. If it is a zero, the
TBIM will transmit a detectable event. After the TBC has detected
whether one or more TBIMS have transmitted a dominant bit, it will send
a command to transmit the next bit. This command will have an argument
which will tell the TBIMs whether the TBC detected a zero or a one on
the bus. If the detected state matches the one that the TBIM
transmitted, then it will place the next bit on the bus. If not, then it
no longer participates in the current identification cycle until it
receives a start id message. The TBIM will ignore the argument for the
first *TRANSMIT NEXT BIT* command in the cycle. The TBC continues this
process until a valid UUID has been received. Then it will assign the
transducer addresses for that TBIM. Once a TBIM has been set up, it will
no longer participate in the self-identification process. The TBC will
continue to identify all TBIMs on the bus until it gets no response. It
is desirable to require a TBIM without a UUID to respond as if its UUID
was zero. This is useful in distinguishing between a TBIM without a UUID
from the case where there are no more unidentified TBIMs on the bus.

Draft changes:

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

Add the following section to the DATA TYPES section of the draft

Universal Unique Identification

> Symbol: UUID
>
> Size: 10 bytes
>
> The UUID is an identification field associated with the TBIM whose
> value is unique in the universe. There shall be no requirement that
> the interpretation of the UUID reflect the actual place or time of
> manufacture of the TBIM. The use of time and location in the algorithm
> shall be used only to ensure uniqueness. Thus a manufacturer shall be
> allowed to use the fields defined by the algorithm as desired provided
> that when interpreted as defined in Table 1, there shall be no other
> possible manufacturer which could claim use of the same UUID.
>
> The UUID field shall be 10 bytes long and consists of four sub-fields
> (from most to least significant order: location, manufacturer's, year,
> and time) defined as follows:
>
> Table 1. Universal unique identification data type structure

+-------+-----------------------------------------------------+--------+
| Field | Description                                         | \#     |
| \#    |                                                     | bits   |
+-------+-----------------------------------------------------+--------+
| 1     | Location field: The value of this field shall be    | 42     |
|       | chosen by the TBIM manufacturer to identify a       |        |
|       | particular location on the earth, the 'location,'   |        |
|       | over which the manufacturer has physical control.   |        |
|       | This value may represent the actual location of     |        |
|       | TBIM manufacture. A manufacturer may use different  |        |
|       | values of this field in his operation as long as    |        |
|       | all values meet the requirements of this subclause. |        |
|       |                                                     |        |
|       | -   The representation of the location field shall  |        |
|       |     be 42 bits.                                     |        |
|       |                                                     |        |
|       | -   The msb shall indicate North (asserted) or      |        |
|       |     South (not asserted) latitude.                  |        |
|       |                                                     |        |
|       | -   The next 20 most significant bits of this field |        |
|       |     represent the magnitude of the 'location'       |        |
|       |     latitude as an integer number of arc seconds.   |        |
|       |                                                     |        |
|       | -   The next most significant bit shall indicate    |        |
|       |     East (asserted) or West (not asserted)          |        |
|       |     longitude.                                      |        |
|       |                                                     |        |
|       | -   The remaining 20 bits shall represent the       |        |
|       |     magnitude of the 'location' longitude as an     |        |
|       |     integer number of arc seconds                   |        |
|       |                                                     |        |
|       | Latitude magnitude values greater than 90 degrees   |        |
|       | are reserved. Longitude magnitude values of greater |        |
|       | than 180 degrees are reserved.                      |        |
|       |                                                     |        |
|       | (Informative note: One arc second at the equator is |        |
|       | about 30 meters. Thus the range represented by each |        |
|       | 20-bit field is 0 to 1 048 575 arc seconds or 0 to  |        |
|       | 291 degrees which is sufficient to represent        |        |
|       | latitude and longitude on the earth's surface)      |        |
+-------+-----------------------------------------------------+--------+
| 2     | Manufacturer's field: The value of this field may   | 4      |
|       | be chosen by the TBIM manufacturer for any purpose  |        |
|       | provided there are no interferences in the use of   |        |
|       | the location field. A location field interference   |        |
|       | shall mean that there is more than one manufacturer |        |
|       | which could claim physical control over the         |        |
|       | location defined by the location field. If such     |        |
|       | interferences exist all interfering manufacturers   |        |
|       | shall negotiate the use of the manufacturer's field |        |
|       | values to resolve any interferences, that is the    |        |
|       | combination of the location field and the           |        |
|       | manufacturer's fields shall unambiguously define a  |        |
|       | specific TBIM manufacturer This negotiation shall   |        |
|       | be reopened every time there is a change in the     |        |
|       | interference.                                       |        |
+-------+-----------------------------------------------------+--------+
| 3     | Year field: The value of this field shall be the    | 12     |
|       | value of the current year.                          |        |
|       |                                                     |        |
|       | The representation of the year field shall be a     |        |
|       | 12-bit integer value. The range of this field shall |        |
|       | be the years 0 to 4095 AD. The beginning of the     |        |
|       | year shall be deemed to start on January 1,         |        |
|       | 00:00:00, UTC.                                      |        |
+-------+-----------------------------------------------------+--------+
| 4     | Time field: This value shall be chosen by the TBIM  | 22     |
|       | manufacturer such that in combination with the      |        |
|       | location, manufacturer's and year fields the        |        |
|       | resulting UUID is unique for all TBIMs made under   |        |
|       | the manufacturer's control. The choice of values    |        |
|       | for the time field shall be further restricted such |        |
|       | that the values when interpreted as the time since  |        |
|       | the beginning of the year do not represent times    |        |
|       | prior to the manufacturer obtaining physical        |        |
|       | control over the 'location' nor values in the       |        |
|       | future in which the manufacturer cannot guarantee   |        |
|       | physical control over the 'location.'               |        |
|       |                                                     |        |
|       | The representation of the time field shall be a     |        |
|       | 22-bit integer. The range shall be 0 to 4 194 303.  |        |
|       | When it is necessary to interpret this field as     |        |
|       | time since the beginning of the year the            |        |
|       | representation shall be an integer number of ten    |        |
|       | second intervals. In this case, time values greater |        |
|       | than one year are reserved. (Informative note:      |        |
|       | There are approximately 31 536 000 seconds per      |        |
|       | year.) The beginning of the year shall be deemed to |        |
|       | start on January 1, 00:00:00, UTC.                  |        |
+-------+-----------------------------------------------------+--------+

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

Add the following section to the CONTROL CODES section of the draft

### TBIM Identification Commands and Protocol

The purpose of this protocol is to provide a method for allowing a bus
controller to identify and configure all TBIMs that are currently
connected to the belt. It is important to note that a TBIM must be
configured (have at least one logical transducer identifier assignment)
before it can be used for data/information transfer. This method does
not allow any other activities to take place on the command channel
while the identification process is in progress.

NOTE:\
This method does not require any previous knowledge of the configuration
of the bus, but it can take advantage of previous knowledge in order to
speed up the time required for configuration. It is envisioned that the
bus controller will store configuration information on all devices that
are connected to the bus. Whenever the bus controller is reset, it will
use this information and part of this protocol to configure the bus then
it will poll and configure any remaining TBIMs.

This protocol uses two commands for polling and two commands for
configuration. For polling, the *START ID* command is used to begin the
process and the *TRANSMIT NEXT BIT* will sequentially transmit a UUID
from the TBIMs to the bus controller. For configuration the WRITE
Transducer identifier UUID is used to assign Transducer identifiers to
physical transducers on a TBIM and the Verify UUID command is used to
determine whether a TBIM is still connected and if so, then how many
physical transducers are on that TBIM.

This protocol assumes that a zero is the dominant bit. It also assumes
that the bus controller can detect when one or more TBIMS are
transmitting the dominant bit. Upon command from the bus controller, all
TBIMs will transmit one bit of their UUIDs. If the current bit is a one
(not dominant), the TBIM will not transmit anything. If it is a zero,
the TBIM will transmit a detectable message. After the bus controller
has detected whether one or more TBIMS have transmitted a dominant bit,
it will send a command to transmit the next bit. This command will have
one argument which will tell the TBIMs whether the bus controller
detected a zero or a one on the bus for the previous bit. If the
detected state matches the one that the TBIM transmitted, then it will
place the next bit on the bus. If not, then it no longer participates in
the identification process until it receives a start id message. The bus
controller continues this process until a valid UUID has been received.
Then it will make up the transducer identifier assignments for that
TBIM. Once a TBIM has been set up, it will no longer participate in the
self-identification process. The bus controller will continue to
identify all TBIMs attached to the bus until it gets no response.

#### Start ID

This command contains no arguments. Upon receiving this command, a TBIM
with no transducer identifiers assigned will initialize its logic and
prepare to participate in the identification process. It will assume
that the last bit it transmitted was a one.

Table 2 Start ID Command

  ------- ----------- -----------------------------------------------------
  Field   Number of   Function
          bits        

  1       16          00

  2       8           17 - Operation Code
  ------- ----------- -----------------------------------------------------

#### Transmit Next Bit

This command has one argument. This argument will be either a zero or a
one and corresponds to the state of the last transmitted bit as detected
by the TBC. Upon receiving this command, a TBIM with no transducer
identifiers assigned will compare the state of this argument to that of
its last transmitted bit. If they do not match, the TBIM will cease to
participate in this process until another start ID command is received.
If they match, the TBIM will transmit the next bit of its UUID for eight
bit times if that bit is a zero. If the next bit is a one, then the TBIM
will not transmit. If for any reason, the TBIM receives this command
after transmitting all eighty bits of its UUID, it will cease to
participate in this process until another start ID command is received.

Table 3 Transmit Next Bit

  ------- ----------- -----------------------------------------------------
  Field   Number of   Function
          bits        

  1       16          00

  2       8           145 - Operation Code

  3       8           The least significant bit of this byte will contain a
                      zero if the last bit received was a zero. Otherwise,
                      it will contain a one.
  ------- ----------- -----------------------------------------------------

####