<p>Since the incorporation of electronic controls into automobiles in the 1970s, the complexity of automotive software has steadily increased. Recent cars and trucks have more electronics and lines of code than modern aircraft. This complexity has made the commoditization of the software exceptionally challenging. The AUTomotive Open System ARchitecture (AUTOSAR) standard was created to enable original equipment manufacturers (OEMs), Tier 1 and Tier 2 Suppliers, Vendors, and other players in automotive software to freely buy, sell, and integrate software components for automotive applications. AUTOSAR does this through a standardized set of software interfaces and a methodology for enabling software exchange, allowing software tools to interoperate. This study explored how AUTOSAR practitioners go about the business of conducting the methodology and its perceived benefits and problems. A global survey of AUTOSAR practitioners was conducted to collect company and respondent demographic information and details concerning specific practices. The survey results indicated practitioners believe AUTOSAR was good at abstracting hardware from the software and between the software components. Respondents also indicated that the AUTOSAR methodology was complicated and not sufficiently prescriptive, leading to inconsistent interpretation and application. Based on the survey results, it was concluded that more work is needed to provide more decisive clarity and direction for AUTOSAR practitioners.</p>

The evolving of the networking application and electronic components are pushing the bandwidth limits in the automotive domain [19]. Consequently, the car manufacturers have begun to produce more complex Electronic Control Units (ECUs) to fulfil the automotive technology evolution. Car manufacturers have used ECUs from different vendors to get the most creative features in cars [19]. These ECUs requires a standard network interface such as Ethernet which can bring significant features such as high bandwidth, low weight and full duplex communication. Nowadays, Ethernet has adapted to apply in the automotive application. Therefore, it has called for a high degree of testing to ensure the safety and interoperability between these ECUs. However, the testing of the Automotive Ethernet is facing many challenges such as finding and solving the issues as early as possible in the development process. Besides that, testing an Automotive Ethernet TCP/IP stack is a complex task, as it required an upper tester to cause the implementation of the device under the test to move to specific states. AUTOSAR has defined a standardised control protocol (Test Stub) to use it as an upper tester for executing the AUTOSAR Acceptance Test (for TCP/IP stack) [6]. This protocol has used for conducting the test cases of the TCP, UDP and IP protocols in AUTOSAR [21] [22] [23]. OPEN Alliance has specified an Automotive Ethernet ECU test specification which covers more protocols than AUTOSAR such as ARP and DHCP [7]. Consequently, potential gaps and issues may arise when using the Test Stub to conduct the test cases of the OPEN Alliance, as it initially defined for conducting the AUTOSAR Acceptance Test. This work presents the evaluation of the Test Stub in context of using it to conduct the OPEN Alliance Automotive Ethernet ECU Test. Furthermore, it will introduce a solution to overcome the potential issues and gaps which may arise after using the Test Stub (defined by AUTOSAR) to conduct the test cases of the OPEN Alliance.

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.

Classic AUTOSAR provides a standardized architecture and guidelines for automotive development. However, it does not include specifications for securing Ethernet communication. The IEEE 802.1AE standard specifies a security standard called Media Access Control Security (MACsec) to protect Ethernet communication. MACsec protected communication requires key agreement between the network peers. IEEE has also standardized this as MACsec Key Agreement (MKA) protocol specified in the 802.1X-2020 standard. This thesis determines the feasibility of incorporating the MKA protocol and MACsec standard in Classic AUTOSAR. For this purpose, we designed and implemented a proof of concept (PoC), having an evaluation board running Classic AUTOSAR communicating via Ethernet with a virtual machine. Classic AUTOSAR has a layered architecture. The PoC developed in this thesis introduces a services module in its basic software layer, which performs MKA protocol and provides MACsec protection. It interacts with the Ethernet interface in the hardware abstraction layer and with the cryptographic service manager (CSM) in the services layer. Furthermore, this thesis evaluates the results to determine that the PoC meets the security requirements and does not violate the Classic AUTOSAR specifications. Based on the design and implementation of this proof of concept, we conclude that it is feasible to incorporate the MKA protocol and MACsec standard in Classic AUTOSAR. This work also mentions the limitations of the PoC and future work required to achieve the goal of having MKA protocol and MACsec standard as a part of Classic AUTOSAR specification. / Classic AUTOSAR tillhandahåller en standardiserad arkitektur och riktlinjer för fordonsutveckling. Den innehåller dock inga specifikationer för att säkra Ethernet-kommunikation. IEEE 802.1AE-standarden specificerar en säkerhetsstandard som kallas Media Access Control Security (MACsec) för att skydda Ethernet-kommunikation. MACsec-skyddad kommunikation kräver nyckelöverenskommelser mellan nätverkskollegorna. IEEE har också standardiserat detta som MACsec Key Agreement (MKA)-protokoll specificerat i 802.1X-2020-standarden. Denna avhandling bestämmer möjligheten att införliva MKA-protokollet och MACsec-standarden i Classic AUTOSAR. För detta ändamål designade och implementerade vi ett proof of concept (PoC), med ett utvärderingskort som kör Classic AUTOSAR som kommunicerar via Ethernet med en virtuell maskin. Classic AUTOSAR har en skiktad arkitektur. PoC som utvecklats i denna avhandling introducerar en tjänstemodul i sitt grundläggande mjukvarulager, som utför MKA-protokoll och ger MACsec-skydd. Den interagerar med Ethernet-gränssnittet i hårdvaruabstraktionslagret och med den kryptografiska tjänstehanteraren (CSM) i tjänsteskiktet. Dessutom utvärderar denna avhandling resultaten för att fastställa att PoC uppfyller säkerhetskraven och inte bryter mot Classic AUTOSAR-specifikationerna. Baserat på designen och implementeringen av detta proof of concept drar vi slutsatsen att det är möjligt att införliva MKA-protokollet och MACsec-standarden i Classic AUTOSAR. Detta arbete nämner också begränsningarna för PoC och framtida arbete som krävs för att uppnå målet att ha MKA-protokoll och MACsec-standard som en del av Classic AUTOSAR-specifikationen.

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.

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.

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.

