0% found this document useful (0 votes)
1K views19 pages

IOT PHD Course Work Notes VTU

The document discusses strategies for implementing Internet of Things (IoT) technologies in smart cities. It outlines a four-layer architecture for smart city IoT with street, city network, data center, and services layers. Currently, most city infrastructure is siloed, but an integrated IoT strategy could optimize resources like transportation, utilities, and infrastructure to improve living standards. The strategy should scale solutions across departments, share data, and reduce waste. Cloud and edge computing models can address integration challenges by processing some data locally and aggregating other data in the cloud.

Uploaded by

bhargavi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
1K views19 pages

IOT PHD Course Work Notes VTU

The document discusses strategies for implementing Internet of Things (IoT) technologies in smart cities. It outlines a four-layer architecture for smart city IoT with street, city network, data center, and services layers. Currently, most city infrastructure is siloed, but an integrated IoT strategy could optimize resources like transportation, utilities, and infrastructure to improve living standards. The strategy should scale solutions across departments, share data, and reduce waste. Cloud and edge computing models can address integration challenges by processing some data locally and aggregating other data in the cloud.

Uploaded by

bhargavi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 19

Internet of Things

Module 5
Syllabus

Choice 1 (20 marks) Choice 2 (20 marks) Important (Priority


wise)

IoT Strategy for Connected Smart and Connected Cities IoT Strategy
Manufacturing Strategy for Connected
Architecture for Connected Smart city network Manufacturing
factory architecture IACS
IACS Reference Model Smart city security
Reference
architecture
The CPwE Reference Model Model
Smart street lighting
Resilient Ethernet Resilient
Utilities
Protocol (REP) Ethernet
Power utility
CPwE Wireless Protocol
IT/ OT divide
RTLS (REP)
Grid blocks reference
Utilities
model
Power utility
Primary substation grid
IT/ OT divide block and automation
Grid blocks reference model SCADA
Primary substation grid block IEC 61850
and automation
SCADA
IEC 61850
Smart and Connected Cities
An IoT Strategy for Smarter cities
The world is rapidly urbanizing, and this trend is slated to continue. Very few cities were
designed to immediately accommodate a very large population. Rapid growth typically strains
city infrastructure. Roads, bridges, and sewer systems often reach their full capacity, making
access to urban services challenging. Hence, there is a need to transform traditional cities into
Smart cities, and it goes without saying that this will certainly involve IoT. Thus, an effective IoT
strategy for Smarter cities is the need of the hour.
The IoT strategy for smarter cities should be built around
1. Providing basic necessities while reducing the carbon footprint
2. Optimizing the efficiency of critical resources (water, light, gas)
3. Waste and emissions processing
4. Capitalizing on the economic benefits of large urban populations while mitigating the
social and environmental difficulties that come with them
The IoT strategy for smarter cities should be able to make effective use of digitization and
ICT (connects people, data, and processes) in providing viable solutions to problems. The
solution thus obtained should be
1. Scalable
2. Increases efficiency
3. Reduces Cost
4. Enhances Quality of life
Smart City: “A Smart City is a technologically modern urban area that uses different types of
electronic methods and sensors to collect specific data, analyze it and make intelligent
decisions so as to optimize services and processes that deliver a better quality of life for people”
Vertical IoT Needs for Smarter cities
IoT solutions typically start at the street level, with sensors that capture data on almost
everything from parking space availability to water purity. Data analytics is then used
extensively in transforming the captured data into business insights, leading to smart solutions
such as efficient traffic management, power management, and so on. If these smart solutions are
enabled through connectivity, they can have a transformative impact on quality of life. To
maximize value, smart cities can adopt a shared-revenue business model to monetize smart city
infrastructure.
A recent CISCO study has identified IoT to have the following economic impact over a decade:
1. Smart buildings: Smart buildings have the potential to save $100 billion by lowering
operating costs by reducing energy consumption through efficient integration of HVAC
and other building infrastructure systems.
2. Gas Monitoring: Monitoring gas could save $69 billion by reducing meter-reading
costs and increasing the accuracy of readings. Gas monitoring will also enhance safety
by providing a timely alert in case there is a sudden consumption increase.
3. Smart parking: Smart parking could create $41 billion by providing real-time visibility
into parking space availability. Residents can identify and reserve the closest available
parking space, whereas traffic wardens can identify non-compliant usage, and
municipalities can introduce demand-based pricing.
4. Water Management: Smart water management could save $39 billion by connecting
household water meters over an IP network to provide remote usage and status
information. Some of the benefits are real-time consumption visibility and leak
detection. Smart meters can also be used to coordinate and automate private and public
lawn watering. At a city scale, IoT can be used to manage water supply equipment
and report status. A gate or a pump can be opened and closed remotely and
automatically in real-time, based on a variety of flow input and output analytics data.
Vibrations can be measured to detect and predict potential equipment failures. Repair
items can be dispatched proactively before equipment failures. These efficiency gains
directly translate into operational gains.
5. Road Pricing: Smart cities could create $18 billion in new revenues by implementing
automatic payments; proactively rerouting public transportation services or private users.
By enabling new and more meaningful connections, governments and other public-sector
agencies worldwide can benefit and ultimately create quantifiable benefits for citizens.
Meanwhile, a smart city can use these technological advances to improve its livability index,
which can help attract and retain talent, thus accelerating growth. This may drive foreign
investment, leading to higher economic impact and potential for future investments.
Global vs. Siloed Strategies
The main obstacle to implementing smart solutions in today’s traditional infrastructure is the
complexity of how cities are operated, financed, regulated, and planned. Cities attempting to
upgrade their infrastructure are doing it independently. Even cities using IoT technology break
up city assets and service management into silos that are typically unable to communicate
or rely on each other.
The independent investment model results in the following problems:
1. Isolation of infrastructure and IT resources
2. No sharing of intelligence and vital information
3. Waste and duplication in investment and effort
4. Difficulty in scaling infrastructure management
For example, in traditional city infrastructure, parking, lighting, and traffic departments are all
administratively independent and run separately with their own budgets used to invest in
upgrading their respective infrastructures. This introduces duplication of investments made on
the same infrastructure, with only minor details tailored to specific department oversights. This is
highly inefficient money management and wastes public resources.
However, integrating and expanding disparate IoT systems comes with challenges:
1. Solution needs to extend across vendors, and technologies, thus needing a horizontal
solution
2. Collection of large amounts of diverse data in real-time
3. Technological challenges such as How to collect data? Where to analyze data? (locally
or in the cloud), Data aggregation, Making data available for applications, Setting up
Infrastructure and Maintenance in a cost-effective manner, and so on
4. Each smart city demands a tailored solution
5. A resilient computing model which offers mobility, and speed and can be scaled, thus
making sure value is delivered
One of the solutions to tackle the challenges above is a combination of cloud and fog
computing. Data that needs to be processed locally stays at the edge of the network, whereas
other data can be sent to the cloud. For example, real-time information about parking spaces can
be processed locally at the edge, whereas global statistics and analytics of traffic data can be
processed in the cloud.
Smart City IoT Architecture

