network module user’s guide - home - etas...network module - user’s guide 5 etas introduction...

Network ModuleUser’s Guide

2

Copyright

The data in this document may not be altered or amended without special noti-fication from ETAS GmbH. ETAS GmbH undertakes no further obligation in rela-tion to this document. The software described in it can only be used if the customer is in possession of a general license agreement or single license. Using and copying is only allowed in concurrence with the specifications stipulated in the contract.

Under no circumstances may any part of this document be copied, reproduced, transmitted, stored in a retrieval system or translated into another language without the express written permission of ETAS GmbH.

© Copyright 2019 ETAS GmbH, Stuttgart

The names and designations used in this document are trademarks or brands belonging to the respective owners.

V2.1.0 R01 EN - 06.2019

Network Module - User’s Guide 3

Contents

ETAS Contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.1 About this Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Using this Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Network Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Working with Network module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.1 Creating a Network module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.2 Importing a Network module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3 Editing a Network module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.4 Removing a Network module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4.1 Rest Bus Simulation of a Network Module . . . . . . . . . . . . . . . . . . . 18

4 The Network Module APIs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.1 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2 An example on how to use Network module API . . . . . . . . . . . . . . . . . . . . 26

5 ETAS Contact Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4

Introduction ETAS

1 Introduction

This manual addresses qualified personnel working in the fields of automobileECU development and testing. Specialized knowledge in the areas of measure-ment and ECU technology is required.

1.1 About this Manual

This manual contains information about working with a Network module. Themanual contains the following chapters:

• "Network Modules" on page 6

• "Working with Network module" on page 7

This chapter describes how to work on Network Modules.

– "Creating a Network module" on page 7

– "Importing a Network module" on page 9

– "Editing a Network module" on page 11

– "Removing a Network module" on page 17

– "Rest Bus Simulation of a Network Module" on page 18

1.2 Using this Manual

Presentation of Information

All actions to be performed by the user are presented in a so-called "use-case"format. This means that the objective to be reached is first briefly defined in thetitle, and the steps required to reach the objective are then provided in a list. Thispresentation looks as follows:

Definition of Objective

Any preliminary information...

• Step 1

Any explanation for Step 1...

• Step 2


• Step 3


Any concluding remarks...

To create a new file

When creating a new file, no other file may be open.

• Choose File → New.

The "Create file" dialog box is displayed.

Type the name of the new file in the "File name" field.

The file name must not exceed 8 characters.

• Click OK.

Network Module - User’s Guide

ETAS Introduction

The new file will be created and saved under the name you specified. You cannow work with the file.

Typographic Conventions

The following typographic convention are applied:

Important notes for the users are presented as follows:

Choose File → Open. Menu options are printed in bold, blue characters.

Click OK. Button labels are printed in bold, blue characters.

Press <ENTER>. Key commands are printed in small capi-tals enclosed in angle brackets.

The "Open file" dialog box appears. The names of program windows, dialog boxes, fields, etc. are enclosed in double quotes.

Select the setup.exe file. Text strings in list boxes, in program code and in path and file names are printed using the Courier font.

A conversion between Logic and Arithmetic data types is not possi-ble.

Emphasized text portions and newly intro-duced terms are printed in an italic font face.

Note

Important note for users.


Network Module - User’s Guide6

Network Modules ETAS

2 Network Modules

A Network module provides configurations of residual bus simulations using dif-ferent network types. It allows configurations of the bus type, "CAN/CAN FD/Automotive Ethernet".

The configuration is based on the AUTOSAR 4.3 standard.

Hardware Requirements

To be able to run Network bus simulations, you need at least one CAN board.

Use CAN boards of the following type:

• XC16 (for CAN)

• IB200 (for CAN)

• IB600 (for CAN/CAN FD)

• IB640 (for CAN/CAN FD)

To be able to use Automotive Ethernet you will need at least one free Ethernetport in the RTPC.

Use Ethernet Ports of the following type:

• Supported onboard Ethernet adapter

• TP_4LAN_3U (Intel I350) 4 port Ethernet adapter

You might also require a "Media Convertor“ (ETH to AETH),Type CBEB100.1-1m0 (RJ45) to connect to an actual ECU depending upon thetype of the ECU.

Software Requirements

