Page History

Terminology

Understanding key concepts is essential when

Terminology 

When dealing with communication protocols, you need to have some concepts clear to understand how they work. Check the definition of key concepts . Below are definitions of important terms used throughout the documentation and inside the platform.:

• Communication protocol:
 
• A set of rules that define how external devices communicate with the software platform.
• Communication driver:
 A software
• Software designed for data transmission between the software platform and an external device following the device's communication protocol.
• TX message:
 
• A message sent from the software platform to the external device.
• RX message:
 A
• A message sent from the external device to the software platform.
• Byte:
 The
• The basic unit of information used in TX and RX messages.
• External device:
 Any
• Any device or software used with the software platform, such as PLCs, sensors, and actuators
, among others
• .

Communication Protocols

The platform supports multiple communication protocols. Each one has , each with specific characteristics and benefits that may suit suited to different applications. The below list describes some of the most used communication protocols, providing brief descriptions.Here are descriptions of some commonly used protocols:

• Modbus:

 Modbus is a

• A serial protocol that uses a master-slave architecture to communicate with external devices. It

is

• operates on a request-response

based

• basis,

meaning

• where the master device sends a request to the slave device and waits for a response before sending the

subsequent

• next request. Modbus supports various data types, including bits, bytes, integers, and floats.

See 

• See Modbus Master Protocol

 and 

• and Modbus Slave Protocol

 for

• for more details.

• OPC UA:

 

• OPC UA (Open Platform Communications Unified Architecture) is a platform-independent protocol based on web services. It uses a client-server model to communicate with external devices

. It

• and supports advanced security and encryption to protect transmitted information.

See 

• See OPC UA Client Communication Driver

 for

• for more details.

• AB Rockwell ControlLogix:

 The AB Rockwell ControlLogix

• This protocol is used to communicate with devices in the ControlLogix family from Rockwell Automation. It uses a master-slave architecture and supports various data types, including bits, bytes, integers, and floats. The ControlLogix protocol is widely used in the industry and is relatively easy to implement.

See 

• See AB Rockwell ControlLogix and CompactLogix devices

 for

• for more information.

• TSimulator:

 The TSimulator

• A simulation driver

is a communication protocol

• that allows users to generate random values in various data types for testing and validation purposes. It is designed to be used with the Devices Module

. It provides flexible options that allow users to create accurate and customized simulations for their systems

• . TSimulator supports multiple data types, including BOOL, INTEGER, FLOAT, STRING, RAMP, and SINE.

For each data type, the user

• Users can configure the minimum and maximum

value the simulation value can reach

• values for each data type and other options, such as string length for

the

• STRING type or ramp step for

the

• RAMP type. Access

the 

• the TSimulator Auto Generated Values page for additional information about the Simulator protocol configuration.

Detailed Functionality

The communication protocol used in SCADA systems has several peculiaritiesunique features. The following subsections delve into explore the essential components and optimization strategies for managing communication between the platform and external devices. 

Read Groups and Write Groups

Read Groups and Write Groups are essential crucial for managing communication between the platform and external devices. They contain information about tags and communication operands and are responsible for , organizing and optimizing the data exchange process. A Read Group reads data from devices, while a Write Group writes data to devices. These groups are dynamically created based on the tags' configuration, such as Access Type, Polling Rate, and addresses, and then are managed by the communication driver.

Communication Optimization

Efficient communication is crucial vital for the performance of any industrial automation system. Several strategies can be implemented to optimize communication between the platform and external devices, such asincluding:

• Grouping tags with similar polling rates and access types.
• Combining sequential addresses in a single request message
reduces
• to reduce the number of messages.
• Adjusting the MaximumBlockSize parameter according to the device's capabilities.
• Using multiple communication channels to prioritize specific requests or handle different devices concurrently.

Read On Display Access Type

The Read On Display Access Type is a setting that enables communication only when data is displayed on the screen. This can improve performance for data that doesn't require constant updates or historical storage. Read Groups and Write Groups are created during the Devices Module startup without considering the Access Type. When a screen opens, the platform checks if any points have the Read On Display setting and are linked to the tags of the open screen. Points with Read On Display AccessType Access Type that are not displayed on the screen are disabled, and the associated group is only turned off if all its points are disabled.

