• Aurix TC367, NXP NJA38-Phantom
• Autosar mit Dual-Core-Controller
• DMA-gestützter Treiber für NJA38, Com-Handler
• Treiber/Handler für RealTimeClock via I2C
• NVM-Manager für einen der Cores
• Bootloader für Java-Applets auf dem NJA38

Keyless-Go, Keyless-Entry, Schlüsselortung über LF- und HF-Funkstrecke  in Kooperation zunächst mit Hella, später mit Continental

• Freescale PowerPc MCP5646, Renesas RH850 F1M
• Autosar an verteilten Standorten
• Treiber für kundenspezifische Asics für HF- und LF- Funkstrecke mit harten Echtzeit-Anforderungen (CDDs)
• Kryptologie für Protokoll vom/zum Schlüssel
• System-Konfiguration: Interrupts, Peripherie, NVM, Ressourcen-Verbrauch etc.
• Zentrales Interface-Modul zwischen den Entwicklungs-Partnern
• Misra-konformer C-Code, teilweise ASIL-B

Entwicklung eines neuartigen Steuergerätes zur aktiven Motorlagerung

• Freescale PowerPc MCP5668, DualCore
• Autosar-OS
• UDS-Diagnose
• CAN (Vector-Treiber)
• VW/Audi Standard-Software (ISO-TP, UDS, SDS, DEH)
• XCP über CAN und Ethernet
• Flash-Bootloader
• Bootloader-Updater
• Flash-Emulated Eeprom (NV-RAM-Manager)
• AD-, DA- Wandlung sowie Signal-Verarbeitung on-chip
• Vorwiegend C aus Performance-Gründen, C++ in unkritischen Modulen, Misra-geprüft mit PC-Lint

Haupt-Schwierigkeiten:

• Bootloader
  • soll möglichst wenig Ressourcen belegen, dabei schnell und sicher arbeiten
  • mit geänderten Configuration-Fuses zurechtkommen
  • Host-Seite des Bootloaders wird ebenfalls benötigt (Windows, Visual C++)
• Flash-Emulated-Eeprom
  • mit 32kB steht nur wenig Flash zur Verfügung, eine Flash-Page belegt 1,5kB
  • ?die Emulation muss mit 2 Pages auskommen

• Bestehenden MOST-Verstärker erweitern um eine zusätzliche CAN-Schnittstelle zur zusätzlichen Erfassung von Motor-Management-Daten
• Daten auf Konsistenz prüfen, umformatieren und an DSP übertragen für zusätzliche Audio-Features
• Sehr hohe zeitliche Anforderungen: Latenzzeit zwischen eingehenden CAN-Daten und Verfügbarkeit der Daten im DSP muss minimal sein.
• ST10F276 (832k/68k), DSP 21365, 2 Codecs, Analoge + Digitale PowerAmps
• Firmware unter OSEK, BMW-Standard-Core, MOST NetServices, CAN

Haupt-Schwierigkeiten.

• Der neue CAN-Kanal darf die bestehende Software zeitlich nur minimal belasten. Die neu an den DSP zu übertragenden Daten sollten möglichst in bereits bestehende Übertragungen integriert werden, um auch hier den Zeitlichen Zusatzaufwand minimal zu halten.

Verlauf:

• Nachdem ein Prototyp erstellt war, wurde das Projekt wegen der aufkommenden finanziellen Schwierigkeiten vom Endkunden gestoppt.

• LenksäulenModul mit Lenkwinkel- und Lenk-Geschwindigkeits-Sensor
• 2-Prozessor-System mit gegenseitiger Überwachung
• KWP2000 ? Diagnose für Audi
• UDS-Diagnose für VW
• Star12
• Firmware unter OSEK mit 2 x CAN, TP2.0, KPW2000 bzw. UDS
• Bootloader, Flash-Emulated-Eeprom

Haupt-Schwierigkeiten:

• Sehr hohe Sicherheits-Anforderungen, hohe Varianten-Vielfalt

• Adaption bestehender Software-Komponenten an die Gegebenheiten der Sensorik und Aktorik in den anvisierten Ziel-Fahrzeugen
• K-Line ? Diagnose
• Star12, Firmware unter OSEK mit CAN

Haupt-Schwierigkeiten:

• Hohe Sicherheits-Anforderungen, durch starken Preisdruck reduzierte Sensorik-Inputs, dadurch erhöhte Anforderungen an Software-Algorithmen

• Autoren der Software sind nicht mehr verfügbar. Trotz mangelhafter Dokumentation und nicht-vertrautem Assembler-Dialekt (ST6) soll die Ursache des Fehlverhaltens gefunden und behoben werden. Hoher Zeitdruck, da sich die Komponente bereits in der Massenfertigung befindet.
• ST6 Assembler, kaum dokumentiert, LIN

Haupt-Schwierigkeiten:

• Analyse der schlecht-dokumentierten Assembler-Software
• Test-Aufbau mit Emulator, Programmer
• Identifikation der problematischen Stellen, anschl. Fehlerbehebung

• 10-Kanal-Verstärker als Audio-Schaltzentrale des Premium-Infotainment-Systems
• Zusammenarbeit auf akustischem Gebiet mit B&O.
• Erweiterte Palette von Audio-Features: Verzerrungserfassung und -Begrenzung, Kompressor Virtualizer (7.1), Laufzeit- und Phasen- Korrekturstufen Fahrzeug-spezifischer Equalizer, Geräusch-Maskierung
• ST10F276 (832k/68k), DSP 21365, 2 Codecs, Analoge + Digitale PowerAmps
• Firmware unter OSEK, TP2.0, KPW2000, MOST NetServices optionale CAN-Variante
• Extensive Fremd- und Eigen- Diagnose-Anforderungen
• Firmware-Update für Applikation, Bootloader, DSP und Tuning-Daten

Haupt-Schwierigkeiten:

• Komplexes Gesamtsystem, hohe zeitliche Anforderungen des MOST-Systems, Aufwändige Versorgung des DSP mit Koeffizienten, Unterdrückung jeglicher Störgeräusche bei allen Einsatz-Bedingungen Sicherheit bei Updates, Erfüllung der Produktions-Anforderungen Zufriedenstellung der (nicht selten unrealistischen) Kunden-Erwartungen 

FIRMWARE-ENTWICKLUNG BLDC-ANTRIEBE FÜR AKTIV-LENKUNG (BOSCH / BMW) UND ELEKTROHYDRAULISCHE KUPPLUNG (FTE)

• Entwicklung eines BLDC-Antriebs nach Vorgaben, die zusammen mit dem Kunden auszuarbeiten sind. Einsatz eines DSP bzw. eines Hybrid-Controllers (µC + DSP) MSP56F83xx, Ausnutzung aller On-chip-Ressourcen zur Kostenoptimierung der HW.

Haupt-Schwierigkeiten:

• Der bürstenlose Motor wird von einem Controller angesteuert, der nicht über ein eigenes CAN-Interface verfügt. Zur Erstellung eines Prototypensystems muss ein solches extern hinzugefügt werden sowie Treiber- und Protokoll-Software nach Kundenvorgaben entwickelt werden.
• Zur Anbindung des CAN-Interface an die vorhandene Elektronik steht lediglich eine Abart des SPI-Bus zur Verfügung, die für solche Zwecke nicht sonderlich gut geeignet ist.
• Durch die Zwischenschaltung eines weiteren Bussystems entstehen Timing-Engpässe beim rechtzeitigen Erfassen und Auswerten der CAN-Nachrichten.
• Sensorlose Erfassung der Rotorlage, Sinus-Kommutierung, relative Positions bestimmung durch eigenes kostenoptimiertes Sensorsystem.
• Harte Echtzeit-Anforderungen sowie komplexe Berechnungen der Vektor-Steuerung
• Kommunikation mit Mastersystem über CAN bei kundenspezifischem Protokoll