The below listed licence(s) is(are) required to work with Network modules:

• COSYM_NIC for CAN/CAN FD

• COSYM_NAE for Automotive Ethernet

ETAS Working with Network module

3 Working with Network module

This chapter describes how to work on Network Modules.

The individual sections contain information on:

• "Creating a Network module" on page 7

• "Importing a Network module" on page 9

• "Editing a Network module" on page 11

• "Removing a Network module" on page 17

• "Rest Bus Simulation of a Network Module" on page 18

3.1 Creating a Network module

Follow the steps below to create a Network module.

• Go to COSYM and open a project.

The Project dashboard is displayed as shown in the image below.

Fig. 3-1 Project dashboard in COSYM

• Go to View menu and click Deployment Man-agement.<or>Click Edit Target in Deployment view in the Sys-tem editor.

Deployment Management is displayed.


8

Working with Network module ETAS

• Right-click on a target.

A context menu is displayed as shown in the image below.

Fig. 3-2 A context menu on a target

• Click Create Network Module .

"Create Network Module" dialog box is displayed.

• Specify the location of the .arxml file or click Browse to select the ARXML files.

"List of ARXML files to be imported" displays the list of ARXML files.

• Click Save & Edit.

A new network module is created inside the selected target in COSYM and the same is opened in the default text editor.

Fig. 3-3 Network module in the text editor



3.2 Importing a Network module

Follow the steps below to import a Network module:

• Go to View menu in the Project dashboard (see Fig. 3-1) and click Deployment Management. <or>Click Edit Target in Deployment view in the Sys-tem editor.


• Right-click on a target.

A context menu is displayed.

Fig. 3-4 Deployment Management in COSYM


10


• Click Import.

The "Import Model" dialog box opens.

Fig. 3-5 Import Model window

• Select the path of the Network module which is to be imported or click Browse to select it.

• Click Browse to select the destination path in COSYM, if you want to change the target.

• Enter the description which is optional.

• Click Import.

The selected Network module is imported into COSYM.

Note

"Name in COSYM" filed is disabled and "Configuration file for the selected model" field is not applicable for importing a Network module.



3.3 Editing a Network module

It describes how to edit a Network module by opening it in the default text editorthrough COSYM.

Follow the steps below to edit a Network module:

• Go to View menu in the Project dashboard (see Fig. 3-1) and click Deployment Management.


• Expand the arrow to view the modules which are available in a target.

• Double-click on a Network module to edit it.

The NetworkConfiguration.xml is displayed for editing in the text editor.

• Modify the required changes and click Save on the File menu to save the changes.

• Right-click on the edited network module in COSYM.

A context menu is displayed.

• Click Update to reflect the modified changes in the network module.


12


To edit the NetworkConfiguration.xml file

Tags in the file have the following meaning:

Tag Meaning

version: Indicates the version of the Network Module.

file name: Points to the ARXML file location.

ecu name: ECU names in the ARXML file which you wish to simulate.

Collect-FramesWith-outSenders:

Configuration under "default ECU settings" which contain comma-separated search strings to detect CAN/CAN-FD frames without sender but only with receiver(s). If no search strings are provided, all unassigned CAN frames are included in the code generation by default.

hard-ware-access:

Bus Type and its required configuration.If the user has not selected any values for the hard-ware-access, default values would be taken into consid-eration.For CAN-Board ID and Controller ID is to be defined.Default Board ID is "0" and Controller ID is "0".The Controller ID's have to be defined according to the hardware configuration shown below."IXXAT_XC16_CAN" - 0 and 1"IXXAT_IB200_CAN" - 0 to 3"IXXAT_IB600_CANFD" - 0 to 3"IXXAT_IB600_CAN" - 0 to 3"IXXAT_IB640_CAN" - 0 to 3"IXXAT_IB640_CANFD" - 0 to 3For CAN - SBR and FBR is to be defined, however this is a optional configuration.For CAN-FD valid ranges (in Kbps) will be as follows:SBR 250, 500, 1000.FBR 500, 1000, 2000, 4000, 5000, 8000, 10000.If user does not configure SBR and FBR then the values from ARXML file will be used.For CAN-FD ISOMode is to be defined.Default ISOMode is "true"FOR CAN ISOMode is ignored.For ETHERNET - Device name is to be defined. Default device name is "eth1".

