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 ofmagnitude may come as a surprise. The average modern car has up to 150 electronic control units (ECUs) running up to100million lines of code. In comparison, the F-35 fighter jet had fewer than 25million lines of code, the Android operating systemfewer than 15million lines of code, and Google Chrome fewer than 10million lines of code.1
The abundance of software emerging in automotive applications necessitates a method of curating and controlling the myriad ofsoftware 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. Teslademonstrated 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 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 OEMshave had gaps in the SOTA capabilities of their vehicles exposed, leading to reputational damage and loss in consumerconfidence.
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 alsoaccelerating.
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 labour-intensive process. The removal of an engine management ECU from anengine 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, bridging from early ECUs to today’shighly 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 deliverpotentially 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 toattend 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 recallsadministration. SOTA can be utilised during the production process to ensure that the vehicle firmware is correct before the car iscompleted 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 itsdestination market is significant. The ability to efficiently update the ECUs in a vehicle at its pre-delivery inspection (PDI), at thereceiving 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 audioconfiguration may be sufficient for listening to the radio or making hands-free calls during the commute. For longer trips orvacations, the OEM could offer options to upgrade to high definition audio or audio processing algorithms to optimise sounddistribution 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 howmuch 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 informationacross the network: handshaking, error detection, and error correction. Handshaking is the process through which SOTA nodesnegotiate and confirm the transfer of data across the link - for example, ensuring that each block of the transfer has beensuccessfully completed before transferring the next block. Error detection is the process through which the SOTA nodes monitorthe data being transferred across the link to identify when errors have occurred in the transmission. For example, cyclicredundancy 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 inerror 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 severalcommunication interfaces (A2B, CAN, LIN, CXPI, Ethernet, FlexRay, etc.) with varying loading, this is often not a problem. It isobviously preferable, however, to accommodate both the data transmission and transmission coordination on the same link ifpossible.
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 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 orEthernet. In recent years, A2B from Analog Devices has emerged as the de facto choice to address the demands posed byincreasingly 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 networkswith 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 analogue connectionsbetween head units, amplifiers, speakers, and microphones. A2B addresses many of the challenges that characterise point-to-pointanalogue connections: cable weight, cable cost, routing difficulties, and the reliability concerns of multiple connections. A2Bfacilitates the transport of fully synchronised 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 of50Mbps. A2B has a deterministic latency of less than 50μs, making it an extremely attractive solution for latency sensitiveapplications such as active noise cancellation (ANC), road noise cancellation (RNC), acoustic echo cancellation and noisereduction (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 ofautomotive applications ranging from entry-level infotainment systems featuring a head unit and microphone module to morecomplex 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 15m and a maximum cable length between the main node and the final sub-node of 80m (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. Sub-nodes - 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 sub-node transceiver devices support a variety of value-added features such as time division multiplexed (TDM) andpulse 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, fewersub-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 (up to 2.7W) or high powermode (up to 50W).
Designed from the outset as an automotive link, A2B has class-leading EMI/ EMC performance with several specific designconsiderations (for example, configurable output power levels) incorporated into the transceiver to ease the EMC challengestypically experienced by automotive Tier 1s and OEMs. A2B is comprehensively tested against the full suite of automotive EMCtests - 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 super-frame, a structure comprised of multiple downstream and upstream synchronous data slots, sync control, and syncresponse 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 super-frame, adding synchronous (audio) and asynchronous (I2C/SPI) data after thesync 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 super-frame with each node adding any additional synchronousdata 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 bymain 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 processorat 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 distance within the synchronous slots of the A2B super-frame. The A2B transceiver SPI interface can be leveraged for several different applications - to configure the A2B transceiver at SPI clock rates of up to 10MHz, 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 super-frames 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 (forexample, event/interrupt driven, register polling), ADI offers a comprehensive ISO/IEC 15504 (automotive SPICE) accreditedsoftware 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 A2Bmailbox transfer information between nodes on the network. The A2B data pipe software add-on leverages the A2B synchronousslots to transfer information between nodes on the network. The A2B data tunnel software add-on leverages the A2B SPI data overdistance to transfer information between nodes on the network.
Figure 3. The correlation of A2B hardware and software capabilities for data transfer.
The combination of the A2B mailbox feature with the communication channel software add-on delivers data throughput at rates up to 15kbps. While being useful for applications such as diagnostics, the throughput afforded by the mailbox feature is insufficient forbandwidth 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 1Mbps.This yields more attractive communication speeds for SOTA applications - for example, the transfer of a 20Mb file in 20seconds.The combination of SPI data over distance with the A2B data tunnel software add-on can deliver data throughput at rates of over16Mbps. This yields the fastest data communication speed possible on the A2B bus - for example, the transfer of a 100Mb file inless than 7seconds.
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 application software.
Test equipment is an important ecosystem element for any automotive technology, and A2B is no different. Analog Devices will joinother trusted test equipment vendors already offering A2B analysers and monitors with a full featured A2B bus analyser developedto 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. This can assist when designing and prototypingan A2B network. An A2B monitor functions as a passive monitoring node on an A2B network, observing A2B audio and data passingthrough 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 A2Bdesign-in.
A2B has several third-party design service partners with proven track records in bringing A2B designs to the market. These partnersoffer 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 genericsof 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 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 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 efficientlysupport 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 tovarious software development programs before moving to Ireland with a new role working on wireless battery managementsystems (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 asADI’s Automotive Audio Bus (A2B®) and controller area network (CAN) stack. He holds a master’s degree in software systems fromBITS, 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 DSPFAE 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, primarilyin 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 thepowertrain 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 andcryptography, audio algorithms, autonomous driving, sensor fusion, and Sanskrit literature. He can be reached atjagannath.rotti@analog.com.
Joe Triggs is the design director for the Automotive Connectivity and Sensing (ACS) Group in Analog Devices’ Automotive CabinEntertainment (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.
Promoted content: Does social media work for engineers – and how can you make it work for you?
So in addition to doing their own job, engineers are expected to do the marketing department´s work for them as well? Sorry, wait a minute, I know the...