Kurz nach der Jahrtausendwende führte die steigende Innovation und Komplexität von entwickelten Automotive-Systemen zum Anstieg der Anzahl von installierten elektronischen Systemen in Fahrzeugen. Dies wurde und wird noch immer durch die stetig wachsende Anzahl von rechtlichen und sicherheitstechnischen Vorgaben verstärkt. Da ein signifikanter Teil der Entwicklungskosten neuer Systeme in der Softwareentwicklung auf den im Automotive-Bereich verwendeten Steuergeräten (Electronic Control Unit, oder ECU) entsteht, wurde 2003 der AUTOSAR Developement Partnership ins Leben gerufen. Das Ziel dieser Arbeit ist, ein einheitliches System zu realisieren, in welchem eine vom Anbieter unabhängige Testbasis für AUTOSAR-konforme Tests ermöglicht werden soll, so dass ein Begleiten des Entwicklungsprozesses möglich ist. Es sollen sich Testmodule verschiedener Art am System anmelden und schließlich einem Arbeitsfluss zur Absicherung von AUTOSAR-Steuergeräten zur Entwicklungszeit hinzugefügt werden.

AUTOSAR was created as a standard software infrastructure to be able to fulfill a very large amount of requirements. These days, more and more OEMs are trying to introduce AUTOSAR in their products. Since there are a large amount of diagnostic IDs needed in the Engine control unit and also a huge effort is necessary to configure the ECU, it is very much important to have a tool to generate some parts of the Engine Control Unit software, most importantly the diagnostics software. Diagnostic Communication manager is one such AUTOSAR module which deals with a huge amount of diagnostic data identifiers. Also at BEG, In the actual Non-AUTOSAR Bosch Automotive software, there are a number of different features that are needed and expected in the future AUTOSAR software. The aim of this thesis is to develop a tool that successfully introduces AUTOSAR in the BEG projects with all the necessary features and that is best in terms of Usability, Maintainability, and Improvability. This tool has to generate the complete AUTOSAR Diagnostic communication manager software with all the necessary features. The work can be divided into two parts. The first part includes a complete analysis of the existing tools that are used to generate configuration files and code. Then, List out all the possibilities of each tool, find their advantages and disadvantages and compare each of the tools, either individually or as a combination of tools. This is followed by documenting the choice of best way to generate AUTOSAR DCM with all the necessary features. In the second part, the implementation is carried out. After the best tool is chosen, the implementation of the features for that particular tool is planned accordingly so that it generates the DCM software. Implementation is made and then it is tested with the existing test bench.

The automotive industry is experiencing a rapid increase in software complexity due to various functionalities introduced into modern vehicles. Companies use software development standards like AUTOSAR to develop the application layer software independent from the hardware. Development methodologies such as Model-Based Design are used to increase the efficiency of the development process and decrease the time to market. However, to ensure high-quality software standards such as A-SPICE are imposed on the companies. Conforming to A-SPICE requires having certain traceability between work artifacts. Thus, manual and inefficient development, testing, and requirement management processes lead to higher time to market. This thesis will introduce the concept of virtual validation using VEOS virtual platform from dSPACE. The new toolchain will focus on automatizing the testing process, requirement management, and report generation. To highlight the benefits of the virtual validation concept this new approach will be compared to the existing one, which includes a lot of manual development steps. Besides the application of the virtual validation with AUTOSAR and non-AUTOSAR software architectures will be discussed.