subnets: Subnet Names in ARXML file which you wish to simulate.

clusters: CAN Cluster Names in the ARXML file which you wish to simulate.

display-Ser-viceInfo:

Appends the serviceinfo (i.e major, minor, instance) to the offered/requested service labels. Serviceinfo by default is appended to the labels, the displayServiceInfo option is set to "true".Set the displayServiceInfo option to "false", to omit service information being appended to labels.



code-gen: Generates code either for simulating the ECU or for moni-toring purpose.simulateEcu:For monitoring set the simulateEcu to "false"Default code is always generated for simulation.

skipCANRxMessages:If this property is set to "true", code generation for Rx messages in CAN/CAN-FD ECUs are skipped.Defaulted to "false" which will include CAN Rx messages in code generation.

EnableSignalsForHexManip:If this property is set to "true", code generation includes SwitchToHex signals otherwise they are not considered. Set to true by default, which adds SwitchToHex signals.

ManipulatePDUTimings:If this property is set to "true", then the inports to manip-ulate PDU timings will be included in the code generation. Defaulted to "false" which does not include any inports to manipulate PDU timings.

EventGroupMCastManip:If this attribute is set to "true" the MCast_Threshold signal will be added under every Tx Event group of the offered service. Defaulted to "false" which does not include MCast_Threshold signal under "TX Event group" of the offered service.

EnableSDTimingsManip:Enable or disable manipulation of service discovery timings for Offered\consumed services feature. Default value set to "false" (this indicates that the feature is disabled by default).

Dis-card-E2EDe-code-Failed-PDU:

If set to "true", failed E2E messages will be discarded else if "false", the messages will be decoded.

ISO Mode: If the hardware supports CAN FD ("IXXAT_IB600_CANFD", "IXXAT_IB640_CANFD"), you can choose whether the ISO certified protocol ("true") or the original Bosch protocol ("false") shall be applied.

Tag Meaning


14


dis-play-set-tings:

Contains different attributes which influence how the CEE hierarchy is gen-erated.

PDUType: Possible values are Name, ID, Both. Default value is Both.

serviceType: Possible values are Name, ID, Both. Default value is ID.

OfrSvcPrefix: The prefix which will get prefixed to provided service. Default is "osvc_".

ReqSvcPrefix: The prefix which will get prefixed to requested service. Default is "rsvc_".

EventGrpPrefix: The prefix which will get prefixed to event groups. Default is "evgrp_".

ethPDUDirection: If set to "true", it groups the PDUs under event group under tx\rx folder. Use "false" if this hierarchy is not needed.

OfrSvcHierarchy: Groups all the offered services from an Ethernet ECU under this folder name. Provide empty string if hierarchy is not needed.

ReqSvcHierarchy: Groups all the requested services from an Ethernet ECU under this folder name. Provide empty string if hierarchy is not needed.

ethHierarchy: Groups all the ethernet subnets\ECUs under this folder. Provide empty string if hierarchy is not needed.

canHierarchy: Groups all the CAN clusters\ECUs under this folder. Provide empty string if hierarchy is not needed.

groupByCluster: Groups all the CAN ECUs under this folder. Provide empty string if hierarchy is not needed.



Complete example:<?xml version="1.0"?><networkmodule version="2.4">

<autosarfiles><file name="D:\LCO\Config Files\AUTOSAR Files\CAN-FD

\File1.arxml"><ecus><ecu name="ecu1">

<code-gen simulateEcu ="true" skipCANRxMessages="false" EnableSignalsForHexManip="true" ManipulatePDUTimings="false" EnableSDTimingsManip="false" EventGroupMCastManip="false"/>

<CAN-hardware-access><device-id cluster="ENGINE" boardid ="1" controllerid="1"

ISOMode="true"/></CAN-hardware-access><ETHERNET-hardware-access><device-id device="eth2" ethProtocol="802.1Q" OVLAN="1798"

subnets="subnet_1" displayServiceInfo="false"/>

GTS: Configuration needed for Global Time synchroni-zation and dependent functionality

SubTlv-Time-Synchronization:

EthTSynTLVFollowUpTimeSubTLV: Adds "TimeSecured Sub tlv" information to the FUP ethernet message.

