2021-06

Practice of AUTOSAR China User

Group: Development of OTA
Demonstration System for Vehicle
Computer Network
JING Zhe，Bosch
CHEN Zhu, GENG Shang, HingeTech
CAI Jianbing，ABUP
ZHANG Shiyu，Freetech
ZHOU Kailun，Neusoft Reach
FAN Zhirong，Dongfeng Motor

AUTOSAR Partnership

Abstract: The OTA demonstration system for vehicle computer network, which is jointly developed by
AUTOSAR China User Group, uses the AUTOSAR development method and software architecture, and
applies the basic software of the Adaptive Platform (AP) and the Classic Platform (CP). The components
from all participants are integrated into a network architecture of new generation vehicles through joint
development work, which realizes the OTA remote software upgrade demonstration function. Software
development based on the AUTOSAR standard is deeply understood. This article introduces the design
and implementation of the demonstration system, and shares the experience and shows the challenges
encountered by all participants in the applying AUTOSAR technologies.

1 Overview
According to Bosch's E/E architecture evolution roadmap, there are 3 major stages and 6 steps. 3 major
stages are: distributed architecture, cross-domain centralized architecture, and vehicle centralized
architecture; 6 steps are: modularization, integration, zone integration, cross-zone integration, vehicle
central computer, and vehicle cloud computing. Each step gradually completes the function integration,
1/30
multiple independent networks integration, the central gateway coordinates communication, cross-
zone function integration, and then reduces costs through the central domain controller, and finally
establishes a virtual domain through the network and completes complex functions integration through
the central vehicle computer or even cloud computing.

Figure 1-1 Trends in automotive E/E architecture (Bosch)

On one hand, some controllers with high real-time and functional safety demands will still exist for a
long time, such as chassis electronic stability control system (ESC), the electronic power steering system
(EPS), the airbag control unit (ACU), etc. On the other hand, most OEMs’E/E architectures have now
entered the era of domain controllers. Therefore, AUTOSAR organization has developed the “adaptive
platform" specification in addition to the "classic platform" to specify the advanced functions for e.g.
autonomous driving, C2X, and OTA for the new E/E architecture.

2/30
 Figure 1-2 Overview of AUTOSAR's global partners (Associate Partner and Attendee are not listed)

AUTOSAR (AUTomotive Open System Architecture) is a worldwide development partnership of car

manufacturers, suppliers and other companies from the electronics, semiconductor, and software
industry. AUTOSAR has been committed to establishing the standardized software framework and open
E/E system architecture for intelligent mobility since it established in 2003. By simplifying the
replacement and updating of software and hardware, the AUTOSAR method lays the foundation for the
reliable control of the increasingly complex electronic and software systems of today and future vehicles.
In addition, AUTOSAR improves cost efficiency by allowing partners to cooperate in a competitive
manner. AUTOSAR's “Core Partners” include BMW Group, Bosch, Continental, Daimler, Ford, General
Motors, PSA Group, Toyota and Volkswagen Group. In addition to these companies, there are more
than 200 partners who play an important role in the success of the partnership and can use these
standards for free. For more information about the AUTOSAR organization and standards, please visit
the AUTOSAR official website www.autosar.org and follow the WeChat public account "AUTOSAR
Organization".

For the equality in the cooperation in the AUTOSAR organization, the members of AUTOSAR are called
"Partners". The AUTOSAR User Group is a link in the organizational structure which allows all types of
partners to participate in. The main work is to jointly research, learn, and discuss how to better apply
the published AUTOSAR standard. The work user group is organized in the form of projects, which
means that there are project teams, goals, work packages, plan for start and end. The user group is

3/30
voluntarily initiated by partners, and its work content, assignment of responsibilities, duration, speakers
(group leader), etc. are all discussed by the partners participating in the user group.

Figure 1-3 AUTOSAR organization structure

A number of AUTOSAR partners in China successfully initiated a user group work from 2014 to 2016. It
completed the integration of AUTOSAR basic software of the multi-controller for the power system of
electric vehicle, and answered the question "How to start using AUTOSAR". With the release of the new
standard platform "Adaptive Platform", partners have demands for joint research on new standard
applications. At the beginning of 2019, they began to discuss the establishment of a new user group. A
consensus was reached in April 2019 to complete the development of the "OTA Demonstration System
for Vehicle Computer Networks" together, to better understand of Adaptive Platform and to apply it
with OTA technology. After more than one year of development, the demonstration system was
completed in July 2020. Participating partners in this user group are: ABUP, Bosch, Dongfeng Motor,
Freetech, HingeTech, NXP and Neusoft Reach. The spokesperson is from HingeTech. Meanwhile,
another user group was established at the same time to collect and discuss the AUTOSAR requirements
of China's intelligent connected vehicles. The user group of developing this demo system is referred to
as "Demonstration System User Group".

