Document title
Author
Version
Erkki Jantunen
1.0
Date
Contact
Status
2014-01-30
Erkki.Jantunen@vtt.fi
final
DELIVERABLE D6.2 of WP 6
Page:
1 (13)
DELIVERABLE D6.2 of Work Package 6:
Updated technology analysis, state of the art
and technical property requirements report
Work package leader:
Olli Ventä
Olli.Venta@vtt.fi
Abstract
This document is an updated version the deliverable D6.1. This document describes the principles how the
technology analysis, state of the art and technical property requirements reports deliverable D6.1 and D6.2 are
formed of a number of production objects. The principle of collecting the State of the Art material in Task 6.1
is heavily linked to the work carried out in Task 6.2 Requirements. In fact the Requirements defined by the
partners of the Arrowhead project form the skeleton of D6.1 and D6.2 as the defined technological Sub-Categories make up the list of production objects this description now formally introduces. Consequently, it can be
said that the Requirements definition leads the writing of the State of the Art reports and not the other way
around.
ARTEMIS Innovation Pilot Project: Arrowhead
THEME [SP1-JTI-ARTEMIS-2012-AIPP4 SP1-JTI-ARTEMIS-2012-AIPP6] [Production and Energy System Automation Intelligent-Built environment and urban infrastructure for sustainable and friendly cities]. The research leading to these results has received funding from the ARTEMIS Joint Undertaking and from the national programs/funding authorities.
Grant agreement no: 332987. Project Coordinator: Professor Jerker Delsing | Luleå University of Technology
www.arrowhead.eu
Document title
Author
Version
Erkki Jantunen
1.0
Date
Contact
Status
2014-01-30
Erkki.Jantunen@vtt.fi
final
DELIVERABLE D6.2 of WP 6
Page:
2 (13)
Table of Contents
1.
Introduction ...................................................................................................................................... 3
1.1. Benefit of existing level of technology focused on Arrowhead purposes ........................................... 3
1.2. Categories and subcategories of state-of-art topics, phasing and managing the editing.................... 3
1.3. Format of State-of-art reports ........................................................................................................... 4
2.
State of the Art.................................................................................................................................. 5
2.1. State of the Art Structure .................................................................................................................. 5
2.1.1.
Categories and Sub-Categories ...............................................................................................................5
2.1.2.
Defined State of the Art structure with delivery date information ........................................................6
2.2. State of the Art results ...................................................................................................................... 8
2.2.1.
Energy domain communication protocols and information models standards within the residential
environment ..........................................................................................................................................................8
2.2.2.
Service Oriented Documentation Methodologies ..................................................................................8
2.2.3.
Safety/Dependability analysis methods..................................................................................................8
2.2.4.
Experiences of SOA core services in military applications ......................................................................9
3.
Technical property requirements ...................................................................................................... 9
3.1. Requirements elicitation ................................................................................................................... 9
3.1.1.
The Principles of the Requirement Matrix ............................................................................................10
3.1.2.
The Requirements Elicitation Process Plan ...........................................................................................10
3.1.3.
Status and Statistics for Requirements .................................................................................................12
3.1.4.
Requirement Elicitation Time Plan........................................................................................................12
3.2. Requirements .................................................................................................................................. 13
4.
Appendixes ..................................................................................................................................... 13
5.
Conclusions ..................................................................................................................................... 13
6.
Revision history ............................................................................................................................... 13
6.1. Contributing and reviewing partners ...................................................... Error! Bookmark not defined.
6.2. Amendments................................................................................................................................... 13
6.3. Quality Assurance ........................................................................................................................... 13
www.arrowhead.eu
Document title
Author
Version
Erkki Jantunen
1.0
Date
Contact
Status
2014-01-30
Erkki.Jantunen@vtt.fi
final
DELIVERABLE D6.2 of WP 6
Page:
3 (13)
1. Introduction
1.1. Benefit of existing level of technology focused on Arrowhead
purposes
It is of vital importance for any research project to base itself to the existing technological environment in order to guarantee that the research work is not repetition of something that has already been
developed and that the project actually enables a leap forward in scientific sense. At the same time
it should be kept in mind that we do not intend to edit a voluminous and yet-another-textbook of all
kinds of interesting technologies but rather to indicate the outstanding sources of descriptions, regarding the so-called common modern knowledge based on global literature and past projects and
the status among the Arrowhead partners who are among the most significant developers and beneficiaries of these technologies.
The spectrum of technologies and domains potentially interesting here is enormous and we have
chosen a practical pilot-driven and focusing on essentials strategy. The requirements elicitation process carried out by task 6.2 now guides our top-down and inside-out state-of-art selection process of
task 6.1 (cf. appendix 1). The rationale is as follows: The piloting work-packages, WP1-WP5, give
out application-oriented requirements, starting from most significant and expected to be elaborated
throughout pilot generations. 2) These requirements are interpreted to technological requirements as
input to the technical work packages, WP7-WP9, to eventually and by pilot generations provide the
technologies to carry out the pilots. Via the iterative work of both the piloting work packages and
the technical work packages, both at consortium work meetings and else, we have obtained the initial
definitions of topics to be included in the state-of-art outcome of the Arrowhead project. In the course
of the 1st generation of the projects (M1-M18) the set of state-of-art topics shall reach its practical
limits regarding importance and focus, as indicated by the pilot driven nature of Arrowhead. The
first set of these deliverables have been reported in Deliverable D6.1 and are not repeated in this
document.
1.2. Categories and subcategories of state-of-art topics, phasing
and managing the editing
The outline of the State of the Art reporting has been defined in D6.1 Deliverable and is partially
repeated also in this document. The definition is based on the Requirements that the participating
companies have defined in Task 6.2. In addition the leading definition work of Work Package 1 has
given further basis for this report. The purpose is to write a deliverable report of all the Sub-Categories that the partners have defined Requirements for. The Sub-Category reports will finally be
grouped into Category deliverable reports according to the definition in this report. It is expected that
the leading role in the writing will be taken by the partner who has the highest number of man months
of those partners interested in the specific Sub-Category. However, the leading role means in this
context that the partner takes the responsibility of making the Sub-Category deliverable to come true.
Consequently, the responsible partner might not do much of the writing as in many cases it might be
logical that the Universities and Research Organizations would do most of the writing. Also, as the
very simple principle of defining the responsibilities would have led to a situation that some partners
would have had quite a high number of responsibilities some discussions have taken place in order
to share the responsibilities more evenly and this report actually represents the result after those
discussions. The responsibility definition of the Category summary level follows the same principle
www.arrowhead.eu
Document title
Author
Version
Erkki Jantunen
1.0
Date
Contact
Status
2014-01-30
Erkki.Jantunen@vtt.fi
final
DELIVERABLE D6.2 of WP 6
Page:
4 (13)
i.e. the partner that has the highest number of man months in a Category will take the integration
responsibility.
The State of the Art reporting in Task 6.1 will take place in three phases (delivery months 7 (D6.1),
11 (D6.2), and 16 (D6.3)). Those state of the art deliverables that might miss the delivery date are
reported in the following deliverable and consequently all those Deliverable reports that have not
been part of D6.1 or this document will be reported in D6.3. In case the need to do further State of
the Art definition after project month 16 should arise that work can be done in some other technology
Work Package such as WP11.
1.3. Format of State-of-art reports
Each sub-category description is expected and advised to include the following subtitles and respective sections:

Abstract

Introduction

o
Brief introduction of the technology
o
Link and role in Arrowhead
Relevant literature review
o

Timeline
o

Most noticeable events in the development of the technology with prognosis of the
future
Conclusion
o

Important to recognise existing reviews, books and standards (no need to re-peat the
exiting text)
Emphasis in predicting the future
Reference list
The State of the Art reports should not have a great number of pages with repetition of text from
other sources. On the order of ten pages about each of the covered technologies might be the optimal
length however keeping in mind that the maturity of the technology and the current phase of development might give reason for considerable variation in length. Also, the idea is to refer to existing
previous review works, books, articles, projects, and standards all the time without unnecessary repetition. It is also aimed that a lot of focus is given to the prediction of the future i.e. how the specific
technology is expected to develop.
In addition to Requirements based on State of Art Deliverables Outlined in this Deliverable some
other State of the Art Deliverables will be created based on technological basis defined by the Universities and Research Organisations.
www.arrowhead.eu
Document title
Author
Version
Erkki Jantunen
1.0
Date
Contact
Status
2014-01-30
Erkki.Jantunen@vtt.fi
final
DELIVERABLE D6.2 of WP 6
Page:
5 (13)
2. State of the Art
2.1. State of the Art Structure
The State of the Art report aims to cover all the relevant technologies of Arrowhead project. The
structure of the report follows that of the Requirements table gathered by Sintef based on the information received from the partners. All of the separate State of the Art deliverables are considered as
appendices of this document but not included in the same file but published as separate documents.
2.1.1. Categories and Sub-Categories
The Categories and Sub-Categories that the partners have indicated to be interested in during the
Requirements definition process are shown in Table 1.
Table 1
Categories and Sub-Categories
Category
Sub-Category
Analytic calculations
Asset Management
Analytic calculations
Control
Analytic calculations
Energy Management
Analytic calculations
Forecasting
Analytic calculations
Virtual improved sensors
Architectural requirements
Platform hardware (gateway)
Architectural requirements
Sensor hardware and infrastructure and measuring
Architectural requirements
Design tools
Dependability
Architectural security analysis
Dependability
Data and information security
Dependability
Device and service security
Dependability
Socio-technical dimension of security (e.g. privacy)
Dependability
Safety and reliability (security impact on safety)
Dependability
Maintenance Support
Energy management of embedded sensors
Energy management in embedded devices
Interoperability and Integrability
Communication between systems (service layer)
www.arrowhead.eu
Document title
Author
Version
Erkki Jantunen
1.0
Date
Contact
Status
2014-01-30
Erkki.Jantunen@vtt.fi
final
DELIVERABLE D6.2 of WP 6
Page:
6 (13)
Categories and Sub-Categories
Category
Sub-Category
Interoperability and Integrability
Definition of applicative Web Services
Interoperability and Integrability
Design for interoperability
Interoperability and Integrability
Wireless integration API
Interoperability and Integrability
Legacy integration
Interoperability and Integrability
Service brokerage
Standards
Applicative standards
Standards
Communication between systems (service layer)
(standards)
Standards
Interoperability guidelines
Standards
Safety standards
Standards
Wireless communication standards
Wireless sensors and communication
Robustness
Wireless sensors and communication
Standard wireless networks (active and passive)
Wireless sensors and communication
Design and commissioning
Usability
Usability
Quality of Service (response, scalability, perfor- Quality of Service (response, scalability, performance, resilience)
mance, resilience)
2.1.2. Defined State of the Art structure with delivery date information
Table 2 presents a summary of the defined Sub-Categories for which State of the Art Deliverables
will be written. The planned delivery month is shown in the table. The State of the Art Deliverables
will be later collected into larger objects according to the Category structure of the project requirements.
Table 2
SoTA Delivery plan
Sub-category
Delivery Month
Applicative standards
11
Architectural security analysis
7
www.arrowhead.eu
Document title
Author
Version
Erkki Jantunen
1.0
Date
Contact
Status
2014-01-30
Erkki.Jantunen@vtt.fi
final
DELIVERABLE D6.2 of WP 6
Page:
7 (13)
SoTA Delivery plan
Sub-category
Delivery Month
Asset Management
16
Communication between systems (service layer)
11
Communication between systems (service layer) (standards)
11
Control
11
Data and information security
11
Definition of applicative Web Services
11
Design and commissioning
11
Design for interoperability
11
Design tools
11
Device and service security
7
Energy Management
7
Energy management in embedded devices
7
Forecasting
11
Interoperability guidelines
11
Legacy integration
11
Platform hardware (gateway)
16
Quality of Service (response, scalability, performance, resilience) 11
Robustness
11
Safety and reliability (security impact on safety)
11
Safety standards
11
Sensor hardware and infrastructure and measuring
11
Socio-technical dimension of security (e.g. privacy)
16
Standard wireless networks (active and passive)
16
Usability
11
Wireless integration API
11
www.arrowhead.eu
Document title
Author
Version
Erkki Jantunen
1.0
Date
Contact
Status
2014-01-30
Erkki.Jantunen@vtt.fi
final
DELIVERABLE D6.2 of WP 6
Page:
8 (13)
SoTA Delivery plan
Sub-category
Delivery Month
Virtual improved sensors
11
2.2. State of the Art results
This deliverable consists of numerous deliverables listed as appendices of this document but not
included in this same file but as separate files. As explained above the set of deliverables listed in
table two is based on the Requirements table which is also one of the appendices of this document.
The purpose of the State of the Art deliverables is to define the State of the Art status of the relevant
technologies of Arrowhead project. Those deliverables having delivery month 7 are presented in
Deliverable 6.1 and as its appendices and not repeated here in this document.
2.2.1. Energy domain communication protocols and information models
standards within the residential environment
This document describes the most relevant standards and projects related to energy data communication in the residential environment, one of the areas addressed by Arrowhead. The following issues have been analysed:
o
European mandates related to microgrids (mandates for Smart Grids and Smart Meters)
o
Standards for middleware and communication protocols (IEC, IEEE,
CEN/CENELEC/ETSI…)
o
More than 20 EU projects (FP6, FP7 and Artemis) related to microgrids and smart grids.
2.2.2. Service Oriented Documentation Methodologies
One of the objectives of task 6.1 is to document the generic design guideline and design patterns
which shall describe how Arrowhead systems shall interact. This document evaluates suitable technologies methodologies for specification, design, engineering and commissioning of Arrowhead
services.
This appendix represents part of an on-going effort to extensively review the documentation and
development methodologies being used by Arrowhead partners. The result from this work is also
contained on our first proposal to document Arrowhead interfaces, which is contained in another
document.
2.2.3. Safety/Dependability analysis methods
Reliability and safety analyses have a remarkably long history. Already in the 1930s statistical
methods were used for industrial product quality control and for assessing the probability of airplane collisions, later for analysing the German V1 rocket. In the 1950s FMEA was introduced by
the US DOD for reliability analyses of military equipment, FTA was developed later in the 1960s
for reliability assessment of ballistic missiles (Minuteman) and space rockets. In the 1970s risk
analyses were intensively applied to nuclear reactors. The use of risk analyses in the chemical pro-
www.arrowhead.eu
Document title
Author
Version
Erkki Jantunen
1.0
Date
Contact
Status
2014-01-30
Erkki.Jantunen@vtt.fi
final
DELIVERABLE D6.2 of WP 6
Page:
9 (13)
cess industry was strongly encouraged by the Bhopal disaster in 1984. Since the 1990s several industry domains have developed their specific safety standards; first chemical process, space and
avionics industries, in the mid-1990s the machinery industry, later the rail domain, in recent years
the automotive industry. Today, risk analysis methods are also used for process improvement (process FMEA) in order to gain efficiency and to control product quality.
There is a generic functional safety standard [IEC 61508], which has to be applied to potentially
hazardous E/E/PE (electrical, electronic and programmable electronic) equipment in case no other
domain-specific standard is available.
Apart from mere safety aspects, risk analysis methods can also be used for minimizing defects, improving quality and increasing production efficiency. Arrowhead takes into consideration the various aspects that can be treated by applying risk analysis methods. Dependent on the domain where
the Arrowhead-Framework is used, specific standards can be applied. But in any case safety and
reliability analyses as described in the various standards are indispensable, and the minimum
equipment reliability resulting from the safety requirements has to be assessed. Depending on the
specific type of application environment, an adequate selection of the risk analysis methods described will be necessary to improve and evaluate the safety and reliability.
While random faults of hardware components can usually be treated with statistical failure models,
software faults are always deterministic but hard to find due to the complexity of the parallel
threads in continuous time space. Only in rare cases, software correctness can be proven formally;
therefore fault mitigation measures resulting from risk analysis must usually be provided in the system concept. Most of the described analysis methods can be used for both hardware and software,
i.e. to identify effects and costs of their failing.
2.2.4. Experiences of SOA core services in military applications
Even if the military application field is not in the scope of Arrowhead, Arrowhead partners have
valuable experiences in in applying SOA technology in that area. Especially when it comes to the
fairly application independent areas of core services and systems.
Appendix [5] describes experiences and lessons learned from implementation of SOA technology
based solutions with references to the Interoperability design areas as well as the Communication
between system service layer areas. References are or have been openly published and are available
on request.
3. Technical property requirements
3.1. Requirements elicitation
The requirements are organized in one matrix that will evolve over the lifetime of the Arrowhead
project. This deliverable marks an intermediate milestone of the requirements matrix representing a
fairly coherent set of domain requirements as well as some technical requirements.
The purpose of the Requirements Matrix is to compile a structure to support the progress of the
project in the direction of the explicit needs.
www.arrowhead.eu
Document title
Author
Version
Erkki Jantunen
1.0
Date
Contact
Status
2014-01-30
Erkki.Jantunen@vtt.fi
final
DELIVERABLE D6.2 of WP 6
Page:
10 (13)
3.1.1. The Principles of the Requirement Matrix
We decided to collect the requirements in one Excel matrix. Excel was chosen because it is readily
available to all participants and no further tool competence should be needed. Furthermore, Excel
has a number of features that could be used to manage the requirements.
The requirements were kept in one tab of the Excel sheet while other tabs were used to contain supplementary information to help participants fill out the Requirements in the best way.
We included a dictionary to explain briefly terms that occur in the requirements, but which may not
be familiar to all the participants.
To further characterize the requirements and help understand whether the requirements are adequate for the fulfilment of the project objectives, we added columns in the matrix for the project
objectives and for domain categories. The project objectives are explained in one separate tab and
the explanations are taken from the Arrowhead Technical Annex.
The categories were developed in a plenary of Arrowhead following the very initial set of requirements having been developed. The tabs on objectives and categories also show simple statistics of
how many requirements have been categorized in the different categories and classified to fulfil the
different project objectives.
3.1.2. The Requirements Elicitation Process Plan
At the start of the Arrowhead project we made a stepwise plan for how the requirements should be
created and developed. In the following we shall explain the stepwise approach.
Domain Task Leaders have
provided some requirements
WP1
req
WP2
req
WP3
req
WP4
req
WP5
req
Categories &
Objectives
added in Graz
T6.2
domain
requirements
Domain req's
assessed for clarity
req
WP7
req
WP8
req
WP9
technical
requirements
Figure 1 The initial structure of the requirements
As depicted in Figure 1 the first step would be that the five domain work packages created a set of
domain requirements which would then be assessed for clarity by the Task 6.2 and these clarified
domain requirements could be understood by the technical work packages.
The domain tasks did produce quite a few requirements on a fair abstraction level, but it is still a
question whether the technical work packages took those requirements as meaningful input.
www.arrowhead.eu
Document title
Author
Version
Erkki Jantunen
1.0
Date
Contact
Status
2014-01-30
Erkki.Jantunen@vtt.fi
final
DELIVERABLE D6.2 of WP 6
Page:
11 (13)
WP1
technology
WP2
WP7
T6.2
technology
WP3
Added after
Luleå meeting
WP8
WP4
WP9
technology
WP5
D6.1 include internal
review of the requirements
We are still not
done here!
technical solutions / promises
Figure 2 The technical response
The next step in the elicitation process was for the technical work packages to respond with "promises" specified as their technical requirements that they would commit to satisfy. The technical
promises would be related to domain requirements by traceability entries in the Requirements Matrix.
This step is not fully finalized, yet, and we see the need to revitalize the creation of technical promises and commitments, and their traces to the associated domain requirements.
There are technical promises available in the Requirements Matrix, but for work packages 7 and 9
the promises are generic and not related to specific domain requirements. WP8 has made a number
of technical requirements that can be interpreted as promises and that are well traced to doamin requirements.
In this step we also conducted a thorough internal review of the domain requirements and these reviews are also documented in the available material. Since D6.1 we have conducted some updates
and evolution of the domain requirements based on the internal reviews.
WP1
assess
req
WP2
assess
req
WP3
assess
req
WP4
assess
req
WP5
assess
req
req
WP7
req
WP8
req
WP9
T6.2
technical
assessments
Figure 3 The assessment of requirements
www.arrowhead.eu
Traces from technical promises
to domain requirements needed
Document title
Author
Version
Erkki Jantunen
1.0
Date
Contact
Status
2014-01-30
Erkki.Jantunen@vtt.fi
final
DELIVERABLE D6.2 of WP 6
Page:
12 (13)
The last step in the approach, which is not formally a part of the elicitation process, is the the assessment of the requirements when technology has been developed in the project. The Requirements Matrix should in that step be the prominent vehicle for showing the relationships between
the provided technology and the domain needs that the technology satisfies.
3.1.3. Status and Statistics for Requirements
•
190 Requirements (as of 11. November 2013)
•
153 from Domain WPs (WP 1-5)
•
12 from WP7
•
14 from WP8
•
11 from WP9
The statistics show that there is a fair amount of domain needs specified, but the technical work
packages have still to come up with more specific promises.
3.1.4. Requirement Elicitation Time Plan
•
M3 (May 2013) Arrowhead Kick-offs
•
M4 (June 2013) Domain requirements 1. version
•
WPLs of WP1..5 need to provide Domain Requirements
•
Domain requirements 1 reviewed by T6.2 participants
•
•
The Graz Meeting (mid June)
•
M6 (August 2013) Domain requirements 2. version
•
WPLs review and possibly modify the requirement suggestions made by T6.2
•
The Luleå Meeting (mid September)
•
Milestone 1: M7 (September 2013) D6.1 Technical requirements 1. version
•
•
•
Made by T6.2 in cooperation with WPs 7-9 and also the WPs 1-5
•
Designated internal review included of all requirements performed
M9 (November 2013) Technical Requirements 2. version
•
The technical requirements is reviewed by domains WP1..5
•
The internal review comments merged into the requirements
Milestone 2: M11 (10. January 2014) D6.2 Technical Requirements 3. version
•
•
This deliverable
Milestone 3: M16 (June 2014) D6.3 Add more technical promises
•
www.arrowhead.eu
to ascertain the quality (clarity) of the requirements
more concrete, more measureable, more unambiguous
Document title
Author
Version
Erkki Jantunen
1.0
Date
Contact
Status
2014-01-30
Erkki.Jantunen@vtt.fi
final
DELIVERABLE D6.2 of WP 6
Page:
13 (13)
3.2. Requirements
The Complete Requirements Table is presented as an Excel table in Appendix 1 of this Deliverable.
(Not included in this document.)
4. Appendixes
The following appendixes are parts of deliverable D6.2:
[1] Requirements Matrix snapshot of 22. January 2014
[2] Energy domain communication protocols and information models standards within the residential environment
[3] Service Oriented Documentation Methodologies
[4] Safety/dependability analysis methods
[5] Experiences of SOA core services in military applications
5. Conclusions
This document repeats the outline of how the State of the Art Deliverables will be written and collected. The document summarizes some of the technologies which will be covered in the Arrowhead project. It is continuation to Deliverable D6.1 and those State of the Art areas covered in that
report and not repeated in this deliverable. Currently 28 technologies are recognized but it is expected
that some additional technologies will be covered when the need for these is recognized in the project. However, it is clear that the great majority of State of the Art needs have already been defined
based on the recognized Requirements of the partners of the project.
6. Revision history
6.1. Amendments
No.
Date
Version
Subject of Amendments
Author
1
2014-01-22
1.0
First draft
Erkki Jantunen
2
2014-01-30
2.0
Final
Erkki Jantunen
3
6.2. Quality Assurance
No.
Date
Version
Approved by
1
2014-01-30
2.0
Olli Ventä
2
www.arrowhead.eu