A Smart city architecture is a 4 layered architecture. Data flows from devices at the

street layer to the city network layer and connects to the data center layer,

where the data is aggregated, normalized, and virtualized. The data center

layer provides information to the services layer, which consists of the

applications that provide services to the city. Herein, dataflow from sensor to
application involves a translation process wherein different protocols and different application
languages are translated into a normalized language. This common language simplifies
communication and data management and allows solutions to inform each other. Leveraging
this exchange allows smart cities to develop new solutions that span services, without requiring
further infrastructure, and future-proofs the system.
Street Layer: The street layer is composed of devices and sensors that collect data and take
necessary action. A sensor is a data source that generates data required to understand the
physical world. A variety of sensors are used at the street layer such as
1. Magnetic sensor: Detects parking events by analyzing changes in the surrounding
magnetic field when a heavy metal object, such as a car or a truck comes close to it
2. Lighting controller: Dims and brightens light based on time or ambient conditions
3. Video cameras: Detects vehicles, faces, and traffic conditions for various traffic and
security use cases by employing video analytics
4. Air Quality sensor: Detects and measures gas concentrations to give a measure of
pollution
5. Device Counters: Estimates the number of devices in an area that could be used in
tracking the number of vehicles parked in an area, the number of pedestrians on a
sidewalk, and so on
The choice of a particular sensor or technology for a smart city depends on
1. The exact nature of the problem, the accuracy and cost trade-offs, interaction with other
IoT systems, and installation limitations posed by the physical environment
2. Lifetime and maintenance costs - Eg: Sensors mounted on a light pole vs. sensors
mounted somewhere with no power and network access
3. Edge analytics powered by event-driven systems. Event-driven systems allow the city
infrastructure to be contextually intelligent so that only targeted events trigger data
transfer to the cloud. This flexibility allows the infrastructure to monitor a large number
of systems without the risk of overloading the network with uneventful status update
messages. This maximizes data transfer speeds and minimizes server requirements and
costs.
4. Storage - Based on method, location, and length of time the data has to be archived.
Eg: Storing video for weeks vs. storing based on event-based triggers. This has a big
impact on the analytics that can be included in the limited physical capacity of the
device.
5. Privacy - Privacy is a major concern whenever public data is collected and stored.
Herein, legal and privacy considerations play a major role in choosing a system.
Collecting and storing only what is minimally required seems to be the way forward.
Eg: Installing a limited image resolution camera that cannot detect anything beyond
general shape or a particular matter of interest, so as to safeguard privacy. Low
bandwidth communication systems may be used to limit the data that is being sent.
It is critical to have a good network infrastructure that allows communication between devices
that use a variety of communication protocols. The network for a smart city has to be
ruggedized for outdoor conditions and must be able to withstand harsh weather conditions.
LoRaWAN is growing as a major protocol for smart city sensors. Smart city networks also have
to make possible closed-loop decision-making, all the while supporting low-power
consumption protocols.
City Layer: The city layer acts as a transport layer between the edge devices and the data
center layer. At the city layer, which is above the street layer, network routers and switches
must be deployed to match the size of the city data that needs to be transported. This layer
aggregates all data collected by sensors and the end-node network into a single transport
network. The challenge herein is that devices using multiple protocols need to be handled in an
efficient manner. The city layer must be built around resiliency to ensure that a packet coming
from a sensor will always be forwarded to the headend station. Resilient Ethernet Protocol
(REP) can be used to achieve this wherein two paths exist from any aggregation switch to the
data center.
Data Center Layer: The data collected from the sensors is sent to a data center, where it can be
processed and correlated. Based on this processing of data, meaningful information and
trends can be derived, leading to business insights. For example, an application in a data center
can provide a global view of the city traffic and help authorities decide on the need for more or
less common transport vehicles. The key technology which drives the data center layer is the
cloud. With a cloud infrastructure, data is stored in rented logical containers accessed through
the internet. As containers can be extended or reduced based on needs, the storage size and
computing power are flexible and can adapt to changing requirements or budget
conditions. In short, the cloud provides a scalable, secure, and reliable data processing engine
that can handle the immense amount of data passing through it. Smart city issues also require
new data processing and management models such as Software as a Service (SaaS) models
and expense-based consumption models. In expense-based consumption models, critical data is
given priority, and later when financial constraints are addressed, richer data processing will be
enabled. However, not all data is processed in the cloud. Real-time data and locally significant
data are often processed at the edge (Fog architecture) and then sent to the cloud for a
global perspective.
Services Layer: Smart city applications can provide value to a variety of users such as citizens,
city operators, law enforcement, and so on. The collected data should be visualized according to
the specific needs of each consumer and individual use cases. Example: Parking data, Traffic
data. Traffic data can be used by individual car drivers to find the least congested route, whereas
a variation of the same information can help authorities in rerouting traffic around known
congestion points. The services layer enables cross-domain benefits.
On-Premises vs. Cloud
A key consideration in developing ICT connectivity solutions is data hosting, whether data be
hosted On-Premise or Cloud. This decision is greatly influenced by local security and legal
policies. On-Premises offer security, whereas the cloud offers scalability and flexibility. A
hybrid hosting approach whereby some data may be migrated to the cloud while other data
stays On-Premise could be implemented. For example, images from individual street cameras
may be stored locally, whereas the analytics may be hosted in the cloud.
Smart City Security Architecture
A serious concern of most smart cities and their citizens is data security. Vast quantities of
sensitive information are being shared at all times and cities have a duty to protect their
citizens’ data from unauthorized access, collection, and tampering. In general, citizens feel
safe if data is owned by the city itself, and not some private entity. Hence there is a need for a
centralized, cloud-based, compliance-based security mechanism.
A security architecture for smart cities must utilize security protocols to fortify each layer of
architecture and protect city-data. Security protocols should authenticate the various
components and protect data transport throughout. The security architecture should be able to
evolve with the latest technology and incorporate regional guidelines.
Street layer: At the street layer, sensors should have their own security protocols and security
features like device/ sensor identification and authorization, device/ sensor data encryption,
user ID authentication, and authorization, Trusted Platform Module enabling self-destruction
when the sensor is physically handled. Another consideration is the type of data that the sensor
is able to collect and process. For example, a roadside car counter may include a Bluetooth
sensor that uniquely identifies each driver or pedestrian. Security considerations should
determine whether this information should even be collected. If it is collected, a decision should
be made on whether this data is processed using an “online process” (information is used for
analytics, but individual identifying data is not stored and is therefore forgotten immediately) or
a more classical analytical process (data is stored temporarily). Data should be secured both
at rest and in motion, but when data is stored, additional security needs to be put in place to
ensure that information will not be tampered with, abused, or stolen.
City layer: The city layer transports data between the street layer and the data center layer. It
acts as a network layer. Some common industry elements for security on the network layer are
1. Firewall: A firewall is located at the edge. A firewall is a network security device that
monitors traffic to or from your network. It allows or blocks traffic based on a defined
set of security rules.
2. VLAN: A VLAN provides end-to-end segmentation and protects data from rogue
intervention. VLANs allow network administrators to automatically limit access to a
specified group of users by dividing workstations into different isolated LAN segments.
When devices are separated into multiple VLANs, often by department, it's easier to
prevent a compromised computer from infecting the entire network.
3. Encryption: Protecting traffic from the sensor to the application is a common
requirement that can be achieved via encryption. Encryption is the method by which
information is converted into secret code that hides the information's true meaning.
Data Center and Services layer: At the data center layer, having a secure virtual private
cloud is a common requirement. Creating dynamic perimeters around applications, clients,
hosts, and shared resources is a vital requirement. Integrating the latest technology frameworks
is the key to ensuring the integrity of a city solution.