Although this demonstration project does not specify the performance target, the network architecture
and technical elements are almost the star-of-art automotive technologies. In this article, the
participating partners describe the completed work and share their experience, hoping to bring some
experience and inspiration in software development based on the AUTOSAR standard to the readers.

4/30
2 Demonstration system design and realization

2.1 System design

The OTA function based on multi-domain control is the base to realize the fast iteration of intelligent
connected vehicles, and it is also an inevitable trend of future vehicle development. By implementing
the OTA upgrade of the various systems in the vehicle network, the maintenance cost of the system can
be reduced, and the OTA can also provide customers with personalized services and meet the needs of
different customers, improve the user's viscosity and satisfaction with the vehicle. Many OEMs have
implemented the OTA upgrade of ECUs on CAN bus. However, the CAN bus can no longer meet the
upgrade requirements of ECUs of intelligent connected vehicles, and the on-board Ethernet bus is
imperative. The OTA demonstration system of the vehicle computer network realizes the SOTA and
FOTA using the AUTOSAR adaptive platform and the classic platform, and initially verifies the OTA
upgrade process and OTA strategy according to the AUTOSAR standard.

Figure 2-1 Demonstration system real shots

2.1.1 System Function Design

The function of the OTA demonstration system is shown in Figure 2-2 . The system includes a gateway,
smart antenna, vehicle firewall, ADAS camera, ADAS domain controller, cockpit domain controller, and
OTA platform.

The OTA platform has the capabilities of vehicle management, model management, software version
management, and task release and push. The platform also has management attributes, including
account system, authority system, etc., and supports different departments, and functional engineers of

5/30
OEMs to implement OTA-related operations on the platform and view the execution of OTA tasks. The
format of the pushed software package adopts the format defined by UCM.

The smart antenna realizes the functions of body control, remote control, remote diagnosis, and OTA
through vehicle Ethernet, BT, BLE, Wi-Fi, 3G/4G. In the AUTOSAR OTA Demo system, the smart antenna
is responsible for authentication and communication with the OTA cloud, downloading, verifying, and
backing up all ECU upgrades, checking upgrade conditions, execution of upgrade strategies.

Figure 2-2 Demonstration system function diagram

Vehicle firewall implements network security isolation and prohibit unauthorized access ， vehicle
firewall policy management and dynamic updates and provide security protection mechanisms for inter-
domain data interaction, boundary intrusion prevention detection and other functions.

The HMI interface in the cockpit domain controller is used for the human-computer interaction of the
entire system upgrade process, which is upgrade control and upgrade status information display. The
upgrade application in the cockpit domain controller uses the CM (communication management), DM
(diagnostic management), and UCM (update configuration management) modules in the AUTOSA
adaptive platform architecture to complete the management and control of the upgrade of each
module in the system.
6/30
The ADAS camera sensor receives the UDS message forwarded by the gateway, parses the encrypted
upgrade package, performs CRC check, and supports the resume breakpoint upgrade.

The ADAS domain controller is continuously upgraded through OTA to optimize the performance of
detection of pedestrians/vehicles, the perception and recognition of new commercial vehicle models
and new traffic signs, optimization of functional control logic, and the addition of new autonomous
driving features.

The gateway is responsible for connecting the cockpit domain controller, ADAS domain controller, and
vehicle firewall into a local area network that combines Ethernet, ensuring safe and reliable data
communication between modules, and performing protocol conversion between Ethernet data and
CAN messages. Connecting the vehicle firewall and ADAS camera.

The upgrade logic process of the entire system is shown in Figure 2-3 below.

Figure 2-3 OTA upgrade process diagram

2.1.2 Network topology design

The network topology of the system is shown in Figure 2-4. 4G LTE communication is adopted between
the OTA platform and the smart antenna. The smart antenna and the gateway are connected via
Ethernet, and the communication protocol adopts SOME/IP and DoIP protocols. Ethernet uses the
100Base-T1 automotive Ethernet standard. The gateway uses 1 CAN interface and 3 Ethernet interfaces.
The communication rate of CAN bus is 500Kbit/s, and the communication rate of Ethernet bus is
7/30
100Mbit/s. The CAN bus connects the gateway and the ADAS camera. The gateway refreshes the ADAS
camera by converting the DoIP diagnostic message of the smart antenna to the UDS on CAN diagnostic
message.