• Bereits bestehende Firmware-Versionen auf die neuesten Hardware-Erkenntnisse adaptieren und mit erweiterten Funktionen ausstatten.
• Zur Kostenoptimierung wird verstärkt auf sensorlose Systeme gesetzt. Verschiedene Lösungsansätze mit den etablierten sensorbehafteten Varianten vergleichen und diesen weitest möglich annähern.
• Erweiterte Sicherheitsaspekte sind zu berücksichtigen, das EMV-Verhalten sowie die Notlaufeigenschaften zu verbessern und die jeweils spezifischen Anforderungen der einzelnen KFZ-Hersteller sollen weitestgehend erfüllt werden. 

Haupt-Schwierigkeiten:

• Trotz steigender Komplexität muss angestrebt werden, mit den vorhandenen Ressourcen (ROM / RAM / Eeprom / Rechenleistung) auszukommen und dabei nicht auf Kosten der Qualität zu optimieren. 

FIRMWARE-ENTWICKLUNG BLDC-ANTRIEBE FÜR AKTIV-LENKUNG (BOSCH / BMW) UND ELEKTROHYDRAULISCHE KUPPLUNG (FTE)

• Entwicklung eines BLDC-Antriebs nach Vorgaben, die zusammen mit dem Kunden auszuarbeiten sind. Einsatz eines DSP bzw. eines Hybrid-Controllers (µC + DSP) MSP56F83xx, Ausnutzung aller On-chip-Ressourcen zur Kostenoptimierung der HW.

Haupt-Schwierigkeiten:

• Der bürstenlose Motor wird von einem Controller angesteuert, der nicht über ein eigenes CAN-Interface verfügt. Zur Erstellung eines Prototypensystems muss ein solches extern hinzugefügt werden sowie Treiber- und Protokoll-Software nach Kundenvorgaben entwickelt werden.
• Zur Anbindung des CAN-Interface an die vorhandene Elektronik steht lediglich eine Abart des SPI-Bus zur Verfügung, die für solche Zwecke nicht sonderlich gut geeignet ist.
• Durch die Zwischenschaltung eines weiteren Bussystems entstehen Timing-Engpässe beim rechtzeitigen Erfassen und Auswerten der CAN-Nachrichten.
• Sensorlose Erfassung der Rotorlage, Sinus-Kommutierung, relative Positions bestimmung durch eigenes kostenoptimiertes Sensorsystem.
• Harte Echtzeit-Anforderungen sowie komplexe Berechnungen der Vektor-Steuerung
• Kommunikation mit Mastersystem über CAN bei kundenspezifischem Protokoll

• Die Zielsetzung bestand insbesondere darin, die geforderten Funktionen mit Hilfe einer stark abgemagerten Hardware und einem günstigen aber sehr einfachen Controller (PIC16C622) in kurzer Zeit zu realisieren, um den Kostenvorstellungen eines bestimmten Großkunden entgegen zu kommen.

Umsetzung:

• Erzeugung eines Drehfeldes für 3-phasigen bürstenlosen Motor
• Drehzahlregelbereich von 200 bis 5500 UPM
• Versorgungsspannungsbereich von 30 bis 60 V
• Temperaturbereich von ?20 bis 80°C
• Kennliniengesteuerte temperaturabhängige Drehzahlregelung
• PD ? und PID ? Regelung, Blockier-Erkennung, Überlastschutz, Sanftanlauf
• Drehzahlüberwachung, Alarmfunktionen für Drehzahl und Temperatur

Resultate:

