NOVI22/1993
`
`nnsmflx
`
`Version History
`Version:A
`
`Document Title: HAFiT®- SMART Communications
`Protocol, Physical And Data Link Specification
`
`Document Revision: 4.-
`
`HAFlT® Communication Foundation Document
`
`Number: HCF_SPEC-42
`42Ihistory
`
`Maintenance Con-[fa]
`
`DiSfl'ibUfiOl'l COIWIOI
`
`Location of Original Master:
`Company: Roserriount Inc.
`Address: 12001 Technology Drive, Eden Prairie, MN,
`55344. USA
`
`Location of Copy Master:
`Company: HART Communication Foundation
`Address: 9390 Research Blvd., Suite l-100, Austin.
`TX, 73759. USA
`
`Author: Gregory Opheim
`
`Distribution Contact: Ron Heison
`
`Location of Electronic Archive:
`
`Location of Control Inionnation:
`
`Computer: cs_ss
`Archive copy path: IuIdocIhctIspecI42Ia/hcispec.hdr.i
`Change History path and file name: Iuldoclhcllspecl
`
`Distribution History path and file name: Iutdoclhctl
`SD90/42/dislfib
`
`T‘-"Tj"'""—;"‘—:T'—_
`
`Approval Control
`Company name I Persons title (Executive)
`HART’ Communication Foundation! Director
`
`Persons Sigture
`’
`Jimcobb mic er
`
`Date Signed
`
`
`
`
`
`
`
`
`
`
`Date Signed
`Persons Signature
` ’Fj“=:F‘"—”"T""—
`lfzaflai Du I6. ‘ii
`Gr°9°~ Owe-m
`
`Company nameIPrsons Title (WG Chair)
`
`Petitioner Emerson's Exhibit 1009
`Page 1 of 28
`
`

`
`Petitioner Emerson's Exhibit 1009
`Page 2 of 28
`
`Petitioner Emerson's Exhibit 1009
`Page 2 of 28
`
`

