Introduction To SGAM Toolbox

Introduction to the „SGAM Toolbox“
Author: Christian Neureiter (christian.neureiter@en-trust.at)

Version: 0.4
Date: 2014-04-27
Josef Ressel Center for User-Centric Smart Grid Privacy, Security and Control
Salzburg University of Applied Sciences
Urstein Sued 1 | 5412 Puch/Salzburg | Austria
Tel.: +43 (0)50 / 2211 - 1300 | Fax: +43 (0)50 / 2211 - 1349| e-mail: info@en-trust.at | Web: www.en-trust.at
Table of Contents
1. Introduction .................................................................................................................................... 3
2. The Smart Grid Architecture Model (SGAM) ................................................................................ 4
2.1. The Interoperability Layer ................................................................................................... 5
2.2. The Smart Grid Plane ......................................................................................................... 5
2.3. Domains .............................................................................................................................. 6
2.4. Zones .................................................................................................................................. 6
3. SGAM Toolbox Architecture .......................................................................................................... 8
4. SGAM Toolbox Installation .......................................................................................................... 10
6. Proposed Development Process ................................................................................................. 12
7. System Analysis Phase ............................................................................................................... 14
7.1. Use Case Analysis ............................................................................................................ 14
7.1.1. Develop Business Case Model.......................................................................... 14
7.1.2. Develop High Level Use Case Model ................................................................ 16
7.1.3. Develop Primary Use Case Model .................................................................... 18
7.2. Develop Function Layer .................................................................................................... 20
7.3. Develop Business Layer ................................................................................................... 21
8. System Architecture Phase ......................................................................................................... 23
8.1. Develop Component Layer ............................................................................................... 23
8.1.1. Map Actors to physical Components ................................................................. 23
8.1.2. Develop Component Layer ................................................................................ 24
8.2. Develop Information Layer ................................................................................................ 25
8.2.1. Develop Business Context View ....................................................................... 25
8.2.2. Perform Standard and Information Object Mapping .......................................... 26
8.2.3. Develop Canonical Data Model View ................................................................ 27
8.3. Develop Communication Layer ......................................................................................... 29
9. Design and Development of single Components ........................................................................ 30
10. Non-Functional Requirements .................................................................................................... 31
10.1. Security Requirements ...................................................................................................... 31
10.1.1. Theoretical Background ..................................................................................... 31
10.1.2. Requirements Engineering ................................................................................ 35
11. Generating Reports ..................................................................................................................... 38
12. Acknowledges and Future Work ................................................................................................. 38
13. References .................................................................................................................................. 39
Introduction to SGAM-Toolbox 2/39

www.en-trust.at
1. Introduction
The document at hands describes the ideas and the usage of the SGAM-Toolbox for
developing Smart Grid systems in reference to the Smart Grid Architecture Model (SGAM) as
introduced by the Smart Grid Coordination Group (SGCG) in 2012 [1].
It focuses on the SGAM-Toolbox and its’ application and does not describe the underlying
methods or technologies like Systems-Engineering, UML-based modeling or the handling of
the involved modeling tool (Enterprise Architect from Sparx Systems1).
If you have any feedback according the toolbox or need further help please feel free to
contact us and send a mail to christian@en-trust.at.
Please take note of the available Video-Tutorials that demonstrate in detail how to utilize the
SGAM Toolbox for architecting Smart Grid Systems. Simply follow the links on www.en-
trust.at or search for “SGAM Toolbox” on YouTube.
1 www.sparxsystems.com

www.en-trust.at
2. The Smart Grid Architecture Model (SGAM)
The Smart Grid Architecture Model (SGAM) was introduced by the Smart Grid Coordination
Group in 2012 [1].
The SGAM focuses on a structured description of a distributed Smart Grid System in order to
identify standardization gaps. However, the proposed architecture model appears to be very
useful for architecting smart grid systems. Hence, the SGAM Toolbox was developed in
order to ease the modeling of Smart Grid Systems in reference to the SGAM.
The architecture model helps to analyze Smart Grid systems and interactions by mapping
them to a three dimensional cube that is depicted in listing
Business Objectives
Polit. / Regulat.. Framework
Business
Layer
Interoperability Dimension
Function
Outline of Usecase
Layer
Subfunctions
Information Data Model
Layer Data Model
Communication
Protocol Market
Layer
Protocol
Enterprise
Component Operation
Layer Station
Generation
Transmission Field Zones
Distribution Process
DER
Customer
Domains Premise
Figure 1 - The Smart Grid Architecture Model (SGAM) [1]

www.en-trust.at
The following subsections that comprise explanations for the single SGAM elements are
taken from section “7.2 – SGAM Framework Elements” of the original, public available Smart
Grid Coordination Group Document [1].
2.1. The Interoperability Layer

In order to allow a clear presentation and simple handling of the architecture model, the
interoperability categories are aggregated into five abstract interoperability layers.
Business Layer: The business layer represents the business view on the information
exchange related to smart grids. SGAM can be used to map regulatory and economic
(market) structures and policies, business models, business portfolios (products & services)
of market parties involved. Also business capabilities and business processes can be
represented in this layer. In this way it supports business executives in decision making
related to (new) business models and specific business projects (business case) as well as
regulators in defining new market models.
Function Layer: The function layer describes functions and services including their
relationships from an architectural viewpoint. The functions are represented independent
from actors and physical implementations in applications, systems and components. The
functions are derived by extracting the use case functionality which is independent from
actors.
Information Layer: The information layer describes the information that is being used and
exchanged between functions, services and components. It contains information objects and
the underlying canonical data models. These information objects and canonical data models
represent the common semantics for functions and services in order to allow an
interoperable information exchange via communication means.
Communication Layer: The emphasis of the communication layer is to describe protocols

and mechanisms for the interoperable exchange of information between components in the
context of the underlying use case, function or service and related information objects or data
models.
Component Layer: The emphasis of the component layer is the physical distribution of all
participating components in the smart grid context. This includes system actors, applications,
power system equipment (typically located at process and field level), protection and tele-
control devices, network infrastructure (wired / wireless communication connections, routers,
switches, servers) and any kind of computers.
2.2. The Smart Grid Plane
Every layer itself is depicted by the utilization of the Smart Grid Plane, which is defined as
follows:
In general power system management distinguishes between electrical process and

information management viewpoints. These viewpoints can be partitioned into the physical
domains of the electrical energy conversion chain and the hierarchical zones (or levels) for
the management of the electrical process (refer to [IEC62357-2011, IEC 62264-2003]).
Applying this concept to the smart grid conceptual model introduced in section 6.3 allows the

