Abstract
Software over the air (SOTA) is rapidly emerging as a vital capability for automotive OEMs to develop and deploy. The ability to update modules, support customers, and monetize additional features makes mastering SOTA an attractive proposition. This article discusses why SOTA has emerged in the automotive environment, how it can be deployed, and how A2B technology can be used to implement SOTA in audio and infotainment networks.
Introduction
If a consumer was 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 fewer than 15 million lines of code, and Google Chrome fewer than 10 million lines of code.1
The abundance of software emerging in automotive applications necessitates a method of curating and controlling the myriad of software versions and revisions present throughout the vehicle. The benefits that accrue for an automotive manufacturer, or OEM, that leverages SOTA updates can range from remedying minor vehicle issues to responding to natural disasters. Tesla demonstrated one of the most widely recognized applications of SOTA updates in response to Hurricane Irma in September 2017. With the storm bearing down on the state of Florida (U.S.), 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.2 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.3 Early implementations of software updates required the removal of the ECU from the vehicle for reprogramming, a potentially time-consuming and labor-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, center 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, bridging 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 life cycle— not just the streamlining of software recalls administration. SOTA can be utilized during the production process to ensure that the vehicle firmware is correct before the car is completed and sent for shipping. With shipping times for vehicles varying between days (for example, the OEM domestic market) to weeks (for example, foreign markets), the potential for software updates to be required at the time the vehicle arrives in 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 to its new owner operating exactly as desired. This is especially valuable for models early in their life cycle, 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 optimize sound distribution within the vehicle. SOTA could be used to facilitate such upgrades within minutes of a transaction taking place, enabling 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 recover from, if possible, error conditions. Several techniques exist to implement error correction—from re-requesting 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 appropriate authentication on all in-vehicle networks prevents unauthorized 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 posed by increasingly complex audio requirements. Boasting significant audio bandwidth advantages over alternate connectivity solutions, A2B also offers the ability to transfer data, allowing 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 characterize point-to-point analog connections: cable weight, cable cost, routing difficulties, and the reliability concerns of multiple connections. A2B facilitates the transport of fully synchronized audio data (I2S/TDM/PDM) and control data (I2C/SPI) throughout a distributed, multinode 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 subnodes with a maximum cable length between nodes of 15 m and a maximum cable length between the main node and the final subnode 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 onto the A2B audio bus. Subnodes—which vary in complexity from complex power amplifiers with significant processing to simple microphone nodes—contain A2B transceivers that interface to 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 subnode 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 optimized feature sets, such as an endpoint subnode transceiver (no TDM support) and an optimized main node transceiver (reduced cable length, fewer subnodes).
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 (up to 2.7 W) or high power mode (up to 50 W).
Designed from the outset as an automotive link, A2B has class-leading EMI/ EMC performance with several specific design considerations (for example, configurable output power levels) incorporated into the transceiver to ease the EMC challenges typically experienced by automotive Tier 1s and OEMs. A2B is comprehensively tested against the full suite of automotive EMC tests—for example, CISPR 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 subnode can use or consume some of the downstream data and add data for other downstream nodes. The last subnode 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.
Another data transport mechanism supported by several generations of A2B transceivers is the mailbox. Mailboxes can be used by main and subnodes to send I2C messages across the network—from main node to subnode or from subnode 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 subnode (for example, an amplifier).
The host processor can initiate communication with the processor in a subnode by loading the desired data, across the A2B bus, into the mailbox registers of the subnode A2B transceiver. The A2B transceiver in the subnode alerts the processor in the subnode to the presence of an I2C message via the interrupt pin. The processor in the subnode can read the message directly via I2C from the A2B transceiver. The processor in the subnode can initiate communication to the host in the main node by loading the desired data for transmission into the mailbox I2C registers in the subnode transceiver. The A2B transceiver in the main node alerts the host to the presence of an I2C message in the subnode transceiver via the interrupt pin. The host may then choose to read the data in the subnode 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 distance within the synchronous slots of the A2B superframe. The A2B transceiver 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 subnode transceiver, to communicate with an SPI-enabled peripheral device in a subnode, or even to facilitate SPI-to-SPI communication between subnodes 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 initialization of the entire network remotely. To support network configuration and interaction with the network once configured (for example, event/interrupt driven, register polling), ADI 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. 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—for example, the transfer of a 100 Mb file in less than 7 seconds.
A2B Tools
A2B is also supported through SigmaStudio, Analog Devices’ industry recognized 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 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 analyzers and monitors with a full featured A2B bus analyzer developed to support all features of the new AD243x product family.
An A2B analyzer can emulate either a main node or subnode in an A2B network. This can assist when designing and prototyping an A2B network. An A2B monitor functions as a passive monitoring node on an A2B 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 debug 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 A2B designs to the market. These partners offer a range of services from off-the-shelf hardware modules to bespoke hardware design and software design support.
Four generics of the AD243x family are recommended for automotive applications with an overview provided in Table 1.
Table 1. AD243x Family of A2B Devices
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 boards are complemented by several other A2B boards offered by a range of third-party design services.
Table 2. A2B Evaluation Boards
Summary
A2B is broadly recognized 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 also has the ability to also 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, please refer to analog.com/a2b. To learn more about the A2B software offered by Analog Devices, please refer to analog.com/en/design-center/evaluation-hardware-and-software/software/a2b-software.html.
References
1 Codebases: Millions of Lines of Code. Information is Beautiful.
2 Simon Usborne. “How Did Tesla Make Some of Its Cars Travel Further During Hurricane Irma?” The Guardian, September 2017.
3 Robert Charette. “This Car Runs on Code.” IEEE Spectrum, February 2009.
About the Authors
Karthik Radhakrishna is a software applications engineer with Analog Devices. He joined ADI in 2011 where he contributed to various software development programs before moving to Ireland with a new role working on wireless battery management systems (wBMS). He has experience in automotive infotainment and processing programs such as audio frameworks for ADI SHARC processors. His recent contributions include leading software development for automotive connectivity programs such as ADI’s Automotive Audio Bus (A2B) and controller area network (CAN) stack. He holds a master’s degree in software systems from BITS, Pilani, India. He is passionate about working with customers to create innovation around the latest automotive trends, which includes automotive networks and BMS. He can be reached at karthik.radhakrishna@analog.com.
Danny Ko is a systems architect for audio and emerging technologies based in Seoul, Korea. Danny joined ADI in 2004 as a DSP FAE supported Samsung, LG, and broad market for three years before changing his focus to automotive in 2007. In 2010, Danny transferred to the automotive segment as an automotive system application engineer and worked in the infotainment area, primarily in audio applications. Since 2018, his work has extended to emerging technology. He can be reached at danny.ko@analog.com.
Jagannath Rotti graduated from PES Institute of Technology, Bangalore with a degree in electronics and communication. He has 15+ years of automotive software experience. Prior to joining Analog Devices, he worked at Robert Bosch and Autoliv in the powertrain and safety domains, respectively. At ADI, he is an engineering manager in the Automotive SW Team, leading software efforts for the Automotive Audio Bus (A2B) portfolio. His areas of interest include automotive networks, network security and cryptography, audio algorithms, autonomous driving, sensor fusion, and Sanskrit literature. He can be reached at jagannath.rotti@analog.com. Joe Triggs is the design director for the Automotive Connectivity and Sensing (ACS) Group in Analog Devices’ Automotive Cabin Entertainment (ACE) Business Unit. The ACS Group supports A2B, C2B, and GMSL. He earned his primary degree (B.Eng.) from the University College of Cork in 2002 before completing his M.Eng. at the University of Limerick in 2004. He completed his M.B.A. at the University of Limerick’s Kemmy Business School in 2012. He can be reached at joe.triggs@analog.com.
 is rapidly emerging as a vital capability for automotive OEMs to develop and deploy.){kind=link}