• Dieses Projekt reichte bis nahe an die Grenzen des Machbaren heran. Manch eine eingesparte Hardware-Komponente musste durch einen komplexen und schnellen Software-Algorithmus ersetzt werden. Dies brachte extrem hohe Anforderungen an die Verarbeitungsgeschwindigkeit des Controllers mit sich und konnte von dem aus Kostengründen gewählten Typ nur mit Mühe und unter Einsatz ungewöhnlicher Maßnahmen geleistet werden. Besonders das geforderte weite Drehzahlband in Verbindung mit dem ebenfalls großen Spielraum für die Versorgungsspannung bereitete erhebliche Probleme.
• Dank enger Zusammenarbeit mit den HW-Designern und einer dadurch erzielten optimalen Abstimmung zwischen µC-Möglichkeiten und externer Beschaltung gelang es, die hochgesteckten Ziele auch mit der stark vereinfachten Schaltung zu erreichen.

UNTERSUCHUNG DER EINSATZMÖGLICHKEIT VON HOCHSPRACHE BEI DER FIRMWARE-ENTWICKLUNG IM LOWCOST-SEGMENT

• Es war zu untersuchen, in wie weit der Einsatz von C oder einer anderen geeigneten Hochsprache auch in den eingesetzten kleineren Controllern (meist <= 2k Worte) möglich und sinnvoll ist bzw. welche Vor- und Nachteile dies mit sich bringt.

Umsetzung:

• Die vorhandene Assembler-Software wurde einer eingehenden Analyse unterzogen und deren Funktionalität teils in C übernommen, teils durch günstigere Algorithmen ersetzt.
• Die Stärken und Schwächen der am Markt verfügbaren Compiler mussten im Hinblick auf Code-Überhang und Geschwindigkeitsverluste untersucht werden, so dass Empfehlungen ausgesprochen und für den gewählten Compiler konkrete Einsatz-Anweisungen in Form von Einschränkungen des Sprachraums für optimale Ergebnisse definiert werden konnten. Auf diese Weise entstand ein firmeninternes 'Embedded-C'.
• Bei der Untersuchung des vom gewählten Compiler erzeugten Codes stießen wir auch auf einige Compiler-Fehler. Diese konnten dank der Aufgeschlossenheit des Herstellers recht schnell behoben wurden. Darüber hinaus gelang es noch, einige Vorschläge zur weiteren Steigerung der Performance umzusetzen.
• Nach weiteren Optimierungs-Durchgängen für den gewählten Compiler entstand eine Referenzsoftware, die bei minimalem Code-Überhang fast völlig ohne Assembler-Einsatz auskommt und somit die Vorteile des Hochsprachen-Einsatzes auch für dieses Low-Cost-Segment der Produkte erschließt.

Resultate:

• Die gefundenen Ergebnisse flossen in eine Dokumentation mit folgendem Inhalt ein:
  • Compiler-Empfehlung
  • Empfehlungs- / Verbotsliste für den Einsatz der Sprachelemente von C
  • C-Referenz-Software mit einem Überhang von < 3 % zur bisherigen Assembler-Software
  • Checkliste zur Überprüfung des fertigen Codes auf Einhaltung festgelegterQualitätskriterien
  • A?uf den Einsatzzweck optimierte Varianten einiger oft benötigter C-Libary- Funktionen
• Der Großteil der Firmwarestände vieler Lüfter-Varianten dieses bearbeiteten Produkt-Segments bauen seither auf den Empfehlungen dieses Projektes auf.
• Die Entwicklungsgeschwindigkeit wurde merklich erhöht bei gleichzeitiger spürbarer Verringerung der Fehlerträchtigkeit sowohl bei der Software-Entwicklung als auch bei der Versionsverwaltung und Variantenpflege.
• In einem ergänzenden Schritt kam es zur Einführung von Dokumentationsstandards für den C-Code sowie zu Empfehlungen im Bereich Versions-Management. Nach Anschaffung der empfohlenen Tools durch den Kunden (Struktogramm-Editor, Versionskontrollsystem) erhielten die betroffenen Mitarbeiter vor dem Start des nächsten Projektes eine entsprechende Kurzschulung.