SMPTE RP 138-1996 Control Message Architecture for Digital Control Interface.pdf

《SMPTE RP 138-1996 Control Message Architecture for Digital Control Interface.pdf》由会员分享，可在线阅读，更多相关《SMPTE RP 138-1996 Control Message Architecture for Digital Control Interface.pdf（5页珍藏版）》请在麦多课文档分享上搜索。

1、STD-SMPTE RP 338-ENGL 377b 8357403 0002b7b b84 = SMPTE RECOMMENDED PRACTICE RP 138-1996 Revision of RP 138-1 992 Con trot Message Architecture for Digital Control Interface 1 General 1.1 Scope This practice defines the architecture of the control message language used within a general-purpose commun

2、ications channel of an interface system which transports data and control signals between equip- ment utilized in the production, post-production, and/or transmission of visual and aural information. It is intended that the language described in this practice be utilized when constructing messages u

3、sed as part of an overall system, allowing interconnection of programmable and nonprogrammable equipment as required to configure an operational system with a defined function, and to allow rapid reconfiguration of a system to provide more than one defined function utilizing a given group of equipme

4、nt. 1.1.1 Control message language is composed of vocabulary, syntax, and semantics expressed in terms of tokens, rules, and actions, respectively. 1.1.2 The primary intent of this practice is to define the architecture of the messages to be transmitted within the supervisory protocol of the communi

5、cations channel for the purpose of con- trolling equipment by external means. Syntax is the set of rules which shall be applied to the vocabulary (tokens) to construct control mes- sages. (The content of the vocabulary and its semantics, being specific to the type of generic equipment, is defined el

6、sewhere.) This prac- tice, or sections thereof, may be applied to the interconnection of elements within an item of equipment. Page 1 of 5 pages 1.2 Definitions For the purpose of this practice, the following defini- tions shall apply: virtual machine: A logical device consisting of a single device

7、or a combination of devices that responds in essence or effect as a generic type of equipment; e.g., VTR, video switcher, telecine, etc. virtual circuit: A transparent, logical communi- cations connection between virtual machines. The communications path, in reality, passes through other levels and

8、is propagated over a physical medium. 2 Message structure 2.1 Architecture The message architecture described in this practice is prepared broadly on the principals of communica- tions levels. This architecture follows a logical struc- ture and is defined in terms of a virtual machine. Messages are

9、of variable length according to function. Complex functions may be divided into basic func- tions, transmitted as a sequence of shorter messages for execution in the virtual machine. 2.2 Virtual machine All messages pertaining to generic types of equipment shall be defined in terms of the virtual ma

10、chine. Utili- zation of the virtual machine concept in defining mes- sages provides a message architecture that is independent of machine-specific characteristics. - Copyright Q 1996 by the SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 595 W. Hartcdale Ave., White Plains, NY 10607 Approved Dece

11、mber 1 O, 1996 (914) 761-1100 STD*SMPTE RP 338-ENGL RP 138-1 996 Lb m 8357403 0002677 530 m 3 Control message classification 3.1 Control messages Control messages are classified in accordance with figure 1. 3.1.1 Virtual machine messages are used to pass commands and responses between virtual machin

12、es. Virtual machine messages are those initiated by a controlling device with responses originating in the controlled device. Receipt of a virtual machine message shall result in a defined action and/or response by the virtual machine. Virtual machine messages may be subdivided into: 3.1.1.1 Common

13、messages whose coding is re- served to provide for functions of general appli- cation; e.g., procedures, reference time functions, and reset. 3.1.1.2 Type-specific messages are applicable to specific generic categories of equipment. 3.1.1.3 User-defined messages implement spe- cial functions which a

14、re not included in the type- specific message set. 3.1.2 System-service messages are messages other than virtual machine messages. 3.2 Virtual machine message subsets A separate and distinct subset of virtual machine messages shall be specified for each type of virtual machine (VTR, telecine, audio

15、tape recorder, graphics generator, etc.). Said subset, temed a dialect, shall comprise common messages, type-specific mes- sages, and, optionally, user-defined messages. 3.2.1 Common messages: Re s i de n t mach i ne messages which are in all virtual machine dia- lects but not necessarily operative

