Fonctions contenues dans V7.2 Service Pack 8

Aperçu des fonctions

  • RAM d’émulation limitée – Prise en charge de la RAM overlay pour Renesas RH850
  • Prise en charge de nombres entiers 64 bits (limité à la plage de valeurs 32 bits)
  • COM-API – Prise en charge de la surveillance du bus
  • AUTOSAR – Prise en charge de la surveillance d’I-PDU multiplexés pour CAN/CAN-FD
  • AUTOSAR – Prise en charge de « E2E communication protection » pour la surveillance CAN/CAN-FD
  • Affichage et modification de noms d’alias dans la configuration matérielle
  • Contrôle des chevauchements de paramètres dans la base de données
  • Flashage ProF-XCP – Nouvelle commande XCP_SET_TIMEOUT
  • Recherche dans le dialogue « Add hardware device »

RAM d’émulation limitée – Prise en charge de la RAM overlay pour Renesas RH850

Exemple de schéma de recouvrement du microcontrôleur Renesas RH850

La famille de microcontrôleurs Renesas RH850 prend en charge plusieurs clusters de mémoires flash. Chaque cluster nécessite pour l’application un traitement spécifique de la RAM overlay associée.

INCA d’ETAS prend en charge le mécanisme de recouvrement de RH850, permettant ainsi l’application pour tous les clusters de mémoires flash. La solution logicielle optimise par ailleurs l’utilisation de la RAM overlay générale et propre au cluster.

Prise en charge de nombres entiers 64 bits (limité à la plage de valeurs 32 bits)

Actuellement, les valeurs 64 bits sont accessibles via des bitmasks.

La toute dernière génération de calculateurs prend en charge les registres de 64 bits. Pour permettre un accès rapide aux données, il faut que ces registres soient lus avec un accès unique. Les données étant généralement inférieures à 64 bits, plusieurs données sont stockées dans l’un de ces paquets.

Pour la lecture et l’écriture via un accès unique, INCA prend désormais en charge les nombres entiers 64 bits. Des bitmasks contenant jusqu’à 32 bits actifs doivent être utilisés pour séparer les différentes informations. Ils doivent être présents dans une séquence. Une prise en charge 64 bits complète est prévue pour les futurs Service Packs.

COM-API – Prise en charge de la surveillance du bus

Il est judicieux pour de nombreuses applications de surveillance de bus d’échanger le fichier de description du bus. Une commande API permet de charger les fichiers de description dans une base de données INCA existante.
Les commandes suivantes ont été créées pour lire une description de bus :

  • ReadCanDBFile
  • ReadAutosarFile
  • ReadFibexFile
  • ReadLdfFile

Les commandes suivantes ont été créées pour affecter une description de bus à un appareil de surveillance :

  • HWProjectSystem.SetProject

Les descriptions de surveillance de bus suivantes sont prises en charge :

  • CAN DB for CAN, CAN FD, J1939
  • AUTOSAR V4.1, 4.2, 4.3 pour CAN, CAN FD, FlexRay
  • Fibex V3.0,3.1 pour FlexRay
  • LDF V1.3, 2.3 pour LIN

AUTOSAR – Prise en charge de la surveillance d’I-PDU multiplexés pour CAN/CAN-FD

Schéma d’un I-PDU multiplexé ; la zone de sélection définit la façon dont la partie dynamique est interprétée.

Les signaux définis dans les segments statiques et dynamiques d’un I-PDU multiplexé peuvent être mesurés dans INCA à l’aide de la surveillance CAN/CAN-FD. L’I-PDU multiplexé pour la communication avec le calculateur du client permet d’utiliser efficacement la largeur de bande disponible.

Remarque : ES590, ES591, ES690 et ES1222 ne prennent pas en charge cette fonction.

AUTOSAR – Prise en charge de « E2E communication protection » pour la surveillance CAN/CAN-FD