Les véhicules modernes sont de plus en plus informatisés pour satisfaire les exigences de sureté les plus strictes et pour fournir de meilleures expériences de conduite. Par conséquent, le nombre d'unités de contrôle électronique (ECU) dans les véhicules modernes a augmenté de façon continue au cours des dernières années. En outre, les applications à calcul complexe offrent une demande de calcul plus élevée sur les ECU et ont des contraintes de temps-réel dures et souples, d'où le besoin d’une approche unifiée traitant les deux types de contraintes. Les architectures multi-cœur permettent d'intégrer plusieurs niveaux de criticité de sureté sur la même plate-forme. De telles applications ont été conçues à l'aide d'approches statiques; cependant, les approches dites statiques ne sont plus réalisables dans des environnements très dynamiques en raison de la complexité croissante et les contraintes de coûts strictes, d’où la nécessite des solutions plus souples. Cela signifie que, pour faire face aux environnements dynamiques, un système automobile doit être adaptatif; c'est-à-dire qu'il doit pouvoir adapter sa structure et / ou son comportement à l'exécution en réponse à des changements fréquents dans son environnement. Ces nouvelles exigences ne peuvent être confrontées aux approches actuelles des systèmes et logiciels automobiles. Ainsi, une nouvelle conception de l'architecture électrique / électronique (E / E) d'un véhicule doit être développé. Récemment, l'industrie automobile a convenu de changer la plate-forme AUTOSAR actuelle en "AUTOSAR Adaptive Platform". Cette plate-forme est développée par le consortium AUTOSAR en tant que couche supplémentaire de la plate-forme classique. Il s'agit d'une étude de faisabilité continue basée sur le système d'exploitation POSIX qui utilise une communication orientée service pour intégrer les applications dans le système à tout moment. L'idée principale de cette thèse est de développer de nouveaux concepts d'architecture basés sur l'adaptation pour répondre aux besoins d'une nouvelle architecture E / E pour les véhicules entièrement électriques (VEF) concernant la sureté, la fiabilité et la rentabilité, et les intégrer à AUTOSAR. Nous définissons l'architecture ASLA (Adaptive System Level in AUTOSAR), qui est un cadre qui fournit une solution adaptative pour AUTOSAR. ASLA intègre des fonctions de reconfiguration au niveau des tâches telles que l'addition, la suppression et la migration des tâches dans AUTOSAR. La principale différence entre ASLA et la plate-forme Adaptive AUTOSAR est que ASLA permet d'attribuer des fonctions à criticité mixtes sur le même ECU ainsi que des adaptations bornées temps-réel, tant dis que Adaptive AUTOSAR sépare les fonctions temps réel critiques (fonctionnant sur la plate-forme classique) des fonctions temps réel non critiques (fonctionnant sur la plate-forme adaptative). Pour évaluer la validité de notre architecture proposée, nous fournissons une implémentation prototype de notre architecture ASLA et nous évaluons sa performance à travers des expériences. / Modern vehicles have become increasingly computerized to satisfy the more strict safety requirements and to provide better driving experiences. Therefore, the number of electronic control units (ECUs) in modern vehicles has continuously increased in the last few decades. In addition, advanced applications put higher computational demand on ECUs and have both hard and soft timing constraints, hence a unified approach handling both constraints is required. Moreover, economic pressures and multi-core architectures are driving the integration of several levels of safety-criticality onto the same platform. Such applications have been traditionally designed using static approaches; however, static approaches are no longer feasible in highly dynamic environments due to increasing complexity and tight cost constraints, and more flexible solutions are required. This means that, to cope with dynamic environments, an automotive system must be adaptive; that is, it must be able to adapt its structure and/or behaviour at runtime in response to frequent changes in its environment. These new requirements cannot be faced by the current state-of-the-art approaches of automotive software systems. Instead, a new design of the overall Electric/Electronic (E/E) architecture of a vehicle needs to be developed. Recently, the automotive industry agreed upon changing the current AUTOSAR platform to the “AUTOSAR Adaptive Platform”. This platform is being developed by the AUTOSAR consortium as an additional product to the current AUTOSAR classic platform. This is an ongoing feasibility study based on the POSIX operating system and uses service-oriented communication to integrate applications into the system at any desired time. The main idea of this thesis is to develop novel architecture concepts based on adaptation to address the needs of a new E/E architecture for Fully Electric Vehicles (FEVs) regarding safety, reliability and cost-efficiency, and integrate these in AUTOSAR. We define the ASLA (Adaptive System Level in AUTOSAR) architecture, which is a framework that provides an adaptive solution for AUTOSAR. ASLA incorporates tasks-level reconfiguration features such as addition, deletion and migration of tasks in AUTOSAR. The main difference between ASLA and the Adaptive AUTOSAR platform is that ASLA enables the allocation of mixed critical functions on the same ECU as well as time-bound adaptations while adaptive AUTOSAR separates critical, hard real-time functions (running on the classic platform) from non-critical/soft-real-time functions (running on the adaptive platform). To assess the validity of our proposed architecture, we provide an early prototype implementation of ASLA and evaluate its performance through experiments.