Figure 2-4 OTA demonstration system network topology diagram

2.2 OTA Platform

In the demonstration project, a firmware, APP, partition, configuration and other upgrade solutions are
built, and the software package is configured on the platform and pushed to the car. After receiving the
software package, the car will automatically execute the upgrade strategy of the platform configuration,
so as to install and manage the software on different ECUs. The UCM of AUTOSAR AP regulates the
format, management and release process of the software package. Relying on the characteristics of its
own platform and the advantages of AP, ABUP has integrated the solution, re-developed the format of
the software package on the platform and the software installation management process on the car,
and built a set of software upgrade processes that can adapt to AUTOSAR. After integration, ABUP’s
solution can be adapted to both AUTOSAR and non-AUTOSAR platforms.

8/30
 Figure 2-5 Block diagram of OTA platform architecture

The OTA platform architecture is shown in Figure 2-5, including vehicle management, model
management, software version management, and task release and push capabilities. The platform also
has management attributes, including account system, authority system, etc., and supports different
departments, and OEMs to implement OTA-related operations on the platform and view the execution
of OTA tasks.

The channel between the car and the cloud uses mature communication technologies in the Internet
field such as 4G, HTTPS, MQTT, CDN, etc., to ensure that communications comply with information
security standards and that vehicles can receive OTA services.

OTA upgrade can be divided into three stages, namely generating update package, transmitting update
package, and installing update. Through the network communication channel, the whole stage realizes
the update of terminal code and data, and then improves the function and service of the terminal. The
update package follows the specifications in the UCM of the AUTOSAR adaptive platform.

UCM software package structure is shown in Figure 2-6. The software package contains (Container) one
or more executable files. In addition to application and configuration data, each software package
contains a package Manifest, which provides additional information, such as package name, version,
dependencies, and specific supplier information, so that users can formulate special processing based
on this information.

9/30
 Figure 2-6 Package format description （AUTOSAR）

2.3 Smart antenna

The smart antenna provided by HingeTech is a smart Ethernet shark fin antenna module developed
based on Broad-Reach technology, which integrates Tuner, GPS, 3G/4G/5G, BT, Wi-Fi, BLE, RKE, TPMS
radio frequency modules. The smart antenna converts the radio frequency data into a digital signal, and
communicates with each ECU in the car through the on-board Ethernet after decoding, and provides
radio services, positioning/inertial navigation services, remote control services, 4G/5G, V2X, etc. for each
node device and different kinds of access service.

In the OTA Demo system, the smart antenna implements OTA Client, UCM, CM, DM and other software
function modules based on the AUTOSAR adaptive platform, and then realizes the upgrade
management of each module in the system. The software architecture of the smart antenna controller
is shown in Figure 2-7.

10/30
 Figure 2-7 Smart antenna software architecture diagram

OTA Client is the master of the upgrade. On one hand, it connects with the OTA cloud server to obtain
upgrade information and upgrade packages, and on the other hand, it cooperates with UCM, CM, and
DM to control the upgrade process.

Figure 2-8 SOME/IP communication

The CM module is mainly used to transmit upgrade commands and upgrade status information between
the smart antenna and the cockpit domain controller. CM is a core functional module of the SOA-based

11/30
AUTOSAR adaptive platform. It is responsible for communication between applications in a distributed
real-time embedded environment and service-oriented communication between all levels of AUTOSAR
adaptive platform applications, including intra-process, inter-process communication and between
ECUs. The main functions of CM are to provide APIs related to Service, Method, Event, and Field.
SOME/IP communication is used between ECUs, as shown in Figure 2-8.

UCM is the abbreviation of Update and Configuration Management. It is a service of AUTOSAR AP. It
mainly provides software upgrade and configuration management functions. It provides access
interface for software upgrade service through ara::com.

Figure 2-9 UCM component diagram

UCM internally consists of one or more classes, as shown in Figure 2-9, which cooperate to complete a
certain class of operations.

PackageManager is the core component of UCM service, responsible for implementing various
functional interfaces defined by Spec, and realizing various business interaction logic with clients. Other
components are tool components of PackageManager, which are used by PackageManager to
implement corresponding basic operations.

Receiver is a component used by UCM PackageManager to complete the upgrade package reception,
which implements resource application, transmission control, data caching, and package integrity
verification during the upgrade package reception process.

Extractor is a tool used by PackageManager to extract compressed packages. Extractor provides abstract
interface to PackageManager, which can realize the extraction function of zip compressed package.

