Critical Infrastructures Governance

Exploring SCADA Cybernetics through Architectured Policy Semantic

Djamel Khadraoui and Christophe Feltus
Service Science and Innovation, Public Research Centre Henri Tudor
29, avenue John F. Kennedy
L-1855 Luxembourg-Kirchberg, Luxembourg
christophe.feltus@tudor.lu
Abstract SCADA-systems are very complex, sophisticated and
integrated systems which support people in monitoring and
governing the huge volumes of knowledge engendered by critical
infrastructures (industry, energy, transport, and healthcare).
These systems are elaborated upon a colossal range of
precontrived components which need to interact thoroughly with
each other although, a priori, they all use heterogeneous
technologies and protocols, they behave unevenly through the
SCADA architecture, and they are all located in miscellaneous
corners of the production system. Furthermore, these
components interact, amongst other, by means of policies which
formulate the reasoning for component behaviour in terms of
expecting actions realization or in terms of accessed information.
This paper explores these policies semantic through a unified
component modelling approach with the aim of providing a
homogeneous and coherent framework, adapted for the
governance of the system by all SCADA and non-SCADA
operators.
Keywords Policy management; SCADA system; architecture;
IS security; critical infrastructure.

I.

INTRODUCTION

SCADA systems are very complex, sophisticated and

integrated systems which support people in monitoring and
governing the huge volumes of knowledge engendered by
critical infrastructures (CI in industry, energy, transport, and
healthcare) [1]. In our previous work, we have defined a
metamodel for the components of the SCADA architecture
[2]. This metamodel has been elaborated acknowledging
traditional enterprise architecture metamodel (EAM) and it
allows modelling each component according to a similar
structure. This structure proposes a representation of the latter
based on a three layered perspective, namely: the organization
layer, the application layer and the technical layer [4, 5].
Contrary to traditional EAM, one particular aspect of the
metamodel elaborated for SCADAs components is that it is
enriched with the concept of policy at the two upper
architecture layers, thereby making it possible to elicit
organizational policies and application policies [2].
Depicting SCADA systems allows acknowledging the wide
range of components which compose it [6], like for instance:
the remote terminal unit (RTU), the intrusion detection system
(IDS), the monitoring tools, the honeypots, and so forth. These
components need to interact with each other and therefore, it is
fundamental to have the system supported by accurate and
1

Supervisory Control and Data Acquisition

perfectly integrated policies. Indeed, when for instance, a

monitoring system detects an intrusion, it requests the firewall
to adapt the filtering policy to face this intrusion. This
requirement for adaptation is achieved by a filtering policy
modification, induced by the monitoring tool. Another example
is the alert correlation performed by a correlation engine. The
homology is achieved according to the correlation policy which
receives alerts from different network sources and which, based
on the correlation policy, generates a new policy at the
destination of the protection mechanisms such as the access
right manager, the server, and so forth. In this context, the
amount of generated policies is very important. Their
elaboration is based on different (meta-) models [7] which have
different semantics (intrusion detection, alert correlation,
reaction, access control, etc. [8]), and that are activated at
different layers of the network (organizational, application or
technical policies).
The objective of this work is to support the SCADA
manager and human operators with an integrated approach for
designing, managing and monitoring SCADA systems policies.
To that end, we propose a solution which consists in modelling
each SCADA component based on the SCADA metamodel, to
elaborate the connections between the SCADA components
instances, and to define the policy acknowledging the
information in input, the expected format of the outlay policy,
and the operational rules. This paper is organized as follows. In
the next section, we propose a synthetic review of the SCADA
metamodel, in Section III, we highlight how a policy may be
easier engineered following components instances and how a
policy monitoring solution may concretely benefit the SCADA
operators and managers. Afterwards we provide a case study
extracted from [15] and finally, we describe the main related
work and conclude the paper.
II.

SCADA METAMODEL BACKGROUND

This section recalls our previous work in the field of SCADA

system modelling. We first introduce the SCADA metamodel,
followed by the SCADA modelling layers.
A. SCADA metamodelling insights
Our goal in modelling the SCADA system into a layered
architecture metamodel is to provide CI operators with the
tools for governing SCADA systems (monitoring and decision
making). In previous works [2], we have elaborated such a
SCADA metamodel based on the ArchiMate language to give
a multiple layered view of a SCADA component using
policies. To generate the latter, we realized a specialization of
the original ArchiMate metamodel for SCADA components.