Smart City Use-Case Examples: Connected/ Smart Street Lighting


Of all urban utilities, street lighting comprises one of the largest expenses in a municipality’s
utility bill, 40% of the total. Maintenance of street lights is an operational challenge, given a
large number of lights and their vast geographic distribution.
Connected Street Lighting Solution: Smart lighting solution helps reduce lighting expenses,
increase energy savings, and improve operating efficiencies while minimizing upfront
investment. LED technology is leading the transition from traditional street lighting to smart
street lighting because
1. LEDs require less energy to produce more light than legacy lights
2. LEDs have a longer life span and a longer maintenance cycle
3. LED technology can reduce individual light bills by up to 70%
4. LEDs are well suited to smart solution use cases
Street Lighting Architecture
Connected lighting uses a light management application to manage street lights remotely by
connecting to the smart city’s infrastructure. This application attaches to LED lights, monitors
their management and maintenance, and allows one to view the operational status of each light
via a cloud connection. The gateway relays instructions from the application to the lights and
stores the local light’s events for the application’s consumption.
Connected Lighting Architecture
A human or automated operator can use a cloud application to perform automated scheduling
for lights and even get light sensors to perform automated dimming or brightening, as needed.
Lighting nodes vary widely in the industry, especially with respect to elements such as what
communication protocol they use.
Smart lighting as an ICT connectivity solution utilizes an existing city asset with an existing
power source. For example, LED light bulbs are commonly equipped with basic sensors to
detect light, and environmental parameters, such as temperature, humidity, and so on. This
enables street lights to act as local weather reporting stations. Adding such basic sensors
typically adds only marginal cost. More specialized capabilities can also be embedded, such as
basic audio or video functionality, measuring oxygen levels, measuring the amount of
pollution, and so on. But, this typically comes with additional cost and demands extensive
network requirements such as high bandwidth. Efficiency is the key metric here. For example,
the amount of lighting can be reduced on highways where no cars are detected. Lights can be set
to blink with a specific pattern to help police locate a specific GPS location quickly.