Current trend in automotive industry is moving towards adopting the multicore microcontrollers in Electronic Control Units (ECUs). Multicore microcontrollers give an opportunity to run a number of separated and dedicated operating systems on a single ECU. When two heterogeneous operating systems run in parallel on a multicore environment, the inter OS communication between these operating systems become the key factor in the overall performance. The inter OS communication based on shared memory is studied in this thesis work. In a setup where two operating systems namely EB Autocore OS which is based on AUTomotive Open System Architecture standard and Android are considered. Android being the gateway to the internet and due to its open nature and the increased connectivity features of a connected car, many attack surfaces are introduced to the system. As safety and security go hand in hand, the security aspects of the communication channel are taken into account. A portable prototype for multi OS communication based on shared memory communication with security considerations is developed as a plugin for EB tresos Studio.

Moderne Fahrerassistenzsysteme und der Weg zum autonomen Fahren stellen immer größere Anforderungen an die Steuergeräte Hard- und Software im Fahrzeug. Um diese Anforderungen zu erfüllen kommen vermehrt hochperformante Steuergeräte mit einer heterogenen Prozessorarchitektur zum Einsatz. Ein Safety-Prozessor, auf dem ein standardmäßiges AUTOSAR-Betriebssystem ausgeführt wird, übernimmt dabei die echtzeitkritischen und sicherheitsrelevanten Aufgaben wohingegen die rechenintensiven und dynamischen Aufgaben auf einem sehr viel leistungsfähigeren Performance-Prozessor unter einem POSIX-Betriebssystem wie zum Beispiel Linux ausgeführt werden. Hierbei soll es ermöglicht werden unter dem Linux System ebenfalls AUTOSAR Softwarekomponenten und Module auszuführen, welche beispielsweise die im Fahrzeug verwendeten Kommunikationsprotokolle umsetzen oder weniger sicherheitskritische Aufgaben erfüllen. Auf diese Weise lassen sich andere Steuergeräte im Fahrzeug entlasten. Dazu wurde im Rahmen dieser Arbeit eine Softwarearchitektur entwickelt, die es ermöglicht AUTOSAR-Komponenten direkt in einer Linux-Umgebung auszuführen. Des Weiteren wurde eine einfache und effiziente Kommunikation zwischen AUTOSARKomponenten und Linux-Applikationen erarbeitet.