Firstly, we redefined the Core of the metamodel in order to

figure out the concept of the Policy (Fig. 1.). The Core
represents the handling of Passive Structures by Active
Structures during the realization of Behaviours. For the Active
Structures and the Behaviour, the Core differentiates between
external concepts, which represent how the architecture is
being perceived by the external components (as a Service
Provider attainable by an Interface), and the internal concept
which is composed of Structure Elements (Roles,
Components) and linked to a Policy Execution concept.
Passive Structures contains Object (e.g. data and
organizational object) which represents architecture
knowledge. Secondly, the concept of Policy was defined in
accordance to the SCADA metamodel. The proposed
representation is composed of three elements defining the
Policy:
1. Event is defined as something done by a Structure
Element which generates the execution of a Policy.
2. Context symbolizes a configuration of Passive Structure
that allows the Policy to be executed (e.g. a security level
or the value of an object).
3. Responsibility [9, 10] is defined as a state assigned to an
agent (human or software) to specify obligations and rights
in a specific context [2]. Thereby, responsibilities
correspond to a set of behaviours that have to be performed
by Structure Elements. This behaviour can use Object from
Passive Structure or modify values.
With these three elements, we generate an auxiliary Policy
artefact mirroring the execution of a set of Responsibilities in
a specific Context and in response to a determined Event.
Concepts and colours were taken from the original
ArchiMate metamodel, except for Organizational Function
and the Application Function which were replaced by the
Organizational Policy concept and the Application Policy
concept. Through the Policy Concept, we show that each
operation done by the SCADA components can be transferred
into a Policy Execution. Although there is a semantic
difference in ArchiMate between the application and the user
who exploits the application, in the SCADA domain, we
consider that actors and roles are played by components that
we define as being specific Structure Elements acting in CI
context. Hence, three layers structure the metamodel for the
SCADA components:
4. The Organizational Layer offers products and services to
external customers, which are realized in the organization
by organizational processes performed by Organizational
Roles according to Organizational Policies.
5. The Application Layer supports the Organizational Layer
with Application Services which are realized by
Applications according to Application Policies.
6. The Technology Layer offers Infrastructure Services
needed to run applications, realized by computer and
communication hardware and system software.
Based on this analysis, we had defined the Organizational
Policy as the rules which define the organizational
responsibilities and govern the execution of behaviours, at the
organization domain, that serve the product domain in
response to a process domain occurring in a specific context,

which is symbolized by a configuration of the information

domain. And we defined the Application Policy as the rules
that define the application responsibilities and govern the
execution, at the application domain, of behaviours that serve
the data domain to achieve the application strategy.
B. SCADA metamodel layers
The three layers which structure the SCADA metamodel (Fig.
1) are the Organizational, Application and Technical Layers:
The Organizational Layer highlights the organizational
processes and their links to the Application Layer. At first the
Organizational Layer is defined by an Organizational Role
(e.g. Alert Detection Component). This role, accessible from
the outside through an Organizational Interface, performs
behaviour on the basis of the organization's policy
(Organizational Policy) associated with the role. Then, the
component is able (depending on its role) to interact with other
roles to perform behaviour; this is symbolized by the concept
of Role Collaboration [2]. Organizational Policies are
behavioural components of the organization whose goal is to
achieve an Organizational Service to a role following Events.
Organizational Services are contained in Products
accompanied by Contracts. Contracts are formal or informal
specifications of the rights and obligations associated with a
Product. Values are defined as an appreciation of a Service or
a Product that the Organization attempts to provide or acquire.
The Organizational Objects define units of information that
relate to an aspect of the organization.
The Application layer is used to represent the Application
Components and their interactions with the Application
Service derived from the Organizational Policy of the
Organizational Layer. The concept of the components in the
metamodel is very similar to the components concept of UML
[11] and allows representing any part of the program.
Components use Data Object which is a modelling concept of
objects and object types of UML. Interconnection between
components is modelled by the Application Interface in order
to represent the availability of a component to the outside [2]
(implementing a part or all of the services defined in the
Application Service). The concept of Collaboration from the
Organizational Layer is present in the Application Layer as
the Application Collaboration and can be used to symbolize
the cooperation (temporary) between components for the
realization of behaviour. Application Policy represents the
behaviour that is carried out by the components.
The Technical Layer is used to represent the structural
aspect of the system and highlights the links between the
Technical Layer and the Application Layer and how physical
pieces of information called Artefacts are produced or used.
The main concept of the Technical layer is the Node which
represents a computational resource on which Artefacts can be
deployed and executed. The Node can be accessed by other
Nodes or by components of the Application Layer. A Node is
composed of a Device and a System Software [4]. Devices are
physical computational resources where Artefacts are
deployed when the System Software represents a software
environment for types of components and objects.

