Introduction to CC-Link IE TSN

CC Link IE TSN is an ethernet based industrial communication stack. It is based on earlier CC Link IE concepts, uniting them with the ideas of time synchronized networking (TSN). The standards are maintained by the CC Link Partners Association (CLPA).

In a CC-Link IE TSN network, all stations perform time synchronization using either PTP IEEE1588v2 or gPTP IEEE802.1AS. The time synchronization is performed in the initialization sequence and periodically during the runtime sequence.

Communications are performed with the communication cycle divided into time slots as a time sharing method. Settings related to the time sharing method are configured once in the initialization sequence.

Table 3: Example of time slots in a cycle

In this example Tslt1 is used for the cyclic communication, Tslt2 for the time synchronization and Tslt0 for everything else. Length and order of the timeslots can be configured as needed, but the catch all timeslot is usually last. Some extras, such as guard banding etc. are also possible options. 

All devices taking part in the cyclic communication will observe these timeslots. Common start time of the timeslots is ensured by the time synchronization.

Central Concepts

SLMP

SLMP (Seamless Messaging Protocol) is a protocol used to implement communication between applications seamlessly without awareness of the network hierarchy and boundaries. It is often used in communication between the CC-Link family network and other general-purpose Ethernet devices.

SLMP messages are defined as payload, using a lower level network service such as TCP/IP, UDP or CC Link IE TSN as transport layer. In the port CC Link IE TSN implementation, SLMP is provided by GOAL and uses UDP.

The CC Link IS TSN stack uses SLMP messages extensively for the setup process.

TSN

Two methods for time synchronization are supported by CC Link IE TSN:

• PTP, described in IEEE1588v2

• gPTP, described in IEEE802.1AS

Both methods used timestamped ethernet frames to determine delays and derive a timestamp that is the same on all devices in the system. In the port CC Link IE TSN implementation, they are provided by the underlying GOAL runtime. For both methods, the ethernet controller of the hardware needs to support time stamping of incoming and outgoing frames. For gPTP, two hardware clocks should be provided, though the implementation in GOAL also works with just one.

Qbv

While TSN ensures common starttime of cycles, another mechanism is needed to ensure messages are only sent inside of the corresponding timeslots. For each message to be sent, it must always be checked if the timeslot is open and if the message can be fully transmitted inside of it. If not, the message must be queued for the next transmission cycle.

Every time a timeslot opens, it will check if there are queued message to be sent.

This is standardized in IEEE802.1Qbv. Qbv can be supported by hardware or simulated in software. The software variant requires calculation effort that often makes it only usable for Class A devices.

Link Devices

The data that is transferred, is locally organized in so-called link devices. These differentiate by direction and by data type.

Table 4: Overview of link devices

*not yet supported 

Remote Stations provide data in link devices with predefined sizes, positions and meaning. The master device selects data for cyclic transfer from the available link devices by defining payloads during the communication setup.

The statusword link device is standardized data provided only in the direction from remote stations to the master. It contains predefined bit data concerning the status of the remote station and its cyclic connection.

Communication Setup

Process

The communication is set up in four discreet steps:

Detection

The master broadcasts requests to any CC Link IE TSN device on the network to identify themselve and check their capabilities. Remote stations announce their capabilities including i.e. station number, TSN mode etc. Only if this fits with information previously set in the master, can the process continue.

The master will periodically send out further detection requests even after cyclic communication is established. This is meant to discover newly connected devices and any remote stations already communicating will no longer respond.

Network Configuration

After detection, the master will configure network settings of the detected station and will configure and start the time sync process between master and remote station. The timeslots are configured on the device during this step but not yet activated.

Slave Configuration

The remote station will active a station mode, switching from the default if necessary.

Only if the time sync process has completed successfully at this time, will it now expect a cyclic configuration.

Cyclic Configuration

During cyclic configuration, the master will now set up which data from the link devices will be put into the cyclic communication frames.

Once this step completes successfully, the devices will start cyclic communication automatically.

Remote Station Setup 

A remote station is configured by the master during communication. As such it needs little local setup beforehand:

• The link devices need to be setup.

• The station number must be set.

• The (default) station mode must be set.

This tool will create code that handle these steps. It will also create an entry point to enter a custom application. The application is responsible for updating the link devices with data (i.e. from attached sensors) and for handling incoming data from the master (i.e. control commands).

Master Setup

The master SDK is intended to create a PLC, which will require dynamic knowledge on all connected slaves. The ICC can only create static setups and therefore does not support the master SDK; see the master examples: 01_master or 03_master_ct instead.

CSP+

CC Link IE TSN uses device description files in an Xml format, called CSP+ files. These can be exchanged between device developers to facilitate information exchange. Many engineering tools allow importing of device descriptions into their system; this often then allows an easier setup for the customer.

The tool will automatically transfer all information needed into a CSP+ file.

CANopen data access

The CANopen object dictionary and its data transfer methods have established themselves as very flexible and workable ideas that have found their way into other communication standards. In CC Link IE TSN the idea of a CANopen like configuration and object access can be used as an alternative option to the regular methods.

If enabled, an object dictionary as in CANopen will be used to store local data. To transfer this data, the word link devices will instead be used to address individual CANopen objects in the object dictionary. Configuration and Transportation of the transfer are managed with methods similar to CANopen PDOs and SDOs.

With the help of the PDO Assignment objects and the PDO Mapping objects it is possible to precicly define the byte stream transfered in the cyclic data. This process thus offers a more customizable way to get specific data without being dependant on preexisting data formats. Due to the wide dissemination of CANopen and the reusage of some of its concepts in other standards (i.e. EtherCAT, PowerLink) this process is often already known by the device developers.

Object dictionary

All device parameters are stored in an object dictionary. This object dictionary contains the description, data type and structure of the parameters as well as the address composed of a 16‑bit index and an 8-bit sub-index. The object dictionary is organized in different sections:

Table 5: Structure of the CANopen object dictionary

Service Data Objects

Service Data Object (SDO) represents a CANopen service based on the client/server model. This service allows the access to all objects and is used for configuration purposes.

In CC Link IE TSN SDO communication is realized through spezialized SLMP commands. This also means that no special SDO configuration or objects (in the object dictionary) are needed.

Process Data Objects

Process Data Object (PDO) represents a CANopen service based on the producer/consumer model.

The content of PDO messages is determined by the PDO mapping. The PDO mapping is specified in profile standards or can be set by the manufacturer. A PDO mapping may be preconfigured in the local device or be dynamically set by a master.

This service is configured via the PDO communication and PDO mapping parameters, and the PDO configuration objects.

Table 6: PDO Settings