www.en-trust.at
foundation of the Smart Grid Plane (see Figure 7.). This smart grid plane enables the
representation on which levels (hierarchical zones) of power system management
interactions between domains take place.
According to this concept those domains, which are physically related to the electrical grid
(Bulk Generation, Transmission, Distribution, DER, Customer Premises) are arranged
according to the electrical energy conversion chain. The conceptual domains Operations and
Market are part of the information management and represent specific hierarchical zones.
The conceptual domain Service Provider represents a group of actors which has universal
role in the context of smart grid. This means that a Service Provider can be located at any
segment of the smart grid plane according to the role he has in a specific case.
2.3. Domains
The Smart Grid Plane covers the complete electrical energy conversion chain, as described
in Table 1 - SGAM Domains.
Domain Description
Bulk Generation Representing generation of electrical energy in bulk quantities, such as by
fossil, nuclear and hydro power plants, off-shore wind farms, large scale solar
power plant (i.e. PV, CSP)– typically connected to the transmission system
Transmission Representing the infrastructure and organization which transports electricity
over long distances
Distribution Representing the infrastructure and organization which distributes electricity to
customers
DER Representing distributed electrical resources directly connected to the public
distribution grid, applying small-scale power generation technologies (typically
in the range of 3 kW to 10.000 kW). These distributed electrical resources
may be directly controlled by DSO
Customer Hosting both - end users of electricity, also producers of electricity. The
Premises premises include industrial, commercial and home facilities (e.g. chemical
plants, airports, harbors, shopping centers, homes). Also generation in form of
e.g. photovoltaic generation, electric vehicles storage, batteries, micro
turbines… are hosted
Table 1 - SGAM Domains
2.4. Zones
The SGAM zones represent the hierarchical levels of power system management
[IEC62357-2011]. These zones reflect a hierarchical model which considers the concept of
aggregation and functional separation in power system management. The basic idea of this
hierarchical model is laid down in the Purdue Reference Model for computer-integrated
manufacturing which was adopted by IEC 62264-1 standard for ―enterprise-control system
integration‖ [IEC 62264-2003]. This model was also applied to power system management.
This is described in IEC 62357 ―Reference architecture for object models services‖ [IEC
62357-2003, IEC 62357-1-2012].
The concept of aggregation considers multiple aspects in power system management:
 Data aggregation – data from the field zone is usually aggregated or concentrated in
the station zone in order to reduce the amount of data to be communicated and
processed in the operation zone

www.en-trust.at
 Spatial aggregation – from distinct location to wider area (e.g. HV/MV power system
equipment is usually arranged in bays, several bays form a substation; multiple DER
form a plant station, DER meters in customer premises are aggregated by
concentrators for a neighborhood)
In addition to aggregation the partitioning in zones follows the concept of functional

separation. Different functions are assigned to specific zones. The reason for this
assignment is typically the specific nature of functions, but also considering user
philosophies. Real-time functions are typically in the field and station zone (metering,
protection, phasor-measurement, automation…). Functions which cover an area, multiple
substations or plants, city districts are usually located in operation zone (e.g. wide area
monitoring, generation scheduling, load management, balancing, area power system
supervision and control, meter data management…).
The SGAM zones are described in Table 2 - SGAM Zones
Zone Description
Process Including the physical, chemical or spatial transformations of energy
(electricity, solar, heat, water, wind …) and the physical equipment directly
involved. (E.g. generators, transformers, circuit breakers, overhead lines,
cables, electrical loads any kind of sensors and actuators which are part or
directly connected to the process,…).
Field Including equipment to protect, control and monitor the process of the power
system, e.g. protection relays, bay controller, any kind of intelligent electronic
devices which acquire and use process data from the power system.
Station Representing the areal aggregation level for field level, e.g. for data
concentration, functional aggregation, substation automation, local SCADA
systems, plant supervision…
Operation Hosting power system control operation in the respective domain, e.g.
distribution management systems (DMS), energy management systems
(EMS) in generation and transmission systems, microgrid management
systems, virtual power plant management systems (aggregating several
DER), electric vehicle (EV) fleet charging management systems.
Enterprise Includes commercial and organizational processes, services and
infrastructures for enterprises (utilities, service providers, energy traders …),
e.g. asset management, logistics, work force management, staff training,
customer relation management, billing and procurement…
Market Reflecting the market operations possible along the energy conversion chain,
e.g. energy trading, mass market, retail market.
Table 2 - SGAM Zones

www.en-trust.at
3. SGAM Toolbox Architecture
The SGAM Toolbox mainly consists of three components:
1. SGAM MDG Technology
2. SGAM Model Templates
3. SGAM Reference Data
The definition of the elements that can be used to model a SGAM related project is done by
the use of MDG Technology. The SGAM MDG Technology holds these definitions.
To ease the work with the Toolbox some Model Templates have been created. They are
based on the above mentioned definitions and can be accessed via the New Model Wizard.
The SGAM Reference Data holds some Information concerning the representation of defined
elements and some definitions for a Model-Import or -Export.
Figure 2 - The SGAM Toolbox Architecture
The most important element of the SGAM Toolbox is the SGAM Metamodel, which is derived
from the SGAM and delivers the available elements and their relations.
Figure 3 - The SGAM Metamodel depicts the SGAM Metamodel as rough overview without
mentioning the individual attributes (implemented as Tagged Values).

www.en-trust.at
class Architecture
SGAM Business Layer
use has
Business Actor
«invokes»
Business Case realizes Business Goal
SGAM Function Layer
composes
High Lev el Use Case invokes Scenario
Primary Use Case
use use
has composes
SGAM Actor
Function Interrelation Use Case Step
«trace» SGAM Information Layer

associates
«trace» associates provides

Data Model Standard Information
Obj ect
has conveys
Information Obj ect Flow
SGAM Communication Layer
has
Communication Relation
SGAM Component Layer

has ICT Association
hosts
SW Component
Application
has Electric Association
Figure 3 - The SGAM Metamodel

www.en-trust.at
4. SGAM Toolbox Installation
The Toolbox Installation Package describes the necessary steps on how to install the SGAM
Toolbox. The Toolbox itself consists of a folder labeled "SGAM Toolbox". The folder's
subfolders and elements are structured according to the Toolbox Architecture, which can be
found in Figure 2 - The SGAM Toolbox Architecture.
SPEM Toolbox Installation
SGAM Toolbox Installation
Please Note: You are required to make use of some

Enterprise-Architect functions here. It is not stated here, where
to find these functions. This is due to the reason that it
depends on your version where you can find the functions.
Please use the very, very useful integrated help to learn more
about these functions.
Step 2 - Import Step 4 - Create a

Step 1 - Copy Step 3 - Import
Reference Data new SGAM Project
Project Templates MDG Technology
Copy the Project Templates to the local Model Import Reference Data Use the MDG-Technology Use the "New Model Wizard" to create your own SGAM Project
Pattern Directory. Use the "Import Reference Data" Function from Enterprise Import function to install the Select "New Model from Pattern" in the Project Browser to launch the
The Project Templates are xml-files. You can find Architect to import the SGAM Reference Data. SGAM Toolbox. Model Wizard. Choose the SGAM-Toolbox in the "Technology" Section.
them under "SGAM Toolbox\Model Templates\" --> Learn about this function by using the "help" from Typically you find it under “Tools On the right side you can select the SGAM Model you want to create.
Copy them to your local Model Pattern Directory. Enterprise Architect. --> MDG Technology Import”.
This directory looks like "C:\Program Files\Sparx The SGAM Reference Data is a xml file that can be found under Use the Enterprise Architect Help Hint 1: It is useful to work with a "Project Template Package" to make
Systems\EA\ModelPatterns" "SGAM Toolbox\Reference Data\SGAM Toolbox Reference to learn more about this function. the elements automatically appear in a specified layout. E.G., use the
Data.xml" The file to import is an xml file rectangular Notation for Use Cases in the SGAM plane. The Toolbox
named "SGAM Toolbox.xml". You delivers an initial Project Template Package that can be generated with
Check if you succeeded: can find it under "SGAM Toolbox the Model Wizard.
Open any diagram, navigate to "Swimlanes and Matrix" and \SGAM Toolbox.xml"
select the "Matrix" Register Card. You will have to restart Enterprise Hint 2: You can find a complete example on www.en-trust.at which
Among the "Model Profiles" in this Register Card you should Architect after importing. could serve as quite good starting point.
find 5 SGAM Layer Profiles, labeled in the way
"SGAM_Function_Layer".
Name: Toolbox Installation

