Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Көңіл көтеру технологиясы жабдықтарын басқаруға арналған желілік протоколдар
Network protocols for control of entertainment technology equipment
Басқару желілері архитектурасы (ACN) – көңіл көтеру технологиясы жабдықтарын басқаруға арналған желілік протоколдар жиынтығы, әсіресе тікелей эфирде немесе кең ауқымды орналымдарда қолданылады. Мысалы, жарықтандыру, дыбыс немесе арнайы эффектілер жабдықтары. ACN – Ойын-сауық қызметтері және технологиялар қауымдастығы (Entertainment Services and Technology Association) тарапынан қолдау көрсетіледі және оның алғашқы ресми нұсқасы ANSI стандарты E1.17 2006 «Көңіл көтеру технологиясы. Басқару желілері архитектурасы» болды. Стандарт кейіннен қайта қаралып, ANSI E1.17 2010 ретінде жарияланды. ACN бастапқыда UDP/IP протоколының үстіне орналастырылғандықтан, стандартты және төмен бағалы Ethernet және 802.11 (Wi-Fi) желілерін қоса алғанда, көптеген IP-транспорттарымен үйлесімді жұмыс істейді.
Architecture for Control Networks (ACN) is a suite of network protocols for control of entertainment technology equipment, particularly as used in live performance or large scale installations. For example, lighting, audio or special effects equipment. ACN is maintained by Entertainment Services and Technology Association and its first official release was ANSI Standard E1.17 2006 Entertainment Technology Architecture for Control Networks. The standard was subsequently revised and released as ANSI E1.17 2010. ACN was initially designed to be layered on top of UDP/IP and therefore will run over most IP transports including standard, inexpensive Ethernet and 802.11 (Wi Fi) networks.
Протоколдық архитектура
ACN ортақ протоколдық архитектураны, екі негізгі желілік протоколды (SDT, DMP), құрылғы сипаттау тілін (DDL) және E1.17 өзара іс-қимыл үшін профильдерді (EPI немесе өзара іс-қимыл профильдері деп аталады) анықтайды. Бұл профильдер ACN архитектурасының элементтерін нақты жағдайда өзара іс-қимыл қабілеттілігін қамтамасыз ету үшін қалай қолдану керектігін көрсетеді. Мысалы, белгілі бір желілік ортада қолданылатын уақыт параметрлері үшін нақты мәндерді немесе диапазонды беру арқылы. ACN-нің кіші протоколдарға, өзара іс-қимыл профильдеріне және басқа да шағын бөліктерге бөлінуі оны оқу мен түсінуді қиындатады деген сын айтылғанмен, бұл архитектураны жоғары модульді және анық қабатталған етеді. Осының арқасында көптеген бөліктерді басқа жағдайларда пайдалануға, немесе басқа бөліктерге өзгеріс енгізбей ауыстыруға немесе жаңартуға болады. Мысалы, DMP бастапқы стандартта көрсетілгендей, SDT-мен қатар TCP арқылы да жұмыс істеді, DDL DMX512 (ANSI E1.31/Streaming ACN) арқылы қол жеткізілетін құрылғыларды сипаттау үшін аз өзгерістермен бейімделді, ал бірнеше өзара іс-қимыл профильдері стандарттың басқа бөліктерін бұзбай үлкен өзгерістерге ұшырады немесе ауыстырылды.
ACN defines a common protocol architecture, two major network protocols (SDT, DMP), a device description language (DDL) and a number of ‘E1.17 Profiles for Interoperability’ (known as EPIs or interoperability profiles) which define how elements of the ACN architecture must be used in a particular context to achieve interoperability. For example, by providing specific values or ranges for timing parameters to be used in a particular network environment. The breakdown of ACN into sub protocols, interoperability profiles and other small pieces has been criticized as making ACN hard to read and understand but it makes the architecture highly modular and cleanly layered and this has allowed many of the pieces to be operated in other contexts or replaced or revised without changing the other pieces. For example, DMP has been operated over TCP as well as over SDT as defined in the initial standard, DDL has been adapted with little change to describe devices accessed by DMX512 (ANSI E1.31/Streaming ACN), and several interoperability profiles have seen major revision or replacement without disturbing the other parts of the standard.
Ортақ сәулет
Жалпы архитектура спецификациясы негізгі протоколдарда қолданылатын, TLV кодтауына ұқсас ұяластырылған протоколдық дерек бірліктерінің (PDU) форматын анықтайды. Одан әрі, жоғары деңгейдегі протоколдарды төменгі деңгейдегі тасымалдауға біріктіру үшін минималды Root Layer протоколының қалай қолданылатыны көрсетіледі және UDP/IP желісінде қолдану үшін PDU форматын пайдалана отырып, осы Root Layer протоколы анықталады.
The common architecture specification defines a format of nested protocol data units (PDUs), rather similar to TLV encoding, which are used in the main protocols. It then defines how a minimal Root Layer Protocol is used to splice the higher level protocols into a lower level transport and defines such a Root Layer Protocol using the PDU format for use on UDP/IP.
Сессия деректерін тасымалдау
Сессиялық деректер тасымалы (SDT) – UDP/IP арқылы жұмыс істейтін, сенімді көп тарату протоколы. Ол желідегі құрылғыларды сессияларға біріктіруге және оларға жеке немесе топтап хабарлар жіберуге мүмкіндік береді. Хабарлардың жеткізілуі реттілікпен жүзеге асырылады, ал хабарлардың сенімділігі немесе сенімсіздігі әрбір хабар бойынша таңдап қойылды (кейбір деректер үшін сенімділік өте маңызды болса, ал басқалары үшін сенімділік механизмінің уақыт және ресурстар шығындарын болдырмау пайдалы). Сенімділік механизмі қосылыстың үзілуін анықтауға мүмкіндік беретін онлайн күйді де қамтамасыз етеді. SDT кешігу, сенімділік деңгейі және ресурстық талаптар арасындағы қатынастың жоғары дәлдігімен реттеуге мүмкіндік береді, ал көптеген бір мезгілдегі сессияларды қолдау мүмкіндігі, байланысты функциялары немесе ұқсас байланыс талаптары бар құрылғыларды топтастыру және басқару үшін қуатты құрал екенін көрсетеді.
Session Data Transport (SDT) is a reliable multicast transport protocol which operates over UDP/IP which can be used to group peers within a network into sessions and deliver messages to them individually or as a group. Message delivery is ordered and messages may be selectively sent reliably or unreliably on a message by message basis (reliability is very important for some data while avoiding the time and resource overhead of the reliability mechanism is beneficial for others). The reliability mechanism also provides online status so a component will detect when a connection is broken. SDT provides a high degree of fine tuning over the trade off between latency, reliability levels and resource requirements and availability of large numbers of concurrent sessions means they are a powerful tool for grouping and managing components whose functions are related or whose communication requirements are similar.
Құрылғыны басқару протоколы
Құрылғыны басқару протоколы (DMP) кез келген құрылғыны оның ағымдағы немесе қажетті күйін көрсететін, адрестелетін қасиеттер жиынтығы ретінде ұсынады. Бақылаушының бақылауы немесе басқаруы осы қасиеттердің мәндерін орнату немесе тексеру арқылы жүзеге асырылады. Сауалнаманың тиімсіздігін болдырмау үшін, жай ғана қасиеттердің мәнін оқудан (Get Property хабарын пайдалану) басқа, DMP жазылу механизмін ұсынады. Осы механизм арқылы құрылғы, қасиеттің мәні өзгерген кезде барлық жазылған бақылаушыларға асинхронды түрде оқиға хабарламаларын жібереді. DMP өзінің қосылымдары сенімділікті қамтамасыз ете алады деп күтеді, сондықтан шоу кезінде операциялық өткізу қабілетінің үлкен бөлігін құрайтын Set Property және Event хабарламаларына DMP деңгейінде нақты растау қажет болмайды. E1.17 стандартында және көптеген жүйелерде SDT осы сенімділікті қамтамасыз етеді, бірақ DMP сенімді қосылыстарды қамтамасыз ету үшін TCP арқылы да жұмыс істей алады. DMP құрылғысындағы әрбір қасиеттің биттік мөлшері, бейнелеу форматы, оқу/жазуға қолжетімділігі және функциясы протоколмен анықталмайды, ол тек қасиеттің мәнін оқу және/немесе жазу механизмін анықтайды. Оның орнына, бұл ақпарат DDL-де жазылған құрылғы сипаттамасы арқылы немесе белгілі бір құрылғы түрлері туралы алдын ала білу арқылы алдын ала бағдарламаланған болуы мүмкін.
Device Management Protocol (DMP) represents any device as a set of addressable properties which represent its current or desired state. Monitoring or control by a controller is achieved by setting or examining the values of those properties. To avoid the inefficiencies of polling, in addition to simply reading property values (using a Get Property message) DMP provides a subscription mechanism whereby a device will asynchronously send event messages to all subscribed controllers when the value of a property changes. DMP expects that its connections can provide reliability so that Set Property and Event messages which form a large part of the operational bandwidth in a show situation do not require explicit acknowledgement at the DMP level. In the E1.17 standard and the majority of systems SDT provides this reliability but DMP has also been operated using TCP to provide its reliable connections. The size in bits, representation, read/write accessibility and function of each property in a DMP device is not determined by the protocol which only defines the mechanism to read and/or write the property value. Instead, that information must either be provided externally by a device description written in DDL or in limited cases may be pre programmed by fore knowledge of specific device types.
Құрылғыны сипаттау тілі
Құрылғы сипаттау тілі (DDL) кез келген құрылғының интерфейсі мен мүмкіндіктерін машинамен оқуға арналған түрде сипаттауға мүмкіндік береді. Бұл сипаттаманы басқарушы интерпретациялай алады, содан кейін ол құрылғыны басқару үшін автоматты түрде конфигурацияланады. Сипаттама DMP жұмыс істеуі үшін қажетті мекенжай және қасиеттерді байланыстыру туралы ақпаратты ғана емес, сонымен қатар құрылғының функционалдығы, мүмкіндіктері және семантикасы туралы мол ақпаратты кеңейтілген форматта қамтиды, бұл басқарушыға өзінің нақты жағдайы үшін қажетті мүмкіндіктерді алуға, ал қажеттіліктеріне сәйкес келмейтін ақпаратты жіберіп тастауға мүмкіндік береді. DDL – XML негізіндегі тіл және сипаттамалар бірнеше XML құжатында сақталады. Кәдімгі ACN жүйелерінде құрылғының сипаттамасын өзінен жүктеуге болады. Дегенмен, сипаттамалар басқа тәсілдермен де таратылуы мүмкін (мысалы, интернеттен жүктеу арқылы), және сипаттама бір типтегі барлық құрылғылар үшін жарамды болғандықтан, басқарушылар көбінесе кездесетін құрылғылар үшін сипаттамалардың кэшін сақтай алады.
Device Description Language (DDL) allows a machine parsable description of the interface and capabilities of any device to be defined. This description can be interpreted by a controller which may then automatically configure itself for controlling that device. The description not only provides the address and property mapping information which is necessary for DMP to operate but it can also contain a huge amount of information on the functionality, capabilities and semantics of the device in an extensible format which allows a controller to extract the features it needs for its specific context while skipping over information which is not relevant to its needs. DDL is an XML based language and descriptions are contained in a small number of XML documents. In normal ACN systems the description for a device may be downloaded from the device itself. However, descriptions may also be distributed in other ways (such as internet download) and since a description is valid for all devices of the same type, controllers can typically maintain a cache of descriptions for devices they commonly encounter.
Өзара әрекеттесу профильдері
ANSI E1.17 стандарты жүйеде бастапқы қызметтерді іздеу, UDP және IPv4 пайдаланылған кезде көп тарату адрестерін бөлу, көп тарату кезінде UDP порттарын тағайындау, сәйкес жүйелерде IP-адрестерді беру, нақты орталарда протоколдың мерзімін бақылау және тағы да басқалары үшін пайдалы келеді. ACN архитектурасына сәйкес келетін басқа EPI-лер ANSI E1.17 стандартынан тыс әзірленді (төменде қараңыз).
Interoperability profiles (EPIs) are provided in ANSI E1.17 for initial service discovery in a system; for allocation of multicast addresses when used on UDP and IPv4; for UDP port allocation when multicasting, for IP address assignment in conformant systems, for protocol timeouts in specific environments and so on. Other EPIs which conform to the ACN Architecture have been developed outside the ANSI E1.17 standard (see below).
Сыртқы кеңейтулер
ACN-ның модульдік табиғатының арқасында оны кеңейту оңай болды. Сол ұйыммен негізгі ANSI E1.31 протоколы, яғни Ағызатын ACN немесе sACN әзірленді. Ол IP желілері (немесе кез келген басқа ACN үйлесімді тасымалдау арнасы) арқылы DMX512 деректерін тасымалдау үшін ACN Root Layer және PDU форматын пайдаланады. PLASA тарапынан бірнеше қосымша өзара іс-қимыл профильдері әзірленіп, стандартталды. Оларға мыналар кіреді:
Due to its modular nature ACN has been easy to extend. A major protocol ANSI E1.31 known as Streaming ACN or sACN was developed by the same organization and uses the Root Layer and PDU format of ACN to transport the data of DMX512 data over IP networks (or any other ACN compatible transport). A number of further Interoperability Profiles have been developed and standardized by PLASA. These include:
ANSI E1.30 3 2009 – SNTP және NTP қолданылып, ACN жүйелеріндегі уақыт анықтамасы.
ANSI E1.30 4 2010 – DMX512 немесе Ағызатын ACN арқылы басқарылатын құрылғыларды сипаттау үшін DDL-ді қалай пайдалану керектігін анықтайды.
ANSI E1.30 3 2009 Time Reference in ACN Systems Using SNTP and NTP
ANSI E1.30 4 2010 which defines how to use DDL to describe devices controlled using DMX512 or Streaming ACN