`
`ROSEMOUNT INC.
`
`HARTTM Smart Communications Protocol
`
`PHYSICAL AND DATA LINK SPECIFICATION
`
`REVISION #4
`
`DATE OF RELEASE: 03/20/I988
`
`DATE OF PRINTING: 03/28/1988
`
`13870003} '
`Roscmount Document Number:-B-86099-7-7-—
`/
`
`if<'.vf5,‘gh A
`
`Petitioner Emerson's Exhibit 1009
`Page 3 of 28
`
`

`
`Petitioner Emerson's Exhibit 1009
`Page 4 of 28
`
`Petitioner Emerson's Exhibit 1009
`Page 4 of 28
`
`

`
`PHYSCIAL AND DATA LINK SPECIFICATION
`
`...........................................................1
`INTRODUCTION AND OVERVIEW....................
`DEVICE TYPES..........................................................................................................l
`RELATED DOCUMENTATION ...............................................................................l
`MESSAGE STRUCTURE......................................................................................................l
`PREAMBLE CHARACTERS.................................................................................. ...2
`MESSAGE DETECT PATTERN ..................................
`..........................................2
`MASTER-TO-SLAVE MESSAGES..........................................................................2
`SLAVE-TO-MASTER MESSAGES ..........................................................................3
`COMMANDS................................................................................................................4
`PHYSICAL LAYER ..........................................
`..................................................................A
`SIMULTANEOUS COMMUNICATIONS...............................................................5
`HARDWARE DESIGN ..........
`..................................................................................5
`PROTOCOL SPECIFICATION ............................................................................................6
`MODEL.........................................................................................................................6
`PRIMITIVE RECEIVE AND TRANSMIT MACHINES.......................................6
`SLAVE PROTOCOL MACHINE..............................................................................6
`MASTER PROTOCOL MACHINE...........................................................................7
`ARBITRATION AND TIMEOUT CONSTANTS................................................l0
`CHARACTER FORMATS................................................................... ..10
`TIMER MODEL .......................................................................................10
`SLAVE TIMEOUT..................................................................................1l
`MASTER TIMEOUTS............................................................................Il
`PERFORMANCE ........
`..................
`...........................................................l3
`ERROR DETECTION..............................................................................................13
`TRANSACTION TIME............................
`.............................................................l4
`RETRIES.....................................................................
`......................................... ...l5
`HARDWARE
`........................................16
`............................
`GENERAL.....................
`FIELD INSTRUMENT SPECIFICATIONS..........................................................I6
`MASTER SPECIFICATION....................................................................................l6
`SAMPLE CODE FOR MASTER ARBITRATION ......................................................... ..17
`RELEASE NOTES.........................................
`...................................................................2I
`
`4.5.1.
`4.5.2.
`4.5.3.
`4.5.4.
`
`Petitioner Emerson's Exhibit 1009
`Page 5 of 28
`
`

`
`Petitioner Emerson's Exhibit 1009
`Page 6 of 28
`
`Petitioner Emerson's Exhibit 1009
`Page 6 of 28
`
`

`
`ROSEMOUNT INC. HARTTM Smart Communications Protocol
`
`Page 1
`Physical and Data Link Specification Rev: 4 Release Date: 03/20/1988
`
`
`INTRODUCTION AND OVERVIEW
`
`The Rosemount Smart Communication Protocol provides a reliable. transaction-ori-
`ented service between master devices, such as a control system or a Rosemount Model
`268 Remote Transmitter Interface, and field devices, such as Rosemount Smart Field
`Instruments.
`It describes the rules used by Rosemount Smart Field Instrument prod-
`ucts--and products compatible with that family--to communicate digital information
`over a physical link (such as a 4-20 mA line).
`
`The protocol is designed to facilitate relatively low-bandwidth, moderate response time
`communications in industrial environments. Typical applications include remote proc-
`ess variable interrogation, parameter setting, and diagnostics. However, the protocol is
`adaptable to a broader range of needs. The following sections will define the require-
`ments built into the protocol, and show how they are related to various environmental
`and performance considerations.
`
`DEVICE TYPES
`
`The communications protocol recognizes three distinct device types. The most
`basic is the Field Instrument, a device that outputs a digital message (such as
`a measurement) in response to a command received from a master device. The
`field instrument always functions as a slave in a master-to-slave relationship
`with the master.
`
`The second device type recognized by the protocol is a primary master. A
`primary master is the main communicator with the field instruments and, as
`such, has arbitration priority in a dual master configuration. A control sys-
`tern would be an example of a primary master.
`
`The third device type is a secondary master. The secondary master would
`usually be an "occasional" user of the link. An example of a secondary mas-
`ter is the Rosemount Model 268.
`
`As far as the protocol is concerned, the only difference between primary and
`secondary masters is in the arbitration process. Refer to section 4.0 for a
`more comprehensive discussion of arbitration.
`
`RELATED DOCUMENTATION
`
`This protocol specification does not attempt to describe the individual proto-
`col commands used to exchange information between a master and a field
`instrument. For a detailed explanation of these commands, refer to the
`HARTTM Smart Communications Protocol Documentation package.
`
`MESSAGE STRUCTURE
`
`In order to pass information between two users, each must know the exact structure of
`both transmitted and received messages. For example, if the master sends a message to
`a field device, both users must know which byte is the “address" byte.
`
`The master-to-slave message format is slightly different from the slave-to-master
`format. Sections 2.3 and 2.4 give a detailed description of each format.
`
`Petitioner Emerson's Exhibit 1009
`Page 7 of 28
`
`

