Features in detail
Data logging
Vehicle data must be recorded for testing and analysis purposes – the evaluation takes place offline at a later time. The very high volumes of data require intelligent mechanisms for limiting data. These include selective logging of individual signals or messages using filters, an event-triggered "start/stop" feature and the automatic overwriting of old, unnecessary data. The data logging feature also has an energy-saving standby mode that can be quickly ended using the "Wake On" function when the product is in use.
Reading and writing data
In-vehicle networks are closed systems within a vehicle. These systems are not described on a single device basis, as in industrial systems, but on a network basis using message catalogs (DBC, Fibex, ARXML, LDF, A2L and others). These descriptions allow the recorded data to be decoded and evaluated. When using HMS products, users have the choice of recording the data on a message-based or signal-based basis in order to achieve the optimal result tailored to the respective application.
Flexibility through customized triggers
All data logging solutions from HMS include an integrated trigger function. This consists of individual events that trigger the logging process, i.e. start or end it. These include, for example, exceeding a threshold value, receiving defined messages or logical links between events.
Diagnosis
Various diagnostic protocols are supported. Diagnostic data or update functions can be sent to control units using the optionally available D-PDU API or via DoIP.
Gateway
The gateway is the main application of every configuration being executed on the CANnector, Mobilizer or FRC-EP series. It is not only providing the data transfer from one CAN bus to another, it also allows to connect logical bus systems – like user code, data logger, Matlab/Simulink, etc. – to the overall data exchange. With this strategy it is possible to route every frame, PDU or signal individually from source to destination. This can be operated directly or for example via customized user code to manipulate the data on the fly.
How can you configure a gateway application? All you need to do is to use the gateway view of the ACT tool and use the drag & drop concept to define the source and destination relation. Just drag the desired data from the source bus and let it drop on the destination – not relevant whether this is a real bus system or the user code, logger or something else. At the end, the created configuration can be loaded on an Ixxat embedded platform and executed standalone.
FlexRay / CAN / CAN FD / LIN
Bus description files can be used for these interfaces, but it is not required to use them. If provided, it helps you to easily configure a signal-based gateway because you can select the signals out of the bus description file and map them to another bus with an underlying description file. So, it is thereby possible to combine signals from different source messages into one target message.
But what if the physical signal representation doesn’t match between source and destination? In this case you can either activate an automatic signal transformation or use your user code or a specific MATLAB/Simulink model to do complex signal adjustments.
And how are the generated frames sent on the destination bus? Therefore, several options are available:
- Event triggered by the reception of one or many source signals
- Event triggered by the value change of one or many source signals
- Cyclically with the cycle time defined in the corresponding CANdB
- Cyclically with your manually adjusted cycle time
- Based on a trigger signal which can be generated by – for example – your user code
- A combination of the possibilities above
But some signals don’t need a changing value? Yes, that might be the case. In such a case you can use a static default value for these signals. This can be a static value defined in the underlying bus description file or a personally defined value.
Configuration of an LIN-2-CAN-Gateway:
- Use our free of charge ACT Software
- Import your LDF file
- Select the signals and frames which should be routed to CAN(FD)
- ACT can generate new DBC
- Or you import your DBC/ARXML File and “map” via drag&drop your signals to your DBC-signal/frames - In addition you can create a visualization with our websocket als via drag&drop
- If you want to manipulate signals, use our C-User-Code
- Download the configuration to the device
Ready !
EtherCAT
You need to connect your CAN (FD), FlexRay or LIN based system to modern industrial communication? No problem, just choose a CANnector, Mobilizer or FRC-EP series device with an EtherCAT extension. Inside ACT you can then use the easy drag & drop concept to generate mappings from/to the EtherCAT slave. ACT also automatically generates a corresponding ESI file which can be used together with any capable EtherCAT master to comfortably configure your EtherCAT network.
Once connected to EtherCAT, all data – coming from the CAN (FD), Flexray or LIN bus system or from any other EtherCAT based sensor or IO device – is distributed synchronized and on the same communication system to your SPS or PC controlling the test execution.
Analog / Digital IO
The FRC-EP, Mobilizer and CANnector devices do also provide analog or digital I/O ports. ACT allows to use these signals like any other signal in your configuration. After configuration of data direction, range of values, conversion rules and unit, the IOs can easily be mapped via drag & drop from/to any other bus system.
Virtual bus
By means of ACT you can add the virtual bus to your configuration. The virtual bus can be used to define your own “variables” (environment variables) in the configuration. These variables can be mapped via the drag & drop concept to/from any other bus system. This allows – for example – to calculate such a variable by your C user code module and then use it in any other bus system.
DBC Generator
One functionality of the gateway is to generate DBC Files based on the mapping of the different physical and logical buses – for CAN, CAN FD, Generic Ethernet, virtual CANonEthernet, CAN@net.
FDX
XCPonEthernet is too complicated for you? No problem, you can also use the much easier Fast Data Exchange protocol to connect third party software solutions with the CANnector, Mobilizer or FRC-EP series device. With ACT, all needed signals are mapped via the drag & drop concept from/to the FDX bus system. ACT is automatically generating the corresponding XML description file for the FDX bus. This XML file can be imported into your software solution and you are ready to read or send data.
Generic Ethernet / CAN@net / Virtual CAN(FD)onEthernet
You want to reduce cabling or to bridge large distances? Our Generic Ethernet protocol is easily solving this challenge. Generic Ethernet is a virtual CAN(FD), FlexRay or LIN bus system on Ethernet. By means of ACT you can map the desired data from/to the Generic Ethernet bus system.
The data is then distributed via Ethernet and can be turned back to the physical protocols by using a counter CANnector, Mobilizer or FRC-EP series device. This is called the classical range extender.
In case that you intend to connect the data stream directly to a PC, you can use our VCI driver to use the device as a remote PC interface.
Up to 16 of such virtual buses can be configured. You can use this to distribute the desired data not to one but up to 16 different IP addresses or ports. This means that you can create your own Ethernet based communication network and just use CAN(FD), FlexRay or LIN protocols on the “last mile”.
The Generic Ethernet protocol allows also the combination of Ixxat CAN@net devices with CANnector, Mobilizer or FRC-EP series devices. If you don't have enough CAN ports, just use this possibility to extend to up to 136 CAN / 72 CAN FD interfaces.
Your Windows PC doesn't allow to use the VCI driver? Therefore, the Generic Ethernet protocol is very easy to be implemented on any target operating system. In the easiest case you can just use a terminal program to send and receive the data.
Residual bus simulation (RBS)
The Residual Bus Simulation – or Rest Bus Simulation (RBS) – is used to simulate ECUs or parts of a vehicle. Normally you need to code it manually by means of a scripting language – but not with solutions from Ixxat. Our RBS ist generated automatically by means of a vehicle description database you have defined with the integrated vehicle editor. All you need to do is to select the ECUs you want to simulate.
The following work is automatically done by ACT:
- Detecting which messages shall be sent
- Detecting which messages do contain CRCs or alive counters
- Generating the modules which do the CRC and alive counter calculation automatically
- Cross compile the generated C code and integrate it with highest performance into the rest of your testing configuration
All that is done with configuration wizards – there is no programming effort.
You want to influence the RBS? No problem, just add your specific code or algorithm into the automatically generated modules. At the end, the complete configuration including your RBS is executed autonomously on the devices of the Mobilizer or FRC-EP series.
XCPonEthernet
You want to control or adjust the RBS executed on the Mobilizer or FRC-EP series device? For this, XCPonEthernet can be used to connect a third party software supporting this standard.
If needed, ACT generates a A2L description file containing all signals which are sent by the RBS/GW configuration being executed on the device. From the perspective of the third-party tool, the Mobilizer or FRC-EP series device is a virtual ECU. By means of the A2L virtual memory, locations containing the desired signals can be read or written. By doing so, you are able to influence everything that is sent on the different bus systems. This includes also the CRC and alive counters generated by the RBS or signals which a calculated by your user code being executed on the device.
HIL signal manipulation
Based on the FlexRay/CAN RBS and the XCPonEthernet extension, the signals sent by the RBS can be defined and manipulated. This includes, for example:
- On/off switching of signals for a defined time or number of cycles
- Transmission of defined substitute values with switched-off signals
- Defined corrupting of CRCs and alive counters
The control of the signal manipulation can take place via user code, the gateway or XCPonEthernet.
Visualization
The signal visualization is added as a virtual bus to the gateway configuration. It enables easy display and stimulation of all mapped signals via the integrated web server. Any device (PC, smartphone, tablet) can be used as a display device. The only basic requirement is an HTML5-capable web browser. HMS provides a generic HTML page for this. This can be adapted by the user to suit their own requirements. The visualization device is connected via USB, Ethernet or WLAN.
You can individually select which signals shall be visualized and whether they shall be displayed in textual or graphical form. Such a visualization configuration can be stored either on the CANnector/Mobilizer/FRC-EP series or the visualization device. This allows to store views individually or to define by the person having done the configuration what is allowed to be seen.
Do you want to have a specific visualization? If the default visualization is not sufficient, you can easily add your own HTML5 based visualization. You just need to connect to the standardized data exchange stream.
Matlab/Simulink models
For some users, developing C code is too complex, or there are already ready-made models from other projects. These models can be integrated using a separate API. In the same way as the user code, a Matlab/Simulink model can access the mapped signals and messages. This makes it possible to integrate more complex functional models.
If functional models based on Matlab or Simulink already exist, they can be integrated into the overall configuration using ACT. If required, the ACT automatically generates a basic model that contains all the required signals and the framework for signal transformation from the raw value to the physical signal value. The user only has to design the desired functions using Matlab or Simulink or copy the existing model into the basic model. At the end, the executable module is automatically generated from this model and integrated into the overall configuration, which is executed independently on the device.
Usercode
In addition to the possibilities of the standard gateway solution, the intelligent gateways of the Mobilizer, CANnector and FRC EP series offer the possibility of integrating your own functions. For this purpose, the user code bus is added as a virtual bus to the gateway configuration. Signals and messages that are mapped to and from all bus systems using drag & drop serve as input/output for your own code. The user code application is written in standard C and can map specific algorithms. This makes controlling digital outputs or implementing a complex trigger module for the logger easy and convenient.
IxAdmin
IxAdmin is the PC based administration tool (freeware) for the FRC-EP Series, Mobilizer and CANnector platform which can be connected via USB, Ethernet or WiFi.
- Up-/download of configurations
- Management of multiple configurations
- Execution of device updates
- Update firmware/board support package
- Runtime license management
- General settings
- Access to the web-based dashboard
- Access to logger files
- Also available as command line tool
Vehicle Editor
The basis for most solutions are bus description files such as CANdB, DBC, LDF, FIBEX or AUTOSAR-XML. Normally, the descriptions contain a lot of information, but are missing important details like CRC, checksum or alive counter algorithms which are needed to generate e. g. a Residual Bus Simulation (RBS).
The Vehicle Editor allows to create a complete vehicle description database containing all information needed. In case of changes during the life cycle of your testing application (e. g. new vehicle integration levels), a new variant of such a vehicle description database can be created which then allows then an easy porting of existing residual bus or gateway configurations. This saves time and reduces the risk of introducing errors into already verified testing configurations.