Author: Christian Neureiter
Version: 0.3
Created: 24.06.2013 14:09:01
Updated: 30.11.2013 12:47:38
Figure 4 - SGAM Toolbox Installation
Please Note: You are required to make use of some specific Enterprise-Architect functions
here. It is not stated here, where to find these functions. This is due to the fact that it
depends on your version of Enterprise Architect where to find the functions.
Please use the very, very, very useful Enterprise Architect Help to learn more about these
functions.
Element Notes
Step 1 – Copy the Project Templates to the local Model Pattern Directory.
Copy Project The Project Templates are xml-files. You can find them under "SGAM
Templates Toolbox\Model Templates\"
Copy them to your local Model Pattern Directory.
This directory looks like "C:\Program Files\Sparx
Systems\EA\ModelPatterns\"
Step 2 – Import Reference Data
Import Reference Use the "Import Reference Data" Function from Enterprise Architect
Data to import the SGAM Reference Data.

www.en-trust.at
--> Learn about this function by using the "help" from Enterprise
Architect.
The SGAM Reference Data is a xml file that can be found under
"SGAM Toolbox\Reference Data\SGAM Toolbox Reference Data.xml"
Check if you succeeded:
Open any diagram, navigate to "Swimlanes and Matrix" and select the
"Matrix" Register Card.
Among the "Model Profiles" in this Register Card you should find 5
SGAM Layer Profiles, labeled in the way "SGAM_Function_Layer".
Step 3 – Use the MDG-Technology Import function to install the SGAM
Import MDG Toolbox.
Technology Typically you find it under “Tools  MDG Technology Import”. Use
the Enterprise Architect Help to learn more about this function.
The file to import is an xml file named "SGAM Toolbox.xml". You can
find it under "SGAM Toolbox\SGAM Toolbox.xml"
You will have to restart Enterprise Architect after importing.
Step 4 – Use the "New Model Wizard" to create your own SGAM Project
Create a new SGAM Select "New Model from Pattern" in the Project Browser to launch the
Project Model Wizard. Choose the SGAM-Toolbox in the "Technology"
Section. On the right side you can select the SGAM Model you want
to create.
Hint 1: It is useful to work with a "Project Template Package" to make

the elements automatically appear in a specified layout. E.G., use the
rectangular Notation for Use Cases in the SGAM plane. The Toolbox
delivers an initial Project Template Package that can be generated
with the Model Wizard.
Hint 2: You can find a complete example on www.en-trust.at which

could serve as quite good starting point.

www.en-trust.at
6. Proposed Development Process
The proposed development process is inspired from the Use Case Mapping Process
(UCMP) as introduced by [1].
It basically consists of three phases, where the first two phases reflect the main tasks of the
UCMP, but in an adopted schedule.
First, during the System Analysis Phase, the systems functionality is to be described. This is
done by executing a Use Case Analysis, developing the SGAM Function Layer and
developing the SGAM Business Layer.
Next, during the System Architecture Phase, the development of the Component, the
Information and the Communication Layer is done.
The Design & Development Phase, which addresses the realization of individual systems, is
not SGAM specific and hence can be done by means of classic systems engineering
methods. It is conceptualized as iterative phase to highlight the idea of suggested agile
development.
The following sections describe the steps to be performed in more detail.
Please refer to the provided video tutorials to learn more about the application of this
development process and the steps that have to be done during the execution of each task.
SPEM SGAM Dev elopment Process
SGAM Development Process
System Analysis Phase System Architecture Phase
Develop Develop Develop

Use Case Develop Develop
Function Information Communication
Analysis Business Component
Layer Layer Layer
Layer Layer
The suggested SGAM

Development process is
mapped to the classic
MDA process to align
the elements and the
terminology
«output»
«output» «output» «output»
System Analysis System Architectur

Phase Phase Design &
Implementation
Phase
Computation Platform
Platform Platform Specific
Independent Independent
Specific Model Implementation
Model (CIM) Model (PIM)
(PSM) (PSI)
Name: SGAM Development Process

Version: 0.3
Created: 08.06.2013 21:47:56
Updated: 29.11.2013 17:16:53
Figure 5 - SGAM Development Process

www.en-trust.at
Element Notes
System Analysis During the System Analysis Phase the specification for the system to
Phase be built has to be developed. Therefor it is necessary to identify the
project-roles, the stakeholder and their individual requirements and
the interrelation of the project with its environment and its project
context.
Computation The Term "Computation Independent Model" is taken from Model
Independent Model Driven Architecture (MDA). It focuses on the desired behaviour and
(CIM) function of a system without mentioning how the system is
implemented (Separation of concerns).
System Architectur The System Architecture Phase is used to map the prior defined
Phase functionalities to a basic architecture. This basic architecture consists
of the major function blocks and the concerning interfaces of the
whole system.
Platform Independent The "Platform Independent Model" aims to identify major function
Model (PIM) blocks without relating them to a concrete implementation
Design & The Design & Implementation Phase is designed as iterative process.
Implementation The underlying idea is to support agile development aspects. During
Phase this phase, a prior developed architecture is designed and
implemented.
Platform Specific The "Platform Specific Model" describes the design for the specific
Model (PSM) components. The design is done with respect to the selected
plattform.
Platform Specific The "Plattform Specific Implementation" is the last Layer of the MDA
Implementation (PSI) deliverables. As the name mentions, it depicts the implementation
itself.

www.en-trust.at
7. System Analysis Phase
7.1. Use Case Analysis

The execution of the Use Case Analysis is one of the key tasks that has to be performed. It
focuses on the identification of involved actors and goals and on the decomposition of the
Product-Owner inputs into single Use Cases. As the identified model elements state the
basis for all further modeling, this is a very crucial task and should obtain the necessary
attention.
SPEM Use Case Analysis
Use Case Analysis
«used tool» «used tool» «used tool»
Business
Function
Layer
Layer
Template
Template
Develop Business Develop High Develop

Case Model Level Use Case Primary Use
Model Case Model
«output»
«output»
«output»
Name: Use Case Analysis

Business Author: Christian Neureiter
High Level Primary Version: 0.1.1
Case Use Case
Use Case Created: 19.10.2013 12:24:42
Model Model
Model Updated: 29.11.2013 18:18:38
Figure 6 - Use Case Analysis
The three tasks of the Use Case Analysis are described in the following subsections in detail.
7.1.1. Develop Business Case Model

Focus of this task is the identification of involved Business Actors (BA), their assigned
Business Goals (BG) and individual Business Cases (BC) that are performed by the BA in
order to reach the individual BG. In addition, High Level Use Cases (HLUC) are identified
and modeled that are included by the BC.
After creating a new Enterprise Architect project with an empty model you can make use of
the Model Wizard to get a template for the development of the Business Case Model.
1. Start the Model Wizard (Menu  Project  New Model) and select “SGAM Toolbox” as Technology and
“SGAM Business Layer” as model template. Of course you can also create the single packages and
diagrams manually, but for the beginning the template is useful to get an idea about the concept.
This step creates a new package named “SGAM Business Layer” within your model. The
content of this package is an example that illustrates, how a Business Case Model looks like.

