If a consumer were to rank the software complexity of their belongings, what would top the list? Their laptop? Their smartphone? Their gaming console? The fact that the vehicle sitting in their driveway most likely outstrips any of these devices by an order of magnitude may come as a surprise. The average modern car has up to 150 electronic control units (ECUs) running up to 100 million lines of code. In comparison, the F-35 fighter jet had fewer than 25 million lines of code, the Android operating system has fewer than 15 million and Google Chrome fewer than 10 million.
The abundance of software emerging in automotive applications necessitates a method of curating and controlling the myriad software versions and revisions present throughout the vehicle. The benefits that accrue for an automotive manufacturer, or OEM, that leverages software over the air (SOTA) updates can range from remedying minor vehicle issues to responding to natural disasters.
Tesla demonstrated one of the most widely recognised applications of SOTA updates in response to Hurricane Irma in September 2017. With the storm bearing down on the US state of Florida, Tesla responded to customer requests by issuing a SOTA update to unlock extra range from their vehicles to assist owners attempting to travel to safety from the impending hurricane. Other OEMs have had gaps in the SOTA capabilities of their vehicles exposed, leading to reputational damage and loss in consumer confidence.
With emerging megatrends such as vehicle electrification and automotive autonomy increasing the number of ECUs and lines of code in the vehicle further, the importance of ensuring robust and effective SOTA capabilities in every domain of the vehicle is also accelerating.
ECUs have been part of the automotive landscape since a microcontroller was first used to control the spark timing in the 1977 Oldsmobile Toronado. Early implementations of software updates required the removal of the ECU from the vehicle for reprogramming, a potentially time-consuming and labour-intensive process. The removal of an engine management ECU from an engine bay may be straightforward. The removal of a radio head unit, in comparison, could require significant stripping of the dashboard, centre console and other trim. Once removed from the vehicle, early ECUs required reprogramming using complicated tools such as bed-of-nails programmers, which are expensive, complex and occasionally temperamental. These factors combined to make issuing software updates to early ECUs less attractive than simply replacing the unit with another module.
Software over the air
SOTA is an apex point in the development of software updates in the automotive industry, spanning from early ECUs to today’s highly networked, flexible automotive infrastructure. The ability to update ECUs in situ in the vehicle is not only attractive but is also becoming an increasingly important capability for automotive OEMs.
We’ve already examined how OEMs can use SOTA to deliver potentially lifesaving features in a responsive and agile manner. One of the most obvious use cases for SOTA is to allow OEMs to address critical software issues in their vehicles, as and when required. This is an exceptionally powerful capability as it can eliminate the need for software-related vehicle recalls, resulting in an improved ownership experience for the consumer and reduced recall costs for the OEM. The ability to apply software updates in a controlled fashion, without requiring the vehicle to attend a dealership, delivers significant value for the OEM.
SOTA has the potential to simplify many other elements of a vehicle’s lifecycle, not just the streamlining of software recall administration. SOTA can be utilised during the production process to ensure that a vehicle’s firmware is correct before the car is completed and sent for shipping. With shipping times for vehicles varying between days (for example, in the OEM domestic market) and weeks (for example, foreign markets), the potential for software updates to be required at the time the vehicle arrives at its destination market is significant.
The ability to efficiently update the ECUs in a vehicle at its pre-delivery inspection (PDI), at the receiving port or supplying dealer, ensures that the vehicle arrives at its new owner operating exactly as desired. This is especially valuable for models early in their lifecycle, which may be undergoing frequent software updates.
Further opportunities for SOTA may exist as OEMs seek to create the ability for consumers to unlock, on a temporary or permanent basis, additional features in their vehicles. Consider the infotainment system as an example; in the future, OEMs could offer customers the ability to upgrade the software running in their vehicle depending on their needs.
For daily driving, a standard audio configuration may be sufficient for listening to the radio or making hands-free calls during the commute. For longer trips or vacations, the OEM could offer options to upgrade to high-definition audio or audio processing algorithms to optimise sound distribution within the vehicle. SOTA could be used to facilitate such upgrades within minutes of a transaction taking place, opening up the potential for lucrative additional revenue streams for OEMs.
SOTA considerations
Before an OEM can consider implementing SOTA in a vehicle, several system characteristics must be examined, such as how much bandwidth is required, how transmission will be coordinated between nodes and whether security is necessary.
The bandwidth offered by the SOTA solution must be considered in the context of the typical software update file size and the time that will be available to transfer the software update across the network. Although many software downloads are supplied in a delta format (which contains only the software components that need to be changed), the file size can still be in the realm of tens of megabytes. If the bandwidth available is in the range of kilobytes, the download of a software update could take tens of minutes rather than the minutes or seconds that may be more practical in a service setting.
Transmission coordination considerations include aspects of the protocol necessary to ensure the reliable transfer of information across the network: handshaking, error detection and error correction.
Handshaking is the process through which SOTA nodes negotiate and confirm the transfer of data across the link – for example, ensuring that each block of the transfer has been successfully completed before transferring the next block.
Error detection is the process through which the SOTA nodes monitor the data being transferred across the link to identify when errors have occurred in the transmission. For example, cyclic redundancy check (CRC) values calculated in both the source and destination node are commonly used for such requirements.
Error correction is the process through which the SOTA nodes respond to and if possible recover from, error conditions. Several techniques exist to implement error correction – from re-requesting data from the source node, to re-transmitting the block of data received in error, to using schemes such as forward error correction (FEC) to repair the corrupted data.
Depending on the bandwidth offered by the SOTA solution and the transmission coordination requirements, it may be necessary to implement the data transfer and transmission coordination on different networks. With automotive ECUs typically featuring several communication interfaces (A2B, CAN, LIN, CXPI, Ethernet, FlexRay, etc.) with varying loading, this is often not a problem. It is obviously preferable, however, to accommodate both the data transmission and transmission coordination on the same link if possible.
The consequences of a security weakness in an automotive network have been highlighted on a number of occasions in which ethical hackers have taken control of vehicle networks and demonstrated the risks involved by exercising functions such as wipers, stereos and even braking. Such weaknesses could be calamitous to the safety of the vehicle’s occupants and fellow road users. OEMs must take steps to ensure that appropriate authentication on all in-vehicle networks prevents unauthorised nodes or users from achieving access.
A number of established automotive networks already mentioned are suitable for use in SOTA architectures, for example, CAN or Ethernet. In recent years, A2B from Analog Devices has emerged as the de facto choice to address the demands imposed by increasingly complex audio requirements. Boasting significant audio bandwidth advantages over alternative connectivity solutions, A2B also offers the ability to transfer data, giving OEMs the opportunity to incorporate SOTA capabilities into their audio networks with no additional hardware requirements.
A2B overview
A2B is a high-bandwidth, bidirectional digital bus originally conceived to solve the audio distribution challenges emerging in automotive applications. Existing automotive audio architectures typically involve multiple point-to-point analog connections between head units, amplifiers, speakers and microphones. A2B addresses many of the challenges that characterise point-to-point analog connections: cable weight, cable cost, routing difficulties and the reliability concerns of multiple connections. A2B facilitates the transport of fully synchronised audio data (I2S/TDM/PDM) and control data (I2C/SPI) throughout a distributed, multi-node audio system using an unshielded twisted pair (UTP) cable and connector infrastructure.
Up to 32 channels of audio are supported on the A2B bus in both upstream and downstream directions, giving a total bandwidth of 50 Mbps. A2B has a deterministic latency of less than 50 μs, making it an extremely attractive solution for latency-sensitive applications such as active noise cancellation (ANC), road noise cancellation (RNC), acoustic echo cancellation and noise reduction (AEC-NR) and beamforming (BF).
A2B supports several different topologies such as point-to-point, daisy chain and branch, making it suitable for a wide variety of automotive applications ranging from entry-level infotainment systems featuring a head unit and microphone module, to more complex audio systems such as RNC featuring an ECU combined with multiple microphones, speakers and accelerometers.
An A2B network is comprised of a main node and up to 16 sub-nodes with a maximum cable length between nodes of 15 m and a maximum cable length between the main node and the final sub-node of 80 m (including branches). A main node contains an A2B transceiver connected to a host processor that can send audio, control data and I2C/SPI data on the A2B audio bus.
Sub-nodes – which vary in complexity from complex power amplifiers with significant processing, to simple microphone nodes – contain A2B transceivers that interface with a broad range of peripheral devices such as microphones, digital signal processors (DSPs), speakers, sensors (for example, an accelerometer) or Class-D amplifiers.
Main and sub-node transceiver devices support a variety of value-added features, such as time division multiplexed (TDM) and pulse density modulation (PDM) microphone inputs. Cost-reduced derivatives of A2B transceivers exist with optimised feature sets, such as an endpoint sub-node transceiver (no TDM support) and an optimised main node transceiver (reduced cable length, fewer sub-nodes).
In addition to supporting A2B nodes, which are locally powered, A2B provides bus power to facilitate challenging audio system architectures such as powered remote tuners and innovative audio features such as Class-D enabled headrest speakers. The latest generation of A2B transceivers (AD243x) is capable of supporting standard bus power mode
Designed from the outset as an automotive link, A2B has class-leading EMI/EMC performance with several specific design considerations incorporated into the transceiver (for example, configurable output power levels) to ease the EMC challenges typically experienced by automotive Tier 1 companies and OEMs. A2B is comprehensively tested against the full suite of automotive EMC tests – CISPR&nsp;25 Class 5 (emissions), ISO 11452-2/ISO 11452-4/ISO 11452-9, ISO 7637-3 (immunity) and ISO 10605 (ESD).
Data transmission over A2B
Over and above supporting the transmission of audio, A2B also facilitates several mechanisms for transmitting other forms of data across the bus. One of the fundamental constructs of A2B that enables the transmission of both audio and data across the bus is the superframe, a structure comprised of multiple downstream and upstream synchronous data slots, sync control and sync response frames. While synchronous data slots carry I2S and TDM data in audio applications, they can also be used to carry other types of data to meet the requirements of SOTA applications.
The main node initiates the transmission of a superframe, adding synchronous (audio) and asynchronous (I2C/SPI) data after the sync control frame. Each sub-node can use or consume some of the downstream data and add data for other downstream nodes. The last sub-node on the bus builds the upstream portion of the superframe, with each node adding any additional synchronous data after the sync response frame. Each node can use or consume the upstream data.
Figure 2. Superframe structure.
Another data transport mechanism supported by several generations of A2B transceivers is the mailbox. Mailboxes can be used by main and sub-nodes to send I2C messages across the network – from main node to sub-node or from sub-node to main node. Mailboxes are usually used to establish handshaking between the host in the main node (for example, a head unit) and processor at the sub-node (for example, an amplifier).
The host processor can initiate communication with the processor in a sub-node by loading the desired data, across the A2B bus, into the mailbox registers of the sub-node A2B transceiver. The A2B transceiver in the sub-node alerts the processor in the sub-node to the presence of an I2C message via the interrupt pin. The processor in the sub-node can read the message directly via I2C from the A2B transceiver.
The processor in the sub-node can initiate communication to the host in the main node by loading the desired data for transmission into the mailbox I2C registers in the sub-node transceiver. The A2B transceiver in the main node alerts the host to the presence of an I2C message in the sub-node transceiver via the interrupt pin. The host may then choose to read the data in the sub-node transceiver mailbox registers across the A2B bus.
A third transport mechanism, introduced in the latest generation of the A2B transceiver family (AD243x), is the transfer of SPI data over considerable distances within the synchronous slots of the A2B superframe. The A2B transceiver’s SPI interface can be leveraged for several different applications: to configure the A2B transceiver at SPI clock rates of up to 10 MHz, to achieve direct access to registers and status information in a sub-node transceiver, to communicate with an SPI-enabled peripheral device in a sub-node, or even to facilitate SPI-to-SPI communication between sub-nodes without the involvement of the main node. Previous generations of A2B transceivers, which do not feature an SPI interface, are capable of transparently passing superframes featuring SPI data upstream and downstream to other nodes in the network.
A2B reference software
A2B has minimal processing requirements throughout the network, with scope for the host controller to perform a complete initialisation of the entire network remotely. To support network configuration and interaction with the network once configured (for example, event/interrupt-driven register polling), Analog Devices offers a comprehensive ISO/IEC 15504 (automotive SPICE)-accredited software package. The software is available in several variants, including those compatible with Embedded C, Linux, Android and QNX, to help reduce the customer’s time to market and ensure consistency with best-practice transceiver configuration.
In addition to the software offered to support the fundamental operation of A2B, optional software packages are available to assist customers to exercise features such as data transmission across A2B. Software packages are available to leverage the A2B features already discussed and as outlined in Figure 3.
Figure 3. The correlation of A2B hardware and software capabilities for data transfer.
The A2B communication channel software add-on leverages the A2B mailbox transfer information between nodes on the network. The A2B data pipe software add-on leverages the A2B synchronous slots to transfer information between nodes on the network. The A2B data tunnel software add-on leverages the A2B SPI data over distance to transfer information between nodes on the network.
The combination of the A2B mailbox feature with the communication channel software add-on delivers data throughput at rates up to 15 Kbps. While being useful for applications such as diagnostics, the throughput afforded by the mailbox feature is insufficient for bandwidth-intensive applications such as SOTA.
The combination of A2B synchronous slots with the data pipe software add-on can deliver data throughput at rates of over 1 Mbps. This yields more attractive communication speeds for SOTA applications – for example, the transfer of a 20 Mb file in 20 seconds. The combination of SPI data over distance with the A2B data tunnel software add-on can deliver data throughput at rates of over 16 Mbps. This yields the fastest data communication speed possible on the A2B bus, equivalent to the transfer of a 100 Mb file in less than 7 seconds.
A2B tools
A2B is also supported through SigmaStudio, Analog Devices’ industry-recognised algorithm and network design tool. SigmaStudio supports all aspects of the A2B design-in process – network design via drag-and-drop of A2B nodes and auxiliary devices, node configuration, bit error rate analysis, bandwidth calculation and power calculation. SigmaStudio combines the supplied data and generates .c and .h files for integration into the customer’s application software.
Test equipment is an important ecosystem element for any automotive technology and A2B is no different. Analog Devices will join other trusted test equipment vendors already offering A2B analysers and monitors with a full-featured A2B bus analyser developed to support all features of the new AD243x product family. An A2B analyser can emulate either a main node or sub-node in an A2B network, which can assist when designing and prototyping such a network. An A2B monitor functions as a passive monitoring node on a network, observing A2B audio and data passing through the node while supporting the input and output of audio. These tools assist in reducing time to market and design-in complexity for customers. They also accelerate the debugging and investigation of any issues observed during all stages of A2B design-in.
A2B has several third-party design service partners with proven track records in bringing such designs to market. These partners offer a range of services, from off-the-shelf hardware modules to bespoke hardware design and software design support.
Table 1. AD243x family of A2B devices.
Four generics of the AD243x family are recommended for automotive applications, with an overview provided in Table 1. The A2B audio bus is supported through a range of product evaluation boards from Analog Devices that cover the various generics of A2B transceivers. These are complemented by several other boards offered by a range of third-party design services.
Table 2. A2B evaluation boards.
Summary
A2B is broadly recognised as the de facto choice for audio networking in the automotive market. Whether the system involves audio distribution or acoustic features such as road noise cancellation or noise reduction, the many benefits offered by A2B, such as low latency and outstanding EMC performance, are well known and understood. The A2B portfolio’s ability to transport non-audio data on the same network opens several new options for system designers, including the ability to easily and efficiently support SOTA on the audio network.
To learn more about A2B technology, discover A2B collateral and find out more about A2B applications, refer to www.analog.com/a2b. To learn more about the A2B software offered by Analog Devices, navigate to the rather lengthy web address using the short URL www.dataweek.co.za/*apr22-a2b.
| Tel: | +27 11 923 9600 |
| Fax: | +27 11 923 9884 |
| Email: | [email protected] |
| www: | www.altronarrow.com |
| Articles: | More information and articles about Altron Arrow |
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version