Vector: CANoe / CANalyzer

Bisheriger/interner Bezeichner: CANoeCANalyzer

Herstellerinformationen

Hersteller

Webseite

Produktname

Version

Vector Informatik GmbH

http://www.vector.com

CANoe / CANalyzer

ab 10.0, getestet bis 18SP2

Kategorien

MDL 🛈

APL 🛈

BAN 🛈

BMA 🛈

SVC 🛈

DGN 🛈

FIU 🛈

EES 🛈

FCT 🛈

DBG 🛈

IMG 🛈

AUDIO 🛈

ENVSIM 🛈

ENVCOM 🛈

✓

✓

✓

Datenquellen

Dateiformat

Kommentar

*.dbc

CAN-DBC

*.xml

Fibex (ASAM MCD 2 NET)

*.arxml

Autosar XML

*.MAPort.xml

MAPort-Konfigurationsdatei

Signalaufnahmen 🛈

Dateiformat

Kommentar

*.blf, *.csv, *.mdf, *.mf4

Plattform

Betriebssystem

Unterstützung

Windows

✓

Linux

Ports

Besonderheiten

Hinweise zu System- und Umgebungsvariablen

Systemvariablen, deren Name oder Namespace mit einem Unterstrich beginnt, können möglicherweise von ecu.test nur gelesen aber nicht geschrieben werden.

Systemvariablen müssen typgerecht geschrieben werden. Insbesondere ist es nicht möglich, eine Ganzzahl (ohne Komma/Dezimalpunkt) in eine Variable vom Typ Double zu schreiben. Stattdessen muss die Zahl als Gleitkommazahl (also 3.0 oder float(3) statt 3) angegeben werden.

Systemvariablen und Umgebungsvariablen des Typs Data können in ecu.test über den Tab Modellzugriff nicht verwendet werden. Stattdessen können die Tooljobs ReadSysVar und WriteSysVar ausgeführt werden. Die Werte sind hierbei als Tupel oder Liste von Zahlen anzugeben. Für Umgebungsvariablen müssen die Zahlen im Unsigned-Int8-Format sein (zwischen 0 und 255 je einschließlich). Der geschriebene Wert wird, falls er nicht mit 0 endet, automatisch durch CANoe bzw. CANalyzer mit einer abschließenden 0 terminiert. Für Systemvariablen ist dagegen das Signed-Int8-Format erforderlich (zwischen -128 und +127) und es erfolgt keine automatischen 0-Terminierung.

Hinweise zum Aufnehmen

System- und Umgebungsvariablen können nicht explizit aufgezeichnet werden. Wenn aber eine Bus-Aufnahme durchgeführt wird, sind System- und Umgebungsvariablen in dieser Aufnahme implizit mit enthalten. Diese können also insbesondere in die selbe Signalgruppe „dazugezogen“ werden. Dabei muss man nur darauf achten, mehr Bus-Signale als System- oder Umgebungsvariablen zu haben, damit ecu.test eine Bus-Aufnahme, die zusätzlich System- und/oder Umgebungsvariablen enthält, anfertigt, statt eine Umgebungs- oder Systemvariablen-Aufnahme zu versuchen.

ecu.test muss zum Aufzeichnen eigene Recorder in der Online-Messkonfiguration anlegen. Das ist nur bei angehaltener Messung möglich. Wenn mindestens so viele von ecu.test erstellte Recorder existieren wie der Testfall Signalaufnahme-Gruppen enthält, können diese auch bei weiterlaufender Messung wiederverwendet werden.

Aufnahmen können erst nach dem Messungsstart begonnen werden und sollten vor Ende der Messung beendet werden. Insbesondere bedeutet das, dass wenn der Messungsstart in der Testbenchkonfiguration auf Manuell gestellt ist, die Auto-Start/-Stop-Funktion der Aufnahmegruppe nicht verwendet werden kann, sondern die Testschritte StartTrace (StartTrace_Symbol) und StopTrace (StopTrace_Symbol) nach bzw. vor den Jobs StartMeasurement bzw. StopMeasurement aufgerufen werden müssen.

Hinweise zu CAPL-Funktionen