Utilities
The importance of utilities (electric power, gas, & water) to the basic function of society is
evident as many governments categorize them as ‘critical infrastructure”. The size and scale of
utility networks can be truly massive, and thus integrating them into an IP network is a major
challenge. Eg: Deploying metering systems over an IP network.
Power Utility Industry: The three stages of the power supply are as follows:
1. Generation: In this stage, electricity gets produced via nuclear, hydroelectric, or any
other means. The so-generated high-voltage (HV) electrical power is sent through
high-voltage transmission lines into the transmission system.
2. Transmission: Power transmission takes the HV power (115 kV and above) over long
distances (50 km and greater). Transmission lines include aerial cables and submarine
cables. The transmission system is responsible for connecting HV lines from generation
stations to substations.
3. Distribution: Power distribution includes the part of the utility network from the
substation to the home or business. This includes the medium-voltage (12.5kV)
powerlines and pad mount transformers. The power is stepped down to low voltage at the
transformers.

The IT/ OT divide in Utilities


The very early days of utility OT networks facilitated operators to make readings without
having to travel to remote locations. When ethernet first became available, computing became
so inexpensive and powerful that it could be used almost anywhere throughout the grid instead of
just at a central control room. The longevity and scale of legacy utility systems mean it is not
economical to replace all of them with smart systems. Hence slow and steady integration of
smart systems needs to be carried out with existing legacy systems.
OT engineers are always looking for better, cost-effective ways to do things, and this often
includes utilizing IT technology wherever possible. IT technology has the benefit of wide
adoption in the industry, meaning it is easy to find qualified people to design and support
networks. The challenge was and continues to be, understanding the OT physical systems
and making sure that general-purpose IT is up to the job.
As utility networks begin to migrate to IP communications and use IoT architectures, the
size of OT networks becomes orders of magnitude larger than those of IT counterparts.
Example: AMI (Advanced Metering Infrastructure), where the electric meters become smart
IP-enabled devices. In such cases, concerns that need to be addressed are
1. Network resiliency and redundancy for mission-critical OT applications: Redundancy
is the intentional duplication of system components in order to increase a system's
dependability. Resilience refers to a system's ability to recover from a fault and maintain
the persistence of service.
2. Managing distribution systems on the grid which act as transit between IT & OT
networks
3. Security Management in IT and OT networks, and their interconnection point
In the past, IT and OT were completely separate groups. Today, as networks converge, OT and
IT need to work together. OT engineers need to learn IP skills and IT engineers should learn
important aspects of the utility’s core OT system. But the transfer of such hard-earned
knowledge in a short span of time poses a challenge. These challenges have ushered in the age of
smart grid - the combination of the electric power grid and ICT.