Communication between the Nodes of the Technology Layer is

defined logically by the Communication Path and physically
by the Network.
The complete SCADA metamodel is the union of the three
layers. As shown below, new connections between the layers
have appeared. For the Passive Structure we observe that
Artefact of the Technical Layer realizes Data Object of the
Application Layer which, itself, realizes Organizational
Object of the Organizational layer.

Application Domain in a configuration of the Data Domain.

UML provides support for modelling the behaviour performed
by the Application Domain as Sequence Diagram.
Configuration of the Data Domain can be expressed as Preconditions of the Sequence Diagram and symbolized by the
execution of a test-method on the lifeline of the diagram.
III.

POLICY ENGINEERING

To engineer the SCADA policies, two steps are necessary. The

first one concerns the modelling of each SCADA component
according to the metamodel. The second one concerns the
detection and identification of the connections amongst each
composing artefact of the component models.
A. SCADA metamodel instance per component
This first step aims at providing the SCADA operators and
managers with a holistic and integrated view of the SCADA
architecture building blocks. To that end, the SCADA
metamodel is instantiated for each architecture component.
This step is achieved by shaping the component according to
the three abstractions typically advocated by the enterprise
architecture paradigm. This step allows discovering the
building artefacts of the components as well as the
connections amongst the components artefacts. This unified
representation of each component implies paramount
outcomes for the SCADA operator since it confers to the latter
a global functional insight of each component irrespective of
any implementation or vendors influence.

Figure 1: Three layers of SCADA system metamodel extracted from [2]

The Behaviour element connections show that the

Application Service uses the Organizational Policy to
determine the services which it proposes. In the same way, the
Technical Layer bases its Infrastructure Service upon the
Application Policy of the Application Layer. Concerning the
Active Structure connections, the Role concept determines,
along with the Application Component, the Interface provided
in the Application layer. The Interface of the Technical Layer
is also based on the components of the Application Layer.
C. Policy modelling
In the Organizational Layer, Organizational Policy can
be represented as an UML Use Case [11] where concepts of
Roles represent the Actors which have Responsibilities in
the Use Case, and the Collaboration concepts show the
connections between them. Concepts of Products, Value and
Organizational Service provide the Goal of the Use Case.
Pre- and Post-conditions model the context of the Use Case
and are symbolized in the metamodel by the Event concept
(pre-condition) and the Organizational Object (pre-/postcondition). In the Application Layer, Application Policy is
defined as the realization of Responsibilities by the

B. Policy semantic investigation

The unitary SCADA component models are used in the second
step to picture the global structure of the SCADA architecture
and of the connections, in terms of policies, amongst the
components of the architecture. Fig. 2 highlights the two types
of policies recovered in SCADA architecture:
1) Cognitive Policy
Cognitive Policies [12] are represented in blue in Fig. 2. They
represent policies which govern the behaviour of one artefact
of the component architecture. This policy specifies the rule
that the Responsible artefact needs to follow for the execution
of a defined activity in a specific execution context. This rule
is dictated by the artefact which exists in the same component
or in another one. The artefact which generates the policy is
the Master artefact and the one which execute it is the Slave
artefact. The Cognitive Policy morphology is articulated on
the following set of attributes (perceived by [13]): Master
artefact, Slave artefact, Master component, Slave component,
Behaving rule, Trigger item, Usage context, Priority extension
(Table I).
Table I. Cognitive policy attributes name and attributes ID
Attribute Name

Attributes ID

Master artefact
Salve artefact
Master component
Slave component
Behaving rule
Trigger item
Usage context
Priority extension

CP-Ma-art
CP-S-art
CP-Ma-Com
CP-S-Com
CP-Ru
CP-TI
CP-UC
CP-prior

The application schema of a CP, as presented in Fig. 2, obeys

the two following controls: (1) the communication path is
from a Master structural concept to a Slave behavioral concept
or (2) the communication path is from a Master behavioural
artefact to another Slave behavioural artefact.

Therefore, we describe the case study, we elaborate its