L’une des améliorations d’AUTOSAR 4.x réside dans la sécurisation de la communication via la « E2E communication protection ». Chacun des différents profils E2E met en œuvre une association de mécanismes de protection tels que compteurs de séquences, ID de données et contrôle de redondance cyclique (CRC).

INCA ne lit et interprète que les valeurs issues de la Protocol Data Unit (PDU). Les exigences suivantes sont prises en compte :

  • INCA gère les données utilisateur et PDU pour des signaux de mesure sélectionnés.
  • Tous les signaux de la protection E2E sont visibles dans le dialogue de sélection des variables et disponibles pour les mesures et enregistrements.
  • Les champs « CRC », « Counter » et « Length » s’affichent sour forme de signaux de mesure dans INCA, pour surveiller les valeurs de l’en-tête E2E.

Affichage et modification de noms d’alias dans la configuration matérielle

Grâce au menu contextuel, le nom des appareils INCA peut être stocké dans le matériel sous la forme d’un nom d’alias.

Si plusieurs appareils du même type (par exemple deux XETK d’ETAS) sont utilisés à bord d’une même voiture, ils doivent être affectés/identifiés de manière claire et unique. Le numéro de série n’est ici d’aucune aide, car il ne fournit aucune information sur la fonction de l’appareil. Des noms d’alias peuvent désormais être stockés dans les appareils pour faciliter l’identification du matériel. Ils permettent d’affecter les appareils installés à bord d’une voiture à ceux de la configuration matérielle INCA.

INCA montre les noms d’alias dans :

  • le dialogue « Dialog „Search for hardware »
  • le dialogue « Hardware mapping »
  • la fenêtre « Configuration matérielle »
  • le dialogue « Assign project »

Pour le mapping automatique du matériel, le nom de l’appareil INCA et le nom d’alias doivent correspondre. Utiliser pour ce faire l’entrée de menu contextuel « Use Alias as name ».

Contrôle des chevauchements de paramètres dans la base de données

Les jeux de données peuvent être contrôlés pour identifier les chevauchements de paramètres.

Si deux paramètres partagent la même mémoire, l’application d’un paramètre affecte l’autre, ce qui n’est pas toujours intentionnel. Les paramètres nécessitent souvent plusieurs octets pour stocker les valeurs. Un simple contrôle de différentes adresses de départ ne permet pas d’identifier tous les chevauchements.

C’est pourquoi INCA prend désormais en compte à la fois l’adresse et la taille des paramètres. Le contrôle peut être lancé manuellement pour les projets INCA (fichiers A2L). Les paramètres se chevauchant avec des bitmasks différents sont également détectés.

Flashage ProF-XCP – Nouvelle commande XCP_SET_TIMEOUT

Pour le flashage XCP, ProF utilise la connexion XCP établie avec les paramètres du fichier A2L. Ceux-ci sont optimisés pour la mesure XCP et l’application, mais pas pour le flashage.

Le flashage inclut quelques processus comportant de longs temps de traitement tels que l’effacement de la mémoire du calculateur ou le calcul de la somme de contrôle. L’utilisation des paramètres optimisés t1-t7 pour les faibles temporisations XCP en provenance du fichier A2L pourrait entraîner des temporisations dans la communication XCP lors du flashage.

En cas d’utilisation des paramètres XCP optimisés pour la mesure t1-t7 en provenance du fichier A2L, il est désormais possible de faire appel à différents paramètres de temporisation XCP pour le flashage. Ceci permet de modifier les temporisations individuelles t1-t7 lors du flashage et d’éviter ainsi de rencontrer des problèmes de temporisation.

La nouvelle commande est expliquée dans la documentation ProF.

Recherche dans le dialogue « Add hardware device »

Une fonction de recherche a été ajoutée au dialogue « Add hardware device ».

INCA prend en charge les appareils matériels les plus divers. La nouvelle fonction de recherche dans le dialogue « Add hardware device » permet de trouver aisément le matériel recherché.