DOCSLIB.ORG

Ttethernet – a Powerful Network Solution for Advanced Integrated Systems Ttethernet: a Powerful Network Solution for Advanced Integrated Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Ttethernet – a Powerful Network Solution for Advanced Integrated Systems Ttethernet: a Powerful Network Solution for Advanced Integrated Systems GE Fanuc Intelligent Platforms TTEthernet – A Powerful Network Solution for Advanced Integrated Systems TTEthernet: A Powerful Network Solution for Advanced Integrated Systems TTEthernet – A Powerful Time-Triggered switches provide ARINC 664 functionality to meet existing Network Solution requirements of avionics Ethernet networks. With TTEthernet, critical control systems, audio/video and As the most widely-installed local area network technology, standard LAN applications can share one network. TTEthernet Ethernet is used as a universal network solution in office facilitates design of mixed criticality systems and system-of- and web applications, and production facilities. Engineering, systems integration. maintenance and training costs for Ethernet-based networks are considerably lower than costs for many proprietary bus In the aviation domain, TTEthernet can be used for high- systems and Ethernet generally offers higher bandwidths. speed active controls, smart sensor and actuator networks, But when Ethernet was developed over 30 years ago, time- deterministic avionics and vehicle backbone networks, critical, deterministic or safety-relevant tasks were not taken critical audio/video delivery, reflective memory, modular into account. controls and integrated modular systems such as Integrated Modular Avionics (IMA) or distributed IMA. TTEthernet also Time-Triggered Ethernet (TTEthernet) expands classical targets also critical embedded systems in aerospace and Ethernet use with powerful services (SAE AS6802) to meet defense, automotive, medical, energy production, and the new requirements of reliable, real-time data delivery industrial automation. in advanced integrated systems. In addition, TTEthernet Non-critical functions via IEEE 802.3 Ethernet (Asynchronous) Critical IMA functions via rate-constrained ARINC 664 (Asynchronous) Audio/Video delivery using time-triggered services (Synchronous) Critical (D)IMA/control functions via time-triggered services TTEthernet (Synchronous) Switch Figure 1: TTEthernet (SAE AS6802) enables design of advanced integrated systems utilizing asynchronous and synchronous communication via IEEE 802.3 Ethernet. It is scalable and supports fault-tolerant (N-redundant), time-critical and mixed criticality functions in one network. TTEthernet supports system-of-systems integration. 2 Determinism in Critical Ethernet Networks TTEthernet supports both asynchronous and synchronous Determinism is dependant on application domain require- (ARINC 664 and SAE AS6802) approaches to deterministic ments and represents predictable operation performance. networking, and enables parallel operation in mixed asyn- For networking domains, determinism is related to: chronous/synchronous networks. It is designed to cover • temporal communication behavior (message jitter cross-industry application needs and provide deterministic and latency) network operation for a broad range of different applica- • predictable bandwidth use tions. The primary reason for the integration of both SAE AS6802 and ARINC 664 on the same TTEthernet switch is the An Ethernet network with specified jitter and latency can be ensured availability of time-triggered services. Without those seen as deterministic “enough”, assuming that predictable services it would be impossible to define robust network par- data exchange without data traffic congestion is viable for a titioning for asynchronous and synchronous data flows. given application case. For ARINC 664 networks, the context of determinism is defined as the control of maximum trans- System Integration using Synchronous and Asynchronous mission delay (latency) throughout the network. Ethernet Communication Distributed functionality in advanced integrated network In the Time-Triggered Ethernet standard, SAE AS6802, systems is established by coordinated operation of differ- Time-Triggered Ethernet provides extensions to standard ent functions with different criticality-levels and quality of IEEE 802.3 to support hard real-time, rate-constrained service. In order to establish coordination among all of the and unconstrained IEEE 802.3 traffic on a common mixed- different functions on a network, some sort of “synchro- criticality network. A synchronization strategy based on nization” is required either at the network, middleware or time-triggered principles is described in the SAE AS6802 application layer, or combined at different layers at once. standard, defining a fault-tolerant self-stabilizing synchroni- zation strategy. Devices that comply with this standard are IEEE 802.3 Ethernet provides asynchronous communication capable of synchronizing their local clocks to each other in services. By constraining the maximum rate of message a fault-tolerant way. The context of determinism is defined delivery, jitter (e.g. 500µs) and latency, the deterministic as exact system timing throughout the system. Messages communication behavior for avionics applications can are transferred based on a fault-tolerant system time base be accomplished without synchronous communication, with microsecond jitter. as described in the ARINC 664 (Avionics Full Duplex Ethernet) Specification. Predictable (deterministic) operation in IEEE 802.3 Ethernet networks for critical embedded systems can be achieved by: At the network level, ARINC 664 operates asynchronously and coordination among distributed functions using • Asynchronous approach (ARINC 664): Constraining the ARINC 664 networks is “synchronized” at higher-level OSI rate (frequency) of data transmissions (e.g. max. jitter layers. In this case, jitter is in Nx100 µs range and latencies 500µs, latency > jitter) with sampling rates of upto 1KHz. are in the order of 1 to 10 milliseconds or higher. High jitter Bandwidth partitioning is based on rate-constrained traf- influences the accuracy of point-to-point latency and fic shaping (in end systems) and policing (in the switch) limits maximum achievable sampling rates, especially in a • Synchronous approach (SAE AS6802): Establishing fault- complex system with several switches (multi-hop networks). tolerant synchronized operation using asynchronous Maximum latencies of 10 or more milliseconds are not Ethernet messaging with sampling rates of upto 50kHz unusual in complex ARINC 664 networks. Therefore the (jitter below few microseconds). The bandwidth partition- applications and higher layers should be designed to be ing is based on exact (µs) time base and message delivery robust against latency and high jitter. So the idea of deter- based on time-triggered services. minism here is not to constrain jitter, but to have a known • Mixed asynchronous/synchronous approach to satisfy maximum latency throughout the network. different contexts of determinism in different applications using critical Ethernet networks 3 TTEthernet: A Powerful Network Solution for Advanced Integrated Systems Determinism Context: Control jitter and exact timing in the system (µs jitter and minimize latency) Determinism Context: 10 kHz Control maximal 1000 µs latency in the system 1 kHz 100 µs 10 Hz 10 µs 1 Hz 1 µs Asynchronous Synchronous Asynchronous Synchronous (rate-constrained) (time-triggered) (rate-constrained) (time-triggered) Figure 2 Determinism context in Ethernet networks depends of the application (max. sampling rate) and the approach to system design – asynchronous (coordination and synchronization among functions is conducted at higher layers) or synchronous (control of timing and synchronization at network level). It is easier to control accurate (µs jitter!) network timing using services which are integrated closer to the com- System latency in asynchronous systems munication layer, so it makes sense to add fault-tolerant contains a large jitter-related component synchronization at the Ethernet network level as an addi- and an additional tional service (SAE AS6802). Higher layers and middleware margin to ensure maximum latency are therefore simpler and can support efficient use of computing resources. 15 µs Due to low jitter and ability to narrowly control latency, it System latency can be factored out by system is possible to precisely control network bandwidth use and 10 µs design and system its allocation to asynchronous or synchronous traffic with design and system timing robust network bandwidth partitioning. This level of control 5 ms control (Time-Triggered Architecture - TTA) supports design of well-defined and unambiguous key system interfaces to simplify system integration. So 1 ms determinism in SAE AS6802 Time-Triggered Ethernet is to minimize jitter and at the same time have well-defined Asynchronous Synchronous latency. The control of timing throughout a network system (rate-constrained) (time-triggered) also helps to reduce maximum latency. Otherwise the jitter in a system represents an uncertainty which requires Figure 3 Maximum latency throughout the system is influenced additional margins be added to the maximum latency to by jitter in asynchronous (rate constrained) and synchronous guarantee deterministic behavior. The positive side-effect (time-triggered) systems. The maximum latency in the system of a synchronous approach is that latency can be ruled out represents a trade-off between synchronous and asynchronous from system design considerations if the global time base is design paradigm. available and the jitter is in microseconds. 4 In avionics networks, the SAE AS6802 standard is a synchro- challenges for complex distributed systems by robust par- nous communication technology enabling hard real-time
Load more