building blocks and we discuss the issues.
A. Description of the case study
Fig. 3 introduces the generic building blocks of a SCADA
architecture. This architecture receives input from distributed
probes (I/O from RTU and PLC) and SCADA adaptors,
provides outputs (using a View node visualization system) to
the incident team, and is refined according to new findings by
the Cyber Control Room (CCR). Our approach is illustrated by
three blocks selected according to [17]: the Detection
Correlation, the Online Cyber Analysis and the Visualization
System.

Figure 2. Two types of policy for SCADA. CP in blue and PP in red.

1) Permissive Policy
Permissive Policies are represented in red in Fig. 2. They
represent policies which govern the knowledge acquisition
rules from the Master to the Slave artefact [14]. This
knowledge acquisition traditionally takes the form of SCADA
states data accessed or provided in order to provide the
Responsible with the access (of in, out, in_out types [16])
to successive Cognitive Policies in case of occurring events.
The Permissive Policies morphology is articulated on the
following set of attributes [perceived by [15]): Master artefact,
Slave artefact, Master component, Slave component,
Permission rules, Pre-permission conditions, Master
permission cardinality, Slave permission cardinality, and
Cognitive constraints (Table II) - sustained by Cognitive
Policy states).
Table II. Permissive Policy attributes name and attributes ID
Attribute Name

Attribute ID

Master artefact
Slave artefact
Master component
Slave component
Permission rules
Permission conditions
Master permission cardinality
Slave permission cardinality
Cognitive constraints

PP-Ma-art
PP-S-art
PP-Ma-Com
PP-S-Com
PP-Ru
PP-Condi
PP-Ma-Car
PP-S-Car
PP-Co.con.

The application schema of a CP, as highlighted in Figure 2,

obeys the two following controls: (1) the communication path
is from a Master structural artefact to a Slave informational
artefact or (2) the communication path is from a Master
behavioural artefact to a Slave informational artefact.
IV. USE CASE
To illustrate CP and PP in SCADA architecture and their
visualization impact on the CI governance by the SCADA
operator, we exploit the SCADA model from the [15].

Figure 3. Building blocks of the SCADA system extracted from [15]

1) Detection correlation
Detection and cyber detection (DCD) [19] compose the
skeleton of the detection correlation mechanism which
supports the SCADA environment. Mainly three security
zones constitute the source of classified knowledge for this
DCD, namely, the corporate networks, the CI, and the field of
correlation that constitutes the input from distributed sensors.
The fields are architecture-based on traditional and specific
components from SCADA networks, to know: IDS,
Honeypots, Anti-Virus, and RTUs mirror. DCD performs a
correlation based on low validated alerts/events aggregation
(true-positive detections [20]) to higher validated alerts. As
highlighted in Fig. 3, cyber threat and security propagation
models support the correlation mechanism by allowing
analyzing and detecting suspicious signatures and suspicious
behaviours to issue a set of Detected Cyber Parameter (DCP).
2) Online cyber analysis
The Online Cyber Analysis (OCA) module [21] acts as the
heart of the SCADA schema, since it supports the definition of
the Refined Cyber Parameters provided to the Cyber
Simulator. OCA receives as input the DCP from the DCD on
the one hand, and the data from the analysis tools on the other
hand. The Cyber-physical Events are correlated amongst this
DCD and the Operative Level Analysis module (which we

have decided not to model in this paper since it semantically

acts as the OCA at an operative level).
3) Visualization system
The Visualization System is an extensive module pictured by a
hexagon symbol and acts as an ultimate SCADA Vector of
Communication for the support of the Incident Team [22].
As depicted in Fig. 3, the input of the Visualization System is

extracted from three fundamental building blocks: the Risk

Evaluation, the Automatic Countermeasures Selection and the
Service Simulator - concatenate data from OCA (and the
Operative Level Analysis) - by means of the Cyber Simulator.
The Visualization System supports the SCADA Operators and
Incident Manager, and extensions are possible towards any
ICT Operators.

Figure 4. SCADA architecture extracted from [15] focussed on detection correlation, online cyber analysis and visualization system

B. Building blocks modelling

