1、BRITISH STANDARDBS EN 62379-1:2007Common control interface for networked digital audio and video products Part 1: GeneralThe European Standard EN 62379-1:2007 has the status of a British StandardICS 33.160.01; 35.100.01g49g50g3g38g50g51g60g44g49g42g3g58g44g55g43g50g56g55g3g37g54g44g3g51g40g53g48g44g
2、54g54g44g50g49g3g40g59g38g40g51g55g3g36g54g3g51g40g53g48g44g55g55g40g39g3g37g60g3g38g50g51g60g53g44g42g43g55g3g47g36g58BS EN 62379-1:2007This British Standard was published under the authority of the Standards Policy and Strategy Committee on 31 December 2007 BSI 2007ISBN 978 0 580 57652 2National f
3、orewordThis British Standard is the UK implementation of EN 62379-1:2007. It is identical to IEC 62379-1:2007. The UK participation in its preparation was entrusted to Technical Committee EPL/100, Audio, video and multimedia systems and equipment.A list of organizations represented on this committee
4、 can be obtained on request to its secretary.This publication does not purport to include all the necessary provisions of a contract. Users are responsible for its correct application.Compliance with a British Standard cannot confer immunity from legal obligations.Amendments issued since publication
5、Amd. No. Date CommentsEUROPEAN STANDARD EN 62379-1 NORME EUROPENNE EUROPISCHE NORM November 2007 CENELEC European Committee for Electrotechnical Standardization Comit Europen de Normalisation Electrotechnique Europisches Komitee fr Elektrotechnische Normung Central Secretariat: rue de Stassart 35, B
6、 - 1050 Brussels 2007 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC members. Ref. No. EN 62379-1:2007 E ICS 33.160; 35.100 English version Common control interface for networked digital audio and video products - Part 1: General (IEC 62379-1:2007) I
7、nterface de commande commun destin aux produits audio et video numriques connects en rseau - Partie 1: Gnralits (CEI 62379-1:2007) Gemeinsame Steuerschnittstelle fr netzwerkbetriebene digitale Audio- und Videogerte - Teil 1: Allgemeines (IEC 62379-1:2007) This European Standard was approved by CENEL
8、EC on 2007-10-01. CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such national standard
9、s may be obtained on application to the Central Secretariat or to any CENELEC member. This European Standard exists in two official versions (English and German). A version in any other language made by translation under the responsibility of a CENELEC member into its own language and notified to th
10、e Central Secretariat has the same status as the official versions. CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Cyprus, the Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembo
11、urg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and the United Kingdom. Foreword The text of document 100/1248/FDIS, future edition 1 of IEC 62379-1, prepared by IEC TC 100, Audio, video and multimedia systems and equipment, was submitte
12、d to the IEC-CENELEC parallel vote and was approved by CENELEC as EN 62379-1 on 2007-10-01. The following dates were fixed: latest date by which the EN has to be implemented at national level by publication of an identical national standard or by endorsement (dop) 2008-07-01 latest date by which the
13、 national standards conflicting with the EN have to be withdrawn (dow) 2010-10-01 Annex ZA has been added by CENELEC. _ Endorsement notice The text of the International Standard IEC 62379-1:2007 was approved by CENELEC as a European Standard without any modification. _ EN 62379-1:2007 2 CONTENTS 0 I
14、ntroduction 5 0.1 Overview .5 0.2 Structure of the family of standards .5 0.3 Model of the equipment being controlled .6 0.3.1 Blocks .6 0.3.2 Control framework .7 0.3.3 How the framework helps when designing units 8 0.3.4 How the framework enables “plug and play“ .8 0.3.5 Defining a new type of blo
15、ck .8 0.4 Management information base (MIB) 9 0.4.1 Objects 9 0.4.2 Other uses of OIDs .9 0.4.3 Migration to XML 9 0.5 Status broadcasts .10 0.5.1 Introduction .10 0.5.2 Status page information sources10 0.5.3 Status page general format10 0.6 Calls10 0.7 Privilege levels11 0.8 Automation12 0.9 Uploa
16、ding software12 0.10 Encapsulation of messages.13 0.11 Further information13 1 Scope.14 2 Normative references .14 3 Terms and definitions .14 4 Unit management .17 4.1 Protocol.17 4.2 MIB definitions 18 4.2.1 General .18 4.2.2 Application-wide type definitions19 4.2.3 Conceptual row type definition
17、s .23 4.2.4 MIB objects for basic unit identity and status information.24 4.2.5 MIB objects for the block framework 27 4.2.6 MIB objects for real time clock information.29 4.2.7 MIB objects for reference clock information .30 4.2.8 MIB objects for software upload.31 4.2.9 MIB objects for scheduled o
18、perations 33 5 Procedures.35 5.1 Real-time clocks35 5.2 Procedures for uploading software 35 5.2.1 Areas.35 5.2.2 Contents36 5.2.3 Procedure for updating a software component .37 EN 62379-1:2007 3 5.2.4 File format for a software component.37 5.2.5 Format for product files .38 5.2.6 Software distrib
19、ution39 5.3 Scheduled operations39 5.3.1 Requesting a scheduled operation.39 5.3.2 Executing a scheduled operation .41 5.3.3 Delaying a scheduled operation.41 5.3.4 Aborting a scheduled operation .41 5.3.5 State of relative operations41 6 Status broadcasts.41 6.1 General .41 6.2 Page formats.43 6.2.
20、1 Basic unit identity page .43 6.2.2 Time-of-day page 43 6.2.3 Scheduled operations page .44 6.3 Page groups44 6.3.1 basicUnitStatus.44 6.3.2 timeOfDay.44 6.3.3 scheduledOps.44 Annex A (informative) Background information.46 Annex B (informative) Machine-readable MIB definitions49 Annex C (informati
21、ve) Machine-readable status page-group definitions .67 Bibliography68 Figure 1 A block.6 Figure 2 Ports 6 Figure 3 Example of a “unit“.7 Table 1 Managed objects conveying information about the unit24 Table 2 Managed objects for block and connector configuration.27 Table 3 Managed objects for real-ti
22、me clock information29 Table 4 Managed objects for reference clock information.30 Table 5 Managed objects for software upload 31 Table 6 Managed objects for scheduled operations33 EN 62379-1:2007 4 Annex ZA (normative) Normative references to international publications with their corresponding Europ
23、ean publications 69 0 Introduction 0.1 Overview This family of standards specifies a control framework for networked audiovisual equipment. It provides a means for management entities to control not only transmission across the network but also other functions within interface equipment. Although it
24、 was originally developed for audio over asynchronous transfer mode (ATM) in radio broadcasting, the control framework has been extended to encompass video and other time-critical media, as well as other networking technologies and other applications in both professional and consumer environments. T
25、he control framework provides a number of key features: it provides a consistent interface to the functionality in an audiovisual unit; it enables systems to be built that are truly “plug and play“, by providing the means for equipment to discover what units are connected to the network and what the
26、ir capabilities are; it links discrete areas or blocks of functionality together in a consistent and structured way; it allows us to define small focused building blocks from which more complex functionality can be built; it ensures new functionality can be developed and integrated consistently and
27、easily into the framework. The functionality provided by an audiovisual unit is represented using one or more “blocks“ (such as a cross-point switch or a gain control), structured and connected together using the control framework. As a further aid to the “plug-and-play“ functionality, a common form
28、at for audio and video being conveyed across the network is also specified, to avoid situations in which two pieces of equipment fail to communicate because there is no format which both support. Equipment may, of course, also support other formats appropriate to particular applications, and the sta
29、ndard mechanisms for initiating and terminating communication will work for those formats in the same way as for the standard formats. 0.2 Structure of the family of standards IEC 62379 is intended to include the following parts: Part 1: General Part 2: Audio Part 3: Video Part 4: Data Part 5: Trans
30、mission over networks Part 6: Packet transfer service Part 1 specifies aspects which are common to all equipment. Parts 2 to 4 specify control of internal functions specific to equipment carrying particular types of media; in the case of Part 4, this would be time-critical media other than audio and
31、 video, for instance, RS232 and RS422 data for applications such as machine control, or the state of EN 62379-1:2007 5 the “on air” light in a broadcast studio. Part 4 does not refer to packet data such as the control messages themselves. Part 5 specifies control of transmission of these media over
32、each individual network technology, with a separate subpart for each technology. It includes network specific management interfaces along with network specific control elements that integrate into the control framework. Part 6 specifies carriage of control and status messages and non-audiovisual dat
33、a over transports that do not support audio and video, such as RS232 serial links, with (as with Part 5) a separate subpart for each technology. 0.3 Model of the equipment being controlled 0.3.1 Blocks A piece of equipment (a “unit“) is regarded as being composed of functional elements or “blocks“ w
34、hich may be linked to each other through internal routing. Blocks may have inputs, outputs and internal functionality. In general, the output of one block connects to the input of the next block in the processing chain. Blocks can have some associated control parameters and/or status monitoring acce
35、ssible via the control framework management interface. Inputs OutputsIEC 1627/07Figure 1 A block A typical block would be a pre-amplifier, which has one input, one output, and a parameter which sets the gain. Another would be a mixer, with several inputs, one output, and parameters to select the con
36、tribution of each input to the mix; these parameters are effectively fader settings. A tone generator would have one output and no inputs, and parameters that set the level, frequency, etc. There is a special class of blocks called “ports“; ports provide an external connection to other equipment. An
37、 “input port“ is one where audio, video, or other data enters the unit and an “output port“ is one where it leaves the unit. Sometimes the port corresponds to a physical connection, for instance, an XLR socket for analogue audio; sometimes it is a virtual entity which can be one end of a connection
38、across a network, or one channel on an interface such as AES10 (MADI) which conveys multiple audio streams. Input port Outputport IEC 1628/07Figure 2 Ports An input port has no inputs (or rather, no internal inputs; it will have an external input, but that is not part of the model of the internal st
39、ructure of the unit) and a single output, which EN 62379-1:2007 6 supplies the incoming stream to the inputs of other blocks. In the case of a network port, parameters would specify the network address; a physical audio port might have parameters which show the sampling rate and bit depth. Similarly
40、, an output port has a single input and no (internal) outputs. Figure 3 shows an example of how the various blocks connect together within a unit. Note that each input is connected to exactly one output, but an output may be connected to several inputs, or to none. Input channel 1 MixerNetwork inter
41、face Input channel 2 Input channel 1 Audio output 1 Audio output 2 Pre-amp Audio input 1 IEC 1629/07 Figure 3 Example of a “unit“ There is a block which performs a mix between three inputs, two from the network and one from a physical audio port (or, looking at it another way, two from remote source
42、s and one from a local source). The local source is connected via a pre-amplifier. The resulting signal is output locally at output 2 and also transmitted on the network. There is another local output which carries a copy of one of the remote sources. The set of available blocks, the connectivity be
43、tween them, and the parameter settings for each may be fixed, or changeable by a management terminal, or read-only but changeable by external factors. Where blocks are implemented in software, a unit may provide the ability for a management terminal to create and delete them. Where blocks are implem
44、ented in physical hardware, the blocks themselves cannot be changed but it may still be possible for the management terminal to reprogramme the routing between them. 0.3.2 Control framework The control framework consists of two lists; a list of blocks (also called control elements), and a list of co
45、nnections between them. In both lists, an individual block is identified by a “block id“, which is a number that is different for each block in a unit. A blocks entry in the list of blocks shows what type of block it is, represented by a globally unique value as described in 0.3.5. Groups of blocks
46、that are connected together are called processing chains. A processing chain typically represents what a unit does as a whole, so, for instance, a unit that alters the gain of an input to produce an output would have one simple processing chain that consists of an input port connected to a gain bloc
47、k which is connected to an output port. EN 62379-1:2007 7 0.3.3 How the framework helps when designing units The standard anticipates that many control blocks will be designed and implemented over time to control the many different sorts of functionality audio and audiovisual units provide. Units ca
48、n be built from existing blocks or new ones created as required. It will often be possible to represent complex, product-specific control functionality using a number of linked instances of simpler, standard blocks that together provide the functionality required. 0.3.4 How the framework enables “pl
49、ug and play“ A management terminal simply needs to recognize those blocks that are relevant to the functions it controls. (The term “management terminal“ covers a wide variety of equipment, from a broadcast control system to the user interface of a device on a home network.) It can discover what units are present on the network and what functions each contains; it does not need to recognize the units themselves, only the blocks that describe the functionality in which it is interested. The discovery proc