EthTSynTLVFollowUpStatusSubTLV: Adds "StatusSecured Sub tlv" information to the FUP ethernet message.

EthTSynTLVFollowUp-UserDataSubTLV:Adds "UserDataSecured Sub tlv" information to the FUP ethernet message.

Default value for the SubTlv is set to "true". Indicates all the above subtlv would be appended to the ethernet message.Set it to "false" in case you wish to ignore some subtlv information.

CRCTimeFlags:Value to be entered in Decimal format. Default all bits except reserved would be enabled i.e CRC-TimeFlags = 63. This is used for calculation CRC_time_0 and CRC_time_1.

IncrementVirtual-Clock:

Default is set to "true" with a period of 1ms.It is a virtual clock which increments automati-cally based on period.In a LABCAR project with multiple network mod-ules, only one of the modules can be configured with "Virtual clock" set to "true", for the other modules this should be configured as "false".


16


</ETHERNET-hardware-access></ecu>

<ecu name="Default"> <CAN-hardware-access> <device-id cluster="DEFAULT" boardid="0" controllerid="1" ISO-Mode="true" /> </CAN-hardware-access> <code-gen simulateEcu ="true" skipCANRxMessages="false" EnableSignalsForHexManip="true" ManipulatePDUTimings="false" EnableSDTimingsManip="false" EventGroupMCastManip="false"/><CollectFramesWithoutSenders>unmapped,abc</CollectFramesWithout-Senders> </ecu></ecus><CAN-hardware-access>

<Clusters Names=""/><device-id cluster="DEFAULT" boardid ="0" controllerid="0" ISO-

Mode="true"/><device-id cluster="ENGINE" boardid ="0" controllerid="1" ISO-

Mode="false"/><baud-rate cluster="DEFAULT" SBR ="500" FBR ="1000"/>

</CAN-hardware-access><ETHERNET-hardware-access>

<device-id device="eth1" ethProtocol="802.1Q" OVLAN="1798" subnets="subnet_1,subnet_2,subnet_3" displayServiceInfo="true"/>

</ETHERNET-hardware-access> <code-gen simulateEcu ="true" skipCANRxMessages="true" EnableSig-nalsForHexManip="true" ManipulatePDUTimings="false" EnableSDTimings-Manip="false" EventGroupMCastManip="false"/>

<Discard-E2EDecode-Failed-PDU value = "true" /><display-settings PDUType ="Name" serviceType ="Name" OfrSvcPrefix ="" ReqSvcPrefix="" EventGrpPrefix ="eg_" ethPDUDirection = "false"

OfrSvcHierarchy="tx" ReqSvcHierarchy="rx" ethHier-archy ="ETH" canHierarchy = "" groupByCluster="false"/>

</file>

<file name="D:\LCO\Config Files\AUTOSAR Files\CAN-FD\File2.arxml"><ecus>

<ecu name="ecu2"><code-gen simulateEcu ="true" skipCANRxMessages="true"

EnableSignalsForHexManip="true" ManipulatePDUTimings="false" EnableSDTimingsManip="false" EventGroupMCastManip="false"/>

<CAN-hardware-access><device-id cluster="CHASSIS" boardid ="2" controllerid="2"

ISOMode="true"/><baud-rate cluster="CHASSIS" SBR ="500" FBR ="1000"/>

</CAN-hardware-access><ETHERNET-hardware-access>

<device-id device="eth4" ethProtocol="802.1Q" OVLAN="1798"subnets="subnet_2" displayServiceInfo="false"/>

</ETHERNET-hardware-access> </ecu>



<ecu name="ecu3"><code-gen simulateEcu ="false" skipCANRxMessages="false"

EnableSignalsForHexManip="true" ManipulatePDUTimings="false" EnableSDTimingsManip="false" EventGroupMCastManip="false"/>

<ETHERNET-hardware-access><device-id device="eth4" ethProtocol="802.1Q" OVLAN="1798"

subnets="subnet_1"/></ETHERNET-hardware-access>

</ecu> </ecus><CAN-hardware-access>

<Clusters Names=""/><device-id cluster="DEFAULT" boardid ="0" controllerid="0" ISO-

Mode="true"/><device-id cluster="CHASSIS" boardid ="0" controllerid="1" ISO-