Understanding how the Read On Display Access Type works is essential for efficient communication, as it helps reduce unnecessary data exchange. To learn more information, see see Access Types.

Communication Messages

Communication messages are the foundation of data exchange between the platform and external devices. They transmit information from one entity to another, following a specific communication protocol. There are two types of communication messages:

• TX messages: Sent from the software to the device.
• RX messages: Sent from the device to the software.

Both types contain a series of bytes, each with its specific meaning, following the rules established by the chosen communication protocol. Message types can include the following types:

• Command
• Response
• Alarm
• Status

To better understand the communication process better, let's analyze the Modbus TCP/IP, a real-world protocol. The Modbus TCP/IP is widely used protocol in industrial automation and that allows data exchange between various devices through a TCP/IP network. This protocol uses a client-server model, where the client (the platform) sends requests to the server (the device) to read or write data. The image below describes the structure of the protocol's message.

Where:

Modbus TCP/IP Message Structure

• Transaction ID (2 bytes):
 This
• This unique number helps match requests and responses.
• Protocol ID (2 bytes):
 This
• This is a constant value (0x0000) for Modbus.
• Length Field (2 bytes):
 Specifies
• Specifies the length of the remaining message.
• Unit ID (1 byte):
 The
• The address of the remote device.
• Function Code (1 byte):
 Indicates
• Indicates the requested action, such as read or write.
• Data (variable): Contains the data to be read or written or error information.

Understanding the structure of a specific protocol 's structure is essential to for properly configuring communication between FactoryStudio the software platform and external devices. Each device manufacturer and communication protocol 's creator defines communication message rules. These messages are called TX and RX. TX messages are the messages that go from FactoryStudio the software platform to the device, and the RX messages are the messages that go from the device to FactoryStudiothe software platform. Each entity related to in this “conversation” needs to know the communication protocol to understand what the TX and RX messages mean. Each byte within the message has a specific meaning. Let us consider

Example of a Fictitious Communication Protocol

Consider the following fictitious communication protocol definition:

• [STX]

Where:

• [STX]: Is the start : Start Message (02 hexa).
• [CMD]: Is the Command (04 hexa for a Read Action, 05 hexa for a Write Action, or 06 hexa for Ack Answer).
• [OPR]: Is the operand  Operand (31 hexa for an Integer or 32 hexa for a Float).
• [STA]: Is thestart Start Address - Beginning address to read or write (two bytes).
• [CNT]: Is the counter Counter of the quantity of bytes in the data packet to read or write (one byte) .
• <DATA>: Is the data Data bytes related to the content read or write written (each operand can have 2 or 4 bytes).
• [ETX]:   Is the end End Message (0D hexa).

Based on the above this fictitious communication protocol definition, the following statements are true:

• If the CNT is a single byte
that indicates
• indicating the number of bytes and the FF hex means 255, a communication block can have a maximum of 255 bytes. Thus, each TX/RX can transmit a maximum of 127
(integer)
• integers or 64
(
• floats
)
• , which are the operand limits per communication block. The CNT, or 255 in this case, is the MaximumBlockSize, defined as the maximum size of
the communication block. As defined by
• the communication
protocol, the user generally cannot customize the Maximum
• block
size
• .
• Since a device's available operands can be much larger than the MaximumBlockSize, multiple TX/RX exchanges
can
• may be required to read or write
on
• all the data.
 
• In a TX/RX, a read dataset is called a ReadGroup. Each ReadGroup contains information regarding FS Tags and communication operands. Consequently, the number of operands must be less than the maximum block size.
• ReadGroups and WriteGroups are created during the Devices Module startup.
Also, the
• The Points settings are sorted, and the Groups are sequentially created by considering whether
or not
• two different points can be in the same communication TX/RX. The information considered
is
• includes Node, Address (Operand, Address, Name), MaximumBlockSize, Read/Write Command, and Polling Time.

In this section: