Case Study: Implementation of AUTOSAR TcpIp
AUTOSAR is being the prominent talk of the automotive industry in the last decade. AUTOSAR is known for its flexible design and scalability, among various other advantages. This case study discusses about implementation of one such AUTOSAR module, TcpIp. The implementation approach, challenges faced are described further.
Background
In any automotive environment, various services, including communication between ECUs and memory management, is essential. Having a standard software architecture is significant, especially when there are contributions from multiple suppliers. AUTOSAR is a global development partership which standardizes software architecture for automotive Electronic Control Units (ECUs).
Customer is working on an integrated implementation of various AUTOSAR modules. Our development team works on three of such AUTOSAR modules: SomeIpTp, Sd, TcpIp. There was a specific requirement for TcpIp to implement it on top of lwIP. lwIP is a light-weight IP stack used when dealing with limited resources.
TCP/IP Stack
The TCP/IP Stack is a fundamental framework for transmission of data from one end to another. It specifies how data should be packetized, addressed, transmitted, routed, and received. It comprises of a number of communication protocols - ARP, IP, ICMP, TCP, UDP, DHCP, Auto-IP, to name a few. Each of these protocols solves a unique communication problem.
lwIP
Some ECUs that does basic sensor interfacing would be physically small and inexpensive. In such a scenario, an implementation of the TCP/IP stack, might have to consider using limited computing resources. lwIP is a small independent implementation of the TCP/IP protocol suite. The focus of the lwIP TCP/IP implementation is to reduce resource usage while still having a full scale TCP. This makes lwIP suitable for use in embedded systems with just tens of kilobytes of free RAM and room for around 40 kilobytes of code ROM.
AUTOSAR
The AUTOSAR community aims to have a standardized software architecture in place that can be used by various vendors contributing for an automotive environment. It provides specifications for many software components. For each component, it specifies the list of APIs to be implemented, callback functions to be called from other modules, configuration parameters to be supported.
The Implementation
AUTOSAR TcpIp specifies a list of APIs to be implemented, and lwIP has all such APIs implemented. Hence, it was assumed that a simple mapping from AUTOSAR’s TcpIp requirements to lwIP’s actual TCP/IP implementation would be sufficient. But, there was more to it. lwIP had several deviations from the specifications of AUTOSAR’s TcpIp. The challenges that are faced during implementation of such mappings, and solutions to overcome the same are listed below.
Challenge #1: Understanding AUTOSAR’s configuration parameters.
AUTOSAR specifies a number of requirements, including software requirements, configuration parameters. Those parameters could be as simple as enabling or disabling a particular protocol to reduce code at compile time. Some parameters could be intended to control a protocol’s behaviour. Thus, understanding the protocol was a pre-requisite to getting familiar with configuration parameters. Extensive study and presentation activities for understanding the protocols and hence the config parameters were conducted amongst team members. Then a design document was created on configuration parameters, bifurcating into Supported in lwIP, Partically Supported in lwIP, Supported in TcpIp and Not Supported.
Challenge #2: Mapping from AUTOSAR’s TcpIp to lwIP’s TCP/IP
Even though the core implementation of both AUTOSAR’s requirements and lwIP’s implementation was the same TCP/IP, there were some differences between them. lwIP was not able to support some of the requirements specified by AUTOSAR. Before concluding that a particular feature is not supported, lwIP is searched thoroughly. Interestingly, AUTOSAR could not make use of some of the features implemented by lwIP, as it is not mentioned in the specifications. Apart from mapping APIs, data structures also needed to be mapped at certain places. For example, AUTOSAR specifies that an Ethernet Interface controller can have more than one Local Address. However, lwIP’s Ethernet interface data structure could hold only one Unicast IPv4 address, making it not possible to support the requirement.
Challenge #3: Limited Hardware for Testing
To test the stack in the board, TcpIp has to be integrated with all other software components, including a EthIf layer customized to the board. Owing to limited hardware availability and the complexity of the build, testing the implementation on the board was quite challenging. To solve this, a dummy EthIf layer was developed using TAP interface. A networking setup was created between the application invoking TcpIp APIs and the host machine using TAP network interface on Linux. This enabled us to test the software on the PC, overcoming the build complexities and limited hardware availability.
Challenge #4: Invoking Various Test Scenarios
As the behaviour of AUTOSAR’s TcpIp stack varies for different configuration
provided, invoking such scenarios is necessary. For the same reason, a test setup
was designed. Each test case had a folder, and shell scripts in it to
generate and build test cases. A default configuration was kept, and
that was customized according to test cases. As running and testing them
manually was quite painful, they were later automated using Robot Framework,
with keywords implemented using scapy Python module.
Conclusion
Despite the challenges, we were able to successfully implement the module on top of lwIP and map the requirements specified by AUTOSAR. Both unit testing and integration testing were performed on the module to check for compliance with the specification. Static code analysis, such as MISRA checks, complexity checks, and style checks, was also performed to ensure code quality.
Partner with us to accelerate your AUTOSAR development. Whether you need MCAL support for a new microcontroller, or a custom AUTOSAR network or flash stack to reduce licensing costs, our team can help. Contact us at sales@zilogic.com