`
`2.l.
`
`PREAMBLE CHARACTERS
`
`Every message--whether from a master or from a field device--is preceded by
`a specified number of hexadecimal I-‘F characters called preambles. These
`“setup" characters, along with the appropriate STX or ACK ASCII delimiter
`character are used to form the message detect patterns described in section
`2.2. Additionally, the preambles perform the same function as a modem
`carrier signal in that they enable the receiver's signal-detect circuitry.
`
`As part of the response to the initial "who are you" query sent by the master,
`each field instrument will inform the master of the minimum number of
`preambles that it requires for satisfactory operation. The master will then
`send that number of preamble characters in all further transactions with that
`field instrument. Since the master can‘t know this number until the field
`instrument responds, the initial query should send 20 preamble characters.
`Alternatively, in order to increase average throughput, the most probable
`number of preambles (5) could be sent on the first try.
`If there is no re-
`sponse, the retry would default to 20 preambles.
`
`A minimum of five and a maximum of twenty preambles will be used for all
`field instrument -to-master messages.
`
`2.2. MESSAGE DETECT PATTERN
`
`Some energy~sensing carrier detect systems may falsely enable the receiver
`circuitry in the presence of sufficient noise on the link. For maximum relia-
`bility, the protocol uses a 3 byte pattern recognition method to indicate the
`start of a message.
`
`FF FF 02
`Host-transmitted message detect pattern:
`Field device-transmitted message detect pattern: FF FF 06
`
`In some applications there may be more than one field device connected to
`the link, each with a different address.
`It is possible that field device A's
`response to a host command may have an embedded data pattern of [FF FF
`02 (B’s address)] that would normally be interpreted by field device B as a
`message for him. To protect against this, the receiver circuitry in both the
`master and the field instruments must be programmed to detect both message
`detect patterns for proper operation. Once a message detect pattern has been
`sensed, any further message detect pattern recognition is masked until the end
`of the message.
`'
`
`2.3. MASTER-TO-SLAVE MESSAGES
`
`Figure 2-2 shows the format of a master-to-slave message. Reading from left
`to right, in the order in which the message is transmitted:
`
`The first field is the message detect pattern which was described in section
`2.2.
`
`The second field is the address field. The upper fggr bit; ingiggtg thg sggrcg
`fhtn
`n hlwrfr'inif
`inin TheModel
`268 uses a source code of 0000. All other master implementations should use
`
`Petitioner Emerson's Exhibit 1009
`Page 8 of 28
`
`Petitioner Emerson's Exhibit 1009
`Page 8 of 28
`
`