12/30
Parser is used by PackageManager to parse the contents of the Manifest file and obtain software
dependencies, versions, names, checksums, references, etc. Parser is also used to parse information such
as the version, name and other information of the installed applications on the platform, package
information, and for the client to obtain the list of installed applications, package lists, etc. Parser reads
the application.json file from the software installation path (/opt/function/) and organizes it into
SoftClusterInfo.

Storage is a tool component used by PackageManager to process storage-related operations. It is

mainly used to solidify cached data to NVM. In the software solidification operation, the original data is
not deleted, but an overwrite method is adopted.

Transaction is used to implement activation and rollback operations after installation. After the software
is installed or upgraded, restarting may encounter errors of various reasons. At this time, the client can
take a rollback operation to roll back the system to the state before the installation or upgrade. After
UCM calls the Activate interface on the client, it first needs to check the dependencies of the application.
After the dependency check is passed, the EM interface is called to start the applications involved in this
upgrade in turn (the information is saved in the manifest file of the upgrade package), according to the
return value of EM Determine whether the upgrade is successful. During this process, as long as an
application fails to start, UCM considers that the upgrade has failed and reports the error information
to the Client. If all the software activations are successful, the activation is complete and UCM reports
that the upgrade was successful.

DM (Diagnostic Management), as a service module, provides diagnostic services for the AUTOSAR AP
platform, interacts with the diagnostic tester through DoIP externally, and provides services for
applications that need to be diagnosed through ara::com internally. DM is mainly divided into two
modules, DCM and DEM. Among them, DCM (Diagnostic Communication Management) is mainly
responsible for diagnostic communication management, which is the processing of UDS related
commands. DEM (Diagnostic Event Management) is diagnostic event management, which is mainly
responsible for the processing of events within the software platform.

In the AUTOSAR OTA Demo system, the DM is used to perform the diagnostic transmission of the
upgrade package to upgrade other devices, including vehicle discovery, connection establishment, and
UDS diagnosis. The implementation details are as follows:

1）Vehicle discovery

The purpose of the vehicle discovery process is to tell the DoIP attribute of the node to other DoIP
nodes in the current local area network. Other DoIP nodes can decide whether to establish connection

13/30
and communication with them according to their own business needs. There are two ways for Server to
tell Client its DoIP attributes:

a) After power-on, actively send vehicle announcement message three times, carrying logical
address, VIN, EID and other information in the message, as shown at a in Figure 2-10;
b) Client sends the vehicle identification request by broadcast at an appropriate time, and the server
that receives the message replies to the vehicle identification response message in the form of
unicast, which carries the logical address, V IN, E ID and other information. As shown at b and c
in Figure 2-10.

Figure 2-10 Vehicle discovery

2）Establish a connection

Figure 2-11 Establishing a connection

14/30
Client and Server can communicate with UDS only after a connection is established. The establishment
of a connection is divided into 3 steps:

a) Client actively establishes a TCP connection with Server, as shown at a in Figure 2-11；
b) The client sends a routing activation request message to request activation of the route, and the
server agrees or rejects the activation request according to the actual situation. The activation
result is notified to the client by sending a routing activation response message, as shown at b
in Figure 2-11;
c) If the client and the server have not communicated for a long time, the server will actively send
an alive check request message to check whether the client is still working normally, if the client
does not send an alive check response message, the server will disconnect the established
connection with the client, as shown in the figure Shown at c in Figure 2-11.
3）UDS diagnosis

The Client has been discovered by the vehicle, has obtained the information of all DoIP nodes in the
current LAN, and has established connections with all DoIP nodes. The client can initiate an upgrade
package transmission request to a node in the network through the UDS upgrade process defined in
advance through the logical ID, VIN, and EID, as shown in Figure 2-12.

Client Server
( Smart Antenna ) ( Gateway/IVI )

Diagnostic message
DoIP ACK
Diagnostic message response

Diagnostic message
DoIP ACK
Diagnostic message response

Figure 2-12 Diagnosis

Regardless of the CAN controller or the Ethernet controller, the software flashing process is the same,

see Figure 2-13.

1. Enter the extended diagnostic session ($10 03): The diagnostic device sends an extended mode
request message ($10 03) at a period of 3s through functional addressing, so that all electronic
control units in the CAN network enter the extended diagnostic session.