Für den Aufruf von CAPL-Funktionen durch ecu.test bestehen einige Einschränkungen:

  • Alle im Testfall verwendeten CAPL-Funktionen müssen beim Messungsstart angemeldet werden.

    Dazu ist es erforderlich, dass der Messungsstart durch ecu.test entweder automatisch bei Testfallbeginn oder explizit per Job StartMeasurement erfolgt. Wenn die Messung bereits läuft und von ecu.test nicht beeinflusst wird, kann diese CAPL-Registrierung nicht erfolgen.

    ecu.test versucht automatisch, die in dem Testfall, in dem der automatische oder explizite Messungsstart erfolgt, per Job CallCAPLFunction verwendeten CAPL-Funktionsnamen zu ermitteln und zu registrieren.

    Wenn Namen von CAPL-Funktionen erst zur Laufzeit bestimmt werden, oder die Messung in einem Testfall gestartet und in einem späteren CAPL-Funktionen verwendet werden sollen, können diese nicht automatisch erkannt werden. Diese CAPL-Funktionen müssen vor dem Messungsstart per Job-Aufruf RegisterCAPLFunction vorgemerkt werden, damit sie beim Messungsstart registriert werden können.

  • Es sind nur Argumente und Rückgabewerte vom typ long möglich. Für andere Werte ist das Verhalten nicht definiert: Fehlermeldungen und/oder unsinnige Werte können auftreten.

  • CAPL-Funktionen, die einen Rückgabewert liefern, müssen in CANoe im Messaufbau eingebunden werden. CAPL-Blöcke im Simulationsaufbau liefern anstelle eines Rückgabewerts nur unsinnige Werte zurück.

  • Bei Änderungen an CAPL-Quellcode muss manuell in CANoe bzw. CANalyzer die Funktion alle Knoten kompilieren ausgelöst werden.

Hinweise zur Arbeit mit Busdatenbanken

Bitte darauf achten, dass die gleiche Busdatenbank in CANoe bzw. CANalyzer angegeben ist, da diese nicht automatisch von ecu.test hinterlegt wird.

FlexRay-Kanäle A und B (Einschränkung nur für Fibex)

Falls CANoe bzw. CANalyzer mit einem FlexRay-Bus verwendet wird, in welchem beide Kanäle A und B verwendet werden, dann ist das in ecu.test wie folgt zu konfigurieren:

  • In der Testbenchkonfiguration dem Tool CANoeCANalyzer zwei BUSACCESS-Ports hinzufügen, welche auf den gleichen Kanal in CANoe/CANalyzer verweisen.

  • In der Testkonfiguration unter Buszugriff zwei Bussysteme anlegen, welche beide die gleiche Busdatenbank verwenden.

  • Unter Kanal muss je einer der beiden Kanäle gewählt werden.

  • Als Aktiver Knoten muss je einer der beiden Ports ausgewählt werden.

Hinweise zu Testmodulen

Testmodule können mit Hilfe des Testschritts CANoe Testmodul-Runner ausgeführt werden.

Hinweise zur XIL-Schnittstelle

Voraussetzungen

  • Vector CANoe XIL API

  • ASAM AE XIL Standard Assemblies 2.0.1 oder höher

Info

Bitte beachten Sie bei der Auswahl des XIL-API Server in der Testbenchkonfiguration, dass die 64-Bit-Variante ausgewählt werden muss.

Weitere Hinweise zur Einrichtung finden sich unter How to Troubleshoot XIL API Issues.

Einstellungen für jede CANoe Konfiguration

File ‣ Options ‣ Extensions ‣ XIL API & FDX Protocol

  • XIL API Server aktivieren

  • FDX aktivieren

  • FDX-Datei anlegen/referenzieren

Info

Bitte beachten Sie die CANoe-Dokumentation im Abschnitt CANoe ‣ ASAM XIL API ‣ Model Access Port

FDX-Dateien

ecu.test kann über die XIL-API ausschließlich auf Signale und Variablen aus CANoe zugreifen die Bestandteil einer FDX-Datei sind. Diese Datei kann in CANoe unter File Tab ‣ Options ‣ Extensions ‣ XIL API & FDX Protocol erstellt und verknüpft werden.

Alle Einträge der FDX stehen später in ecu.test als Modellgrößen zur Verfügung.

Info

Bitte beachten Sie bei der Verwendung von mehreren Gruppen im FDX deren Konfiguration in der .MAPort.xml

*.MAPort.xml

Zusätzlich zur CANoe Konfiguration (*.cfg) wird für den Zugriff über die XIL-API eine *.MAPort.xml benötigt. Diese Datei legt die zu Verwendende CANoe Konfiguration fest und konfiguriert die Gruppen der verwendeten FDX-Dateien.

Der Pfad zu dieser Datei muss in der Testbenchkonfiguration im Feld Modell-Verzeichnis (siehe oben) angegeben werden. Daraufhin kann dann die konkrete .MAPort.xml in der Testkonfiguration als Modelldatei ausgewählt werden.

Info

Den Aufbau der Datei entnehmen Sie bitte der CANoe-Dokumentation im Abschnitt CANoe ‣ ASAM XIL API ‣ Model Access Port

Hinweise zur Verwendung vom GenericBus-Port

Info

Der Generic Bus Port kann nur zusammen mit dem XIL-Modellport verwendet werden.