Mode="true"/></CAN-hardware-access>

<ETHERNET-hardware-access><device-id device="eth3" ethProtocol="802.1Q" OVLAN="1798"

subnets="subnet_1,subnet_2,subnet_3" displayServiceInfo="true"/></ETHERNET-hardware-access>

<code-gen simulateEcu ="true" skipCANRxMessages="false"/><Discard-E2EDecode-Failed-PDU value = "false" />

<display-settings PDUType ="Both" serviceType ="ID" OfrSvcPrefix ="osvc_" ReqSvcPrefix="rsvc_" EventGrpPrefix ="evgrp_" ethPDUDirec-tion = "true"

OfrSvcHierarchy="OfferedServices" ReqSvcHierarchy="RequestedServices" ethHierarchy ="Ethernet" canHierarchy = "CAN" groupByCluster="true"/> <GTS><SubTlv-TimeSynchronization EthTSynTLVFollowUpTimeSubTLV="true" CRC-TimeFlags="63" EthTSynTLVFollowUpStatusSubTLV="true" EthTSynTLVFol-lowUpUserDataSubTLV="true" /> </GTS>

</file></autosarfiles><IncrementVirtualClock value="true" period-ms="1" />

</networkmodule>

3.4 Removing a Network module

• Right-click on a module.

Context menu is displayed.

• Click Delete to delete a Network module.


18


3.4.1 Rest Bus Simulation of a Network Module

Network Module Hierarchy in ETAS Experiment Environment

The following figure shows the hierarchy of components in a Network modulefor CAN/CAN-FD shown in the ETAS Experiment Environment:



The following figure shows the hierarchy of components in a Network modulefor Automotive Ethernet shown in the ETAS Experiment Environment:


20


The Network module components are arranged as shown in the following figure:

Supported AUTOSAR Features

The following AUTOSAR features are supported in Network module.

• Global time Synchronization:

The entire Network module can be synchronized by Global Time Synchro-nization method specified in AUTOSAR. Currently the CAN/CAN-FD net-work and the Automotive Ethernet networks can be synchronized together. This globally synchronized time can be seen under every ECU as <ECUName>_GlobalSyncTime.

• Support for Sub TLVs in AE:

The support for Sub TLVs in AE is in addition to the existing support of SYNC and FUP frames for GTS for AE.Also, enablers for CAN/CAN-FD, AE SYNC and Follow-up packets are available.Additionally the transmission of the following Sub TLVs as part of FUP message from GTS time master is supported:

– Time secured sub TLV

– Status secured sub TLV

– User data secured sub TLV



The Sub TLVs are enabled for transmission by default and can be config-ured in NetworkConfiguration.xml.

<GTS> <SubTlv-TimeSynchronization EthTSynTLVFollowUpTimeSub-TLV="true" CRCTimeFlags="63" EthTSynTLVFol-lowUpStatusSubTLV="true" EthTSynTLVFollowUpUserDataSubTLV="true" /></GTS>

• Ethernet Monitoring:

The Automotive Ethernet communication between two ECUs can be monitored using this feature. The set up should look as below.

To monitor an ECU, the ARXML file of that ECU should be added to in Network configuration XML and the tag „simulatedECU“ in Network con-figuration XML has to be set to „false“ for the ECU that needs monitor-ing. The mirroring device is an external device that is capable of repeating the messages that are transmitted through it. In the above diagram ECU1 transmits data from ECU1 to ECU2 via Mirroring Device and Mirroring Device repeats the message to LABCAR.

• E2E Protection:

The following E2E Profiles are supported in LABCAR as per the AUTOSAR specification.

– Profile 2

– Profile 5

– Profile 6

– Profile 7

Note

While monitoring, only the received messages will be displayed in the Experiment Environment.


22


• Update indication bits support

Update indication bits configured under PDUs in ARXML need to have relevant signals in Network module in CEE.Update bits can be configured for signals, signal groups and PDUs.The length for these signals is 1 bit as it indicates only two possible values, 0 or 1.The following example from ARXML shows how the signal will be config-ured:

– Frame: PDU-To-Frame-Mapping attribute for PDUs

– PDU: I-Signal-TO-I-PDU-Mapping attribute for signals or signal groups