15/30
2. Check of flashing conditions ($31): The diagnostic device sends routine control services ($31 01
02 03) through physical addressing to check whether the target controller meets the
preconditions for flashing.
3. Prohibition of DTC recording ($85): The diagnostic equipment uses the DTC setting service ($85)
through functional addressing, and prohibits the electronic control unit in the CAN network from
recording DTC.
4. Close communication ($28): The diagnostic equipment uses the communication control service
($28) through functional addressing to prohibit the electronic control unit in the CAN network
from sending and receiving non-diagnostic messages.
5. Enter the programming session ($10 02): The diagnostic device enables the electronic control
unit to enter the programming session through physical addressing. When the application
program is running, the electronic control unit can jump from the application program to the
boot loader.

F：Functional addressing P：Physical addressing

16/30
 Figure 2-13 Flashing flow chart

6. Security access (($27) The diagnostic device provides secure access to the electronic control unit
through physical addressing (($27)). All electronic control units that can be rewritten should
support the security access service.

One of the following conditions occurs, the electronic control unit will be locked:

 Receive another security access request (regardless of whether the request format,
content, security level, etc. are valid).
 The electronic control unit switches to another diagnostic session, or the electronic control
unit switches to the same diagnostic session.
 Before unlocking the electronic control unit, the following services need to be
prohibited:
 Write data.
 Request a download.
7. Write fingerprint information ($2E F1 84): The diagnostic device writes fingerprint information to
the electronic control unit through physical addressing.
8. (Optional) Flash drive flashing: flashing the Flash drive to the RAM address specified in the
electronic control unit. The flashing sequence consists of three service requests: request
download ($34), data transmission ($36) and request exit transmission ($37). If the electronic
control unit does not need to flash the Flash driver, please skip to step 10.
9. (Optional) Software CRC32 check ($31): If the electronic control unit does not need to flash the
Flash driver, please skip to step 10 to execute. After flashing the Flash driver, the diagnostic device
starts the verification through the routine control service ($31), and the diagnostic device
compares the verification value calculated by the electronic control unit with the verification value
on the device side. If the two are equal, the data flashing is successful.
10. Erase the corresponding area of the memory ($31 FF 00): This function uses the routine control
service ($31) to execute the memory erasing program. Before this routine is called, the valid
status bit of the logic block that is requested to be erased must be set to invalid to prevent the
unsuccessful end of the flashing process and accidental execution of application program steps.
11. Application program flashing: flashing the application program to the specified non-volatile
memory address in the electronic control unit. The flashing sequence consists of three service
requests: request download ($34), data transmission ($36) and request exit transmission ($37).
12. Software CRC32 check ($31)
See step 9 for details.
13. Flash Compatibility Check

17/30
 After completing the application program flashing, the electronic control unit shall perform a
flashing compatibility check and update the software compatibility status parameters according
to the check results.
14. Restart of the electronic control unit ($11): The electronic control unit is reset by hardware to
erase the Flash driver code in the RAM and make the application effective.
15. Enter extended session ($10): The diagnostic equipment uses functional addressing to enable the
electronic control unit on the CAN network to enter the extended session through the session
control service.
16. Open communication ($28): The diagnostic equipment uses the communication control service
($28) to restore the normal communication of the electronic control unit on the CAN network
through functional addressing.
17. Turn on the recording DTC function ($85): The diagnostic equipment enables the recording DTC
function through function addressing. Allow the electronic control unit connected in the CAN
network to record DTC.
18. Enter the default session ($10): The diagnostic equipment uses functional addressing to enable
the electronic control unit on the CAN network to enter the default session through the session
control service.

2.4 Vehicle firewall

With the rapid development of vehicle network technology, the accompanying network attacks have
become more and more serious. As a network security barrier, vehicle firewalls can effectively resist
external network attacks. The vehicle firewall has the following functions:

 Network security isolation, unauthorized access is prohibited

 Vehicle firewall policy management and dynamic update
 Provide security protection mechanism for data interaction between domains
 Border intrusion prevention detection

The vehicle firewall is developed based on the Neusar aCore basic software independently developed
by Neusoft Reach. NeuSAR aCore is a set of basic software for autonomous driving, V2X and other
applications that can meet high-performance computing and high-bandwidth communications, and
fully supports the AUTOSAR adaptive platform standard. Figure 2-14 shows the software architecture
of the vehicle firewall.

18/30
 Figure 2-14 NeuSAR aCore basic software architecture

In the OTA demo system, the upgrade scheme adopted by each domain controller is implemented
based on the AUTOSAR adaptive platform. The OTA upgrade strategy of the vehicle firewall is realized
by the technology of diagnostic transmission upgrade package + UCM. The vehicle firewall will first
receive the vehicle identification request from the gateway, and then feedback its own information
(logical address, VIN, etc.) to the gateway, and the gateway will save the connection information with
the vehicle firewall. Next, the gateway will send a series of diagnostic requests to prepare for the
upgrade, such as switching to a programming session, checking whether the domain controller meets
the flashing conditions, and verifying safe access. After all the preparations are done, the upgrade
package starts to be transmitted. NeuSAR aCore mainly handles 3 types of service requests:

 0x38RequestFile Transfer service, which sends the information related to the upgrade to the
domain controller, and waits for the domain controller to feedback the upgrade information;
 0 x36TransferData service is responsible for transferring upgrade data;
 0 x37RequestFileTransfer service, responsible for verifying whether the data transfer is complete.
After the upgrade transfer is completed, the correctness and dependency of the upgrade file will
be checked. The upgrade file is placed in a specific location, and the UCM client is notified to use
this file to update; after the UCM client recognizes the upgrade file, it will use the standard service
interface PackageManagement to transmit the software package to the UCM server, and control
and manage the upgrade process of the UCM server ; After the UCM server receives the upgrade
package, under the guidance of the UCM client, perform the upgrade verification, processing,

19/30
 and activation steps of the upgrade package.

Figure 2-15 Functional block diagram of NeuSAR aCore diagnostic module

As mentioned above, OTA upgrade mainly involves two major technical modules: upgrade and
configuration management (UCM) and diagnosis (DM). The UCM function cluster in Neusar aCore is
used to install, update and delete applications. The UCM functional cluster includes three terminals: the
upgrade package maker, UCM server, and UCM client. On the compilation environment, the upgrade
package maker first uses the host computer to configure the upgrade package content, then creates
the corresponding upgrade package on the compilation environment, and finally uploads the upgrade
package to the UCM client (OTA platform). The UCM client is responsible for controlling and managing
the upgrade process of the UCM server, implements software upgrades, and obtains software packages
and related information about the upgrade process. The UCM server is responsible for the specific
20/30
operations of software upgrades. The diagnostic module in NeuSAR aCore uses two protocols,
Diagnostics over Internet Protocol (DoIP) and Unified Diagnostic Services (UDS), based on the on-board
Ethernet diagnostic technology. The DoIP protocol is to carry out diagnostic communication through
the network protocol, and specifies the diagnostic communication interaction mode and message
format between the test equipment and the domain controller. The UDS protocol stipulates a series of
diagnostic services, such as reading DID, routine control, and domain controller flashing services to
facilitate after-sales and production line personnel to find and solve problems. Figure 2-15 shows the
functional framework of the diagnostic module in NeuSAR aCore.

2.5 Cockpit Domain Controller and Screen

In the OTA Demo system, an HMI interface is developed in the cockpit domain controller for the human-
computer interaction of the entire system upgrade process, which is upgrade control operation and
upgrade status information display. The upgrade application program in the cockpit domain controller
cooperates with the CM, DM, and UCM modules in the AUTOSAR adaptive platform to complete the
management and control of the upgrade of each module in the system.

Figure 2-16 Cockpit domain controller software architecture diagram

The upgrade application communicates with the OTA Client in the smart antenna through the CM
module, so that the upgrade application initiates upgrade-related control commands to the OTA Client,
and at the same time obtains the corresponding status information for display in the HMI, and the smart
21/30
antenna runs SOME/IP The client, the SOME/IP server is running in the domain controller, and the
detailed process of communication between the two is as follows：

1) Establish service connection