www.en-trust.at
Developing your own Business Case Model comprises the following steps:
2. Model the identified Business Actors by making use of the Model Element “Business Actor”. This
element can be found in the View “Toolbox” and placed by drag and drop onto the diagram.
3. Model the individual Business Goals for every Business Actor by using the element “Business Goal”.
Bring them into relation with the concerning Business Actor by making use of the “dependency” relation.
4. Model the Business Cases that are performed by the Business Actors in order reach the individual
Business Goals. The relation between Business Actor and Business Case is of type “use”; the relation
between Business Case and Business Goal is of type “realize”. Typically numerous Business Cases
exist. You can make use of all UML Use Case relations to model the dependencies between them. It is
also a good practice to make diagrams composit in order to reduce complexity.
5. Identify and model specific High Level Use Cases by making use of the element “High Level Use
Case”. Bring them in relation with individual Business Cases by making use of the “invoke” relation. Say,
a Business Case invokes High Level Use Cases.
Please note that every Business Case from the template is linked to an individual SGAM
Business Layer Diagram. These diagrams will be modeled after finishing the SGAM Function
Layer, as there will be defined which domains and zones are affected by each related High
Level Use Case.
uc Business Case Analysis
Business Case Analysis
The flexibility contract between the

DSO and the Facility Operator is
realized by a dynamic pricing model.
As the prices correlate with the total
load in the Distribution System, they are
a steering mechanism for flexible loads.
Delay DS Optimize
Flexibility Contract
Upgrade Energy Costs
«Business Actor» «Business Actor»
DSO Facility Operator
(from Business (from (from (from Business
Actors and Business Business Actors and
Business Goals) Actors Actors Business Goals)
and and
Business Business
Goals) Goals)
Utilizes Flexible Prov ides Flexible

Loads Loads
(from Utilize Flexible (from Provide Flexible

Loads) Loads)
«invokes» «invokes» «invokes»
«High Level Use ...

«High Level Us... «High Level Us...
Control Electric Load Control E-Car Demand Response
from Thermal Energy
Charging
System
(from Control Electric (from Control E-Car (from Demand

Load from Thermal Energy Charging) Response)
System)
Name: Business Case Analysis

Version: 0.3
Created: 17.06.2013 13:32:38
Updated: 26.11.2013 23:39:35
Figure 7 - Business Case Model (Example)

www.en-trust.at
7.1.2. Develop High Level Use Case Model
After the identification of the involved High Level Use Cases (HLUC) in the prior executed
task they need to be described in more detail. The description of the HLUCs consists of two
basic steps. First, model the relations between the individual HLUC’s by making use of the
standard Use Case relationships from the UML. Next, decompose every single HLUC in
more granular Primary Use Cases (PUC) and describe their cooperation.
These modeling tasks are performed at the level of the SGAM Function Layer. For the ease
of use, the SGAM Toolbox provides some adequate templates which can be used for
modeling as described below:
“SGAM Function Layer” as model template. Of course you can also create the single packages and
This step creates a new package named “SGAM Function Layer” within your model. The
content of this package is an example that illustrates, how a model of HLUCs and PUCs
could look like. Besides the model itself the package shows the best practice for structuring
your model: Inside the package is a SGAM Function Layer diagram located that is used to
depict the relations between the single HLUCs. For every HLUC an individual Sub-Package
with the name of the corresponding HLUC and the stereotype “HLUC” is integrated.
Each of these Sub-Packages holds two diagrams of type SGAM Function Layer. The first
diagram is used to decompose the HLUC into more granular PUCs and to describe their
relations. The second diagram is used to locate the involved PUCs within the SGAM plane,
consisting of domains and zones. Again, for every PUC an individual Sub-Package with the
name of the PUC and the stereotype “PUC” exists.
To create your own High Level Use Case Model follow the steps below:
2. Place all HLUC’s you identified during the prior task on the Top-Level Diagram in the SGAM Function
Layer Package and model the relations between them.
3. To keep your model clean and to enhance the readability of the later on generated reports, create a
package structure as described above and move the HLUCs from the SGAM Business Layer package to
the corresponding Sub-Package in the SGAM Function Layer Package.
4. For every HLUC Sub-Package create a diagram of type “SGAM Function Layer”
5. Decompose the HLUC into more granular PUCs and describe their cooperation. It is good practice to
make use of Activity Diagrams to do so. To create compact information you can also place the Activity
Diagram itself on this diagram. Depict functional interrelations between single PUCs by making use of
the “Functional Interrelation” relation.
6. Hint: You can automatically generate an Activity Diagram from the HLUC. To do so, you have to invoke
the single PUCs within the “Scenario” description of the HLUC. Please learn more about “Scenarios” and
“Generate Diagrams” in the Enterprise Architect Help.

www.en-trust.at
Figure 8 - High Level Use Case Model (Example)

www.en-trust.at
7.1.3. Develop Primary Use Case Model
The aim of this task is a more detailed description for every single Primary Use Case (PUC)
developed in the prior task. Basically it is valid to make use of any possibility that helps
understanding the functionality of the PUC. In praxis it is useful to describe all PUCs in a
similar way. A proven method is to describe the PUCs by using Activity and Sequence
Diagrams. Enterprise Architect comprises a very powerful possibility for an automated
generation of these diagrams. Creating the descriptions that way is a very efficient approach
for modeling the PUCs. To make use of this possibility follow the steps below:
1. Create a SGAM Function Layer Diagram within every PUC Sub-Package and place the corresponding
PUC in it.
2. Describe the functionality of the PUC in any text editor (or use the available Product-Owner description).
Write in a way, that every sentence represents one step or Activity of the PUC and write every sentence
in a new line. Try to create sentences that hold the name of every involved actor and every exchanged
information. For example instead of “Actor A sends Voltage Measurement to Actor B. Actor B responds
with the new operation point” write “Actor A sends Voltage Measurement to Actor B. Actor B transmits
Operation Point to Actor A.”. Now, copy the written text to the clipboard.
3. Open the properties dialog of the corresponding PUC and select “Scenarios” from the “Rules” menu on
the left. Here, select the “Structured Specification” tab and right click into the Action description field.
Now you can select to “create structure from clipboard text”. Doing this, creates for every sentence
written before a single step in the Use Case description. After this, you can close the property.
4. Create for every Actor involved the corresponding Model Element (SGAM Actor) and link it to the PUC.
Take care to name the actors the same way as they are called in the textual description. Of course, if the
Actor already exists in your model, do not create it again but place and link the existing one. If you open
the Scenario Description within the PUC properties dialog again, you will see that the name of the
connected actor is now underlined.
5. Having all involved Actors linked to the PUC, you can generate an Activity and Sequence Diagram
automatically. In the menu bar of the “Structured Specification” tab you can find the Icon for “Generate
Diagrams”. Here you can select which type of diagrams you want to generate.
Please Note: The described functionality is very powerful and enables you to describe Use Cases in a
very efficient way. You can manipulate the activity diagram and update the structured description with
the changes. Of course it is also possible to create alternate and exception paths and much more.
Please refer to the very valuable Enterprise Architect Help to learn more about these capabilities.
6. In the generated Activity Diagram you can analyze the PUC and create model elements for every
Information Item transmitted. Use the element “Information Object” for this task. As this diagram is of
type “Activity Diagrams” you won’t find this element in the toolbox. You have to select the SGAM
Function Layer toolbox by clicking on “More tools…” at the top of the toolbox and selecting “SGAM-
Toolbox / SGAM Function Layer”. Depict the relation between a single Activity (Use Case Step) and the
Information Item by means of the “dependency” relation.
7. In the generated Sequence Diagram you can attach the created Information Items to the corresponding
sequence. Right click on the corresponding connection and select “Advanced/Information Flows
Realized”. In the appearing dialog click on “click to create new information flow…”. A package browser
opens where you can select the referred Information Item. Again, please refer to the Enterprise Architect
Help to learn more.
8. You can place the generated Activity and Sequence Diagrams directly in the PUC diagram simply by
using “drag and drop”. This helps, as you have all relevant description – the PUC and it’s involved
actors, the algorithmic aspect (activity diagram) and the communication aspect (sequence diagram) – in
one diagram that will be used during reporting.

