• Echtzeit-Treiber für HF- und LF- Subsysteme
• Treiber für UWB-Subsystem
• Power-Management
• Bootloader, Bootloader-Updater
• NVM-Managerment incl. FEE

Entwicklung des Fahrberechtigungs-Systems für MLBevo (Audi & Co) Keyless-Go, Keyless-Entry, Schlüsselortung über LF- und HF-Funkstrecke in Kooperation zunächst mit Hella, später mit Continental

KeyComponents

• 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

KeyComponents

• 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

Entwicklung diverser Module für eine neue dynamische BLDC-Antriebs-Serie wie

• Bootloader (Host- und Target- Seite)
• Flash-Emulated-Eeprom, Parameterspeicher
• Steuerung über CANOpen (Ansteuerung von bis zu 64 Motoren)
• Alternative RS485-Kommunikations-Schnittstelle
• Redundante Positions-Erfassung durch zwei unabhängige Systeme
• Synchronisation mehrerer Antriebe

KeyComponents

• Motorsteuerungs-Variante des dsPIC33, Resolver

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.

KeyComponents

• 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

KeyComponents

• 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

KeyComponents

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

KeyComponents

• ST6 Assembler, kaum dokumentiert, LIN

Haupt-Schwierigkeiten

• Analyse der schlecht-dokumentierten Assembler-Software
• Test-Aufbau mit Emulator, ProgrammerIdentifikation 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

KeyComponents

• 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

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

Beratung Sw-Architektur, Betriebssysteme, CAN-Netz
Beim Einsatz in Operations-Mikroskopen und Peripherie

Aufgabenstellung

Die verschiedenen Subsysteme von Operations-Mikroskopen (in anderen Ländern als OP-Roboter bekannt) sollen untereinander vernetzt und evtl. ein Betriebssystem eingeführt werden. Der Auftrag umfasste die Beurteilung eines vom Kunden vorge-legten Entwurfs einer neuen Sw-Architektur sowie die Weitergabe von Know-How im Bereich CAN-Vernetzung.

Da das Umfeld solcher Geräte hochgradig sensibel ist (meistens Menschen), wurde höchste Priorität auf Fehlertoleranz, gegenseitige Überprüfung der einzelnen Teil-systeme sowie Notbetriebseigenschaften im Fehlerfall gelegt.

Umsetzung / Resultate

Das Kundenteam präsentierte zunächst seinen Entwurf. Dieser wurde in den entscheidenden Teilen analysiert, kommentiert und hinterfragt. In verschiedenen Teilbereichen konnte Konsens erzielt werden, indem Alternativen übernommen, Sackgassen verworfen und neue Vorschläge aufgegriffen wurden. Für weitere  Bereiche entstanden Pro- und Contra- Listen der verschiedenen in Frage kommenden Lösungsansätze, die an die übergeordneten Stellen zur endgültigen Entscheidung im Hinblick auf Marketing- und andere nicht-technische Gesichtspunkte weitergeleitet wurden.

Die so festgelegten Definitionen setzte das Entwicklungsteam des Kunden um. Die Resultate mussten weitere Reviews durchlaufen, um potentielle Schwachstellen zu finden und Wege zu deren Beseitigung auszuloten.

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.

Die vorhandenen chemischen bzw. batteriebetriebenen autarken Schmiergeräte sollten weiterentwickelt werden zu einem mittels CAN-Bus vernetzten System, das über eine Zentrale parametriert, gesteuert und überwacht werden kann. Da bis zu 100 Teilnehmer an einem Netzverbund teilnehmen können sollen, müssen die Kosten der einzelnen Teilnehmer auf niedrigem Niveau verbleiben, obwohl auch der autarke Betrieb ohne Zentraleinheit gewährleistet sein muss.

Weitere Forderungen:

• Bis zu 100 Teilnehmer, Netzausdehnung bis zu 1000m
• Als Netzteilnehmer sind vorzusehen:
• Schmierstoffspender
• I/O-Module mit SPS-Anbindung
• Sensor-Module (Temperatur, Vibration / Akustik, Beschleunigung etc.)
• Geringe Kosten für einzelnen Teilnehmer
• Autarker Betrieb der Teilnehmer ohne Verluste von Eventdaten
  über einen Zeitraum von min. 3 Wochen
• Automatische Erkennung von Positionsveränderungen im Netz
• Betrieb der Zentraleinheit an mehreren unabhängigen Netzen
• Zentrale und dezentrale Signalisierung von kritischen Füllständen und Fehlern

Umsetzung

Als Hauptprobleme stellte sich schnell die hohe Teilnehmerzahl in Verbindung mit den geforderten Leitungslängen heraus, weil über dieselbe die Teilnehmer sowohl versorgt werden als auch miteinander kommunizieren. Bedingt durch den hohen Innenwiderstand der Leitung und den hohen Strombedarf beim Spenden wurden alle erdenklichen Maßnahmen ergriffen, um die mittlere Stromaufnahme zu reduzieren:

• Netz-exklusive Spendevorgänge mit gegenseitiger Verriegelung
• Extensive Nutzung der Sleep-Modi sowohl der Controller als auch der
  CAN-Treiber
• Definierte Awake- und Sleep- Zyklen für effizientere Kommunikation

Resultate

Die Zentraleinheit wurde auf Basis eines PC-Moduls unter Linux aufgebaut. Ein Treiber für den CAN-Bus musste ebenso selbst entwickelt werden wie ein FTP-Client zur Übertragung der von den Teilnehmern eingesammelten Daten auf ein größeres Speichermedium. Auch der größte Rest der Software musste aus den diversen Linux-Ressourcen mit vielen Anpassungen zurechtgeschneidert werden.

Weitere Schwierigkeiten stellten sich durch die Forderung ein, dass das gesamte System sowohl bei Netzunterbrechungen als auch bei Ausfall der Stromversorgung eine sichere automatische Wiederinbetriebnahme ohne Datenverluste gewährleisten muss ohne auf USPs oder ähnliches zurückzugreifen.

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 festgelegter
  Qualitätskriterien
• Auf 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.