CANoe.CANopen enables efficient planning, management, simulation, test and startup of CANopen networks. During the system design phase the user has the opportunity to simulate the later behavior of a system, estimate the bus load, and draw conclusions, like the necessary hardware performance, supported with extensive, CANopen-specific functions.
CANeds and ProCANopen included
A significant aspect of CANoe.CANopen is the automatic generation of simulation models. The application oriented C-based language, CAPL (communication access programming language) from Vector is used as the programming language for this purpose.
All information necessary for the generation exist in the device descriptions that are set up using ProCANopen. The entire CANopen-specific functionality of an ECU is simulated by a nodelayer-DLL. The user can utilize the functionality of this DLL by means of function calls from a generated CAPL program. This makes it very easy to initiate a SDO access to another device in the network from the CAPL program.
Automatic Test Generation
It is easy to generate test sequences for CANopen devices. The necessary test functions are identified and assembled into a sequence, based on device descriptions existing in standardized format (EDS files). CANoe.CANopen runs through these sequences. All test results are conveniently logged and documented to a report file. The following test scenarios can be generated:
Full coverage of the CiA310 test specification, which forms the basis of the CiA Conformance Test, is thus ensured.
Creating application tests easily
A test environment for a CANopen network can be generated at the press of a button. In turn, this makes it easy to create application tests. Simulated network nodes can be "remote controlled" by a user created test sequence. The user triggers a PDO transfer from the simulated node to the DUT (device under test) by a simple function call. Another function call by SDO reads the output value from the DUT and compares it to the target value.
Communications monitoring and analysis
In a trace window the CAN message traffic is displayed while simultaneously interpreting the protocol information it contains. The user not only sees the service that is currently being executed, but can also see all relevant service parameters at a glance. This information is displayed in clear text and gives the user a quick overview of the chronological order of individual protocol sequences for the observed CANopen services thereby making it significantly easier to localize errors in a real system. If there are any signal definitions (objects segments which can be defined within the new XML standard) made within the EDS file, those signals are displayed in the trace window automatically.
The CANopen Scanner evaluates CAN messages and shows the active nodes in a list. Other node-specific information is also output, such as the node state and device name.
The object directory for an individual device is shown in a tree structure that is structured as a function of user inputs. The objects to be shown are taken from the EDS file for the relevant device. It is easy to read-out and modify device parameters that are mapped into a device by object dictionary entries. This is how the user can configure necessary settings in a device. In the modification of PDO parameters the access dialog considers the access order specified by the CiA 301 communications profile. If no EDS file exists for a device, it is still possible to access the object dictionary by a special dialog. Changes to device parameters are stored separately for each device in a device configuration file (DCF).
CANoe.CANopen uses the standardized file formats EDS and DCF to store data. Also the new XML format (XDD and XDC) regarding CiA 311 is supported by the CANoe.CANopen. Simple data exchange with any other CANopen tool such as CANalyzer.CANopen is guaranteed.
For more information, application notes and a demo version please refer to Vector's website: www.canopen-solutions.com/canopen_canoe_en.html