The development of embedded software in the automotive industry has reached a level of complexity, which is unmaintainable by traditional approaches. The AUTomotive Open System Architecture (AUTOSAR) was created to standardize the automotive software. In this architecture, the development of software is spread, in general, between three different entities: Original Equipment Manufacturers (OEMs), e.g. Volvo; Tier-1 Suppliers, such as Vector; and Tier-2 Suppliers, for example, Renesas Microelectronics. Another methodology that has emerged is to develop Electronic Control Units (ECUs) domain wise: infotainment, chassis & safety, powertrain, and body and security. To allow inter-domain communication, the state of art for fast and reliable communication is to use a gateway ECU. The gateway ECU is a crucial component in the electrical/electronic (E/E) architecture of a vehicle. In AUTOSAR, a third party, different from the car manufacturer, typically implements the gateway ECU. A major feature for a gateway ECU is to provide highly flexible configuration. This flexibility allows the car manufacturer (OEM) to fit the gateway ECU to different requirements and product derivations. This thesis investigates the implementation of post-build configuration for a gateway ECU. First, the thesis provides the reader with some background on AUTOSAR and the current E/E architecture of the gateway ECU. The protocols used by the gateway are explained. The design of a potential solution and its implementation are discussed. The implementation is evaluated through regression tests of the routing functionality. Processing time, memory use, and scaling of the solution are also taken into account. The results of the design and the implementation if judged adequate could be used as a springboard to allow post-build in an existing gateway ECU architecture. The results could consolidate the path towards full conformance to AUTOSAR. / Inbyggda system har ökat i fordonsindustrin. Utvecklingen av dessa inbyggda programvaror har varit komplex och är inte genomförbar per enhet. Idag är utvecklingen gjort av tre foretag: en OEM (Original Equipement Manufacturer), Tier-1 leverantorer som tillhandahaller mjukvara till OEMs, Tier-2 leverantorer som tillhandahåller elektroniska styrenheter (ECU) hardvaror. Förmedlingsnod ECU är en viktig komponent i ett fordons elektriska/elektroniska (E/E) arkitektur. En tredje part implementerar, som skiljer sig från OEM, de flesta funktionerna av den förmedlingsnod ECU. En viktig egenskap för en förmedlingsnod är att tillhandahålla en mycket flexibel konfiguration. Denna flexibilitet tillåter (OEM) att anpassa förmedlingsnod till olika kraven och fordonarkitekturer. Denna avhandling undersöker genomförandet av Post-build konfigurationen, ocksa kallad dynamisk konfigurationen för en förmedlingsnod ECU. För det första gers bakgrund på AUTOSAR och den nuvarande E/E arkitekturen för den ECU. De kommunikation protokoll som används förklaras. Utformningen av en potentiell lösning och dess genomförande diskuteras. Implementeringen utvärderas genom regressionstest av routingsfunktionaliteten. Behandlingstid, minneseffektivitet och skalning av lösningen beaktas också. Resultaten av konstruktionen och genomförandet om det bedömdes som lämpligt skulle kunna användas som ett springbräda för att möjliggöra postbyggnad i en befintlig förmedlingsnod arkitektur. Resultaten kan konsolidera vägen mot full överensstämmelse med AUTOSAR. / Le développement de systèmes embarqués dans l’industrie automobile a atteint un niveau de complexité très élevé. D’où la nécessité de créer de nouvelles méthodologies. AUTomotive Open Architecture (AUTOSAR) a été créé pour la mise place de standards pour le développement dans l’industrie automobile. Dans l’architecture AUTOSAR, le développement de logiciels embarqués est reparti, en général, entre trois partis : Original Equipement Manufacturer (OEM), Renault par exemple. Le deuxième niveau regroupe les fournisseurs de logiciels et outils, par exemple, Elektrobit. On retrouve en troisième position les Tier-2 suppliers, fournisseurs de cartes électroniques pour l’automobile, comme Renesas ST. Le développement de calculateurs est séparé par domaine : Multimédia, châssis, motorisation et intérieur. La communication inter-domaine passe par un calculateur passerelle. Le calculateur passerelle est essentielle dans l’architecture électronique du véhicule. Dans AUTOSAR, le calculateur est fourni par un tiers parti, différent du constructeur automobile. Il est donc nécessaire pour le constructeur d’être capable de configurer le calculateur passerelle, sans repasser par le vendeur. Par exemple, le constructeur peut décider, réception du software de rajouter une nouvelle route dans la passerelle. Cet aspect est connu sur le nom de Post-build Configuration dans AUTOSAR. Le but de ce stage est le design et l’implémentation de Post-build configuration d’un calculateur passerelle. D’abord, AUTOSAR et l’architecture électronique d’un calculateur passerelle sont détaillées. Les protocoles de communication sont aussi décrits. Ensuite, le design et les choix d’implémentation sont discutés. L’implémentation est évaluée avec des tests de régression sur les fonctionnalités de routage. Aussi, la solution finale est évaluée sur les critères de performance de routage, l’efficacité en consommation mémoire et la capacité d’être intégrée dans un produit final.