www.en-trust.at
Figure 9 - Primary Use Case Model (Example)

www.en-trust.at
7.2. Develop Function Layer
The SGAM Function Layer describes the location of all involved Primary Use Cases (PUC)
and Actors for a specific High Level Use Case (HLUC). Hence, it has to be developed for
every HLUC separately. The steps below describe how to create the SGAM Function Layer
for a single HLUC.
1. Use the SGAM Function Layer Template to create a new SGAM Function Layer Diagram inside the
“HLUC” package.
2. To make the SGAM Plane (domains and zones) visible, open “Diagram” in the pull down menu and
select the “Swimlanes and Matrix” dialog. Within the register card “Matrix” you can select a Model Profile.
Select the “SGAM Function Layer” Profile and activate the Check-Box “activate” at the top.
3. Place all involved PUCs and Actors in the diagram and arrange them in respect to the corresponding
domains and zones.
SPEM Dev elop Function Layer
Develop Function Layer
«used tool»
Function Layer
Template
Develop SGAM
Function Layer
«output»
Name: Develop Function Layer

SGAM
Version: 0.3
Function
Created: 15.06.2013 17:36:54
Layer Updated: 19.10.2013 13:37:24
Figure 10 - Develop Function Layer

www.en-trust.at
uc Control Electric Load from Thermal Energy System
Generation Transformation Distribution DER Customer Premise

Control
electric load
Market
Enterprise
Operation
«Primar...
Operation Plan
«SGAM Actor»
DMS
(from (from Operation Plan)
Actors)
function interrelation
Station
«Primar...
Control Heat
Generation
«SGAM Actor»
EMS
(from Control Heat (from
Generation) Actors)
Field
function interrelation
function interrelation function interrelation
«Primar... «Primar... «Primar...

Data Control Heat Control CHP
Acquisition Pump
(from Data Acquisition) (from Control Heat (from Control CHP)

Pump)
Process
«SGAM Actor» «SGAM Actor» «SGAM Actor»

Thermal Storage HP CHP
(from (from (from
Actors) Actors) Actors)
Name: Control Electric Load from Thermal Energy System

Version: 0.1.1
Created: 22.11.2013 19:49:40
Updated: 26.11.2013 23:39:35
Figure 11 - SGAM Function Layer (Example)
7.3. Develop Business Layer

The focus of the SGAM Business Layer is to show the affected domains and zones for every
Business Case and hence has to be modeled for each of them. It is suggested to use the
involved High Level Use Cases as model elements. The steps below describe how to model
the SGAM Business Layer for a single Business Case.
1. Use the SGAM Business Layer template to create a new SGAM Business Layer diagram for every
Business Case (New Diagram/SGAM Toolbox/SGAM Business Layer)
Select the “SGAM Business Layer” Profile and activate the Check-Box “activate” at the top.
3. For every invoked HLUC open the SGAM Function Layer diagram and analyze which domains and
zones are affected.
4. Go to the SGAM Business Layer diagram and place the corresponding HLUC in it. Switch the
appearance of the HLUC to rectangular (right click / Advanced / Use Rectangular Notation)

www.en-trust.at
5. Locate and resize the HLUC according to the affected domains and zones. Having done this for all
HLUCs, you see which domains and zones are affected by the Business Case in total.
6. Place the Business Case in the diagram (at the bottom of the Z-Order), switch to rectangular notation
and resize and locate it according to the totally affected domains and zones.
SPEM Dev elop Business Layer
Develop Business Layer
«used tool»
Business Layer
Template
«output»
Align Business
Cases in SGAM
Business Layer
Name: Develop Business Layer

SGAM Version: 0.3
Business Created: 15.06.2013 17:22:43
Layer Updated: 19.10.2013 12:38:08
Figure 12 - Develop Business Layer

uc Prov ide Flexible Loads
Market
Enterprise
Operation «business use case»

Prov ides Flexible Loads
«High Level Use Case»
Control E-Car Charging
Control Electric Load from Thermal Energy System
Station
Demand Response
Field
Process
(from Demand Response)
(from Control Electric Load from Thermal Energy System)

(from Control E-Car Charging)
Figure 13 - SGAM Business Layer (Example)

www.en-trust.at
8. System Architecture Phase
8.1. Develop Component Layer

The development of the SGAM Component Layer represents the model transformation from
the Computational Independent Model (CIM) to the Platform Independent Model (PIM). This
transformation maps the functional description of the system to a general, architectural
solution.
Hence, in a first step a mapping from logical actors to physical components has to be done.
Next, the identified physical actors are utilized to create the SGAM component layer.
Both steps can be executed by usage of the supplied Component Layer Template.
SPEM Dev elop Component Layer
Develop Component Layer
Component «used tool»

«used tool» Layer Template
Map Actors to Develop

physical Component
Components Layer
«output» «output»
Name: Develop Component Layer

SGAM Author: Christian Neureiter
Actor
Component Version: 0.3
Mapping
Layer Created: 15.06.2013 12:55:23
Model
Updated: 26.06.2013 14:42:01
Figure 14 - Develop Component Layer
8.1.1. Map Actors to physical Components

To perform the mapping of the logical Actors (as created in the Function Layer) to physical
Components follow the steps below:
1. Use the SGAM Component Layer template to create a new SGAM Component Layer diagram
2. Place all involved logical Actors to the diagram
3. Create a physical representation (component) for every Actor. This physical representation can either be
a specific component or a Software Application. You can use the appropriate model elements from the
toolbox for this step. Use the “trace” relation to depict the model transformation step. You can also
create new Components by using the general “Component” element. It is also possible to use your own
images for these Components. Please use the Enterprise Architect Help to learn more about this
possibility.
4. If a Software Application is introduced, you need to create a “Computer” Component as well. Use the
“hosts” relation to show, which computer hosts which Software Application.

www.en-trust.at
deployment Actor Mapping Model
Actor Mapping Model
«SGAM Actor» «SGAM Actor» «SGAM Actor» «SGAM Actor» «SGAM Actor»
CHP DMS EMS HP Thermal Storage
(from (from (from (from (from
Actors) Actors) Actors) Actors) Actors)
«trace» «trace» «trace» «trace» «trace»
HP Controller Storage IED

CHP Controller DMS Controlling EMS
App
«hosts»
G
Heat Pump Thermal
CHP DMS Storage
Figure 15 - Actor Mapping Model (Example)
8.1.2. Develop Component Layer

The development of the SGAM Component Layer can be done by following the steps below:
1. Use the SGAM Component Layer template to create a new SGAM Component Layer
Select the “SGAM Component Layer” Profile and activate the Check-Box “activate” at the top.
3. Place all prior created physical components within the plane in the corresponding domain and zone.
4. Create additional necessary components, like ICT-Networks (represented as clouds), Electric Networks
(e.g. “Medium Voltage Network”) or electric components like Transformers. Following the modeling-
concepts you can of course make single components like for example ICT-Networks “composite” and
describe them in more detail. Please refer to the Enterprise Architect Help to learn more about this
possibility.
5. Model the relations between the individual components. You can use the “Electric Association” relation
to depict electric connections, especially along the electric conversion chain in the process zone, and
“ICT Association” to model ICT connections.

www.en-trust.at
deployment SGAM Component Layer
Market
Enterprise
Operation
Components::DMS
DLC NW
Station
Components::EMS
Field
Components::HP Components::CHP Components::