The purpose of service discovery is to inform other SOME/IP nodes in the multicast network of the
service ID, instance ID, port number, and IP address of the service provided by the SOME/IP node. Other
SOME/IP nodes can choose whether to communicate with this node in SOME/IP according to their own
business needs. Server has two ways to inform Client of information such as service ID, instance ID, etc.：

 The server periodically sends an offer service message at a fixed interval. The message carries
information such as service ID, instance ID, port number, and IP address, as shown at a in Figure
2-17.
 The client sends a request server message in a multicast manner at an appropriate time, and the
server that receives the message replies to the offer service message in a unicast form, which
carries information such as logical address, VIN, and EID. As shown at b and c in Figure 2-17.

Figure 2-17 Establish service connection

2) Check for updates

First, IVI needs to subscribe to the event group where the event is located, as shown at a in Figure 2-18.
Then IVI initiates a check and update request to Smart Antenna through the method. Smart Antenna
obtains updates, update package size, version number, and version number from the OTA Server.

22/30
Publish description information, etc., and send this information to the IVI through the event, as shown
in b and c in Figure 2-18.

Figure 2-18 Check for updates

3) Request to download the update package

First, IVI needs to subscribe to the event group where the event is located, as shown at a in Figure 2-19.
Then IVI initiates a download update package request to Smart Antenna through the method, Smart
Antenna downloads the update package from the OTA Server, and passes the download status and
progress. The event is sent to the IVI in real time, as shown at b, c, d, and e in Figure 2-19.

