Tag Archives: Ethernet

How Ethernet AVB is playing a central role in automotive streaming applications


Ethernet is emerging as the network of choice for infotainment and advanced driver assistance systems, Atmel’s Tim Grai explains.


Imagine you’re driving down the highway with the music blaring, enjoying the open road. Now imagine that the sound from your rear speaker system is delayed by a split second from the front; your enjoyment of the fancy in-car infotainment system comes to a screeching halt.

Ethernet is emerging as the network of choice for infotainment and advanced driver assistance systems that include cameras, telematics, rear-seat entertainment systems and mobile phones. But standard Ethernet protocols can’t assure timely and continuous audio/video (A/V) content delivery for bandwidth intensive and latency sensitive applications without buffering, jitter, lags or other performance hits.

fig1_popup

Audio-Video Bridging (AVB) over Ethernet is a collection of extensions to the IEEE802.1 specifications that enables local Ethernet networks to stream time synchronised, loss sensitive A/V data. Within an Ethernet network, the AVB extensions help differentiate AVB traffic from the non-AVB traffic that can also flow through the network. This is done using an industry standard approach that allows for plug-and-play communication between systems from multiple vendors.

The extensions that define the AVB standard achieve this by:

  • reserving bandwidth for AVB data transfers to avoid packet loss due to network congestion from ‘talker’ to ‘listener(s)’
  • establishing queuing and forwarding rules for AVB packets that keep packets from bunching and guarantee delivery of packets with a bounded latency from talker to listener(s) via intermediate switches, if needed
  • synchronizing time to a global clock so the time bases of all network nodes are aligned precisely to a common network master clock, and
  • creating time aware packets which include a ‘presentation time’ that specifies when A/V data inside a packet has to be played.

Designers of automotive A/V systems need to understand the AVB extensions and requirements, as well as how their chosen microcontroller will support that functionality.

AVB: A basket of standards

AVB requires that three extensions be met in order to comply with IEEE802.1:

  • IEEE802.1AS – timing and synchronisation for time-sensitive applications (gPTP)
  • IEEE802.1Qat – stream reservation protocol (SRP)
  • IEEE802.1Qav – forwarding and queuing for time-sensitive streams (FQTSS).

In order to play music or video from one source, such as a car’s head unit, to multiple destinations, like backseat monitors, amplifiers and speakers, the system needs a common understanding of time in order to avoid lags or mismatch in sound or video. IEEE802.1AS-2011 specifies how to establish and maintain a single time reference – a synchronised ‘wall clock’ – for all nodes in a local network. The generalized precision time protocol (gPTP), based on IEEE1588, is used to synchronize and syntonize all network nodes to sub-microsecond accuracy. Nodes are synchronized if their clocks show the same time and are syntonised if their clocks increase at the same rate.

fig.2

This protocol selects a Grand Master Clock from which the current time is propagated to all network end-stations. In addition, the protocol specifies how to correct for clock offset and clock drifts by measuring path delays and frequency offsets. New MCUs, such as the Atmel | SMART SAMV7x (shown above), detect and capture time stamps automatically when gPTP event messages cross MII layers. They can also transport gPTP messages over raw Ethernet, IPv4 or IPv6. This hardware recognition feature helps to calculate clock offset and link delay with greater accuracy and minimal software load.

Meanwhile, SRP guarantees end-to-end bandwidth reservation for all streams to ensure packets aren’t delayed or dropped at any switch due to network congestion, which can occur with standard Ethernet. For the in-vehicle environment, SRP is typically configured in advance by the car maker, who defines data streams and bandwidth allocations.

Talkers (the source of A/V data) ‘advertise’ data streams and their characteristics. Switches process these announcements from talker and listeners to:

  • register and prune streams’ path through the network
  • reserve bandwidth and prevent over subscription of available bandwidth
  • establish forwarding rules for incoming packets
  • establish the SRP domain, and
  • merge multiple listener declarations for the same stream

