Symposium: LIN-Entwicklungen zwischen Qualitätsanforderung und Kostendruck
Vom Conformance-Test zum LIN-Baukasten #####
Fortsetzung des Artikels von Teil 1
Internet-Links
[1] Vector-Lösungen für die LIN-Vernetzung: www.lin-solutions.de
[2] LIN-Konsortium: www.lin-subbus.org
ist bei Vector Informatik Teamleiter und Produktmanager für LIN-Tools.
gavin.rogers@vector-informatik.de
SOI für den LIN-Bus
Die neue LIN-Spezifikation 2.1: Teil 1, Teil 2
Jobangebote+ passend zum Thema
Auf Wunsch eines OEMs konzipierten und spezifizierten die LIN-Spezialisten von Vector einen Prototypen des Black-Box-Master-Conformance-Tests. Da die Testkommunikation die normale Master-Funktion nicht beeinträchtigen darf, ist die Definition eines speziellen Diagnoseservices erforderlich. Während normalerweise der Master die Kommunikation mit den Slaves bestimmt, erfordert die Testkommunikation eine Einflussmöglichkeit von Seiten des Testers (Bild 4). Der Slave schickt in der Rolle des Testers ein Testkommando an den Master, auf das dieser nun positiv oder negativ reagiert. Allerdings kommt man nicht umhin, jeweils einen Test-Login und eine Testinitialisierung durchzuführen, d.h., die Anwendung ist in jedem Fall in den Vorgang einzubinden.
Auf Wunsch eines OEMs konzipierten und spezifizierten die LIN-Spezialisten von Vector einen Prototypen des Black-Box-Master-Conformance-Tests. Da die Testkommunikation die normale Master-Funktion nicht beeinträchtigen darf, ist die Definition eines speziellen Diagnoseservices erforderlich. Während normalerweise der Master die Kommunikation mit den Slaves bestimmt, erfordert die Testkommunikation eine Einflussmöglichkeit von Seiten des Testers (Bild 4).
Der Slave schickt in der Rolle des Testers ein Testkommando an den Master, auf das dieser nun positiv oder negativ reagiert. Allerdings kommt man nicht umhin, jeweils einen Test-Login und eine Testinitialisierung durchzuführen, d.h., die Anwendung ist in jedem Fall in den Vorgang einzubinden.
In jedem Fall müsste der existierende und standardisierte Treiber um eine Test-Server-Fähigkeit erweitert werden. Der dafür erforderliche Zusatzcode liegt schätzungsweise bei 20 bis 30 %, bezogen auf den aktuellen Treiberumfang, was für Master-Steuergeräte meistens gut zu verkraften ist.
Momentan umfasst die Prototyp-Implementierung von Vector elf Services (Tabelle), mit denen die Spezifikationen des aktuellen LIN-2.0-Conformance-Test vollständig erfüllt werden können. Dieses Konzept ist nicht nur grundsätzlich erweiterbar, sondern auch standardisierbar. Es basiert nicht nur auf dem existierenden LDF samt passendem Entwicklungsprozess, auch alle Kommandos sind offengelegt und erweiterbar.
Umfangreiche LIN-Testerfahrungen in Verbindung mit CANoe.LIN sammelte das Delphi Technical Center in Krakau (Polen), sowohl bei Projekten mit LIN 2.0 als auch mit dem J2602-Protokoll, dem amerikanischen LIN-Pendant (Bild 3). Dabei stellte sich heraus, dass die LIN-Conformance-Tests allein auf Basis der OSISchichten nicht ausreichen. Die Testaktivitäten wurden deshalb in Richtung verschiedener Anwendungstests ausgedehnt. Der Fokus liegt dabei auf dem Testen von LIN-Signalen, der Schedule Table des LIN Masters, bei Gateways sowie auf Diagnosetests. Für die Umsetzung und Automatisierung der Testabläufe erwiesen sich die von CANoe.LIN zur Verfügung gestellten CAPL-Testfunktionen als unverzichtbar. Selbst sehr komplexe „Test Cases“ lassen sich in der C-ähnlichen CAPL-Syntax leicht implementieren und erweitern.
Der „Gray-Box-Master-Test“ versus V-Modell
Die Erfahrungen in der Praxis zeigen, dass die Realisierung des Master-Conformance-Test als Gray-Box-Test noch nicht die optimale Lösung darstellt. Bei Gray-Box-Tests wird mit Hilfe einer Testapplikation und eines Test-LDF direkt auf den Master-Treiber zugegriffen. Dadurch erreicht man zwar eine volle Testabdeckung, muss aber auch den Nachteil in Kauf nehmen, dass sich der übliche, am V-Modell orientierte Entwicklungsprozess nicht einhalten lässt. Die Verifikation der Master-Konformität ist nur am Anfang des Entwicklungsprozesses möglich. Sobald allerdings die produktive Datenbasis (LDF) und Applikation auf dem Master-Steuergerät laufen, sind weitere Verifikationen während der Entwicklung nicht mehr durchführbar. Auch ein Conformance-Test durch den OEM bedarf der Unterstützung des Zulieferers. Von OEMs und Zulieferern wird daher häufig die Frage nach dem Master-Conformance-Test in Form eines Black-Box-Tests gestellt.
- Vom Conformance-Test zum LIN-Baukasten #####
- Internet-Links
- Treiberschnittstelle mit Testservices
- Vom Conformance-Test zum LIN-Baukasten