Figure 2-19 Request to download the update package

4) Request to install the update package

First, IVI needs to subscribe to the event group where the event is located, as shown at a in Figure 2-20,
and then IVI initiates an installation update package request to Smart Antenna through the method,

23/30
Smart Antenna upgrades each module through the DM and UCM function modules, and installs The
status and progress are sent to the IVI through the event, as shown at b, c, d, and e in Figure 2-20.

Figure 2-20 Request to install the update package

The upgrade application receives the upgrade package from the OTA Client through the DM module,
and transmits the upgrade package to the UCM module for specific upgrade actions. The cockpit
domain controller uses UCM's Update function to implement program updates. The upgrade process is
divided into three stages: data packet transmission, data packet processing, and activation. The details
of each state of each stage are as follows:

1. The upgrade application calls the TransferStart interface to initiate software package transfer and
enters the Transferring. In this process, UCM assigns an ID identification code representing this
transmission task to the upgraded application, and applies for resources in advance for receiving
the software package, and prepares for receiving it. The TransferStart interface requires the client
to pass in the size of the software package to be transferred.
2. In the Transferring state, the upgrade application calls the TransferData interface to transfer data.
Since the software package is generally large and cannot be transferred at one time, the data
packet needs to be broken down into data blocks. The TransferData interface requires the
upgrade application to pass in the data block count for this transfer. (1,2,3...).
3. The upgrade application calls TransferExit to end the transfer. If the sum of the data received by
the UCM at this time is equal to the size of the software package, the transfer is successfully
terminated and enters the Transferred state. In other cases, there is an error and enters the Error
state.

24/30
 4. In the Transferred state, the upgrade application can call DeleteTransfer to delete the software
package.
5. In the Transferred state, the upgrade application can call the ProcessSwPackage interface to
initiate package processing tasks and enter the Processing state. In this state, the client can call
the GetProcessProgress interface to query the processing progress. The processing content of
the software package includes decompressing the software package, reading the manifest
content, obtaining the relevant configuration information of the software installation, closing the
relevant applications that are running, and closing the relevant files (including application files,
configuration data, calibration files, the manifest, etc.) is copied to the corresponding path or
removed from the relevant path. The metadata provided by the manufacturer in the software
package indicates the operations that UCM needs to perform at this stage. After the software
package is processed, it enters the Processed state. In the Uninstall operation, the integrity of
dependencies needs to be checked, that is, if there are applications that depend on the program
to be uninstalled, an error will be reported and the uninstallation cannot be performed.
6. In the Processed phase, the upgraded application can call the Revert-ProcessSwPackages
interface to restore the system file changes caused by the processing software package to the
state Transferred before processing, or call the Activate interface to activate all processing, and it
will enter the Activating state at this time.
7. During the activation process, if there is any error, it will return to Processed. The upgraded
application can also call the Rollback interface to restore the system to the state before activation.
The activation process first performs a dependency integrity check, and restarts the application
or system after all dependencies are satisfied.
8. After the activation is complete (the upgraded application is running), the upgraded application
can call the Finish interface. UCM will clean up the intermediate data, cached data, software
package, etc. during the upgrade process at this time, and the upgrade operation ends.

2.6 ADAS domain controller

As the ADAS domain controller of the upgraded end, Freetech based on the AUTOSAR adaptive
platform, through the DoIP bus, in the controller ARA: DIAG service processing function to achieve 0x38,
0x36, 0x37 based on the diagnostic service of the Ethernet protocol stack.

When the 0x37 instruction transmits the software upgrade package, the UCM Client instance will be
triggered, and the UCM Client instance will call each service of UCM through the internal bus SOME/IP
of the controller. In the UCM service, Activation/Verification will determine the validity of the software

25/30
package. If the software package is invalid, the program flow is rolled back, and if it is valid, the upgrade
is completed.

Figure 2-21 ADAS domain controller software architecture diagram

Figure 2-22 Freetech domain controller OTA upgrade flow chart

26/30
 Figure 2-23 Freetech domain controller Package Manager state diagram

2.7 Gateway
In the AUTOSAR OTA Demo project, the gateway is responsible for combining smart antennas, cockpit
domain controllers, ADAS domain controllers, ADAS cameras, and vehicle firewalls into a local area
network that combines CAN and Ethernet, ensuring safe and reliable data communication between
modules. The hardware adopts NXP's MPC5748G chip-based development board for implementation.
It provides 8 CAN interfaces, 5 Ethernet (100M) interfaces, and the Ethernet rate can reach 6Gbps after
using optimized technology.