The standard stipulates that AVB data can reserve only 75% of total available bandwidth, so for a 100Mbit/s link, the maximum AVB data is 75Mbit/s. The remaining bandwidth can be used for all other Ethernet protocols.

In automotive systems, the streams may be preconfigured and bandwidth can be reserved statically at system startup to reduce the time needed to bring the network into a fully operational state. This supports safety functions, such as driver alerts and the reversing camera, that must be displayed within seconds.

SRP uses other signalling protocols, such as Multiple MAC Registration Protocol, Multiple VLAN Registration Protocol and Multiple Stream Registration Protocol to establish bandwidth reservations for A/V streams dynamically.

The third extension is FQTSS, which guarantees that time sensitive A/V streams arrive at their listeners within a bounded latency. It also defines procedures for priority regenerations and credit based traffic shaper algorithms to meet stream reservations for all available devices.

The AVB standard can support up to eight traffic classes, which are used to determine quality of service. Typically, nodes support at least two traffic classes – Class A, the highest priority, and Class B. Microcontroller features help manage receive and transmit data with multiple priority queues to support AVB and ‘best effort class’ non AVB data.

box

Automotive tailored requirements

Automotive use cases typically fix many parameters at the system definition phase, which means that AVB implementation can be optimised and simplified to some extent.

  • Best Master Clock algorithm (BMCA): the best clock master is fixed at the network definition phase so dynamic selection using BCMA isn’t needed.
  • SRP: all streams, their contents and their characteristics are known at system definition and no new streams are dynamically created or destroyed; the proper reservation of data is known at the system definition phase; switches, talkers and listeners can have their configurations loaded at system startup from pre-configured tables, rather than from dynamic negotiations
  • Latency; while this is not critical, delivery is. Automotive networks are very small with only a few nodes between a talker and listener. It is more important not to drop packets due to congestion.

Conclusion

The requirement to transfer high volumes of time sensitive audio and video content inside vehicles necessitates developers to understand and apply the Ethernet AVB extensions. AVB standardization results in interoperable end-devices from multiple vendors that can deliver audio and video streams to distributed equipment on the network with micro-second accuracy or better. While the standard brings complexities, new MCUs with advanced features are simplifying automotive A/V design.


This article was originally published on New Electronics on October 13, 2015 and authored by Tim Grai, Atmel’s Director of Automotive MCU Application Engineering. 

Nuvation talks Atmel and batteries at EELive! 2014

Nuvation CEO Mike Worry is at Atmel’s EELive! 2014 ToT booth presenting a series of Tech Talks about his company’s EV Battery Management System. His presentations have been covered by a number of prominent journalists, including Steve Taranovich of EDN.

“We’e seen enough instances of battery disasters occurring over the last few years in our industry. Batteries have a tremendous amount of energy within and if not properly handled and charged/monitored can be dangerous,” writes Taranovich.

“With chemistries such as Lithium, each cell must have its voltage monitored and balanced. This not only extends battery life, but prevents tragedies. [This is why] Nuvation has expertly developed their customizable battery Management System (BMS) that can handle 10s to 1,000s of cells. The system is easily made compatible with lithium, nickel, silver based and other battery chemistries.”

In terms of the Tank Controller, Nuvation selected Atmel’s ATSAM4E8C, a 32-bit ARM Cortex-M4 controller to power a wide range of features, including Ethernet, UART, CAN, current shunt and optically-isolated GPIO.

As Taranovich notes, the Tank Controller is also equipped with an optically-isolated interface to battery pack management (PackMan) strings.

“The system handles soft-start, main start and emergency disconnect and controls the charging system to protect the battery,” says Taranovich.

Meanwhile, the PackMan, or BMS slave utilizes Atmel’s ATA6870N, a Li-Ion, NiMH battery measuring, charge balancing and power-supply circuit.

This IC is tasked with measuring all cell voltages simultaneously – and balancing cells with higher voltage. 

Each IC is capable of monitoring 6 cells, with a daisy chain configuration supporting up to 16 PackMan board or 96 stacked cells.