Recommended publications
  • On Ttethernet for Integrated Fault-Tolerant Spacecraft Networks
    On TTEthernet for Integrated Fault-Tolerant Spacecraft Networks Andrew Loveless∗ NASA Johnson Space Center, Houston, TX, 77058 There has recently been a push for adopting integrated modular avionics (IMA) princi- ples in designing spacecraft architectures. This consolidation of multiple vehicle functions to shared computing platforms can significantly reduce spacecraft cost, weight, and de- sign complexity. Ethernet technology is attractive for inclusion in more integrated avionic systems due to its high speed, flexibility, and the availability of inexpensive commercial off-the-shelf (COTS) components. Furthermore, Ethernet can be augmented with a variety of quality of service (QoS) enhancements that enable its use for transmitting critical data. TTEthernet introduces a decentralized clock synchronization paradigm enabling the use of time-triggered Ethernet messaging appropriate for hard real-time applications. TTEther- net can also provide two forms of event-driven communication, therefore accommodating the full spectrum of traffic criticality levels required in IMA architectures. This paper explores the application of TTEthernet technology to future IMA spacecraft architectures as part of the Avionics and Software (A&S) project chartered by NASA's Advanced Ex- ploration Systems (AES) program. Nomenclature A&S = Avionics and Software Project AA2 = Ascent Abort 2 AES = Advanced Exploration Systems Program ANTARES = Advanced NASA Technology Architecture for Exploration Studies API = Application Program Interface ARM = Asteroid Redirect Mission
    [Show full text]
  • Study of the Time Triggered Ethernet Dataflow
    Institutionen f¨ordatavetenskap Department of Computer and Information Science Final thesis Study of the Time Triggered Ethernet Dataflow by Niclas Rosenvik LIU-IDA/LITH-EX-G{15/011|SE 2015-07-08 Linköpings universitet Linköpings universitet SE-581 83 Linköping, Sweden 581 83 Linköping Link¨opingsuniversitet Institutionen f¨ordatavetenskap Final thesis Study of the Time Triggered Ethernet Dataflow by Niclas Rosenvik LIU-IDA/LITH-EX-G{15/011|SE 2015-07-08 Supervisor: Unmesh Bordoloi Examiner: Petru Eles Abstract In recent years Ethernet has caught the attention of the real-time commu- nity. The main reason for this is that it has a high data troughput, 10Mbit/s and higher, and good EMI characteristics. As a protocol that might be used in real-time environments such as control systems for cars etc, it seems to fulfil the requirements. TTEthernet is a TDMA extension to normal Eth- ernet, designed to meet the hard deadlines required by real-time networks. This thesis describes how TTEthernet handles frames and the mathemat- ical formulas to calculate shuffle delay of frames in such a network. Open problems related to TTEthernet are also discussed. iii Contents 1 Introduction 1 2 Ethernet 2 2.1 Switching . 2 2.2 Ethernet frame format . 3 2.3 The need for TTEthernet . 4 3 TTEthernet 6 3.1 TTEthernet spec . 6 3.1.1 Protocol control frames . 6 3.1.2 Time-triggered frames . 7 3.1.3 Rate constrained frames . 9 3.1.4 Best effort frames . 10 3.2 Integration Algorithms . 10 3.2.1 Shuffling . 10 3.2.2 Preemption .
    [Show full text]
  • Generating Synthetic Voip Traffic for Analyzing Redundant Openbsd
    UNIVERSITY OF OSLO Department of Informatics Generating Synthetic VoIP Traffic for Analyzing Redundant OpenBSD-Firewalls Master Thesis Maurice David Woernhard May 23, 2006 Generating Synthetic VoIP Traffic for Analyzing Redundant OpenBSD-Firewalls Maurice David Woernhard May 23, 2006 Abstract Voice over IP, short VoIP, is among the fastest growing broadband technologies in the private and commercial sector. Compared to the Plain Old Telephone System (POTS), Internet telephony has reduced availability, measured in uptime guarantees per a given time period. This thesis makes a contribution towards proper quantitative statements about network availability when using two redun- dant, state synchronized computers, acting as firewalls between the Internet (WAN) and the local area network (LAN). First, methods for generating adequate VoIP traffic volumes for loading a Gigabit Ethernet link are examined, with the goal of using a minimal set of hardware, namely one regular desktop computer. pktgen, the Linux kernel UDP packet generator, was chosen for generating synthetic/artificial traffic, reflecting the common VoIP packet characteristics packet size, changing sender and receiver address, as well as typical UDP-port usage. pktgen’s three main parameters influencing the generation rate are fixed inter-packet delay, packet size and total packet count. It was sought to relate these to more user-friendly val- ues of amount of simultaneous calls, voice codec employed and call duration. The proposed method fails to model VoIP traffic accurately, mostly due to the cur- rently unstable nature of pktgen. However, it is suited for generating enough packets for testing the firewalls. Second, the traffic forwarding limit and failover behavior of the redun- dant, state-synchronized firewalls was examined.
    [Show full text]
  • An Extension of the Omnet++ INET Framework for Simulating Real-Time Ethernet with High Accuracy
    An Extension of the OMNeT++ INET Framework for Simulating Real-time Ethernet with High Accuracy Till Steinbach, Hermand Dieumo Kenfack, Franz Korf, Thomas C. Schmidt HAW-Hamburg, Department Informatik Berliner Tor 7, D-20099 Hamburg, Germany {till.steinbach, hermand.dieumo, korf, schmidt}@informatik.haw-hamburg.de ABSTRACT those fields; real-time Ethernet is a promising candidate for Real-time extensions to standard switched Ethernet widen the upcoming tasks. the realm of computer networking into the time-critical do- Ethernet has proven to be a flexible, widely deployed, and main. These technologies have started to establish in pro- highly scalable protocol. Current Ethernet is a technology cess automation, while Ethernet-based communication in- based on switching that also allows to increase the amount of frastructures in vehicles are novel and challenged by particu- traffic simultaneously transferred, by using segregated com- larly hard real-time constraints. Simulation tools are of vital munication in groups. However, due to its randomised me- importance to explore the technical feasibility and facilitate dia access and best effort approach, it does not provide re- the distributed process of vehicle infrastructure design. liable temporal performance bounds. Real-time extensions This paper introduces an extension of the OMNeT++ to Ethernet promise to overcome those obstacles. INET framework for simulating real-time Ethernet with high In process automation, several Ethernet-based products temporal accuracy. Our module implements the TTEther- already provide real-time functionality for tasks with strict net protocol, a real-time extension to standard Ethernet that temporal constraints. The use of real-time Ethernet in an is proposed for standardisation.
    [Show full text]
  • Developments in Audio Networking Protocols By: Mel Lambert
    TECHNICAL FOCUS: SOUND Copyright Lighting&Sound America November 2014 http://www.lightingandsoundamerica.com/LSA.html Developments in Audio Networking Protocols By: Mel Lambert It’s an enviable dream: the ability to prominent of these current offerings, ular protocol and the basis for connect any piece of audio equip- with an emphasis on their applicability Internet-based systems: IP, the ment to other system components within live sound environments. Internet protocol, handles the and seamlessly transfer digital materi- exchange of data between routers al in real time from one device to OSI layer-based model for using unique IP addresses that can another using the long-predicted con- AV networks hence select paths for network traffic; vergence between AV and IT. And To understand how AV networks while TCP ensures that the data is with recent developments in open work, it is worth briefly reviewing the transmitted reliably and without industry standards and plug-and-play OSI layer-based model, which divides errors. Popular Ethernet-based proto- operability available from several well- protocols into a number of smaller cols are covered by a series of IEEE advanced proprietary systems, that elements that accomplish a specific 802.3 standards running at a variety dream is fast becoming a reality. sub-task, and interact with one of data-transfer speeds and media, Beyond relaying digital-format signals another in specific, carefully defined including familiar CAT-5/6 copper and via conventional AES/EBU two-chan- ways. Layering allows the parts of a fiber-optic cables. nel and MADI-format multichannel protocol to be designed and tested All AV networking involves two pri- connections—which requires dedicat- more easily, simplifying each design mary roles: control, including configur- ed, wired links—system operators are stage.
    [Show full text]
  • Overview on IP Audio Networking Andreas Hildebrand, RAVENNA Evangelist ALC Networx Gmbh, Munich Topics
    Overview on IP Audio Networking Andreas Hildebrand, RAVENNA Evangelist ALC NetworX GmbH, Munich Topics: • Audio networking vs. OSI Layers • Overview on IP audio solutions • AES67 & RAVENNA • Real-world application examples • Brief introduction to SMPTE ST2110 • NMOS • Control protocols Overview on IP Audio Networking - A. Hildebrand # 1 Layer 2 Layer 1 AVB EtherSound Layer 3 Audio over IP Audio over Ethernet ACIP TCP unicast RAVENNA AES67 multicast RTP UDP X192 Media streaming Dante CobraNet Livewire Overview on IP Audio Networking - A. Hildebrand # 3 Layer 2 Layer 1 AVB Terminology oftenEtherSound Layer 3 Audio over IP • ambiguousAudio over Ethernet ACIP TCP unicast • usedRAVENNA in wrongAES67 context multicast RTP • marketingUDP -driven X192 Media streaming • creates confusion Dante CobraNet Livewire Overview on IP Audio Networking - A. Hildebrand # 4 Layer 2 Layer 1 AVB Terminology oftenEtherSound Layer 3 Audio over IP • ambiguousAudio over Ethernet ACIP TCP Audio over IP unicast • usedRAVENNA in wrongAES67 context multicast RTP • marketingUDP -driven X192 Media streaming • creates confusion Dante CobraNet Livewire Overview on IP Audio Networking - A. Hildebrand # 5 Layer 7 Application Application Application and Layer 6 Presentation protocol-based layers Presentation HTTP, FTP, SMNP, Layer 5 Session Session POP3, Telnet, TCP, Layer 4 Transport UDP, RTP Transport Layer 3 Network Internet Protocol (IP) Network Layer 2 Data Link Ethernet, PPP… Data Link Layer 1 Physical 10011101 Physical Overview on IP Audio Networking - A. Hildebrand # 10 Physical transmission Classification by OSI network layer: Layer 1 Systems Transmit Receive Layer 1 Physical 10011101 Physical Overview on IP Audio Networking - A. Hildebrand # 12 Physical transmission Layer 1 systems: • Examples: SuperMac (AES50), A-Net Pro16/64 (Aviom), Rocknet 300 (Riedel), Optocore (Optocore), MediorNet (Riedel) • Fully proprietary systems • Make use of layer 1 physical transport (e.g.
    [Show full text]
  • Model 5421 Dante® Intercom Audio Engine
    Model 5421 Dante® Intercom Audio Engine Key Features • 16-channel audio engine creates multiple • DDM support and AES67 compliant virtual party-line (PL) intercom circuits • PoE powered, Gigabit Ethernet interface • Dante audio-over-Ethernet technology • Configured using STcontroller application • Auto Mix for enhanced audio performance • Table-top, portable, or optional rack-mount • Supports Studio Technologies’ intercom installation beltpacks Overview The Model 5421 Dante® Intercom Audio Engine is a high- enclosure can be used stand-alone or mounted in one space performance, cost-effective, flexible solution for creating (1U) of a standard 19-inch rack enclosure with an optional party-line (PL) intercom circuits. It’s directly compatible rack-mount installation kit. To meet the latest interoper- with the Studio Technologies’ range of 1-, 2-, and 4-chan- ability standard the Model 5421’s Dante implementation nel Dante-enabled beltpacks and other interface-related meets the requirements of AES67 as well as supporting the products. The unit is suitable for use in fixed and mobile Dante Domain Manager (DDM) application. Using DDM, broadcast facilities, post-production studios, commercial compliance with ST 2110-30 may be possible. and educational theater environments, and entertainment The Model 5421 provides one 16-channel audio engine applications. which can be configured to provide from one to four “virtual” Only a Gigabit Ethernet network connection with Power- intercom circuits. The term “audio engine” was selected over-Ethernet (PoE) support is required for the Model to describe a set of audio input, processing, routing, and 5421 to provide a powerful resource in a variety of Dante output resources that can be configured to support spe- applications.
    [Show full text]
  • Hasseb Audio Over Ethernet XLR Instructions Manual Version
    September HASSEB AUDIO OVER ETHERNET XLR INSTRUCTIONS MANUAL 19, 2018 VERSION 1.0 HASSEB AUDIO OVER ETHERNET XLR hasseb Audio over Ethernet XLR is an easy to use and portable device used to send lossless, realtime microphone audio signal using Ethenet network. The device is compatible with AES67 standard and can be used as a standalone device or together with other AES67 compatible devices. Two 3-pin XLR audio connectors are used to connect microphones to Ethernet netowork. The device has two input channels with a high quality analog amplifier and A/D converter to digitize the analog microphone signals. In addition, the device has a 48 V phantom source for microphones requiring phantom power. The device is configured using a web user interface and mDNS (multicast Domain Name System) protocol is supported to easily find the device IP addresses from the network. For professional grade network audio systems PTP (Precision Time Protocol) based time synchronization is required. The device can act as IEEE1588 grand master to provide synchronization clock signal to the network. INSTALLATION The device can be powered through the Ethernet cable using a Power over Ethernet capable switch of through a micro USB connector with an external 5 V USB power supply. DHCP (Dynamic Host Configuration Protocol) support is enabled by default, so the device will assign an IP address automatically. All hasseb Audio over Ethernet XLR devices and most other AES67 devices and their names and IP addresses connected to the network can be found using any software, capable of searching the network for mDNS supported devices.
    [Show full text]
  • Implementing Audio-Over-IP from an IT Manager's Perspective
    Implementing Audio-over-IP from an IT Manager’s Perspective Presented by: A Partner IT managers increasingly expect AV systems to be integrated with enterprise data networks, but they may not be familiar with the specific requirements of audio-over-IP systems and common AV practices. Conversely, AV professionals may not be aware of the issues that concern IT managers or know how best to achieve their goals in this context. This white paper showcases lessons learned during implementations of AoIP networking on mixed-use IT infrastructures within individual buildings and across campuses. NETWORKS CONVERGE AS IT such as Cisco and Microsoft. AV experts MEETS AV do not need to become IT managers to As increasing numbers of audio-visual do their jobs, as audio networking relies systems are built on network technology, only on a subset of network capabilities, IT and AV departments are starting configurations, and issues. to learn how to work together. As AV experts come to grips with the terminology Similarly, IT managers are beginning and technology of audio-over-IP, IT to acquaint themselves with the issues specialists—gatekeepers of enterprise associated with the integration and networks—are beginning to appreciate implementation of one or more networked the benefits that AV media bring to their AV systems into enterprise-wide converged enterprises. networks. Once armed with a clear understanding of the goals and uses This shift means that the IT department of these systems, IT managers quickly of any reasonably sized enterprise— discover that audio networking can be commercial, educational, financial, easily integrated with the LANs for which governmental, or otherwise—is they are responsible.
    [Show full text]
  • Developing Deterministic Networking Technology for Railway Applications Using Ttethernet Software-Based End Systems
    INDustrial EXploitation of the genesYS cross-domain architecture Developing deterministic networking technology for railway applications using TTEthernet software-based end systems Project n° 100021 Astrit Ademaj, TTTech Computertechnik AG Outline INDustrial EXploitation of the genesYS cross-domain architecture GENESYS requirements - railway Time-triggered communication TTEthernet SW based implementation of the TTEthernet Conclusion ARTEMISIA Association Title Presentation - 2 GENESYS – GENeric Embedded SYStems INDustrial EXploitation of the genesYS cross-domain architecture Instruction how to build your embedded systems architecture GENESYS: ¾ is a reference architecture template providing specifications and requirements to design a cross domain embedded systems architecture. ¾ architecture style supports a composable, robust and comprehensible, component based framework with strict separation of computation from message based communication ¾ distinguishes between 3 integration levels: • Chip Level (IP cores communicate via a deterministic Network-on-a-Chip) • Device Level (Chips communicate within a device) • System Level (Devices communicate in an open or closed environment) ARTEMISIA Association Title Presentation - 3 GENESYS and the railway domain INDustrial EXploitation of the genesYS cross-domain architecture Safety-critical applications in the railway domain require ¾ deterministic communication networks ¾ robustness and ¾ composability are key issues. GENESYS ¾ architecture style supports a composable, robust and comprehensible,
    [Show full text]
  • Protocol Selection Table
    Protocol Selection Table Bender offers signal line protection devices for many different communication and signal protocols. Use the table below to know which protectors must be used for a good surge protection. Selection table Protocol Signal Bender Surge protector I/O ± 5 VDC, < 250kHz NSL7v5-G NSLT1-7v5 I/O ± 12 VDC, < 250kHz NSL18-G NSLT1-18 I/O ± 24 VDC, < 250kHz NSL36-G NSLT1-36 I/O 0-20mA / 4-20mA NSL420-G NSLT1-36 I/O RS-232 NSL-DH I/O RS-422 NSL485-EC90 (x2) I/O RS-452 NSL485-EC90 (x2) I/O RS-485 NSL485-EC90 I/O 1-Wire NSL485-EC90 Protocol Signal Bender Surge protector 10/100/1000BaseT Ethernet NTP-RJ45-xCAT6 AS-i 32 VDC 1-pair NSL36-G NSLT1-36 BACnet ARCNET / Ethernet / BACnet/IP NTP-RJ45-xCAT6 BACnet RS-232 NSL-DH BACnet RS-485 NSL485-EC90 BitBus RS-485 NSL485-EC90 CAN Bus (Signal) 5 VDC 1-Pair NSL485-EC90 C-Bus 36 VDC 1-pair NSSP6A-38 CC-Link/LT/Safety RS-485 NSL485-EC90 CC-Link IE Field Ethernet NTP-RJ45-xCAT6 CCTV Power over Ethernet NTP-RJ45-xPoE DALI Digital Serial Interface NSL36-G NSLT1-36 Data Highway/Plus RS-485 NSL485-EC90 DeviceNet (Signal) 5 VDC 1-Pair NSL7v5-G NSLT1-7v5 DF1 RS-232 NSL-DH DirectNET RS-232 NSL-DH DirectNET RS-485 NSL485-EC90 Dupline (Signal) 5 VDC 1-Pair NSL7v5-G NSLT1-7v5 Dynalite DyNet NTP-RJ45-xCAT6 EtherCAT Ethernet NTP-RJ45-xCAT6 Ethernet Global Data Ethernet NTP-RJ45-xCAT6 Ethernet Powerlink Ethernet NTP-RJ45-xCAT6 Protocol Signal Bender Surge protector FIP Bus RS-485 NSL485-EC90 FINS Ethernet NTP-RJ45-xCAT6 FINS RS-232 NSL-DH FINS DeviceNet (Signal) NSL7v5-G NSLT1-7v5 FOUNDATION Fieldbus H1
    [Show full text]
  • Hono AVB Custom MODULAR AVB 1U INTERFACE
    November 5, 2020 Hono AVB Custom MODULAR AVB 1U INTERFACE 1 DESCRIPTION FEATURES The Hono AVB Custom is an AVB audio interface in a 1U 4 AVB transmit and 4 AVB receive streams. rack mount format providing up to 32 channels of AVB receive and transmit. Stream formats of 1,2,4,8,16 and 32 channels. The unit can be populated with up to four function specific 1U rack-mount unit. modules, allowing up to 16 channels of analog or AES/EBU I/O. Each module has an interchangeable connector that may Modular architecture allows up to 4 I/O modules to be be configured with either a pluggable terminal block, inserted into the back of the unit. StudioHub+® RJ-45, or a 50pin Centronics connector with XLR breakout cables. Module connector options include Terminal Block ® (Phoenix style), StudioHub+ RJ-45, or 50pin Centronics The AVB Custom features a powerful Texas Instruments 32bit connector with XLR breakout cables. floating point DSP that allows sophisticated switching/mixing. A graphics display on the unit’s front panel shows peak Available modules include eight-channel analog I/O and meters and status. eight channel AES/EBU I/O, 8 channel mic preamp and 16x16 GPIO. AudioScience provides application software that may be used to set up the AVB Custom. ASIControl sets up all internal Powerful floating point DSP provides metering, level features of the unit. 3rd party software allows AVB routing control and up to 20 dB gain on all signal paths. connections to be set up between the unit and any other AVB Interoperable with all AudioScience AVB Sound Cards device on the network.
    [Show full text]