16、in all virtual machines, whose coding is reserved to provide for functions of general applications. 3.2.2 Type-specific messages: Virtual machine messages which are defined in virtual machine di al ect recommended p ractices. Figure 1 - Message Classification Page 2 of 5 pages STD-SMPTE RP LIA-ENGL

17、L77h 8357401 0002678 457 RP 138-1 996 3.2.3 User-defined messages: Virtual machine messages which are unique to the type (manu- facturer, model, version, SIN, etc.) of the spe- cific machine. Although the definition and/or documentation of user-defined messages is con- sidered outside the scope of t

18、his practice, the structure of such messages shall conform to the message architecture as defined herein. 4 Control message construction A parameter has the following syntax: PARAMETER = (NAME +) VALUE(S) The name may be implied with the use of specific keywords and, in such cases, is therefore not

19、re- quired. The length and format of the value (or values) are defined by the name (or implied name). No restric- tion is placed on the possible concatenation of pa- rameter values. 4.1 Syntax 4.2 Message formats System service and virtual machine messages are uniformly constructed with the followin

20、g syntax: MESSAGE = KEYWORD (+ARGUMENT) where the keyword characterizes the function to be performed and the argument contains the parame- ters, where necessary, to perform that function. All control messages are formed as groups of integral bytes. The first byte of each message shall be the keyword

21、. A keyword specification defines the format of its arguments; although no mathematical relation- ship is intended between the bit pattern of the keyword and the format. Messages are constructed in one of the following formats: Format 1 Message Format 2 Message where: or: where: or: where: . , , . .

22、 . The appropriate message format can be selected by means of the decision tree given in figure 2. Page 3 of 5 pages RP 138-1 996 STD*SMPTE RP 13B-ENGL 177b = 8357403 0002b77 373 *ECURlSWE IIECURSSWE Figure 2 - Decision tree 5 Message coding 5.2.1 Logical parameter values 5.1 Identical or similar fu

23、nctions on equipment of differing generic types should be effected by the same keyword bit pattern. Parameters representing any abstract function(s) that may be expressed by a Simple binary State of 1 (true) or O (false) such as tally on/off or yedno. 5.2 Parameter values Messages may contain parame

24、ters as an essential part. All parameters are classified as follows: The minimum code length for a single logical parame- ter is one byte. Individual logical parameters can be assembled, where applicable, into PUPS to form bit-specific bytes for transmission purposes. Page 4 of 5 pages STD-SMPTE RP

25、136-ENGL 1b m 5.2.2 Numerical parameter values Parameters representing a numerical value and con- sisting of the following: Unsigned number parameters: Parameters representing any numerical value without polarity. Signed number parameters: Parameters representing any numerical value with polarity. 5

26、.2.3 Time-code parameter values Time is indicated as a four-byte quantity. Parameters representing hours, minutes, seconds,and frames are expressed in BCD in that order. (in BCD,the least significant bit is transmitted first.) The hex “40-bit of the frames byte will be set to one (1) in drop-frame c

27、ompensated mode. In nondrop frame uncompen- sated mode and ali other time code standards, this bit 6357401 0002bBO 005 m R P 138-1 996 will be zero (O). In all standards, the hex”80”-bit of the seconds byte will be set to zero (O) to indicate mono- chrome field 1 or color fields 1, 3, 5, or 7. This

28、bit set to one (1) will indicate monochrome field 2 or color fields 2, 4, 6, or 8. Unused bits are reserved and are set to zero (O) until defined (see figure 3). 5.2.4 High-resolution time code parameter values High-resolution time is indicated as a six-byte quan- tity. The first four bytes are exac

29、tly the same as time parameter values. The two remaining bytes express fractions of frames as a 16-bit binary unsigned num- ber (see figure 3). 5.2.5 Literal parameters are parameters based, in general, on ASCII characters. 5.2.6 Raw data parameters are parameters based on a free-form data stream. Raw data parameters must provide for byte transparency to the lower layers. The first byte of a raw data parameter shall be a byte count. FIELDMARK DROP FRAME (COMPENSTED MODE Figure 3 - High-resolution time parameter format Page 5 of 5 pages