During the overall development of complex engineering systems different modeling notations are employed. For example, in the domain of automotive systems system engineering models are employed quite early to capture the requirements and basic structuring of the entire system, while software engineering models are used later on to describe the concrete software architecture. Each model helps in addressing the specific design issue with appropriate notations and at a suitable level of abstraction. However, when we step forward from system design to the software design, the engineers have to ensure that all decisions captured in the system design model are correctly transferred to the software engineering model. Even worse, when changes occur later on in either model, today the consistency has to be reestablished in a cumbersome manual step. In this report, we present in an extended version of [Holger Giese, Stefan Neumann, and Stephan Hildebrandt. Model Synchronization at Work: Keeping SysML and AUTOSAR Models Consistent. In Gregor Engels, Claus Lewerentz, Wilhelm Schäfer, Andy Schürr, and B. Westfechtel, editors, Graph Transformations and Model Driven Enginering - Essays Dedicated to Manfred Nagl on the Occasion of his 65th Birthday, volume 5765 of Lecture Notes in Computer Science, pages 555–579. Springer Berlin / Heidelberg, 2010.] how model synchronization and consistency rules can be applied to automate this task and ensure that the different models are kept consistent. We also introduce a general approach for model synchronization. Besides synchronization, the approach consists of tool adapters as well as consistency rules covering the overlap between the synchronized parts of a model and the rest. We present the model synchronization algorithm based on triple graph grammars in detail and further exemplify the general approach by means of a model synchronization solution between system engineering models in SysML and software engineering models in AUTOSAR which has been developed for an industrial partner. In the appendix as extension to [19] the meta-models and all TGG rules for the SysML to AUTOSAR model synchronization are documented. / Bei der Entwicklung komplexer technischer Systeme werden verschiedene Modellierungssprachen verwendet. Zum Beispiel werden bei der Entwicklung von Systemen in der Automobilindustrie bereits früh im Entwicklungsprozess Systemmodelle verwendet, um die Anforderungen und die grobe Struktur des Gesamtsystems darzustellen. Später werden Softwaremodelle verwendet, um die konkrete Softwarearchitektur zu modellieren. Jedes Modell stellt spezifische Entwurfsaspekte mit Hilfe passender Notationen auf einem angemessenen Abstraktionsniveau dar. Wenn jedoch vom Systementwurf zum Softwareentwurf übergegangen wird, müssen die Entwicklungsingenieure sicherstellen, dass alle Entwurfsentscheidungen, die im Systemmodell enthalten sind, korrekt auf das Softwaremodell übertragen werden. Sobald danach auch noch Änderungen auftreten, muss die Konsistenz zwischen den Modellen in einem aufwändigen manuellen Schritt wiederhergestellt werden. In diesem Bericht zeigen wir, wie Modellsynchronisation und Konsistenzregeln zur Automatisierung dieses Arbeitsschrittes verwendet und die Konsistenz zwischen den Modellen sichergestellt werden können. Außerdem stellen wir einen allgemeinen Ansatz zur Modellsynchronisation vor. Neben der reinen Synchronisation umfasst unsere Lösung weiterhin Tool-Adapter, sowie Konsistenzregeln, die sowohl die Teile der Modelle abdecken, die synchronisiert werden können, als auch die restlichen Teile. Der Modellsynchronisationsalgorithmus basiert auf Tripel-Graph-Grammatiken und wird im Detail erläutert. An Hand einer konkreten Transformation zwischen SysML- und AUTOSAR-Modellen, die im Rahmen eines Industrieprojektes entwickelt wurde, wird der Ansatz demonstriert. Im Anhang des Berichts sind alle TGG-Regeln für die SysML-zu-AUTOSAR-Transformation dokumentiert.