Controller Controller Storage IED
Process
G
Components::Heat
Pump Components::CHP
«Electric NW»
LV
MV/LV Components::
Thermal Storage
Figure 16 - SGAM Component Layer (Example)
8.2. Develop Information Layer

Focus of this task is to model the information object flows between the single components
and to identify proper data model standards that are suitable to reflect these information
objects.
The development of the Information Layer consists of three consecutive tasks as described
in the following subsections.
You can make use of the Model Wizard to create the involved diagrams automatically:
“SGAM Information Layer” as model template. Of course you can also create the single packages and
This step creates a new package named “SGAM Information Layer” within your model. The
content of this package is an appropriate sub package for each of the three necessary steps.
8.2.1. Develop Business Context View

The Business Context View models the information object flows between individual
components. It can be developed following the steps below:
1. Open the “Business Context View” Diagram as created from the Model Wizard or create this diagram
manually
2. Place all components in the diagram. Hint: If you copy the elements from the Component Layer, you will
have arranged them in the same way as in the Component Layer

www.en-trust.at
3. Hide Relations. After placing the components in the diagram, all relations (e.g. ICT Associations, Electric
Associations) as introduced so far will be visible. As we are not interested in these relations within the
Information Layer, you can make them invisible. Open the “Diagram” Drop-Down Menu, select
“Advanced”  “Visible Relations” and deselect all relations. Do not accidently delete these relations
instead of making them invisible. Deleting them will delete them not only from the diagram but from the
model, so you won’t see them in the original diagrams anymore.
4. Create Information Object Flows. In the Primary Use Case Diagram we identified which Information
Objects are to be communicated between logical actors. Use the “Information Object Flow” Relation to
model these flows here as well and select the appropriate “Information Objects” in the Pop-up window.
Note: This step is some “copy” task, in a future version of the SGAM Toolbox this will be automated.
class Business Context View
Business Generation Transformation Distribution DER Customer Premise
Context
Market
Enterprise
Operation «Information Object»

Authentication Credentials
«Information Object Flow»

«Information Object» Energy Price Table
Components::DMS
Station
«Information Object»
Storage Temperatures

Components::EMS
«Information Object» HP Operation Point

Field «Information Object Flow»
«Information Object» CHP Operation Point

Process
Figure 17 - Business Context View (Example)
8.2.2. Perform Standard and Information Object Mapping
1. Open the “Standard and Information Object Mapping” Diagram as created from the Model Wizard or
create this diagram manually

www.en-trust.at
have arranged them in the same way as in the Component Layer
3. Turn the visibility of all relations – except the Information Object Flows – off
4. Create appropriate “Data Model Standard” Elements and associate the related components with them by
using the “Associates Data Model Standard” relations.
5. Place all used Information Objects in the diagram and state the relations between Data Model Standards
and Information Objects by using the “Provides Information Object” relations.
class Standard and Information Obj ect Mapping
Standard and Information Object Mapping
Authentication
«Data Model Stand... Credentials
My Energy-Price Standard
(from Information Objects)
«Associates Data Model»
Energy Price Table

Authentication Credentials
«Information Object Flow» «Associates Data Model»

«Information Object» Energy Price Table
Components::DMS

Components::EMS
«Information Object» HP Operation Point

«Information Object» CHP Operation Point
«Associates Data Model»

«Associates Data «Associates

Model» Data«Associates
Model» Data Model» «Information Object»
«Data Model Standa... (from Information Objects)

OPC-UA «Information Object»
CHP Operation Point

HP Operation Point Name: Standard and Information Object Mapping
Author: chn
(from Information Objects) Version: 0.3
Created: 17.06.2013 14:10:36
Updated: 26.11.2013 23:39:36
Figure 18 - Standard and Information Object Mapping (Example)
8.2.3. Develop Canonical Data Model View
1. Open the “Canonical Data Model View” Diagram as created from the Model Wizard or create this
diagram manually
have arranged them in the same way as in the Component Layer.
3. Place all related “Data Model Standard” Elements in the diagram

www.en-trust.at
4. Resize and arrange the “Data Model Standard” Elements over domains and zones according to their
associated components
class Canonical Data Model
Canonical Generation Transformation Distribution DER Customer Premise
Data
Model
Market
Enterprise
Operation
«Data Model Standard»
My Energy-Price Standard
Components::DMS
Station
(from Standard and Information Object Mapping)

«Data Model Standard»
OPC-UA
Components::EMS
Field
(from Standard and Information Object Mapping)

Components::CHP
Components::HP
Controller Controller Components::
Storage IED
Process
Figure 19 - Canonical Data Model View (Example)

www.en-trust.at
8.3. Develop Communication Layer
The focus of the Communication Layer is to depict the used technology and protocols for the
communication between single components.
You can model this layer by following the steps below.
“SGAM Communication Layer” as model template. Of course you can also create the single packages
and diagrams manually, but for the beginning the template is useful to get an idea about the concept.
have arranged them in the same way as in the Component Layer.
3. Hide Relations. After placing the components in the diagram, all relations (e.g. ICT Associations, Electric
Associations) as introduced so far will be visible. As we are not interested in these relations within the
Information Layer, you can make them invisible. Open the “Diagram” Drop-Down Menu, select
“Advanced”  “Visible Relations” and deselect all relations. Do not accidently delete these relations
instead of making them invisible. Deleting them will delete them not only from the diagram but from the
model, so you won’t see them in the original diagrams anymore.
4. Use the “Communication Path” Relations to model the communication paths between the components
5. For every communication path define the protocol and the technology as tagged value
sd SGAM Communication Layer

Comm.
Layer
Market
Enterprise
Operation
Protocol: WebServ ice

Technology: ADSL
Components::DMS
Station
Protocol: OPC-UA Protocol: OPC-UA

Technology: Ethernet
Technology: Ethernet
Components::EMS
Protocol: OPC-UA
Field Technology: Ethernet

Process
Name: SGAM Communication Layer

Author: chn
Version: 0.3
Created: 17.06.2013 14:27:12
Updated: 29.11.2013 21:15:09
Figure 20 - SGAM Communication Layer (Example)

www.en-trust.at
9. Design and Development of single Components
The development of all five SGAM layer delivers a big picture of a distributed smart grid
system. For every component it is defined, which functionality it has to deliver and how it
interacts with its surrounding components over all interoperability layers.
For the development of one, specific component out of this distributed system you could say
that the systems’ context and the systems’ interfaces are defined. The system (component)
itself is yet treated as black box. During the development of this system, the black box now is
to be turned into a white box.
To start the development one component it is a very valuable possibility, to show the
functionality and all interfaces over all interoperability layers in one diagram. This can easily
achieved by following the steps below:
1. Make the system (component) of interest composite and create a new diagram
2. Place the component in this diagram
3. Right click on the component and select “insert related elements”. Now all related elements and the
relations are placed into this diagram.
Figure 21 - Component Responsibility Model (Example)

www.en-trust.at
10. Non-Functional Requirements
The afore mentioned issues describe how to architect Smart Grid Systems with focus on
their functionality, which is denoted by means of Use Cases.
However, in such systems do not only have to meet functional requirements but also non
functional requirements like Reliability, Availability, Maintainability, Safety, Security and
Privacy.
This section should give you an idea how to approach these issues.
10.1. Security Requirements

Due to the nature of the Smart Grid as “critical infrastructure”, Security is of central interest.
In this subsection is discussed, how to obtain, analyse and maintain Security Requirements
for a certain Smart Grid System. First, the theoretical background is outlined on basis of a
Conceptual Framework. Subsequent to this it is illustrated, how the SGAM Toolbox can
support the Requirements Engineering Task.
10.1.1. Theoretical Background