The Gridblocks Reference Model


Gridblocks reference model developed by CISCO offers an easy-to-understand model for both
novice and advanced users. The model is forward-looking and is intended to be a generalized
end-state reference framework that can help assist in deploying and designing end-to-end secure
energy communications solutions for all aspects of the grid, thus facilitating the smart grid.
The Gridblocks reference architecture provides the following benefits:
1. Details a flexible, tier-based model that supports incremental improvements across the
grid
2. Enables secure integration of both new and legacy technologies, thus improving overall
visibility and manageability of network elements
3. Builds on open standards, preventing vendor dependency, and supporting
interoperability, thereby reducing costs
4. Enables consolidation and convergence of various utility networks, thus streamlining
operations, and reducing operational and capital costs, all the while creating value
5. Provides a digitization roadmap for utilities to enable modernization
The key strategy of this model is to unite formerly disconnected functions of the grid through
network communications into a converged architecture. Each tier of the grid may be owned
and operated by different divisions of the same power company, or even entirely different
companies. The Gridblocks reference model is organized into 11 tiers as follows:
1. Prosumer tier: The prosumer tier combines the dual roles of producer and consumer
and encompasses external elements that might impact the grid. These are devices that
are neither owned by the utility nor part of its infrastructure but interface with it
somehow. This includes distributed energy resources (DERs) that produce local power
from solar or other means. This could also include energy storage systems.
2. Distribution tiers: This part of the grid lies between the distribution substation and the
end user. It is further broken into 2 sub-tiers
a. Distribution Level 2 tier: This tier acts as the last mile supporting metering
systems, EV recharging stations, and so on
b. Distribution Level 1 tier: This tier connects Level 2 tier networks to the
distribution substation and provides backhaul services
3. Substation tier: This tier includes all substation networks, both the transmission and
distribution substations. Transmission substations connect multiple transmission lines
and typically involve higher voltages, and feed power to distribution stations.
Distribution substations receive an input of 115 kV and feed power at 25 kV or less to
the end customer. Inside the substation, there are often strict network requirements,
such as resiliency, performance, time synchronization, and security. Primary
distribution substations may also include data aggregation.
4. System control tier: This tier includes Wide area networks that connect substations with
each other and with control centers. The substation WANs require flexibility and
scalability. The system control tier supports connectivity for remote SCADA devices,
event messaging, and so on.
5. Intra-Data center/ Intra-Control center tier: Both these centers are at the same logical
level, but they have very different requirements. A Data center contains enterprise-level
applications and services. A Control center contains real-time systems that operate and
control the grid itself. This tier needs to be connected to the substation through the
system control tier so that important data can be collected and run by both IT and OT
systems in the substations.
6. Utility tier: This is an IT-Focused tier. The utility tier is the connection point between
the control center and the enterprise network. It utilizes firewalls with appropriate
security policies to ensure that only trusted traffic from the enterprise network enters the
control center.
7. Balancing tier: This tier supports connections between third-party power-generation
operators and balancing authorities. In an electric utility, supply may not always meet
the demand. To manage load and demand, most utilities are interconnected with other
utilities so that power exchange (buy and sell) between utilities is possible. This needs to
happen in a balanced manner, which is facilitated by balancing authority. If electrical
demand and supply fall out of balance, blackouts may occur.
8. Interchange tier: This tier allows electricity to be bought and sold between utility
operators so that the same can be monetized
9. Trans-regional/ Trans-national tier: Most utility grids are interconnected with much
larger super grids for power interchange, grid monitoring, and power flow
management
10. Wide area measurement and control system (WAMCS) tier: This tier includes
connections to a critical component of the power grid, power management units (PMUs),
which are responsible for wide-area power measurements across the grid
The Primary Substation Gridblock and Substation Automation
SCADA: SCADA is a system by which remote devices can be monitored and controlled by a
central server. SCADA plays a critical role in the substation, allowing controls and data
acquisition from remote devices, known as remote terminal units (RTUs), and intelligent
electronic devices (IEDs). RTUs and IEDs are relays, load controllers, and circuit breaker
controllers which are attached to the power grid hardware. In the world of SCADA, a remote
device is called a SCADA slave, and the server is a SCADA master.
In its early days, SCADA systems were independent with no connectivity to other systems.
Over time, remote WAN networks allowed SCADA connectivity to extend to RTUs, but these
were typically point-to-point serial links that mostly utilized RS-232. Later, SCADA began to
adopt standards-based protocols and open network architecture. This led to local SCADA
masters at each substation via LAN. As IP WAN networks became available, SCADA services
began to be dispersed throughout the network via a centralized SCADA master in the control
center.
In the figure below, electrical relays are attached via serial connections to RTUs, which are in
turn connected to a SCADA gateway device that is connected to the substation ethernet network.
A SCADA gateway device typically has 2 functions:
1. Protocol Translation
2. Tunneling serial traffic through the IP network
IEC 61850: The modernization of Substation Communication Standards
Existing serial-based SCADA systems lack deployment flexibility and ultimately rely on aging
serial communications. IEC 61850 standard is an effort towards modernizing substation
communication by taking advantage of Ethernet and IP. IEC 61850 overcomes vendor and
network interoperability challenges in the substation and beyond by replacing serial links
with Ethernet and IP. The inherent flexibility of ethernet means that IEDs can easily
communicate directly with one another and with other elements of the communication
infrastructure.
IEC 61850 Station Bus
IEC 61850 defines substation communication in two key areas - the station level and the
process level as illustrated in the figure above. The equipment at the station level
communicates with IEDs at the bay level via the station bus. The Bay level relates to
high-voltage devices such as transformers. These devices make connections into the
measurement system for protection and control. Devices in the bay level typically have two
types of network interfaces: one for SCADA management connected to the station bus and
another connected to the process bus.
The IEC 61850 defines three main traffic classes:
1. Manufacturing Message Specification (MMS): MMS supports client/ server
communication over IP and is used for SCADA. MMS traffic is typically found on the
station bus.
2. Generic Object Oriented Substation Event (GOOSE): GOOSE uses Ethernet-based
multicast communications in which IEDs can communicate with each other and
between bays. GOOSE is typically used over the station bus.
3. Sample Values (SVs): SVs are typically found on the process bus to carry voltage and
current samples.
GOOSE is an extremely important tool as it is the primary 61850 message type used between
electrical protection and control systems which continually monitor the power being
delivered by transmission lines and feeders. If power is disrupted for some reason, the
measurement system detects it within a few milliseconds and passes GOOSE messages through
the Ethernet network to a peer relay that switches power delivery to an alternate line or feeder.
If the GOOSE messages are not delivered correctly or within time, the electrical relays can
become confused, and power can be incorrectly switched, causing blackouts.
IEC 61850 Process Bus

