quirements the same quality concern (e.g, different la-
tency requirements). DDS does not only offer a set of
QoS, but also allows system developers to set differ-
ent QoS parameters for different entities such as Top-
ics, Data Readers, and Data Writers.
To satisfy time constraints and requirements for
reliable communication in SG, the QoS in the DDS
framework needs to be tailored. Different compo-
nents should be able to set different contracts. The
communication between publishers/ subscribers can-
not be established unless both parties agree on the set
of QoS. Given that, we suggest the following QoS at-
tributes to be tailored:
• Latency (Deadline): This attribute can be used
to set restrictive time constraints for components,
which allows publishers/subscribers to specify
how fast they can publish/receive data (Object-
Managment-Group, 2015). The attribute can be
tailored depending on the constraints of the com-
ponent on communication. For example, mission-
critical components (e.g., protection relays) in SG
must tailor this attribute to set up a rigid deadline
for data transmission.
• Latency Budget: This is another important qual-
ity attribute that can be used for implementing op-
timization on the publisher side to accommodate
the maximum acceptable latency of subscribers
which refers to the delay from the time the data
is written until the data is inserted into the sub-
scriber’s cache. It can be tailored to define com-
munication rules to satisfy restrictive time con-
straints for devices. One approach to tailoring this
attribute is to use it in conjunction with a priority-
based transport protocol to set up higher priority
for data with low latency budget.
• Reliability: This enables a Reader to receive data
reliably sent by a Writer. It can be used in SG
to satisfy reliability constraints. There are two
sub-parametersfor setting this QoS – Reliable and
Best Effort. The Reliable setting enforces reliable
data exchange. For example, for the components
(e.g., smart meters) that can tolerate a certain la-
tency to receive data, the Reliable parameter can
be set to retransmit data until received. On the
other hand, the Best Effort setting has no relia-
bility mechanism. Thus, it can be used for the
components that periodically publish data sam-
ples where only the latest one matters (e.g., data
sensors). Tailoring this quality attribute is carried
out by making appropriate setting for the given re-
liability constraints.
5.2 Tailoring Discovery Mechanism
The key for establishing communication between
publishers and subscribers is discovering the exis-
tence of participants. In the DDS context, this re-
quires DDS entities to be informed of each other’s
existence for communication. Not only this, the dis-
covery feature should also provide communication
guides between different publishers and subscribers.
For example, communication guides can be provided
as IP multicasting by devices where the DDS infras-
tructure manages the group membership.
The DDS specification defines a Real-Time Pub-
lish Subscribe protocol (RTPS) which describes a dis-
covery functionality. The main purpose of RTPS is
to support the interoperability of applications built
upon different implementation platforms of vendors.
RTPS (Object-Managment-Group, 2014) defines two
discovery protocols – Participant Discovery Protocol
(PDP) and Endpoint Discovery Protocol (EDP). PDP
is used for discovering different domain participants,
while EDP is used for matching data readers and data
writers. However, these protocols are defined in a
generic way, which may cause some drawbacks with
respect to system dynamism. For example, they re-
quire a large amount of periodic data exchange, which
is not applicable to the components that have limited
computing resources, processing, or power resources
(e.g., batteries). In the following, we describe features
with respect to DDS discovery service that need to be
tailored to improve SG dynamism.
• Providing Communication Guides for Differ-
ent Components: As mentioned in Section 4, SG
requires a dynamic communication system. Thus,
it is important to allow system components to be
added and removed in a dynamic way. For exam-
ple, when a new component (e.g., new publish-
ers/subscribers) is added to the system, the com-
ponent can be reached efficiently by the use of
discovery hints (e.g., the group membership pro-
vided by DDS).
• Enabling Multiple Discovery Strategies for
Different Components: The DDS specifica-
tion allows the separation of its implementa-
tion from discovery services (Object-Managment-
Group, 2014). However, a DDS implementation
in SG should have a built-in discovery service to
support flexible and dynamic discovery of com-
ponents. Components with limited resources may
not be able to handle heavy interactions. For
smooth integration of these components, the DDS
infrastructure must provide alternative discovery
mechanisms. For example, IEDs or sensors in SG
need a simple discovery protocol such as Simple