“Nuvation’s BMS must deal with the balance/imbalance of a battery pack. It looks at the state-of-charge (SOC) between cells in the pack,” Taranovich adds. “The usable SOC of pack is determined by the lowest energy cell and then the BMS has the task of balancing these cells accurately and quickly without overcharging or overheating the cell.”

Interested in learning more? You can check out Nuvation’s official site here, while the full text of Steve Taranovich’s “Nuvation at EELive: The Fun in Electronics Design” can be read on EDN here.

ATmega328P + ARM Cortex-A7 = Akarel

Akarel – which recently surfaced on Indiegogo – is a hardware development kilt that integrates Atmel’s ATmega328P microcontroller (MCU) and a 1GHz Allwinner A20 dual-core ARM Cortex-A7 processor (CPU) on a single board with a touch screen.

As Akarel creator Karel Kyovsky notes, the platform is targeted at devs and Makers who require a touch screen interface to implement their respective projects.

The development platform is currently available in two iterations: Akarel 7 (7-inch display) and Akarel22 (22-inch display). The former features an industrial grade projected capacitive multi touch connected via I2C, while the latter is equipped with a USB-linked capacitive single touch.

“Some development kits are missing displays or touch, [while] others use obscure software stacks. Imagine implementing your hack ideas within hours instead of days like you’ve been doing until now,” Kyovsky explained.

“Akarel integrates Android OS running on [the] ARM Cortex A7 via UART, with Arduino software running on [Atmel’s] ATmega328P MCU. Integration and connection of both chips on [a single] PCB [offers a number of] advantages.”

According to Kyovsky, these include:

  • 

Graphics and UI capabilities of Google’s flagship Android OS
  • Optimized environment for application development
  • Seamless network connectivity via WiFi or Ethernet
  • Access to extensive Arduino community libraries

Kyovsky says he envisions Akarel being used to develop smart home automation and security systems, kiosks/payment terminals, along with Internet of Things (IoT) devices and appliances.

On the software side, the Akarel kit offers Makers and developers access to a Git repository stocked with Uboot source code, Linux kernel source (3.4.39), fine-tuned Android OS sources (4.2.2), Arduino firmware sources, Arduino tools (i.e. avrdude) and example apps.

“We want you to concentrate on writing an application not on spending time to make the basic things work. We have done it for you already. And if you want to dive deeper and modify the Linux kernel or Android OS…Why not? You have all the sources available for you to change and compile,” Kyovsky added.

“In order to save you from the hell of installing all the toolchain (correct version of gcc, libs, headers, automake, make, java, you name it) we have also prepared a Ubuntu virtual machine for you which may be downloaded and which has [the entire] toolchain preinstalled so that you can start recompiling your complete stack within a few minutes.”

Interested in learning more about the Akarel? You can check out the project’s official Indiegogo page here.

Video: Diving under the sea with a DIY ROV

Doug and Kay are currently building an underwater ROV capable of diving 3,000 below the waves, maneuvering on the ocean floor and relaying video as well as side-scan sonar signals back to the surface.

As HackADay’s Brian Benchoff notes, the duo continues to document the entire build process on YouTube, with the first video depicting the construction of a pressure vessel.

“For communication with the surface everything is passing over a single Cat5 cable. They’re using an Ethernet extender that uses a twisted wire pair to bring Ethernet to the ocean bottom,” Benchoff explained.

“With that, a few IP webcams relay video up to the ship and a simple [Atmel-based] Arduino setup allows for control of the ship’s thrusters.”


In terms of the thrusters, Doug and Kay selected off the shelf brushless mortars for model RC cars and planes.

“By potting the coils of a brushless outrunner motor, Doug and Kay found this solution makes an awful lot of sense,” Benchoff continued.

“It’s cheap, fairly reliable, doesn’t require a whole lot of engineering.”

Interested in learning more about the undersea ROV project? You can check out Doug and Kay’s official blog here.

Powering industrial communications with Atmel