Fig. 4 illustrates the holistic representation of the SCADA
components realized by the two steps of the policy
engineering schema. In this figure, we focus on three blocks
advocated by [17] cyber detection/correlation, online cyber
analysis and visualization system. Four additional blocks have
been partially incorporated to support the case description:
IDS, Honeypot, Operative Level Analysis, and the CI. In this
model, we have afterwards considered the CP and PP amongst
artefacts, respectively in blue and in red. Finally, these policies
have been reformulated according to the syntax policy
attributes from Table I and II, such as motivated by [2]. The
DCD is modeled on the left size of Fig. 4 and is associated
through two PPs with the IDS and the honeypots, respectively,
by the Detection Module and the Correlation Application. The
Alert Detection DB Slave Artifact at the application layer is

determined, in turn, by the Analytical Function Policy Master

artefact (illustrated in Table III using data from [2]) from the
Online Cyber Analysis module. The OCA module is the
central part of Fig. 4 and acts as a facilitator building block
between the DCD and the Visualization System. The
Confirmed Alert data object from its application layer acts as a
Slave artifact associated with the Visualization Policy. Hence,
this latter is logically of a permissive type and is bound to the
Visualization Policy/Service master artefact. Moreover, three
CP are associated to this artefact. The two first are related to
the IDS Application and Honeypot Application (which are of
Slave type read access allowed) and the latter is directed
towards the Visualization Policy/Service (which is of Master
type write access allowed). Finally, the last module of Fig. 4
is the Visualization System. This latter is sustained by a Slave
type CP towards the CI Operators, and by a master type PP
towards the CI Nodes.

Table III. CP instantiation for the Analytical function policy master artifact
Attribute ID

Attribute Name

CP-Ma-art
CP-S-art
CP-Ma-Com
CP-S-Com
CP-Ru

Organization policy/Service (pII2)

Alert/Detection Database (DB a.dd)
ONLINE CYBER ANALYSIS
CYBER DETECTION AND CORRELATION
Policy:: pII2, DB a.dd, if Act1On=3
than DB upgrade field DB a.add
correlation list else unchange
Probs flg activate (Act3On)
Any time, sector covered plant 2.
Probs priority (From Act1 to Act9)

CP-TI
CP-UC
CP-prior

V.

VI.

CONCLUSIONS

The huge amount of information managed by CI argues for the

support of cybernetic SCADA which behaves as a very
complex and sophisticated system. This later supports human
operators in monitoring and governing the system security by
elaborating the operational policies amongst the architecture
components. This paper explores the usage of EAM to
construct an integrated SCADA metamodel dedicated to these
components artefacts and structured according to (1) three
layers of abstraction, namely: Organization, Application, and
Technical layer and (2) two semantically consistent types of
policies: the Permissive Policy and the Cognitive Policy. The
results of the SCADA modelling and policy engineering
approach constitute, as illustrated by the case study, a global
analytical tool for the SCADA operators which rely on a
rational and unified component security based architecture to
continuously monitor and manipulate the policy attributes
acknowledging their impact on the whole CI system.
ACKNOWLEDGMENT
The research is funded by the CockpitCI project within the 7th
framework Programme of the European Union (topic SEC2011.2.5-1 Cyber-attacks against critical infrastructures).
REFERENCES

[2]

[4]
[5]

[6]

[7]

RELATED WORKS

The main related work consists in a framework for assessing

the maintainability using EAM proposed by [23] which
sustains flexible systems maintenance by supporting the
SCADA operators to assess the management of the
architecture. In line with EAM, [24] provides a solution to
develop and adapt the security analysis framework for the
architectural language and [25] refines the monitoring
paradigm using EAM. [26] tackles the visualization through
real-time SCADA and very large-scale integration (VLSI)
monitoring interface, such as underlined by [27]. Cyber
security policy has been reviewed by [3] who summarizes
cyber security problems and the possible existence of
vulnerabilities. This was correlated by [17, 19 and 20] who
strengthen new policy EAM based on modelling needs as well
as on bound exploitation perspectives.

[1]

[3]

Briesemeister, L., et al. Detection, correlation, and visualization of

attacks against critical infrastructure systems, 8th PST, 2010, Canada.
Blangenois, J., Guemkam, G., Feltus, C., Khadraoui, D., Organizational
Security Architecture for Critical Infrastructure, 8th International
Workshop on Frontiers in Availability, Reliability and Security, ARES
2013, Regensburg, Germany

[8]
[9]

[10]

[11]
[12]

[13]
[14]
[15]
[16]
[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]
[25]
[26]
[27]

Tan, S. Electric Power Automation Control System Based on SCADA

