Safety has been always been an important part, irrespective of the field of work that it accounts for. The functional safety standard that is currently being used in the automotive domain is the ISO 26262. This is an adaptation of the IEC 61508 safety standard. It is directed as a basic functional safety standard for a variety of industries. The version of ISO 26262 that is used in this thesis is the final draft released in January, 2011. In this thesis, various parts of the ISO 26262 functional safety standard are considered in order to understand the differences and interdependencies between them. The parts of ISO 26262 that are treated are as follows; Part 1: Vocabulary, Part 3: Concept phase, Part 4: Product development at the system level, Part 6: Product development at the software level and Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analysis. During the entire course of this thesis the ISO 26262 standard is evaluated and the experience gained from it is jotted down. The understanding gained during this thesis about the ISO 26262 can be applied to ongoing or new development processes. As safety can never be overlooked, the wisdom that belongs to the ISO 26262 can be generously used into embedded systems that demand certain levels of safety.

The YellowCar at the professorship of computer engineering of TU Chemnitz is a demonstration vehicle. The car is equipped with multiple networked Electronic Control Unit (ECU)s. There are regular software and hardware updates. Before introduction of any new update, it is essential to test the behavior of the car. This can be done through simulation. Since the majority of the ECU in YellowCar are AUTOSAR based, several AUTOSAR simulation tools can be used to do so. However non-AUTOSAR ECU applications can still not be simulated in these tools. Moreover simulating with such tools need the whole application to be implemented and also very expensive. Simulink is one of the most powerful tools for the purpose of Model-in-the-Loop (MIL) testing which is a popular strategy in the embedded world. The scope of this Master thesis is analyzing the YellowCar and its architecture to develop a dynamic Simulink architectural model that can be modified and extended to facilitate future updates. The outcome of this thesis is an implementation of a model for the YellowCar which allows both AUTOSAR and non-AUTOSAR ECUs to be simulated as one system. Also the model supports extension by easy addition of new modules like ECU or sensor through a graphical user interface.

The vision of automated driving demands a highly available system, especially in safety-critical functionalities. In automated driving when a driver is not binding to be a part of the control loop, the system needs to be operational even after failure of a critical component until driver regain the control of vehicle. In pursuit of such a fail-operational behavior, the developed design process with software redundancy in contrast to conventional dedicated backup requires the support of automatic configurator for scheduling relevant parameters to ensure real-time behavior of the system. Multiple implementation methods are introduced to provide an automatic service which also considers task criticality before assigning task to the processor. Also, a generic method is developed to generate adaptation plans automatically for an already monitoring and reconfiguration service to handle fault occurring environment.

Durch die Einführung der Systemarchitektur AUTOSAR im automobilen Umfeld, können Applikationen unabhängig von der verwendeten Hardware oder der genutzten Kommunikationssysteme entwickelt werden. Dadurch können Funktionen wieder verwendet werden, was Zeit und Ressourcen einsparen kann. So können Funktionen, die sich etabliert haben, in späteren Entwicklungen durch Anpassung in der Konfiguration genutzt werden ohne dabei den Quellcode zu ändern. Jedoch stellt die große Zahl an Parametern in der AUTOSAR Architektur große Herausforderungen an die Absicherung eines Steuergerätes. Dieser Aspekt wird durch eine meist heterogene Toollandschaft verstärkt. Umso wichtiger ist es, dass während der Entwicklung von AUTOSAR Steuergeräten statische Analysen die Software und die Konfiguration überprüfen, um so die Softwarequalität sicherstellen zu können. In der Masterarbeit werden eine Menge von AUTOSAR spezifischen statischen Analysen für die einzelnen Schichten eines AUTOSAR Steuergerätes entwickelt. Für die Analyse werden Einstellungsdateien (nach Standard und Firmenspezifische) und der Quellcode an sich genutzt. Die Analysen geben optional Korrekturvorschläge an den Entwickler. Die Umsetzung erfolgt in einem C# Prototyp und wird an der Lichtsteuerung des Automotive Demonstrator YellowCar angewendet werden.

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 okat i fordonsindustrin. Utvecklingen av dessa inbyggda programvara har varit komplex och ar inte genomforbar per ett enhet. Idag ar utvecklingen gjort av tre foretag: en OEM (Original Equipement Manufacturer), Tier-1 leverantorer som tillhandahaller mjukvara till OEMs, Tier-2 leverantorer som tillhandahaller 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.