Industrial communications are a critical aspect of current-gen automated systems – with defined standards that continue to evolve as new industrial Ethernet protocols emerge. Atmel’s versatile portfolio of microcontrollers (MCUs) provides engineers with the peripherals and internal system architecture required to efficiently interface new products with leading field busses, industrial Ethernet standards and wireless communications.

Field Bus

Atmel offers a dedicated RS485 mode for USART peripherals which is available on most ARM processor-based AT91SAM and AVR 32-bit microcontrollers. Meanwhile, a rich number of DMA channels on Atmel megaAVR, AVR XMEGA, AVR 32-bit and AT91SAM MCUs unload the CPU during industrial communication transfers, with multi-layer bus implementation on Atmel 32-bit microcontrollers enabling true parallel data transfers and effectively minimizing bus load limitation.

In addition, there is an (optional) external bus interface on several Atmel microcontrollers, with up to 32-bit data supports dedicated ASSP for protocols such as Profibus. Plus, up to 12Mbps USART on the SAM3U and SAM9 microcontrollers provides support for external transceivers. In terms of single or dual CAN controllers, select Atmel MCUs are V2.0A and V2.0B standard compliant, supporting independent message objects that are programmable on the fly and ideal for field bus such as CANopen and DeviceNet.

Industrial Ethernet

The vertical integration of management execution systems with factory floor equipment has resulted in the continued convergence of the Ethernet TCP/IP protocol with industrial field busses. As noted above, several industrial Ethernet protocols have emerged, including Profinet, Ethernet/IP, ModbusTCP/IP, EtherCat and Ethernet Powerlink.

“Most industrial Ethernet automated systems do not require compliance with a PLC cycle times lower than a few milliseconds. For these applications, the industrial Ethernet protocol can be cost-effectively implemented in software on a microcontroller with an integrated standard Ethernet MAC peripheral,” an Atmel engineering rep told Bits & Pieces.

“Due to their moderate flash size requirement, protocols like Modbus TCP can be implemented in a microcontroller. Atmel offers ARM-based and 32-bit AVR microcontrollers with up to 512KB of flash and an integrated Ethernet MAC unit.”

According to the rep, one of the most noteworthy features includes a 10/100 Ethernet Media Access Controller (EMAC) peripheral with chained buffer Direct Memory Access (DMA). This acts as a master on the internal multi layer bus with multiple internal SRAM blocks – enabling a true parallel data transfer between the Ethernet frames and the application data.

“Atmel’s  SAM9  MPUs are also price-competitive solutions for implementing industrial Ethernet protocols, such as the Ethernet/IP standard, which requires a higher flash size and faster execution time,” the engineering rep continued.

“Atmel’s  SAM9 MPU, like the SAM9G45, offers a variety of benefits, including a 400Mhz clocked ARM926EJ core with 32KB instruction and data caches speed execution time. There is also deterministic execution time with the use of the TCM (Tightly Coupled Memory) interface, enabling access to the internal SRAM with zero wait state at 400MHz. Indeed, by dynamically configuring the SRAM as TCM, Ethernet frames can be analyzed at full speed without any copy to the cache.”

For motion control applications, synchronism and short latency aspects are crucial. Protocols such as Profinet IRT or Ethercat address these requirements and are suited for systems with a sub-millisecond PLC times. In this case, specific ASSP or FPGA solutions must be used. The Atmel SAM9G45, with its dual EBI feature, lets designers integrate the industrial Ethernet communication module with minimal performance impact. Data transfers between the ASIC or FPGA can be handled by the DMA unit, in parallel with external RAM access.

Wireless Communication

Wireless communication in the industrial automation sector is increasingly popular, as it provides an easier way to install and connect mobile or inaccessible equipment. To be sure, industrial control equipment such as PLC and DCS IO modules primarily utilize IEEE802.11 WLAN and Bluetooth standards. And that is one of the reasons Atmel’s 32-bit microcontrollers and microprocessors feature an embedded multimedia card interface which supports connection to an SDIO WLAN or Bluetooth module. In fact, a full reference design based on the Atmel AVR 32-bit microcontroller and the industrial Wifi Module from H&D is available for evaluation and development here, while a Linux-based solution for Atmel SAM9 microcontrollers can be found here.

