No description available.

No description available.

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]).

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.

Automotive Ethernet is a newly introduced in-vehicle bus that allows unicast communication between ECUs. It is based on the OSI model of Ethernet, with a few modifications on the physical layer and newly introduced application protocols. AUTOSAR, a consortium of automotive OEMs, Tier-1 suppliers and tool vendors has defined a standard software architecture that simplifies the ECU software development with its well defined software specifications and APIs. The Automotive Ethernet stack is now an integral part of the latest AUTOSAR specification release 4.2. Infineon Aurix TriCore TC27x microcontroller is a popular board used in ADAS applications. The board has support for Fast Ethernet. This thesis investigates the setting up of an Ethernet communication on the TriCore board running under AUTOSAR software architecture. The various modules of the AUTOSAR Ethernet stack are familiarized and configured. This is followed up by validating the implementation on the Ethernet physical layer. The validation is based on a real Ethernet communication between the TriCore board and the Vector VN5610 network interface card. TCP and UDP based connections between the AUTOSAR compliant board and the VN5610 are tested and validated. A test suite for evaluating the protocol conformance of the AUTOSAR Ethernet stack exists at Bertrandt. The final step of this thesis involved the execution strategies for this test suite.

Examensarbetet syftar till att undersöka möjligheten att expandera befintlig testprocess av elektroniska styrenheter. Hos Volvo Construction Equipment sker verifiering av styrenheter till stor del i riggar som består av större CAN-nätverk och innehåller många komponenter. Antalet riggar begränsas av att de är kostsamma, vilket i sin tur leder till att antalet tester som kan genomföras är begränsat. Målet med arbetet är att undersöka om det är möjligt att skapa en testmiljö som verifierar funktionalitet i en styrenhet, separerad från övriga delar av nätverket. Planen är att testmiljön ska kunna användas som komplement till de befintliga riggarna. Arbetet visar att det är möjligt genom att implementera en testmiljö som kan verifiera funktionalitet hos en separerad styrenhet. Testmiljön ger Volvo möjlighet att utföra fler tester och därmed expandera deras testprocess av elektroniska styrenheter. / The thesis aims to examine the possibility of expanding the existing test process of Electronic Control Units. At Volvo Construction Equipment, verification of control units is mostly done in rigs that include large CAN-networks and contains multiple components. The number of rigs available is limited by their cost, which leads to a limited number of tests that can be made. The thesis is investigating whether it is possible to create a test environment that verifies functionality of an Electronic Control Unit, separated from the network. The purpose of the test environment is to be used as a complement to the existing rigs. The thesis shows that it is possible by implementing a test environment that can verify functionality of a separated control unit. This test environment allows Volvo to perform more tests and thereby expand their test process of Electronic Control Units.

Vortrag gehalten am 4. Juni 1988 an der Universität Würzburg anläßlich der Exkursion des Aufbaustudienganges "Europäische Integration" des Europa-Instituts der Universität des Saarlandes Lange vor Einführung des Euro ließ die Bundesbank die private Verwendung der Europäischen Währungseinheit (ECU) in Deutschland zu. Der Beitrag zeichnet die Schaffung und Bedeutung des ECU seit 1979 nach, einschließlich der Unterscheidung von offizieller und privater Verwendung, und benennt einige offene Rechtsfragen im Hinblick auf das Währungsrecht der DM.

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 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.

Neste trabalho são apresentados os resultados obtidos no desenvolvimento de uma unidade de controle para motores de combustão interna (UCM). A unidade foi desenvolvida com o intuito de facilitar os estudos de motores, por ser um sistema flexível e acessível. Para cálculos de rotinas de controle e acionamento de atuadores são utilizados, respectivamente, um microcontrolador e um FPGA, sendo que ambos são componentes de fácil obtenção e utilizados em placas de prototipagem encontradas no mercado (Arduino Due e Xula 2). O uso de um FPGA para executar o comando de atuadores se deve à alta velocidade de processamento, processamento paralelo e grande quantidade de portas digitais disponíveis, o que permite facilidade na expansão do sistema para comandos de múltiplos atuadores e o sincronismo desses com o sistema mecânico. O microcontrolador fica encarregado de executar as rotinas de cálculos que não exigem exato sincronismo, como rotinas de controle e comunicação com periféricos. A planta escolhida para ensaios da UCM é um motor ciclo Otto a álcool de 4 cilindros e 1.6 litros, com injeção multiponto. Ensaios foram realizados com o protótipo final e englobaram somente o controle do sistema de ignição do motor devido à facilidade de controle utilizando-se somente um parâmetro de entrada (velocidade) e devido ao controle de quantidade de combustível ser similar e utilizar as mesmas partes de código que o sistema de ignição. / In this work is presented the development of a flexible and accessible engine control unit for research purposes. For the calculations of the control routines and to drive the actuators synchronously, are used respectively, a microcontroller and an FPGA. The integrated circuits selected are easily accessible and are used in common prototyping boards found on the market (Arduino Due and Xula 2). The use of an FPGA to control the activation of the actuators is due the high speed, parallel processing and the large number of IOs, which allows the easy expansion of the system to drive more actuators, synchronized or not, with the mechanical system. The microcontroller calculates the routines that dont need an exact synchronism of the electronic system with the mechanical system, like control routines and communication tasks. The selected mechanical system for tests is a 1.6 Liter Otto engine with multipoint fuel injection and is powered with ethanol. Tests were conducted using the final board prototype only for the ignition system, because of the easy of control using a few parameters, and because ignition FPGAs code is almost the same used to drive fuel injection actuators.