Direct data exchange between PLC and XML/JSON based data aggregator

1. © Feri Handoyo
IMPLEMENT
XML/JSON DATA
EXCHANGEINPLC
DESIGN & IMPLEMENTATION REALTIME PLC
COMMUNICATION USING APPLICATION LAYER FORMAT
RUN
TCP/IP (DATA LAYER)
DATA CONSUMER
TCP/IP (CONTROL SYSTEMS LAYER)

2. © Feri Handoyo
page 2
Background
• Data centric project to aggregate real time process control information
into a dedicated data server.The data can later be used as part of
automation of the data exchange in the move towards Industry 4.0.
• Avoid the use of additional layer in the IT space (i.e. custom application to
act as data exchange such as OPC to XML converter).This means less
software application to maintain.
• Decision is to implement the gateway functionality in a PLC.The main
advantage is connection to process control is easy (all kind of protocols
available between PLCs) and it will be just additional PLC nodes in the
system.

3. © Feri Handoyo
page 3
Objectives
• A data gateway PLC to consolidate data from control systems (other PLCs)
• The gateway PLC communicates to Data Consumer in real time over
TCP/IP using object style data structure (XML or JSON). Data Exchange is
2 way:
• From PLC: Process Control Data
• To PLC: Production Instructions (e.g. Schedule, Recipe)
• The data structure must be configurable, must allow nested objects and
must support arrays or nested objects.

4. © Feri Handoyo
page 4
TheProblems
• PLC memory limitation (up to 40MB)
• String intensive application to construct send and interpret received telegrams
• PLC CPU power limitation
• Limited CPU power to process up to 5 level deep nested objects and can be
repeated for up to 200 times at each level. Nested loop calls may crash some
PLC brands due to running out of stack.
• Delay in processing outgoing telegrams if PLC cannot generate structure
in timely fashion.
• Even longer delay or error in processing incoming telegrams if PLC cannot
identify (deserialize) correctly.
• How to efficiently manage changes to the data structure.
• Using a traditional PLC (not the PC based PLC).

5. © Feri Handoyo
page 5
DataStructure(Example)
• A configuration file (.xml) is defined in Data Consumer.This file contains
the definition of data types and telegram types.
• A user defined data type called DataType1 can be defined as:
<type name=“DataType1">
<comment>Description about DataType1</comment>
<elements>
<element name=“GroupName" type=“string” length="100" repeat="1">
<element name=“CountProcessValues" type=“integer” length=“4" repeat="1">
<element name=“ProcessValue" type=“TypeProcessValue” length=“184" repeat=" CountProcessValues">
</elements>
</type>
• In example above, an element called ProcessValue is a nested object of
typeTypeProcessValue. Additionally it will be repeatable (array) by the
value of the integer element CountProcessValues.

6. © Feri Handoyo
page 6
DataStructure(Example–cont’d)
• User defined typeTypeProcessValue will have similar structure:
<type name=“TypeProcessValue ">
<comment>ProcessValue in PLC</comment>
<elements>
<element name=“VariableName" type=“string” length=“48" repeat="1">
<element name=“VariableValueString" type=“string” length="100" repeat="1">
<element name=“VariableValueReal" type=“real” length=“4" repeat="1">
<element name=“VariableValueDateTime" type=“datetime” length=“16" repeat="1">
<element name=“UnitOfMeasurement" type=“string” length=“16" repeat="1">
</elements>
</type>
• In example above, PLC values may be string, real or timestamp. Realtime
data will need to be mapped to the target element.
• User definedTelegrams are also defined in similar manner.

7. © Feri Handoyo
page 7
DataStructure(Example–cont’d)
• User defined telegrams ReadWritePLCTags may be defined as:
<telegram name=“ReadWritePLCTags ">
<comment>Telegrams to read or write PLCTags</comment>
<elements>
<element name=“Definition" type=“GenericDef” length=“64" repeat=“1">
<element name=“GroupData" type=“DataType1” length=“288" repeat=“12">
</elements>
</type>
• In example above, the GenericDef contains basic telegram data used for
Telegram Name, Quality Check, Handshake, Message ID and time stamp.
• In this example, element GroupData of type DataType1 is created and
repeated 10 times. Assuming a fixed value of 15 is used for each group
(CountProcessValues =15),Total length of each transaction for this
telegram=12x((15x184) +104)=34368 bytes.

8. © Feri Handoyo
page 8
DataStructure(Example–cont’d)
• Assuming a fixed value of 15 is used for each group (element
CountProcessValues =15), the telegram ReadWritePLCTags will have to be
instantiated for exchange as:
VariableName
VariableValueString
VariableValueReal
VariableValueDateTime
UnitOfMeasurement
CountProcessValues
GroupName

9. © Feri Handoyo
page 9
Prompts
• How to manage large number of strings and unused space (reserved
element length)
• How to build reliableTCP socket interface with multi thread support and
efficient buffering for data exchange (some telegrams can grow more than
1.5MB in each transmission).
• How to manage the flexible telegram structure in PLC? Especially for the
large telegrams.
• How can we efficiently map process values and include in sent telegrams
on the fly? How can we efficiently extract values from telegram fields into
process values on the fly?
• Nice to have: how can we process the config XML file directly and pass it
to a format that PLC can understand, by simply selecting the file and hit a
button (macro or script).

10. © Feri Handoyo
page 10
Solution
String Map
Data Model
Reserve string for
what is used. Do not
use array fixed strings.
Embed Cross
Reference in telegram
body for fast and
accurate update.
Variable Map
Data Model
PLC variables are
consolidated into a
centralized area.
Addressing is simple
equation that will
point to the correct
tag.
Embed the Cross
reference in telegram
body for fast and
accurate update.
Telegram
Vessels
Recursively and
asynchronously
generate telegram
vessels based on
loaded XML config.
Embed cross
references to strings
and process values in
telegram body.
Sending is a simple
copy of a vessel with
payload intoTCP
buffer.
Auto Config
Tool
Custom built tool
allows loading XML
file as-is and format
into model that PLC
cand use.
Config function block
in PLC accepts this
data and generate
telegram vessels.
TCP Buffers
Use the same
structure as String
Map Data Model to
allow directly reflect
references to
incoming telegrams.
Rotating buffers to
avoid collision.

11. © Feri Handoyo
String Map
Data Model
Reserve string for
what is used. Do not
use array fixed strings.
Embed Cross
Reference in telegram
body for fast and
accurate update.
page 11
Solution(StringMapDataModel)
• A PLC variable of string data type to contain ALL strings that will be used
in telegrams.
• Only unique strings are stored and each only occupy used length.
• Reference book with location of each string.
• Telegrams andTypes share common strings.They are replaced with a 4
bytes integer reference as opposed to the complete string length.
• EachTelegram has information only for dynamic strings.
• To send telegram, only update dynamic fields.
• To process incoming telegram, simply superimpose the reference book
on the data inTCP buffer and extract strings out.

12. © Feri Handoyo
page 12
Solution(VariableMapDataModel)
• Similar approach to the string data model, a PLC variable of variable
data type to contain ALL data mapping that will be used in telegrams.
• Reference book with location of each variable with a simple formula to
derive each tag location into a 4 bytes address.
• EachTelegram has information for variable mapping in its body.
• To send telegram, variable values are always pointed in its fields. Simply
copy data from the source into telegram vessel at specified location.
• To process incoming telegram, simply superimpose the reference book
on the data inTCP buffer and they will point to target variables.
Variable Map
Data Model
PLC variables are
consolidated into a
centralized area.
Addressing is simple
equation that will
point to the correct
tag.
Embed the Cross
reference in telegram
body for fast and
accurate update.

13. © Feri Handoyo
Telegram
Vessels
Recursively and
asynchronously
generate telegram
vessels based on
loaded XML config.
Embed cross
references to strings
and process values in
telegram body.
Sending is a simple
copy of a vessel with
payload intoTCP
buffer.
page 13
Solution(TelegramVessels)
• EachTelegram will be recursively exploded in PLC memory.The process
may have to be spread across multiple PLC scan to avoid stack overflow.
• A PLC function block will have custom stack. It will continue the iteration
at every call based on the stack values.
• A flag in each telegram vessel indicates if it is ready for use.
• Actual vessels are created only for outgoing telegrams with all the
references to string and variable maps.To send a telegram, simply copy
the vessel intoTCP buffer area and include strings and variables
referenced in its body.
• To process incoming telegram, superimpose telegram reference table
onto theTCP buffer and read the values directly out to target variables.

14. © Feri Handoyo
TCP Buffers
Use the same
structure as String
Map Data Model to
allow directly reflect
references to
incoming telegrams.
Rotating buffers to
avoid collision.
page 14
Solution(TCPBuffers)
• Implement a reliable Socket Interfaces (client and server).
• RotatingTCP Buffer to avoid collision. PLC locks a buffer area for read to
prevent new arrival to the same area.
• TCP buffer has the same structure as String Map Data Model.
Superimpose the lookup reference with template data makes telegram
processing faster.

15. © Feri Handoyo
Auto Config
Tool
Custom built tool
allows loading XML
file as-is and format
into model that PLC
cand use.
Config function block
in PLC accepts this
data and generate
telegram vessels.
page 15
Solution(AutoConfigTool)
• A configuration tool is developed to parameterize the PLC.
• It allows using the same XML file as is used in Data Consumer.A click of a
button or running of script will translate the XML into format that PLC
can process.
• Receiving Function Block in PLC performs the actual build.

16. © Feri Handoyo
page 16
Summary
The solution has been implemented successfully on Rockwell PLC and working in
progress to adapt to SiemensTIA, Schneider and GE PLCs.
This can be used for all kind of industries to map their data to a data aggregator with
high level interface.This opens the pathway to data exchange automation as part of
Industry 4.0 initiatives.
Points to consider:
- No need of additional data exchange box (e.g. OPC, etc) and no need to have custom
software built to translate process data into supported interface.
- PLC-PLC data map is easy, many options available
- Opens possibility to include other equipments (VSD, analysers, etc)

17. THANK
YOU
Feri Handoyo