And last, but certainly not least, industrial sensors and actuators have demanding requirements for power consumption, board space and implementation cost. For these products, IEEE802.15.4 technology, such as Zigbee or Wireless-HART is most appropriate, with Atmel offering complete wireless solutions based on our low-power microcontrollers and RF transceivers. Benefits include excellent RF performance, which enables longer range and more robust RF link, optimized power consumption and lowest system cost.

Additional information about Atmel MCUs that can be used to power a wide range of industrial communication devices is available here.

Zigbee Smart Energy Profile

The much anticipated Zigbee Smart Energy Profile 2.0 was recently released. Representing an effort spanning more than three years, this milestone includes contributions from NIST, IETF and the Zigbee Alliance. Various companies also participated in the initiative, including utility, meter, silicon and software stack vendors.

Smart Energy – the application profile that drove the Zigbee Alliance development of the Zigbee IP (ZIP) –  is the first public profile requiring ZIP instead of the current Zigbee and Zigbee PRO underlying stacks. Zigbee IP (ZIP) and SEP 2.0 offer TCP/IP based interoperability for smart energy networks, thereby facilitating participation in the Internet of Things (IoT) without the need for special gateways. In fact, ZIP is designed to be physical layer (phy) agnostic and is capable of running across various platforms including 802.15.4 Wireless, WiFi, Power Line Carrier Ethernet and more.

SEP 2.0 is built using numerous mainstream protocols such as TLS/HTTPS, XML, EXI, mDNX  and REST. Each SEP 2.0 device boasts an optimized HTTP server serving up and responding to data objects defined by an XML schema. Security is ensured by familiar HTTPS with strong authentication, while an RFC compliant IPv6 stack provides the network with specific routing and translation layers for the wireless PHY.  The SEP 2.0 presentation from the Zigbee Alliance is available here [PDF].

Two recommended implementation strategies for SEP 2.0 in devices are Single Chip and Multi-Phy. Single Chip implementations use a dedicated microcontroller and RF transceiver (or a combined SoC) running a dedicated stack. This strategy works particularly well when adding Zigbee SEP 2.0 support where there is no other network or TCP/IP stack in low to mid range devices. A good example might be a thermostat or load control device, both of which require communications with other smart energy devices – even if they are equipped with a small processor dedicated to the control and UI functions of the device.

The Multi-Phy implementation –  a new way of looking at Zigbee – offers advantages in devices equipped with multiple network interfaces and/or a capable processor such as an Atmel SAM4, SAM9, or SAMA5 MPU or MCU. In such cases, the 802.15.4 transceiver (like the AT86RF233) becomes the network interface PHY layer underneath the IPv6 stack and SEP 2.0 layers running on the processor. Since the IPv6 stack is a compliant implementation, other network PHYs are also supported by the stack. Running two or more physical interfaces with a single processor is certainly not an issue, as devices that communicate via Zigbee, WiFi, PLC, and Ethernet can be designed. Because a single processor and IPv6 stack are used, the cost will ultimately be lower than duplicating these functions in a separate chip dedicated to Zigbee SEP 2.0.

Single Chip and Multi-Phy implementation

Single Chip and Multi-Phy implementation

The multi-phy implementation is also ideal for gateway devices bridging different physical layers. And since SEP 2.0 is built using standard web protocols, once you bridge the smart energy network to the Internet, managing your home energy devices from a tablet or smartphone is no stretch at all and brings us closer to the reality of the Internet of Things (IoT).

Atmel, along with software stack partner Exegin Technologies, offers robust and compliant solutions for Zigbee IP and SEP 2.0. There is already interest from leading networking and utility companies, with deployment of certified devices expected before the end of 2013. The critical design decision most of us have to consider? Whether to dedicate the cost and complexity of a single chip Zigbee solution – or optimize it and lower cost with a software stack and radio transceiver solution that offers shared resources and the possibility of multiple networks.