ITER Control System Technology Study

1
ITER Control System Technology Study
Klemen agar klemen.zagar_at_cosylab.com
2
Overview

• About ITER
• ITER Control and Data Acquisition System (CODAC)
  architecture
• Communication technologies for the Plant
  Operation Network
• Use cases/requirements
• Performance benchmark

3
A Note!

• Information about ITER and CODAC architecture
  presented here-in is a summary of ITER
  Organizations presentations
• Cosylab prepared studies on communication
  technologies for ITER

4
About ITER (International Thermonuclear
Experimental Reactor)
5
About ITER
29m
28m
6
CODAC Architecture
7
Plant Operation Network (PON)

• Command Invocation
• Data Streaming
• Event Handling
• Monitoring
• Bulk Data Transfer
• PON self-diagnostics
• Diagnosing problems in the PON
• Monitoring the load of the PON network
• Process Control
• Reacting on events in the control system by
  issuing commands or transmitting other events
• Alarm Handling
• Transmission of notification of anomalous
  behavior
• Management of currently active alarm states

8
Prototype and Benchmarking

• We have measured latency and throughput in a
  controlled test environment
• Allows side-by-side comparison
• Also, hands-on experience is more comparable
• Latency test
• Where a central service is involved (OmniNotify,
  IceStorm or EPICS/CA)
• Send a message (to the central service)
• Upon receipt on the sender node, measure
  difference between send and receive times
• Without a central service (OmniORB, ICE, RTI
  DDS)
• Round-trip test
• Send a message (to the receiving node)
• Respond
• Upon receipt of the response, measure the
  difference
• Throughput test
• Send messages as fast as possible
• Measure differences between receive times
• Statistical analysis to obtain average, jitter,
  minimum, 95th percentile, etc.

9
Applicability to Use Cases

• First number performance
• Second number functional applicability of the
  use case

• not applicable at all
• applicable, but at a significant
  performance/quality cost compared to optimal
  solution custom design required
• applicable, but at some performance/quality cost
  compared to optimal solution custom design
  required
• applicable, but at some performance/quality cost
  compared to optimal solution foreseen in
  existing design
• applicable, and close to optimal solution use
  case foreseen in design

10
Applicability to Use Cases

• First number performance
• Second number functional applicability of the
  use case

• not applicable at all
• applicable, but at a significant
  performance/quality cost compared to optimal
  solution custom design required
• applicable, but at some performance/quality cost
  compared to optimal solution custom design
  required
• applicable, but at some performance/quality cost
  compared to optimal solution foreseen in
  existing design
• applicable, and close to optimal solution use
  case foreseen in design

11
PON Latency (small payloads)
12
PON Latency (small payloads)

• Ranking
• OmniORB (one way invocations)
• ICE (one way invocations)
• RTI DDS (not tuned for latency)
• EPICS
• OmniNotify
• ICE storm

13
PON Throughput
14
PON Throughput

• Ranking
• RTI DDS
• OmniORB (one way invocations)
• ICE (one way invocations)
• EPICS
• ICE storm
• OmniNotify

15
PON Scalability

• RTI DDS efficiently leverages IP multicasting
• (source RTI)

• With technologies that do not use IP
  multicasting/broadcasting, per-subscriber
  throughput is inversely proportional to the
  number of subscribers!
• (source RTI)

16
EPICS

• Ultimately, ITER Organization has chosen EPICS
• Very good performance.
• Easiest to work with.
• Very robust.
• Full-blown control system infrastructure (not
  just middleware).
• Likely to be around for a while (widely used by
  many labs).
• Where EPICS could improve?
• Use IP multicasting for monitors.
• A remote procedure call layer (e.g., abuse
  waveforms to transmit data serialized with with
  Google Protocol Buffers, or use PVData in
  EPICSv4).

17

• Thank You for Your Attention