Protocols. Proceedings of the International Conference on Information
Engineering and Applications (IEA) 2012. Springer London, 2013.
Lankhorst, M. ArchiMate language primer, 2004.
Zachman, J. A. 2003. The Zachman Framework For Enterprise
Architecture: Primer for Enterprise Engineering and Manufacturing.
Engineering, no. July: 1-11.
Li, D., Serizawa, Y., Kiuchi, M. Concept Design for a Web Based
Supervisory Control and Data-Acquisition (SCADA) System, IEEE PES
Transmission and Distribution Conference, Yokohama, 2002, pp. 32-36.
Baskerville, R., Siponen, M. (2002). An information security meta-policy
for emergent organizations. Logistics of Information Management,
15(5/6) pp. 337-46.
Chang, D., Patra, A., Bagepalli, N., et al. Zone-Based Firewall Policy
Model for a Virtualized Data Center. U.S. Patent No 20,130,019,277.
Guemkam, G., Feltus, C., Bonhomme, C., Schmitt, P., Khadraoui, D.,
Guessoum, Z. Reputation based Dynamic Responsibility to Agent for
Critical Infrastructure, IEEE/WIC/ACM International Conference on
Intelligent Agent Technology, 22-27/8/2011, Lyon, France.
doi>10.1109/WI-IAT.2011.194
Bonhomme, C., Feltus, C., Khadraoui, D. Dynamic Responsibilities
Assignment in Critical Electronic Institutions - A Context-Aware
Solution for in Crisis Access Right Management, ARES 2011, Vienna,
Austria. DOI: 10.1109/ARES.2011.43
UML 2 ( http://www.uml.org/)
Xu, W., Zhang, X., and Jahn, G. Towards system integrity protection
with graph-based policy analysis. In : Data and Applications Security
XXIII. Springer Berlin Heidelberg, 2009. p. 65-80.
Doherty et al.. (2009). The information security policy unpacked: A
critical study of the content of university policies. IJIM 29(6)
Barth, A et al. (2009). Securing frame communication in browsers.
Communications of the ACM, 52(6), pp. 83-91.
Nicholson, A. et al. (2012) SCADA security in the light of CyberWarfare. Computers and Security , 31 (4), pp. 418-436.
Maj, S. P., Makasiranondh, W., & Veal, D. (2010). An Evaluation of
Firewall Configuration Methods. IJCSNS, 10(8), 1.
Briesemeister, L., Cheung, S., Lindqvist, U., & Valdes, A. (2010,
August). Detection, correlation, and visualization of attacks against
critical infrastructure systems. In Privacy Security and Trust (PST),
2010 Eighth Annual International Conference on (pp. 15-22). IEEE.
Rakocevic, V., et al. Computational intelligence in a real-time SCADA
system to monitor and control continuous casting of steel billets.
Systems, Man and Cybernetics, 1995. IEEE, Vol. 2.
Daryabar, F., et al., Towards secure model for SCADA systems,
International Conference on Cyber Security, Cyber Warfare and Digital
Forensic (CyberSec), 2012 60, 64, 2012.
Gill, R., Smith, J., & Clark, A. (2006, January). Experiences in passively
detecting session hijacking attacks in IEEE 802.11 networks. In
Proceedings of the 2006 Australasian workshops on Grid computing and
e-research-Volume 54 (pp. 221-230). Australian Computer Society, Inc.
Fink, G. A., et al. Visualizing cyber security: Usable workspaces.
Visualization for Cyber Security, 2009. VizSec 2009. 6th International
Workshop on. IEEE, 2009.
Kitamura, M., Kojima, T., & Nishida, S. (2006). SCADA Data
Visualization Using Equipment Graphs. IEEE Transactions on
Electronics, Information and Systems, p. 126, pp.788-796.
Lagerstrm, R. Analyzing system maintainability using enterprise
architecture models. Proceedings of the 2nd Workshop on Trends in
Enterprise Architecture Research (TEAR 2007).
Ekstedt, M., Sommestad, T., Enterprise architecture models for cyber
security analysis, PSCE '09. IEEE/PES, 1,6, 15-18 March 2009
Stanescu, A. M. et al. Supervisory control and data acquisition for
virtual enterprise, IJPR, Vol. 40, Iss. 15, 2002.
Qiu, B., et al. "Internet-based SCADA display system." Computer
Applications in Power, IEEE 15.1 (2002): pp. 14-19.
Constantinescu, C. Trends and challenges in VLSI circuit reliability.
Micro, IEEE 23.4 (2003): pp. 14-19.