The software is a key differentiator and driver of innovation in the automotive industry. The major challenges for software development are increasing in complexity, shorter time-to-market, increase in development cost and demand of quality assurance. The complexity is increasing due to emission legislations, variants of product and new communication technologies being interfaced with the vehicle. The shorter development time is due to competition in the market, which requires faster feedback loops of verification and validation of developed functionalities. The increase in development cost is contributed by two factors; the first is pre-launch cost, this involves the cost of error correction in development stages. Another is post-launch cost; this involves warranty and guarantees cost. As the development time passes the cost of error correction also increases. Hence it is important to detect the error as early as possible. All these factors affect the software quality; there are several cases where Original Equipment Manufacturer (OEM) have callbacks their product because of the quality defect. Hence, there is increased in the requirement of software quality assurance. The solution for these software challenges can be the early quality evaluation in continuous integration framework environment. The most prominent in today\'s automotive industry AUTomotive Open System ARchitecture (AUTOSAR) reference architecture is used to describe software component and interfaces. AUTOSAR provides the standardised software component architecture elements. It was created to address the issues of growing complexity; the existing AUTOSAR environment does have software quality measures, such as schema validations and protocols for acceptance tests. However, it lacks the quality specification for non-functional qualities such as maintainability, modularity, etc. The tool is required which will evaluate the AUTOSAR based software architecture and give the objective feedback regarding quality. This thesis aims to provide the quality measurement tool, which will be used for evaluation of AUTOSAR based software architecture. The tool reads the AUTOSAR architecture information from AUTOSAR Extensible Markup Language (ARXML) file. The tool provides configuration ability, continuous evaluation and objective feedback regarding software quality characteristics. The tool was utilised on transmission control project, and results are validated by industry experts.

The rapidly evolving technologies in the automotive industry have been defining new challenges, setting new goals and consenting to more complex systems. This steered the AUTOSAR community toward the independent development of the AUTOSAR Adaptive Platform with the intention of addressing and serving the demands defined by the new technology drivers. The use of an already existing software based on an open-source development - specifically GNU/Linux - was recognized as a matching candidate fulfilling the requirements defined by AUTOSAR Adaptive Platform as its operating system. However, this raises new challenges in addressing the safety aspect and the suitability of its implementation in safety-critical environments. As safety standards do not explicitly handle the use of open-source software development, this thesis proposes a tailoring procedure that aims to match the requirements defined by ISO 26262 for a possible qualification of GNU/Linux. And while very little is known about the behavior specification of GNU/Linux to appropriate its use in safety-critical environments, the outlined methodology seeks to verify the specification requirements of GNU/Linux leveraging its claimed compliance to the POSIX standard. In order to further use GNU/Linux with high pedigree of certainty in safety-critical applications, a software partitioning mechanism is implemented to provide control over the resource consumption of the operating system –specifically computation time and memory usage- between different criticality applications in order to achieve Freedom from Interference. The implementation demonstrates the ability to avoid interference concerning required resources of safety-critical applications.

Die Möglichkeit, komplexe Applikationen für Steuergeräte zu entwerfen und zu implementieren wird durch die Systemarchitektur AUTOSAR stark vereinfacht. Ein Applikations-Entwickler implementiert nur noch die reine Funktionalität, während der Teil, der die Interaktion mit der Hardware ermöglicht, von entsprechenden Werkzeugen automatisch generiert wird. Viele Hersteller bieten hierfür Produkte, die vom grafischen Entwurf der Software bis zu finalen Tests des fertigen Steuergeräte-Codes alles abdecken. Zentrales Element ist hierbei immer die AUTOSAR-XML, welche alle Informationen zur Anwendung aufnimmt. Dadurch können verschiedene Zulieferer einzelne Module zu einer Anwendung beisteuern. Durch den technologischen Fortschritt und die Integrierbarkeit von verfügbaren Teilsystemen oder einzelnen Komponenten werden eingebettete Systeme immer komplexer ([Har02]). Daher müssen neue Spezifikationen erstellt und demzufolge neue AUTOSAR-Versionen publiziert werden. Die Hersteller müssen sich an diese neuen Vorgaben halten, um so konkurrenzfähig auf dem Markt zu bleiben ([ZS14]).