Summary of ArcCore: Accelerating Innovation and the AUTOSAR Standard

Vasil Borozanov
M.Sc Software Systems Engineering, Matriculation Number : 341041, Rheinisch-Westf alische Technische Hochschule, Aachen vasil.borozanov@rwth-aachen.de

Abstract. This is a summary of the lecture given by Thomas Winkler, where he explains how the company ArcCore operates, the main products and the connection with AUTOSAR. Furthermore, an overview of the AUTOSAR standard is given, explaining the architectural layers, as well as the main goals and principles. Dierent types of communication between components is also discussed, and the further process of the software development. Keywords: AUTOSAR, Software Component Development

Introduction

The opening was the introduction to the ArcCore. This company was founded in 2009, it is now located in Sweden and Germany. It consists of around 25 employees: engineers, sub-contractors, managers, admins and sales representatives. The size of this company is not xed it can be dynamically scaled with temporary resources and/or trained sub-contractors [1]. ArcCore is a company which standardizes on AUTOSAR. AUTOSAR (Automotive Open System Architecture) is an open standard for automotive software architecture, developed in collaboration with automotive Original Equipment Manufacturers (OEMs), suppliers, tool developers and other companies. In order to get a clear picture of the software developed by ArcCore, the lecturer also described the goals of the AUTOSAR. The main goals are: standardization of system functions intended for usage for the automotive industries (Standard Core solution), not being dependent of a certain vehicle type (easily scalable) and to be prepared for the future technologies, improving the good cost-eciency without compromising the quality. Operating on a standard also gives the exibility to cooperate with many OEMs. In order to make sense of all the current and upcoming Electronic Control Units (ECUs), the AUTOSAR partnership developed specic software architecture.

Vasil Borozanov

ArcCore products

The portfolio of the company oers products and licenses which reduce the developing time and increase the productivity. The oered products are: Arctic Core, Arctic Studio and the Arctic Bootloader. ArcCore also oers adoptions and extension on customers demand, and professional expertise about integration and conguration, AUTOSAR or about embedded platforms.

AUTOSAR Architecture

The AUTOSAR Architecture is divided into four software layers: Application Layer: contains the functional applications of an Electronic Control Unit (ECU) network. They are also referred to as AUTOSAR Components, serving to encapsulate the functionality for implementing the standard. AUTOSAR Run-Time Environment (RTE): it provides the communication services to the components. It decouples the application software from the concrete infrastructure software. The main purpose of this layer is to make the AUTOSAR Components independent from a particular ECU. AUTOSAR Basic software: Denes the infrastructure software. This layer is located between the microcontroller and the RTE. We can further subdivide it into four dierent types of services: Input/output it standardizes the access to I/O peripherals (like sensors). Memory it standardizes the access to both internal and external memory. Communication standardizes the access to the vehicle network systems. System oers standardized library functions and services. The Microcontroller Abstraction: This is the lowest layer, which serves to make the layers above independent from the microcontroller. It contains internal drivers, who have direct access to the controller and memory.

Designing Software Components

Arctic Studio is intended for the developers. It is an Eclipse based IDE to simplify the process of making applications for the automotive market. The compiler is bundled along with the necessary tools. With this tool one can create software components or compositions, dene interfaces and ports between these components, and program the behavior of each component. Besides developers, the studio can be used by integrators: a complete application can be integrated from a set of components and connected to an embedded platform, mapping the components to tasks and the ports to signals. The coupling between the application software and the hardware should be as low as possible. In order to achieve this, AUTOSAR introduced the Virtual Functional Bus (VFB). The VFB encapsulates the communication mechanisms between dierent AUTOSAR components on an abstract level (who is communicating with whom). This allows a virtual

Summary of ArcCore and AUTOSAR

integration, suitable for early development phase. The communication is described with the concept of ports, interfaces and connections. This is the most abstract level that describes a component. The second abstraction level denes the behavior of the components and how it is communicating with the RTE. The communication pattern is implemented by using the events scheduling, as well as scheduling units and aspects. The lowest abstraction level describes the implementation of the internal behavior and maps it into code. This is where the component realization is dened. Depending whether we are application developers, integrators or platform managers, Arctic Studio Solutions provides tools for each category.

Fig. 1. Layers of AUTOSAR Architecture

The application developers create SWCs, dene the interfaces, the ports and specify the internal behavior of them. The Arctic Studio tools provide a description language for the software components Artext. Additional feature for the SWCs is the Arctic SWC contract generator. A SWC is independent from the type of the microcontroller of the ECU, the location of other SWCs which com-