`
`ROSEMOUNT INC. HARTTM Smart Communications Protocol
`Page 3
`Physical and Data Link Specification Rev: 4 Release Date: 03/20/1988
`
`
`a value other than zero. The master must provide the destination code (lower
`four bits) of the address field.
`
`The third field is the command field. This byte tells the field instrument
`what it is supposed to do. The command field is normally one byte in length
`but may be extended by using a SFE value. Then, the next byte becomes part
`of the command field, also.
`
`The fourth field is the byte count field. It is one byte in length and specifies
`the message length by describing the number of bytes of information between
`this byte and the parity check byte that terminates the message.
`
`The fifth field is the data field. The actual number of data bytes depends on
`the command being used. The minimum data field length is 0 bytes. The
`maximum data field length is 25 bytes.
`
`The sixth field is a one-byte longitudinal parity check field. This value is
`determined by an exclusive-OR of the message bytes beginning with the STX
`character (02) and ending with either the last data byte or, if there is no data,
`the byte count byte. It is used along with vertical parity checks on individual
`bytes for error detection.
`
`SLAVE-T0-MASTER MESSAGES
`
`Figure 2-2 also shows the format of a Slave-to-Master message. These messages
`are similar to Master-to-Slave messages, but use a different message detect
`pattern. They also include a two-byte response code field. The message is
`structured as follows:
`
`The first field is the message detect pattern, as described in section 2.2.
`
`The second field, the address field, is echoed from the incoming Master-to-
`Slave message.
`
`The third field, the command field, is also echoed from the incoming Master-
`to-Slave message.
`
`The fourth field, the byte count, specifies the number of bytes following
`between it and the parity check byte at the end of the message. The minimum
`value of this field is 2, since all Slave-to-Master messages have a two-byte
`response code.
`
`The fifth field is a 2 byte response code and is unique to Slave-to-Master
`messages. If bit 7 of the first response code byte is cleared, the first byte
`describes how the field instrument dealt with the command that it just re-
`ceived, and the second byte describes the status of the field instrument. How-
`ever, if bit 7 is set, the first byte indicates that a communications error has
`occurred and now becomes a communications error summary.
`
`The sixth field is the data field. Again, this field is analogous to Master-to-
`
`Petitioner Emerson's Exhibit 1009
`Page 9 of 28
`
`

`
`calculated and checked similarly to the Master-to-Slave message parity check,
`except that the ACK character replaces the STX.
`
`Two Bytes if Extended
`
`~ M$ om
`
`MASTER — T0 — SLAVE MESSAGE FORMAT
`
`SLAVE — TO — MASTER MESSAGE FORMAT
`
`EM were
`
`Two Bytes if Extended
`
`2.5.
`
`COMMANDS
`
`Fig. 2-2. Message Formatting
`
`When a master requests a specific action or certain information from a field
`instrument, it does so by sending a specific command. The field instrument
`decodes the command and, after testing it for validity and applicability,
`performs the command, and responds to the master.
`
`The commands are broken down into three groups:
`Universal
`Common Practice
`
`Transmitter-Specific
`
`A complete description of the Rosemount Smart Protocol commands can be
`found in the HARTTM Smart Communications Protocol Documentation.
`
`3.
`
`PHYSICAL LAYER
`
`Physical Layer The Smart Field Instrument Communications Protocol is intended to be
`supported by a specific hardware implementation. The method chosen is called fre-
`quency-shift keying (FSK). With this method a logic “l" (mark) condition is repre-
`sented by a certain frequency, and a logic “0" (space) condition by a different fre-
`quency. A popular telephony standard, Bell 202, was chosen for the Rosemount Smart
`communication implementation. This choice satisfies three important criteria:
`
`I. The standard is well-supported. Several manufacturers make Bell 202
`modem chips, thereby facilitating the interface of third-party masters to
`Rosemount field instruments.
`
`_ 2. The standard is reliable. Bit error rates are sufficient to provide reliable
`communications over 5000 ft of twisted-pair wiring.
`
`Petitioner Emerson's Exhibit 1009
`Page 10 of 28
`
`Petitioner Emerson's Exhibit 1009
`Page 10 of 28
`
`

`
`ROSEMOUNT INC. HARTTM Smart Communications Protocol
`Page 5
`Physical and Data Link Specification Rev: 4 Release Date: 03/20/1988
`
`
`3. The standard can easily coexist with the 4 to 20 mA dc analog signal. The
`chosen method of communications does not affect control loop operation.
`
`SIMULTANEOUS COMMUNICATIONS
`
`A fundamental concept of the Rosemount communications technique is that
`communications between a master and a field instrument should not affect dc
`loop operation. Since the FSK signal is a zero-average energy contributor to
`the loop, the analog filtering - typically i-2 poles with a corner frequency of
`less than l0Hz - present at the input to the control system will “strip" the ac
`modulation from the signal, leaving the loop dc signal unaffected. This
`allows for maintaining normal analog loop control while communicating with
`the field instrument.
`
`HARDWARE DESIGN
`
`The protocol has been designed to be supported by the FSK hardware imple-
`mentation. A typical design would use a microprocessor, a Universal Asyn-
`chronous Receiver/Transmitter (UARTJ, Bell 202 modern, crystal. and du-
`plexer circuitry. The function of the duplexer is to interface the transmit
`and receive modem channels to the communications loop. Figure 3-1 shows a
`block diagram of the design. Refer to the section 6 for a more detailed list of
`hardware specifications.
`
`Micro—
`
`processor
`
`Loop Connection T
`
`V"
`
`DUPLEXER
`
`CIRCUITRY
`
`Fig. 3-]. Typical Hardware Block Diagram (2-Wire System)
`
`Petitioner Emerson's Exhibit 1009
`Page 11 of 28
`
`