CAN function realization mainly includes three parts: physical layer, data link layer and network layer.
The physical layer realizes the CAN signal differential voltage through the circuit design to ensure the
correct transmission of the CAN signal data; the data link layer needs to ensure the normal transmission
and reception of the CAN signal data, that is, the CAN circuit signal is converted into the corresponding
CAN data. This part of the work is performed by the MCU The internal CAN control port is implemented,
and the corresponding CAN driver needs to be developed at the software level to ensure the normal
operation of the CAN control port; the network layer is developed according to the ISO 15765-2
specification definition, which realizes the framing of CAN data packets, Packet grouping and flow
control functions.

27/30
The realization of the Ethernet function is based on the physical layer circuit design, and the network
port driver layer program is developed to ensure the normal transmission of Ethernet data. According
to the needs of the gateway function, the LwIP protocol stack was transplanted on the basis of the driver
layer to realize the support for IPv4 and IPv6 protocols, and the DoIP server was developed to ensure
the safety and stability of the upgrade process.

2.8 ADAS Camera

As the ADAS camera sensor of the upgraded end, Freetech is based on the classic AUTOSAR platform
architecture, and through the traditional DoCAN method, it receives UDS messages forwarded by the
gateway, parses the encrypted upgrade package, performs CRC verification, and supports resumable
transmission upgrades.

Figure 2-24 Schematic diagram of ADAS camera sensor software architecture

3 Concluding remarks
In recent years, with the continuous enhancement of automotive functions, especially the higher
requirements of autonomous driving and smart cockpit systems, people's attention to automotive
software continues to increase. The AUTOSAR organization has also launched a new standard platform
Adaptive Platform (AP) in response to these new challenges. In the context of the increasing use of the

28/30
AUTOSAR standard by Chinese companies, several companies came together and cooperated in the
development of the AUTOSAR China User Group Demonstration System Subgroup, and realized a car
computer that has reference significance for actual mass production projects. Network OTA
demonstration system. Through this process, all participants have a deeper understanding of the system
and software development that combines OTA technology with the AUTOSAR standard. And it has laid
a certain foundation for the products of all parties to comply with the new AUTOSAR standard.

At the same time, this project once again proved the feasibility of the user group cooperation framework
organized by AUTOSAR. Many parties participate in the user group project initiated by someone, and
they all have the inherent motivation to bring their own gains, and they can carry out task assignment,
project management and cooperative development spontaneously and equally. The members of the
project team recognized the advantages of using the AUTOSAR standard from the perspective of their
products. I believe that more AUTOSAR user groups and working groups in China will emerge in the
near future to jointly promote the development of standards-based automotive software.

Terms and abbreviations

ADAS： Advanced Driver Assistance System

AP： Adaptive Platform
API： Application Program Interface
BSW： Basic Software
CAN： Controller Area Network
CM： Communication Management
CP：Classic Platform
DCM： Diagnostic Configuration Management
DEM： Diagnostic Event Management
DM： Diagnostic Management
DoCAN： Diagnostics over CAN
DoIP： Diagnostics over Internet Protocol
DTC： Diagnostic Trouble Code
ECU： Electronic Control Unit
EID： Entity Identification
EM： Execution Management
HMI： Human-machine Interface
IVI： In-vehicle Infotainment

29/30
LIN： Local Interconnect Network
LTS： Log Trace Service
MCU： Micro-controller Unit
MPU: Micro-processor Unit
OEM: Original Equipment Manufacturer
OTA： Over-the-air update
ROS： Robot Operating System
SOA： Service-oriented Architecture
UCM： Update and Configuration Management
UDS： Unified Diagnostic Services
V2X： Vehicle to Everything
VIN： Vehicle Identification Number

目录索引

1 Overview .............................................................................................................................................................................. 1

2 Demonstration system design and realization ...................................................................................................... 5

2.1 System design ........................................................................................................................................................... 5

2.2 OTA Platform ............................................................................................................................................................. 8

2.3 Smart antenna .........................................................................................................................................................10

2.4 Vehicle firewall ........................................................................................................................................................18

2.5 Cockpit Domain Controller and Screen..........................................................................................................21

2.6 ADAS domain controller ......................................................................................................................................25

2.7 Gateway .....................................................................................................................................................................27

2.8 ADAS Camera ..........................................................................................................................................................28

3 Concluding remarks.......................................................................................................................................................28

30/30