All security considerations are built around a certain “Asset” that could be subject to an
attack. Every Asset implicitly has some Vulnerabilities that potentially can be exploited. Say,
every Vulnerability is potentially exploited by a certain Threat. An Attack is the actual
exploitation of a Threat, so an Attack is the realization of a Threat by a certain Attacker.
In order to mitigate the existing Vulnerabilities we want to implement some specific
Countermeasures. These Countermeasures can be seen as the Realization of the Security
Requirements we are going to determine during the Requirements Engineering task.
Figure 22 shows the relations between these entities.
class Security Metamodel - Asset
Security Requirement realizes
Security Asset
has mitigated by
Vulnerability Countermeasure
potentially exploited by actually exploited by
Threats realizes Attack
executes
Attacker
Figure 22 - Security Asset
Before the individual Security Requirements can be determined, it is necessary to more

closely describe the “Security Asset” entity.
If we take a closer look to Attacks, we can say a successful attack manipulates or
compromises a certain system. This means that some data (includes malicious commands)
is introduced or extracted from the system. A system typically has two types of interfaces to

www.en-trust.at
it’s environment, which we call “System Context”. First, a User Interfaces provide the
possibility for direct interactions with users and second Communication Interfaces allow
communication with other systems.
This considerations deliver two types of Assets that can be attacked in order manipulate a
system:
 System Security Asset
 Communication Security Asset
Before an Attack to these Assets can be executed it is necessary for an Attacker to get
access to a System’s interfaces. This means whether physical access to a certain system or
network access. As Network Access also comprises physical Access to a network, we
combine them to one single Asset:
 Network Security Asset
This concept is depicted in Figure 23.

class Security Assets
Attacker Attacker Attacker
Attack Communication Attack Communication
Attack System Attack System
Protocol:
Technology:
Technology:
System B
ICT NW
System A
Attack Network
Attacker
Figure 23 - Security Assets
Back to our Conceptual Framework this shows, that Security Assets can be categorized -
according to their originating elements – in three different categories.
1) System
2) Communication
3) Network
Hence, each of these Asset Categories, needs it’s specific Security Requirements.
Classifying Assets into these three categories delivers a certain benefit: As the natures of
elements within a category are quite similar, a basic set of Security Requirements for every
Asset Category can be formed and used as starting point.
The aggregate of these Security Requirements reflects the Realization of an individual
Security Strategy. The Security Requirements Pattern integrated in the SGAM Toolbox are
based on a four layer strategy. Thus, all individual Security Requirements can be mapped to
one of the four security Layer
 Policy
 Technical Measures
 Detection and Forensics
 Containment

www.en-trust.at
Figure 24 shows the Conceptual Framework, extended by Security Requirements for every
Asset Category and the composition of Security Requirements by Requirements of all layer.
class Security Metamodel - Requirements
System Security has System Security Asset

Requirement
Network Security has Netw ork has mitigated by

Requirement
Communication Security has Communication

Requirement
Threats realizes Attack

Security Strategy
Policy
Requirements
executes
Technical
Measures
Detection & Attacker

Forensics
Containment
Figure 24 - Security Requirements
Of course, the individual Requirements for every element will differ and hence, the general
“Requirement Patterns” can only serve as “qualitative” starting point, like for example
“Authentication”.
To turn the general requirements for every system into more specific, say quantitative
requirements like “ Authentication with Username/Password” or “Authentication with physical
Token and PIN code” it is necessary, to determine the Risk, every Asset is facing.
Basically, the Risk is built upon the potential Loss or harm that can be delivered by a
compromised system and the Likelihood of a successful Attack.
Figure 25 shows the extended Conceptual Framework.
class Security Metamodel
System Security has System

Security Asset
Requirement
Network Security has Netw ork has mitigated by

Requirement
Communication Security has Communication

Requirement
associates Threats realizes Attack

Security Strategy
Policy
Requirements
has Reduced by
associates executes
Technical
Measures
Detection & Likelihood Attacker

Forensics Potential Loss or Harm
Containment
determines determines
Risk
Figure 25 - Risk

www.en-trust.at
To calculate the Risk for every system, a very simple formula is suggested:
𝑛
𝑅𝑖𝑠𝑘 = 𝑆𝐿 ∗ 2𝐷𝑂𝐸 ∗ ∑ 𝐴𝑃𝐼𝑖

𝑖=1
SL… Security Level (from M/490 SGIS): Criticality of a System

DOE…Direct Operational Effects {0,1}
API… Attack Probability Indicator
The formula basically multiplies the potential harm with an indicator for the probability of a
successful attack. The value for the potential harm is determined from the “Security Level” as
provided as guidance from the M/90 SGIS working group. It is directly related to an elements
position within the SGAM plane as depicted in Figure 26.
Figure 26 - SGIS Security Level Guidance (from M/90 SGIS working group report)
In addition to the Security Level we introduced a factor (2DSO) to incorporate whether direct
operational effects to the grid are to be expected or not.
Contrasting to the potential harm, the probability of a successful attack is harder to get.
However, to get an idea about the probability we suggest the usage Indicators to get a
qualitative value. The main indicators are:
 Hackers Motivation (How much effort is an attacker willing to spend?)

 Assets Reachability (How easy is the system reachable for attacks?)
 Propagation of Secrets (How many participants have legally access?)
To make the assessment of the single indicators practicable and to obtain smiliar results
from different assessors we suggest to only use values from 1 to 3 for every indicator.
An example for such a Risk Assessment is given in Figure 27.

www.en-trust.at
Figure 27 - Risk Assessment Example
Please note, that all the mechanisms according the evaluation of the Risk, especially the
formula and the API’s are only a “first version” suggestion that should demonstrate the
mechanisms behind the process. Of course, all of them can and should be adopted to your
individual needs!
10.1.2. Requirements Engineering

The Requirements Engineering Process can basically be divided in to three separate steps:
1) Identify the Security Assets and apply the according qualitative Requirements Pattern
2) Assess the Risk for every Asset
3) Refine the Security Requirements for every System according to the existing Risk.
To start the Requirements Engineering follow the steps below:
1. Create a new Security Requirements Diagram place all components and networks there and make all
ICT Connections and Communications visible.
2. Apply System Security Requirements, Network Security Requirements and Communication Security
Requirements to every associated Component.
class Security Requirements
Protocol: Proprietary
Technology: Technology:
Management
Ethernet Ethernet IED
System Operational NW
Management System Management System / IED Operational NW Security IED System Security
Security Communication Security

www.en-trust.at
To apply the Requirements Pattern, follow the steps below:
1. Open the Composite Diagram of a Requirement and place the Requirement in the Diagram
2. Select the appropriate pattern in the toolbox and drop it to the diagram
3. Merge the pattern with the existing Requirement: In the “Insert Pattern” Dialog navigate to the top level
Requirement of the pattern, e.g. “Network Security”, select the Action “Merge” and navigate to the
individual Requirement. The pattern’s top level requirement will be replaced with the existing, individual
requirement.
Figure 28 - Merge pattern with existing element
class System Security
System Security
notes
System Security aims at counteracting unintended
manipulation or spying of systems
Security against Insider

Security against Security against System Attacks
Outsider System Attacks System Security aims at "Compromised Clients"
counteracting System Attacks
unintended
manipulation or spying
of systems
Client Supervision System Access Access Control

Restrictions (Authentication)
(Authorisation)
Control, Document and

Minimize System Access
Maintain System
Possibilities (Remote Access)
Entry-Points
Require strong credentials Automated Account Expiry

Client Security Policies Process
Limit Permissions for