Über den Bus-Port können im Modell (via FDX) abgebildete Bussignale gelesen und manipuliert werden. Die Abbildungsvorschriften von Bussignal zu Modelldaten werden in der Testbenchkonfiguration hinterlegt (siehe oben). Deren Syntax wird im nachfolgenden Abschnitt beschrieben.

Porttyp BUSACCESS (GENERIC)

Bus-Port für den Zugriff auf die Restbussimulation des Umgebungsmodells. Die Abbildung von Signal-/Botschaftsnamen auf Modell-Pfade ist mit Pfad-Mustern weitgehend konfigurierbar. Die Abbildung von CRC- und ALIVE-Signalen wird gesondert konfiguriert. CRC- und ALIVE-Signale werden am Präfix „CRC“ bzw. „ALIV“ des jeweiligen Signalnamens erkannt.

Die Pfade in den Eigenschaften können verschiedene Platzhalter enthalten, die beim Zugriff auf ein Signal automatisch ersetzt werden. Ein Platzhalter wird mit einem %-Zeichen angeführt und in Runde Klammern gesetzt: %(<platzhalter>). Nach der schließenden Klammer muss ein Formatierungs-Code stehen.

Info

Ein valider Ausdruck wäre also bspw.: %(signal)s, wobei „signal“ ein Platzhalter und „s“ ein Formatierungscode darstellen.

Verfügbare Platzhalter

bus

Name des Busses

node

Name des Steuergerätes

frame

Name der Botschaft / des Frames

frameId

Die ID der Botschaft / des Frames.

CAN: CAN-ID FlexRay: Slot-ID

pdu

Name des/der PDU/Subframes

signal

Name des Signals

cycleRepetition

Nur FlexRay: Anzahl Zyklen bis ein Frame erneut gesendet wird

baseCycle

Nur FlexRay: Erster Kommunikationszyklus, in dem ein Frame gesendet wird.

segmentType

Nur FlexRay: „Dynamic“, wenn die aktuelle Slot-ID über der maximalen Anzahl an statischen Slots liegt, sonst „Static“

signalGroup

Name der Signalgruppe

Formatierungscodes

Die Platzhalter können mit den folgenden Formatierungsregeln manipuliert werden:

s

Platzhalter wird nur ersetzt, Groß-/Kleinschreibung des ersetzenden Wertes bleiben erhalten.

us

ersetzter Wert wird komplett in Großbuchstaben konvertiert.

ls

ersetzter Wert wird komplett in Kleinbuchstaben konvertiert.

d

ersetzter Wert wird als Dezimalzahl dargestellt.

x

ersetzter Wert wird als Hexadezimalzahl mit Kleinbuchstaben dargestellt.

X

ersetzter Wert wird als Hexadezimalzahl mit Großbuchstaben dargestellt.

4x

ersetzter Wert wird mit führenden Nullen auf 4 Stellen aufgefüllt (die Stellenanzahl kann geändert werden, und auch in Kombination mit d bzw. X statt x verwendet werden)

Pfad-Bestandteil als optional markieren

Es ist möglich bestimmte Teile eines Pfades als optional zu markieren. Ein Pfad-Bestandteil ist dann optional, wenn er:

  • in eckigen Klammern steht, also zwischen „[“ und „]“ und

  • wenigstens ein Platzhalter enthalten ist

Ein optionaler Bestandteil ist nur dann im Zielpfad enthalten, wenn alle darin befindlichen Platzhalter mit einem Wert ersetzt werden können.

Ein Beispiel: Als TX-Pfad ist folgendes konfiguriert: /can/[%(signalGroup)s/]%(signal)s/Value. Befindet sich das entsprechende Bussignal „A“ in einer Signalgruppe (z.B. „sign_group“), resultiert das in einen TX-Pfad: /can/sign_group/A/Value. Der optionale Bestandteil ist also im Zielpfad enthalten. Ist das Signal hingegen nicht Bestandteil einer Signalgruppe, ergibt das den Pfad: /can/A/value.

Tx-Switch-Pfad

Der Tx-Switch-Pfad wird benutzt, um die Manipulation von Signalen zu de-/aktiviern. Das Signal auf dem Switch-Pfad wird dazu auf folgende Werte gesetzt, um die Manipulation des Zielsignals zu steuern:

  • 0: wenn das Zielsignal nicht manipuliert wird

  • 1: wenn das Zielsignal mit Repräsentation Physikalische Umrechnung geschrieben wird

  • 2: wenn das Zielsignal mit Repräsentation Rohwert geschrieben wird

Wenn die Option Fehlenden *-Tx-Switch-Pfad ignorieren gesetzt ist, muss der Tx-Switch-Pfad nicht existieren. Das Zielsignal wird trotzdem mit dem gewünschten Wert überschrieben.