Vasil Borozanov

municate with and the number of times a software component is instantiated in a system.

Fig. 2. AUTOSAR Software Components

Communication between SWCs and Integration

In theory, components are exchangeable if they provide the same public interface and implement the same logic. Components are developed against the VFB and they do not communicate directly with the OS or the hardware. The component has well dened ports for communication, which can be PPort (provided interface) or RPort (required interface). The basic communication patterns are Client Server and Sender Receiver. Client Server The server is the provider the port that provides the interface (PPort). The client invokes the operations (RPort), requesting a service. Depending on the communication, a client can use blocking (synchronous) or non-blocking (asynchronous) communication. Sender Receiver The sender gives information to one or several receiver. The sender is non-blocked and doesnt expect a response from a receiver. Every port interface has also a ag attribute called isService, whose purpose is to describe if the service is provided by AUTOSAR or by another component. The integrators connect the ECUs to an ECU Extract, mapping the SWCs to tasks and ports to signals. Given a conguration, they generate a RTE from it. In order to integrate a SWC, AUTOSAR provides description format for the system, as well as for the resources. Platform managers are conguring the modules in AUTOSAR Basic Software (BSW). Using wizard congurations for the communication stack can be imported. After that c-code is generated and compiled together with the Arctic Core. When mapping components to ECUs, certain constraints have to be introduced. The System Conguration Input (SCI) introduces constraints and requirements that force or forbid a SWC to be mapped.

Summary of ArcCore and AUTOSAR

Fig. 3. Communication Patterns: a) Client-Server b) Sender -Receiver

Arctic Core is the embedded platform. It is including all the features need for building the software platform for the given Electronic Control Unit (ECU). Regarding the AUTOSAR version (3.x or 4.x), there are two version of the Arctic Core. The Arctic Bootloader serves to check if the main software is present. It runs on start-up, after the CPU is restarted. It is used to handle the specic requirements by the OEMs.

AUTOSAR Software Process

The rst step is to map the SWCs to the ECUs. This is done by the System Conguration activity. The output is an XML document called System Conguration Description (SCD), which includes the system information and the mapping itself. Next the information from the SCD is extracted. This is done for each ECU in the system. Then the ECU conguration takes place: all the information about implementation is added, Basic Software Modules etc. The output document is the ECU Conguration Description. Using this document, the software for the specic ECU can be developed. In this step details about the scheduling information have to be dened. The last step is the generating of the executables based on the congurations dened in the previous step. This means generated or compiling code and linking the package les into an executable. Parallel with this steps, additional steps are performed, such as generating the components API and implementing the functionality.

Vasil Borozanov

The AUTOSAR motto is cooperate on standards, compete on implementations. ArcCore promotes the use of open standard: their platform is issued under the Open Source license.

Future of ArcCore

The presenter stated that ArcCore has a strong eco system and a big community, with intuitive tools and open for collaboration. Since it benets from the standard, ArcCore continuously contributes to the development of it, as well as to the Artop initiative (AUTOSAR Tool Platform User Group). The community interested in the products grows steadily. The biggest market segment belongs to the cars, after that the trucks and special vehicles. The ArcCore products can be obtained by two licenses i.e. it implements the dual licensing model. One is proprietary commercial license and the other one is GNU General Public license.

Summary

As the interest for the automotive industry is continuously increasing, so is the process for developing components becoming easier. More and more developers are writing software for vehicles; however the standard is very strict when it comes down to implementation. The AUTOSAR architecture follows this standard. There are varieties of tools intended for implementation. ArcCore Studio oers all the functionality needed for developers, integrators are platform managers.

References
1. 2. 3. 4. ARCORE http://www.arccore.com/ AUTOSAR Automotive Open System Architecture http://www.AUTOSAR.org/ AUTOSAR, From Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/AUTOSAR Artop: Developing AUTOSAR Tools in the Community by Dana Wong, Thomas Wengler, Rinat Asmus, Michael Rudorfer 5. Real-Time Systems Laboratory (ReTiS Lab): An introduction to AUTOSAR 6. Chandrashekara N (ETAS/ESC): Basics of AUTOSAR 7. Sandmann G., Thompson R: Development of AUTOSAR Software Components within Model-Based Design

References
1. Lutkebohle, I. Bworld robot control software. http://aiweb.techfak.uni-bielefeld.de/content/bworld-robot-control-software/, 2008.