Secure Credential Handling
unmanaged clients
Emphasize Client Security
(Automated Patching,
Minimize Access Permissions
Periodic Credential Renewal Malware Detection,...)
Detection of suspicious
clients Control, Document and
Blocking of Brute-Force Force expiration of insider
Maintain Access Permissions
Attacks access information
Client Compromised Incident
Process Maintain different security
Prevent Code-Injection Combine "Have a token" and
levels for different
Attacks "know a secret" paradigm
functionalities
Detection of Brute-Force or Anomaly/Intrusion Detection Control, Document and

Code-Injection Attacks Maintain authorised Clients
Tracking and Documentation

Maintain Containment Anomaly Detection
of attacks
Principle for individual
security segments
Operate System in isolated
space Access Tracking
Reaction-Plan to insuccessful
system attack User Access Feedback
Reaction-Plan to successful
attack Minimize Access Rights
(Containment of single
Access)
Legend Access Incident Process
Policy
Measure
Detection and Forensic
Containment
Periodic Assessment
of Security
Requirements
Figure 29 - Example for instantiated Requirements Pattern

www.en-trust.at
To start with the risk assessment, open the Security Requirements Diagram and create
“Risk” elements for every identified asset.
For the assessemt of the Risks it is a good praxis, to export all Risk elements to a CSV file
and make the Assessment in a single Excel sheet. After the Assessment, the values for the
individual Attributes can be reimported to the model again.
An appropriated Specification for CSV Import/Export of Risk elements is integrated in the
SGAM Toolbox.
class Security Requirements
Associated Risk
«Risk» «Risk» «Risk» «Risk»

Management System Risk Management System / IED Operational NW Risk IED System Risk
Communication Risk
tags tags tags
1.1 Hackers Motivation = tags 1.1 Hackers Motivation = 1.1 Hackers Motivation =
1.2 Asset Reachability = 1.1 Hackers Motivation = 1.2 Asset Reachability = 1.2 Asset Reachability =
1.3 Propagation of Secrets = 1.2 Asset Reachability = 1.3 Propagation of Secrets = 1.3 Propagation of Secrets =
2.1 SGIS Security Level = 1.3 Propagation of Secrets = 2.1 SGIS Security Level = 2.1 SGIS Security Level =
2.2 Direct Operational Effects = 2.1 SGIS Security Level = 2.2 Direct Operational Effects = 2.2 Direct Operational Effects =
3.1 Calculated Risk = 2.2 Direct Operational Effects = 3.1 Calculated Risk = 3.1 Calculated Risk =
3.1 Calculated Risk =
associates
associates associates associates
associates
Security Assets
Protocol: Proprietary
Technology: Technology:
Management
Ethernet Ethernet IED
System Operational NW
Security Requirements
Management System Management System / IED Operational NW Security IED System Security
Security Communication Security
After having the basic requirements attached to the systems and having the individual Risks
assessed, the refinement of the created requirements can be done, which of course is a
manual task.
Please recognize the “Security Assessment” Elements within the Requirements Patterns.
These elements and their link to selected requirements give you the possibility to easily
access and create some “Check-Lists” for periodic Security Assessments, which are a vital
element for security.

www.en-trust.at
11. Generating Reports
The generation of reports is a very powerful possibility delivered by Enterprise Architect. You
can both, create HTML reports (Click through the whole model in an ordinary Internet
Browser) or create documents.
The toolbox provides some useful templates which directly can be used for the generation of
reports or which can be extended according to the individual needs. These templates are
available in the “Resources” View under the section “Templates  Document Templates 
SGAM Toolbox”.
As the possibilities for automated generation of reports are vast and hence, introduce a
certain complexity, the publication of a video tutorial according this task is scheduled in near
future.
12. Acknowledges and Future Work

The financial support of the Josef Ressel Center by the Austrian Federal Ministry of
Economy, Family and Youth and the Austrian National Foundation for Research, Technology
and Development is gratefully acknowledged.
Funding by the Austrian Federal Ministry for Transport, Innovation and Technology and the
Austrian Research Promotion Agency (FFG) under Project 838793, ``INTEGRA'', is gratefully
acknowledged.
As the SGAM Toolbox appears to be a very useful help for architecting Smart Grid Systems
continuous development is planned. The features for the next iteration will be selected
according to the gained experience during application in various projects.
However, a few feature requests already exist as you can find below:
 Integration/Import of the Intelligrid Use Case Template

 Visualization
 Integration of Libraries
o ENTSO-E Role Model
o M/490 Use Case Management Repository
o M/490 Actor List
o ICT Component Library
o Data Model Standards
o Protocol/Technology Standards
o …
 Automate Model Transformations
o Use Case <–> Component Mapping
o Information Object Flows
 Logic Mapping of Elements to Domains/Zones
 Element Attribute Refinements

www.en-trust.at
13. References
[1] Smart Grid Coordination Group, „Smart Grid Reference Architecture,“

CEN/CENELEC/ETSI, 2012.

www.en-trust.at

Introduction To SGAM Toolbox

Uploaded by

Copyright:

Available Formats

Introduction To SGAM Toolbox

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Introduction To SGAM Toolbox

Uploaded by

Copyright:

Available Formats

Introduction to the „SGAM Toolbox“

Author: Christian Neureiter (christian.neureiter@en-trust.at)

Introduction to SGAM-Toolbox 2/39

Introduction to SGAM-Toolbox 3/39

Figure 1 - The Smart Grid Architecture Model (SGAM) [1]

Introduction to SGAM-Toolbox 4/39

2.1. The Interoperability Layer

Communication Layer: The emphasis of the communication layer is to describe protocols

2.2. The Smart Grid Plane

In general power system management distinguishes between electrical process and

Introduction to SGAM-Toolbox 5/39

Introduction to SGAM-Toolbox 6/39

In addition to aggregation the partitioning in zones follows the concept of functional

Introduction to SGAM-Toolbox 7/39

Figure 2 - The SGAM Toolbox Architecture

Introduction to SGAM-Toolbox 8/39

SGAM Business Layer

SGAM Function Layer

«trace» SGAM Information Layer

«trace» associates provides

SGAM Communication Layer

SGAM Component Layer

Figure 3 - The SGAM Metamodel

Introduction to SGAM-Toolbox 9/39

SGAM Toolbox Installation

Please Note: You are required to make use of some

Step 2 - Import Step 4 - Create a

Name: Toolbox Installation

Figure 4 - SGAM Toolbox Installation

Introduction to SGAM-Toolbox 10/39

Hint 1: It is useful to work with a "Project Template Package" to make

Hint 2: You can find a complete example on www.en-trust.at which

Introduction to SGAM-Toolbox 11/39

SPEM SGAM Dev elopment Process

SGAM Development Process

System Analysis Phase System Architecture Phase

Develop Develop Develop

The suggested SGAM

«output» «output» «output»

System Analysis System Architectur

Name: SGAM Development Process

Figure 5 - SGAM Development Process

Introduction to SGAM-Toolbox 12/39

Introduction to SGAM-Toolbox 13/39

7.1. Use Case Analysis

SPEM Use Case Analysis

Use Case Analysis

«used tool» «used tool» «used tool»

Develop Business Develop High Develop

Name: Use Case Analysis

Figure 6 - Use Case Analysis

7.1.1. Develop Business Case Model

Introduction to SGAM-Toolbox 14/39

Business Case Analysis

The flexibility contract between the

Utilizes Flexible Prov ides Flexible

(from Utilize Flexible (from Provide Flexible

«invokes» «invokes» «invokes»

«High Level Use ...