<p>The car industry has created a series of standards called AutoSAR as a response to the increasing number of processors in modern vehicles. Among these specifications is one for real-time operating systems (RTOS). This RTOS standard includes requirements for memory protection. This thesis outlines the work involved in introducing the memory protection outlined in this specification in the OSEck operating system. The work consisted of updating the operating system, implementing the AutoSAR OS API, and updating the suite of toolsused to build the finished system.The AutoSAR specifications were found to be very thorough and well thoughtout. The OS API was successfully implemented, and the data-structures needed to permit its functionality. The existing software tools were updated to conformwith the new requirements from AutoSAR, and additional software was createdto ease the configuration process.Memory protection was successfully implemented in the OSEck operating system, including two implementations of the trap interface. The memory protection functionality adds yet another layer of user-configuration to the operating system. Also, additional overhead for system calls, context switches and message passing is expected. A general evaluation of how OSEck application performance is aff ected is beyond the scope of this thesis, but preliminary studies of additional instruction counts on certain system calls have been performed.</p>

In an automotive context today’s need of testing functions while in factory, correcting faults in the workshop or adding extra value in the aftermarket makes it very important to easily be able to download new software to the electronic control units in vehicles. In the platform for standard automotive software development called AUTOSAR, two known protocols are presented to specify the procedure on how to implement this download operation: Unified Diagnostic Services (UDS) and the Universal Measurement and Calibration Protocol (XCP). However the part of the UDS and XCP standards that is about reprogramming is not completely a part of the AUTOSAR standard yet. In this thesis, UDS and XCP have been compared to evaluate which of the two that has most support in AUTOSAR today and are most likely to be fully integrated into AUTOSAR in the future. Since UDS already has support in AUTOSAR for some of the functions needed for reprogramming and because of the fact that UDS is a part of the extensively used On-board Diagnostic standard (OBD-II), UDS is chosen to be the most suitable protocol for implementing reprogramming functionality according to AUTOSAR. A bootloader with the ability to download data has been developed using only relevant functions from UDS and following the AUTOSAR specifications where it is applicable. / För att kunna testa fordonsfunktioner i fabriken, åtgärda mjukvarufel under service eller för att uppgradera fordonet med nya funktioner är det viktigt att kunna ladda ner ny mjukvara till fordonets styrsystem. Den standardiserade mjukvaruplattformen för fordonsindustrin, AUTOSAR, innehåller två protokoll som båda specificerar hur mjukvara kan laddas ner: Unified Diagnostic Services (UDS) och Universal Measurement and Calibration Protocol (XCP). Tyvärr är de delarna av UDS och XCP som beskriver mjukvarunerladdning inte en del av AUTOSAR än. I det här examensarbetet har UDS och XCP jämförts för att utvärdera vilken av de båda som i dagsläget har störst stöd för nerladdning av mjukvara i AUTOSAR och vilken som troligast kommer att bli en del av AUTOSAR i framtiden. Eftersom AUTOSAR redan stödjer några av de funktioner i UDS som behövs för nerladdning av mjukvara samt på grund av att UDS är en del av branschstandarden för fordonsdiagnostik OBD-II, har UDS valts som den mest lämpade att i dagsläget användas för att implementera nerladdning av mjukvara enligt AUTOSAR. En bootloader som stödjer nerladdning av mjukvara via UDS har sedan implementerats enligt AUTOSAR-specifikationen så långt som möjligt.

The car industry has created a series of standards called AutoSAR as a response to the increasing number of processors in modern vehicles. Among these specifications is one for real-time operating systems (RTOS). This RTOS standard includes requirements for memory protection. This thesis outlines the work involved in introducing the memory protection outlined in this specification in the OSEck operating system. The work consisted of updating the operating system, implementing the AutoSAR OS API, and updating the suite of toolsused to build the finished system.The AutoSAR specifications were found to be very thorough and well thoughtout. The OS API was successfully implemented, and the data-structures needed to permit its functionality. The existing software tools were updated to conformwith the new requirements from AutoSAR, and additional software was createdto ease the configuration process.Memory protection was successfully implemented in the OSEck operating system, including two implementations of the trap interface. The memory protection functionality adds yet another layer of user-configuration to the operating system. Also, additional overhead for system calls, context switches and message passing is expected. A general evaluation of how OSEck application performance is aff ected is beyond the scope of this thesis, but preliminary studies of additional instruction counts on certain system calls have been performed.

The aim of this thesis is to build a framework based on the CAN bus and to create the auto-run scripts followed by the AUTOSAR Acceptance Test for Arctic Core and Arctic Studio, the products from ARCCORE AB. Subsequent to this, the UART driver between the test bench and the application layer has been implemented. In total, 11 test cases are configured with the application layer, the run time environment (RTE) layer and the basic software (BSW) layer. Thus, the test bench of each test case is also implemented. The result shows that 82.7% test cases are passed and the CANTP module and the LDCOM module are found not supported in the Arctic studio.

This paper presents the structure and basic elements of the Autosar software architecture. In addition, the configuration code generation options are presented for both MC-ISAR drivers and AURIX TriCore TC277 hardware modules using EB tresos Studio. For the purpose of possible integration of the electric motor control algorithms, configurations of the GTM and VADC hardware modules have been created and described to enable the generation of PWM signals along with synchronously triggered parallel analogue-to-digital conversions. For this purpose, an application interface including the PWM driver was also developed and described.