Der stetig steigende Funktionsumfang im Automobil und die zunehmende Vernetzung von Steuergeräten erfordern neue Methoden zur Beherrschung der Komplexität in der Validierung und Verifikation. Die virtuelle Absicherung ermöglicht die Integration der Software in einem PC-System, unabhängig von der Ziel-Hardware, zur frühzeitigen Gewährleistung der Softwarequalität im Entwicklungsprozess. Ebenso kann die Wiederverwendbarkeit vorhandener Komponenten in zukünftigen Mikrocontrollern sichergestellt werden. Die Grundlage dafür liefert der AUTOSAR-Standard durch einheitliche Schnittstellenbeschreibungen, welche die Abstraktion von Hardware und Software ermöglichen. Allerdings enthält der Standard hardwareabhängige Software-Komponenten, die als Complex-Device-Drivers (CDDs) bezeichnet werden. Aufgrund ihrer Hardwareabhängigkeit sind CDDs nicht direkt in eine virtuelle Absicherungsplattform integrierbar, da die spezifischen Hardware-Module nicht verfügbar sind. Die Treiber sind dennoch Teil der Steuergeräte-Software und somit bei einem ganzheitlichen Absicherungsansatz mit zu betrachten. Diese Dissertation beschreibt sieben unterschiedliche Konzepte zur Berücksichtigung von CDDs in der virtuellen Absicherung. Aus der Evaluierung der Praxistauglichkeit aller Ansätze wird eine Auswahlmethodik für die optimale Lösung bei sämtlichen Anwendungsfällen von CDDs in der Steuergeräte-Software entwickelt. Daraus abgeleitet, eignen sich zwei der Konzepte für die häufigsten Anwendungsfälle, die im Weiteren detailliert beschrieben und realisiert werden. Das erste Konzept erlaubt die vollständige Simulation eines CDD. Dies ist notwendig, um die Integration der Funktions-Software selbst ohne den Treiber zu ermöglichen und alle Schnittstellen abzusichern, auch wenn der CDD noch nicht verfügbar ist. Durch eine vollständige Automatisierung ist die Erstellung der Simulation nur mit geringem Arbeitsaufwand verbunden. Das zweite Konzept ermöglicht die vollständige Integration eines CDD, wobei die Hardware-Schnittstellen über einen zusätzlichen Hardware-Abstraction-Layer an die verfügbare Hardware des Systems zur virtuellen Absicherung angebunden werden. So ist der Treiber in der Lage, reale Hardware-Komponenten anzusteuern und kann funktional abgesichert werden. Eine flexible Konfiguration der Abstraktionsschicht erlaubt den Einsatz für eine große Bandbreite von CDDs. Im Rahmen der Arbeit werden beide Konzepte anhand von industrierelevanten Projekten aus der Serienentwicklung erprobt und detailliert evaluiert. / The constantly increasing amount of functions in modern automobiles and the growing degree of cross-linking between electronic control units (ECU) require new methods to master the complexity in the validation and verification process. The virtual validation and verification enables the integration of the software on a PC system, which is independent from the target hardware, to guarantee the required software quality in the early development stages. Furthermore, the software reuse in future microcontrollers can be verified. All this is enabled by the AUTOSAR standard which provides consistent interface descriptions to allow the abstraction of hardware and software. However, the standard contains hardware-dependent components, called complex device drivers (CDD). Those CDDs cannot be directly integrated into a platform for virtual verification, because they require a specific hardware which is not generally available on such a platform. Regardless, CDDs are an essential part of the ECU software and therefore need to be considered in an holistic approach for validation and verification. This thesis describes seven different concepts to include CDDs in the virtual verification process. A method to always choose the optimal solution for all use cases of CDDs in ECU software is developed using an evaluation of the suitably for daily use of all concepts. As a result from this method, the two concepts suited for the most frequent use cases are detailed and developed as prototypes in this thesis. The first concept enables the full simulation of a CDD. This is necessary to allow the integration of the functional software itself without the driver. This way all interfaces can be tested even if the CDD is not available. The complete automation of the generation of the simulation makes the process very efficient. With the second concept a CDD can be entirely integrated into a platform for virtual verification, using an hardware abstraction layer to connect the hardware interfaces to the available hardware of the platform. This way, the driver is able to control real hardware components and can be tested completely. A flexible configuration of the abstraction layer allows the application of the concept for a wide variety of CDDs. In this thesis both concepts are tested and evaluated using genuine projects from series development.