`
`4-1.
`
`MODEL
`
`The following notation is used in the state transition diagrams of this section:
`-
`Each protocol entity is defined by a state-transition diagram.
`-
`Labeled circles represent states that protocol entities can be in.
`-
`Transitions are directed arcs. They show which state a protocol leaves
`and which state it transitions to. A transition is labeled with the con-
`dition that caused it and the corresponding output {this may be null).
`A transition label is written as the pair “<transition_cause> f<output>".
`Actions to be executed as a consequence of taking a transition are
`bracketed by “{actions]".
`Heavily outlined states are terminal states for the machine, i.e. at the
`end of processing of transitions the machine must end in a terminal
`state. Conditions and actions are expressed in the programming lan-
`guage “C".
`
`-
`
`-
`
`4.2.
`
`PRIMITIVE RECEIVE AND TRANSMIT MACHINES
`
`To simplify the state transition diagrams, the operation of the underlying
`physical hardware interfaces and i/o driver software is not detailed here.
`Their operation is abstracted in the state diagrams by the “xmt_msg” and
`“rcv_msg" and “enable.indicate" actions respectively. Typically these actions
`would be implemented as interrupt driven ifo drivers. The function per-
`formed by the"xmt_msg" action is to handle the handshaking and physical
`transmission of a data message. The function performed by the
`“enable.indicate” action is to handle detection of a transmission on the line
`(by a combination of carrier and message detect). The function of the
`“rcv__msg" action is to buffer an incoming message and to process it for valid
`address and parity information.
`
`4.3.
`
`SLAVE PROTOCOL MACHINE
`
`The slave protocol has been deliberately engineered to be as simple as pos-
`sibie, consistent with the need for providing reliable communication. Opera-
`tion is “speak only when spoken to". Figure 4-1 describes the operation of
`the slave. An incoming message triggers the protocol state machine which
`begins operation by looking for a correctly framed message. (preambles, STX
`as first byte, ctc.). Incorrectly framed messages are ignored. Next the address
`field is checked against the slave address. If there is no match, the message is
`ignored, otherwise a validity check is made. If any of the parity check tests
`fail. or if the message buffer overflows, then a negative acknowledgment,
`NAK, (Bit 7 of the status field =l) is returned since the message was other-
`wise correct (framed correctly).
`
`if the message has been received without errors, the protocol passes the
`information in the message back to the user through a “transmit.indicate".
`When the user executes a "transmit.response”, an acknowledgment message is
`formulated and returned. If the response timer “TTO" expires or the slave is
`busy, a negative acknowledgment (indicated in the status fields) is returned
`and any subsequent “transmit.response" ignored. The machine is restarted
`with the next incoming message. The “TTO” time-out is the maximum amount
`of time it could possibly take a slave to respond to an incoming message. All
`other time-outs within a given system are based on the value of this time-out. I
`It is identical for all slaves.
`
`Petitioner Emerson's Exhibit 1009
`Page 12 of 28
`
`Petitioner Emerson's Exhibit 1009
`Page 12 of 28
`
`