IEC 61850-9 defines process bus communications in which critical process-level equipment may
communicate messages over Ethernet.
The figure above illustrates a possible IEC 61850 substation automation design. As shown, 2
separate ethernet segments are used - the station bus and the process bus. The station bus
allows inter-IED communication like GOOSE messages for protection and control as well as
SCADA communications. The process bus uses an entirely different set of ethernet switches
for the critical substation automation functions. It must use distinct physical switches. One
reason for this is the network resilience requirements of the process bus. The substation
automation design takes advantage of the ethernet framework offered by IEC 61850 where both
legacy RTUs and modern 61850-capable devices are used.

Network resiliency protocols in the Substation


The IEC 61850 process bus has some of the most stringent resiliency requirements of any
application in any industry. Even the loss of one packet or ethernet frame cannot be tolerated.
Parallel Redundancy Protocol (PRP)
PRP is an IEC standard for implementing highly available automation networks which
ensure that the network never loses even a single Ethernet frame, even in the event of a
network outage. Instead of just sending one frame, a PRP enabled dual attached IED is
capable of sending redundant copies of the same frame on different but parallel Ethernet
VLAN segments.
The Ethernet frames originating from the LED are given a sequence number. The two frames
then traverse the two parallel network paths until they arrive at the receiving IED. The receiving
IED selects a preferred (active) interface and discards the frame received on the nonpreferred
(backup) interface. In the event of a failure in one of the parallel networks, this approach
guarantees that at least one of the packets will always arrive at the destination IED.
The downside of this approach is that IEDs and ethernet networks may not always be PRP
capable. This would require upgradation to support PRP.
To get around this problem, a PRP-capable access switch is attached to an existing IED. In this
case, the PRP access switch acts as the redundancy box (RedBox) making dual copies of the
Ethernet frame and sending the copies over different VLANs on opposing sides of the network.
The receiving PRP switch then forwards one copy and removes the duplicate copy. The
advantage of this approach is that intermediary switches need not be PRP-capable.

High-Availability Seamless Redundancy


HSR was specifically designed for Ethernet ring topologies. Herein, the IED has only a single
attachment to the HSR RedBox Ethernet switch. The HSR RedBox sends out duplicate copies
on the same VLAN but on opposite sides of the ring. One key constraint of HSR is that all
intermediary switches in the ring must be HSR capable.

You might also like