Designing Security-enhanced Embedded Systems: Bridging Two Islands of Expertise $(function(){PrimeFaces.cw("Tooltip","widget_formSmash_items_resultList_41_j_idt799_0_j_idt801",{id:"formSmash:items:resultList:41:j_idt799:0:j_idt801",widgetVar:"widget_formSmash_items_resultList_41_j_idt799_0_j_idt801",showEffect:"fade",hideEffect:"fade",target:"formSmash:items:resultList:41:j_idt799:0:fullText"});});

Designing Security-enhanced Embedded Systems: Bridging Two Islands of Expertise $(function(){PrimeFaces.cw("Tooltip","widget_formSmash_items_resultList_41_j_idt799_0_j_idt801",{id:"formSmash:items:resultList:41:j_idt799:0:j_idt801",widgetVar:"widget_formSmash_items_resultList_41_j_idt799_0_j_idt801",showEffect:"fade",hideEffect:"fade",target:"formSmash:items:resultList:41:j_idt799:0:fullText"});});
Linköping Studies in Science and Technology
Licentiate Thesis No. 1624
Designing Security-enhanced
Embedded Systems: Bridging Two
Islands of Expertise
by
Maria Vasilevskaya
Department of Computer and Information Science
Linköping University
SE-581 83 Linköping, Sweden
Linköping 2013
This is a Swedish Licentiate’s Thesis
Swedish postgraduate education leads to a Doctor’s degree and/or a Licentiate’s degree.
A Doctor’s degree comprises 240 ECTS credits (4 year of full-time studies).
A Licentiate’s degree comprises 120 ECTS credits.
c 2013 Maria Vasilevskaya
Copyright ISBN 978-91-7519-486-8
ISSN 0280–7971
Printed by LiU Tryck 2013
URL: http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-98213
Designing Security-enhanced Embedded
Systems: Bridging Two Islands of Expertise
by
Maria Vasilevskaya
October 2013
ISBN 978-91-7519-486-8
Linköping Studies in Science and Technology
Licentiate Thesis No. 1624
ISSN 0280–7971
LiU–Tek–Lic–2013:58
ABSTRACT
The increasing prevalence of embedded devices and a boost in sophisticated attacks
against them make embedded system security an intricate and pressing issue. New approaches to support the development of security-enhanced systems need to be explored.
We realise that efficient transfer of knowledge from security experts to embedded system
engineers is vitally important, but hardly achievable in current practice. This thesis proposes a Security-Enhanced Embedded system Design (SEED) approach, which is a set of
concepts, methods, and tools that together aim at addressing this challenge of bridging
the gap between the two areas of expertise.
First, we introduce the concept of a Domain-Specific Security Model (DSSM) as a suitable
abstraction to capture the knowledge of security experts in a way that this knowledge
can be later reused by embedded system engineers. Each DSSM characterises common
security issues of a specific application domain in a form of security properties, which are
further linked to a range of solutions.
As a next step, we complement a DSSM with the concept of a Performance Evaluation
Record (PER) to account for the resource-constrained nature of embedded systems. Each
PER characterises the resource overhead created by a security solution, a provided level
of security, and the evaluation technique applied.
Finally, we define a process that assists an embedded system engineer in selecting a
relevant set of security solutions. The process couples together (i) the use of the security
knowledge accumulated in DSSMs and PERs, (ii) the identification of security issues in
a system design, and (iii) the analysis of resource constraints of a system and available
security solutions. The approach is supported by a set of tools that automate its certain
steps.
We use a case study from a smart metering domain to demonstrate how the SEED
approach can be applied. We show that our approach adequately supports security experts
in description of knowledge about security solutions in the form of formalised ontologies
and embedded system engineers in integration of an appropriate set of security solutions
based on that knowledge.
This work has been supported by the Swedish National Graduate School of Computer
Science (CUGS) and the EU FP7 SecFutur Project.
Department of Computer and Information Science
Linköping University
SE-581 83 Linköping, Sweden
Acknowledgement
I would like to express my gratitude to my supervisor Simin Nadjm-Tehrani
for the support that she provided to me over the recent years. Her tireless
assistance and guidance have helped me to learn and progress with my
research.
I gratefully acknowledge Linda Ariani Gunawan, Peter Herrmann, David
Broman, and Kristian Sandahl with whom I had many fruitful discussions
regarding my research and teaching. Special thanks go to David Broman
for his unlimited support and inspiration as my mentor. Thanks to my
secondary advisor Nahid Shahmehri for her feedback given at our meetings
and when reading some parts of this thesis.
I wholeheartedly thank all current and former members of RTSLab for
their friendship, support, and all the valuable comments during numerous
RTSLab meetings. My appreciation extends also to members of other divisions of IDA with whom I happened to interact regarding my research and
teaching.
I would like to thank all administrative personnel who make our working
environment very pleasant. Special thanks go to Anne Moe, Eva Pelayo
Danils, and Åsa Kärrman. It would have been much more difficult to work
effectively without their professional support and patience.
Last but not least, I am thankful to my family for their support throughout these years. The encouragement and valuable assistance provided by
Anatoly and Dmitry helped a lot in preparation of this thesis. I am sincerely thankful to my parents Elena and Viktor as well as to others for their
care during these years.
Undoubtedly, there were many other people who contributed to my work
with their support, advice or rewarding moments spent together. Unfortunately, it is not feasible to name everyone. Therefore, I anonymously thank
all of you who did not find their name here but has contributed with their
effort or time at any point of this journey.
Maria Vasilevskaya
Linköping, Sweden
October, 2013
v
Contents
1 Introduction
1.1 Motivation . . . . .
1.2 Problem Formulation
1.3 Contributions . . . .
1.4 List of Publications .
1.5 Outline . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
3
3
4
5
2 Background and Case Study
2.1 Embedded Systems Engineering . . .
2.2 Modelware Zoo . . . . . . . . . . . .
2.2.1 Main Concepts . . . . . . . .
2.2.2 UML . . . . . . . . . . . . . .
2.2.3 MARTE . . . . . . . . . . . .
2.2.4 SPACE . . . . . . . . . . . .
2.2.5 Tools . . . . . . . . . . . . .
2.3 Ontology Technologies . . . . . . . .
2.4 Case Study: Metering Infrastructure
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
10
10
15
17
18
21
22
24
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 SEED: Bird’s Eye View
3.1 Introduction to SEED . . . . . . . . . . . . . . . . . . . . . .
3.2 The SEED Foundation . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Creation of a System Model . . . . . . . . . . . . . . .
3.2.2 Capturing the Domain-specific Security Knowledge . .
3.2.3 Development of a Security-enhanced Embedded System
27
27
28
28
29
30
4 Capturing of the Domain-specific Security Knowledge
4.1 Developed Concepts and Artefacts . . . . . . . . . . . .
4.1.1 Domain-specific Security Model . . . . . . . . . .
4.1.2 Performance Evaluation Record . . . . . . . . . .
4.2 Capturing Security Knowledge . . . . . . . . . . . . . .
33
33
34
40
47
vii
.
.
.
.
.
.
.
.
.
.
.
.
viii
CONTENTS
5 Application of the Domain-specific Security Knowledge
5.1 System Model . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1 Modelling a Functional Behaviour of a System . .
5.1.2 Modelling an Execution Platform . . . . . . . . . .
5.2 Association with DSSMs . . . . . . . . . . . . . . . . . . .
5.3 Asset Elicitation and Search for Security Properties . . .
5.3.1 Asset Elicitation on a Functional Model . . . . . .
5.3.2 Search for Security Properties . . . . . . . . . . . .
5.3.3 Asset Elicitation Utilising a Platform Model . . . .
5.4 Search for Concrete SBBs . . . . . . . . . . . . . . . . . .
5.5 Compatibility-based Selection of Concrete SBBs . . . . .
5.5.1 Introduction into the Compatibility Analysis . . .
5.5.2 Ontologies for Compatibility Analysis . . . . . . .
5.5.3 Model-based Compatibility Analysis . . . . . . . .
5.5.4 Scalability and Performance . . . . . . . . . . . . .
5.6 Extended Form of the Process . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
51
52
53
55
56
57
57
62
63
66
68
69
70
74
77
79
6 Related Work
6.1 Composing a System from Reusable Blocks . .
6.1.1 Component-based Development . . . . .
6.1.2 Aspect-oriented Development . . . . . .
6.2 Security-enhanced System Design . . . . . . . .
6.2.1 General Methods to Deal with Security
6.2.2 Methods for Embedded Systems . . . .
6.2.3 Selection of Security Measures . . . . .
6.2.4 Risk Analysis . . . . . . . . . . . . . . .
6.3 Marrying Ontologies and Models . . . . . . . .
6.4 Performance Analysis at the Design Phase . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
81
81
81
83
84
85
87
88
89
89
90
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7 Conclusions and Future Work
93
7.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
List of Figures
2.1
2.2
2.3
Life cycle process models . . . . . . . . . . . . . . . . . . . .
Simplified design flow [1] . . . . . . . . . . . . . . . . . . . . .
Models, meta-models, and meta-meta-models – the layered
organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 Model transformation: concepts and their relations . . . . . .
2.5 Relations between domains and languages, adapted from [2] .
2.6 Example of the stereotype definition and usage . . . . . . . .
2.7 Structure of the MARTE profile . . . . . . . . . . . . . . . .
2.8 Structure of the MARTE analysis packages . . . . . . . . . .
2.9 SPACE model-based engineering method, adapted from [3] .
2.10 Model of a simple e-consultation application in SPACE . . .
2.11 Smart metering infrastructure (an overview) . . . . . . . . . .
11
12
14
16
17
18
19
20
24
3.1
3.2
Generic process – the SEED foundation . . . . . . . . . . . .
Fragments of simplified design flows . . . . . . . . . . . . . .
28
31
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
DSSM concept and related artefacts . . . . . . . . . . . . . .
Core security ontology fragment . . . . . . . . . . . . . . . . .
UML representation of the core security ontology . . . . . . .
Fragment of the metering DSSM . . . . . . . . . . . . . . . .
Enriched security ontology . . . . . . . . . . . . . . . . . . . .
PER concept and related artefacts . . . . . . . . . . . . . . .
Core evaluation ontology . . . . . . . . . . . . . . . . . . . . .
GEM UML profile to capture performance evaluation results
The refinement of the GEM profile for the security domain .
Fragment of the security evaluation record for the DES RBB
Enriched evaluation ontology . . . . . . . . . . . . . . . . . .
The process for creation of DSSMs . . . . . . . . . . . . . . .
Registration of concrete SBBs tool (the user interface) . . . .
34
35
37
38
39
41
41
43
46
46
47
48
50
5.1
5.2
5.3
5.4
Application of the domain-specific security knowledge . . . .
Functional system model of the measurement transfer scenario
Detailed behaviour of the transfer handler block . . . . . . .
Platform model for a TSMC device . . . . . . . . . . . . . . .
51
53
54
55
ix
9
9
x
LIST OF FIGURES
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
5.13
5.14
5.15
5.16
Association of the selected DSSM with the system elements
(the user interface) . . . . . . . . . . . . . . . . . . . . . . . .
Rules of the asset identification technique . . . . . . . . . . .
Illustration of the rules . . . . . . . . . . . . . . . . . . . . . .
Functions to traverse a functional system model . . . . . . . .
Asset analyser tool (the user interface) . . . . . . . . . . . . .
Asset elicitation technique utilising a platform model . . . . .
Adapted model protecting the transfer of measurement data .
Concrete SBB searcher tool (the user interface) . . . . . . . .
Ontologies for compatibility analysis . . . . . . . . . . . . . .
Classification levels for the developed ontologies (excerpts) . .
Model-based compatibility analysis tools (the user interfaces)
Extended form of the proposed process . . . . . . . . . . . . .
56
59
60
61
62
63
68
69
71
72
77
79
List of Tables
4.1
Correspondence between our GEM and (MARTE) GQAM . .
45
5.1
5.2
5.3
5.4
Results of eliciting assets from the functional model . .
Association of the assets with the platform components
Threats and violated security goals . . . . . . . . . . . .
Scalability and performance estimations . . . . . . . . .
61
65
65
78
xi
.
.
.
.
.
.
.
.
.
.
.
.
Chapter 1
Introduction
The ubiquitous presence of networked embedded devices is no longer questioned. Large computing infrastructures that bring automation in our daily
lives exist due to support of such devices interconnected through networks.
Being a part of such infrastructures, embedded devices carry and process
sensitive information. Thus, both their exposure to open networks and their
critical role in storing, processing, and transmission of information makes
embedded devices a target of sophisticated attacks. The interest of attackers is stimulated by the fact that modern embedded systems are often easily
accessible (e.g. deployed in a hostile environment) and the consequences of
compromising such devices can be very large. If an attacker hacks a device
of one type, the attack can be quickly replicated to all other devices of the
same type possibly in thousands or millions. If attackers take control over
one of the devices of a large network, they can gain access to other devices
of the network. For example, a computer scientist at Colombia University,
Ang Cui, has developed a technique that allows taking complete control of
a Cisco IP phone, that in turn allows affecting other parts of a connected
system (other phones in a network, computer, printers, etc.) [4]. These
facts impose high requirements on security standards for embedded systems
that are often neglected. To emphasise the point, McClure estimates [5]
that there are already 10 billion embedded devices in operation that were
designed without much thought about security.
Thus, it goes without saying that security issues should be considered
during embedded system development since insufficient security can create
a substantial risk for society and significant lost of profits for embedded
system producers, owners, and end users.
1.1
Motivation
Although security is an essential aspect of networked embedded systems,
it is still approached as an add-on late in the development process. This
1
2
CHAPTER 1. INTRODUCTION
can hardly be effective due to the complexity of embedded systems, their
resource-constrained nature, and non-functional requirements. For instance,
Ravi et al. [6] discuss the main consequences of incorporating security solutions into embedded systems at the late development phases. Resources
planned during the initial development phase do not account for security
functions. These insufficient resource requirements dramatically limit the
number of security solutions available for a system engineer or even put this
number to zero. The authors identify a set of bottlenecks that system designers consequently have to deal with. These include, but not limited to,
the energy consumption overheads (the battery gap) and the computational
demands (the processing gap). Ravi et al. argue for a shift to an appropriate
design methodology to address these challenges.
There is a number of factors that make attacks on embedded systems
successful. An unthoughtful system design is one of the sources of potential
breaches. Vulnerabilities introduced during the implementation phase are
another one. Human factors such as an intentional and unintentional misuse
of system components are major problems during the usage phase. While
all factors are significant, this thesis focuses on resolving security issues at
the design phase of the system development. The underlying reason for
such a focus is that the consequences of an unthoughtful design influence
all later phases of the system life cycle. At the same time, integration of
security mechanisms already at the design phase allows early exploration of
performance, power consumption, cost and other trade-offs. This motivates
adopting the principles of model-based engineering [7] as a vehicle to bring
security consideration to a design phase.
A mere focus on the design phase is not enough to efficiently tackle security issues. The challenge is amplified by the diversity and complexity of
both security solutions and embedded systems as such. Embedded systems
design requires in-depth understanding of an application domain, usage scenarios, and deployment environment. Security threats, in turn, vary from
application to application and are more or less prevalent in an application
domain. Due to these concerns, Kocher et al. [8] stress the need of system
engineers (who are not necessarily experts in security) to understand both
required level of security assurance and the overhead caused by injecting
security solutions into a system design.
Security mechanisms should be developed and thoroughly studied by
security experts, whereas the resulting knowledge should be available for
embedded system engineers. Last but not the least, a security solution for
embedded systems should be specific for a particular application domain
in order to provide the required efficiency at the cost of acceptable performance. This brings us to two additional principles that we propose in this
thesis to improve practices of security-enhanced embedded system development, namely the separation of roles (i.e. an embedded system engineer and
security expert) and domain specialisation (i.e. application-driven security)
principles.
1.2. PROBLEM FORMULATION
1.2
3
Problem Formulation
The objective of this thesis is to provide concepts and tools for addressing
security issues of embedded systems already at the design phase. We aim to
reach this goal by defining an approach which targets two categories of professionals. With the help of the developed approach, security experts should
have an opportunity to describe developed security solutions in a reusable
manner. This, in turn, should enable embedded system engineers to select a
suitable set of security solutions based on the analysis of both system’s security needs and system resource constraints. The approach should explore
the following principles:
• Model-orientation: which allows dealing with security concerns already at the early development phase.
• Domain specialisation: which increases the quality and efficiency of
eventual solutions by narrowing down the focus to a specific domain.
• Separation of responsibilities and concerns: which promotes separation
of security expert and embedded system engineer roles.
Realising the basic principles stated above, we contribute to tackling the
challenge of adequate support for a security expert and an embedded system
engineer by answering the following questions:
• What abstractions and concepts are suitable for a security expert to
assist in creating a useful description of a security mechanism?
• What technologies and processes can be employed to assist a security
expert in capturing this knowledge?
• What are methods and tools that should equip an embedded system
engineer to enable the use of the provided security knowledge to efficiently select a set of security solutions for their integration into a
system design?
1.3
Contributions
The main contribution of this work is the definition of a Security-Enhanced
Embedded system Design (SEED) approach. More specifically, our contributions consists of:
• a proposal of two concepts to represent the domain-specific security
knowledge that encapsulates information about reusable security solutions, namely Domain-Specific Security Model (DSSM) and Performance Evaluation Record (PER),
• a process for a security expert to capture the domain-specific security
knowledge,
4
CHAPTER 1. INTRODUCTION
• a process for an embedded system engineer to reuse the captured
knowledge at the system design phase,
• development of a MagicDraw [9] plug-in to support the processes described above.
The MagicDraw plug-in combines both modelling and ontology technologies to implement the DSSM and PER concepts.
The process defined for an embedded system engineer, in turn, rests on
two other contributions of this thesis:
• a method called asset elicitation technique that analyses a system design to elicit a system’s security needs;
• a method called model-based compatibility analysis that matches resource constraints of an embedded system under development and alternative security solutions.
1.4
List of Publications
The work presented in this thesis is based on the following publications:
• S. Nadjm-Tehrani and M. Vasilevskaya, Towards a Security Domain
Model for Embedded Systems, in The 13th IEEE International Symposium on High Assurance Systems Engineering (HASE), poster session,
IEEE, November 2011
• M. Vasilevskaya, L. A. Gunawan, S. Nadjm-Tehrani, and P. Herrmann,
Security Asset Elicitation for Collaborative Models, in Model-Driven
Security Workshop (MDSec) in conjunction with MoDELS, ACM,
Innsbruck, Austria, Octorber 2012
• M. Vasilevskaya, L. A. Gunawan, S. Nadjm-Tehrani, and P. Herrmann,
Integrating security mechanisms into embedded systems by domainspecific modelling, Journal of Security and Communication Networks,
Wiley, June 2013.
• M. Vasilevskaya and S. Nadjm-Tehrani. Support for Cross-domain
Composition of Embedded Systems Using MARTE Models. Submitted for review.
Some content of this thesis have been published as parts of deliverables
of the EU FP7 SecFutur project [10]:
• Deliverable 3.1: Abstract model for embedded systems. Edited by
Simin Nadjm-Tehrani and Maria Vasilevskaya, 2011.
• Deliverable 4.1: SecFutur Development Process V1 and Modelling
Framework. Edited by Antonio Maña, Jose F.Ruiz, and Rajesh Harjani, 2011.
1.5. OUTLINE
5
• Deliverable 4.2: SecFutur development process V2 and code development and tool-suite V1. Edited by Jose F. Ruiz, Antonio Maña, and
Marcos Arjona, 2012.
• Deliverable 4.3: SecFutur code development and tool-suite V2. Edited
by Maria Vasilevskaya and Simin Nadjm-Tehrani, 2013
The following papers were authored or co-authored during the period of
the presented work. The papers are not included in this thesis.
• B. Yatsalo, S. Gritsyuk, O. A. Mirzeabasov, and M. Vasilevskaya,
Uncertainty Treatment within Multicriteria Decision Analysis with the
Use of Acceptability Concept, Journal of Large-scale Systems Control,
RAS, 2011.
• M. Vasilevskaya, D. Broman, and K. Sandahl, An Assessment Model
for Large Project Courses, ACM Technical Symposium on Computer
Science Education, SIGCSE, 2014.
1.5
Outline
The rest of this thesis is organised as follows. We provide the necessary background to our work in Chapter 2. Chapter 3 explains the idea and structure
of SEED in general terms that are detailed in the following chapters. In particular, Chapter 4 defines the process for capturing of the domain-specific
security knowledge. Chapter 5 explains methods and tools to use the captured knowledge for integration of protection mechanisms into an embedded
system design. Thereafter, we provide a summary of some related work in
Chapter 6. Finally, Chapter 7 concludes this thesis and gives some pointers
for future work.
Chapter 2
Background and Case
Study
This chapter provides the necessary background needed in the context of
this work. Section 2.1 gives an overview of the basic process models for
embedded system engineering. Then, the basic concepts, tools, and methods
of model-based engineering are introduced in Section 2.2 followed by a brief
introduction to ontology technologies given in Section 2.3. We conclude
this chapter by presenting a case study from the smart metering domain
described in Section 2.4 that is used as a running example throughout this
thesis to illustrate the introduced concepts, methods, and processes.
2.1
Embedded Systems Engineering
Development of embedded systems is a complex task. Therefore, a set of
process models exist that support engineers in tackling this complexity. In a
broad sense, a process defines a set of activities, their input/output artefacts,
roles with responsibilities, tools, time frames, and costs. In our work, we
are mainly concerned about activities and input/output artefacts.
At the level of main activities, life cycle models (i.e. process models)
for development of embedded systems are very similar to life cycle models proposed for general software engineering. In particular, there are five
basic steps that span across the whole life cycle of a system: requirements
definition, system specification, functional design, architectural design, and
prototyping/implementation [11]. The first step intends to capture the customer’s wish in terms of what a system shall do. The following step, i.e.
system specification, refines the customer description in a more concise and
precise form. The next two steps go deeper and turn specifications into a
set of functional blocks that are later mapped into architectural elements.
These elements are combinations of hardware and software resources. Fi-
7
8
CHAPTER 2. BACKGROUND AND CASE STUDY
nally, a system is implemented that results in a prototype. The extended
life cycle models instrument these basic five steps with extra activities, such
as testing, validation, verification, and maintenance. In the following, we
outline three widely known life cycle models, namely waterfall, spiral, and
V models.
• The waterfall [12] model depicted in Figure 2.1(a) represents a development cycle as a sequence of the steps above. According to this
model, an engineer should proceed to the next step when the current
phase is completed. Additionally, there is a feedback loop (depicted by
the backward arrows) to the previous phase that ensures conformance
of artefacts created on the current phase to the artefacts produced
on the previous step. The presence of this feedback loop differs the
waterfall model from a simple sequential process.
• The V model [13] depicted in Figure 2.1(b) is similar to the waterfall model, but it emphasises the verification and validation activities.
A system development follows the top-down approach (the left-hand
side), while the verification and validation activities go from the bottom to the up (the right-hand side). Thus, the implemented system
is verified against each produced artefact, namely implementation, architectural design, functional design, specification, and requirements.
Unit and integration testing verifies a system against the artefacts created at the prototyping/implementation phase, e.g. program design.
• The spiral model [14] depicted in Figure 2.1(c) promotes an iterative
style for development of a system. Thus, the main difference of the
spiral model and the above mentioned models is that it emphasises
iterative emergence of several versions of the same system. First, a
very restrictive version of a system is developed to understand if the
requirements are correctly and adequately formulated. Then, the system evolves into more complex and complete versions, e.g. prototype,
initial design, and enhanced design. The corresponding artefacts, e.g.
requirement specifications, functional and architectural designs, implementation, also evolve. The radius of the spiral can reflect the amount
of time spent on each cycle.
Different variations, modifications, and combinations of the presented
process models exist. For example, Douglass [15] proposes a so called harmony development process (see Figure 2.1(d)) where the V and spiral models
are combined.
The embedded systems community also poses a process for embedded
system development that differentiates two distinct levels. They are system
and lower levels. In this approach, verification, validation, testing, estimation, and analysis steps are tightly woven into a process. The system
level concerns defining a system model and selecting a suitable architecture.
2.1. EMBEDDED SYSTEMS ENGINEERING
(a) Waterfall model
(c) Spiral model
9
(b) V model
(d) Harmony model
Figure 2.1: Life cycle process models
These artefacts are further evolved into different parts of code (RTOS and
application code) and elements of hardware at the lower level.
Figure 2.2: Simplified design flow [1]
The last model for the life cycle development that we visualise in this
section is the simplified design flow presented by Marwedel [1]. Figure 2.2
depicts this process. This model does not radically differ from the models presented above. The design starts from some application knowledge
10
CHAPTER 2. BACKGROUND AND CASE STUDY
that is transformed into specification, and hardware/software components.
However, Marwedel explicitly brings the design repository into the process.
According to Marwedel, this repository serves to keep track of design models
evolution. However, we envisage wider use of this component, namely as a
point to extend and refine the initial design. This idea is further exploited
and evolved in our work.
2.2
Modelware Zoo
In this section, we briefly introduce the reader to the area of model-based
engineering. First, we cover main concepts of the modelling theory. Thereafter, we describe two modelling languages used in our work, namely UML
and MARTE, and an employed system modelling approach called SPACE
together with its modelling language. We conclude this section outlining
tools that support principles of model-based engineering.
2.2.1
Main Concepts
We begin with introducing terms of models, meta-models, transformation,
and basics of the language engineering, followed by brief discussions on topics
such as domain-specific compared to general modelling, and model-based
compared to model-driven engineering.
Models and Meta-models
In general, models allow to raise the abstraction level to deal with growing
complexity of artefacts (e.g. embedded system design) [16]. Abstraction
improves understanding of complex artefacts and allows their efficient analysis through hiding some irrelevant information. In other words, a model
represents a real system highlighting its properties of interest.
Any model conforms to some meta-model that defines its properties.
Thus, a meta-model defines a modelling language used to create a model of a
certain type for a system. Depending on the type of properties that a model
should describe an employed meta-model will change. Consequently, a metamodel conforms to some language used to define properties of this metamodel, i.e. a meta-meta-model. In theory, an infinite hierarchy of model–
meta-model relations can be specified. However, in practice, meta-metamodel is abstract and general enough to define itself wrapping the layered
organisation of modelware (see the left side of Figure 2.3). Such organisation
is sometimes referred as the four-layered architecture (M0-M3) [17] or 3+1
organisation [18].
The right side of Figure 2.3 depicts a classical example that demonstrates
an instantiation of the layered organisation introduced above. A real-world
object (car) is shown at level M0. A model of the car is shown at level M1.
This model describes a car as a Car class with one “colour” attribute. The
2.2. MODELWARE ZOO
11
meta-model located at M2 explains how to understand this model, namely
what elements are classes and what elements are attributes. Finally, level
M3 defines concepts used at level M2. Thus, both Attribute and Class are
represented as classes at M3.
Figure 2.3: Models, meta-models, and meta-meta-models – the layered organisation
The Object Management Group (OMG) [19] implements the M3 level as
the Meta-Object Facilities (MOF) standard [20]. MOF is used to define the
Unified Modelling Language (UML) [17] located at the M2 level.
Transformation
Model transformation is a technique that allows defining a mapping between different models, i.e. source and target models, that are different
representations of the same system. Figure 2.4 depicts a classical scheme
that explains concepts of model transformation and their relations. Any
model transformation is applied to source and target models, but the actual
transformation is defined at the meta-model level, i.e. a model transformation definition refers to elements of the meta-models of the source and target
models. Thus, model transformation receives input and output models that
conform to their respective source and target meta-models. At the same
time, a model transformation definition is a model by itself that conforms
to some meta-model, i.e. to a transformation language [18, 7].
Basically, transformation languages can be classified as declarative, imperative, and hybrid. Declarative languages require an engineer to specify
relations between source and target meta-models, e.g. in terms of functions.
In contrast, one needs to specify such details as execution order (sequence
of steps) when imperative languages are used. A hybrid type of languages
is an intermediate category that mixes constructs and principles from both
12
CHAPTER 2. BACKGROUND AND CASE STUDY
Figure 2.4: Model transformation: concepts and their relations
declarative and imperative languages.
Depending on the nature of target and source meta-models, transformation languages can be classified as model-to-model (M2M) and model-to-text
(M2T) transformations [21]. Naturally, the former type of transformations
input a model conforming to a certain meta-model (e.g. UML) and produce another model that conforms to a different meta-model (e.g. EntityRelation Diagram), while the latter type of transformation results in some
textual representation (e.g. Java code). Recently, a third type of transformation called text-to-model (T2M) has been introduced. Additionally, one
can classify a transformation as endogenous or exogenous. A transformation
is considered to be endogenous if source and target models conform to the
same meta-model. In contrast, an exogenous transformation is used when
source and target models conform to different meta-models.
Model transformation is a powerful concept that is used to automate different tasks of model-based engineering [22]. For example, code generation
is a special type of model transformation where the target model is code.
Model composition, model refactoring, verification, and reverse engineering
are other examples of scenarios where model transformation can be applied.
Abstract Syntax, Concrete Syntax, and Semantics
To enable sophisticated operations with models (e.g. transformation), they
must have a well-defined structure. Therefore, techniques for systematic
definition of meta-models should be used. The research area that concerns
proper definition of complex modelling languages is sometimes referred to
as modelling language engineering [23].
The main elements that define a language are its syntax (i.e. a language’s
notation) and semantics (i.e. a language’s meaning). There are two types
2.2. MODELWARE ZOO
13
of syntax that serve for different purposes, namely an abstract syntax and a
concrete syntax [24]. An abstract syntax defines all valid models of modelling
languages. For example, an abstract syntax defines what are concepts of a
modelling language (e.g. classes and their attributes) and what are their
valid relations (e.g. associations). Meta-modelling (see Figure 2.3) is a
technique for defining an abstract syntax. A concrete syntax defines how an
abstract syntax appears for an engineer (i.e. for its users). Thus, a concrete
syntax deals with representation of a modelling language. A concrete syntax
can be represented in textual or visual (e.g. boxes and arrows) notations.
Semantics defines the meaning of a language notation (i.e. syntax).
In general, there are two steps to define semantics for a language. First, a
semantic domain should be defined that provides a meaning for each expression. This meaning must be an element of another well-understood domain,
e.g. real numbers. Afterwards, a semantic mapping should be created to
bound elements of an abstract syntax to a defined semantic domain.
Domain-specific vs. General-purpose Modelling
Model-based engineering methods distinguish two big categories of modelling languages, namely Domain-Specific Modelling Languages (DSMLs)
and General-Purpose Modelling Languages (GPMLs). DSMLs are languages
that are designed for a certain domain [25]. Such languages are usually designed by a group of experts to be used in a specific context or company
to facilitate a particular task (e.g. the task of describing things in that domain). In other words, a DSML allows the user to specify a solution using
terms of a problem domain that are built in this DSML. Besides, DSMLs
are intended to support a better reuse of functionality recurring in a set of
modelling tasks. Thus, a DSML is optimised for a certain class of problems
within a domain. In contrast, a GPML does not target a specific domain,
but rather is intended to be applied in any domain.
Since expressiveness of DSMLs is bound to a particular domain, they
can be used only for a predefined set of problems. In contrast, GPMLs
are advertised to be suitable for a wide range of modelling tasks. However,
DSMLs bring higher productivity and conciseness in modelling since an engineer operates with a limited set of concepts that are familiar and intuitive
for a considered domain.
There are a lot of discussions on the topic of “DSML vs. GPML”. Both
classes of languages are suitable for different purposes and scenarios. Therefore, it is rational to be aware of their advantages and disadvantages through
their systematic comparison. Boundaries between domain-specialisation are
not obvious: any language is more or less domain-specific [2]. In this section, we outline some characteristics that are typical for a pure DSML and
GPML.
A pure DSML can be characterised by the following set of peculiarities:
it is designed for a small and well-defined domain; it has a relatively small
size with a limited set of user-defined abstractions; its development takes
14
CHAPTER 2. BACKGROUND AND CASE STUDY
months to years; it is designed by a few domain experts; its user community
is a small and accessible group. In contrast, a real GPML is designed for a
large and complex domain; it has a large language size with a sophisticated
set of general abstractions; its development usually spans over years and
decades; it is designed by gurus and large communities.
To conclude our discussions about DSMLs and GPMLs, Figure 2.5 illustrates views on relations between domains and languages presented by
Voelter [2]. Figure 2.5(a) shows the relations between domains as a hierarchical structure where a domain of a pure GPML is the lowest level. An
example of a languages order based on their domain-specificity is depicted in
Figure 2.5(b). We believe that these figures give a good intuition on boundaries between domain-specific and general-purpose modelling languages.
(a) Domain hierarchy
(b) Language order
Figure 2.5: Relations between domains and languages, adapted from [2]
Model-based vs. Model-driven Engineering
A set of development paradigms that rely on models as a key artefact have
recently emerged. They are Model-Based Engineering (MBE), Model-Driven
Development (MDD), Model-Driven Engineering (MDE), and Model-Driven
Architecture (MDA). However, these techniques can be distinguished based
on the role of models in the proposed processes.
To begin with, we briefly explain the difference between “model-driven”
and “model-based” prefixes. Intuitively, the latter is a softer version of the
former: the former prefix says that models drive the process, while in the
latter case models play an important role, but are not key artefacts. In
case of “model-driven”, it is often expected that a model is used to generate
the final implementation. In contrast, for the “model-based” techniques, a
model can be used for various kinds of analysis and even test generation,
but the actual implementation can be done by developers. Thus, MDE can
be considered as a subset of MBE [7]. Similarly, MDD is a subset of MDE,
since the letter “D” stands for “Development” that is one type of activity
in system engineering. Finally, MDA is a realisation of MDD proposed by
Open Management Group (OMG) [19] that is inherently based on OMG
standards.
2.2. MODELWARE ZOO
2.2.2
15
UML
Unified Modelling Language (UML) is a widely accepted general purpose
modelling language. Modelling concepts defined by UML are organised in
different types of diagrams. The current version of UML (v2.4.1) [17] differentiates 14 types of diagrams. These diagrams are classified in two categories: those that are intended to model structural and behaviour parts
of a system. Each type of diagram uses different modelling concepts that
together allow describing diverse aspects of a system.
There are seven types of structural diagrams. A class diagram shows
system’s classes, their attributes, their operations, and the relations among
classes. A component diagram shows the components of a system and their
relations. A composite structure diagram shows the internal structure of
a class and the interaction (collaboration) that this structure enables. A
deployment diagram can be used to show the hardware/software parts of
a system and artefacts deployed on this execution environment. An object diagram shows instantiation of the system classes. A package diagram
shows the logical organisation of a system as a set of packages and their dependencies. Finally, a profile diagram encapsulates custom domain-specific
extensions of the standard UML constructs (see below).
Behaviour of a system can be described using seven types of diagrams.
An activity diagram can be used to show a workflow (both control and data)
of a system. A state machine diagram shows the system’s states and their
transitions. A use case diagram is used to give a high-level description of a
system in terms of actors, their goals, and dependencies between actors and
goals. Communication and sequence diagrams are used to describe the interaction and communication between objects as sequences of messages using
different syntaxes. The last two types of diagrams are interaction overview
and timing diagrams that enable creation of an overview of a system and
specifying some timing constraints of operations respectively.
This rich set of diagrams allows capturing different aspects of a system.
All together, they have a complex and diverse syntax, but rather weak semantics. As a result, UML diagrams are used for modelling tasks in many
different domains, but these models are not comparable due to the absence
of a commonly agreed semantic domain. Therefore, usually a small subset
of UML (i.e. some syntactical constructs such as a subset of UML class diagrams) is used and is further supported by a user-defined semantics bound
to a considered domain.
In addition, the UML standard defines extensibility mechanisms that
can be used to add domain-specificity to UML. They are profiles, stereotypes and tag values. A profile is a special type of package that contains
stereotypes. A visual representation of a profile is referred to as a profile
diagram. A stereotype allows adding a set of specific properties (suitable
for a particular domain) into existing UML concepts (e.g. class, activity,
component). Thus, a stereotype can be considered as a mechanism to refine existing UML concepts with required non-standard semantics. Each
16
CHAPTER 2. BACKGROUND AND CASE STUDY
stereotype extends (refines) some UML base meta-class (e.g. class, property, named element). Therefore, a stereotype can be used to annotate only
those concepts that extend the same meta-class. A stereotype can introduce
additional domain-specific properties. These properties are defined through
so called tag values. Figure 2.6 depicts a small example of a stereotype definition and its usage. Figure 2.6(a) shows a stereotype called Car that has
two attributes, namely colour and brand. Thereafter, we have applied the
stereotype Car to specialise the class BondCar (see Figure 2.6(b)). Hence,
BondCar has all the properties declared for the Car stereotype. The colour
and brand properties can be assigned to some values using tag values. For
our example in Figure 2.6(b), they are black and Aston Martin respectively.
(a) Definition of a stereo- (b) Usage of a stereotype
type
and tag
Figure 2.6: Example of the stereotype definition and usage
Note, that a stereotype should not be confused with the inheritance
relation. Annotation of entities with a certain stereotype does not bring
the classical child-parent dependency. In our example, if we remove the
stereotype Car from the model, the class BondCar will still exist but without
the colour and brand properties that belong to the stereotype Car. In
contrast, a child can not exist without a parent when the inheritance relation
is established.
One can distinguish two main approaches to defining a UML profile [26].
The first approach starts directly by defining a set of stereotypes that extend
the UML meta-model. The second approach introduces a more systematic
two-stage process.
According to the latter approach, an engineer first needs to create a
conceptual model for a domain. A conceptual model describes all (relevant)
concepts of a selected domain and their relations. In the second stage,
the actual set of stereotypes together with their attributes and constraints
is derived from a conceptual model. This process is sometimes referred
to as mapping [27]. Lagarde et al. [26] suggest to automate this step to
avoid errors and to enable relevant verifications to ensure consistency of the
resulting profile with its conceptual model. In the context of the modelling
language engineering explained in Section 2.2, the mentioned conceptual
model can be referred to as an abstract syntax and a profile as a concrete
syntax.
2.2. MODELWARE ZOO
2.2.3
17
MARTE
MARTE [28] is a standardised UML profile designed for Modelling and Analysis of Real-Time Embedded systems. It contains a rich set of concepts to
support design and analysis of embedded systems. The structure of this profile is outlined in Figure 2.7. The MARTE foundations package provides a
set of concepts required to model non-functional properties (the NFP package), time properties (the Time package), generic resources of an execution
platform (the GRM package), and resource allocation (the Alloc package).
These foundations serve as basics for the MARTE design and analysis models.
The design package (or model) contains sub-packages to describe the
hardware and software resources, namely Hardware Resource Modeling (HRM)
and Software Resource Modeling (SRM). Additionally, the design modelling
packages contains concepts to model a component structure and application features. These concepts are encapsulated into the Generic Component
Model package (GCM) and High-Level Application Modeling (HLAM) packages. The MARTE analysis package provides facilities to model the context
required to perform analysis of real-time and performance characteristics of
embedded systems. In particular, the Generic Quantitative Analysis Modeling (GQAM) package defines a set of general terms while its extensions refine
them to support schedulability (SAM) and performance analysis (PAM).
Figure 2.7: Structure of the MARTE profile
Figure 2.8 shows the basic elements of the GQAM package. Its central
concept is the Analysis Context. This concept aggregates all relevant information needed to describe the constitutents of any type of analysis. In particular, the analysis context concept relates resource platform and workload
behaviour elements. A workload behaviour defines a set of system operations
that are triggered over time by a set of workload events. A resource platform
is a container for resources, i.e. hardware/software execution platform, that
are used by the system operations mentioned above.
Several experience reports on applying the MARTE profile to industrial cases exist. In general, we can distinguish the following strategies for
MARTE exploitation:
• Strategy 1: The whole design process is maintained using MARTE.
18
CHAPTER 2. BACKGROUND AND CASE STUDY
Figure 2.8: Structure of the MARTE analysis packages
• Strategy 2: A part of MARTE is reused. The rest of modelling is
maintained extending MARTE with new concepts or using another
profile together with MARTE.
• Strategy 3: A currently used DSML is adapted and mapped onto
MARTE constructs. Additionally, some new concepts existing in a
selected DSML are created to extend MARTE.
André et al. [29] and Zimmermann et al. [30] explore some MARTE packages to model System-on-Chip and Network-on-Chip systems respectively,
employing strategy 2. In particular, they use time and hardware resource
modelling capabilities of MARTE. Some concepts added into MARTE concepts are Bridge (an extension of the MARTE HwBridge stereotype), Port
(an extension of the HwEndPoint stereotype), and CPU (an extension of
the HwProcessor stereotype). Following the same strategy, Iqbal et al. [31]
use concepts from the NFP and GRM packages together with a set of concepts from another profile to encompass the task of model-based robustness
testing. Bernardi et al. [32] and Cancila et al. [33] define two profiles for dependability (DAM) and safety (SOPHIA) analyses extending the MARTE
analysis modelling packages.
Espinoza et al. [34] present results of the ADAMS project [35] where standards from the automative domain, namely AUTOSAR and EAST-ADL2,
are aligned with MARTE. This use of MARTE corresponds to strategy 3 of
our classification. Demathieu et al. [36] present their experience on applying
MARTE for an academic case study where a robot system is modelled using the SRM and HRM MARTE packages. This work is an example where
strategy 1 within our classification is employed.
2.2.4
SPACE
We proceed to describe a method that employs a modelling language that
is based on a subset of the UML standard enriching it with the formal
semantics.
SPACE is a model-based engineering method [3] supported by the Arctis tool-set [37]. When this method is used, applications are composed of
2.2. MODELWARE ZOO
19
building blocks that can specify local behaviour as well as the interaction
between several distributed entities. This specification style enables a rapid
application development since, on average, more than 70% of a system specification comes from reusable building blocks provided in domain-specific
libraries [38]. In turn, this strategy helps to reduce the expertise required
in developing cross-domain applications. An additional benefit is the formal
semantics of the specification defined by Kraemer and Herrmann [39], which
makes it possible to verify system properties, e.g. that the building blocks
are correctly integrated into activities [37].
Figure 2.9 gives an overview of the SPACE method [39]. An engineer
starts studying a library of reusable building blocks. In case a needed building block does not exist in the library, an engineer can start creating a new
one and add it into the library for its further reuse. Each building block
can cover the behaviour of a single component as well as collaborative behaviour among several components. Building blocks can be domain-specific
or quite general that can be integrated into several systems. Each building
block is described as a combination of UML collaborations (an element of
a UML composite structure diagram), activities (an element of a UML activity diagram), and so-called external state machines (ESMs) that specify
externally visible behaviour of building blocks. Several building blocks are
composed into a system with desired services. At this stage, analysis of a
composed system (e.g. verification of functional or safety properties) can be
performed due to the defined transformation of collaborative models into a
temporal logic formula that serves as an input to the TLA (Temporal Logic
of Actions) model checker [40]. Thereafter, the resulted system design is
automatically transformed into state machines, that can be further used to
generate implementation code via relevant transformations.
Our contribution enhances the step composition and analysis from Figure 2.9 when it comes to decide on a set of security measures expressed as
reusable building blocks. In particular, we elaborate a method to select a set
of security building blocks that are suitable for a system under development
according to identified security needs.
Figure 2.9: SPACE model-based engineering method, adapted from [3]
In the following, we explain elements of the modelling language used
by SPACE, namely local blocks, collaborative blocks, and external state
machines. We use a small example of a simple e-consultation application
20
CHAPTER 2. BACKGROUND AND CASE STUDY
depicted in Figure 2.10 to demonstrate the introduced elements. In this
scenario, a customer sends a question to a consultant. The consultant processes the question and sends a reply to the customer. The system structure
is specified by a UML collaboration as shown in Figure 2.10(a). On this
diagram, the collaboration roles depicted as rectangles represent two components of the system, namely a Customer and a Consultant. These two
components are bound to the client and server roles respectively. The collaboration use, namely the chart:Simple Chart block, that is depicted as an
ellipse encapsulates a logic of the component interaction.
Figure 2.10(b) shows the behaviour view of the system that is modelled
as a UML activity with a slightly modified syntax. The e-consultation scenario is built of two partitions, i.e. the client and the server, that model
the corresponding entities, i.e. a customer and a consultant. These partitions include three building blocks (instantiated as call behaviour actions),
namely cm:Customer, cnt:Consultant, and chart:Simple Chart. The former
two blocks model the local behaviour and are denoted local blocks, while
the latter block models interaction between entities and called collaborative
block. Each of these blocks is associated with another UML activity that
details their behaviour (not shown in Figure 2.10).
(a) UML Collaboration
(b) UML Activity
(c) External State Machine
Figure 2.10: Model of a simple e-consultation application in SPACE
The overall activity is called system block. In our example, the local
blocks are initiated with a special node denoted as filled circle (•). Pins at
sides of building blocks are used to control their behaviour passing tokens of
control or data flows along corresponding edges. The white pins represent
pins that are used to start (the start and in-ask pins) or to terminate (the
out-reply pins) building blocks. The dark pins denote streaming pins, i.e.
pins that are used just to pass data objects. In our case, they are ask, reply,
out-ask, and in-reply. The pins out-reply and in-ask transmit data objects
as well, but these are activating and deactivating pins respectively, and,
therefore, are coloured in white.
2.2. MODELWARE ZOO
21
Figure 2.10(c) illustrates the ESM for the Simple Chart building block
that is a modified UML state machine. The labels of the transitions refer
to pins that sit on sides of the corresponding building block used to pass
tokens. Thus, pins are used to activate transitions. The slash symbol (/)
indicates if a transition is activated by an input (the slash symbol follows
the label) or output (the slash symbol preceeds the label) pin.
Similar to functional building blocks, security mechanisms can be expressed as self-contained building blocks. SPACE has been already used
for encapsulating security functionality in the form of building blocks [41]
validating their correct integration [42]. Additionally, the recent work of
Gunawan and Herrmann [43] enables compositional verification of security
properties for SPACE models.
2.2.5
Tools
MBE promotes the use of modelling for a set of sophisticated tasks of system
development. It defines techniques to manipulate produced models, e.g.
for simulation, verification, and transformation. These techniques, in turn,
must be supported with corresponding tools to enjoy all benefits that are
provided by MBE. This section outlines some basic and widely spread tools
that enable the practices of MBE.
There are two main languages for meta-modelling, namely MOF (referred
to in Section 2.2.1) and Ecore. Recall, that a meta-model or abstract syntax
defines the structure of a modelling language, i.e. its constructs, relations,
and properties. Ecore is a meta-modelling language used within the Eclipse
Modelling Framework (EMF) [44]. The EMF project is a widely used modelling framework that allows engineers to work with modelling languages.
EMF provides facilities to define abstract and concrete syntax, and to create
editors for custom models and Java code for developed meta-models. MOF
is an OMG standard language for meta-modelling that, in particular, defines
UML. OMG defines two variants for MOF, namely Essential MOF (EMOF)
and Complete MOF (CMOF). CMOF extends EMOF with additional structures. To specify a modelling language using EMOF, an engineer can use the
Kermeta tool [45]. Alternatively, KM3 (Kernel Meta-Meta-Model) [46] is a
textual language to create meta-models for DSMLs. Meta-models specified
in Ecore or MOF can be serialised to an XMI file.
A variety of tools exist to define a concrete syntax for a DSML. For
example, Graphiti [47] and GMF [48] are Eclipse-based graphic frameworks
that allow developing custom editors. These tools enable automatic generation of a basic editor that can be further refined and tuned. Alternatively,
an engineer can define the text representation of a concrete syntax for a
modelling language using such tools as Xtext [49]. It provides a language to
define grammars and a generator to create parsers and Eclipse-based editors
for DSMLs.
A lot of tools are available for modelling with UML: MagicDraw [9],
22
CHAPTER 2. BACKGROUND AND CASE STUDY
Enterprise Architecture [50], Rhapsody [51], to name some main examples.
Additionally, EMF provides its own UML2Tool plug-in [52] for defining UML
models. Most of the tools mentioned above already support the use of the
MARTE profile providing corresponding plug-ins. Moreover, MARTE is
implemented in the Eclipse-based Papyrus tool [53]. In our work, we use
the MagicDraw tool together with its MARTE plug-in since MagicDraw was
used in a European project in which we participated. Besides, we use the
Eclipse-based Arctis tool-set [37] to work with the language of the modelbased engineering method SPACE describe in Section 2.2.4.
Atlas Transformation Language (ATL) and Query/View/Transform
(QVT) are M2M transformation languages. QVT (QVT Operational) [54] is
an imperative language standardised by OMG that allows specifying unidirectional transformations. ATL [55] is a declarative and imperative (hybrid)
language developed within EMF. To create transformations using these languages, an engineer needs to write a script. Henshin [56] and EMorF [57]
are declarative EMF M2M transformation languages where transformations
are specified graphically. There is also an extensive support for M2T transformations. For example, EMF provides Java Emitter Template (JET),
Acceleo, and Xpand template-based languages.
2.3
Ontology Technologies
An ontology [58] represents knowledge in a particular domain as a set of
concepts and their relations. This knowledge is formalised as a logic-based
system and described by knowledge representation languages. In particular,
we use the Web Ontology Language (OWL2) [59] which is a commonly used
and standardised language for creation of large ontologies.
OWL represents an ontology as a sequence of axioms. These axioms
describe classes, relations between classes, and their individuals. An OWL
class declares the concept of a domain and can be refined by sub-classes.
OWL individuals are instances of OWL classes. OWL supports two types
of relations. OWL object property defines a relation between two individuals, where one of them plays the role of a domain, and another one plays
the role of a value range. In other words, domain defines a subject of a
relation, whereas range defines an object. OWL datatype property serves to
introduce relations between an individual (domain) and the XML schema
datatypes (range) known as XSD (XML Schema Definition). XSD provides
such primitive data types as boolean, integer, etc.
The OWL language supports a set of constructs that facilitate management of ontologies. In particular, the OWL language implements the
importing feature, which allows relating different OWL ontologies using the
owl:import statement. When merging two or more ontologies, it may be the
case that these ontologies contain overlapping concepts that have different
names, but actually refer to the same things from the reality. Such similar concepts should be related in the merged ontology using the construct
2.3. ONTOLOGY TECHNOLOGIES
23
owl:sameAs. This procedure sometimes is referred as ontologies alignment
that is the process of determining correspondences between concepts.
OWL ontologies enable querying of the declared knowledge by combining ontology reasoners (e.g. Pellet or HermiT) and SPARQL querying language [60]. SPARQL 1.1 is a standard query language (recommended by
W3C) to execute data queries on top of OWL. It supports yes/no-questions
(the ASK query form), a selection which matches a desired pattern (the SELECT query form), filtering (the FILTER modifier), sorting (the ORDER
modifier), string matching, etc.
To design and manage an ontology, one can use such a tool as Protégé [61].
Since tools developed in this work are Java-based, we exploit the Java OWL
API [62, 63] to manipulate ontologies (i.e. addition and modification of
axioms). To execute SPARQL queries, one can load an ontology into the
Protégé tool and use its SPARQL plug-in [64]. In our work, we use Java
APIs provided by the widely accepted Jena [65] framework to query ontologies. It provides the SPARQL compliant query engine (among other
services) for OWL ontologies.
The OWL standard [66] defines three variants of OWL, namely OWL
Lite, OWL DL (Description Logic), and OWL Full. These three sublanguages have different expressiveness and, consequently, different complexity, and, therefore, are used for different purposes. OWL Lite is the
simplest variant and allows the user to capture classification hierarchy and
constraints with restricted expressiveness. For example, it permits only 0
and 1 as cardinality values. However, it has a simple implementation and
comparatively easy to use. In contrast, OWL DL is the most expressive
variant. It supports all OWL constructs, but their use is restricted by a set
of requirements and rules outlined by W3C [66]. These constraints maintain
computational completeness and decidability of this language. OWL Full relaxes constraints of OWL DL and enjoys all capabilities of OWL constructs.
The price for this freedom is absence of any computational guarantees.
Ontologies for Security
A number of ontologies for security have been proposed. For example, Herzog et al. [67] and Fenz and Ekelhart [68] introduce two ontologies that
formalise the domain of information security from different aspects; Kim et
al. [69] present an ontology for annotating web-services; Karyda et al. [70]
propose an ontology to assist reuse of the experts’ security knowledge in
the area e-government applications. Extended surveys and classification of
different security ontologies can be found in works of Blanco et al. [71] and
Souag et al. [72] where the authors discuss 28 and 17 security ontologies
respectively. In our work, we adopt the ontology presented by Herzog et al.
since it is built upon classic components of risk analysis. We continue with
a brief description of this ontology.
The core of Herzog et al. ontology [67] consists of six classes. Four of
them are concepts related to risk analysis, i.e. asset, vulnerability, threat,
24
CHAPTER 2. BACKGROUND AND CASE STUDY
and countermeasure. The remaining two classes are security goal and defence strategy. Relations between these concepts are defined as follows: an
asset can have several vulnerabilities; a threat threatens assets with respect
to some security goals; a countermeasure protects assets with respect to
security goals by means of defence strategies.
The ontology gives diverse classifications of countermeasures, assets,
threats, and vulnerabilities relevant for information security. In particular, the ontology defines 133 countermeasures, 79 assets, 88 threats, and 14
vulnerabilities. The security goal and defence strategy classes are described
by a set of individuals. Six individuals are defined for the defence strategy class, namely correction, deflection, detection, deterrence, prevention,
and recovery. Fifteen individuals are defined for the security goal class, e.g.
confidentiality, integrity, authorisation, and anonymity.
2.4
Case Study: Metering Infrastructure
Figure 2.11 depicts an infrastructure called Trusted Sensor Network (TSN)
from the smart metering domain. This case study is provided by the MixedMode company that are active in the European SecFutur project [10]. TSN
is built of a set of metering devices, database servers, client applications,
and a communication infrastructure. The main goal of this system is to
measure energy consumption at households and to associate measurements
with the clients’ data for billing purposes.
Figure 2.11: Smart metering infrastructure (an overview)
The actual measurement is done by Trusted Sensor Modules (TSMs)
consisting of a computing platform and physical sensors. The acquired measurement data is transferred via a local bus from each TSM to a Trusted
Sensor Module Collector (TSMC). All measurements collected by TSMCs
2.4. CASE STUDY: METERING INFRASTRUCTURE
25
are eventually sent to an operator server through a general-purpose network.
Note that the TSMC is also an embedded device, similar to TSM but with
more functionality. That is, TSMC and TSM are functional modules that
are implemented on the same physical platform.
The overall specification of this case study consists of 11 main scenarios that have a range of diverse security considerations. In this thesis, we
focus on the measurement data transfer from TSM to TSMC and from
TSMC to an operator server. Consequently, we concentrate on those security issues that concern confidentiality and integrity of the measurement
data produced, collected, or stored by the system components.
Chapter 3
SEED: Bird’s Eye View
This chapter presents a Security-Enhanced Embedded system Design (SEED)
approach, that provides concepts, methods, and tools for dealing with security issues of embedded systems already at the design phase.
3.1
Introduction to SEED
SEED addresses the situation when system engineers are not necessarily
security experts, and when security experts are not easily accessible to assist
system engineers. Overall, the SEED approach rests on three basic principles
discussed in the introduction:
• model-orientation,
• domain specialisation, and
• separation of responsibilities and concerns.
Besides these principles, there is another significant design consideration,
namely the proposed approach is defined as an increment to existing practices and process models known for embedded system development. These
concerns for security-related processes have been revealed by Whit and Harrison [73]. The authors point out that among factors that prevent enforcing
security in a systematic way are a lack of security expertise and hesitation
of system engineers to commit to follow a new approach that deals with the
security aspects due to associated risks.
The SEED approach can be considered in two parts that describe it at
two levels of abstraction. These parts are SEED foundation and SEED realisation. The SEED foundation is a generic form of the proposed process1
that can be instantiated for different technologies, modelling and formal languages. The SEED foundation defines main activities, involved roles, used
1 The
words approach and process are used interchangeably in this thesis.
27
28
CHAPTER 3. SEED: BIRD’S EYE VIEW
principles, and their exploitation. The SEED realisation is an implementation of the generic process on a selected set of technologies and languages.
In this thesis, the set of languages and technologies selected for one SEED
realisation are SPACE, MARTE, and ontology.
This chapter focuses on presenting the generic process, i.e. the SEED
foundation. The realisation details are explained in Chapters 4 and 5 where
we also illustrate application of the SEED using the smart metering case
study.
3.2
The SEED Foundation
Figure 3.1 depicts the generic process2 of the SEED foundation. It consists
of three activities: creation of a system model, capturing of the domainspecific security knowledge, and development of a security-enhanced embedded system. These activities are performed by embedded system engineers
or security experts. Thus, the SEED approach acts as a vehicle for communication between the two expert groups. We continue explaining each of the
above-mentioned activities.
Figure 3.1: Generic process – the SEED foundation
3.2.1
Creation of a System Model
The activity of creation of a system model is performed by an embedded
system engineer. Figure 3.2(a) depicts a fragment of a simplified embedded system design flow that demonstrates artefacts that are used for the
SEED foundation. Note, that this figure does not detail how an embedded
2 It has been developed in cooperation with research partners from the EU FP7 SecFutur project [10].
3.2. THE SEED FOUNDATION
29
system engineer produces the artefacts (see the process models described in
Section 2.1).
An embedded system engineer starts from system specifications and creates a functional model of a system and a set of models for potential execution platforms. A functional model of a system is a set of modelling
elements that describe structural and behavioural aspects of an application,
e.g. UML class and activity diagrams respectively. An execution platform
model of a system describes an assembly of resources. Each resource provides some services to support execution of an application described as a
functional model. Thereafter, an embedded system engineer proceeds to
select the best-fitted execution platform. This step includes allocation of
elements of a functional model onto available resources, i.e. onto the execution platform model. In other words, allocation is used to establish an
association between elements of functional and execution platform models.
To sum up, the generic process, i.e. the SEED foundation, uses three artefacts produced while designing an embedded system. These artefacts are a
functional model, execution platform model (just platform model from now
on), and allocation information.
Hence, SEED is intended to support security analysis when a system engineer has a version of a system design when some decisions about functionality of an embedded system and its hardware/software architecture have
been made. At this point, an embedded system engineer has relevant information needed to estimate the system’s capabilities to deal with security
aspects. In particular, the initial system design is present, valuable objects
and actions that influence them are known, and the capacity of a system
dedicated for security enforcement of security can be indicated.
3.2.2
Capturing the Domain-specific Security Knowledge
Capturing (and consequently storing) of the domain-specific security knowledge is an essential step to enable further reuse. This activity is conducted
by a domain security expert (just a security expert or a security engineer
from now on), i.e. a security expert who has knowledge about an application domain. The main task that a security expert completes as a part
of this activity is to describe available security mechanisms. Additionally,
a security expert provides other relevant information that is needed for an
embedded system engineer to make informed decisions to select a suitable
set of security mechanisms.
Figure 3.2(b) illustrates a simplified flow of a security mechanism development adopted in SEED. First, a functional model is created based
on some mathematical abstraction, e.g. an algorithm defined as a mathematical object for further analysis. Similarly to an embedded system,
a functional model defines behaviour and structural aspects of a security
mechanism. Thereafter, a security expert proceeds to implement it. At the
30
CHAPTER 3. SEED: BIRD’S EYE VIEW
implementation phase, besides a functional model, a security expert needs
some information about execution platform constraints, e.g. to select an
implementation language or libraries. Thereafter, the evaluation step allows studying performance aspects of a security mechanism (i.e. the created
resource overhead for a provided security level) on selected evaluation execution platforms given a certain workload.
The set of artefacts mentioned above, namely a functional model, execution platform constraints, data about performance evaluation (evaluation platforms, workload, and results of evaluation), constitute the domainspecific security knowledge. Recall that a domain represents an application
domain like smart metering devices and set-top boxes in the context of
this work. Additionally, the domain-specific security knowledge includes a
declaration of security properties provided by a security mechanism. All
together, these artefacts give a holistic view on existing security solutions
needed to support their integration into an embedded system. For example, an embedded system engineer can study such aspects as: whether a
system integrated with a security mechanism still maintains its dedicated
functionality in a satisfactory way; or whether an integrated security mechanism fits in the resource-related constraints of an embedded system; or
whether security properties of an integrated security mechanism correspond
to formulated security requirements of a system.
The domain-specific security knowledge is stored in a repository so that
it is available for an embedded system engineer to its further reuse. The
domain specialisation of security knowledge is motivated by the following
rationale. Security requirements for a particular application depend on potentially present threats that vary based on the nature of an application and
deployment environment (i.e. a domain). As a result, the domain-specific
security knowledge will have a different set of required security properties
and, consequently, associated with them security mechanisms that satisfy
these security properties.
3.2.3
Development of a Security-enhanced Embedded
System
An embedded system engineer carries out the activity of development of a
security-enhanced embedded system. The goal is to extend a system model
with security features that are retrieved from relevant parts of the domainspecific security knowledge. In particular, this activity of the SEED foundation is built of three basic steps:
• First, a system model is analysed to identify those parts that need
security protection. Both functional and execution platform models
are subjects of this analysis.
• Second, the security knowledge is consulted to retrieve a set of relevant security properties (based on outcomes of the previous step).
3.2. THE SEED FOUNDATION
(a) Embedded system
31
(b) Security mechanism
Figure 3.2: Fragments of simplified design flows
Consequently, a set of security mechanisms that are available in the
repository to satisfy identified security properties are also retrieved
from the domain-specific security knowledge.
• Finally, since integration of a new feature into an embedded system
comes with resource claims, a selected set of security mechanisms is
studied with respect to a potentially created resource overhead.
The result of this activity is an embedded system design extended with
a suitable set of security mechanisms that meet security goals of a system
under development.
In this section, we have described the SEED foundation that presents
the generic process intended to support an embedded system engineer and
security expert in designing security-enhanced systems. In the next chapters, we describe one instance of the SEED realisation. In particular, we
clarify in terms of specific concepts, methods, languages, and technologies
how the domain-specific security knowledge is captured by a security expert
(in Chapter 4) and how it is applied by an embedded system engineer (in
Chapter 5).
Chapter 4
Capturing of the
Domain-specific Security
Knowledge
This chapter details the “capturing of the domain-specific security knowledge” activity for the SEED realisation. Recall from Figure 3.1, that as a
part of this activity, a security expert creates a set of artefacts to describe the
existing security mechanisms. This description includes functional model of
security solutions, their provided security properties, and information about
their performance evaluation. In order to structure and operate with this
information, we develop two concepts, namely a Domain-Specific Security
Model (DSSM) and a Performance Evaluation Record (PER). These concepts are formalised as a set of ontologies. Additionally, we employ methods
and tools from the area of model-based engineering, like modelling languages
and transformations, to facilitate the creation and usage of these concepts
by embedded system engineers and security experts.
We describe the developed concepts and their support in Section 4.1.
Thereafter, Section 4.2 explains processes and tools created to assist a security expert to work with the introduced concepts.
4.1
Developed Concepts and Artefacts
As mentioned above, our approach rests on two concepts. DSSM is a concept
used by a security expert to describe a security solution; PER is another
one that serves to describe results of performance evaluation of a security
solution. These concepts are implemented by aligning two technologies,
namely UML and ontologies. In the following, Section 4.1.1 and Section 4.1.2
explain the DSSM and PER concepts respectively.
33
34
4.1.1
CHAPTER 4. CAPTURING OF THE DOMAIN-SPECIFIC
SECURITY KNOWLEDGE
Domain-specific Security Model
A scheme depicted in Figure 4.1 shows the introduced artefacts and their
relations. The core artefact is an ontology that we use to define the structure
for description of the domain-specific security knowledge. Among studied
ontologies for the security domain, the one created by Herzog et al. [67] fits
our needs. This ontology is a general information security ontology and was
explained in Section 2.3. The ontology created in our work is an adapted
Herzog et al. security ontology and is called core security ontology. To
facilitate the use of this ontology we define an expert’s front-end using the
widely accepted UML standard. In particular, the core security ontology
is represented as a UML class model. This UML class model serves as
a simple tool used by security experts to describe their knowledge about
existing security solutions. Therefore, an instance of this model, i.e. object
diagram, is actually the captured domain-specific security knowledge and is
called Domain-Specific Security Model (DSSM). We transform each DSSM
into the OWL syntax and use it to extend the original core security ontology.
We refer to an extended ontology as an enriched security ontology. In the
following, we continue explaining the mentioned artefacts in more detail.
Figure 4.1: DSSM concept and related artefacts
Core Security Ontology
The core security ontology adapted from the Herzog et al. [67] ontology
is depicted in Figure 4.2. The main point of departure arises in order to
introduce three new concepts, which are security property, security building
block, and domain. Thus, the use of the Herzog et al. ontology has served its
purposes outlined by the authors [67], namely as a learning material about
the structure of information security and as a framework for developing new
detailed security taxonomies. We proceed to describe the adapted ontology
used to support the processes of capturing and using the domain-specific
security knowledge.
In the core security ontology, we reuse three basic concepts introduced by
Herzog et al. [67], namely asset, security goal, and defence strategy. Assets
are the “objects of value” of a system that are needed to be protected. In
our context, they can be stationary data residing on a physical component
or data in transit being transmitted between different components. Other
4.1. DEVELOPED CONCEPTS AND ARTEFACTS
35
Figure 4.2: Core security ontology fragment
types of assets, e.g. algorithms or Intellectual Properties (IPs), may also be
considered and introduced. The protection of an asset leads to the fulfilment of a particular security goal like protecting its confidentiality, integrity,
or availability. The countermeasures introduced below follow a certain defence strategy, e.g. preventing attacks or recovering after an attack. For
the security goal and for the defence strategy, we reuse all the terms (i.e.
individuals) defined in the ontology of Herzog et al.
In addition to these elements, the core security ontology introduces new
concepts, which are shown as grey boxes in Figure 4.2. Two of them are
abstract and concrete Security Building Blocks (SBBs) replacing the notion
of a countermeasure used by Herzog et al. [67]. These refinements enable
us to distinguish between more general countermeasures represented by the
abstract SBBs and their implementations specified as concrete SBBs. For
example, an abstract SBB might refer to a cryptographic hash function as
a general method to provide integrity while the different realisations of the
hash function (e.g. SHA-1, MD2, or MD5), that are implemented as a piece
of code or hardware, are each described by a concrete SBB. With respect
to the resource limits of embedded systems, it is important to note that
the implementations may have different resource footprints. Each concrete
SBB has some functional model and platform model. The latter may be
considered as a description of platform components that are required by a
concrete SBB for execution. Further, a concrete SBB can comply with some
standards, e.g. it may have passed some certification. Another concept
introduced by our ontology is the notion of security properties encompassing
the three notions: assets, security goals, and defence strategies. Finally,
we enrich the ontology with the concept of a domain that represents an
36
CHAPTER 4. CAPTURING OF THE DOMAIN-SPECIFIC
SECURITY KNOWLEDGE
application domain, e.g. the smart metering domain.
The relations in the core security ontology are defined as follows. Like
the countermeasures in the Herzog et al. ontology, an abstract SBB protects
an asset, provides some security goals, and uses some defence strategies. We
have modified the protects relation for a security goal and a defence strategy
used by Herzog et al. [67] since we find that the provides and uses relations
reflect more precisely their semantics within our process. In addition to
these three relations, an abstract SBB belongs to some application domain.
A concrete SBB implements an abstract SBB but, in turn, may create certain assets itself. Therefore, both the assets in the core system and the assets
created to realise the concrete SBBs require security goals. For example, the
keys in some implementation of a public key cryptography mechanism have
to be protected in order to fulfil the confidentiality and integrity goals. Functional and platform models are related to the concrete SBB concept with
the has relation. The last relation of the concrete SBB concepts is a comply
that relates it to the standard concept. This covers common requirements
in engineering of networked embedded systems. In the metering domain, for
example, a system will have to fulfil legal calibration requirements following a standard. Finally, a security property relates assets, security goals,
and defence strategies, which in the following sections will be referred to by
triplets [asset, security goal, defence strategy].
The UML Representation
To support a security expert in capturing the domain-specific security knowledge that is formalised as the core security ontology, we represent the ontology as a UML class model depicted in Figure 4.3. Each DSSM is effectively
an instantiation of the core security ontology. Therefore, we specify a DSSM
as an instance of this class model. The security knowledge captured by each
DSSM is used to extend our core security ontology presented above with
a corresponding set of axioms on relations and individuals. This enables
us to use the ontology querying and reasoning services to extract required
parts when this knowledge is required for an embedded system engineer. In
other words, the class model in Figure 4.3 serves as a language dedicated for
capturing knowledge by security experts, i.e. to create DSSMs, while the
ontology in Figure 4.2 is a formalism for this language [25].
It is worth mentioning, that the UML model in Figure 4.3 is not a direct transformation of the security ontology from Figure 4.2 since it is not
domain knowledge by itself, but rather a tool to capture the knowledge.
The model consists of five classes and three relations, which are direct mappings of the elements of the core security ontology. The preserved classes
are Asset, AbstractSBB, ConcreteSBB, DataStationary, and DataInTransit. The preserved relations are implements (between ConcreteSBB and
AbstractSBB ), protects (between Asset and AbstractSBB ), and creates (between ConcreteSBB and Asset). The is-a relation from DataStationary and
DataInTransit to Asset in the core security ontology is modelled in the form
4.1. DEVELOPED CONCEPTS AND ARTEFACTS
37
Figure 4.3: UML representation of the core security ontology
of generalisations.
Other elements of the core security ontology are specified in a different way. Instances of the security goal and defence strategy classes are
represented as the enumerations SecurityGoalKind respective DefenceStrategyKind. The uses relation between the abstract SBB and defence strategy
classes in our ontology is represented by the property usesStrategy in the
class AbstractSBB. Likewise, the providesGoal property in AbstractSBB replaces the provides relation between the abstract SBB and security goal
classes of the core security ontology. Similarly, the functional model, platform model, and standard concepts related to the concrete SBB concept are
represented as the mFunctional, mPlatform, and stdCompliance properties
of the ConcreteSBB class respectively. Finally, the requiredGoal property
in the association class creates represents the relation requires between the
created asset and the security goal classes of the ontology.
In contrast, the security property and the domain concepts of the core
security ontology are not directly represented in the UML model. This is due
to the fact that the triple asset, security goal, and defence strategy already
captures the notion of a security property. Therefore, security properties
can be directly extracted from a DSSM. Analogously, the domain concept
from the core security ontology is represented by the name of a DSSM (i.e.
the object diagram).
Besides, the UML class model in Figure 4.3 has one additional property,
which does not exist in the ontology, namely externalDSSM in the creates
association class. The externalDSSM property refers to other DSSMs. The
use of this property is needed if a created asset requires protection provided
by security building block that belongs to another known domain.
As mentioned before, a given DSSM is essentially an instance of the UML
class model depicted in Figure 4.3. As an example, we depict in Figure 4.4
the UML class diagram for a small fragment of the metering DSSM used
for our measurement transfer scenario from Section 2.4. This DSSM contains three assets: StoredMeasurement that represents energy measurements
stored on a device; CollectorToServerMsr that represents energy measurements sent from a collector device to an operator server; SensorToMeterMsr
38
CHAPTER 4. CAPTURING OF THE DOMAIN-SPECIFIC
SECURITY KNOWLEDGE
Figure 4.4: Fragment of the metering DSSM
that represents energy measurements sent from a sensor to a metering device. These assets may be protected by five abstract SBBs: Secure stor-
4.1. DEVELOPED CONCEPTS AND ARTEFACTS
39
age and Tamper evident seal that provide confidentiality and integrity for
the StoredMeasurement asset; Cipher that provides confidentiality for the
CollectorToServerMsr asset; Digital signature that provides integrity and
authentication for the CollectorToServerMsr asset; and Anomaly detection
that provides integrity for the SensorToMeterMsr asset. Seven concrete
SBBs implement these abstract SBBs. Each abstract SBB in Figure 4.4 is
supported by one or two implementations. In general, one abstract SBB
can be implemented by several concrete SBBs. For example, the DES and
AES concrete SBBs implement the Cipher abstract SBB. These concrete
SBBs have one or a pair of functional models (see the mFunctional slot). In
this study and in this SEED realisation, they are Arctis blocks for encryption (AES Encryption and DES Encryption respectively) and decryption
(AES Decryption and DES Decryption respectively).
Enriched Security Ontology
In the following, we explain the last artefact introduced in Figure 4.1, namely
the enriched security ontology.
Each DSSM is transformed into the OWL syntax (outlined in Section 2.3)
extending the core security ontology, as it is depicted in Figure 4.1. In other
words, these DSSMs are used to populate the core security ontology. In
turn, each DSSM is encapsulated into a separate ontology, called [domain
name] security ontology that imports (using the owl:import construct) the
core security ontology. We refer to the merge of all domain security ontologies obtained from DSSMs as the enriched security ontology. This modular
structure of the enriched security ontology facilitates its management (e.g.
its update). Figure 4.5 shows the described dependencies of the introduced
ontologies. In this figure, Domain 1 and Domain n represent application
domains, e.g. metering devices and set-top boxes domains respectively.
Figure 4.5: Enriched security ontology
The task of updating the enriched security ontology with the knowledge
CHAPTER 4. CAPTURING OF THE DOMAIN-SPECIFIC
SECURITY KNOWLEDGE
40
captured by a newly created DSSM is implemented as transformation of
elements of a DSSM and their relations into corresponding set of axioms
on classes, relations, and individuals. We use model-to-text transformation
techniques and tools, like Acceleo [74], to realise this transformation. Afterwards, these axioms are added into the corresponding [domain name]
security ontology.
All objects of the metering DSSM in Figure 4.4 are added into the enriched security ontology as individuals of the corresponding concepts of the
core security ontology from Figure 4.2. Thereafter, additional axioms are
added that transform instances of the protects, implements, and creates
associations from a DSSM into corresponding (OWL) object properties.
The usesStrategy and providesGoal attributes are transformed into triples
of [object, object property, subject] where an object is an instance
name of the AbstractSBB class, an (OWL) object property corresponds to
the uses and provides relations respectively, and a subject is a value of the
attribute. The requiredGoal attribute is transformed into analogous triples
where an object is an instance name of the Asset class, an (OWL) object
property corresponds to the requires relation, and a subject is a value of the
attribute. Such attributes as mFunctional, mPlatform, and stdCompliance
are approached in a similar way. The difference is that an (OWL) object
property is replaced by a (OWL) data property since values of these three
attributes are strings.
4.1.2
Performance Evaluation Record
Figure 4.6 depicts a scheme that shows the defined artefacts and their relations. This scheme follows a similar pattern as presented in the previous
section. The core artefact is an ontology that describes concepts and relations of the performance evaluation domain. This ontology is called core
evaluation ontology. Differently from the core security ontology, a UML
profile is designed as a representation front-end for the core evaluation ontology. This profile is called General Evaluation Model (GEM). An expert
defines an evaluation context as a set of UML models of different types and
annotates their elements using stereotypes of the designed profile. These
UML models are called Performance Evaluation Record (PER). Further,
these models are transformed into the OWL syntax and used to extend the
initial core evaluation ontology forming an enriched evaluation ontology.
The infrastructure in Figure 4.6 can be used to capture results of performance evaluation of any building block that realises extra-functional properties, e.g. security, safety, and real-time. Thus, security is just one example
of such extra-functional properties. Therefore, we use generic terms in this
section, i.e. the SBB term introduced in the previous section is replaced by
the Reusable Building Block (RBB) concept. We use examples of security
RBBs (i.e. SBBs) to illustrate some introduced concepts 1 .
1 In
the rest of the thesis (except this section), we avoid using the term RBB. However,
4.1. DEVELOPED CONCEPTS AND ARTEFACTS
41
Figure 4.6: PER concept and related artefacts
In the following, we continue explaining in more detail the mentioned
artefacts.
Core Evaluation Ontology
Figure 4.7 depicts an ontology developed in this study in order to capture results of performance evaluation of RBBs called core evaluation ontology. To
build the core evaluation ontology, we use the knowledge about the structure
of the analysis domain obtained from various sources. They are mainly the
MARTE GQAM profile explained in Section 2, and the published research
and industrial papers where performance aspects of different RBBs are studied, e.g. such works published by Nadeem and Javed [75] and Preissig [76]
where performance characteristics of security solutions are investigated. We
proceed to describe elements of the core evaluation ontology depicted in
Figure 4.7.
Figure 4.7: Core evaluation ontology
Evaluation is a central concept of the core evaluation ontology. It relates
four other concepts that indicate constituents of any evaluation procedure.
a reader should understand that the term SBB can be replaced by RBB when it comes
to discussions of PER and related concepts (e.g. in Section 4.2 and 5.5).
42
CHAPTER 4. CAPTURING OF THE DOMAIN-SPECIFIC
SECURITY KNOWLEDGE
They are Target of Evaluation (ToE), approach, workload, and metrics.
ToE refers to an RBB that is under performance evaluation. There are
two sub-classes for the ToE concept, namely ToE RBB and ToE function.
A ToE can be characterised by a set of parameters introduced by the ToE
parameter concepts, e.g. the key size for an encryption RBB. The platform
concept denotes an evaluation platform used for performance analysis. We
create the required component concept to introduce those components of an
evaluation platform that are significant for a considered ToE to obtain the
captured performance results. For example, it can be a particular instruction
set exploited by a ToE implementation.
The approach concept denotes the description of the used evaluation
method. Each approach can be characterised by its kind and approach
parameters. The approach kind concept defines the type of the evaluation
method. It has such individuals as simulation, emulation, or analytical
analysis. The workload concept introduces the workload used during the
performance evaluation, e.g. a sequence of triggering events, or an amount
of data sent over a channel. Similarly, a workload can be parameterised
using the workload parameter concept.
The metrics concept defines a set of metrics adopted for the performance evaluation. These metrics can be of two categories as denoted by its
sub-classes. The first category (the resource metrics concept) describes the
resource footprint created by ToE (e.g. execution time). The second category (the domain metrics concept) refers to the obtained indicators that
characterise the quality of extra-functional properties, e.g. the security level
provided by a ToE. The presence of these two categories reflects the fact
that for selection of suitable RBBs both resource footprint and quality of
service indices play a significant role.
The following relations are defined in the core evaluation ontology. Any
evaluation evaluates some ToE, executes under some workload, uses some
approach, and obtains some metrics. A ToE RBB can provide some ToE
functions. Any ToE executes on some evaluation platform. A platform may
contain some required components. Any obtained metrics are measured on
some platform. A ToE, approach, and workload have some ToE parameters,
approach parameters, and workload parameters respectively. Additionally,
an approach can have some approach kind. Finally, each evaluation has
some date and performed by some organisation.
The UML Representation
In this section, we define a profile used by an expert in order to capture
performance evaluation results called Generic Evaluation Model (GEM).
This profile is depicted in Figure 4.8.
The GEM profile consists of nine stereotypes and nine relations which
are direct mappings of the elements of the core evaluation ontology. The
preserved classes are gemToE, gemToE RBB, gemToE Function, gemEvaluation, gemApproach, gemWorkload, gemMetrics, gemPlatform, and gem-
4.1. DEVELOPED CONCEPTS AND ARTEFACTS
43
Figure 4.8: GEM UML profile to capture performance evaluation results
RequiredComponent. The preserved relations are uses, evaluatesUnder, obtains, and evaluates which relates gemEvaluation with gemApproach, gemWorkload, gemMetrics, and gemToE respectively. Other directly mapped
relations are measuredOn between the gemMetrics and gemPlatform stereotypes, contains between gemPlatform and gemRequiredComponent, executesOn between gemToE and gemPlatform, and provides between gemToE RBB and gemToE Function. The is-a relations from gemToE RBB
and gemToE Function to gemToE in the core evaluation ontology are modelled as generalisations in GEM.
Other elements of the evaluation ontology are specified in a different way.
Individuals of the approach kind class are represented as an ApproachKind
enumeration (not shown). The has relation between the ToE and ToE parameter classes in our ontology are represented by the property toeParam in
the class gemToE. Likewise, the approachParam property in gemApproach
replaces the has relations between the approach and approach parameter
concepts of the core evaluation ontology. The same logic applies for the
workloadParam property. Finally, the sub-classes of the metrics concept
are represented as corresponding tags of the gemMetrics stereotype, namely
domainMetrics and resourceMetrics.
In the following, we explain what UML models can be annotated with
the stereotypes from GEM, and what MARTE packages are reused. We
conclude this section with an example illustrating a possible use of the GEM
profile.
44
CHAPTER 4. CAPTURING OF THE DOMAIN-SPECIFIC
SECURITY KNOWLEDGE
gemToE, gemApproach, and gemWorkload can be used to annotate either
a complex or a very simple UML model of a corresponding constituent.
The level of detail does not play a significant role for the GEM profile.
Nevertheless, the richer these models are the more informed decisions can
be made by an embedded system engineer when selecting RBBs.
In order to model an evaluation platform, i.e. the gemPlatform stereotype, we use a UML class model annotated with stereotypes from the HRM
MARTE package. An execution platform can describe resources that take
a variety of forms, e.g. hardware, software, or logical resources. In this
study, we consider only hardware components. However, the general concept is scalable to include other forms of resources for analysis. Additionally,
we employ the MARTE NFP types to specify values of all parameters and
metrics tags defined in GEM.
The MARTE GQAM profile (outlined in Section 2.2) allows bridging the
gap between model-driven engineering and existing formalisms and tools for
analysis. Thus, it significantly helps the domain (in our case, security)
experts to design their evaluations. In order to demonstrate how our profile
can be used to capture performance evaluation results modelled in GQAM,
we identify the correspondence between the stereotypes and tags of GEM
and GQAM shown in Table 4.1.
Note that our profile is not restricted to capturing results only when
GQAM or its refinements are used. For example, results presented by Preissig [76], that are obtained through a traditional approach, can also be described by GEM (as we will show later in this section). However, GQAM
can facilitate this task, since the mapping identified in Table 4.1 can be
automated as a transformation directly feeding relevant data into GEM.
GEM is a general UML profile that does not target any concrete extrafunctional domain. The same statement is applicable for the core evaluation
ontology. Therefore, a domain expert should refine some of its concepts to
tailor it to a certain domain. In particular, an expert needs to extend
the ToEParameter, DomainMetrics, and ResourceMetrics stereotypes. Figure 4.9 shows such a refinement for the security domain as an example where
a cipher and anomaly detection RBBs are considered. ToEParam Anomaly
and ToEParam Cipher refine the ToEParameter concept. According to
these refinements, an anomaly detection mechanism can be characterised
by the number of clusters (numberOfClusters), while a cipher building block
can be characterised by its key size (keySize) and cipher mode (cipherMode).
Quality of service metrics for an anomaly detection are detection rate and
false positive rate (see DM Anomaly) and for a cipher they are resistance
to attacker’s capabilities in terms of its skill, motivation, and duration of
the attack (see DM Cipher ). Finally, a pair of resource metrics are considered for these two security RBBs, namely bandwidth and energy (see
RM Anomaly) for an anomaly detector and the used memory and data rate
(see RM Cipher ) for a cipher.
A description of actual performance evaluation results captured when
4.1. DEVELOPED CONCEPTS AND ARTEFACTS
45
Table 4.1: Correspondence between our GEM and (MARTE) GQAM
GEM
gemToE
toeParam
gemPlatform
gemRequiredComponent
gemApproach
kind
approachParam
gemWorkload
workloadParam
gemMetrics
resourceMetrics
domainMetrics
GQAM
The GaScenario stereotype
No direct mapping. It can be mapped
to some variables declared in the contextParam tag (the GaAnalysisContext
stereotype) where sourceKind is defined as
required (req).
The GaResourcePlatform stereotype
Any element from a GaResourcePlatform
model can be annotated with this stereotype.
Not represented.
Not represented. It is defined by an analysis formalism that underlies the GQAM
model.
Not represented.
The GaWorkloadEvent stereotype
No direct mapping. It can be mapped
to some variables declared in the contextParam tag where sourceKind is defined
as required (req).
No direct mapping. It can be mapped to
any declared variable where sourceKind is
set to calculated (calc), estimated (est), or
measured (msr).
No direct mapping. It can be mapped
to some variables declared as tags of the
GaStep stereotype.
No direct mapping. These variables are
usually defined by domain experts and introduced as a part of the contextParam
tag.
the GEM profile is used is called Performance Evaluation Record (PER).
Figure 4.10 depicts an example of a PER used in development of the smart
metering application from Section 2.4. The DES Evaluation class annotated
as “gemEvaluation” shows that an evaluated RBB is DES Encryption where
DES Metrics is a set of the obtained metrics. The DES Encryption RBB
has configuration parameters specified in DES Settings and is executed on
the TMS320C6211 chip. Besides, TMS320C6211 is annotated with the gemRequiredComponent stereotype and, therefore, will be treated as a platform
constraint for DES Encryption in further analysis.
46
CHAPTER 4. CAPTURING OF THE DOMAIN-SPECIFIC
SECURITY KNOWLEDGE
Figure 4.9: The refinement of the GEM profile for the security domain
Figure 4.10: Fragment of the security evaluation record for the DES RBB
Enriched Evaluation Ontology
In the following, we explain the last artefact introduced in Figure 4.6, namely
the enriched evaluation ontology.
Each refinement of the GEM profile for an extra-functional domain (e.g.
as one depicted in Figure 4.9) is transformed into a separate ontology called
[domain name] evaluation ontology that imports the core evaluation ontology enriching it with additional concepts from this domain, e.g. refinements
of the ToE parameters, domain, and resource metrics concepts. Since each
PER (e.g. as one depicted in Figure 4.10) is essentially an instance of the refined GEM profile, we transform it into axioms on individuals and call it [domain name] evaluation record ontology. The transformation is approached
similar to one outlined in Section 4.1.1. For example, a class annotated
with the ToE stereotype becomes an individual of the ToE class. A [domain
name] evaluation record ontology imports a corresponding [domain name]
evaluation ontology. We refer to a collection of [domain name] evaluation
record ontologies as an enriched evaluation ontology. Figure 4.11 shows the
above introduced ontologies and their dependencies. In this figure, Domain
1 and Domain n represent extra-functional domains, e.g. Domain 1 can be
exemplified as the security domain, and Domain n as the safety domain.
4.2. CAPTURING SECURITY KNOWLEDGE
47
Figure 4.11: Enriched evaluation ontology
4.2
Capturing Security Knowledge
In this section, we explain the proposed process for capturing of the domainspecific security knowledge using the DSSM and PER2 concepts.
The starting point of the creation of DSSMs is to decide on a domain.
The DSML theory inherently leaves the notion of a domain flexible. Hence,
it is up to security experts to decide what kind of a domain a DSSM will
describe. Typically, we consider application domains (e.g. metering devices,
set-top-boxes, banking access terminals), which can be characterised by a
different set of assets and a specialised set of security solutions. Domains
can be in some relations, e.g. domains can overlap or one domain can be a
part of another one. Note that the closer a selected domain is tailored to a
type of a system, the more specialised and detailed solutions it contains (i.e.
the set of assets and concrete SBBs). For example, both communication
and metering DSSMs may be applied for our smart metering devices case
study described in Section 2.4, but obviously the communication DSSM will
contain such general assets as “message” and “acknowledgement”, while the
metering DSSM operates with “measurement” as an asset.
The process of DSSM creation is depicted in Figure 4.12. It starts
with three activities: Create a DSSM, Create functional models for concrete
SBBs, and Create PERs for concrete SBBs. The Create a DSSM activity
includes definition of assets, abstract SBBs with their goals and strategies,
and concrete SBBs omitting the definition of their functional and platform
models (i.e. the mFunctional and mPlatform slots of the ConcreteSBB class
depicted in Figure 4.3). Thus, the outcome of this activity is a definition of
the DSSM with place holders for concrete SBBs. Functional models of each
concrete SBBs are created during the Create functional models for concrete
SBBs activity. A security expert creates, e.g. Arctis models of the concrete SBBs. The third activity, i.e. Create PERs for the concrete SBBs, is
2 In this section, we start again to use the term (concrete) SBB instead of RBB when
discussing PER and related concepts shifting the focus back to security.
48
CHAPTER 4. CAPTURING OF THE DOMAIN-SPECIFIC
SECURITY KNOWLEDGE
concerned with a description of the performance evaluation results in the
form of PERs. Note that as a part of each PER a security expert defines
a platform used for an evaluation of a concrete SBB. This platform model
serves as a platform model associated with a concrete SBB (the mPlatform
slot) as it will be shown later.
The order of the three activities described above is undefined, since it
does not play a significant role for our process. Thus, if Arctis models of
the considered concrete SBBs exist (e.g. they are available in the Arctis
library of building blocks [38]), the corresponding activity can be omitted.
Similarly, the activity Create PERs for concrete SBBs can be omitted. The
absence of any of the two types of artefacts produced by these activities (i.e.
functional models for concrete SBBs or their evaluation records) will simply
disable the corresponding type of analysis.
Figure 4.12: The process for creation of DSSMs
The next activity is Register the concrete SBBs that allows associating
the created functional (Arctis) models and PER models of concrete SBBs
with the corresponding elements of the DSSM. In particular, the functional
Arctis model is bound to the mFunctional ; the evaluation platform model
from the created PER indicated with the gemPlatform stereotype is bound
to the mPlatform slot. When all concrete SBBs of the created DSSM have
been bound with the functional and PER models, the DSSM can be registered.
The main outcome of the Register the DSSM activity is two ontologies.
4.2. CAPTURING SECURITY KNOWLEDGE
49
The first ontology is a [domain name] security ontology derived from the
DSSM that is a part of the enriched security ontology as explained in Section 4.1.1. The other ontology is a [domain name] evaluation record ontology
derived from the PER that is a part of the enriched evaluation ontology as
explained in Section 4.1.2. Note that the enriched security and evaluation
ontologies are two independent ontologies that can be used separately from
each other. In our work, we align them employing the owl:sameAs construct (see Section 2.3) as follows: PlatformModel owl:sameAs Platform,
FunctionalModel owl:sameAs ToE.
It is worth noting that this architecture is modular. For example, the
activity Create PERs for concrete SBBs can be replaced by any other activity that allows preparing concrete SBBs for a desirable type of analysis.
This will require creation of the needed infrastructure (e.g. ontologies and
profiles) and adjustment of the alignment.
When updating the enriched ontologies with new knowledge, the important question of maintaining their consistency arises. In particular, an
obvious problem when updating the enriched security ontology is its pollution with concrete SBBs that have different names but refer to the same
implementation3 . The unique name assumption of an ontology says that
entities with different names refer to different elements of the real world.
The OWL language has two constructs to express this assumption, namely
owl:sameAs or owl:differentFrom, that assert that two or more given entities
refer to the same or to different elements of the real world respectively. We
use the latter construct each time a new concrete SBB is added into the
enriched security ontology. However, it may be the case that security experts will populate the enriched security ontology with concrete SBBs that
actually refer to the same implementation. This situation can be resolved
by the owl:sameAs construct that states that two or more individuals refer
to the same element of the real world. However, some additional support
may be needed to ensure that two (or more) concrete SBBs under different
names are equal implementations. We envisage that techniques from the
area of model comparison or models diff (applied to functional and platform
models of concrete SBBs) can be employed to address the mentioned issue.
For example, Selonen [77] and Bendix and Emanuelsson [78] have a survey
about existing model comparison methods for UML models. Besides, a set
of tools exist to implement model comparison, e.g. EMF Compare [79].
The exploitation of these techniques goes beyond the scope of this work.
We consider it as a further enhancement of our tool support. In the rest of
this section, we outline a developed tool that supports the above process of
DSSM creation.
As mentioned earlier, we use the MagicDraw tool [9] as an integration environment. To create DSSMs and PERs, we use the standard functionality
provided by MagicDraw. At the same time, functional models of concrete
SBBs are created in the Arctis tool [37]. In order to bind these two tools
3 The
trivial case, i.e. two entities with the same names, is not possible.
50
CHAPTER 4. CAPTURING OF THE DOMAIN-SPECIFIC
SECURITY KNOWLEDGE
supporting the process of DSSM creation, we have developed a SEED MagicDraw plug-in. In particular, this plug-in assists the creation of DSSMs by
supporting the following activities of the process depicted in Figure 4.12:
• Creation of a DSSM: the plug-in prepares an environment for a security
expert, i.e. it creates a MagicDraw project and loads the class model
depicted in Figure 4.3.
• Registration of concrete SBBs: the plug-in provides an interface (shown
in Figure 4.13) for binding functional model and platform model elements of concrete SBBs with corresponding Arctis and MARTE (from
PER) models.
• Registration of a DSSM: the plug-in executes transformation of the
DSSM and PER to a set of axioms and adds them into the enriched
ontologies. Additionally, the plug-in can be used to upload the created
DSSM and PER to a library (local or public) for its further use.
Figure 4.13: Registration of concrete SBBs tool (the user interface)
This chapter has explained capturing of the domain-specific security
knowledge. For this purpose, we have introduced two concepts, namely
the DSSM and PER concepts. The process followed by a security expert,
that exploits DSSMs and PERs, has been described. In the next chapter,
we describe how an embedded system engineer can apply this knowledge to
select a suitable set of security solutions to be integrated into a system.
Chapter 5
Application of the
Domain-specific Security
Knowledge
This chapter explains the “Development of a security-enhanced embedded
system model” activity for the SEED realisation. In particular, we focus on
the process of application of the domain-specific security knowledge captured
using DSSMs and PERs. This process is depicted in Figure 5.1.
Figure 5.1: Application of the domain-specific security knowledge
The process starts from the functional and platform models of a system.
In particular, we use SPACE models (see Section 5.1.1) to create a functional
description of a system and UML class models annotated with some MARTE
stereotypes (see Section 5.1.2) to create a platform description of a system.
Thereafter, a suitable DSSM is selected and its elements are associated with
the components of a functional model of a system (see Section 5.2). Note
that if a required DSSM is not found, this step should be preceded by
the DSSM creation step explained in the previous chapter. That is, the
association step could be postponed until a suitable DSSM is created.
51
52
CHAPTER 5. APPLICATION OF THE DOMAIN-SPECIFIC
SECURITY KNOWLEDGE
The step Association with DSSMs is followed by the step Asset elicitation&Search for security properties (see Section 5.3) that results in a list
of relevant security properties to be satisfied. Subsequently, concrete SBBs
that satisfy the identified security properties are inferred from the enriched
security ontology as indicated by the Search for concrete SBBs step. Thereafter, a related set of SPACE models are fetched, e.g. from the Arctis
libraries. This step is explained in Section 5.4.
Due to the existence of different concrete SBBs, often various ways to
secure an embedded system are possible that differ with regards to a range
of criteria. For example, an engineer needs to ensure that a system under consideration will still perform the required functionality when security
mechanisms are incorporated [42]. Additionally, when dealing with embedded systems, one needs to investigate how the added security mechanisms
affect the consumption of crucial resources. The compliance of considered
concrete SBBs to some standards can also affect a decision taken by a system engineer. A set of other possible criteria to be considered is proposed
by Georg et al. [80]. Thus, to find a suitable solution one needs to carry
out analysis of desired criteria and compare different alternatives. In our
work, we introduced a so called model-based compatibility analysis technique applied at the Compatibility-based selection of concrete SBBs step.
This analysis studies platform-related constraints of a system under development and alternative concrete SBBs.
Subsequently, a set of SPACE blocks that satisfy this criterion are integrated into a system model. At this point, other type of analysis are enabled,
e.g. to verify that integration of concrete SBBs provides the required level
of protection or that functional properties of a system are not violated by
this increment. It is reflected by the Analysis&Integration of concrete SBBs
step. A dashed line of the box for this step in Figure 5.1 indicates that the
elaboration of this step is not a contribution of this work. However, some
types of analyses are in a focus of the research group that is developing the
Arctis tool.
In the rest of this chapter, we explain each step outlined above using
the case study introduced in Section 2 as a running example. We conclude
this chapter with Section 5.6 that gives to a reader a broader view on the
process of designing a security-enhanced embedded system. In particular,
Section 5.6 extends the proposed process from Figure 5.1 highlighting additional steps and considerations that an embedded system engineer needs
account for when integrating security mechanisms into a system.
5.1
System Model
In the following, we demonstrate the languages employed in our work for
the functional and platform modelling. Section 5.1.1 illustrates a model
of the measurements transfer scenario using the model-based engineering
method SPACE. Section 5.1.2 shows an execution platform for a TSMC
5.1. SYSTEM MODEL
53
device defined as a MARTE model.
5.1.1
Modelling a Functional Behaviour of a System
To develop secure networked embedded systems, we employ the modelbased engineering method SPACE [3] described in Section 2.2. Recall that
applications are composed of building blocks that can specify a local behaviour as well the interaction between several distributed entities. Similar to functional building blocks, security mechanisms can be expressed
as self-contained building blocks. These SPACE building blocks that describe functionality of security mechanisms are concrete SBBs introduced
in Section 4.1.1. Note that as a result of applying the SPACE method (i.e.
building a system as composition of reusable building blocks) the models
used in different scenarios can share a lot of commonalities.
«system» Metering Data Transfer
tsmc
operator_server
start
c: Collector
data:
HashMap
start
start
t: Transfer Handler
dataIn:
dataOut:
HashMap HashMap
ack:
boolean
db: Db Handler
store:
HashMap
ack:
boolean
Figure 5.2: Functional system model of the measurement transfer scenario
Figure 5.2 depicts the measurement transfer scenario modelled in SPACE.
It is a UML activity consisting of two partitions, namely tsmc and operator server, that model the respective entities in our case study. The activity
is composed of three building blocks that are connected with some “glue
logic” through pins on their frames. The building block c: Collector models
periodic collection of measurement data from TSMs handled by a TSMC.
The block db : Db Handler encapsulates the behaviour to store the data in a
database of the operator. The block t: Transfer Handler manages the communication between the two components that, as will be described later,
buffer the data, send it, and resend it in the case of a negative acknowledgement. The block c and db are local blocks since they specify the local
behaviour of an entity. In contrast, the block t is a collaborative block as
it also describes interaction between two entities. The three blocks (c, db,
and t), further, refer to activity diagrams that define their detailed internal
behaviour as exemplified for the block t in Figure 5.3.
The Petri net-like semantics of the activities models behaviour as control
and object flows of tokens between the nodes of an activity via its edges.
54
CHAPTER 5. APPLICATION OF THE DOMAIN-SPECIFIC
SECURITY KNOWLEDGE
When a system starts, a token flows from each of the initial nodes (•) following the edges of the activity. In the application in Figure 5.2, all three inner
blocks are started in the initial node. Then, periodically the collector block
emits a token containing an object of type HashMap through its pin data.
This object maps TSM identifiers to measurement values at a particular
time. As depicted by the outgoing edge from pin data of block c, the object
is forwarded to block t and further to block r: Reactive Buffer via its pin add
(see Figure 5.3). This buffering block, which is taken from one of the Arctis
libraries, is used to buffer measurement data that may arrive when other
data is being sent but not yet acknowledged. If data is received when the
buffer is empty, it is emitted immediately; otherwise, it is buffered. The pin
next is used to get subsequent data. Following the outgoing edge of the pin
out of the block r, a copy of measurement data is stored temporarily in variable temp by the operation set temp. Thereafter, the token flows through
the merge node () and data is sent to the other entity as illustrated by
the edge crossing the partition border. In the receiver partition, the data
is forwarded out of the block which, according to Figure 5.2, is stored in a
database by the block db.
Transfer Handler
sender
temp: HashMap
receiver
r: Reactive Buffer
start
dataIn:
HashMap
init
out:
HashMap
set temp
add:
HashMap
empty
dataOut:
HashMap
next
get temp
false
delete
true
ack:
boolean
Figure 5.3: Detailed behaviour of the transfer handler block
The block db: Db Handler in Figure 5.2 will emit a token via the pin
ack containing either a positive or a negative acknowledgement. A positive
acknowledge corresponds to a successful transfer of measurement data, while
a negative acknowledgement is issued in the case the received measurements
have not passed the validation test executed by the db block. Thus, the token
emitted via the pin ack flows further inside the block t and, as depicted in
Figure 5.3, reaches the decision node (). A positive acknowledgement leads
the token flows through the outgoing edge labelled with true. Thereafter,
the operation delete, that removes the data stored in the variable temp, is
called and subsequent data, if any, is retrieved from the buffer r. A negative
acknowledgement moves the token through the edge labelled with false. In
this case, the previously sent data is retrieved from the variable temp and
5.1. SYSTEM MODEL
55
sent again.
5.1.2
Modelling an Execution Platform
A platform model of a TSMC device for our scenario is depicted in Figure 5.4. We use UML class models annotated with stereotypes of the Hardware Resource Modelling (HRM) package of the MARTE profile (see Section 2.2). The modelling is done in the MagicDraw tool [9].
Figure 5.4: Platform model for a TSMC device
The main component of a TSMC platform is an OMPA3530 board [81].
This board includes computing elements (TMS320C64x+ DSP and ARM
Cortex-A8), storage elements (NAND Flash and LPDDR), communication
interfaces (I2C, SDIO, and 10/100Mbps NIC), a daughter card, and a LCD
display. The daughter card is connected to the ADE7758 sensor via a Serial
Peripheral Interface (SPI) bus. Finally, 10/100Mbps NIC is used to connect
a TSMC to a communication channel (LAN). In the following, we briefly
explain stereotypes used from the MARTE HRM package for modelling of
a TSMC platform.
The HwResource is the most general term of the HRM that represents
any hardware unit. The HwComputingResource denotes a computation unit,
where the HwProcessor is its refinement that represents a processor or microcontroller unit. Similar, the HwMemory is an abstract memory unit that
denotes a given amount of memory, where the HwRAM refines it to repre-
56
CHAPTER 5. APPLICATION OF THE DOMAIN-SPECIFIC
SECURITY KNOWLEDGE
sent a unit of the random access memory. The HwMedia is a central term
that represents a communication resource used to transfer data over some
channel. In our example, we use the HwBus stereotype that models a wired
channel. The HwEndPoint indicates that annotated components are connection points. Finally, the HwDevice stereotype refers to an entity that
interfaces with an external environment.
5.2
Association with DSSMs
The goal of the step Association with DSSMs in the proposed process is
twofold: (1) a DSSM that is relevant for a system under development is
identified and selected; (2) bounds of a system (its functional model), where
the knowledge captured by a selected DSSM should be applied, are established. Figure 5.5 depicts an interface of the SEED MagicDraw plug-in
developed to support this step. We exemplify the Association with DSSMs
step with our use case of the measurements transfer scenario.
Figure 5.5: Association of the selected DSSM with the system elements (the
user interface)
Since the case study is a smart metering application, an embedded system engineer selects the metering DSSM from the library of DSSMs (i.e.
step (1)). Hence, the association is based on a matching of the system and
security domains. Thereafter, those parts of a system containing data to be
protected are identified (i.e. step (2)). In this thesis, we discuss the protection of the metering data that, in the functional system model from Figure 5.2, flows from the block c: Collector in the TSMC to the db: Db Handler
in the operator server. Thus, these two blocks are the starting respective
end points of the object flow to be protected. Therefore, the identifiers of
these two blocks are assigned to the fields StartAnchor and FinishAnchor
respectively as it is shown in Figure 5.5.
5.3. ASSET ELICITATION AND SEARCH FOR SECURITY
PROPERTIES
5.3
57
Asset Elicitation and Search for Security
Properties
In this section, we present the asset elicitation technique along with the
search for security properties method. The developed asset elicitation technique consists of two steps. The first step inspects a functional model identifying present assets. This step uses a set of rules elaborated for traversing
a functional model and the information about assets relevant for a certain
domain obtained from an associated DSSM. Thereafter, we retrieve from the
enriched security ontology a set of security properties associated with the
identified assets through the DSSM. Further, we proceed with the second
step of the asset elicitation technique. This step utilises a platform model
of a system and information about their potential threats to identify vulnerable assets. The output, when the asset elicitation technique is applied,
is a set of assets and security properties that associate security goals and
defence strategies with the identified set of assets.
In Section 5.3.1, we define a set of rules that allow identifying assets
to be protected within a functional system model. Section 5.3.2 shows a
method to retrieve a set of security properties relevant for the identified
assets. Then, we explain the developed approach to refine a set of identified
assets and corresponding security properties utilising the platform description information. This method is presented in Section 5.3.3.
5.3.1
Asset Elicitation on a Functional Model
The first step of the proposed asset elicitation technique is to identify an
initial set of security assets utilising a functional model of a system. This
identification is implemented as rule-based classification of assets developed
in this work. Thus, the rule-based classification is a method that allows identifying assets within a functional model of a system and their matching to
the classes defined in the core security ontology introduced in Section 4.1.1.
In particular, the considered classes are “data stationary” and “data in transit”.
The rule-based classification is realised as application of the rules R1
- R7 to collaborative-based Arctis models. These rules are presented in
Figure 5.6. We have implemented this functionality in a tool called asset
analyser. Afterwards, an engineer complements this classification according
to an associated DSSM. However, it is worth noting that the latter task can
potentially be automated given a system modelling language closely tailored
to a domain (i.e. a domain-specific language). We now proceed to explain
our rules (see Figure 5.6) and their application logic (see Figure 5.8).
According to the SPACE semantics [39], an activity is a directed graph
g with a set of activity nodes V and connecting edges E, i.e g = (V, E).
Figure 5.6 presents the seven identification rules R1 to R7. In the rules, we
use the following functions:
58
CHAPTER 5. APPLICATION OF THE DOMAIN-SPECIFIC
SECURITY KNOWLEDGE
• Two functions mapping an activity node and edge to their particular
types, i.e. kindV : V → KV and kindE : E → KE , where KV =
{operation, merge, join, f ork, decision, local, collaboration, other}
and KE = {object, control}.
• The set ON of all object nodes of a given activity, i.e. the data stored
in the system and transported within the data flow tokens.
• Two functions mapping a given node to the set of its incoming and
outgoing edges, i.e. inE : V → 2E and outE : V → 2E .
• Two functions returning an object flowing to (reps. from) a given node
through an edge, i.e. inO : E × V → ON and outO : V × E → ON .
• A function mapping a node to a set of partitions to which it belongs,
i.e. part : V → 2P , where P is a set of all partitions of a given activity
diagram.
• Two functions that return the source and target nodes of a given edge,
i.e. source : E → V and target : E → V respectively.
• A function mapping a merge node and the set of its incoming object
edges to its outgoing object, i.e. f M erge : V × 2E → ON . Likewise,
we define function f Join for a join node. According to the SPACE
semantics, only one outgoing edge is allowed for merge and join nodes
(see the rule OUT1 in [39]).
• A function mapping a fork node, its incoming object edge, and one of
its outgoing edges to an object flowing through this outgoing edge, i.e.
f F ork : V × 2E × E → ON . Likewise, we define function f Decision
for a decision node. For the sake of generality, we allow that the
second argument of f F ork and f Decision is a set of edges. However,
according to the SPACE semantics [39], fork and decision nodes can
have only a single incoming edge (see the rule IN3 in [39]).
• A function mapping a given asset to a class from the core security
ontology, i.e. class : A → KA , where KA = {transit, stationary} and
A is the set of assets constructed from elements of the set ON . In
particular, each asset is uniquely identified as a tuple hON, V, Ei.
• A function that takes a certain activity (i.e. a graph) g ∈ G and
returns a set of assets elicited within this activity g, i.e. f a : G → 2A ,
where G is a set of activities.
5.3. ASSET ELICITATION AND SEARCH FOR SECURITY
PROPERTIES
R1:
q ∈ V, e ∈ inE (q), kindE (e) = object,
kindV (q) ∈ {operation, local, collaboration}
∃asset : asset = hinO (e, q), q, ei,
class(asset) = stationary, f a(g) = f a(g) ∪ asset
R2:
q ∈ V, e ∈ outE (q), kindE (e) = object,
kindV (q) ∈ {operation, local, collaboration}
∃asset : asset = houtO (q, e), q, ei,
class(asset) = stationary, f a(g) = f a(g) ∪ asset
R3:
e ∈ E, kindE (e) = object, |part(source(e))| = |part(target(e))| = 1,
part(source(e)) ∩ part(target(e)) = ∅, q ∈ V,
kindV (q) ∈ {operation, local}, e ∈ outE (q)
∃asset : asset = houtO (q, e), q, ei,
class(asset) = transit, f a(g) = f a(g) ∪ asset
R4:
e ∈ E, kindE (e) = object, |part(source(e))| = |part(target(e))| = 1,
part(source(e)) ∩ part(target(e)) = ∅, m ∈ V, kindV (m) = merge,
e ∈ outE (m), q ∈ V, inE (m) ∩ outE (q) 6= ∅, kindV (q) ∈ KV \ {other}
∃asset : asset = hf M erge(m, inE (m)), m, ei,
class(asset) = transit, f a(g) = f a(g) ∪ asset
R5:
e ∈ E, kindE (e) = object, |part(source(e))| = |part(target(e))| = 1,
part(source(e)) ∩ part(target(e)) = ∅, d ∈ V, kindV (d) = decision,
e ∈ outE (d), q ∈ V, inE (d) ∩ outE (q) 6= ∅, kindV (q) ∈ KV \ {other}
∃asset : asset = hf Decision(d, inE (d), e), d, ei,
class(asset) = transit, f a(g) = f a(g) ∪ asset
R6:
e ∈ E, kindE (e) = object, |part(source(e))| = |part(target(e))| = 1,
part(source(e)) ∩ part(target(e)) = ∅, j ∈ V, kindV (j) = join,
e ∈ outE (j), q ∈ V, inE (j) ∩ outE (q) 6= ∅, kindV (q) ∈ KV \ {other}
∃assetasset = hf Join(j, inE (j)), j, ei,
class(asset) = transit, f a(g) = f a(g) ∪ asset
R7:
e ∈ E, kindE (e) = object, |part(source(e))| = |part(target(e))| = 1,
part(source(e)) ∩ part(target(e)) = ∅, f ∈ V, kindV (f ) = f ork,
e ∈ outE (f ), q ∈ V, inE (f ) ∩ outE (q) 6= ∅, kindV (q) ∈ KV \ {other}
∃asset : asset = hf F ork(f, inE (f ), e), f, ei,
class(asset) = transit, f a(g) = f a(g) ∪ asset
59
Figure 5.6: Rules of the asset identification technique
The asset elicitation rules defined in Figure 5.6 form a set of assets
for an activity g that is accessed through f a(g). Thus, each time a rule
60
CHAPTER 5. APPLICATION OF THE DOMAIN-SPECIFIC
SECURITY KNOWLEDGE
identifies an asset, i.e. asset, this asset is added into a set of elicited assets
for g, i.e. f a(g) = f a(g) ∪ asset. We require that initially (i.e. before
the elicitation process starts) the set of assets for an activity g is an empty
set, i.e. f a(g) = ∅. We continue describing in more detail each rule from
Figure 5.6 and their application logic.
The rules R1 and R2 express that for an operation, local, or collaboration node q a stationary data asset (i.e. asset) is observed if this node has
an incoming (R1) resp. outgoing (R2) edge e of the kind object. The rules
R3 to R7 are applied to an object flow crossing a border of two partitions,
which corresponds to the data in transit concept. R3 describes the case that
an object leaves an operation node and goes directly to another partition.
By the rules R4 to R7, we cover the cases that a flow passes a merge, join,
decision, or fork node before crossing a partition border. Figures. 5.7.(a) to
5.7.(e) illustrate the cases of R3 to R7 respectively.
(a) Simple case (R3)
(b) Merge case (R4)
(d) Join case (R6)
(e) Fork case (R7)
(c) Decision case (R5)
Figure 5.7: Illustration of the rules
The application of the rules R1 - R7 to a functional system model is
outlined by the traverseBlocks and traverseEdges functions depicted in
Figure 5.8. Recall that each activity (i.e. graph) g is represented by a pair
of nodes and edges (V, E). First, the function traverseBlocks traverses
all nodes V and applies the rules R1 and R2. For example, an application
of this function to the model in Figure 5.2 will identify six data stationary
assets, which are data, dataIn, dataOut, store, and two ack s.
Thereafter, if a considered node is a local block, the traverseBlocks
function is recursively applied to its internal behaviour. Likewise, a collaborative block invokes both the traverseBlocks and traverseEdges functions. For example, this is the case for the analysis of the t block in Figure 5.3. Here, the function traverseEdges applies the R4 rule to the merge
node before the crossing edge from partition sender to receiver. For the decision node before the crossing edges in the opposite direction, the rule R5
is used. As a result, four data in transit assets are elicited: two ack assets
incoming to the get and delete nodes; two temp assets outgoing from the
get and set nodes.
Table 5.1 summarises the results of applying the rules to our measurement transfer scenario described in Figure 5.2. For those assets that have
5.3. ASSET ELICITATION AND SEARCH FOR SECURITY
PROPERTIES
61
function traverseBlocks (Activity g)
for all v in V do
R1 − R2
if kindV (v) = local then
traverseBlocks(v)
end if
if kindV (v) = collaboration then
traverseEdges(v),
traverseBlocks(v)
end if
end for
end traverseBlocks
function traverseEdges (Activity g)
for all e in E do
R3 − R7
end for
end traverseEdges
Figure 5.8: Functions to traverse a functional system model
duplicating names (i.e. ack and temp), we have added their location information in brackets.
Table 5.1: Results of eliciting assets from the functional model
Asset
data, dataIn, dataOut, store, out,
add, two temp (to and from the set
operation), temp (from the get operation),
ack (from the db block), ack (to
the t blocks)
temp (from the merge node)
ack (that goes from the decision
node to the operations get), ack
(that goes from the decision node
to the operations delete)
DSSM classification
StoredMeasurement (Data Stationary)
Not an asset (Data Stationary)
CollectorToServerMsr (Data in
Transit)
Not an asset (Data in Transit)
Figure 5.9 demonstrates the interface of the developed asset analyser
tool when it is applied to the scenario of the MixedMode use case from
the Figure 5.2. The main output of this tool is a table where each row
represents an identified asset. First four columns contain information elicited
by the algorithm (the functions and rules) presented in Figure 5.7, namely
the name of an asset, its source (the NodeId | EdgeId column), and its
class according to the core security ontology (the Ontology classification
62
CHAPTER 5. APPLICATION OF THE DOMAIN-SPECIFIC
SECURITY KNOWLEDGE
column). Classes in the column DSSM classification are assigned by an
engineer among possible alternative classes captured in an associated DSSM.
That is the metering DSSM for this example where the alternative classes are
StoredMeasurement for data stationary assets, and CollectorToServerMsr
and SensorToMeterMsr for data in transit assets (see Figure 4.4).
Figure 5.9: Asset analyser tool (the user interface)
5.3.2
Search for Security Properties
Once the classification of the elicited assets is known a set of corresponding
security properties can be retrieved from the enriched security ontology.
Recall that the security property concept is defined in the core security
ontology as the triple of asset, security goal, and defence strategy. These
triples are generated when a DSSM (i.e. an object diagram) is transformed
into a set of axioms that are added into the enriched security ontology. Thus,
security properties which are available for a given asset can be accessed in
the enriched security ontology executing the following query:
SecurityProperty and has value [Asset]
This query is formulated as an expression written in the Manchester
syntax [82]. The Manchester syntax uses the standard description logic notation to specify restrictions (e.g. ∃, ∀, ∈) replacing them with the English
5.3. ASSET ELICITATION AND SEARCH FOR SECURITY
PROPERTIES
63
language keywords (e.g. some, only, value respectively). All boolean constructs (i.e. u, t, ¬) are also replaced by the English language keywords (i.e.
and, or, not respectively). The rest of the words in the query defined above
are names of the corresponding concepts and relations from the core security ontology depicted in Figure 4.2. The values in square brackets denote
parameters of the query. We employ the HermiT reasoner [83] to execute
this query.
For example, for those assets that are classified as CollectorToServerMsr
and StoredMeasurement (see Table 5.1) the following set of security properties is retrieved:
[CollectorToServerMsr, Confidentiality, Prevention]
[CollectorToServerMsr, Integrity, Detection]
[CollectorToServerMsr, Authentication, Detection]
[StoredMeasurement, Confidentiality, Prevention]
[StoredMeasurement, Integrity, Prevention]
5.3.3
Asset Elicitation Utilising a Platform Model
In this section, we explain the second step of the asset elicitation technique.
In particular, we present a method that refines the results of the rule-based
classification (introduced in Section 5.3.1) by utilising a platform model of
a system.
This method is applied when the initial set of assets and related security
properties are identified inspecting a functional model. Three steps that
compose this method are shown in Figure 5.10. These steps allow identifying
which security properties must be considered as those security properties to
be satisfied given a platform model. Thus, this extending method allows
focusing on a set of relevant assets refining the results from the previous
steps (see Sections 5.3.1 and 5.3.2). We use the platform model selected for
a TSMC block presented in Section 5.1.2.
Figure 5.10: Asset elicitation technique utilising a platform model
At the step 1, initially elicited assets are associated with available platform resources, e.g. communication, computing, and storage components.
64
CHAPTER 5. APPLICATION OF THE DOMAIN-SPECIFIC
SECURITY KNOWLEDGE
In general, any platform components that are involved in operations with
assets should be mentioned during this association. In particular, we provide
the following basic guideline:
1. Associate each data stationary asset with a computing unit that operates on it (i.e. components annotated with the HwProcessor stereotype
and its subclasses) and a memory unit that stores it (i.e. components
annotated with the HwMemory stereotype and its subclasses).
2. Associate each data in transit asset with a communication channel
that is used to transmit this asset (i.e. components annotated with
the HwMedia stereotype and its subclasses) and with two interfaces
on the sender and receiver ends (i.e. the HwEndPoint stereotype).
3. Associate each data stationary asset with some resource (i.e. components annotated with the HwResource or HwDevice stereotypes) that
contains computing and memory units, which operate with the asset
and store it respectively.
4. Associate each data in transit asset with some resource (i.e. components annotated with the HwResource or HwDevice stereotypes) that
contains sender and receiver interfaces and a communication channel,
which are involved in transmission of the asset.
Table 5.2 demonstrates association of the assets elicited in Section 5.3.1
with the components of the TSMC platform depicted in Figure 5.4. The
data asset is associated with the ADE7758 component (the third rule of
our guideline). All other data stationary assets (row 2 and 3 in Table 5.2)
are associated with the NAND Flash or LPDDR components (i.e. memory
units) and the ARM Cortex-A8 component (i.e. computing unit) as it is
instructed by the first rule of the guideline. Finally, following the second
rule, the data in transit assets (row 4 in Table 5.2) are associated with
the 10/100Mbsp NIC components of the TSMC device and of the operator
server host (not shown in Figure 5.4) and onto the LAN, which is used as a
communication channel.
Step 2 from Figure 5.10 involves analysis of existing (known) threats for
components of the used execution platform. In general, this task may imply
collaboration between a security expert and a system engineer, but the use
of threat repositories can facilitate this task. For example, an engineer can
query an ontology like one presented by Herzog et al. [67] potentially extended with other expert knowledge about existing threats. In our case, we
use knowledge acquired within the SecFutur project employing the CORAS
method [84], combined with the results of the threat analysis for embedded
system platforms published by Ravi et al. [85]. Table 5.3 shows the identified
threats and potentially violated security goals.
The last step of the asset elicitation technique (i.e. step 3 in Figure 5.10),
automatically identifies a set of security properties to be satisfied. The
5.3. ASSET ELICITATION AND SEARCH FOR SECURITY
PROPERTIES
65
Table 5.2: Association of the assets with the platform components
Asset
data
dataIn,
dataOut,
out, add
two temp (to and
from the set operation), temp (from
the get operation)
temp (from the
merger node)
Classification
StoredMeasurement
StoredMeasurement
StoredMeasurement
CollectorToServerMsr
Association
ADE7758
[NAND Flash, ARM
Cortex-A8]
[LPDDR,
ARM
Cortex-A8]
[OMAP3530:
10/100Mbsp
NIC,
LAN,
DBHost:
10/100Mbsp NIC]
Table 5.3: Threats and violated security goals
Platform
component
NAND Flash
LAN
Threat
injection
eavesdropping
Violated
security
goal
integrity
confidentiality
identification algorithm is implemented as follows. The security goal of each
earlier retrieved security property (explained in Section 5.3.1) is compared
to the security goal violated by the threat (see Table 5.3), which targets
a platform component associated with an asset of the considered security
property (see Table 5.2). Now, if the security goal of the security property is
equal to the security goal violated by the threat, then this security property
is added to the set of security properties to be satisfied. In our scenario, we
have extracted the following set of security properties to be satisfied:
• SP1 : [StoredMeasurement, Integrity, Prevention]
• SP2 : [CollectorToServerMsr, Confidentiality, Prevention]
SP1 is formulated due to the knowledge about the existence of an injection threat that violates integrity of the NAND Flash component (see
Table 5.3) used in association of the StoredMeasurement asset (see Table
5.2). Similarly, SP2 is identified due to the presence of an eavesdropping
threat that violates confidentiality of the LAN component (see Table 5.3),
which is used in association of the CollectorToServerMsr asset (see Table
5.2).
CHAPTER 5. APPLICATION OF THE DOMAIN-SPECIFIC
SECURITY KNOWLEDGE
66
5.4
Search for Concrete SBBs
At this step, a set of identified security properties to be satisfied are used to
find a set of concrete SBBs. They are, for example, the SP1 and SP2 security
properties for the metering scenario. Concrete SBBs for a particular domain
and security properties described within an associated DSSM are retrieved
from the enriched security ontology executing the following query1 :
ConcreteSBB and (satisfies value [SecurityProperty])
and implements some (AbstractSBB and belongsTo value [Domain])
Execution of the above query for SP1 and SP2 retrieves two concrete
SBBs for the StoredMeasurement asset, namely SecFutur secure storage and
SecFutur TPM seal 2 and two concrete SBBs for the CollectorToServerMsr
asset, namely AES and DES.
Due to the existence of several alternatives to secure a considered scenario an engineer needs to carry out an additional analysis. This is the case
of the measurement transfer scenario above. For example, this analysis may
include investigation of the resource overhead introduced by concrete SBBs.
Our work contributes to one kind of such analyses proposing a technique
that inspects and matches platform constraints of candidate concrete SBBs
and constraints of an execution platform model adopted for a design of an
embedded system under development. Recall that platform constraints for
concrete SBBs are obtained as results of performance evaluation of these security solutions and captured by corresponding PERs that are consequently
stored in the enriched evaluation ontology. This step is reflected in Figure 5.1 by the Compatibility-based selection of concrete SBBs and presented
in the following sections. Different types of (trade-off) analyses are also enabled by our contributions since each PER can be used to store other data
about results of performance evaluation of a concrete SBB.
Other possible criteria for selection of concrete SBBs could be, for example, their effect on the original functionality of a system and the cost of the
concrete SBBs’ integration. Formalisation of these needs goes beyond the
contributions of this thesis. However, our process accounts this necessity as
the Analysis&Integration of concrete SBBs step in Figure 5.1.
For the illustration purposes, let us assume that a system engineer decides to use the AES concrete SBB to satisfy SP2 . As a result, the system
engineer is directed towards a pair of Arctis blocks, namely AES Encryption
and AES Decryption.
As mentioned in Section 4.1.1, integrating a concrete SBB may create
new assets as expressed by the creates and requires relations in the core
security ontology. Hence, a further search of concrete SBBs, i.e. a recursive
application of the above mentioned query, is needed to fulfil the security
1 The
query is written in the Manchester syntax [82]
concrete SBBs that start with the suffix “SecFutur” are developed within the
SecFutur [10] European project.
2 The
5.4. SEARCH FOR CONCRETE SBBS
67
goals required for these new assets. For this query, the security property
is composed of the created asset and its required security goal, namely the
requiredGoal attribute in Figure 4.3. The search is done within the domain
specified by the externalDSSM attribute in Figure 4.3. As a result, search
of concrete SBBs will continue until all security goals of all created assets
are fulfilled. Alternatively, this search will lead to an empty set of SBBs
indicating that a vulnerability remains in terms of an unprotected asset. In
other words, the search for concrete SBBs results in building alternative sets
of concrete SBBs. Each set satisfies a considered security property.
Note that such an approach can lead to a cycle since an ontology reasoner
exhaustively searches for any concrete SBB in a DSSM that satisfies the
security property. For example, the query can return the same concrete
SBB that has invoked it if this concrete SBB satisfies the same security
property required by its created asset. To handle such occurrences, we have
developed an algorithm that detects and resolves such cycle conditions.
This algorithm is based on constructing a directed graph while the search
for concrete SBBs goes on:
• Create a node for each found concrete SBB and asset.
• Create a directed edge from a concrete SBB to an asset if the concrete
SBB creates the asset.
• Create a directed edge from an asset to a concrete SBB if the concrete
SBB protects the asset.
Then, we use a cycle detection algorithm (one based on identification of
backward edges during execution the DFS (Depth-first search) algorithm [86])
to detect cycles in the constructed graph. The search continues if there are
still alternative paths ignoring (by removing) the detected cycles. Otherwise, the engineer is notified of the remaining unprotected asset.
A nice property of the previously selected Arctis blocks (i.e. the AES
pair) is that they already contain a protection of the keys, i.e. new assets
are not created. Thus, we can directly continue with the integration of
these blocks. The integration of the AES blocks (encryption and decryption) is easily done by arranging their instances before and after the block
t: Transfer Handler as shown in Figure 5.11.
The functionality described above is implemented as a tool called concrete SBB searcher. The user interface of this tool is depicted in Figure 5.12.
In this tool, the list “Security properties” contains a list of relevant security
properties for a selected asset (e.g. CollectorToServerMsr). These properties
are represented in a form of tuples, i.e. [asset, security goal, defence
strategy].
The bottom part of the GUI screen shot in Figure 5.12 contains a tree
representation of found sets of concrete SBBs. The root item denotes the
selected for the search security property. For this example, we use the
earlier retrieved security property SP2 that is [CollectorToServerMsr,
CHAPTER 5. APPLICATION OF THE DOMAIN-SPECIFIC
SECURITY KNOWLEDGE
68
«system» Secure Metering Data Transfer
tsmc
operator_server
start
c: Collector
data:
HashMap
start
t: Transfer Handler
dataOut:
Ciphertext
plainIn:
HashMap
e: AES Encryption
cipherOut:
Ciphertext
dataIn:
Ciphertext
ack:
boolean
d: AES Decryption
CipherIn:
Ciphertext
plainOut:
HashMap
store:
start
HashMap
db: Db Handler
ack:
boolean
Figure 5.11: Adapted model protecting the transfer of measurement data
Confidentiality, Prevention]. The root item expands to several items
that have the following format:
[asset]
requires [security goal] : [concrete SBB]
In this string, [asset] and [security goal] are elements from the selected for
the search security property, i.e. CollectorToServerMsr and Confidentiality
respectively from SP2 . Then, [concrete SBB] denotes a retrieved concrete
SBB that satisfies this security property. In our example, they are OpenSSL,
DES, and AES implementations. Note that the AES SBB has a special icon,
i.e. “CA” (Created Assets). This icon denotes that the AES SBB, in turn,
creates some assets to be protected. An engineer needs to expand this item,
to see the created assets, their required security goals, and available concrete SBBs. Thus, a system engineer can see all possible alternative sets of
concrete SBBs that together can be used to protect a considered asset.
5.5
Compatibility-based Selection of Concrete
SBBs
The last step that we describe in this thesis is the Compatibility-based selection of concrete SBBs 3 . It is supported by the method for model-based
compatibility analysis developed in this work. We begin with introducing
a reader into the context in Section 5.5.1. In particular, we recall some
3 In
this section, the term SBB can be understood as the term RBB used in Section 4.1.2
5.5. COMPATIBILITY-BASED SELECTION OF CONCRETE
SBBS
69
Figure 5.12: Concrete SBB searcher tool (the user interface)
concepts introduced earlier in this thesis and outline basics of the proposed
method. Thereafter, Sections 5.5.2 – 5.5.4 explain the method for modelbased compatibility analysis.
5.5.1
Introduction into the Compatibility Analysis
Adding a new feature to a system always comes with resource claims. In
Section 4.1.2, we introduced the PER (Performance Evaluation Record)
concepts that enables capturing results of performance analysis of SBBs
conducted by domain security experts. Among other information, PERs
store data about resource footprint and quality of extra-functional properties
provided by concrete SBBs. Thus, an embedded system engineer can use
this information already at the early design phase increasing the efficiency of
an embedded system design process. Hence, the PER concepts contributes
to selection of a suitable set of concrete SBBs by enabling the sensitivity
and trade-off analyses at early phases.
Another useful and significant input to the design process is knowledge
about platform-specific constraints of concrete SBBs. These constraints
originate from the fact that SBBs (and just RBBs) for embedded systems
are often optimised to exploit a particular feature of hardware components
on which they are implemented. Thus, they can provide good quality of
extra-functional properties (i.e. level of security) while consuming a small
amount of limited resources. In our studies, we argue that these constraints
also need to be documented and accounted in order to support integration
of concrete SBBs into embedded systems. For example, Preissig [76] reports
the results of performance analysis of the Data Encryption Standard (DES)
implementation optimised for the memory architecture of the used chip.
Similarly, other implementations of DES rely on the presence of a certain
instruction set to accelerate permutation operations [6]. Therefore, this information is included as a part of a PER using the gemRequiredComponent
CHAPTER 5. APPLICATION OF THE DOMAIN-SPECIFIC
SECURITY KNOWLEDGE
70
stereotype from the GEM profile explained in Section 4.1.2.
Consequently, each PER is transformed into an ontology called enriched
evaluation ontology that allows storing and structuring this field knowledge.
As a result, a variety of information can be retrieved from this ontology
defining appropriate queries for the ontology, for example:
• Retrieve values of relevant performance metrics for a certain SBB.
• Retrieve a set of SBBs of a particular domain that satisfy required
values w.r.t. certain performance metrics.
• Retrieve a set of SBBs, for which the platform constraints are compatible with a platform adopted for an embedded system under development.
Queries like the first two can be directly implemented as SPARQL queries
[60]. However, the task of compatibility analysis, i.e. the third query in the
list above, requires more sophisticated support. Consequently, we develop
such a support as a method that implements model-based compatibility analysis.
This analysis allows automatically accounting for platform constraints
while selecting a set of SBBs to be used for a system design. An extrafunctional domain expert (in our study, a security expert) provides these
constraints by annotating elements of an evaluation platform (i.e. a MARTE
model) with the gemRequiredComponent stereotype (see Figure 4.8).
The core of our method is a set of ontologies and SPARQL queries designed to infer whether concrete SBBs and an adopted platform for the
embedded system are compatible (i.e. whether the formulated platform constraints for a concrete SBB fits platform declarations of the system being
configured). The SEED MagicDraw plug-in implements this functionality
to support the use of the compatibility analysis.
In the following, Section 5.5.2 explains the developed hierarchy of ontologies and Section 5.5.3 defines the notion of compatibility. Section 5.5.4
shows results of scalability and performance estimations for our approach.
5.5.2
Ontologies for Compatibility Analysis
Figure 5.13 depicts the developed set of ontologies. These ontologies are
organised in three layers: expert, vendor, and engineer layers. The name of
each layer denotes its main actor. These ontologies are related to each other
through the import, use, and refer to relations.
Expert Layer
Ontologies of the Expert layer are created and maintained by experts of the
embedded and security (or any other extra-functional properties) domains.
It contains three ontologies. The first two ontologies are obtained from the
5.5. COMPATIBILITY-BASED SELECTION OF CONCRETE
SBBS
71
Figure 5.13: Ontologies for compatibility analysis
transformation of MARTE packages dedicated to platform resource descriptions. The third ontology is the refinement of the core evaluation ontology
for the security domain as it is already explained in Section 4.1.2.
Techniques to transform UML class models into ontologies are studied
and presented by several researchers, e.g. by Hermida et al. [87] and Xu et
al. [88]. Similar to their works, we identify the mapping needed to transform
MARTE packages. Some basic mapping rules that we apply in our work may
be summarised as follows:
• Each MARTE stereotype is represented as an OWL class.
• Each tag is represented as an OWL object or data property, where
the domain is the stereotype that owns the tag and the range is the
type of the tag. We create an OWL object property if the type of the
tag is equal to another stereotype, which can not be replaced with a
basic type defined in XSD [89] (e.g. float, integer, or string). Thus,
we create an OWL data property if the type of the corresponding tag
is a basic XSD type.
• An enumeration is represented as a class with a predefined set of individuals.
• The generalisation relations of the MARTE profile are represented as
sub-class relations in the ontology, i.e. the “is-a” relation.
• The composition relations are represented as the part-whole object
properties [90], i.e. the “hasPart” relation.
• The named associations are represented as OWL object properties
with the corresponding name, e.g. the “hasConnected” relation.
We avoid using the Ontology UML profile [91] that allows designing ontologies as UML models since this requires in-depth understanding of the
underlying ontologies from an engineer. Our goal is to exploit advantages
72
CHAPTER 5. APPLICATION OF THE DOMAIN-SPECIFIC
SECURITY KNOWLEDGE
of ontology technologies (e.g. querying services), but to allow an engineer
to operate only with terms of a considered extra-functional domain.
We proceed to explain the remaining two ontologies that build the expert
layer, i.e. NFPType ontology and Resource ontology. The third, Security
evaluation ontology, was already discussed in Section 4.1.2.
The NFPType ontology of the expert layer contains a set of types and
their relations needed to characterise a piece of hardware/software component, e.g. data rate (Mbps, Kbps, etc.) and frequency (Hz, KHz, etc.).
This ontology is derived from the MeasurementUnits, MARTE DataTypes,
and Basic NFP Types sub-packages of the MARTE Library package (chapter D.2 of the MARTE profile specification), which enable specification of
non-functional properties.
Note that types such as NFP Real and NFP Integer are not present in
our NFPType ontology since they can be sufficiently modelled as the XSD
types [89], i.e. xs:float and xs:integer respectively. Figure 5.14(a) depicts an
excerpt of the classification from this ontology.
(a) NFPType ontology
(b) Resource ontology
Figure 5.14: Classification levels for the developed ontologies (excerpts)
The Resource ontology contains those concepts needed to describe platform components and is derived from the MARTE HRM package described
in chapter 14.2 of the MARTE profile specification [28]. Some classification
levels of this ontology are depicted in Figure 5.14(b).
The core concept of our ontology is the HwResource class that denotes a
generic hardware entity. The HRM package differentiates two complementary views onto components, namely logical and physical. This structure is
flattened in our ontology since it can be inferred through the ontology view
approaches [92].
The logical view (Hw Logical model) consists of five sub-packages. The
core elements of these sub-packages are transformed into sub-classes of
the HwResource class. These classes are HwComputingResource, HwIsa,
and HwBranchPredictor from the Hw Computing sub-package; HwMemory and HwStorageManager from Hw Storage; HwCommunicationResource
from Hw Communication; HwTimingResource from Hw Timing; and HwDevice from Hw Device.
5.5. COMPATIBILITY-BASED SELECTION OF CONCRETE
SBBS
73
The physical view (Hw Physical model) contains two sub-packages, namely Hw Power and Hw Layout. The core concepts of Hw Power are represented as sub-classes of the HwResource class, i.e. HwPowerSupply and
HwCoolingSupply. The Hw Layout model contains only one element, i.e.
HwComponent. This stereotype is used to specify physical characteristics
(e.g. weight and area) and environmental conditions (e.g. temperature and
humidity) for a platform component. We treat it in a special way in our
ontology. Thus, we have encapsulated physical characteristics of a component into the “ComponentCharacteristics” OWL class and related it to the
HwResource class with the “hasCharacteristics” object property.
The composition relations defined in HRM are transformed into the “hasPart” object properties [90] (and its inverse property “isPartOf”). The
named association “connectTo” is modelled as the “hasConnected” object
property (and its inverse property “isConnectedTo”). Both these properties
have corresponding sub-properties, e.g. “hasCache” is a sub-property of the
“hasPart” property.
Vendor Layer
The Vendor layer in Figure 5.13 consists of vendor component ontologies,
where a vendor is a provider of platform components available for construction of execution platforms for embedded systems (e.g. Texas Instruments [93]). Thus, each ontology encapsulates description of platform components. The resource ontology of the expert layer serves as a description
language to describe these components.
In order to provide the description of available components, a vendor
needs to perform the following steps. First, a vendor uses the MagicDraw
tool [9] to create models of platform components. These models are UML
class diagrams annotated with stereotypes from the HRM package. Second,
a vendor launches the developed SEED MagicDraw plug-in to transform the
created MARTE models of the platform components into an ontology. The
user interface of this plug-in is depicted in Figure 5.15(a). We have used the
Java OWL API [62] and Acceleo [74] tool to implement this transformation.
Figure 5.15(a) depicts an interface of the developed plug-in. A vendor may
create a new ontology for described components or add these components
into an existing ontology.
Figure 5.4 from Section 5.1.2 depicts a valid model of the OMPA3530
board [81] provided by Texas Instruments.
Engineer Layer
The bottom layer in Figure 5.13 is the Engineer layer. At this level, system
and security engineers use the ontologies created at the higher levels (i.e. the
expert and vendor layers) to model the adopted platform for an embedded
systems and platforms used for evaluation of concrete SBBs respectively. In
74
CHAPTER 5. APPLICATION OF THE DOMAIN-SPECIFIC
SECURITY KNOWLEDGE
particular, an engineer uses vendor ontologies when certain vendor components required for the application are known, whereas the resource ontology
is suitable if such a component is not known or not present in vendor ontologies. Additionally, security engineers instantiate the security evaluation
ontology to capture the results of performance evaluation of a considered
SBB. Thus, security engineers create PERs where the concept gemPlatform
refers to the SBB platform specification (see Figure 5.13). These PERs are
further transformed into corresponding security evaluation record ontologies
as explained in Section 4.1.2.
In our smart metering devices case study from Section 2.4, TSMC devices
are built on the OMAP3530 board depicted in Figure 5.4. This component
will be already described and stored in the vendor ontology. Therefore, an
embedded system engineer needs to load the ontology and use this component as a part of the TSMC model. The developed SEED MagicDraw
plug-in supports this functionality.
In the measurement transfer scenario of our case study analysed in Section 5.3, the data transmitted between a TSMC and server (i.e. the CollectorToServer asset) must be protected against confidentiality threats as it is
indicated by the security property SP2 . Consequently, two concrete SBBs
that satisfy this security property have been found in the Metering DSSM
(see Section 5.4). They are the AES (Advanced Encryption Standard) [94]
and DES (Data Encryption Standard) [76] implementations provided by the
Texas Instruments [93]. For these implementations, the AES SBB requires
the use of the C64x+ processor, while the DES SBB requires the use of the
TMS320C6211 chip (see Figure 4.10 in Section 4.1.2).
In the next section, we explain how this architecture of different ontologies enables selection of concrete SBBs (or any RBBs) based on the defined
compatibility analysis.
5.5.3
Model-based Compatibility Analysis
We differentiate two types of the platform compatibility: logical and environmental. In the following, we explain each of the mentioned types and
exemplify some of them using the system and SBB models introduced in
the previous sections.
The notion of logical compatibility is based on the pairwise logical compatibility of a SBB and system platform components defined below.
Definition: Two components A and B are logically compatible if one of
the following holds: (a) A is identical with B ; (b) A has B as a part; (c) A
is a part of B ; (d) A can be connected to B ; (e) B can be connected to A;
(f) a disjunction of (b)-(e).
We employ the ontology querying services to automate a check of the above
definition. In particular, we use the ASK operator of SPARQL [60] that
5.5. COMPATIBILITY-BASED SELECTION OF CONCRETE
SBBS
75
returns a boolean value indicating whether a path that matches a query
pattern exists. For example, the query for case (b) where the relation “hasPart” is examined has the following form:
PREFIX hrm: [the ontology IRI]
ASK {?A hrm:hasPart ?B}
Queries for cases (c) – (e) have a similar structure replacing “hasPart” with
the “isPartOf”, “hasConnected”, and “isConnectedTo” object properties
respectively. To support the check of case (f), we use a special construct
defined by the SPARQL 1.1 syntax, i.e. the so called path properties [95].
It allows examining a path of an arbitrary length. Hence, the query for case
(f) replaces the “hasPart” property with a path expression: (hrm:hasPart
| hrm:isPartOf | hrm:connectedTo | hrm:hasConnected)*. In this expression, the symbol “|” denotes the “OR” operator, while the symbol “∗”
means that any number of occurrences is allowed.
In the query mentioned above, the ?A and ?B symbols denote variables.
They are replaced by components of a system platform and components of a
SBB platform (annotated with the “gemRequiredComponent” stereotype)
respectively. In our case study (see Section 5.5.2), these are OMAP3530
and C64x+ for the AES SBB, and OMAP3530 and TMS320C6211 for the
DES SBB. Since TMS320C64x+ has a C64x+ processor as its part, the
query returns true. In contrast, no path is found between TMS320C6211
and TMS320C64x+ for the DES SBB. Thus, we conclude that the particular
implementation of the DES algorithm is not logically compatible with the
current design of a system platform that is based on the OMAP3530 board,
while AES can be selected as a SBB to provide secure communication for a
TSMC device.
The definition for environmental compatibility is built upon the Env Condition data type from the HRM package (see Figure 14.72 from the MARTE
specifications [28]) which defines five types of environmental conditions:
temperature, humidity, vibration, shock, and altitude. An environmental
condition of each type has a value range. An engineer needs to annotate the components with the “HwComponent” stereotype and define the
“r Conditions” tag to assign environmental conditions to a component. We
use the following terms and functions to define environmental compatibility:
• K and U are sets of the environmental condition types and measurement units respectively, where K = {temperature, humidity, vibration,
shock, altitude} and U = {◦ C, %, m/s2 , g, m}.
• A set EN V CON D defined as I × U × K that describes each environmental condition as a tuple of a value interval (a set I ), a unit (from
the set U ), and a type (from the set K ).
• A function defining environmental conditions of a component, i.e.
76
CHAPTER 5. APPLICATION OF THE DOMAIN-SPECIFIC
SECURITY KNOWLEDGE
env cond : COM P → 2EN V
CON D
, where COM P is a set of compo-
nents.
• Projection functions extracting from an environmental condition the
corresponding type, i.e. kind : EN V CON D → K , unit, i.e. unit :
EN V CON D → U , and value interval, i.e. range : EN V CON D → I .
Given these terms and functions we introduce two other functions to
define the notion of environmental compatibility.
Definition: Environmental compatibility is a function env comp : COM P ×
COM P → {true, f alse}. A component A is environmentally compatible with
a component B if env comp(A, B) is evaluated to true as defined below:
env comp(A, B) , true if hi1 , u, ki, hi2 , u, ki | a ∈ env cond(A),
b ∈ env cond(B), k ∈ kind(a) ∩ kind(b), i1 = range(a), i2 = range(b), i1 ∩ i2 6=
∅ 6= ∅ or ¬∃k : ∀a ∈ env cond(A), ∀b ∈ env cond(B), k ∈ kind(a) ∩ kind(b)
The intuition is that environmental conditions of a platform component
A adopted for an embedded system and a component B required by an SBB
are compatible if corresponding interval values of environmental conditions
of the same type are overlapping. These components are also compatible if
there are no conditions of the same type defined for both components.
In addition, we define another function that specifies the environmental
conditions under which a pair of components can not operate (although each
could operate individually under respective conditions). We refer to such
environmental conditions as environmental constraints. This function is defined as env constr : COM P ×COM P → 2EN V CON D ×2EN V CON D as follows:
hi1 , u, ki, hi2 , u, ki | a ∈ env cond(A), b ∈ env cond(B),
env constr(A, B) ,
k ∈ kind(a) ∩ kind(b), i1 = range(a) \ range(b), i2 = range(b) \ range(a),
u = unit(a)
The intuition is that while each component might operate in an interval
that is a subset of its operational condition, its composition with another
component dictates that one component is prohibited from operating in
those environment conditions that are not within the range allowed by another component (and vice verse). In other words, environment conditions
of one component are constrained because of presence of another component. Therefore, environment constraints for each component are generated.
Alternatively, the presence of these constraints for components guides a system engineer to implement a mechanism (e.g. cooling system) that ensures
that the corresponding components sustain the environment constraints generated for another component (e.g. to keep within a given temperature
range). The SEED MagicDraw plug-in generates these environmental constraints automatically from given environment conditions attached to indi-
5.5. COMPATIBILITY-BASED SELECTION OF CONCRETE
SBBS
77
vidual components.
In our case study, the temperature conditions for OMAP3530 and TMS320C64x+ (the AES SBB) have the same ranges of [0; 90]◦ C . Therefore, the
system and SBB are environmentally compatible without any additional
constraints.
The above definitions for computing the compatibility relation and their
pairwise imposed constraints allow us to reason about environmental conditions of assemblies based on constraints for its constituent components.
Figure 5.15(b) depicts the user interface of the SEED MagicDraw plug-in
supporting compatibility analysis. It allows selecting a type of the desired
compatibility analysis (logical and environmental) and its settings. The bottom part of this tool shows the results of the analysis, namely whether the
system and SBB are compatible according to the selected criteria. Additionally, it shows a generated set of environmental constraints for a environmental compatibility check.
(a) Transformation tool
(b) Compatibility analysis tool
Figure 5.15: Model-based compatibility analysis tools (the user interfaces)
5.5.4
Scalability and Performance
So far, we have used the case study of smart metering devices to illustrate
the compatibility analysis and knowledge management ideas supported by
our methods and tool. This section proceeds to show that this approach is
scalable to domains with large data sets. We design experiments to estimate
the size of resulting vendor ontologies as well as the execution time for the
transformation of MARTE models into OWL.
In this study, we focus on microcontrollers (MCUs) provided by some
78
CHAPTER 5. APPLICATION OF THE DOMAIN-SPECIFIC
SECURITY KNOWLEDGE
of popular vendors (Renesas, Texas Instruments, Fujitsu, Atmel, and Microchip Technology). We estimate the potential complexity of corresponding
MARTE models and the size of corresponding OWL ontologies in terms of
the number of generated axioms. Three classes of embedded systems and
MCUs commonly used for their design [96] are considered: small scale (8-bit
MCUs), medium scale (16-bit MCUs), and sophisticated embedded systems
(32-bit and ARM-based MCUs). Thereafter, we study how many models
are currently available on the market for each vendor (see Table 5.4). The
data has been extracted from the official Internet resources of the vendors
mentioned above.
Table 5.4: Scalability and performance estimations
1
2
3
4
5
6
7
8
9
Renesas
Texas Instruments
Fujitsu
Microchip Technology
Atmel
Total amount of units
Av. number of axioms per unit
Approx. total number of axioms
Av. transformation time (ms)
8-bit
933
0
103
348
238
1622
68
110 296
1455.1
16-bit
2290
406
207
334
0
3237
105
339 885
1627.92
32-bit
1817
292
630
79
179
2997
133
398 601
2497.92
To estimate the potential number of generated axioms, we select five
commonly used MCUs of each class, create their MARTE models, and execute their transformations. This study shows that the simplest 8-bit MCUs
creates an average of 68 axioms while the most sophisticated 32-bit MCUs
generate 133 axioms (see Table 5.4, row 7). The 8th row shows the approximate number of produced axioms when all models are added into ontologies.
Finally, we compare these numbers with scalability studies of the OWL APIs
and Jena technologies done by Horridge and Bechhofer [63] and Dibowski
and Kabitzsch [92]. In particular, Horridge and Bechhofer [63] show that
OWL APIs can easily handle ontologies that contain 1 651 533 axioms consuming 831 MB. As a result, we conclude that the used technologies (OWL
APIs and MARTE) allow handling ontologies for a significant number of
vendors in a potential real world deployment. This capacity allows loading
multiple vendors’ ontologies to execute compatibility analysis. Additionally,
some techniques for swapping ontologies in memory can be implemented to
handle even bigger datasets.
Next, we execute 50 runs of the transformation for the same representatives of each MCU class and measure the execution time for each run (see Table 5.4, row 9). In particular, we measure the execution time of the following
operations for each run: transformation of an original UML/MARTE model
into the OWL API syntax; generation of axioms executing corresponding
OWL APIs; and saving the resulting ontology into an owl-file. The hardware used in this study is a system with 2.8 GHz Intel Core i7 and 8 GB
5.6. EXTENDED FORM OF THE PROCESS
79
of RAM running Mac OS. In our case, the transformation time does not
vary substantially for small and medium MCUs while one second increase is
observed for the sophisticated 32-bit MCUs. This increase can be explained
by naturally larger, in comparison with 8-bit and 16-bit MCUs, complexity
of 32-bit MCUs in both number of elements and their attributes.
5.6
Extended Form of the Process
In this chapter, we have presented the process for application of the domainspecific security knowledge that is depicted in Figure 5.1. The process has
been intentionally simplified by the author to facilitate explanation of the
introduced methods and tools. In this section, we give a broader view to
this process.
Figure 5.16: Extended form of the proposed process
Figure 5.16 depicts the extended representation of our process. The
grey boxes indicate the steps that rest on the SEED methods explained
earlier in this chapter. An embedded system engineer starts to create a
system model that includes both functional and execution platform models.
Thereafter, an engineer proceeds with association of a relevant set of DSSMs
(see Section 5.2) followed by application of the asset elicitation technique
and search for security properties (SPs) method explained in Section 5.3.
When a set of security properties that are relevant for a considered system
80
CHAPTER 5. APPLICATION OF THE DOMAIN-SPECIFIC
SECURITY KNOWLEDGE
are known, preliminary analysis of the proposed security properties should
be conducted as it is shown by the Preliminary analysis of the SPs step. For
example, an engineer can go through additional risk analysis to eliminate
some assets and associated security properties. Alternatively, satisfiability
of the generated set of security properties can be checked. This analysis can
result in the necessity to redesign a system as it is indicated by the go to
(1) step.
As we have explained in Section 5.4, the Search for concrete SBBs step
may lead to proposing a number of alternative ways to secure a system,
i.e. a collection of alternative sets of concrete SBBs. The Compatibilitybased selection of concrete SBBs step allows narrowing the initial collection
of concrete SBBs sets. Thereafter, the proposed ways (sets of concrete
SBBs) to secure a system can be preliminary studied applying some kind of
trade-off analyses as indicated by the Preliminary trade-off analysis based
on PERs step. Recall that each PER stores information about concrete
SBBs performance indices. If this analysis shows that all proposed sets of
concrete SBBs can not be sustained by available resources of a system than
an engineer can return to step (1), e.g. to redesign a system, or step (4),
e.g. to reduce a number of assets.
Thereafter, one selected set of concrete SBBs is integrated into a system design. At this phase, an embedded system engineer can use tools
and techniques developed by the research community to conduct a detailed
analysis to study consequences of incorporating security functions into a
system. The Security analysis step can be used to check whether a set of
integrated SBBs provides the required level of security. The System analysis step can assist in verifying if security functions do not violate functional
requirements of a system, e.g. all deadlines are met. The Detailed trade-off
analysis step allows ensuring that available system resources are enough to
execute both system and security functions. Thus, the former step may result in redesigning a system (i.e. go to step (1)) or reconsidering security
requirements (i.e. go to step (4)). The latter two tasks may lead to selecting
another set of concrete SBBs to be integrated into a system (i.e. go to step
(8)) or redesigning a system going to step (1). In the case when all checks
outlined above show satisfactory results a system model with integrated set
of concrete SBB produce a security-enhanced embedded system model.
Chapter 6
Related Work
In this thesis, we have presented the SEED approach that aims at supporting designing of security-enhanced embedded systems. In the following, we
describe some works that are related to our contributions from different
perspectives. We discuss those works that target similar objectives or that
employ similar methodologies.
6.1
Composing a System from Reusable Blocks
The growing complexity of systems determines the need to enable their
construction as composition of reusable blocks. This approach brings a range
of benefits: it allows reducing the development time and cost, improving
the quality of reusable artefact, utilising better expertise of engineers from
various domains, to name a few. In our work, we exploit the MBE method
SPACE where the notion of a building block is developed. However, there
are other widely spread approaches that can potentially support reusability
of security solutions across different systems. In this section, we describe two
such approaches, namely component-based and aspect-oriented paradigms.
6.1.1
Component-based Development
A component is a core concept used in component-based approaches for
system development. It is a reusable block that encapsulates some system
functions or services. The widely accepted definition of a component is given
by Szyperski [97].
“A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component
can be deployed independently and is subject to composition by third parties.”
Originally, components are meant to be delivered as binary units deployed and composed at run-time. However, this requirement is often relaxed in case of embedded systems up to the design phase due to an overhead
81
82
CHAPTER 6. RELATED WORK
created by a component framework [98]. We proceed to describe the basic
concepts and terminology used in component-based system development approaches [99, 100].
To enable component-based design, each component must adhere a specific component model that defines a set of rules and conventions to describe
a component. In particular, a component is defined by its interfaces. Each
interface reflects properties of the component that are visible externally (i.e.
for other components and a system as a whole). Interfaces can be represented as a set of operations with a list of input and output parameters,
i.e. operation-based interfaces. Alternatively, interfaces can be considered
as entities that send and receive data, i.e. port-based interfaces. One can
distinguish provided (e.g. operations provided for their environment) and
required (e.g. operations required from their environment) interfaces. Additionally, the notion of rich interfaces is introduced [99] to refer to interfaces
that contain additional information about interfaces, e.g. declaration of
their extra-functional properties such as the execution time. Rich interfaces
enable certain verifications when composing components.
The process that establishes connection between components (i.e. the
composition of their functions) is called component composition, binding [100],
or wiring [101]. The result of composition of two or more components is referred to as an assembly. In some component models, the composition of
components is supported through connectors that are mediators between
components. A component model is supported (at the design- or run-time)
by a component framework that is an infrastructure that manages resources
for components.
A set of challenges arises when adopting component-based development
approaches for embedded systems. For example, the temporal properties
of embedded systems require that components provide time characteristics as a part of their interfaces. This is a difficult task if a component
is considered to be a software unit since temporal properties depend on the
underlying hardware. However, the need to utilise benefits of component
frameworks for the world of embedded systems determines the tendency of
developing component-based approaches for these domains as well, e.g. AUTOSAR [102] for automotive industry and ROBOCOP [103] for consumer
electronics domains. Hošek et al. [104] compare ten other component frameworks focusing on those that provide support for execution. Besides general
features related to component models and frameworks (e.g. presence of connectors, type of interfaces) the authors consider a set of requirements that
are coming from the domain of embedded systems. They are, for example,
support for coupling with hardware or modelling real-time attributes.
Several component frameworks have been enhanced to deal with security
aspects. For example, Saadatmand and Leveque [105] develop a methodology to integrate security mechanisms into the ProCom component model.
Abdellatif et al. [106] propose a method to enforce an information flow control of the Think component model.
6.1. COMPOSING A SYSTEM FROM REUSABLE BLOCKS
6.1.2
83
Aspect-oriented Development
Aspect-orientation enforces the separation of concerns principle [107]. This
principle promotes identification of different concerns in a system and their
separation encapsulating them into reusable artefacts, e.g. modules. These
artefacts can be analysed in isolation and applied in several applications.
In aspect-oriented modelling (AOM), reusable modules usually realise so
called crosscutting concerns. The concern is called crosscutting if a requirement, that it expresses, cuts across a whole system. Thus, reusable modules
that implement crosscutting concerns provide such extra-functional properties as security, safety, or other quality of services properties as opposed
to traditional functional units of decomposition used in component-based
development. The terminology of AOM is not so mature as the terminology
of component-based development. However, we have identified some basic
concepts used in AOM approaches that deal with the security concern.
A primary system model is a base model of a system (both its functionality and architecture) under development. This primary system model is
further extended with a so called aspect that is a reusable implementation of
some function that fulfils a crosscutting concern. Each aspect has two forms:
a generic aspect is an application independent model of an aspect, and a
context-specific aspect is a generic aspect instantiated for a given application. To transform a generic aspect into a context-specific aspect, a set of
adaptation rules are applied. Basically, these adaptation rules specify how
to map the abstract syntax of a generic aspect into the syntax of a certain
application domain. Finally, a context-specific aspect is integrated into a
primary system model that results in an integrated system model. The integration is done applying a set of composition rules that can be implemented
as an engine that takes primary system model and context-specific aspects
as an input and produces an integrated system model. Alternatively, composition rules can be represented as a set of instructions for an engineer that
describe steps to be taken for composition. The comprehensive and extensive conceptual reference model of aspect-oriented modelling constituents
is presented by Schauerhuber et al. [108]. Below, we overview two AOM
approaches that deal with the security and dependability concerns. These
approaches employe UML for modelling of a system and aspects.
France et al. [109] represent a generic aspect (referred to as “generalised
form of a solution”) as a pattern that describes common characteristics of a
solution. These patterns are realised as UML model templates. The adaptation is implemented as instantiation of a pattern by binding (i.e. relating)
its template parameters to application-specific values. The composition is
realised by merging UML models of a primary system model with contextspecific aspects. This merge can be controlled and managed by so called
composition directives. For example, composition directives can be used to
specify that some elements of a primary system model should be removed,
added, or modified in a certain way. They also can predefine the order when
several aspects are composed with one primary system model. Thus, vary-
84
CHAPTER 6. RELATED WORK
ing composition directives several (potentially different) integrated system
models can be obtained. Further, an integrated system model is analysed
to reveal conflicts or undesirable properties, and to investigate whether the
used aspect provides the required level of dependability.
Mouheb et al. [110] presents another approach for AOM. A primary
system model is a UML model where some elements are annotated with
stereotypes and tags that express security requirements, e.g. confidentiality
and integrity of data. Additionally, a primary system model is extended
with specifications of join points used to support composition of a primary
system model and aspects. In particular, join points specify where an aspect
should be integrated in a primary system model, e.g. before or after a
specific operation. An aspect is a UML class model that is extended with a
set of stereotypes from a specific UML profile provided by the authors. For
example, one of the stereotypes provided by this profile is a pointcut that
is used to specify where in a primary model an aspect should be injected.
Similar to join points, a pointcut can specify, for instance, that an aspect
should be inserted before or after a UML operation or call. Each aspect
can provide several functions that are referred to as advice in the mentioned
profile. The adaptation of a generic aspect, i.e. creation of a contextspecific aspect, is done as matching join points from a primary system model
and pointcuts from a generic aspect. The composition is defined as actual
weaving of aspects into a primary system model.
To sum up, approaches that allow dealing with security in a reusable
manner emerge. In these approaches a security measure that enforces security properties is represented in the form of a reusable unit. Each approach
has its own syntax and frameworks (i.e. theoretical foundations supported
by tools) to integrate a reusable unit (i.e. a component, aspect, or building
block) into a system model. In our work, we employ the notion of reusable
building blocks used in the MBE method SPACE. Thus, we enjoy a wide
range of capabilities provided by this method. They are, for example, a
powerful tool-set based on Eclipse Modelling Framework called Arctis [37]
and a rich library of already implemented RBBs [38] including the one that
model security measures. Moreover, the SPACE RBBs are specified by the
modelling language that is based on the well-known syntax of UML activities supported by the formal semantics (Temporal Logic of Actions) [39].
The semantics is suitable for designing of distributed systems built of embedded devices. Moreover, this modelling language allows us to analyse
SPACE models to elicit new information required to support integration of
a relevant set of security measures.
6.2
Security-enhanced System Design
This section summarises our review of methods developed to assist a system engineer in integrating security mechanisms into a system design. We
start discussing methods to deal with security aspects that are designed
6.2. SECURITY-ENHANCED SYSTEM DESIGN
85
for general systems in Section 6.2.1 followed by methods that target embedded systems in Section 6.2.2. Thereafter, Section 6.2.3 briefly describes
approaches related to selection of security measures given a repository of
available alternatives. Finally, we briefly discuss some methods to conduct
risk analysis in Section 6.2.4 positioning the proposed asset elicitation technique in the context of these methods.
6.2.1
General Methods to Deal with Security
The challenge of integrating security mechanisms into various types of systems has been addressed by several approaches. They are, for instance,
MDSE1 /UMLsec, MDS2 /SecureUML, security aspects, security patterns,
and AVATAR, to name a few. MDSE/UMLsec [111] is one of the first approaches developed for integration of security related information into UML
specifications of a system. In particular, UMLsec is a UML profile that is
used to incorporate security requirements (such as the fair exchange principle
and secure communication links) in the form of corresponding stereotypes
(i.e. “fair exchange” and “secure link” respectively) and their tags (e.g.
those tags that allow specifying an adversary) into various UML models
(e.g. class or activity models). These stereotypes allow a system engineer to specify a proper set of security requirements for a system under
development. Thereafter, a system design should be enhanced to meet the
augmented security requirements using such techniques as, for example, security patterns [112] or direct refinement of an initial system design. The
use of UMLsec allows formally verifying if the resulted system design meets
the annotated security requirements. Additionally, there are some works
that complement the UMLsec methodology with the security requirements
elicitation phase. Thus, Houmb et al. [113] propose a methodology to elicit
requirements from stakeholders employing a heuristics-based tool empowered by the common criteria standard [114].
MDS/SecureUML [115] deals with design and verification of role-based
access control systems. SecureUML is a security modelling language that
should be combined with other languages used for a system design. Thus,
it enables a system engineer to model both security and functional aspects
of a system simultaneously. The merge of languages is proposed to be implemented through a so called “dialect”. A dialect is used to match metamodels and syntax of corresponding functional and security languages. In
particular, a dialect shows what elements of a system design language are
SecureUML resources and what actions are applied to these resources. Thus,
SecureUML can help to express such information as which elements of a system model shall be considered as resources and what actions are permitted
under these resources.
The aspect-oriented paradigm presented by France et al. [116] identi1 Model-Driven
2 Model-Driven
Security Engineering
Security
86
CHAPTER 6. RELATED WORK
fies security as a crosscutting concern. To deal with this concern, security
functions are encapsulated as aspects that are woven into the initial system model. In this approach, security requirements are elicited by means
of composing a system model with a threat model and checking if the attack succeeds. Thereafter, a suitable security aspect is encapsulated into a
system design. Aspect-Oriented Risk-Driven Development (AORDD) is an
approach developed by Georg et al. [117] that extends the contribution of
France et al. [116] to calculate the fitness of different security measures as
a trade-off between different criteria, e.g. provided security level, project
and deployment effort. The fitness score for a particular security measure is
calculated with a specially constructed Bayesian Belief Network. Further,
Houmb et al. [118] add to AORDD the performance analysis step employing
the PUMA tool.
Security patterns [112] are intended to capture security solutions for
common security challenges. In general, a pattern is an extremely broad
concept that can be used to encapsulate expert knowledge of any kind (e.g.
a reoccurring structure, process, activity, or just some kind of “thing”) along
all phases of a system development. To be able to cover such diverse information, patterns are defined in a highly generic form. In particular, each
pattern describes a solution in a human-readable text (sometimes referred to
as patterns’s documentation), which is sometimes augmented by UML models to help developers to understand a pattern. Schmidt et al. [119] develop
an approach called Security Engineering Process using Patterns (SEPP). In
this process, the authors introduce a special type of patterns called Security Problem Frames (SPFs). SPFs consider generic security requirements
omitting possible means to satisfy these requirements. The SPF description contains the following fields: name, intent, a frame diagram, informal
description, a security template, and an effect. Each field is defined in a textual form, as a UML model, or in some other formal notation. Thereafter,
the authors introduce the notion of a Concretised Security Problem Frame
(CSPF) that describes generic security measures linked to related SPFs. It
is the responsibility of a system engineer to select and instantiate both SPFs
and CSPFs to proceed with the SEPP method.
Other approaches that are designed to assist a system engineer to secure
a system can also be mentioned. For example, Hamid et al. [120] enforce
the notion of security (and dependability) patterns supported by formal
validations. Pedroza et al. [121] propose a SysML-based environment called
AVATAR to model and verify safety, authenticity, and confidentiality properties. The recent work of Uzunov et al. [122] provides a comprehensive
survey, comparison, and classification of many other methodologies to assist
in designing security-enhanced systems.
Compared with the SEED approach proposed in our work where the
security-related knowledge is captured by DSSMs, the approaches mentioned
above still require in-depth security knowledge from a system engineer or
presence of a security expert. For example, it is not clear how a system engi-
6.2. SECURITY-ENHANCED SYSTEM DESIGN
87
neer should select a suitable security aspect in the AORDD method. It is assumed as the given knowledge since the authors know a priori how to model
relevant attacks and how to construct and weave a security aspect. A security pattern is very powerful concept to assist in analysing and developing
secure software in a systematic manner exploiting the “body of accumulated
knowledge” represented as a pattern. However, due to its unfixed (though
flexible) syntax, their application is thought to be manual. This statement
is supported by the fact that security patterns, in general, do not make
any assumption on the used design language for a system implementation.
Thus, application of current security patterns can be hardly automated. In
the SEPP method, selection and instantiation of both SFPs and CSPFs are
supposed to be done by a system engineer that can be cumbersome due to
their complicated structure. In contrast, we provide a bridge between security domain experts and embedded system engineers. The SEED approach
defines a structured methodology (i.e. concepts, methods, processes, and
tools) to create and select a suitable set of security measures represented in
the form of reusable building blocks that can be integrated into a system
under development. Thus, our approach produces a guideline on where and
why a specific security measure should be applied. Moreover, SEED allows
separating the task of designing a security mechanism from a system design.
6.2.2
Methods for Embedded Systems
A number of model-based approaches to enforce security within embedded
systems are proposed. The Ruiz et al. [123] approach requires that a system
engineer defines a set of security properties for a scenario. This assumption
already requires that an embedded system engineer has a good expertise in
security. According to Ruiz et al., each security property is further linked to
attacks and threats. Attacks and threats are modelled in order to describe
the capabilities of intruders to cause harm in a system. Finally, these threat
models are associated with a set of static and dynamic tests to enable the
later testing of a system integrated with security mechanisms.
In our approach, we propose a method to systematically elicit required
security properties consulting the security knowledge captured in DSSMs.
Therefore, our approach addresses the situation when an embedded system
engineer has just limited expertise in security. The knowledge about threats
is indeed exploited in our approach to refine a set of initially elicited security properties. We believe that our approach can be complemented by
the Ruiz et al. [123] idea to link threats with a corresponding set of tests.
However, we envisage that there is also a need to extend this idea linking
security properties and threats to verification facilities (besides tests). This
enhancement will provide required assurance already at the design phase
as opposed to postponing all checks until the first prototype of a system is
available when testing can be performed [124].
Hamid et al. [125] attempt to model trust properties as reusable patterns
88
CHAPTER 6. RELATED WORK
for specific domains. While that work shares our aspirations for reusability,
we consider security concerns rather than trust relations. Similar to our
work, Eby et al. [126] adopt principles of domain-specific modelling. They
propose to integrate a Security Analysis Language (SAL) into a DSML for
the embedded systems domain (that reminds us the SecureUML approach).
However, they focus on security of information flows.
Saadatmand and Leveque [105] develop a method for incorporating security aspects into the ProCom component model. The authors consider two
security goals, namely confidentiality and authentication. This approach
proposes to use (manual) annotations to identify those parts of a system
model where integration of security aspects is needed. In contrast to this
work, we have developed the asset elicitation technique to identify vulnerable parts of a system avoiding manual tagging of a system model.
6.2.3
Selection of Security Measures
An important step that precedes actual integration of security building
blocks is the selection of such. We have observed that the model-based
and model-driven methods mentioned above do not address this task in
detail. However, approaches for selection of security measures are under
development in the context of security patterns [112].
Selection of security patterns is based on their classification. Such classification can be built of just three classes (Fernandez et al. [127]) or be
represented as a multi-dimensional matrix of classes (VanHilst et al. [128])
including such categories as an architectural layer (e.g. network), a lifecycle stage (e.g. design), and a domain (e.g. enterprise systems). In our
work, the basics for selection of concrete SBBs are domains, security goals,
defence strategies, and assets. Thus, there are some overlapping concepts
in our work compared to the dimensions elaborated for security patterns.
However, SEED proposes that only the domain dimension is selected by an
embedded system engineer following the guideline. Selection of other categories is done by applying the elicitation technique and querying the core
security ontology.
Hafiz et al. [129] organise security patterns according to the CIA3 goal
model, a pattern’s application context (i.e. core security, perimeter security,
and exterior security), a problem domain, and their classification based on
the STRIDE4 model. All these classifications are formalised in tabular or
tree forms. In addition to this method, Washizaki et al. [130] develop the
Dimensional Graph (DG) concept to formalise the multi-dimension classification of security patterns. Each DG uses a UML object diagram to show
relations of a pattern to a set of dimensions of interest. We formalise our
categories as the core security ontology, which allows utilising advantages of
3 Confidentiality,
Integrity, and Availability
Tampering, Repudiation, Information disclosure, Denial of service, and
Elevation of privilege
4 Spoofing,
6.3. MARRYING ONTOLOGIES AND MODELS
89
the ontology technology querying services for the selection of concrete SBBs.
6.2.4
Risk Analysis
Asset identification is an essential stage of risk analysis methods that precedes selection of security mechanisms, e.g. as in the CORAS model-based
method [84] or such general frameworks as OCTAVE (Operationally Critical
Threat, Asset, and Vulnerability Evaluation) [131] and CRAMM (CCTA
Risk Analysis and Management Method) [132]. Identification of assets is
normally done through some informal analysis (implemented as brainstorming sessions or interviews) of a system model or other (often informal) representations. We have proposed to automate this task in the presence of a
formal system model composed of functional and execution platform views.
We have defined the rules for traversing a system model expressed as
SPACE collaborative activities to identify assets and classify them in accordance with the knowledge captured within the security ontology. Thereafter,
the knowledge about vulnerabilities and threats associated with elements of
MARTE platform models is applied to refine the initial set of assets. Note
that our methodology does not deny the best of the practice methods existing today. Thus, for example, threat diagrams of the CORAS method can
be used to identify those threats that expose components of an execution
platform adopted for a system under development. Alternatively, threat
and vulnerability security assessment patterns [112] can be employed for
this purpose.
Moreover, the asset identification phase of risk analysis methods and
frameworks [84, 131, 132] usually involves both security experts and stakeholders that are embedded system engineers in our case. In our work, we
undertake one step forward and emphasise the need to make results of such
analysis once conducted by security experts reusable for embedded system
engineers by means of storing its outcomes in a suitable form, i.e. as ontologies, and providing methods for embedded system engineers to apply this
knowledge when designing a system.
6.3
Marrying Ontologies and Models
The use of ontologies to support tasks of model-driven engineering is an
interesting research topic [133]. The potential of ontology technologies applied to the system and software engineering to formalise general modelling
is outlined by Tetlow et al. [134]. Recall that ontologies are used to represent
knowledge as a set of domain concepts and their relations. Similarly, the
conceptual description of a domain through meta-modelling is performed
while creation of a DMSL [25]. Both technologies suggest a range of benefits. For example, one of the main benefits of the ontology technology is its
automated querying services while DSMLs enjoy wider adoption in development environments and tools. Therefore, it is not a surprise that researchers
90
CHAPTER 6. RELATED WORK
try to find a logical synergy to exploit advantages of both of these technologies [133]. For example, Walter et al. [135] in their recent work employ
ontologies to improve the practice of domain-specific modelling (DSM). The
authors have developed a framework for DSMLs that relies on the ontology
reasoning services (e.g. the inconsistency checker) to guide a designer and
to validate incomplete structural domain models. In our work, we combine
the ontology and DSM technologies to assist the development of securityenhanced system models from different application domains. We employ
DSM to constantly populate the used ontology with the domain-specific
security knowledge. Additionally, we provide ontological support for the
standard MARTE profile.
Another interesting and active topic is the use of ontologies to facilitate
designing of complex systems. Dibowski et al. [92] present the ontological
framework to describe devices for the building automation domain. Jianjun
et al. [136] use ontology to configure embedded control systems based on a
functional model of a system that is intended to express the user demand.
Wagelaar [137] combines the ontology technology with the model-driven
architecture principles to enable reuse of platform-independent to platformspecific models (PSMs) transformations. Tekinerdoğan et al. [138] employ
ontologies to support selection of PSMs, where a system platform is described as a set of high level properties. We use ontologies to support a
composition of embedded systems from RBBs that provide extra-functional
properties. Furthermore, we use MARTE models and extend them with
additional concepts to formulate platform-specific constraints as a basics for
such composition. Specifically, we elaborate on the notion of model-based
compatibility as one of possible criteria for selection of a set of concrete
SBBs where security is an example of an extra-functional domain.
6.4
Performance Analysis at the Design Phase
There is a range of tools that enable performance analysis when only a design of a system is available. Robert and Perrier [139] and Piel et al. [140]
present CoFluent and Gaspard2 methodologies and tools to execute performance analysis at the design phase. These techniques use UML/MARTE
models to describe architecture and application designs. In addition to the
MARTE profile, CoFluent employs the SysML [141] modelling language.
Both CoFluent and Gaspard2 introduce some constraints on the original semantics and on usage conventions of MARTE models to enable their further
analysis. Similarly, we make some assumptions on MARTE models when
designing the support (methods and tools) for model-based compatibility
analysis. Thereafter, both CoFluent and Gaspard2 methodologies use a different chain of transformations to generate SystemC TLM 5 code for its
further simulation in suitable tools.
5 Transaction
Level Model
6.4. PERFORMANCE ANALYSIS AT THE DESIGN PHASE
91
The use of performance analysis while composing a system with RBBs at
the early design phases is a subject of active research. Woodside et al. [142,
143] develop and apply the PUMA 6 approach for performance analysis of
RBBs represented as security aspects. Woodside et al. start exploiting
the UML SPT 7 profile, but their further works adapt this methodology
for the MARTE profile. In this work, the authors generate LQN 8 models
that are analysed by a solver and simulator. Similarly, Wehrmeister et
al. [144] presents the AMoERT 9 methodology when the aspect-oriented
paradigm is used. In this work, the authors propose the GenErTiCa tool to
generate Java code for a specific predefined (though selected by an engineer)
target platform. Bondarev et al. [145] present the CARAT 10 toolkit for
performance evaluation where RBBs conform to a specific component model.
The authors use their own modelling language to describe the application
logic and architecture that are synthesised into an executable system model
used for the task scheduling.
We can distinguish two categories of methods that allow obtaining performance evaluation results when only a design model is available. The
methods of the first group (CoFluent and AMoERT) take a set of application and platform models as an input and generate code, e.g. C and SystemC. Afterwards, the generated code is executed in a simulation tool. The
methods of the second group (PUMA, CARAT, and Gaspard2) use models
as a means to input required data into analytical performance analysis tools.
The SPACE method employed in our work enables code generation for
functional models (i.e. UML activities) where Java code is produced from
state machines for a certain predefined execution platform (e.g. ServiceFrame [39]). Thus, one can relate the SPACE methodology to the first
category of the classification outlined above excepting the fact that transformations are bound to a specific predefined execution platform. In our
work, we complement SPACE models with an execution platform described
as MARTE models. These MARTE models can be converted into the corresponding simulation code using methods developed in the approaches mentioned above. Therefore, there is a potential to simulate SPACE models on a
desired execution platform (that is modelled in MARTE), once a formalised
and tooled allocation of SPACE models onto MARTE models is defined.
Moreover, our work complements the approaches described above since it
enables reuse of outcomes of SBBs performance evaluation conducted by
corresponding domain experts.
Ciccozzi et al. [146] propose a meta-model used to propagate results of
monitoring extra-functional properties at the code level back to a system
model in order to improve it. This approach is developed for the CHESS
modelling language [147]. In our work, we exploit MARTE models to cap6 Performance
by Unified Model Analysis
Performance and Time
8 Layered Queueing Networks
9 Aspect-oriented Model-Driven Engineering for Real-Time systems
10 Component Architectures Analysis Tool
7 Schedulability,
92
CHAPTER 6. RELATED WORK
ture platform-specific constraints of embedded systems and SBBs. The proposed MARTE compatible profile allows capturing more information about
outcomes of SBBs performance analysis, e.g. the used workload and the
observed resource footprint. This information (structured, captured, and
searchable) aids an embedded system engineer to select an appropriate SBB
to satisfy required security (or other extra-functional) properties.
Chapter 7
Conclusions and Future
Work
This thesis has presented the SEED approach that supports embedded system engineers and security experts in designing security-enhanced systems.
This chapter summarises this work and discusses some interesting directions
for the future work.
7.1
Conclusions
The increased use of embedded systems in countless applications has led
to a boost in their complexity and a need for constant connectivity to open
networks. As a result, these systems operate with different categories of data
which often include sensitive information. In realities, the task of assuring
security properties of embedded systems becomes more challenging, which
immediately leads to an emergent need in specific methods and tools to
support the development of embedded systems.
In this work, we have focused on some aspects of the aforementioned
challenge and identified the basic principles currently developed by the research community to address these aspects. These aspects and principles
are outlined below. First, the complexity and resource scarcity of embedded
systems can no longer sustain the practice of adding security measures at
the late development phases. To overcome this issue, the focus on security
should be shifted to the design phase following the principles of modelbased engineering. Second, although security attracts more attention, there
are still a fewer security experts than embedded system engineers. The need
to share the knowledge of the security experts and apply it in multiple domains in an effective way emerges. We tackle this issue by implementing
the principle of separation of concerns. Finally, complexity of embedded
systems and modern security solutions encourages that security solutions
93
94
CHAPTER 7. CONCLUSIONS AND FUTURE WORK
are adjusted to a certain application domain, so that their integration into
an embedded system design is less of a burden. We exploit the principle of
domain specialisation to address this issue.
To address the named challenge, we have developed an approach called
SEED that is built around the basic principles mentioned above. With the
help of SEED, security experts gain an opportunity to describe developed
security solutions in a reusable manner and embedded system engineers
can select a suitable set of security solutions based on an analysis of both
system’s security needs and its resource constraints.
SEED rests on two concepts introduced in this thesis, namely DomainSpecific Security Model (DSSM) and Performance Evaluation Record (PER).
The DSSM and PER concepts described in Chapter 4 are relatively easy to
use since they are UML models that are formalised as ontologies: the core
security ontology and the core evaluation ontology respectively. These concepts serve as tools for security experts to capture their knowledge about
existing security solutions. Each DSSM enables characterising common security issues of a specific application domain in a form of security properties.
Thereafter, security properties are linked to available solutions that can be
used for their enforcement. Each PER is used to characterise the resource
overhead created by a security measure, quality of provided extra-functional
properties, and an evaluation technique applied. The underlying ontologies
allow storing the knowledge provided by experts and inspecting this knowledge when it is needed for embedded system engineers.
Additionally, the SEED approach is combined with a set of methods and
tools that support an embedded system engineer in selecting a suitable set
of security measures to be integrated into a system design. These methods,
described in Chapter 5, assist an engineer to consistently use the knowledge
provided by security experts. The first method, called asset elicitation technique, allows analysing a system design and identifying its security needs
by consulting DSSMs. The method conducts inspection of functional and
execution platform models, represented as SPACE and MARTE models respectively, and consult DSSMs to obtain a set of security properties that
are recommended for implementation. A set of security solutions that satisfy security properties are also retrieved from DSSMs. The second method
developed in this thesis examines resource constraints of security solutions
stored in PERs. This technique, called model-based compatibility analysis,
matches platform-related constraints of a system under development and
those required by security solutions.
The SEED approach is supported by a set of tools that have been integrated into the MagicDraw environment as a plug-in. These tools use technologies provided by model-driven engineering, e.g. modelling and transformation facilities.
Using the metering devices domain as an example, we have shown that
the introduced concepts (DSSM and PER) can be employed by a security
expert to describe the security knowledge. Consequently, we have demon-
7.1. CONCLUSIONS
95
strated that it can be used to support an embedded system engineer to
integrate a suitable set of security solutions exploring this security knowledge. This case study that is currently under industrial development has
been provided as a use case within the EU FP7 SecFutur project.
The SEED approach developed in this thesis has the potential to contribute to the emerging practice of systematic treatment of security aspects
in embedded systems. It is one more step towards providing support to
embedded system engineers when designing security-enhanced systems. We
conclude with a few reflections about the problem and solution spaces investigated during this work.
Our work rests on the premise that security functions encapsulated into
reusable SBBs are basic elements used to support designing of securityenhanced embedded systems. However, it is possible to envisage that enforcement of security properties in an embedded system is not limited to
the task of incorporating SBBs. In particular, we find that realisation (at
the design phase) of the system functionality itself and a choice of the hardware/software components for an execution platform have also a considerable impact on security properties. For example, if several alternative ways
to allocate security assets on available components exist, the selected allocation may affect security of a system when components differ in terms of their
tamper resistance. This, in turn, affects a range of SBBs selected for their
integration into an embedded system. While these aspects might be well
understood by security experts, there is a shortage of support for embedded
system engineers to adopt them when designing a system. We believe that
this knowledge possessed by security experts made available for reuse will
empower system engineering teams to be more security conscious.
In Chapter 5 we conclude that the use of DSMLs can improve the asset
elicitation technique thanks to richer semantics tailored to an application
domain. On the other hand, the use of a specific DSML will limit applicability of SEED (or any other approach) confining it to a certain domain.
To increase applicability of DSMLs for general approaches is an important
challenge. We believe that one way to address it is to elaborate suitable abstraction layers that will allow adapting an approach for a range of DSMLs.
To achieve this flexibility we have structured SEED in two levels of abstraction, namely foundation and realisation. The foundation level is the
technology-ignorant level that defines basic principles. The realisation level
refines the formulated principles according to a selected DSML.
In conclusion, we must mention that there are still other processes where
an embedded system is not composed from separate functional and nonfunctional elements, e.g. building blocks. These processes may have many
other emerging challenges when dealing with a task of supporting engineers
in developing security-enhanced embedded systems. This is also an interesting direction of work, but it is outside of the scope of this thesis.
96
7.2
CHAPTER 7. CONCLUSIONS AND FUTURE WORK
Future Work
Since the scope of our work is fairly broad that opens many aspects with
respect to designing a security-enhanced embedded system, many diverse
directions for future work can be identified. In the following, we outline
some of them.
The current version of the core security ontology refines the asset concept by two sub-classes, namely data in transit and data stationary. One
path for future work is to study what are other important assets to be included into the ontology. However, once new assets are introduced, they
should be traceable into a system model to automate their elicitation. The
currently employed SPACE modelling language is a general language for
modelling of distributed applications. Its semantics does not allow identifying other classes of assets within functional models specified with this
language. Therefore, a more expressive, i.e. more domain-specific, language
should be employed for the SEED realisation. This language should allow
identifying newly introduced assets automatically from functional and platform models of a system. Thus, this direction will require studying both a
range of possible assets and existing DSMLs analysing their suitability for
an extension of the asset elicitation technique.
The representation of security properties is an active and interesting
topic. In our work, a tuple consisting of the protected asset, provided security goal, and used defence strategy represents a security property. This
convention limits the range of considered security properties to those that
can be expressed by such a tuple. However, some security properties can be
only expressed, for example, with respect to an operation and an involved
actor. Therefore, we think that employment of a more powerful language
to express security properties will increase the applicability of the SEED
approach. Thus, we propose this topic as another potential direction for
future work.
In SEED, we propose to constantly update the enriched security ontology when capturing the domain-specific security knowledge. Therefore,
an important question of maintaining consistency of the enriched ontology
arises. In particular, an obvious problem with such an update is pollution
of the ontology with concrete SBBs that have different names but refer to
the same implementation. Some issues can be resolved by built-in ontology
services together with such constructs as owl:sameAs or owl:differentFrom.
However, additional support is needed to ensure that two (or more) concrete SBBs under different names are equal implementations as an example.
We envisage that techniques from the area of model comparison or models
diff (applied to functional and platform models of concrete SBBs) can be
employed to address the mentioned issue.
The starting point of SEED is when an embedded system engineer has an
initial version of a functional model of a system and some decisions about a
used platform are taken. However, for security-critical systems, e.g. defence
7.2. FUTURE WORK
97
applications, the security requirements drive and affect the functionality of
a system. Therefore, identifying alternative model-based approaches that
start directly from security assets and their security goals can be another
subject to study.
The SEED approach provides an infrastructure for capturing diverse
performance evaluation results where both resource footprint indices and
quality of service characteristics are stored. The natural development of
this direction is the use of this data for different kinds of trade-off analyses.
Thus, a path for future work will be the exploration of other criteria and
strategies to reuse the performance analysis results stored within PERs.
Finally, availability of advanced and engineer-friendly tools is always
a question when it comes to engineering processes. In our work, we use
MagicDraw as a platform for our supporting tools since it is selected as
an integrating environment within the SecFutur project. However, modeldriven engineering increasingly prioritises open standards. Therefore, the
migration to such environments as EMF can be a potential thread for future work. Additionally, SEED currently relies on UML object models as a
concrete syntax for DSSMs. Development of a text-based syntax can further
improve the provided tool support.
Bibliography
[1] Peter Marwedel. Embedded System Design: Embedded Systems Foundations of Cyber-Physical Systems. Springer, 2011.
[2] Markus Voelter, Sebastian Benz, Christian Dietrich, Birgit Engelmann, Mats Helander, Lennart C. L. Kats, Eelco Visser, and Guido
Wachsmuth. DSL Engineering - Designing, Implementing and Using
Domain-Specific Languages. dslbook.org, 2013.
[3] Frank Alexander Kraemer. Engineering Reactive Systems: A Compositional and Model-Driven Method Based on Collaborative Building
Blocks. PhD thesis, Norwegian University of Science and Technology,
August 2008.
[4] Charles
Q.
Choi.
Cisco
http://spectrum.ieee.org, 2013.
IP
Phones
Vulnerable.
[5] Peter Clarke.
Embedded Systems Next for Hack Attacks.
http://eetimes.com, 2013.
[6] Srivaths Ravi, Anand Raghunathan, Paul Kocher, and Sunil Hattangady. Security in Embedded Systems: Design Challenges. ACM Transactions on Embedded Computing Systems, 3(3):461–491, August 2004.
[7] Marco Brambilla, Jordi Cabot, and Manuel Wimmer. Model-Driven
Software Engineering in Practice. Morgan & Claypool Publishers,
2012.
[8] Paul Kocher, Ruby Lee, Gary McGraw, and Anand Raghunathan.
Security As a New Dimension in Embedded System Design. In Annual
Design Automation Conference (DAC), pages 753–760. ACM, 2004.
[9] MagicDraw. www.magicdraw.com, last visited May 2013.
[10] The SecFutur project: Design of Secure and Energy-efficient Embedded Systems for Future Internet Application. http://www.secfutur.
eu.
99
100
BIBLIOGRAPHY
[11] James K. Peckol. Embedded Systems: A Contemporary Design Tool.
John Wiley & Sons, 2007.
[12] Alan M. Davis. Software Requirements: Analysis and Specification.
Prentice Hall Press, 1990.
[13] German Ministry of Defense. V Model: Software Lifecyce Process
Model, Geenral Reprint No 250., 1992.
[14] Barry W. Boehm. A Spiral Model of Software Development and Enhancement. IEEE Computer Society Press, 1988.
[15] Bruce Powel Douglass. Real Time UML Workshop for Embedded Systems. Elsevier, 2007.
[16] Bran Selic. The Pragmatics of Model-driven Development. IEEE
Computer Society Press, 20:19–25, 2003.
[17] Object Management Group. Unified Modeling Language: Superstructure, version 2.4.1, August 2011. Document number: formal/2011-0806.
[18] Jean Bézivin. On the Unification Power of Models. Software and
System Modeling, 4:171–188, 2005.
[19] Object Management Group. http://www.omg.org, visited July 2013.
[20] Object Management Group. Meta-Object Facilities: Core Specification, version 2.0, 2001.
[21] Dragan Gasevic, Dragan Djuric, and Vladan Devedzic. Model Driven
Engineering and Ontology Development. Springer, 2009.
[22] Krzysztof Czarnecki and Simon Helsen. Feature-based Survey of
Model Transformation Approaches. IBM Syst. J., 45(3):621–645, 2006.
[23] Hans Vangheluwe. Invited talk: Promises and challenges of modeldriven engineering. In European Conference on Software Maintenance
and Reengineering (CSMR), pages 3–4, 2011.
[24] Holger Giese, Tihamér Levendovszky, and Hans Vangheluwe. Summary of the Workshop on Multi-Paradigm Modeling: Concepts and
Tool. In Models in Software Engineering, pages 252–262, 2007.
[25] Steven Kelly and Juha-Pekka Tolvannen. Domain-Specific Modeling:
Enabling Full Code Generation. John Wiley & Sons, 2008.
[26] François Lagarde, Huáscar Espinoza, François Terrier, and Sébastien
Gérard. Improving UML Profile Design Practices by Leveraging Conceptual Domain Models. In IEEE/ACM International Conference on
Automated Software Engineering (ASE), pages 445–448, 2007.
BIBLIOGRAPHY
101
[27] Bran Selic. A Systematic Approach to Domain-specific Language Design Ising UML. In Object and Component-Oriented Real-Time Distributed Computing (ISORC), pages 2–9, 2007.
[28] Object Management Group. UML Profile for MARTE: Modeling and
Analysis of Real-Time Embedded Systems, version 1.1, June 2011.
Document number: formal/2011-06-02.
[29] Charles Andréand Frédéric Mallet, Aamir Mehmood Khan, and
Robert de Simone. Modeling SPIRIT IP-XACT in UML MARTE.
In Design, Automation & Test in Europe (DATE), 2008.
[30] Jochen Zimmermann, Oliver Bringmann, Joachim Gerlach, Florian
Schaefer, and Ulrich Nageldinger. Holistic System Modeling and Refinement of Interconnected Microelectronic Systems. In Design, Automation & Test in Europe (DATE), 2008.
[31] Muhammad Zohaib Iqbal, Shaukat Ali, Tao Yue, and Lionel Briand.
Experiences of Applying UML/MARTE on Three Industrial Projects.
In Springer, editor, Model Driven Engineering Languages and Systems
(MODELS), pages 642–658, 2012.
[32] Simona Bernardi, José Merseguer, and Dorina C Petriu. Adding Dependability Analysis Capabilities to the MARTE Profile. In Model
Driven Engineering Languages and Systems (MODELS), pages 736–
750, 2008.
[33] Daniela Cancila, Francois Terrier, Fabien Belmonte, Hubert Dubois,
Huáscar Espinoza, Sébastien Gérard, and Arnaud Cuccuru. SOPHIA:
a Modeling Language for Model-Based Safety Engineering. In Architecting and Construction of Embedded Systems Workshop (ACESMB), 2009.
[34] Huáscar Espinoza, Sébastien Gérard, Henrik Lönn, and
Ramin Tavakoli Kolagari. Harmonizing MARTE, EAST-ADL2,
and AUTOSAR to Improve the Modelling of Automotive Systems. In
ADAMS Workshop hosted by ECRTS, 2009.
[35] ADAMS project: Action for the Dissemination and Adoption of the
MARTE and Related Standards for Component-based Middleware.
http://www.adams-project.org, last visited July 2013.
[36] Sébastien Demathieu, Frédéric Thomas, Charles André, Sébastien
Gérard, and François Terrier. First Experiments Using the UML Profile for MARTE. In International Symposium on Object Oriented RealTime Distributed Computing (ISORC), pages 50–57, 2008.
[37] Frank Alexander Kraemer, Vidar Slåtten, and Peter Herrmann. Tool
Support for the Rapid Composition, Analysis and Implementation of
102
BIBLIOGRAPHY
Reactive Services. Journal of Systems and Software, 82(12):2068–2080,
December 2009.
[38] Frank Alexander Kraemer and Peter Herrmann. Automated Encapsulation of UML Activities for Incremental Development and Verification. In International Conference on Model Driven Engineering,
Languages and Systems (MoDELS), volume 5795 of LNCS, pages 571–
585. Springer, 2009.
[39] Frank Alexander Kraemer and Peter Herrmann. Reactive Semantics
for Distributed UML Activities. In Formal Techniques for Distributed
Systems (FMOODS/FORTE), LNCS, pages 17–31. Springer, 2010.
[40] Frank Alexander Kraemer and Peter Herrmann.
Formalising
Collaboration-oriented Service Specifications Using Temporal Logic.
In Networking and Electronic Commerce Research Conference, 2007.
[41] Linda Ariani Gunawan, Peter Herrmann, and Frank Alexander Kraemer. Towards the Integration of Security Aspects into System Development using Collaboration-Oriented Models. In Dominic Ślȩzak, Tai
hoon Kim, Wai-Chi Fang, and Kirk P. Arnett, editors, International
Conference on Security Technology (SecTech), volume 58 of Communications in Computer and Information Science, pages 72–85. Springer
Berlin Heidelberg, 2009.
[42] Linda Ariani Gunawan, Frank Alexander Kraemer, and Peter Herrmann. A Tool-Supported Method for the Design and Implementation
of Secure Distributed Applications. In Engineering Secure Software
and Systems (ESSoS), LNCS, pages 142–155. Springer-Verlag, 2011.
[43] Linda Ariani Gunawan and Peter Herrmann. Compositional Verification of Application-Level Security Properties. In Engineering Secure
Software and Systems (ESSoS), LNCS, pages 75–90. Springer–Verlag
Berlin Heidelberg, 2013.
[44] Eclipse Modeling Framework Project (EMF). http://www.eclipse.
org/modeling/emf/, last visited July 2013.
[45] Kermeta. http://www.kermeta.org, last visited July 2013.
[46] Frédéric Jouault and Jean Bézivin. KM3: a DSL for Metamodel Specification. In IFIP WG 6.1 international conference on Formal Methods
for Open Object-Based Distributed Systems, pages 171–185, 2006.
[47] Graphiti - a Graphical Tooling Infrastructure. http://www.eclipse.
org/graphiti/, last visited July 2013.
[48] Graphical Modeling Project (GMP). http://www.eclipse.org/
modeling/gmp/, last visited July 2013.
BIBLIOGRAPHY
103
[49] Xtext. http://www.eclipse.org/Xtext/, last visited July 2013.
[50] Enterprise Architecture. http://www.sparxsystems.com/products/
ea/index.html, last visited July 2013.
[51] Rhapsody.
http://www-03.ibm.com/software/products/us/en/
ratirhapfami/, last visited July 2013.
[52] MDT-UML2Tools. http://wiki.eclipse.org/MDT-UML2Tools, last
visited July 2013.
[53] Papyrus project. http://www.papyrusuml.org, last visited July 2013.
[54] Meta Object Facility (MOF) 2.0 Query/View/Transformation (QVT).
http://www.omg.org/spec/QVT/, last visited July 2013.
[55] ATL. http://www.eclipse.org/atl/, last visited July 2013.
[56] Henshin. http://www.eclipse.org/henshin/, last visited July 2013.
[57] EMorF. http://www.emorf.org, last visited July 2013.
[58] B. Chandrasekaran, John R. Josephson, and V. Richard Benjamins.
What are Ontologies and Why Do We Need Them? In Intelligent
Systems, volume 14, pages 20–26. IEEE, 1999.
[59] Boris Motik, Peter F. Patel-Schneider, and Bijan Parsia. OWL 2
Web Ontology Language Structural Specification and Functional-Style
Syntax, http://www.w3.org/TR/owl2-syntax/, last visited January
2013.
[60] Eric Prud’hommeaux and Andy Seaborne. SPARQL Query Language
for RDF. http://www.w3.org/TR/rdf-sparql-query/, last visited
January 2013.
[61] Protégé Editor. http://protege.stanford.edu, last visited March
2013.
[62] The OWL API. http://owlapi.sourceforge.net, last visited March
2013.
[63] Matthew Horridge and Sean Bechhofer. The OWL API: A Java API
for OWL ontologies. Semant. web, IOS Press, 2011.
[64] SPARQL in Protégé-OWL. http://protege.stanford.edu/doc/
sparql/, last visited March 2013.
[65] Apache Jena project. http://jena.apache.org/, last visited February 2013.
[66] OWL Web Ontology Language. http://www.w3.org/TR/owl-ref/,
last visited July 2013.
104
BIBLIOGRAPHY
[67] Almut Herzog, Nahid Shahmehri, and Claudiu Duma. An Ontology
of Information Security. Journal of Techniques and Applications for
Advanced Information Privacy and Security, IGI Global, pages 278–
301, 2007.
[68] Stefan Fenz and Andreas Ekelhart. Formalizing Information Security Knowledge. In ACM Symposium on Information, Computer and
Communications Security (ASIACCS). ACM, 2009.
[69] Anya Kim, Jim Luo, and Myong Kang. Security Ontology for Annotating Resources. In International conference on On the Move to
Meaningful Internet Systems (OTM), pages 1483–1499, 2005.
[70] Maria Karyda, Theodoros Balopoulos, Lazaros Gymnopoulos, Spyros Kokolakis, Costas Lambrinoudakis, Stefanos Gritzalis, and Stelios
Dritsas. An Ontology for Secure e-government Applications. In International Conference on Availability, Reliability and Security (ARES),
pages 1033–1037, 2006.
[71] Carlos Blanco, Joaquin Lasheras, Rafael Valencia-Garcı́a, Eduardo
Fernández-Medina, Ambrosio Toval, and Mario Piattini. A Systematic Review and Comparison of Security Ontologies. In International
Conference on Availability, Reliability and Security (ARES), pages
813 – 820, 2008.
[72] Amina Souag, Camille Salinesi, and Isabelle Comyn-Wattiau. Ontologies for Security Requirements: A Literature Survey and Classification. In Advanced Information Systems Engineering Workshops
(CAiSE), 2012.
[73] Bill Whyte and John Harrison. State of Practice in Secure Software:
Experts’ Views on Best Ways Ahead. Software Engineering for Secure
Systems: Industrial and Research Perspectives, 2011.
[74] Acceleo. http://www.eclipse.org/acceleo/, last visited February
2013.
[75] Aamer Nadeem and Younus Javed. A Performance Comparison of
Data Encryption Algorithms. In International Conference on Information and Communication Technologies (ICICT), pages 84 – 89, 2005.
[76] R. Stephen Preissig. Data Encryption Standard (DES) Implementation on the TMS320C6000, Application Report, 2000.
[77] Petri Selonen. A Review of UML Model Comparison Approaches. In
Nordic Workshop on Model Driven Engineering, 2007.
[78] Lars Bendix and Pär Emanuelsson. Diff and Merge Support for Modelbased Development. In Workshop on Comparison and versioning of
software models (CVSM), 2008.
BIBLIOGRAPHY
105
[79] EMF Compare; www.eclipse.org/emf/compare/, last visited April
2013.
[80] Geri Georg, Kyriakos Anastasakis, Behzad Bordbar, Siv Hilde Houmb,
Indrakshi Ray, and Manachai Toahchoodee. Verification and TradeOff Analysis of Security Properties in UML System Models. IEEE,
2010.
[81] OMAP3530. http://www.ti.com/product/omap3530, last visited
February 2013.
[82] Ontology Language Manchester Syntax. http://www.w3.org/TR/
owl2-manchester-syntax/, last visited May 2013.
[83] HermiT Reasoner.
september 2013.
http://hermit-reasoner.com,
last
visited
[84] Folker den Braber, Ida Hogganvik, Soldal Lund, Ketik Stølen, and
Fredrik Vraalsen. Model-Based Security Analysis in Seven Steps –
a Guided Tour to the CORAS Method. BT Technology Journal,
25(1):101–117, 2007.
[85] Srivaths Ravi, Anand Raghunathan, and Srimat Chakradhar. Tamper
Resistance Mechanisms for Secure Embedded Systems. In International Conference on VLSI Design (VLSID). IEEE, 2004.
[86] Thomas H. Cormen, Clifford Stein, Ronald L. Rivest, and Charles E.
Leiserson. Introduction to Algorithms. McGraw-Hill Higher Education,
2nd edition, 2001.
[87] Jesús M. Hermida, Marı́a Teresa Romá-Ferri, Andrés Montoyo, and
Manuel Palomar. Reusing UML Class Models to Generate OWL Ontologies - A Use Case in the Pharmacotherapeutic Domain. In International Conference on Knowledge Engineering and Ontology Development (KEOD), pages 281–286. INSTICC Press, 2009.
[88] Zhuoming Xu, Yuyan Ni, Wenjie He, Lili Lin, and Qin Yan. Automatic
Extraction of OWL Ontologies from UML Class Diagrams. World
Wide Web, 2012.
[89] XSD Type System. http://www.w3.org/, last visited March 2013.
[90] Simple Part-whole Relations in OWL Ontologies. http://www.w3.
org/2001/sw/BestPractices/OEP/SimplePartWhole/, last visited
March 2013.
[91] Object Management Group. Ontology Definition Metamodel, version
1.0, May 2009. Document number: formal/2009-05-01.
106
BIBLIOGRAPHY
[92] Henrik Dibowski and Klaus Kabitzsch. Ontology-Based Device Descriptions and Device Repository for Building Automation Devices.
EURASIP J. Embedded Syst., 2011.
[93] Texas Instruments. www.ti.com, last visited March 2013.
[94] Cryptography for C64x+-based Devices. http://www.ti.com/tool/
c64xpluscrypto, last visited January 2013.
[95] Andy Seaborne. SPARQL 1.1 Property Paths, http://www.w3.
org/TR/2010/WD-sparql11-property-paths-20100126/, last visited Jan. 2013.
[96] Ray Kamal. Embedded Systems: Architecture, Programming and Design. Tata McGraw-Hill, 2009.
[97] Clemens Szyperski. Component Software: Beyond Object-Oriented
Programming. Addison-Wesley Longman Publishing Co., Inc., 2002.
[98] Ivica Crnkovic. Component-based Approach for Embedded Systems.
In International Conference on Software Engineering (ICSE), pages
712–713, 2005.
[99] Ed Brinksma, Geoff Coulson, Ivica Crnkovic, Andy Evans, Sébastien
Gérard, Susanne Graf, Holger Hermanns, Bengt Jonsson, Anders
Ravn, Philippe Schnoebelen, François Terrier, Angelika Votintseva,
and Jean-Marc Jézéquel. Component-based Design and Integration
Platforms. Technical report, Project IST-2001-34820. ARTIST, 2003.
[100] Ivica Crnkovic, Séverine Sentilles, Aneta Vulgarakis, and Michel Chaudron. A Classification Framework for Software Component Models.
IEEE Transaction of Software Engineering, 2011.
[101] Ivica Crnkovic. Building Reliable Component-Based Software Systems.
Artech House, Inc., 2002.
[102] Alberto Sangiovanni-Vincentelli and Marco Di Natale. Embedded System Design for Automotive Applications. Computer, IEEE Computer
Society Press, pages 42–51, 2007.
[103] Hugh Maaskant. A Robust Component Model for Consumer Electronic Products. Dynamic and Robust Streaming in and between Connected Consumer-Electronic Devices, Springer, 2005.
[104] Petr Hošek, Tomáš Pop, Tomáš Bureš, Petr Hnětynka, and Michal
Malohlava. Comparison of Component Frameworks for Real-Time
Embedded Systems. In International conference on Component-Based
Software Engineering (CBSE), pages 21–36. Springer-Verlag Berlin,
Heidelberg, 2010.
BIBLIOGRAPHY
107
[105] Mehrdad Saadatmand and Thomas Leveque. Modeling Security Aspects in Distributed Real-Time Component-Based Embedded Systems. In International Conference on Information Technology : New
Generations, pages 437 – 444. IEEE, 2012.
[106] Takoua Abdellatif and Nejla Rouis. Enforcing the Security of
Component-based Embedded Systems with Information Flow Control. In International Conference on Wireless and Ubiquitous Systems
(ICWUS). IEEE, 2010.
[107] Edsger W Dijkstra. On the Role of Scientific Thought. Selected Writings on Computing: A Personal Perspective. Springer-Verlag.
[108] Andrea Schauerhuber, Wieland Schwinger, Elisabeth Kapsammer,
Werner Retschitzegger, Manuel Wimmer, and Gerti Kappel. A Survey
on Aspect-Oriented Modeling Approaches. ACM Computing Surveys,
2010.
[109] Robert France, Indrakshi Ray, Geri Georg, and Sudipto Ghosh.
Aspect-Oriented Approach to Early Design Modelling. IEEE Proceedings Software, 151:173 –185, 2004.
[110] Makan Pourzandi, Djedjiga Mouheb, Chamseddine Talhi, Vitor Lima,
Mourad Debbabi, and Lingyu Wang. Weaving Security Aspects into
UML 2.0 Design Models. In Workshop on Aspect Oriented Modeling
(AOM), pages 7–12, 2009.
[111] Jan Jürjens. Secure System Development with UML. Springer-Verlag,
2005.
[112] Markus Schumacher, Eduardo Fernandez-Buglioni, Duane Hybertson,
Frank Buschmann, and Peter Sommerlad. Security Patterns: Integrating Security and Systems Engineering. John Wiley and Sons, 2005.
[113] Siv Hilde Houmb, Shareeful Islam, Eric Knauss, Jan Jürjens, and
Kurt Schneider. Eliciting Security Requirements and Tracing Them to
Design: an Integration of Common Criteria, Heuristics, and UMLsec.
Requir. Eng., 15:63–93, 2010.
[114] Common Criteria for Information Technology Security Evaluation,
Version 3.1., Revision 4, CCMB-2012-09-001, 2012.
[115] Torsten Lodderstedt, David Basin, and Jürgen Doser. SecureUML: A
UML-Based Modeling Language for Model-Driven Security. In International Conference on The Unified Modeling Language (UML), pages
426–441. Springer-Verlag, 2002.
[116] Geri Georg, Indrakshi Ray, Kyriakos Anastasakis, Behzad Bordar,
Manachai Toahchoodee, and Siv Hilde Houmb. An Aspect-Oriented
108
BIBLIOGRAPHY
Methodology for Designing Secure Applications. Information and Software Technology, 51(5):846–864, 2009.
[117] Geri Georg, Kyriakos Anastasakis, Behzad Bordbar, Siv Hilde Houmb,
Indrakshi Ray, and Manachai Toahchoodee. Verification and TradeOff Analysis of Security Properties in UML System Models. IEEE
Trans. Software Eng., 36(3):338–356, 2010.
[118] Siv Hilde Houmb, Geri Georg, Dorina Petriu, Behzad Bordbar, Indrakshi Ray, Kyriakos Anastasakis, and Robert France. Balancing Security and Performance Properties During System Architectural Design. Software Engineering for Secure Systems: Industrial and Research Perspectives, 2011.
[119] Holger Schmidt, Denis Hatebur, and Maritta Heisel. A Pattern-Based
Method to Develop Secure Software. Software Engineering for Secure
Systems: Industrial and Research Perspectives, 2011.
[120] Brahim Hamid, Sigrid Gürgens, Christophe Jouvray, and Nicolas
Desnos. Enforcing S&D Pattern Design in RCES with Modeling
and Formal Approaches. In ACM/IEEE International Conference on
Model Driven Engineering Languages and Systems (MoDELS), pages
319–333, 2011.
[121] Gabriel Pedroza, Ludovic Apvrille, and Daniel Knorreck. AVATAR: A
SysML Environment for the Formal Verification of Safety and Security
Properties. In IEEE International Conference on New Technologies
of Distributed Systems (NOTERE), pages 1 – 10, 2011.
[122] Anton V. Uzunov, Eduardo B. Fernandez, and Katrina Falkner. Engineering Security into Distributed Systems: A Survey of Methodologies.
Journal of Universal Computer Science, 18(20):2920–3006, 2012.
[123] Jose Fran. Ruiz, Rajesh Harjani, Antonio Mana, Vasily Desnitsky, Igor
Kotenko, and Andrey Chechulin. A Methodology for the Analysis and
Modeling of Security Threats and Attacks for Systems of Embedded
Components. In Euromicro International Conference on Parallel, Distributed and Network-Based Processing (PDP), pages 261 – 268. IEEE
Computer Society, 2012.
[124] Yomna Ali, Sherif El-Kassas, and Mohy Mahmoud. A Rigorous
Methodology for Security Architecture Modeling and Verification. In
International Conference on System Sciences (HICSS), pages 1–10,
2009.
[125] Brahim Hamid, Nicolas Desnos, Cyril Grepet, and Christophe Jouvray. Model-Based Security and Dependability Patterns in RCES
– the TERESA Approach. In International Workshop on Security and Dependability for Resource Constrained Embedded Systems
(S&D4RCES). ACM, 2010.
BIBLIOGRAPHY
109
[126] Matthew Eby, Jan Werner, Gabor Karsai, and Akos Ledeczi. Integrating Security Modeling into Embedded System Design. IEEE International Conference and Workshops on the Engineering of ComputerBased Systems (ECBS), pages 221 – 228, March 2007.
[127] Eduardo B. Fernandez, Hironori Washizaki, Nobukazu Yoshioka, Atsuto Kubo, and Yoshiaki Fukazawa. Classifying Security Patterns.
In Asia-Pacific Web Conference on Progress in WWW Research and
Development (APWeb), pages 342–347, 2008.
[128] Michael VanHilst, Eduardo B. Fernández, and Fabrı́cio A. Braz. A
Multi-Dimensional Classification for Users of Security Patterns. Journal of Research and Practice in Information Technology, Australian
Computer Society Inc., 20(1), 2008.
[129] Munawar Hafiz, Paul Adamczyk, and Ralph E. Johnson. Organizing
Security Patterns. In 4, editor, Software, IEEE, volume 24, pages
52–60, 2007.
[130] Hironori Washizaki, Eduardo B. Fernandez, Katsuhisa Maruyama, Atsuto Kubo, and Nobukazu Yoshioka. Improving the Classification of
Security Patterns. In International Workshop on Database and Expert
Systems Application (DEXA), pages 165–170, 2009.
[131] Alberts Christopher, Sandra Behrens, Richard Pethia, and William
Wilson. Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) Framework, Version 1.0. Technical report, Technical Report CMU/SEI-99-TR-017. ESC-TR-99-017, Carnegie Mellon.
Software Engineering Institute, 1999.
[132] CCTA Risk Analysis and Management Method. http://www.cramm.
com, last visited october 2013.
[133] Dragan Gasevic, Dragan Djuric, and Vladan Devedzic. Model Driven
Engineering and Ontology Development. Springer Publishing Company, 2009.
[134] Phil Tetlow, Jeff Z. Pan, Daniel Oberle, Evan Wallace, Michael
Uschold, and Elisa Kendall. Ontology Driven Architectures and Potential Uses of the Semantic Web in Systems and Software Engineering.
http://www.w3.org/2001/sw/BestPractices/SE/ODA/, last visited
may 2013.
[135] Tobias Walter, Fernando Silva Parreiras, and Steffen Staab. An
Ontology-based Framework for Domain-specific Modeling. In Softw.
Syst. Model. Springer-Verlag, 2012.
110
BIBLIOGRAPHY
[136] Jianjun Yi, Ying Cheng, and Chunhua Gu. A Reconfigurable Design Method of Embedded Control System based on Ontology. In International Conference on E-Product E-Service and E-Entertainment
(ICEEE), pages 1 – 4. IEEE, 2010.
[137] Dennis Wagelaar. Platform Ontologies for the Model-Driven Architecture. PhD thesis, 2010.
[138] Bedir Tekinerdoğan, Sevcan Bilir, and Cem Abatlevi. Integrating Platform Selection Rules in the Model Driven Architecture Approach. In
European conference on Model Driven Architecture: foundations and
Applications (MDAFA), pages 159–173. Springer-Verlag, 2003.
[139] Thomas Robert and Vincent Perrier. CoFluent Methodology for UML.
A CoFluent Design, White Paper, 2010.
[140] Éric Piel, Samy Meftali, Jean luc Dekeyser, Rabie Ben Atitallah, Smaı̈l
Niar, Anne Etien, and Pierre Boulet. Gaspard2: from MARTE to
SystemC Simulation. In Workshop on Modeling and Analysis of RealTime and Embedded Systems (at DATE), 2008.
[141] Object Management Group. Systems Modeling Language: verstion
1.3, 2012.
[142] Murray Woodside, Dorina C. Petriu, Dorin B. Petriu, Jing Xu, Tauseef
Israr, Geri Georg, Robert France, James M. Bieman, Siv Hilde Houmb,
and Jan Jürjens. Performance Analysis of Security Aspects by Weaving Scenarios Extracted from UML models. Journal of Systems and
Software, Elsevier Science Inc., 2009.
[143] Murray Woodside, Dorina C. Petriu, Dorin B. Petriu, Hui Shen,
Toqeer Israr, and Jose Merseguer. Performance by Unified Model
Analysis (PUMA). In ACM Workhsop on Software and Performance
(WOSP), pages 1–12. ACM, 2005.
[144] Marco A. Wehrmeister, Edison P. Freitas, Carlos E. Pereira, and Franz
Rammig. GenERTiCA: A Tool for Code Generation and Aspects
Weaving. In IEEE International Symposium on Object Oriented RealTime Distributed Computing (ISORC), pages 234 – 238, 2008.
[145] Egor Bondarev, Michel Chaudron, and Peter H. N. de With. CARAT:
a Toolkit for Design and Performance Analysis of Component-Based
Embedded Systems. In The conference on Design, automation and
test in Europe (DATE), pages 1024–1029. EDA Consortium, 2007.
[146] Federico Ciccozzi, Antonio Cicchetti, and Mikael Sjödin. Round-trip
Support for Extra-functional Property Management in Model-driven
Engineering of Embedded Systems. Information and Software Technology, Elsevier, pages 1085–1100, 2012.
BIBLIOGRAPHY
111
[147] ARTEMIS-JU-216682, CHESS. http://chess-project.ning.com/,
last visited March 2013.
Department of Computer and Information Science
Linköpings universitet
Licentiate Theses
Linköpings Studies in Science and Technology
Faculty of Arts and Sciences
No 17
No 28
No 29
No 48
No 52
No 60
No 71
No 72
No 73
No 74
No 104
No 108
No 111
No 113
No 118
No 126
No 127
No 139
No 140
No 146
No 150
No 165
No 166
No 174
No 177
No 181
No 184
No 187
No 189
No 196
No 197
No 203
No 212
No 230
No 237
No 250
No 253
No 260
No 283
No 298
No 318
No 319
No 326
No 328
No 333
No 335
No 348
No 352
No 371
No 378
Vojin Plavsic: Interleaved Processing of Non-Numerical Data Stored on a Cyclic Memory. (Available at: FOA,
Box 1165, S-581 11 Linköping, Sweden. FOA Report B30062E)
Arne Jönsson, Mikael Patel: An Interactive Flowcharting Technique for Communicating and Realizing Algorithms, 1984.
Johnny Eckerland: Retargeting of an Incremental Code Generator, 1984.
Henrik Nordin: On the Use of Typical Cases for Knowledge-Based Consultation and Teaching, 1985.
Zebo Peng: Steps Towards the Formalization of Designing VLSI Systems, 1985.
Johan Fagerström: Simulation and Evaluation of Architecture based on Asynchronous Processes, 1985.
Jalal Maleki: ICONStraint, A Dependency Directed Constraint Maintenance System, 1987.
Tony Larsson: On the Specification and Verification of VLSI Systems, 1986.
Ola Strömfors: A Structure Editor for Documents and Programs, 1986.
Christos Levcopoulos: New Results about the Approximation Behavior of the Greedy Triangulation, 1986.
Shamsul I. Chowdhury: Statistical Expert Systems - a Special Application Area for Knowledge-Based Computer
Methodology, 1987.
Rober Bilos: Incremental Scanning and Token-Based Editing, 1987.
Hans Block: SPORT-SORT Sorting Algorithms and Sport Tournaments, 1987.
Ralph Rönnquist: Network and Lattice Based Approaches to the Representation of Knowledge, 1987.
Mariam Kamkar, Nahid Shahmehri: Affect-Chaining in Program Flow Analysis Applied to Queries of Programs, 1987.
Dan Strömberg: Transfer and Distribution of Application Programs, 1987.
Kristian Sandahl: Case Studies in Knowledge Acquisition, Migration and User Acceptance of Expert Systems,
1987.
Christer Bäckström: Reasoning about Interdependent Actions, 1988.
Mats Wirén: On Control Strategies and Incrementality in Unification-Based Chart Parsing, 1988.
Johan Hultman: A Software System for Defining and Controlling Actions in a Mechanical System, 1988.
Tim Hansen: Diagnosing Faults using Knowledge about Malfunctioning Behavior, 1988.
Jonas Löwgren: Supporting Design and Management of Expert System User Interfaces, 1989.
Ola Petersson: On Adaptive Sorting in Sequential and Parallel Models, 1989.
Yngve Larsson: Dynamic Configuration in a Distributed Environment, 1989.
Peter Åberg: Design of a Multiple View Presentation and Interaction Manager, 1989.
Henrik Eriksson: A Study in Domain-Oriented Tool Support for Knowledge Acquisition, 1989.
Ivan Rankin: The Deep Generation of Text in Expert Critiquing Systems, 1989.
Simin Nadjm-Tehrani: Contributions to the Declarative Approach to Debugging Prolog Programs, 1989.
Magnus Merkel: Temporal Information in Natural Language, 1989.
Ulf Nilsson: A Systematic Approach to Abstract Interpretation of Logic Programs, 1989.
Staffan Bonnier: Horn Clause Logic with External Procedures: Towards a Theoretical Framework, 1989.
Christer Hansson: A Prototype System for Logical Reasoning about Time and Action, 1990.
Björn Fjellborg: An Approach to Extraction of Pipeline Structures for VLSI High-Level Synthesis, 1990.
Patrick Doherty: A Three-Valued Approach to Non-Monotonic Reasoning, 1990.
Tomas Sokolnicki: Coaching Partial Plans: An Approach to Knowledge-Based Tutoring, 1990.
Lars Strömberg: Postmortem Debugging of Distributed Systems, 1990.
Torbjörn Näslund: SLDFA-Resolution - Computing Answers for Negative Queries, 1990.
Peter D. Holmes: Using Connectivity Graphs to Support Map-Related Reasoning, 1991.
Olof Johansson: Improving Implementation of Graphical User Interfaces for Object-Oriented Knowledge- Bases,
1991.
Rolf G Larsson: Aktivitetsbaserad kalkylering i ett nytt ekonomisystem, 1991.
Lena Srömbäck: Studies in Extended Unification-Based Formalism for Linguistic Description: An Algorithm for
Feature Structures with Disjunction and a Proposal for Flexible Systems, 1992.
Mikael Pettersson: DML-A Language and System for the Generation of Efficient Compilers from Denotational
Specification, 1992.
Andreas Kågedal: Logic Programming with External Procedures: an Implementation, 1992.
Patrick Lambrix: Aspects of Version Management of Composite Objects, 1992.
Xinli Gu: Testability Analysis and Improvement in High-Level Synthesis Systems, 1992.
Torbjörn Näslund: On the Role of Evaluations in Iterative Development of Managerial Support Systems, 1992.
Ulf Cederling: Industrial Software Development - a Case Study, 1992.
Magnus Morin: Predictable Cyclic Computations in Autonomous Systems: A Computational Model and Implementation, 1992.
Mehran Noghabai: Evaluation of Strategic Investments in Information Technology, 1993.
Mats Larsson: A Transformational Approach to Formal Digital System Design, 1993.
No 380
No 381
No 383
No 386
No 398
No 402
No 406
No 414
No 417
No 436
No 437
No 440
FHS 3/94
FHS 4/94
No 441
No 446
No 450
No 451
No 452
No 455
FHS 5/94
No 462
No 463
No 464
No 469
No 473
No 475
No 476
No 478
FHS 7/95
No 482
No 488
No 489
No 497
No 498
No 503
FHS 8/95
FHS 9/95
No 513
No 517
No 518
No 522
No 538
No 545
No 546
FiF-a 1/96
No 549
No 550
No 557
No 558
No 561
No 563
Johan Ringström: Compiler Generation for Parallel Languages from Denotational Specifications, 1993.
Michael Jansson: Propagation of Change in an Intelligent Information System, 1993.
Jonni Harrius: An Architecture and a Knowledge Representation Model for Expert Critiquing Systems, 1993.
Per Österling: Symbolic Modelling of the Dynamic Environments of Autonomous Agents, 1993.
Johan Boye: Dependency-based Groudness Analysis of Functional Logic Programs, 1993.
Lars Degerstedt: Tabulated Resolution for Well Founded Semantics, 1993.
Anna Moberg: Satellitkontor - en studie av kommunikationsmönster vid arbete på distans, 1993.
Peter Carlsson: Separation av företagsledning och finansiering - fallstudier av företagsledarutköp ur ett agentteoretiskt perspektiv, 1994.
Camilla Sjöström: Revision och lagreglering - ett historiskt perspektiv, 1994.
Cecilia Sjöberg: Voices in Design: Argumentation in Participatory Development, 1994.
Lars Viklund: Contributions to a High-level Programming Environment for a Scientific Computing, 1994.
Peter Loborg: Error Recovery Support in Manufacturing Control Systems, 1994.
Owen Eriksson: Informationssystem med verksamhetskvalitet - utvärdering baserat på ett verksamhetsinriktat och
samskapande perspektiv, 1994.
Karin Pettersson: Informationssystemstrukturering, ansvarsfördelning och användarinflytande - En komparativ
studie med utgångspunkt i två informationssystemstrategier, 1994.
Lars Poignant: Informationsteknologi och företagsetablering - Effekter på produktivitet och region, 1994.
Gustav Fahl: Object Views of Relational Data in Multidatabase Systems, 1994.
Henrik Nilsson: A Declarative Approach to Debugging for Lazy Functional Languages, 1994.
Jonas Lind: Creditor - Firm Relations: an Interdisciplinary Analysis, 1994.
Martin Sköld: Active Rules based on Object Relational Queries - Efficient Change Monitoring Techniques, 1994.
Pär Carlshamre: A Collaborative Approach to Usability Engineering: Technical Communicators and System
Developers in Usability-Oriented Systems Development, 1994.
Stefan Cronholm: Varför CASE-verktyg i systemutveckling? - En motiv- och konsekvensstudie avseende
arbetssätt och arbetsformer, 1994.
Mikael Lindvall: A Study of Traceability in Object-Oriented Systems Development, 1994.
Fredrik Nilsson: Strategi och ekonomisk styrning - En studie av Sandviks förvärv av Bahco Verktyg, 1994.
Hans Olsén: Collage Induction: Proving Properties of Logic Programs by Program Synthesis, 1994.
Lars Karlsson: Specification and Synthesis of Plans Using the Features and Fluents Framework, 1995.
Ulf Söderman: On Conceptual Modelling of Mode Switching Systems, 1995.
Choong-ho Yi: Reasoning about Concurrent Actions in the Trajectory Semantics, 1995.
Bo Lagerström: Successiv resultatavräkning av pågående arbeten. - Fallstudier i tre byggföretag, 1995.
Peter Jonsson: Complexity of State-Variable Planning under Structural Restrictions, 1995.
Anders Avdic: Arbetsintegrerad systemutveckling med kalkylprogram, 1995.
Eva L Ragnemalm: Towards Student Modelling through Collaborative Dialogue with a Learning Companion,
1995.
Eva Toller: Contributions to Parallel Multiparadigm Languages: Combining Object-Oriented and Rule-Based
Programming, 1995.
Erik Stoy: A Petri Net Based Unified Representation for Hardware/Software Co-Design, 1995.
Johan Herber: Environment Support for Building Structured Mathematical Models, 1995.
Stefan Svenberg: Structure-Driven Derivation of Inter-Lingual Functor-Argument Trees for Multi-Lingual
Generation, 1995.
Hee-Cheol Kim: Prediction and Postdiction under Uncertainty, 1995.
Dan Fristedt: Metoder i användning - mot förbättring av systemutveckling genom situationell metodkunskap och
metodanalys, 1995.
Malin Bergvall: Systemförvaltning i praktiken - en kvalitativ studie avseende centrala begrepp, aktiviteter och
ansvarsroller, 1995.
Joachim Karlsson: Towards a Strategy for Software Requirements Selection, 1995.
Jakob Axelsson: Schedulability-Driven Partitioning of Heterogeneous Real-Time Systems, 1995.
Göran Forslund: Toward Cooperative Advice-Giving Systems: The Expert Systems Experience, 1995.
Jörgen Andersson: Bilder av småföretagares ekonomistyrning, 1995.
Staffan Flodin: Efficient Management of Object-Oriented Queries with Late Binding, 1996.
Vadim Engelson: An Approach to Automatic Construction of Graphical User Interfaces for Applications in
Scientific Computing, 1996.
Magnus Werner : Multidatabase Integration using Polymorphic Queries and Views, 1996.
Mikael Lind: Affärsprocessinriktad förändringsanalys - utveckling och tillämpning av synsätt och metod, 1996.
Jonas Hallberg: High-Level Synthesis under Local Timing Constraints, 1996.
Kristina Larsen: Förutsättningar och begränsningar för arbete på distans - erfarenheter från fyra svenska företag.
1996.
Mikael Johansson: Quality Functions for Requirements Engineering Methods, 1996.
Patrik Nordling: The Simulation of Rolling Bearing Dynamics on Parallel Computers, 1996.
Anders Ekman: Exploration of Polygonal Environments, 1996.
Niclas Andersson: Compilation of Mathematical Models to Parallel Code, 1996.
No 567
No 575
No 576
No 587
No 589
No 591
No 595
No 597
No 598
No 599
No 607
No 609
FiF-a 4
FiF-a 6
No 615
No 623
No 626
No 627
No 629
No 631
No 639
No 640
No 643
No 653
FiF-a 13
No 674
No 676
No 668
No 675
FiF-a 14
No 695
No 700
FiF-a 16
No 712
No 719
No 723
No 725
No 730
No 731
No 733
No 734
FiF-a 21
FiF-a 22
No 737
No 738
FiF-a 25
No 742
No 748
No 751
No 752
No 753
Johan Jenvald: Simulation and Data Collection in Battle Training, 1996.
Niclas Ohlsson: Software Quality Engineering by Early Identification of Fault-Prone Modules, 1996.
Mikael Ericsson: Commenting Systems as Design Support—A Wizard-of-Oz Study, 1996.
Jörgen Lindström: Chefers användning av kommunikationsteknik, 1996.
Esa Falkenroth: Data Management in Control Applications - A Proposal Based on Active Database Systems,
1996.
Niclas Wahllöf: A Default Extension to Description Logics and its Applications, 1996.
Annika Larsson: Ekonomisk Styrning och Organisatorisk Passion - ett interaktivt perspektiv, 1997.
Ling Lin: A Value-based Indexing Technique for Time Sequences, 1997.
Rego Granlund: C3Fire - A Microworld Supporting Emergency Management Training, 1997.
Peter Ingels: A Robust Text Processing Technique Applied to Lexical Error Recovery, 1997.
Per-Arne Persson: Toward a Grounded Theory for Support of Command and Control in Military Coalitions, 1997.
Jonas S Karlsson: A Scalable Data Structure for a Parallel Data Server, 1997.
Carita Åbom: Videomötesteknik i olika affärssituationer - möjligheter och hinder, 1997.
Tommy Wedlund: Att skapa en företagsanpassad systemutvecklingsmodell - genom rekonstruktion, värdering och
vidareutveckling i T50-bolag inom ABB, 1997.
Silvia Coradeschi: A Decision-Mechanism for Reactive and Coordinated Agents, 1997.
Jan Ollinen: Det flexibla kontorets utveckling på Digital - Ett stöd för multiflex? 1997.
David Byers: Towards Estimating Software Testability Using Static Analysis, 1997.
Fredrik Eklund: Declarative Error Diagnosis of GAPLog Programs, 1997.
Gunilla Ivefors: Krigsspel och Informationsteknik inför en oförutsägbar framtid, 1997.
Jens-Olof Lindh: Analysing Traffic Safety from a Case-Based Reasoning Perspective, 1997
Jukka Mäki-Turja:. Smalltalk - a suitable Real-Time Language, 1997.
Juha Takkinen: CAFE: Towards a Conceptual Model for Information Management in Electronic Mail, 1997.
Man Lin: Formal Analysis of Reactive Rule-based Programs, 1997.
Mats Gustafsson: Bringing Role-Based Access Control to Distributed Systems, 1997.
Boris Karlsson: Metodanalys för förståelse och utveckling av systemutvecklingsverksamhet. Analys och värdering
av systemutvecklingsmodeller och dess användning, 1997.
Marcus Bjäreland: Two Aspects of Automating Logics of Action and Change - Regression and Tractability,
1998.
Jan Håkegård: Hierarchical Test Architecture and Board-Level Test Controller Synthesis, 1998.
Per-Ove Zetterlund: Normering av svensk redovisning - En studie av tillkomsten av Redovisningsrådets rekommendation om koncernredovisning (RR01:91), 1998.
Jimmy Tjäder: Projektledaren & planen - en studie av projektledning i tre installations- och systemutvecklingsprojekt, 1998.
Ulf Melin: Informationssystem vid ökad affärs- och processorientering - egenskaper, strategier och utveckling,
1998.
Tim Heyer: COMPASS: Introduction of Formal Methods in Code Development and Inspection, 1998.
Patrik Hägglund: Programming Languages for Computer Algebra, 1998.
Marie-Therese Christiansson: Inter-organisatorisk verksamhetsutveckling - metoder som stöd vid utveckling av
partnerskap och informationssystem, 1998.
Christina Wennestam: Information om immateriella resurser. Investeringar i forskning och utveckling samt i
personal inom skogsindustrin, 1998.
Joakim Gustafsson: Extending Temporal Action Logic for Ramification and Concurrency, 1998.
Henrik André-Jönsson: Indexing time-series data using text indexing methods, 1999.
Erik Larsson: High-Level Testability Analysis and Enhancement Techniques, 1998.
Carl-Johan Westin: Informationsförsörjning: en fråga om ansvar - aktiviteter och uppdrag i fem stora svenska
organisationers operativa informationsförsörjning, 1998.
Åse Jansson: Miljöhänsyn - en del i företags styrning, 1998.
Thomas Padron-McCarthy: Performance-Polymorphic Declarative Queries, 1998.
Anders Bäckström: Värdeskapande kreditgivning - Kreditriskhantering ur ett agentteoretiskt perspektiv, 1998.
Ulf Seigerroth: Integration av förändringsmetoder - en modell för välgrundad metodintegration, 1999.
Fredrik Öberg: Object-Oriented Frameworks - A New Strategy for Case Tool Development, 1998.
Jonas Mellin: Predictable Event Monitoring, 1998.
Joakim Eriksson: Specifying and Managing Rules in an Active Real-Time Database System, 1998.
Bengt E W Andersson: Samverkande informationssystem mellan aktörer i offentliga åtaganden - En teori om
aktörsarenor i samverkan om utbyte av information, 1998.
Pawel Pietrzak: Static Incorrectness Diagnosis of CLP (FD), 1999.
Tobias Ritzau: Real-Time Reference Counting in RT-Java, 1999.
Anders Ferntoft: Elektronisk affärskommunikation - kontaktkostnader och kontaktprocesser mellan kunder och
leverantörer på producentmarknader, 1999.
Jo Skåmedal: Arbete på distans och arbetsformens påverkan på resor och resmönster, 1999.
Johan Alvehus: Mötets metaforer. En studie av berättelser om möten, 1999.
No 754
No 766
No 769
No 775
FiF-a 30
No 787
No 788
No 790
No 791
No 800
No 807
No 809
FiF-a 32
No 808
No 820
No 823
No 832
FiF-a 34
No 842
No 844
FiF-a 37
FiF-a 40
FiF-a 41
No. 854
No 863
No 881
No 882
No 890
FiF-a 47
No 894
No 906
No 917
No 916
FiF-a-49
FiF-a-51
No 919
No 915
No 931
No 933
No 938
No 942
No 956
FiF-a 58
No 964
No 973
No 958
FiF-a 61
No 985
No 982
No 989
No 990
No 991
Magnus Lindahl: Bankens villkor i låneavtal vid kreditgivning till högt belånade företagsförvärv: En studie ur ett
agentteoretiskt perspektiv, 2000.
Martin V. Howard: Designing dynamic visualizations of temporal data, 1999.
Jesper Andersson: Towards Reactive Software Architectures, 1999.
Anders Henriksson: Unique kernel diagnosis, 1999.
Pär J. Ågerfalk: Pragmatization of Information Systems - A Theoretical and Methodological Outline, 1999.
Charlotte Björkegren: Learning for the next project - Bearers and barriers in knowledge transfer within an
organisation, 1999.
Håkan Nilsson: Informationsteknik som drivkraft i granskningsprocessen - En studie av fyra revisionsbyråer,
2000.
Erik Berglund: Use-Oriented Documentation in Software Development, 1999.
Klas Gäre: Verksamhetsförändringar i samband med IS-införande, 1999.
Anders Subotic: Software Quality Inspection, 1999.
Svein Bergum: Managerial communication in telework, 2000.
Flavius Gruian: Energy-Aware Design of Digital Systems, 2000.
Karin Hedström: Kunskapsanvändning och kunskapsutveckling hos verksamhetskonsulter - Erfarenheter från ett
FOU-samarbete, 2000.
Linda Askenäs: Affärssystemet - En studie om teknikens aktiva och passiva roll i en organisation, 2000.
Jean Paul Meynard: Control of industrial robots through high-level task programming, 2000.
Lars Hult: Publika Gränsytor - ett designexempel, 2000.
Paul Pop: Scheduling and Communication Synthesis for Distributed Real-Time Systems, 2000.
Göran Hultgren: Nätverksinriktad Förändringsanalys - perspektiv och metoder som stöd för förståelse och
utveckling av affärsrelationer och informationssystem, 2000.
Magnus Kald: The role of management control systems in strategic business units, 2000.
Mikael Cäker: Vad kostar kunden? Modeller för intern redovisning, 2000.
Ewa Braf: Organisationers kunskapsverksamheter - en kritisk studie av ”knowledge management”, 2000.
Henrik Lindberg: Webbaserade affärsprocesser - Möjligheter och begränsningar, 2000.
Benneth Christiansson: Att komponentbasera informationssystem - Vad säger teori och praktik?, 2000.
Ola Pettersson: Deliberation in a Mobile Robot, 2000.
Dan Lawesson: Towards Behavioral Model Fault Isolation for Object Oriented Control Systems, 2000.
Johan Moe: Execution Tracing of Large Distributed Systems, 2001.
Yuxiao Zhao: XML-based Frameworks for Internet Commerce and an Implementation of B2B
e-procurement,
2001.
Annika Flycht-Eriksson: Domain Knowledge Management in Information-providing Dialogue systems, 2001.
Per-Arne Segerkvist: Webbaserade imaginära organisationers samverkansformer: Informationssystemarkitektur
och aktörssamverkan som förutsättningar för affärsprocesser, 2001.
Stefan Svarén: Styrning av investeringar i divisionaliserade företag - Ett koncernperspektiv, 2001.
Lin Han: Secure and Scalable E-Service Software Delivery, 2001.
Emma Hansson: Optionsprogram för anställda - en studie av svenska börsföretag, 2001.
Susanne Odar: IT som stöd för strategiska beslut, en studie av datorimplementerade modeller av verksamhet som
stöd för beslut om anskaffning av JAS 1982, 2002.
Stefan Holgersson: IT-system och filtrering av verksamhetskunskap - kvalitetsproblem vid analyser och beslutsfattande som bygger på uppgifter hämtade från polisens IT-system, 2001.
Per Oscarsson: Informationssäkerhet i verksamheter - begrepp och modeller som stöd för förståelse av informationssäkerhet och dess hantering, 2001.
Luis Alejandro Cortes: A Petri Net Based Modeling and Verification Technique for Real-Time Embedded
Systems, 2001.
Niklas Sandell: Redovisning i skuggan av en bankkris - Värdering av fastigheter. 2001.
Fredrik Elg: Ett dynamiskt perspektiv på individuella skillnader av heuristisk kompetens, intelligens, mentala
modeller, mål och konfidens i kontroll av mikrovärlden Moro, 2002.
Peter Aronsson: Automatic Parallelization of Simulation Code from Equation Based Simulation Languages, 2002.
Bourhane Kadmiry: Fuzzy Control of Unmanned Helicopter, 2002.
Patrik Haslum: Prediction as a Knowledge Representation Problem: A Case Study in Model Design, 2002.
Robert Sevenius: On the instruments of governance - A law & economics study of capital instruments in limited
liability companies, 2002.
Johan Petersson: Lokala elektroniska marknadsplatser - informationssystem för platsbundna affärer, 2002.
Peter Bunus: Debugging and Structural Analysis of Declarative Equation-Based Languages, 2002.
Gert Jervan: High-Level Test Generation and Built-In Self-Test Techniques for Digital Systems, 2002.
Fredrika Berglund: Management Control and Strategy - a Case Study of Pharmaceutical Drug Development,
2002.
Fredrik Karlsson: Meta-Method for Method Configuration - A Rational Unified Process Case, 2002.
Sorin Manolache: Schedulability Analysis of Real-Time Systems with Stochastic Task Execution Times, 2002.
Diana Szentiványi: Performance and Availability Trade-offs in Fault-Tolerant Middleware, 2002.
Iakov Nakhimovski: Modeling and Simulation of Contacting Flexible Bodies in Multibody Systems, 2002.
Levon Saldamli: PDEModelica - Towards a High-Level Language for Modeling with Partial Differential
Equations, 2002.
Almut Herzog: Secure Execution Environment for Java Electronic Services, 2002.
No 999
No 1000
No 1001
No 988
FiF-a 62
No 1003
No 1005
No 1008
No 1010
No 1015
No 1018
No 1022
FiF-a 65
No 1024
No 1034
No 1033
FiF-a 69
No 1049
No 1052
No 1054
FiF-a 71
No 1055
No 1058
FiF-a 73
No 1079
No 1084
FiF-a 74
No 1094
No 1095
No 1099
No 1110
No 1116
FiF-a 77
No 1126
No 1127
No 1132
No 1130
No 1138
No 1149
No 1156
No 1162
No 1165
FiF-a 84
No 1166
No 1167
No 1168
FiF-a 85
No 1171
FiF-a 86
No 1172
No 1183
No 1184
No 1185
No 1190
Jon Edvardsson: Contributions to Program- and Specification-based Test Data Generation, 2002.
Anders Arpteg: Adaptive Semi-structured Information Extraction, 2002.
Andrzej Bednarski: A Dynamic Programming Approach to Optimal Retargetable Code Generation for Irregular
Architectures, 2002.
Mattias Arvola: Good to use! : Use quality of multi-user applications in the home, 2003.
Lennart Ljung: Utveckling av en projektivitetsmodell - om organisationers förmåga att tillämpa
projektarbetsformen, 2003.
Pernilla Qvarfordt: User experience of spoken feedback in multimodal interaction, 2003.
Alexander Siemers: Visualization of Dynamic Multibody Simulation With Special Reference to Contacts, 2003.
Jens Gustavsson: Towards Unanticipated Runtime Software Evolution, 2003.
Calin Curescu: Adaptive QoS-aware Resource Allocation for Wireless Networks, 2003.
Anna Andersson: Management Information Systems in Process-oriented Healthcare Organisations, 2003.
Björn Johansson: Feedforward Control in Dynamic Situations, 2003.
Traian Pop: Scheduling and Optimisation of Heterogeneous Time/Event-Triggered Distributed Embedded
Systems, 2003.
Britt-Marie Johansson: Kundkommunikation på distans - en studie om kommunikationsmediets betydelse i
affärstransaktioner, 2003.
Aleksandra Tešanovic: Towards Aspectual Component-Based Real-Time System Development, 2003.
Arja Vainio-Larsson: Designing for Use in a Future Context - Five Case Studies in Retrospect, 2003.
Peter Nilsson: Svenska bankers redovisningsval vid reservering för befarade kreditförluster - En studie vid
införandet av nya redovisningsregler, 2003.
Fredrik Ericsson: Information Technology for Learning and Acquiring of Work Knowledge, 2003.
Marcus Comstedt: Towards Fine-Grained Binary Composition through Link Time Weaving, 2003.
Åsa Hedenskog: Increasing the Automation of Radio Network Control, 2003.
Claudiu Duma: Security and Efficiency Tradeoffs in Multicast Group Key Management, 2003.
Emma Eliason: Effektanalys av IT-systems handlingsutrymme, 2003.
Carl Cederberg: Experiments in Indirect Fault Injection with Open Source and Industrial Software, 2003.
Daniel Karlsson: Towards Formal Verification in a Component-based Reuse Methodology, 2003.
Anders Hjalmarsson: Att etablera och vidmakthålla förbättringsverksamhet - behovet av koordination och
interaktion vid förändring av systemutvecklingsverksamheter, 2004.
Pontus Johansson: Design and Development of Recommender Dialogue Systems, 2004.
Charlotte Stoltz: Calling for Call Centres - A Study of Call Centre Locations in a Swedish Rural Region, 2004.
Björn Johansson: Deciding on Using Application Service Provision in SMEs, 2004.
Genevieve Gorrell: Language Modelling and Error Handling in Spoken Dialogue Systems, 2004.
Ulf Johansson: Rule Extraction - the Key to Accurate and Comprehensible Data Mining Models, 2004.
Sonia Sangari: Computational Models of Some Communicative Head Movements, 2004.
Hans Nässla: Intra-Family Information Flow and Prospects for Communication Systems, 2004.
Henrik Sällberg: On the value of customer loyalty programs - A study of point programs and switching costs,
2004.
Ulf Larsson: Designarbete i dialog - karaktärisering av interaktionen mellan användare och utvecklare i en
systemutvecklingsprocess, 2004.
Andreas Borg: Contribution to Management and Validation of Non-Functional Requirements, 2004.
Per-Ola Kristensson: Large Vocabulary Shorthand Writing on Stylus Keyboard, 2004.
Pär-Anders Albinsson: Interacting with Command and Control Systems: Tools for Operators and Designers,
2004.
Ioan Chisalita: Safety-Oriented Communication in Mobile Networks for Vehicles, 2004.
Thomas Gustafsson: Maintaining Data Consistency in Embedded Databases for Vehicular Systems, 2004.
Vaida Jakoniené: A Study in Integrating Multiple Biological Data Sources, 2005.
Abdil Rashid Mohamed: High-Level Techniques for Built-In Self-Test Resources Optimization, 2005.
Adrian Pop: Contributions to Meta-Modeling Tools and Methods, 2005.
Fidel Vascós Palacios: On the information exchange between physicians and social insurance officers in the sick
leave process: an Activity Theoretical perspective, 2005.
Jenny Lagsten: Verksamhetsutvecklande utvärdering i informationssystemprojekt, 2005.
Emma Larsdotter Nilsson: Modeling, Simulation, and Visualization of Metabolic Pathways Using Modelica,
2005.
Christina Keller: Virtual Learning Environments in higher education. A study of students’ acceptance of educational technology, 2005.
Cécile Åberg: Integration of organizational workflows and the Semantic Web, 2005.
Anders Forsman: Standardisering som grund för informationssamverkan och IT-tjänster - En fallstudie baserad på
trafikinformationstjänsten RDS-TMC, 2005.
Yu-Hsing Huang: A systemic traffic accident model, 2005.
Jan Olausson: Att modellera uppdrag - grunder för förståelse av processinriktade informationssystem i
transaktionsintensiva verksamheter, 2005.
Petter Ahlström: Affärsstrategier för seniorbostadsmarknaden, 2005.
Mathias Cöster: Beyond IT and Productivity - How Digitization Transformed the Graphic Industry, 2005.
Åsa Horzella: Beyond IT and Productivity - Effects of Digitized Information Flows in Grocery Distribution, 2005.
Maria Kollberg: Beyond IT and Productivity - Effects of Digitized Information Flows in the Logging Industry,
2005.
David Dinka: Role and Identity - Experience of technology in professional settings, 2005.
No 1191
No 1192
No 1194
No 1204
No 1206
No 1207
No 1209
No 1225
No 1228
No 1229
No 1231
No 1233
No 1244
No 1248
No 1263
FiF-a 90
No 1272
No 1277
No 1283
FiF-a 91
No 1286
No 1293
No 1302
No 1303
No 1305
No 1306
No 1307
No 1309
No 1312
No 1313
No 1317
No 1320
No 1323
No 1329
No 1331
No 1332
No 1333
No 1337
No 1339
No 1351
No 1353
No 1356
No 1359
No 1361
No 1363
No 1371
No 1373
No 1381
No 1386
No 1387
No 1392
No 1393
No 1401
No 1410
No 1421
No 1427
No 1450
No 1459
No 1466
Andreas Hansson: Increasing the Storage Capacity of Recursive Auto-associative Memory by Segmenting Data,
2005.
Nicklas Bergfeldt: Towards Detached Communication for Robot Cooperation, 2005.
Dennis Maciuszek: Towards Dependable Virtual Companions for Later Life, 2005.
Beatrice Alenljung: Decision-making in the Requirements Engineering Process: A Human-centered Approach,
2005.
Anders Larsson: System-on-Chip Test Scheduling and Test Infrastructure Design, 2005.
John Wilander: Policy and Implementation Assurance for Software Security, 2005.
Andreas Käll: Översättningar av en managementmodell - En studie av införandet av Balanced Scorecard i ett
landsting, 2005.
He Tan: Aligning and Merging Biomedical Ontologies, 2006.
Artur Wilk: Descriptive Types for XML Query Language Xcerpt, 2006.
Per Olof Pettersson: Sampling-based Path Planning for an Autonomous Helicopter, 2006.
Kalle Burbeck: Adaptive Real-time Anomaly Detection for Safeguarding Critical Networks, 2006.
Daniela Mihailescu: Implementation Methodology in Action: A Study of an Enterprise Systems Implementation
Methodology, 2006.
Jörgen Skågeby: Public and Non-public gifting on the Internet, 2006.
Karolina Eliasson: The Use of Case-Based Reasoning in a Human-Robot Dialog System, 2006.
Misook Park-Westman: Managing Competence Development Programs in a Cross-Cultural Organisation - What
are the Barriers and Enablers, 2006.
Amra Halilovic: Ett praktikperspektiv på hantering av mjukvarukomponenter, 2006.
Raquel Flodström: A Framework for the Strategic Management of Information Technology, 2006.
Viacheslav Izosimov: Scheduling and Optimization of Fault-Tolerant Embedded Systems, 2006.
Håkan Hasewinkel: A Blueprint for Using Commercial Games off the Shelf in Defence Training, Education and
Research Simulations, 2006.
Hanna Broberg: Verksamhetsanpassade IT-stöd - Designteori och metod, 2006.
Robert Kaminski: Towards an XML Document Restructuring Framework, 2006.
Jiri Trnka: Prerequisites for data sharing in emergency management, 2007.
Björn Hägglund: A Framework for Designing Constraint Stores, 2007.
Daniel Andreasson: Slack-Time Aware Dynamic Routing Schemes for On-Chip Networks, 2007.
Magnus Ingmarsson: Modelling User Tasks and Intentions for Service Discovery in Ubiquitous Computing,
2007.
Gustaf Svedjemo: Ontology as Conceptual Schema when Modelling Historical Maps for Database Storage, 2007.
Gianpaolo Conte: Navigation Functionalities for an Autonomous UAV Helicopter, 2007.
Ola Leifler: User-Centric Critiquing in Command and Control: The DKExpert and ComPlan Approaches, 2007.
Henrik Svensson: Embodied simulation as off-line representation, 2007.
Zhiyuan He: System-on-Chip Test Scheduling with Defect-Probability and Temperature Considerations, 2007.
Jonas Elmqvist: Components, Safety Interfaces and Compositional Analysis, 2007.
Håkan Sundblad: Question Classification in Question Answering Systems, 2007.
Magnus Lundqvist: Information Demand and Use: Improving Information Flow within Small-scale Business
Contexts, 2007.
Martin Magnusson: Deductive Planning and Composite Actions in Temporal Action Logic, 2007.
Mikael Asplund: Restoring Consistency after Network Partitions, 2007.
Martin Fransson: Towards Individualized Drug Dosage - General Methods and Case Studies, 2007.
Karin Camara: A Visual Query Language Served by a Multi-sensor Environment, 2007.
David Broman: Safety, Security, and Semantic Aspects of Equation-Based Object-Oriented Languages and
Environments, 2007.
Mikhail Chalabine: Invasive Interactive Parallelization, 2007.
Susanna Nilsson: A Holistic Approach to Usability Evaluations of Mixed Reality Systems, 2008.
Shanai Ardi: A Model and Implementation of a Security Plug-in for the Software Life Cycle, 2008.
Erik Kuiper: Mobility and Routing in a Delay-tolerant Network of Unmanned Aerial Vehicles, 2008.
Jana Rambusch: Situated Play, 2008.
Martin Karresand: Completing the Picture - Fragments and Back Again, 2008.
Per Nyblom: Dynamic Abstraction for Interleaved Task Planning and Execution, 2008.
Fredrik Lantz: Terrain Object Recognition and Context Fusion for Decision Support, 2008.
Martin Östlund: Assistance Plus: 3D-mediated Advice-giving on Pharmaceutical Products, 2008.
Håkan Lundvall: Automatic Parallelization using Pipelining for Equation-Based Simulation Languages, 2008.
Mirko Thorstensson: Using Observers for Model Based Data Collection in Distributed Tactical Operations, 2008.
Bahlol Rahimi: Implementation of Health Information Systems, 2008.
Maria Holmqvist: Word Alignment by Re-using Parallel Phrases, 2008.
Mattias Eriksson: Integrated Software Pipelining, 2009.
Annika Öhgren: Towards an Ontology Development Methodology for Small and Medium-sized Enterprises,
2009.
Rickard Holsmark: Deadlock Free Routing in Mesh Networks on Chip with Regions, 2009.
Sara Stymne: Compound Processing for Phrase-Based Statistical Machine Translation, 2009.
Tommy Ellqvist: Supporting Scientific Collaboration through Workflows and Provenance, 2009.
Fabian Segelström: Visualisations in Service Design, 2010.
Min Bao: System Level Techniques for Temperature-Aware Energy Optimization, 2010.
Mohammad Saifullah: Exploring Biologically Inspired Interactive Networks for Object Recognition, 2011
No 1468
No 1469
No 1476
No 1481
No 1485
FiF-a 101
No 1490
No 1503
No 1504
No 1506
No 1507
No 1509
No 1510
No 1513
No 1523
No 1550
No 1558
No 1582
No 1586
No 1588
No 1589
No 1592
No 1606
No 1624
Qiang Liu: Dealing with Missing Mappings and Structure in a Network of Ontologies, 2011.
Ruxandra Pop: Mapping Concurrent Applications to Multiprocessor Systems with Multithreaded Processors and
Network on Chip-Based Interconnections, 2011.
Per-Magnus Olsson: Positioning Algorithms for Surveillance Using Unmanned Aerial Vehicles, 2011.
Anna Vapen: Contributions to Web Authentication for Untrusted Computers, 2011.
Loove Broms: Sustainable Interactions: Studies in the Design of Energy Awareness Artefacts, 2011.
Johan Blomkvist: Conceptualising Prototypes in Service Design, 2011.
Håkan Warnquist: Computer-Assisted Troubleshooting for Efficient Off-board Diagnosis, 2011.
Jakob Rosén: Predictable Real-Time Applications on Multiprocessor Systems-on-Chip, 2011.
Usman Dastgeer: Skeleton Programming for Heterogeneous GPU-based Systems, 2011.
David Landén: Complex Task Allocation for Delegation: From Theory to Practice, 2011.
Kristian Stavåker: Contributions to Parallel Simulation of Equation-Based Models on
Graphics Processing Units, 2011.
Mariusz Wzorek: Selected Aspects of Navigation and Path Planning in Unmanned Aircraft Systems, 2011.
Piotr Rudol: Increasing Autonomy of Unmanned Aircraft Systems Through the Use of Imaging Sensors, 2011.
Anders Carstensen: The Evolution of the Connector View Concept: Enterprise Models for Interoperability
Solutions in the Extended Enterprise, 2011.
Jody Foo: Computational Terminology: Exploring Bilingual and Monolingual Term Extraction, 2012.
Anders Fröberg: Models and Tools for Distributed User Interface Development, 2012.
Dimitar Nikolov: Optimizing Fault Tolerance for Real-Time Systems, 2012.
Dennis Andersson: Mission Experience: How to Model and Capture it to Enable Vicarious Learning, 2013.
Massimiliano Raciti: Anomaly Detection and its Adaptation: Studies on Cyber-physical Systems, 2013.
Banafsheh Khademhosseinieh: Towards an Approach for Efficiency Evaluation of
Enterprise Modeling Methods, 2013.
Amy Rankin: Resilience in High Risk Work: Analysing Adaptive Performance, 2013.
Martin Sjölund: Tools for Understanding, Debugging, and Simulation Performance Improvement of EquationBased Models, 2013.
Karl Hammar: Towards an Ontology Design Pattern Quality Model, 2013.
Maria Vasilevskaya: Designing Security-enhanced Embedded Systems: Bridging Two Islands of Expertise, 2013.
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Related manuals

Download PDF

advertisement