Entwicklung eines auf OSEK basierenden Kfz-Steuergerätes

Für einen Automobilzulieferer wurde ein OSEK-Standardcore für ein Steuergerät im Automobil angepasst. Neben der Parametrierung des Betriebssystems wurde ein Hardwarelayer als Schnittstelle zwischen Controller-Peripherie (z.B. AD-Wandler) sowie externen Bausteinen (z.B. Seriell-Parallel Wandler) zur Applikationssoftware implementiert. Mit der Zielsetzung maximal möglicher Software-Wiederverwendung erfolgt die Integration von bereits vorhandenen Applikationen wie z.B. Leuchtweitenregulierung in das Softwarepaket. Anschließend wurde eine Überarbeitung der Applikationen entsprechend den veränderten Anforderungen des Kfz-Herstellers durchgeführt.
Kfz-Steuergerät
Hardware Controller STMicroelectronics ST10F269
low-power Controller Atmel M44C092 (Marc4)
serielles EEPROM Microchip 93C76
Schrittmotortreiber STMicroelectronics L9935
Leistungstreiber Infineon BTS
Seriell-Parallel Wandler
Sprachen C und qForth
Umgebung Tasking C166/ST10 V7.5
3Soft OSEK V3.0
GNU Make V3.75
Software Vector CANoe 3.x
Tasking IDE V2.7
PVCS V6.x
ChangeSynergy V4.1
Debugger ISystems WinIDEA V9.1
Lauterbach Trace 32
Dauer 11 Monate

Automotive Standardsoftware

Unterschiedliche, hardwarenahe Softwaremodule in Kfz-Steuergeräten wie z.B. PWM, PWD, Schieberegister-Treiber wurden an zentraler Stelle entwickelt, getestet und auf neue Controller portiert. Die Produktlinien des Kfz-Zulieferers erhalten dadurch die Möglichkeit sich vermehrt auf die eigentliche Funktionsentwicklung zu konzentrieren. Für die entwickelten Treiber werden alle Schritte des Entwicklungsprozesses von Anforderungsaufnahme, Analyse, Design, Codierung, Unit- und Modultest entsprechend des V-Modells umgesetzt.
Standardsoftware
Hardware NEC V850
Sprachen C und Assembler
Umgebung MID Innovator SA, SD V 8.0
Greenhills Multi 2000 V 3.5.1.
Software Telelogic Doors V 7.0
MKS Source Integrity V 8.4
QA-C V 5.0
Doxygen V 1.3.5
Razorcat Tessy V2.2.9 und CTE V2.3.16
Debugger NEC IE-V850E1-CD-NW PCMCIA OnChip Emulator
Dauer 9 Monate

Programmierung eines Windows Simulators für CAN-Mikrocontroller

Für einen CAN-Mikrocontroller war ein taktgenauer Kommando- und Peripherie-Simulator zu erweitern. Das Projekt beinhaltete alle Software-Entwicklungsphasen von Spezifikation, Entwicklung, Integration, Tests sowie Dokumentation und Freigabe. Um eine realitätsnahe Simulation des CAN-Anteils im Mikrocontroller durchführen zu können, ist die Simulation von CAN-Daten anderer CAN-Knoten unerlässlich. Außerdem war die Analyse der bis zu 128 Bit langen CAN-Nachrichten auf einer möglichst hohen Abstraktionsebene darzustellen. Beiden Anforderungen wurde durch die Einbindung eines weit verbreiteten CAN-Simulators in den Chip-Simulator mittels DLL-Schnittstelle Rechnung getragen. Die taktflankengenaue Simulation der CAN-Peripherie auf dem Chip wurde mit API-C in Form einer State Machine für die CAN-Logik in den Chip-Simulator integriert.
CAN Simulator
Details Simulator CAN-Bus für NEC K0-Bausteine
DLL zwischen Windows Anwendungen
Vektor CANalyzer + CANoe V2.x
Sprachen C (API-Programmierung)
Umgebung Microsoft C V1.51, V5.x + V6.x
OS Microsoft Windows 95, 98, NT4, 2000
Dauer 12 Monate

Entwicklung eines CANopen-Systems für Sonderfahrzeuge

Ein mit 8051 Controller ausgestattetes Steuer- und Bedienpanel für Sonderfahrzeuge war auf den 16-Bit Fujitsu Prozessor MB90F497 umzustellen. Außerdem sollte eine Umstellung der bisher verwendeten seriellen Protokolle mit externen Geräten auf CANopen vorbereitet werden. Um den Integrationstest zu vereinfachen, sollte bei der Umsetzung möglichst wenig Änderungen an Hard- und Software des Bedienpanels durchgeführt werden. Unter Ausnutzung der erhöhten Leistungsmerkmale des 16 Bit Controllers (wie z.B. interner AD-Wandler) wurde ein Prototyp mit minimalen Hardware-Änderungen entworfen. Der funktionale Ablauf der ursprünglichen 8 Bit Software wurde unverändert beibehalten. Im Hinblick auf den späteren Austausch der seriellen Kommunikation durch CANopen wurde die Software jedoch in einem zweiten Schritt noch stärker modularisiert. Nach erfolgreichem Test beim Endkunden erfolgte die Integration des Vector CANopen Protokoll-Stack in die Software und wurde das Kundenpersonal in die neue Software eingearbeitet.
CANopen-System
Hardware Prozessor Philips 89C52RC, Fujitsu 16LX MB90F497
Parallel-Seriell Wandler 74HC165 und MIC5841
EEPROM 93LC561SN
LCD-Controller 7225G
RS485 Umsetzer
Sprachen C
Umgebung Softtune 3.1 und 3.3
Software Vector CANopen Slave und Minimaster V4.0
Debugger Fujitsu MB2140 und MB2142-03
Dauer 2,5 Monate