Special Ports in a Network Module

Trigger:

Triggers have a behavior similar to "SingleShot" in a NIC module. If there is avalue change with respect to a 'Trigger' inport from '0' to '1', it will cause atransmission of the respective PDU. By default, the value of a Trigger is '0'.

• If the user changes the value of a Trigger from '0' to '1', it will cause a transmission once.

• If the user changes the value of a Trigger from '1' to '0', it will not cause any transmissions.

• If the user changes the value of a Trigger from '1' to '2', it will not cause any transmissions.

Enable:

This inport is used to enable or disable the component. If it is set to “1”, then thecomponent is enabled. If it is set to “0”, then the component is disabled. Thedefault value for this inport at ECU level will be “0”. In all other components(Frame\PDU), the default value is “1”.

Statistics:

This section provides the details about the statistics of the communication. Thissection will be available at Module\ECU\PDU levels.

PDU Level Statistics:



This section provides information to the user as to how many triggers(cyclic\spontaneous\mixed) have occurred for PDU and how many transmissionsand receptions occurred for PDU.

Fig. 3-6 PDU Tx Level Statistics

Fig. 3-7 PDU Rx Level Statistics

FindService_HaveOffer:

This outport is available under every consumed or requested service statistics ofECUs. The possible values for this outport are "0" and "2".

The value 0 indicates that the service is requested but currently offered by pro-vider ECUs.

The value 2 indicates that the service is requested and offered by provider ECUs.

EventGroup_Subscriber_Count:

This outport is available under every event group statistics of provided or offeredservices of ECUs. The outport displays the count of ECUs that have successfullysubscribed to the event group.

EventGroup_Subscribe_Ack:

This outport is available under every event group statistics of consumed orrequested services of ECUs. The possible values for this outport are "0", "1" and"2".

The value 0 indicates that the event group is not subscribed.

The value 1 indicates that the event group subscribed successfully with a positiveacknowledgment from the service provider.

The value 2 indicates that the event group subscription was attempted but anegative acknowledgment from the service provider was received.

E2E_Status:

This outport will be available under every received E2E protected PDU by thedifferent AUTOSAR profiles 2, 5, 6 and 7. For the values that are possible underthis signal, please refer to the AUTOSAR specification of E2E profiles.

Manipulations in Network Module

DLC for CAN\CAN-FD frames:


24


Every transmitted CAN\CAN-FD frame will have an inport called 'DLC' which willhave the default length value from ARXML. The user can manipulate this valueduring the simulation.

CRC, SQCs for E2E profiles:

Every transmitted PDU protected by E2E profiles 2 or 5 or 6 or 7 will provideinports for manipulating CRC and SQC signals. The behavior is defined below:

– If the CRC\SQC signal inport value is < 0, the calculated value shall be used during transmission.

– If the CRC\SQC signal inport value is >= 0, the manipulated value at inport shall be used during transmission.

– The default value at inport should be -1 for CRC and SQC.

FreshnessMode:

This inport will be available under every ECU. The possible values for this inportare described below:

– Value 0: Use the freshness value based on customer specific calcula-tions.

– Value 1: Use the freshness value at inport 'FreshnessManip'.

– The default value at inport is 0.

SwitchToHex:

Every signal in a transmitted PDU will have a 'switchToHex' to decide the behav-ior of the signal inport. Possible values for this signal and the behavior aredescribed below:

– The value 0 indicates that the signal inport is interpreted as a physical value. This is the default value for every "SwitchToHex".

– The value 1 indicates that the signal inport is interpreted as a hexa-dec-imal value.


ETAS The Network Module APIs

4 The Network Module APIs

COSYM exposes the REST API Interface exposed by the Network module.COSYM uses the Swagger framework. With this framework, the server, clientand documentation are synchronized.

COSYM REST API responses are in JSON formats. COSYM REST API clients cancurrently be generated for Java, JavaScript, C#, and Python language only.

There are 7 Network module REST APIs exposed as COSYM REST APIs for theoperations below.

1. Create network module

2. Import network module

3. Update Network module

4. Migrate the network module

5. Generate the code for the Network module

6. Get the Network Module add-ons

7. Delete Network module

Operation Component Request mothod

Request URL

Create network module

Target POST /v1/projects/{projectId}/targets/{targetId}/modules