`
`ROSEMOUNT INC. HARTTM Smart Communications Protocol
`Physical and Data Link Specification Rev: 4 Release Date: 03/20/1988
`
`Page 7
`
`Address_mctch / —
`
`Addres.s_motch / -
`
`Purity or Buffer / NAK
`
`Transmitresponse / ACK
`[Clear TTO!
`
`TTO Timeout / NAK
`
`Buffer Mk Parity / Transmitjndicate
`[Set RTD}
`
`SLAVE FINITE STATE MACHINE
`
`MASTER PROTOCOL MACHINE
`
`Figure 4-1
`
`Both the masters in the HART protocol definition run the identical state
`transition machine. The arbitration of access to the communication link is
`controlled by time-outs that represent the lengths of time that devices (masters
`and slaves) executing the communication protocol use to decide on what they
`do next based on whether or not they hear transmissions on the communica-
`tion link. Time-outs are measured as the interval between transitions of the
`protocol state machine. Differentiation between the two masters is on the
`basis of the value of a single time-out assigned to two of the transitions
`within the protocol. This results in equal prioritizing of the two masters that
`access the link except when there has been a failure of arbitration (due to
`concurrent attempts to access the link). The master state machine has two
`functions to fulfill. The first is a complementary functionality to that imple-
`mented in the slave. i.e.. that needed to carry out communications reliably.
`The second component of functionality is required to handle arbitration of
`access to the slave between two masters. This partitioning of functionality is
`
`Petitioner Emerson's Exhibit 1009
`Page 13 of 28
`
`

`
`“RT2", and the link quiet/ slave time-out “RTl".
`
`The smaller arbitration constant is “RT2”. It is a constant for both masters.
`It is set to a sufficiently large value to allow the other master on the commu-
`nication link adequate time to initiate transmission (if it desires to do so)
`after the master which is executing the “RT2" time-out has just completed a
`transaction. The link grant time “RT2“ delays a subsequent transmission long
`enough for the master to detect a carrier / start of message due to the other
`masters communication. If no transmission from the other master is heard
`
`during this interval, the granting master is free to initiate another transmis-
`sion if it wants to.
`
`The link quiet time / slave time-out defined by timer “R.Tl" is the larger
`interval. This time period must be long enough to ensure that any response
`from a slave would be received at a master and hence must be greater than
`“TTO" by at least the turnoff and turn-on delays associated with carrier and
`message detection in the serial interface of the masters. When used for link
`quiet time detection, “RTI” ensures that no ongoing transaction will be
`interrupted by a master which is seeking access to the communication link.
`It is the maximum interval of time that an unsynchronized master, which is
`trying to access the link, waits after seeing the end of any ongoing trans-
`missions on the link. If no intervening transmissions occur, the link has come
`free and may be accessed. The arbitration and transmission process occurs as
`described in the next paragraph.
`
`When an initial transmission request occurs. the state machine cycles through
`the arbitration process. First of all, a check is made for ongoing transmissions
`on the link. The link is called “quiet” if no transmissions are seen for a
`period defined by the link quiet timer (RTI). The arbitration process is also
`considered complete if during this wait a response from a slave addressed to
`the other master is received. In either case, the master device is now in syn-
`chronization, and can immediately transmit its message. Message transmission
`must start quickly enough so that the other master, if any, does not think it
`can continue to use the link.
`
`Transmitting a message carries the state machine to the USE state. The retry
`count associated with the transmitted message establishes a re-try mechanism
`that allows the state-machine to recover from failures on the communication
`
`link. This is controlled by the "link quiet / slave time-out" interval associated
`with timer “RTl". This interval is the length of time for which a master will
`wait after sending a message to a slave before deciding that the transmitted
`message has been lost or that the slave has failed. Note that this is the iden-
`tical time period a master seeking to use the link needs to wait to ensure that
`no ongoing transmission is disrupted. Different values are used for "RTI" in
`the two masters to ensure that link synchronization can be recovered if mas-
`ters make “simultaneous" (within the resolution of the carrier detect / 1‘ram-
`ing mechanism) attempts to transmit. The master will leave the USE state for
`the ACCESS state updating the re-try count for this message if either “RTl"
`times out, or an illegally addressed or garbled message is received. If a correct
`response (ACK or Negative Acknowledgment) is received, the transmission
`request has been completed and the master will also transition to the ACCESS
`_state. In this case, the link grant timer ("RT2") is enabled.
`
`Petitioner Emerson's Exhibit 1009
`Page 14 of 28
`
`Petitioner Emerson's Exhibit 1009
`Page 14 of 28
`
`

`
`ROSEMOUNT INC. HARTTM Smart Comnttrrticattorts Protocol
`Page 9
`Physical and Data Link Specification Rev: 4 Release Date: 03/20/1988
`
`
`It moni-
`At this stage the master is in synchronization in the ACCESS state.
`tors the link waiting for "RT2“ to expire. This allows the other master, if
`any. on the link to transmit. it’ it needs to. Such a transmission by the other
`master must be initiated outside of the window defined by the carrier/mes-
`sage detect delays around "RT2". If “RT2" expires without the master detect-
`ing any transmissions, then it can re-transmit a current message if an incor-
`rect response (Negative Acknowledgment) was received and the re-try count
`has not been exceeded. It may alternatively transmit any new message associ-
`ated with a transmit request that it receives while in this state or exit if no
`such request is pending. Note that if the master exits, (i.e. stops monitoring the
`link), it is no longer synchronized and will have to go through the longer
`synchronization time-out "RTl" before transmitting than the shorter “RT2"
`time-out if it is synchronized.
`
`If. while waiting for “RT2" to expire, or in the USE state. the master detects
`a transmission on the link, then it must presume that the other master is
`undertaking a transmission. In this case it must now wait for as long as “RTI"
`or until it sees a response addressed to the other master on the link as it did
`when first attempting to access the link.
`
`Tmsmtl-request / -
`[Count-OI
`lset ‘l'x_t'lng|
`
`ent:Ib|e.imIieute / ncv_usc
`
`Tronsmitraquest / -
`[Set rm; Count-0|
`[Set T:t_l|ogi
`
`ACCESS
`
`RCV_HS-G -- “CK
`ISOI RT2: Clear t'l'l’1|
`[Clear Tz_l|agI
`
`-
`
`{urn 11meoui)|l (ma Tirneout)“
`RCVJ-ISG--(0ACK|| onus]
`kit (Count<Lirnit.)&& Tl._llug /' XHTJISG
`[Clear rm. KY2: Set rtT1|
`
`RT1 fimeout / -
`|Count++|
`
`acv_ust; :- (ACKHNAK) / —
`[Set Rn, caunt++|
`
`RT1 =- UNK QUIET TIMER/TRANSMIT TIMER
`RT2 - UNK GRANT 11MER
`
`enablmindicdte / Rt:v_ust3
`
`ACK,NAK = transmitter response addressed to this fnaster
`OACK.ONN< - ACI<'s at MK‘: addressed to other master
`
`Petitioner Emerson's Exhibit 1009
`Page 15 of 28
`
`

`
`Discussion of timer values for the protocol requires some assumptions about
`the functional behavior of the underlying physical hardware and software.
`The following sections and timing diagram show how these lead to the speci-
`fied values for TTO, RT! and RT2.
`
`4.5.1.
`
`CHARACTER FORMATS
`
`Characters forming a message are assumed to be transmitted asynchronously
`with no intervening inter-character gaps in a message. A character is com-
`posed of eleven bits. These are, in order of transmission, a start bit, eight
`data bits, a parity bit, and a stop bit. At 1200 bits/s , transmitting a character
`takes 9.167 mscc This time period is referred to as a character time. All proto-
`col timing information is expressed in units of character times.
`
`4.5.2.
`
`TIMER MODEL
`
`Link arbitration is controlled by time-outs that represent lengths of time that
`devices executing the protocol use to decide what they do next based on
`whether or not they hear transmissions on the link.
`
`Time-outs are measured as the interval between transitions of the protocol
`state machine. Transitions are initiated when a transmission is completed or
`when a response is received (i.e. preambles and frame synchronization are
`detected). Note that in the case where there is a finite amount of time in-
`volved in deciding that a response is received (e.g.. where enable.indicate is
`mapped into a valid carrier detect together with a minimum number of valid
`preambles), it is possible for a timeout to occur during the “transition". In
`this and all other such cases, processing of the currentiy in progress transition
`is to be completed before any subsequent input to the state machine (such as
`the time-out just mentioned) may be recognized.
`
`Figure 4-3 shows the timer model assumed by the protocol arbitration process.
`This model assumes the existence of a hardware generated clock with a clock
`“ticl-t" period of T seconds. The model assumes that transitions that initiate a
`protocol time measurement such as "RTl” are unsynchronized with the timer
`ticks. This model yields a fundamental resolution uncertainty of-I/+0 ticks. It
`is required that values of time-out intervals be measured with an accuracy of
`-O/+1 character times, implying that the calculated number of ticks corre-
`sponding to a measurement interval be incremented by one before being used
`to generate a time-out. Use of a timer with a resolution better than one char-
`acter time is preferred.
`
`UNSYNCHRONIZED TIMER MODEL
`
`:5 Tin-ner ticks. elapsed tit-ner -= 21'
`(worst case)
`
`(best case)
`
`t
`
`....T
`
`i
`
`T
`
`t
`
`T
`
`T
`
`3 T1:-ner ticks. elapsed time — ST
`
`Figure 4-3.
`
`Petitioner Emerson's Exhibit 1009
`Page 16 of 28
`
`Petitioner Emerson's Exhibit 1009
`Page 16 of 28
`
`

`
`ROSEMOUNT INC. HARTTM Smart Communications Protocol
`P886 11
`Physical and Data Link Specification Rev: 4 Release Date: 03/20/1988
`
`
`4.5.3. SLAVE TIMEOUT
`
`The most fundamental protocol time-out is the slave time-out. This is the
`maximum amount of time that it could possibly take a slave to respond to an
`incoming message. All other time-outs are based on the value of this time-out.
`It critically controls performance of the system and should be made as small
`as possible . It is identical for all slaves.
`
`4.5.4.
`
`MASTER TIMEOUTS
`
`TTO = 28 character times (256.7 msec)
`
`Figure 4-4 is a timing diagram for calculation of the value of “RT2" used
`during the link arbitration process. The purpose of “RT2" is to allow the
`master devices to exchange control of the bus. It is presumed that both masters
`have been monitoring the bus. The origin of the timing diagram is at the
`instant in time when the last byte of the response from a slave is received by
`both of the masters. This origin is established “identically" by both masters
`by processing the slave response and counting off the number of bytes speci-
`fied by the length field in the slave message. The diagram assumes that this
`message was a response to a message from the master labelled “Master(0)".
`"RT2" must be chosen large enough to allow “Master(l)" to start transmitting
`a message, and for “Master(0)“ to reliably detect that "Master(l}'s" message
`transmission has indeed begun. A maximum response window of 20 msec
`after detecting the end of the slave response has been allotted for “Master(l)"
`to begin transmission. After a 12-25 msec delay for carrier detect circuitry to
`unclamp the receive data line, and a further l-2 character delay for deseriali-
`zation in the UART a valid preamble byte will become available at the proto-
`col interface in “Master(0)". A safety factor of one character time is added
`in the calculation of “RT2". Note that it is assumed that the timer slop is-0/
`+1 character time. The resulting value of “RT2" is:
`
`RT2 = 8 character times ( 75 msec)
`
`Note that i1' "Master (I)" can not begin transmission within the response window
`interval. it must defer transmission for a period of "2‘RT1" from the end of the
`Slave transmission in order not to interfere with “Master (0)'s" possible use of the
`bus. This gives a polling master device an opportunity to maintain synchronization
`on the bus. If no transmissions are seen on the bus after this interval. the bus is
`considered to be free for access by either master.
`
`at... Arbrt-g-nan cg» -the many-r"' p.-gggggn
`
`Slave 1'»:
`
`CO)
`
`Mast-rfi 1 ) ‘Pa
`
`Mcantorfid) CD
`
`Safoty Margin
`
`CO Turn on
`-.-.-...-.—..-—..--.--g--.-
`5)
`
`I'D-Q-1-lull:-atlau-I
`
`'|"lo-HQ! gig:
`-$—:—
`C5)
`C9)
`
`Pet