Import network module

Models POST v1/projects/{projectId}/models

Update Network module

Target PUT /v1/projects/{projectId}/targets/{targetId}/modules/{moduleId}

Migrate the network module

Target PUT /v1/networkModel

Generate the code for the Network module

Target PUT /v1/hardwareModel

Get the Network Module add-ons

Target GET /v1/networkAddons

Delete a network module

Target DELETE /v1/projects/{projectId}/targets/{targetId} Deletes a target based on the target id

LIN Editor - User’s Guide 25

26

The Network Module APIs ETAS

4.1 Interface

Interface feature in COSYM opens the Swagger editor to work with the Net-work Module APIs which are embedded with the COSYM REST APIs. The Inter-face gives clear insight on how the API responds to parameters and options.

Follow the step below to open the Swagger editor from COSYM where you cansee the Network Module REST API and use it interactively:

• Go to Help menu → API → Interface on the Proj-ect dashboard in COSYM.

Swagger editor is displayed. Refer to the "Chapter 16 - COSYM REST APIs" in the "COSYM_V2.1.0_User's_Guide.pdf" document for more details.

4.2 An example on how to use Network module API

An example is given below on how to use the swagger API through COSYM.

This example demonstrates how to migrate the network module through RESTAPI.

Firstly, open the Swagger editor through COSYM.

• Go to Help menu → API → Interface on the Proj-ect dashboard in COSYM.

Swagger editor is displayed as shown below.

COSYM REST APIs in Swagger editor:

The REST APIs in the Swagger editor are available in the "Target" component.

Fig. 4-1 Migration API in the Swagger editor

LIN Editor - User’s Guide

ETAS The Network Module APIs

Each API contains request URL, description of an API and the parameter(s) whichneeds to be passed to get the result.

In order to migrate the Network module, you should have the module name andthe model path.

• Click Try it out.

Here, in this example, the name of the model (name) and the file and the path of the network configuration file (uri) are mandatory parameters which are need to be passed.

name: "nwmdl"

uri : "C:\temp\testprj\Hard-ware\HiL_target\nwmdl\Gener-ated\nwmdl\NetworkConfiguration.xml"

LIN Editor - User’s Guide 27

28

The Network Module APIs ETAS

• Click Execute.

The specified Network module will be migrated. The response shows Successful for the successful execution of the API call.

Fig. 4-2 An example to use Network module API

LIN Editor - User’s Guide


ETAS ETAS Contact Addresses

5 ETAS Contact Addresses

ETAS HQ

ETAS GmbH

ETAS Subsidiaries and Technical Support

For details of your local sales office as well as your local technical support teamand product hotlines, take a look at the ETAS website:

Borsigstraße 24 Phone: +49 711 3423-0

70469 Stuttgart Fax: +49 711 3423-2106

Germany WWW: www.etas.com

ETAS subsidiaries WWW: www.etas.com/en/contact.php

ETAS technical support WWW: www.etas.com/en/hotlines.php

http://www.etas.com/en/contact.php

http://www.etas.com/en/hotlines.php

http://www.etasgroup.com



http://www.etas.com

ETAS Figures

Figures
Fig. 3-1 Project dashboard in COSYM........................................................................ 7Fig. 3-2 A context menu on a target.......................................................................... 8Fig. 3-3 Network module in the text editor ................................................................ 8Fig. 3-4 Deployment Management in COSYM ........................................................... 9Fig. 3-5 Import Model window................................................................................ 10Fig. 3-6 PDU Tx Level Statistics................................................................................. 23Fig. 3-7 PDU Rx Level Statistics ................................................................................ 23Fig. 4-1 Migration API in the Swagger editor ........................................................... 26Fig. 4-2 An example to use Network module API ..................................................... 28

ETAS Index

Index
AAUTOSAR features, supported 20
CCreate 7

EEdit 11ETAS Contact Addresses 29

HHardware Requirements 6

IImport 9Importing 9

NNetwork Configuration 12Network Module Ports 22Network Modules 6

OOperation

conventions 5

PPDU Tx Level Statistics 23

RRemove 17Rest Bus 18

SSoftware Requirements 6


network module user’s guide - home - etas...network module - user’s guide 5 etas introduction...

Documents