Standardization in Lab Automation (Sila) 2.0 Making The Standard Fit For The Future and Adapting An Open-Source Collaboration Platform For Standards Development

S TANDARDIZATION IN L AB AUTOMATION (S I LA) 2.
0 -
M AKING THE STANDARD FIT FOR THE FUTURE AND
ADAPTING AN OPEN - SOURCE COLLABORATION PLATFORM
FOR STANDARDS DEVELOPMENT
IMSE M ASTER S T HESIS
I NCZE , G ASP AR
J UNE 2016
Academic Supervisors:
Prof. Dr. Martin Smits Tilburg University
Prof. Dr. Bernhard Mitschang University of Stuttgart
Prof. Dr. Kostas Magoutis University of Crete
Company Supervisor:
Mr. Daniel Juchli Head Lab and Research IT of Wega Informatik AG
Abstract
Standards in Laboratory Automation (SiLA) is a vertical industry standard that promotes

easy setup and interoperability between laboratory devices and management systems. To
cope with the increasing market pressures and rapid changes in the technological land-
scape, the development of standards needs to become more agile. Furthermore, stan-
dards themselves must become increasingly modular to provide adequate flexibility. By
analysing the SiLA 1.3 specifications and engaging a wide range of stakeholders in the
life science industry, this Masters thesis aims to present valuable insights and propos-
als regarding the improvement of the standard and its development. This improvement is
achieved through a holistic approach that encompasses technical features, business motiva-
tions and processes, focusing on collaboration aspects. Using design science, an existing
open-source solution has been extended to improve slow, non-transparent collaboration
and engage more stakeholders in the standardisation process using a single common plat-
form.
Keywords: SiLA, life science, standardisation, business motivations, architectural
changes, integration technologies, communication protocols, taxonomy, collaboration plat-
form, Loomio
i
I dedicate this thesis to the spirit of collaboration and experts working in life sciences
in the hope that SiLA will help them do good things for people and our environment.
ii
Acknowledgements
First and foremost I would like to thank my father, mother and whole family for supporting
me so I can be where I am today. Koszonom nektek!
I would like to thank the management of Wega Informatik AG, Stefan Waltenspiel,
Uschi Mohaupt and Andre Matthijssen, for this great opportunity to do my internship in
Switzerland, and write my thesis on such an interesting and challenging topic.
My great gratitude goes to my company supervisor, Daniel Juchli from Wega Infor-
matik AG, for his continuous support and guidance inspired me throughout the whole
time. I have learned so much from him about life sciences and how complex ecosystems,
such as SiLA, work towards a common goal of standardisation.
I am honored by the help of my academic supervisor, Prof. Dr. Martin Smitz from
Tilburg University, for his valuable recommendations on standardisation literature and
many suggestions to improve this thesis.
I am grateful for the SiLA field trips for Oliver Peter from Actelion, Erwin Althof
and Daniel Baeschlin from Novartis and Tom Kissling from Roche, so I had the chance to
see device installations in their real laboratory environments.
I appreciate the time and knowledge that people gave me for interviews: Axel Wech-
sler from Fraunhofer IPA, Bernd Papenfuss from EQUIcon Software GmbH, Burkhard
Schaefer from BSSN Software, Dominic Lutjohann from cubuslab GmbH, Jana Erjavec
from BioSistemika, Lukas Muller from HSR Hochschule fur Technik Rapperswil, Niklaus
Graber from Association Consortium Standardization in Lab Automation and Thomas
Frech from Xavo Systems AG.
Thanks to all who filled up the thesis-specific pre-implementation, the business moti-
vations and the post-implementation surveys.
My special thanks goes to Peter Boogaard for letting me attend the Paperless Academy
2016 in Barcelona; James Kiesel, Michael Elwood-Smith and other Loomio team mem-
bers for their support regarding development topics; Devon Johnston and Carmen Condrau
from the SiLA consortium; James M. Vergis from the Allotrope Foundation and the em-
ployees of Wega Informatik AG.
I am grateful for all who dreamed, created and taught throughout the International Mas-
ter in Service Engineering (IMSE) Erasmus Mundus educational cooperation, my amazing
classmates from all over the world, the European Union and the European people who sup-
ported us getting this lifetime opportunity.
Last but not least I say thank you for all who I may not have named but contributed to
this Masters thesis in any way.
Basel, 10 June 2016
Gaspar Incze
iii
Table of Contents
Abstract i
Acknowledgements iii
Table of Contents v
List of Tables vi
List of Figures viii
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Research Topic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Research Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Research Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6 Research Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.7 Document Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.8 Common Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 Literature Review 9
2.1 Worldwide Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Vertical IS Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Key Reasons for Standardisation . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Collaboration Initiatives in the Life Science Industry . . . . . . . . . . . 14
2.5 Connectivity Protocol Stacks . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 Integration Styles and Communication Protocols . . . . . . . . . . . . . 23
2.7 Device and Service Discovery Protocols . . . . . . . . . . . . . . . . . . 28
iv
3 Research Methodology 31
3.1 Detailing Research Questions . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2 Research Across the Value Chain . . . . . . . . . . . . . . . . . . . . . . 35
4 SiLA Analysis and Future Improvements for SiLA 2.0 36

4.1 Speed of Standardisation and Organisational Effects . . . . . . . . . . . . 36
4.2 Analysis of current SiLA Processes and Architecture . . . . . . . . . . . 41
4.3 SiLA 2.0 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4 Conclusion of Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5 Flexible Agile Standardisation Tool (FAST) 56

5.1 Design Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2 Pre-Implementation Questionnaire . . . . . . . . . . . . . . . . . . . . . 57
5.3 Tool Development Methodology . . . . . . . . . . . . . . . . . . . . . . 59
5.4 User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.5 Requirements Matrix and Prioritisation . . . . . . . . . . . . . . . . . . . 61
5.6 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.7 Development Environment . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.8 Data Model Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.9 Plugin Development Process . . . . . . . . . . . . . . . . . . . . . . . . 67
5.10 Interface Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6 Validation 72
6.1 Descriptive Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.2 Process Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.3 User Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7 Conclusions and Future Work 82

7.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Bibliography 84
Appendix App. 1
v
List of Tables
2.1 CANopen address ranges (CiA, 2016) . . . . . . . . . . . . . . . . . . . 23
3.1 Research question linkage . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1 Process deadlines per stages . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2 Organisational members priorities (core, supportive, start-up, academic) . 42
4.3 Personal and non-member priorities . . . . . . . . . . . . . . . . . . . . 42
4.4 Summary of current major SiLA 1.3 issues . . . . . . . . . . . . . . . . . 50
4.5 Namespace proposal for SiLA 2.0 . . . . . . . . . . . . . . . . . . . . . 53
4.6 Taxonomy proposal version 1 . . . . . . . . . . . . . . . . . . . . . . . . 54
4.7 Taxonomy proposal version 2 . . . . . . . . . . . . . . . . . . . . . . . . 54
4.8 Mapping SiLA 1.3 and 2.0 concepts . . . . . . . . . . . . . . . . . . . . 55
5.1 User stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.2 Top priorities according to the requirements analysis . . . . . . . . . . . 62
A.1 Corporate members of the SiLA consortium (Feb 2016) . . . . . . . . . . App. 4

A.2 Comparison of communication protocols (1.) . . . . . . . . . . . . . . . App. 5
A.3 Comparison of communication protocols (2.) . . . . . . . . . . . . . . . App. 6
A.4 Comparison of discovery protocols . . . . . . . . . . . . . . . . . . . . App. 7
A.5 Requested features by category and priority (1.) . . . . . . . . . . . . . . App. 8
A.6 Requested features by category and priority (2.) . . . . . . . . . . . . . . App. 9
vi
List of Figures
1.1 Research process of the Masters thesis . . . . . . . . . . . . . . . . . . . 6
2.1 SiLA organisational diagram (SiLA, 2016c) . . . . . . . . . . . . . . . . 15

2.2 SiLA membership level comparison matrix (SiLA, 2016b) . . . . . . . . 16
2.3 LECIS state machine (Object Management Group, Inc., 2003) . . . . . . 18
2.4 Elixir Scientific Program (ELIXIR, 2014b) . . . . . . . . . . . . . . . . 19
2.5 OIC standard protocol stack (OIC, 2016) . . . . . . . . . . . . . . . . . 20
2.6 The Bluetooth Protocol Stack (Zajaczkowski, 2010) . . . . . . . . . . . 21
2.7 (CiA, 2016) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.8 Integration styles in context (Pautasso, Zimmermann & Leymann, 2008) 23
2.9 SOAP message structure . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.10 Web Service standards with CoAP binding (Moritz et al., 2011) . . . . . 26
2.11 Establishing a WebSocket connection (Skvorc et al., 2014) . . . . . . . . 27
2.12 WS-Discovery operation in ad hoc mode (OASIS Web Services Discovery
and Web Services Devices Profile (WS-DD) TC, 2009) . . . . . . . . . . 29
2.13 Finding a device by resource type (rt) (IoTivity, 2016) . . . . . . . . . . 29
3.1 Information Systems Research Framework (Hevner, A. R., March, S. T.,

Park, J., & Ram, S., 2004) . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2 SiLA value chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1 SiLA standardisation process . . . . . . . . . . . . . . . . . . . . . . . 37

4.2 Factors affecting ease of collaboration . . . . . . . . . . . . . . . . . . . 38
4.3 Factors affecting speed of standardisation . . . . . . . . . . . . . . . . . 38
4.4 Investigate generalised business-related effects of speed of standardisation 39
4.5 Investigate factors that speed of standardisation affects . . . . . . . . . . 40
4.6 Priorities by the SiLA 2016 Questionnaire . . . . . . . . . . . . . . . . . 43
4.7 Strategic importance vs. ability to contribute . . . . . . . . . . . . . . . 44
4.8 Perceived maturity of SiLA and impact on businesses . . . . . . . . . . . 46
4.9 Current connection and potential future architecture using MOM . . . . . 48
4.10 An adaptable, modular laboratory architecture (Roberts et al., 2011) . . . 49
vii
4.11 SI base and derived units (US Department of Commerce, 2014) . . . . . 52
4.12 Parameters for the Dispense command . . . . . . . . . . . . . . . . . . . 53
5.1 Core concepts of standards development . . . . . . . . . . . . . . . . . . 57

5.2 Proportions of primary collaboration tools used in SiLA work groups . . 58
5.3 Feedback about the currently used collaboration tool . . . . . . . . . . . 58
5.4 Success factors for collaboration tools (Bartlett, 2015) . . . . . . . . . . 61
5.5 Architecture diagram of FAST . . . . . . . . . . . . . . . . . . . . . . . 63
5.6 Ruby on Rails architecture (Niwatori, 2007) . . . . . . . . . . . . . . . . 64
5.7 Breakdown of Loomio source code by programming languages . . . . . 65
5.8 Hierarchy between user interface elements . . . . . . . . . . . . . . . . 66
5.9 Data model for SiLA 2.0 concepts . . . . . . . . . . . . . . . . . . . . . 67
5.10 Welcome screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.11 Group main page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.12 Discussion page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.1 Current workflow between vendors, work groups, TLT, URC, SRC and
GA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.2 To-be taxonomy workflow between vendors and work groups . . . . . . 75
6.3 FAST effects on collaboration . . . . . . . . . . . . . . . . . . . . . . . 75
6.4 Start screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.5 Work group main page . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.6 Discussion page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.7 SUS scores and acceptability ranges . . . . . . . . . . . . . . . . . . . . 78
6.8 SUS scores for FAST . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.9 FAST usability survey . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.10 Overall satisfaction rate with FAST . . . . . . . . . . . . . . . . . . . . 81
7.1 SiLA Provider Implementation Community Equipment (SPICE) running

on CuBox-i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.2 SiLA v1.3 State Machine Model Diagram . . . . . . . . . . . . . . . . . App. 3
viii
Chapter 1
Introduction
If you think of standardization as the

best that you know today, but which is
to be improved tomorrow; you get
somewhere.
Henry Ford
1.1 Motivation
The efficient operation of a modern society is enabled by a multitude of factors. One of
these factors is having standards, which are technical specifications, defining requirements
for products, services, processes or test methods. Standards are everywhere, working
invisibly unless we feel their absence when we are travelling to a new country, conduct-
ing transactions across borders or connecting different devices. Without interconnectivity
standards, end users face added complexity, subject to additional (sometimes prohibitive)
costs and fail to increase the utility of their investments by realising network externalities
(Idea Group Pub., 2006). Even more importantly, an integration and data storage standard
is required to address the serious reproducibility issues of scientific publications (Pashler
and Wagenmakers, 2012). Modern research is unimaginable without computers and the
amount of data produced necessitates a paradigm shift in handling such complexity (Ince,
2011). It is cost prohibitive to reproduce a scientific experiment if several experts need
to be paid every time to recreate a laboratory setup. In addition, ad hoc data formats hin-
der collaboration and take away valuable time from scientists focusing on their productive
work.
To advance science, not only theoretical reproducibility, but feasible (quick, cost-
effective) verification of scientific experiments is absolutely necessary.
Life sciences include a broad range of studies on microorganisms, plants, animals
and humans. Benevolent research aims for a better understanding of biochemical mecha-
nisms to address hereditary and acquired diseases; to improve life quality, to extend human
1
Chapter 1. Introduction 2
lifespan and to address some of the dangers that globalisation bring to our biosphere and
personal safety.
Because of increasing tourism and the magnitude of worldwide transportation of goods,
even less developed countries and communities need to be prepared to address biological-
chemical hazards and build an infrastructure that is able cope with such challenges. A
recent example is the Zika virus that is transmitted by mosquitoes, causing severe health
problems and head deformations in newborn children if the mother is affected. 46 coun-
tries are experiencing a first outbreak since 2015, mainly in Latin-America and the Pacific
region (WHO, 2016).
Proliferation of interoperability standards in this area enables laboratories, research in-
stitutions and manufacturers around the world to have a lower barrier of entry into medical
research or even other use cases such as food safety control. Furthermore, due to enormous
costs, it is vital to use sometimes decades-old research equipment in third-world countries
and academic institutions even in the developed countries.
1.2 Research Topic

Given the accelerating technological advancements and globalisation trend, efficient col-
laboration between organisations is receiving additional attention. One of the ways to fos-
ter this efficient interworking between companies and their products is to use standards.
They are often developed by a combination of economic, civil, academic and governmental
participants (European Commission, 2016). The core principles of standards are seeking
consensus, providing an open, transparent and non-discriminatory environment. Standards
may have one or more goals of interoperability, safety, cost reduction, repeatability, quality
or as an enabling factor of collaboration (Berg and Schumny, 1990).
In contrast to generally applicable standards, Vertical Information Systems (VIS) stan-
dards focus on industry-wide standardisation. They bring the possibility of tighter inte-
gration of taxonomies and business processes, accelerating information flow through the
supply chains. Additional benefits include improved data quality and reduced develop-
ment costs (Markus, M. L., Steinfield, C. W., Wigand, R. T., & Minton, G, 2006). This is
enabled by a collaborative development of domain-specific vocabularies that standardise
terms used across information systems.
The Association Consortium Standardization in Lab Automation (SiLA, 2016a) has
been created with the mission to establish international open standards which create con-
nectivity between laboratory systems. It has been formed in 2008 by two companies to
address integration challenges in a fragmented laboratory landscape. As of January 2016,
the consortium consists of 31 organisations, reaching worldwide coverage. However, the
current architecture of SiLA limits the achievement of its goal with optimal efficiency and
therefore changes need to be made.
In this Masters thesis, it is investigated how the architecture of a standard can be im-
proved to increase business motivation for future contributions. Following the partnership
with Analytical Information Markup Language (AnIML), an XML-based scientific data
storage standard (AnIML, 2014b), SiLA is providing a complete solution for laboratory
integration efforts. In the past, proprietary protocols were used to connect laboratory de-
vices. With the increased availability of modern integration methods, such as message
buses, it is getting increasingly feasible to build robust communication infrastructures.

Analysing state of the art communication and service discovery protocols it is desired to
take use of beneficial features.
In addition, improving collaboration for standards development and augmenting trans-
parency are expected to increase enthusiasm and encourage participation. This is key to
have to attract and retain a number of experts for standards development. Having a vibrant
community and ecosystem around SiLA is expected to accelerate the pace of standardisa-
tion. The business-related effects of the increased speed is also subject to analysis.
1.3 Research Problem

Industry players can have multiple motivation factors to form or join standard-making
groups. The expectation for effectiveness and efficiency in collaboration is common for
all participants, whether they have a for- or non-profit approach. For companies, obtain-
ing a return on their investments is critical (de Vries, 2013), whereas for volunteers it is
important that they use their limited resources in the best possible way.
Companies need to make rapid changes to be innovative and to remain competitive.
Therefore, analysing the factors affecting the speed of standardisation is crucial. Five con-
structs are tested: organisational context, collaboration tools, company motivations, ease
of collaboration and the speed of standardisation. The speed of standardisation and tech-
nical quality is a trade-off decision (Jakobs, 2006). Furthermore, it is industry-specific and
subject to bias - whether it is considered slow or fast, is also depending on the inclusiveness
of the standardisation proceedings (Walsh, 1997).
Standardisation processes require communication and negotiations between multiple
stakeholders that are facilitated through joint discussions during a usually lengthy process.
Because there is no specialised tool to support the process, the speed of integrating dif-
ferent viewpoints, arguments, and adopting new concepts remains a challenge. Moreover,
tracking issues is not supported by e-mail or forum platforms. On the other hand, tradi-
tional issue trackers have no features like differentiated voting. Even if a large number of
vendors offer collaboration tools, including platforms with end-to-end requirements track-
ing, design of an artifact in one environment will not be a good fit in others (Markus et al.,
2002), and their price may also hinder adoption.
From the technical side, the current SiLA specification mandates the implementation
of a state machine model. This concept ensures that a fixed set of commands and states are
available on all SiLA-compliant apparatus. However, many commands are unnecessary for
numerous devices; this introduces extra development costs and time. Therefore, evolution
towards a more modern, modularised foundation is necessary for ensuring wider adoption
in the industry and easier implementations in the future.
The goal of the SiLA consortium is to make the standard fit for the future using a
behaviour-oriented architecture and a more efficient collaborative process for standards
development. Redesign needs to discover the current best practices that are most fit to
address technical challenges, e.g. choosing the most appropriate communication protocol
or automatic service discovery mechanism available. Considering a more dynamic, fea-
ture focused solution is a paradigm shift which also require rethinking of the standards
development process. This transformation is analogous with changing from monolithic to
service-oriented architectures.
1.4 Research Goal

The primary objective of this Masters thesis is to provide understanding, actionable in-
sights and a comprehensive collaboration platform to improve the SiLA standards and
standardisation processes. Wega Informatik AG, as a member of the SiLA consortium,
is committed to give an additional momentum to the SiLA ecosystem by supporting the
realisation of the aforementioned goals.
First, to understand how SiLA could be made more compelling and successful in the
long run, it is vital to investigate motivations why organisations participate in standards
development. Understanding the context where the SiLA standards have been created is
also essential to find the answers how the evolution of SiLA took place since its launch in
2008. Companies would like to realise benefits from participation without compromising
product roadmaps. Therefore the impact of speed of standardisation is investigated in
relation to generalised key performance indicators.
Secondly, it is needed to provide a comprehensive analysis of the SiLA specifications
from both a process and a technical viewpoint. Upon completing the analysis, an improved
architecture of the SiLA interoperability standard is proposed. This requires redesigning
the current device and interface standard, working together with active SiLA working
groups. Depending on the new architectural design proposal, developing and defining
taxonomies is needed for lab device commands, parameters and behaviours (features),
considering the existing SiLA device classes. This effort will increase both flexibility and
consistency of the standard.
Thirdly, analysing and proposing a more efficient consensus process for the SiLA stan-
dardisation platform and to implement the process in a supporting, open-source web-based
tool that can be used to help further development of SiLA standardisation in an open and
community-driven way. While technical improvements increase the value of SiLA, only
a strong collaborative foundation, supporting actors across the value chain, can ensure
optimal use of available resources and realisation of long-term strategic advantages.
1.5 Research Questions

1. How do a standard-making consortiums organisational structures, procedures and rules
affect the speed of standardisation?
This question primarily focuses on work groups and the effect of team structures and
processes on the efficiency of collaborative tasks.
2. How does efficiency of collaboration tools affect the speed of the standardisation work?
Nowadays, contributors of standards are dispersed in multiple countries and time zones.
In this global setting, it is increasingly vital to have an efficient and asynchronous mode
of collaboration that supports both creation of content and managing the standardisation
process.
3. How does firms motivation to participate in the SiLA consortium affect the speed of
the standards development process?
Several factors are analysed to determine the reasons for which a firm invests in standards
development, and how its speed is affected by the strategic importance attached to partici-
pation.
4. How does a standard-making consortiums organisational structures, procedures, rules,
and efficiency of collaboration tools together affect the ease of collaboration?
This question pertains to the influence of structural elements in the ease of collaboration
in work groups.
5. What values can a faster standardisation process bring to organisations?
Through this question, the role of speed of standardisation in multiple areas, such as inno-
vation and development, is investigated.
6. How to design and implement a web-based tool that successfully can speed up, mak-
ing collaboration more transparent within work groups and throughout the standardisation
process?
The purpose of design science is to solve a particular problem, to create a useful solution
that did not exist before, or to adapt an existing one to better fit the targeted requirements
and improve efficiency.
7. How to validate the adapted web collaboration tool to measure its success in achieving
the research goal outlined in the previous section?
1.6 Research Overview
Figure 1.1: Research process of the Masters thesis

1.7 Document Structure

Chapter 1 Introduction
This chapter describes the motivation for improving standardisation processes and
tools along with the research problem, goals, main questions and the document structure.
Chapter 2 Literature Review

This chapter describes the history of general and VIS standards. The motivation be-
hind standardisation, the reasons why companies spend resources on creating and joining
standardisation groups are investigated. The process of analyzing different theories is com-
bined with case study based research, observing structural and procedural characteristics
of standardisation groups.
Chapter 3 Research Methodology

This chapter describes the research methodology. The research process is visualized
and detailed in order to provide a high-level overview on the steps that were taken to create
this Master thesis.
Chapter 4 SiLA Analysis and Future Improvements for SiLA 2.0

This chapter describes the organisational, process and technical characteristics of SiLA,
with additional focus on integration protocols. Research questions 1-5 will be addressed
in this chapter.
Chapter 5 Collaboration Tool Design

Description, functionality and architecture of the proof-of-concept. Describing the im-
plementation steps and details of the web collaboration tool. Research question 6 will be
addressed in this chapter.
Chapter 6 Validation
Validation is an essential part to assess the contribution of this Masters thesis. Re-
search question 7 will be addressed in this chapter.
Chapter 7 Conclusions and Future Work

Summary and closing thoughts regarding potential directions for the future.
1.8 Common Abbreviations

AnIML - Analytical Information Markup Language
API - Application Programming Interface
BoD - Board of Directors
DCDIS - Device Control and Data Interface Standard
DHCP - Dynamic Host Configuration Protocol
DNS - Domain Name System
FAST - Flexible Agile Standardisation Tool
GA - General Assembly
HTTP - Hypertext Transfer Protocol
IP - Internet Protocol
IS - Information System
IT - Information Technology
OASIS - Organization for the Advancement of Structured Information Standards
OCF - Open Connectivity Foundation
OIC - Open Interconnect Consortium
OSI - Open Systems Interconnection
REST - Representational State Transfer
RFC - Request for Comments
SiLA - Standards in Lab Automation
SMC - SiLA Management Committee
SME - Small and Medium-sized Enterprises
SOAP - originally an acronym for Simple Object Access Protocol
SRC - Supplier Review Committee
TCP - Transmission Control Protocol
TLT - Technical Leadership Team
UDP - User Datagram Protocol
UML - Unified Modeling Language
URC - User Review Committee
URI - Uniform Resource Identifier
VIS - Vertical Information System
W3C - World Wide Web Consortium
WS - Web Service
WSDL - Web Services Description Language
XML - Extensible Markup Language
Chapter 2
Literature Review
In this chapter, the brief history and background of horizontal and vertical IS standardisa-
tion is discussed including the underlying motivations for creation of these standards.
Standards are as old as modern civilization. In 250 BC, the Chinese emperor Qin
Shihuang standardised the length of chariot axles (de Vries, 2013). This not only en-
abled building roads more efficiently but also was beneficial in speed up construction and
maintenance of transport vehicles. Similarly, standards were already used in the Roman
Empire. Roads were constructed in a very robust manner, the quality requirements and
even the width of the roads were standardised (Dyson, 2003). As another example, to feed
the citizens of Rome, a complex supply chain was built from Egypt to the capital. Stan-
dardising storage containers, carrier ships, receipts and quality control processes (among
other things) was crucial for successfully distributing food to more than a million people
in one city an outstanding achievement of that time.
2.1 Worldwide Standards

The emergence of worldwide standards started around the late 19th century when techno-
logical advancement risen to an unprecedented level in the last two millennia. The train
lines crossing large distances from East to West in the United States necessitated a so-
lution for standardising time across stations to create usable schedules. The International
Meridian Conference created the worldwide system of time zones in 1884. In the 20th cen-
tury, with the birth of global telecommunications networks, this process has been further
accelerated.
From the 1960s, globalisation brought forward the birth of the modern, unified storage
container that enabled transportation in a massive, cost-effective scale. Similarly, there is
a general need on the global market for standards, devices and software products need to
communicate with each other. The United Nations/Electronic Data Interchange For Ad-
ministration, Commerce and Transport (UN/EDIFACT) standard has been developed to
speed up business transactions on a global scale. The operation of the internet and related
software is enabled by a multitude standards governed by the World Wide Web Consortium
9
Chapter 2. Literature Review 10
(W3C), Internet Engineering Task Force (IETF), Institute of Electrical and Electronics En-
gineers (IEEE), Internet Assigned Numbers Authority (IANA), International Organization
for Standardization (ISO), Unicode Consortium and many more.
2.2 Vertical IS Standards

While many standards are considered universal (i.e. horizontal, like EDIFACT), other
standards recognized that in order to handle complexity, their scope must be limited to
industry-specific dimensions. Vertical standards enable more detailed interactions between
industry participants and this leads to more efficient, more automated workflows.
2.2.1 RosettaNet
RosettaNet is a global non-profit consortium in the electronics industry founded in 1998. It
has been designed to speed up Business-to-Business (B2B) processes among trading part-
ners, especially transactions that are sent over computer networks in large volumes. The
RosettaNet standard is based on XML, defining process interfaces, message guidelines and
additional information for implementation. The consortium has more than 500 members
worldwide, showing its success. This is also due to the fact that the electronics business
is highly interdependent: value chains are complex and no single commercial entity can
realistically operate alone in the market. In such cases a vertical IS standard can efficiently
promote collaboration that is beneficial for an entire industry.
One of the key value of RosettaNet is a set of collaborative process steps called Part-
ner Interface Processes (PIP). These define template processes that regularly take place
between organisations. They fit into seven main groups that together add up to the foun-
dations of cross-organisational collaboration. These are: Partner Product and Service Re-
view, Product Information, Order Management, Inventory Management, Marketing Infor-
mation Management, Service and Support and Manufacturing. There is a separate group
for RosettaNet-related processes that serve administrative functions.
2.2.2 Mortgage Industry Standards Maintenance Organization (MISMO)

MISMO is a non-profit subsidiary of the Mortgage Bankers Association based in the
United States. It has been founded to create a standard that helps to change the indus-
try processes from paper-based to fully electronic. Participating organisations included
lenders, mortgage bankers, vendors and service providers. This transformation has helped
all players sharing data much easier and significantly speeding up service delivery times.
Defining only a data dictionary (We compete in service, not data) was seen as a
major reason for success (Markus, M. L., Steinfield, C. W., Wigand, R. T., & Minton, G,
2006). In addition, success was defined that the standardisation encompassed the widest
range of industry players, enabling electronic document handling throughout the entire
value chain.
2.3 Key Reasons for Standardisation

Standardisation efforts are supported for multiple reasons. According to Henk de Vries
(Vries, 2006), standards deliver value in seven key areas . Some case studies are mentioned
from his research and also additional sources.
Driving business results in unexpected ways

Standards often enable conducting business or interoperability. If one stakeholder group
can create an excessively complex mandatory (or de-facto) standard, that can hinder healthy
competition. For example, Microsoft created an immensely complex 7000 pages long
OOXML standard although Open Document Format already existed (Blind, 2011) (Na-
garjuna, 2007). This adds an unnecessary burden of hiring consultants and more domain
experts to deal with the high complexity.
Delaying the creation of a standard because of rigid rules can negatively affect the
overall success of standards development and standards diffusion; this occurred with EDI.
While big enterprises realised some of the benefits of e-commerce, most SMEs have never
implemented it because of its proprietary, high-priced, and complex nature (Markus, M.
L., Steinfield, C. W., Wigand, R. T., & Minton, G, 2006).
Participation increases market share

Participating in the right standardisation groups offer various insights and possibilities to
affect decisions. Tyco, a big electronics company has joined several national standardis-
ation bodies to influence which optical connector type should be accepted to a standard.
Because of participation, Tyco could convince the working committee to adopt their pre-
ferred connector. Even though the standard was open, not constraining competition, the
selection of Tycos own preferred connector gave a strategic advantage in time to market.
Avoiding costs by being informed early

Access to relevant information at the right time can save significant costs for companies.
The implications can range from small operations level to large scale, strategic levels.
An example is provided by a manufacturing company who wanted to enter the European
market with computer keyboards. The keyboard status LEDs had red colour which violated
a European standard. This meant that adaptations had to be done on the keyboards would
have resulted in extra costs. However, since the company was informed by an upcoming
change, the LEDs could stay the same because the standard was amended to be indifferent
of colours where safety aspects are clearly not involved.
Extended visibility
Small and Medium-sized Enterprises (SME) usually have very limited marketing budgets
to spend, especially compared to multinational companies. Contributing to a standard
which aims for public good, especially in an area with prospective clients, is a good way
of getting additional visibility. These expert connections can later turn into business oppor-
tunities. For example, a European family-owned achieved 40% increase in their turnover
through their involvement in standardisation. After the widespread Bovine spongiform

encephalopathy disease the British government has decided to pass more strict laws on
this issue. By taking the draft version of an existing ISO standard (that the company has
contributed to earlier) as a recommendation, they could enter a traditionally closed market
without delay. Getting so much visibility in the marketplace would have been financially
unachievable for them through regular advertising channels and the quality focus as a
long-term strategy was a very successful path.
This strategy can be seen in open-source software development as well where open-
ness creates new opportunities. Red Hat Linux is currently the biggest open-source com-
pany, having more than 2 billion dollars turnover in 2015 (RedHat, 2016). SMEs also
create well-targeted open-source software, such as the sciNote Open Source Electronic
Lab Notebook (LLC, 2016), to accelerate innovation, to challenge the status quo or to use
it as an unconventional marketing tool.
Savings on product testing

Product testing, especially safety testing is an expensive part of product development.
Finding the right amount of testing is important to save costs without compromising se-
curity. As an example, an electronic device manufacturer was looking to lower the costs
regarding wire insulation tests mandated by IEC 60694, requiring the application of 2000V
for one minute. This test also required to detach components as this electric voltage could
harm circuits that have not been designed to withstand it. This regulation has been relaxed
to 1000V for one second which was equivalent with the previous test - wire insulation
faults could be uncovered even at this voltage. In addition, the disassembling and re-
assembling step could be forfeited, resulting in further savings.
Lessons from the cases

The case studies mentioned above tell about how contributing to a standard can result
financially significant consequences to firms. Sometimes the savings are not so significant
but in a highly competitive market they can still mean the difference between profits or
loss.
Scientific literature often fails to recognise the importance of human factors that can tip
the odds even towards a seemingly small company. Meeting potential customers, industry
players, government officials and researchers expose company employees to a diverse set
of views. Secondly, building professional relations, improving soft and even diplomatic
skills will have direct and indirect effects to the financial results of the company. Thirdly,
the importance of small details how standards are phrased can mean the difference between
a competitive advantage and disadvantage. For this reason companies are often looking at
standards as strategic investment opportunities, as described in the next part.
Investment decisions
In general, standardisation efforts take many years and even more time until widespread
adoption takes place if the standard is successful. However, if a standard gets into the
widespread adoption phase it is providing a head start to early contributors. Time-to-
market, in-house experience, ability to understand more and shape industry trends have
significant benefits even though many cases those benefits are not (and cant be) quantified
to their full extent at the time of the decision.
Additional reasons for standardisation

Multinational companies often buy up smaller companies to gain competitive advantage.
This can be done to acquire valuable know-how, patents or innovation. On the other hand
these acquisitions lead to a fragmented product and IT landscape. Consolidating not just
IT infrastructure but also software architectures of different products could be considered
to increase efficiency. For a vendor it could make sense to use this as an opportunity to
revisit device interfaces across the board, erasing the technical debt that was accumulated
over time and to lower maintenance costs in the future.
A European Union initiated research group has tried to gather quantifiable evidence on
the motives of standardisation. However, this is exceedingly difficult due to the confiden-
tial nature of data that is involved in such decisions. Business strategy and financial details
are highly private that organisations are understandably very protective about (Blind et al.,
2016).
2.4 Collaboration Initiatives in the Life Science Industry

2.4.1 Standardization in Lab Automation
As described in the introduction chapter, SilA was established in 2008 to create technical
specifications enabling open connectivity between laboratory systems. The SiLA stan-
dards are mainly related to the Application layer of the Open Systems Interconnection
(OSI) model but also relates to Physical, Network, Session and Presentation layers. The
SiLA set of standards consist of:
Device Control & Data Interface Specification for communication be-

tween laboratory devices (SiLA providers) and management systems (SiLA
consumers)
Command Dictionary Specification for standardized control of devices
Data Standard to provide a unified way to store scientific measurements
(AnIML (AnIML, 2014b) is used for this purpose)
Process Management System (PMS) for creating laboratory workflows
Certification for SiLA standard to validate device compatibility with the
standard
Labware Specification is a collection of technical attributes of laboratory
equipment
Pipettor standard to provide a unified way to describe basic and more
advanced liquid handler devices
The SiLA Management Committee (SMC) is responsible for handling operative tasks,
including oversight of work groups, preparation of board meetings and executing deci-
sions. The SMC consists of the President and four Vice-Presidents (Chief Technology
Officer, Processes & Excellence, Treasurer, Corporate Secretary), elected by the General
Assembly.
The Board of Directors (BoD) includes at least eight members: the members of the
SMC and and three Chairs (US Committee, User Review Committee and the Supplier
Review Committee). The General Assembly may elect additional members to the BoD.
Currently there are eight additional stakeholders are appointed, adding up to a total 16
members.
SiLA working groups provide the foundation of the standardisation work. The work
is done on a volunteer basis, each member entity decide on their own how much they
are willing to contribute (i.e. let employees to work on the standard on company time).
Experience and projects running in academic or research institutions also assist the stan-
dardisation (e.g. the Hochschule fur Technik Rapperswil - ILT Institut contributing the
SiLA Provider Implementation Community Equipment, an open-source SiLA provider
implementation). The internal structure of the SiLA consortium is depicted below.
Including multiple type of SiLA members In the SiLA consortium there are five levels
of permanent membership available, depending on the total annual revenue of the organi-
sation in the previous financial year:
Figure 2.1: SiLA organisational diagram (SiLA, 2016c)
Core: suppliers and users above 50 million EUR

Supportive: suppliers and users up to 50 million EUR
Start-up: consultants, affiliates, companies per BoD decision under 5
million EUR
Academic: research institutions
Personal: individuals
Observer: temporary membership up to 1 year for evaluation purposes
Membership fees vary according to the membership type. In addition to the differences
depicted in the comparison matrix below, there are some important advantages of being
core and supportive members. Voting is their exclusive privilege, core members have one
vote and supportive members have a half vote.
2.4.2 Analytical Information Markup Language (AnIML)

AniML has been created in with the goal to Develop an analytical data standard that
can be used to store data from any analytical instrument (AnIML, 2014b). It is an XML-
based format for analytical and biological data. It has been created under the umbrella
of ASTM, international standards organisation that develops and publishes voluntary con-
sensus technical standards covering many areas (ASTM, 2016). AnIML is suitable for
Figure 2.2: SiLA membership level comparison matrix (SiLA, 2016b)
different measurement techniques, independent of data sources and provide compatibility

across vendors. XML is a mature technology and its also an open format, making data
easily accessible to any system. Many general (XML) and lab-specific (AnIML) software
solutions exist to handle integrations tasks in a laboratory.
Sharing data is key in modern research. Not only between internal teams but across a
network of partners, such as independent laboratories, academic research and regulatory
bodies. Regulatory compliance is hot topic for the life science industry. The US-based
Food and Drug Administration (FDA) is issuing public warning letters on their website
regarding the results of their investigations of manufacturer practices and products. An
increased focus is put to control not only US-based companies but also their foreign sup-
pliers. Especially data integrity issues are investigated with increasing focus: 79 % of
warning letters issued regarding drug site(s) outside the US included data integrity asso-
ciated deficiencies. (Consulting, 2016) An open standard is the best way to unify mea-
surements, provide a full audit trail and also ensure long-term archival while avoiding
vendor lock-in.
2.4.3 Allotrope Foundation

Following the publication of two articles in the American Pharmaceutical Review in 2010-
11, the International Consortium for Innovation and Quality formed work groups to ad-
dress pressing issues regarding laboratory integration challenges. Allotrope Foundation

was formed from these work groups in 2012.
The mission of the Allotrope Foundation is to contribute to the creation of an inte-
grated laboratory environment where repetitive tasks are automated, data is captured and
exchanged in standard formats and workflow systems provide easy rearrangement of ex-
periments and reliable, automated execution. These factors enable scientists focusing on
their scientific contribution instead of doing a lot of unnecessary and error-prone manual
work during their research.
Allotrope has it own data container standard - called the Allotrope Data Format (ADF)
- that contains three major parts:
Data descriptors (metadata) in a Resource Description Framework (RDF)

model
Universal data container for storing measurement data
Virtual file system for storing any binary files (this part is optional)
Cooperation between the SiLA Consortium and the Allotrope Foundation seems a logi-
cal step to avoid unnecessary fragmentation in the data storage domain. The first Allotrope
data format publication is expected to happen by the end of 2016. According to the cur-
rently published information, the specifications created by the Allotrope Foundation will
be proprietary, commercial users must pay licensing fees to access and use the taxonomies
and other materials. Having such a closed approach is similar to the path that CORBA,
EDI and LECIS took that may lead to failure achieving widespread standards diffusion.
On the other hand, providing the technical and legal possibility to create free and open
implementations would enable a much more profound impact, just like XML became the
de-facto data interchange format across enterprises.
2.4.4 Laboratory Equipment Control Interface Specification (LECIS)

LECIS has been created to solve the integration difficulties in laboratories in 2003. Along
with ASTM (American Society for Testing and Materials) Standard E1989-98, LECIS
defines a discrete state and communication model for laboratory devices. (Object Man-
agement Group, Inc., 2003)
LECIS uses Common Object Request Broker Architecture (CORBA) to foster inter-
action between different devices. It also uses Device Capability Dataset (DCD) from Na-
tional Institute of Standards and Technology (NIST) to enable Plug and Play function-
ality. It also uses a number of basic states to create a state machine model. SiLA, which
came five years later, describe a state machine model that is similar to the one depicted in
the LECIS document.
Both LECIS and CORBA became deprecated without significant industry adoption,
LECIS has been withdrawn in 2009 (ASTM International, 2009). Still, they are interesting
to be investigated to see how standardisation approaches evolved over time. They also
serve as a good base for comparison to determine which critical success factors were not
met to become widely used.
Figure 2.3: LECIS state machine (Object Management Group, Inc., 2003)
2.4.5 Elixir
The European Molecular Biology Laboratory - European Bioinformatics Institute (EMBL-
EBI), along with five founding member states have created Elixir as a legal entity in De-
cember 2013. (ELIXIR, 2014a)
The goal of this pan-European initiative is to secure the collection and long-term
storage of biological-chemical research data. The explosion of computer generated data
mandates an efficient method for storage. In addition, making publicly funded research
projects available to a large number of researchers is key to extract the most value out of
investments. Many member states of the European Union have national networks but they
are often not interconnected. Elixir not just promote data standards, but by interconnection
nodes in different countries help collaboration across national borders.
In the 2014-2018 program, eight strategic objectives of the ELIXIR Programme (ELIXIR,
2014b) has been identified. These are establishing a scalable, distributed infrastructure;
providing secure and reusable data storages, data connectors and services; develop and
maintain standards for data management and integration, make partnerships, give training
to address skills gap and support big data innovation.
Figure 2.4: Elixir Scientific Program (ELIXIR, 2014b)
2.5 Connectivity Protocol Stacks

2.5.1 Open Connectivity Foundation
The Open Connectivity Foundation (OCF) was created to foster open standardisation for
device interconnection and collaboration among a large number of stakeholders. It en-
compasses the former Open Interconnect Consortium (OIC) along with leading industry
players from among manufacturers, platform providers, software developers and service
providers. The rapidly increasing number of sensors and actuators, called the emergence
of the Internet of Things (IoT), created a need for protocols that have been designed with
particular principles in mind. The core principles are loose coupling (independence from
vendors, operating systems and physical transport media), decreased overhead for trans-
mitted data and energy efficient design. Any company that agrees with and embraces these
core principles can join the OCF. The OCF also sponsors the IoTivity open-source imple-
mentation, which is a Linux Foundation collaborative project. Moreover, the OCF also
includes the activities formerly governed by the UPnP Forum (OCF, 2016).
The scope of the OIC standard is threefold: To control devices locally and remotely as
well as to enable server-to-server communication. To realise this target as an open standard
for machine interconnections, the OIC work groups use several existing specifications that
fulfil the requirements of the core principles:
Support resource-constrained environments (e.g. with less than 10KB

RAM and less than 100KB flash storage according to RFC 7228) (Kera-
nen et al., 2014).
Minimise network traffic and processor load by applying compact head-
ers, an efficient binary protocol and payload compression.
Minimise complexity using a simple resource model, short URIs and two
addressing hierarchies (broad and shallow).
Figure 2.5: OIC standard protocol stack (OIC, 2016)
The Constrained Application Protocol (CoAP, described later in more details) con-
forms to these design aspects. For data representation Concise Binary Object Representa-
tion (CBOR) is used by default that is described in RFC 7049 (Rescorla and Modadugu,
2012; Bormann and Hoffman, 2013). Other formats are also negotiable (JSON, EXI and
XML). For transport layer security, Datagram Transport Layer Security (DTLS) (Rescorla
and Modadugu, 2012) is applied.
OIC consist of two legal entities. The licensing states that OIC specification is covered
by RAND-Z (Reasonable & Non-Discriminatory Zero royalty) patent licensing, while Io-
Tivity code is covered by Apache Licence version 2.0. This is an open-source licence,
allowing unrestricted, even commercial usage (Apache Foundation, 2004). This sepa-
rated licensing model enables developers using source code without joining the Founda-
tion while still benefiting from the legal framework.
2.5.2 Bluetooth
Bluetooth is a wireless interoperability standard designed to work over short distances.
It has been created by Ericsson in 1994. Since 1998, the standard is maintained by the
Bluetooth Special Interest Group (SIG) that has over 29 thousand members as of March
2016 (Bluetooth, 2016).
The Bluetooth standard is interesting because of its ease of use, a similar mode op-
eration would be desired for laboratory setups. Everyday usage of Bluetooth devices is
quite convenient, by pairing them together, a strong form of authentication and authorisa-
tion is realised. There are over thirty profiles exist which describe a well defined use case
along with dependent protocols. These profiles can be seen analogous as device classes
in the SiLA specification. However, Bluetooth profiles provide much greater flexibility by
allocating the most appropriate protocol stack dynamically for the given use case.
Figure 2.6: The Bluetooth Protocol Stack (Zajaczkowski, 2010)
2.5.3 Open Platform Communications Unified Architecture

The OPC Unified Architecture (OPC-UA), created by the OPC Foundation, is a set of
machine-to-machine (M2M) protocols that enables interoperability between manufactur-
ing devices. It has been designed to succeed Open Platform Communications (OPC) that
had several major limitations. First, it was platform dependent, available for Microsoft
Windows only. Secondly, it was depending on the Distributed Component Object Model
(DCOM) that is a proprietary Microsoft technology providing a means of communication
between software components. DCOM configuration is a cumbersome process especially
for first-time users and likely to be the main source of connection issues. Thirdly, the lack
of a strong security model and no configurability of timeout periods were disadvantageous
(Granzer, W., Kastner, W. and Furtak, P., 2010).
OPC-UA removed DCOM dependency by adopting several WS-* standards (e.g. SOAP,
WS-Security and WS-SecureConversation). This also meant a much simpler pass-through
over corporate firewalls. Defining a stronger security model was also done through other
standards (e.g. mandated X.509 certificates for authentication). In addition, providing
portable interface implementation in multiple languages (ANSI C, Java and .NET), con-
figurable service timeouts, heartbeat functionality for monitoring presence and guaranteed
delivery led to a more mature and more compelling solution as a whole.
2.5.4 CANopen
The non-profit CAN in Automation (CiA) association has been formed in March 1992 by
several international users and manufacturers. CANopen is a communication protocol and
device profile specification for embedded systems. By having a common protocol devices
can interact with other devices at ease, without the need of additional channel adapters.
This frees up developers from dealing with hardware specific technicalities, such as bit
timing. Standardized Communication Objects (COB) provide a solution for time-critical
processes, configuration and network management data.
Figure 2.7: (CiA, 2016)
CANopen includes an addressing scheme that is 16-bit long, stored in hexadecimal val-
ues. For data link layer, CANopen is based on ISO 11898-1. For physical layer, CANopen
assumes ISO 11898-2 but does not rely on it in a tightly coupled way.
2.5.5 Licensing and patenting issues

It should be mentioned that Bluetooth, OPC-UA and CANopen are not (open) standards.
The specifications are copyrighted and implementations are likely to be subject to patents.
As an example, Part B (Patents) of the OPC-UA licence states the following:
Adopters are directed to the possibility that compliance with or adoption of OPC
Specifications may require use of an invention covered by patent rights. OPC Foundation
shall not be responsible for identifying patents for which a license may be required by
any OPC specification, or for conducting legal inquiries into the legal validity or scope of
those patents that are brought to its attention. (OPC, 2016)
The undisclosed nature of these patents may result in significant business risks due to
Table 2.1: CANopen address ranges (CiA, 2016)
Index Description
0 Reserved
0001 - 025F Data types
0260 - 0FFF Reserved
1000 - 1FFF Communication Object Area
2000 - 5FFF Manufacturer Specific Area
6000 - 9FFF Device Profile Specific Area
A000 - BFFF Interface Profile Specific Area
C000 - FFFF Reserved
unplannable costs and legal exposure. For this reason, the adoption of non-open standards
require additional due diligence to determine the full scope of business impacts and to
make an informed decision.
2.6 Integration Styles and Communication Protocols

Four major integration styles exist, namely, shared database, remote procedure call, mes-
sage bus and file transfer.
Figure 2.8: Integration styles in context (Pautasso, Zimmermann & Leymann, 2008)
File transfer is the oldest and simplest of all methods. One usage of this method when
an application is writing to a file and another is reading from it. However, this technique
is not scalable, sensitive to file or folder name changes and race conditions. Using such a
system, it is also not defined who uses these files and when they can be safely deleted.
Shared databases operate similarly, but they have considerably higher reference auton-
omy using domain-specific languages such as Structured Query Language (SQL). SQL
queries can operate across databases from different vendors, provided they both sup-
port the same SQL standards. Despite being more efficient than file transfers, shared
databases with schemas are not sufficiently flexible for integrating many different applica-
tions. Shared databases also do not work well across large geographical distances.
Remote procedure calls came to existence after computers were connected together,
forming networks. The RPC rationale is that often reading or storing a particular data is
insufficient; the data has to be calculated on-demand using contextual information neces-
sary for processing such a request. Therefore, many techniques have been created (JAVA
RMI, .NET RMI, Corba, DCOM, XML-RPC and SOAP).
Message bus is a specific type of middleware addressing many limitations that were
previously discussed. It first appeared in big organisations where application integration
efforts drove the adoption of a central information highway. The message bus architec-
ture was designed to build a platform for inter-application messages. This enables loose
coupling and provides special services such as guaranteed delivery or message mediation.
2.6.1 SOAP and Web Service standards

Originally an acronym for Simple Object Access Protocol, SOAP is a protocol to provide
a transport and platform-independent way to exchange structured data between software
components. Its design is enabling programming language neutrality and extensibility.
Version 1.2 of SOAP became a W3C recommendation in 2003. It also became the foun-
dation of other WS-* standards such as Web Services Description Language (WSDL),
WS-ReliableMessaging, WS-Security and others.
SOAP is using XML and a special message format that separates metadata from the
transmitted data. An XML Envelope element identifies the XML document as a SOAP
message. A Header element contains header information while a Body element contains
the actual payload (e.g. function calls and responses). A Fault element (if present in the
Body section) contains information about errors. This separation enables SOAP messages
to be carried over multiple networks and protocols while quality of service policies (avail-
ability, integrity, security, performance, etc.) can be applied on the fly, customised to the
context and requirements.
Figure 2.9: SOAP message structure

While SOAP may not be ideal for simple use cases it leaves more room for alternative
architectural decisions (Pautasso, Zimmermann & Leymann, 2008). Moreover, features
like end-to-end encryption can be useful for cross-organisational information exchange,
especially in cloud-focused laboratories. On the other hand the actual usefulness of such
extra transport layer capabilities depend on the actual situation. The end-to-end argument
in system design promotes critical thinking about putting additional logic to intermediary
layers (Saltzer et al., 1984). A case study in the Dutch healthcare system showed that it
may not be beneficial to have WS-* standards and a business application layer solution can
be more practical if functional requirements and circumstances allow it (Marc de Graauw,
2010).
2.6.2 Representational state transfer (REST)

REST is an architectural style for the World Wide Web, used as an RPC-like integration
mechanism. It is leveraging existing Internet protocols in order to access and manipulate
data over the network. REST has been described in Roy Fieldings PhD thesis and has
been created with a couple of important design goals in mind:
Simplicity: five generic methods that maps Create-Retrieve-Update-Delete

(CRUD) operations to HTTP methods (GET, POST, PUT, PATCH, DELETE).
Add as little overhead as possible to transmitted content. The Lo-REST
approach even goes further and promotes the use of only GET and POST
requests which are accepted and allowed to pass through by all firewalls
and proxy servers.
Speed: Uniform Resource Identifier (URI) is used to address content that
enables caching across the web infrastructure.
Data independence: resources can be served in many formats depending
on the the capabilities of the requesting client. This is enabled by content
negotiation information stored in request headers.
Scalability: the stateless design (all requests containing all the informa-
tion and context needed to process the request) enables requests sprayed
over any number of servers. Load-balancing the requests and caching
capabilities together enable true scalability.
REST is a popular choice for Web 2.0 APIs and used by websites that receive millions
of queries every second. However, REST is not the right technique for all integration
cases. To make the right architectural decision it should be analysed if all requirements
can be successfully met. For example, REST is operating in a RPC-like way, in case of
a network failure, data is lost. In such case it is the responsibility of a client to retry and
resend the lost request.
2.6.3 Constrained Application Protocol (CoAP)

CoAP has been described in IETF RFC 7252 and it is chosen to be on the internet standards
track. The Open Connectivity Foundation promotes CoAP as specifically designed for
small devices where minimizing energy consumption and bandwidth usage is important.
It is titled as the Next-gen IoT protocol, featuring built-in discovery, multicast support
and asynchronous message exchanges. CoAP has been originally developed for UDP
while still providing reliable delivery, simple congestion and flow control implemented
in the CoAP messaging layer. However, many environments can take advantage of CoAP
while working over TCP, therefore this method is also being worked upon (Bormann et al.,
2014).
CoAP is a versatile protocol, providing also some interesting use cases. One among
them is to use it in conjunction with Web Service protocols. While SOAP is often criticised
as being resource intensive (because of the inefficiencies of XML parsing), combining
it with XML compressors, namely the Efficient XML Interchange format (EXI) enables
SOAP over CoAP to be used in constrained environments as well (Moritz et al., 2011).
Figure 2.10: Web Service standards with CoAP binding (Moritz et al., 2011)
2.6.4 WebSocket
WebSocket is a communication protocol that provides full-duplex transmission over a sin-
gle TCP channel. It has been standardized by IETF as RFC 6455. WebSocket enables
modern web applications to provide a low-latency browsing experience without using less
efficient methods like HTTP long polling. According to caniuse.com statistics, about 90%
of browser are compatible with WebSocket as of April 2016. A Websocket connection is
created by sending a HTTP Upgrade command to a server. The server returns the Switch-
ing Protocols HTTP response. After the connection has been established, further data will
be exchanged in binary format.
WebSockets are especially useful for real-time uses such as messaging or interactive
applications. WebSockets creates only a single connection and doesnt need multiple
HTTP headers. According to the tests of Peter Lubbers & Frank Greco, WebSockets can
reduce the unnecessary HTTP header traffic compared to HTTP polling by a factor of 100
or more, depending on the number of concurrent users (Kaazing). Moreover, the server no
longer needs to wait for the client before it can send data again, this can decrease latency
to one-third of its previous value with HTTP polling.
Figure 2.11: Establishing a WebSocket connection (Skvorc et al., 2014)
2.6.5 Advanced Message Queuing Protocol (AMQP)

AMQP is an open standard application layer (Layer 7) protocol for message-oriented mid-
dleware. It was developed by John OHara at JPMorgan Chase in 2004 but even from
the start the project was looked upon as a collaborative effort. In 2005 Apache Qpid was
born under the umbrella of the Apache Foundation. Nowadays many more free and open-
source AMQP implementations exist, such as RabbitMQ, AMQP.NET Lite, SwiftMQ or
IBM MQ Light.
AMQP provides a publish-subscribe model, realising loose coupling principles and
therefore an ideal solution for system integration. It is targeted at enterprise use, support-
ing TLS, Simple Authentication and Security Layer (SASL) and Kerberos authentication.
Currently in a working draft status, SOAP integration is also being worked upon by the
OASIS standardisation group. Their goal is to ensure interoperability between the imple-
mentations of different vendors of Web services (OASIS, 2013).
2.6.6 Message Queuing Telemetry Transport (MQTT)

MQTT is a simple publish-subscribe based transport protocol over TCP/IP. Version 3.1.1
is an OASIS Standard from 2014. Amazon Web Services provide MQTT as the message
broker of their IoT offering. MQTT has been designed to fit low capacity and low band-
width environments. It has strong delivery guarantees, including at-most-once (also known
as fire-and-forget), at-least-one and exactly-once transmission modes. It is also possible to

use MQTT in conjunction with WebSockets.
2.7 Device and Service Discovery Protocols

SiLA DCDIS 1.3 document suggests the implementation of WS-Discovery as an optional
feature. To evaluate this architectural decision that was made several years ago, it is needed
to look at currently available alternatives and best practices. The comparison matrix can
be found in the Appendix. There are some common aspects that are useful to investigate
for each technique:
Which underlying protocols are used?

How many implementations exist? How many programming languages
are supported with libraries? (if applicable)
Are there open-source implementations or libraries available?
The Web of Things Interest Group (operating within W3C) published a wiki page that
is a notable collection of available techniques and helps finding the right architectural
answers for physical object, network, directory, peer, metadata and semantic discovery
(Web of Things Interest Group, 2016). Because the SiLA specification wants to support
quick device setups, the following section focuses on giving a quick summary on network-
based discovery techniques.
2.7.1 WS-Discovery
Web Services Dynamic Discovery (WS-Discovery) is an OASIS standard and defines a
discovery protocol to locate services on a local network using multicast addresses (no-
tably 239.255.255.250 using IPv4 and FF02::C when using IPv6) (OASIS, 2009) and
IANA-assigned ports (tcp/udp 3702) (IANA, 2016). Windows Communication Founda-
tion (WCF) make it easy to integrate WS-Discovery into any .NET 4.0 (or newer) based
application. However, problems can arise with open implementations that have imple-
mented the draft version of the standard, such as Python-ws-discovery (Fernando, 2009).
Java-ws-discovery has an available beta version based on the final 1.1 standard (Skjegstad,
2011).
Device Profile for Web Services (DPWS) should be also mentioned because it is used
in conjunction with WS-Discovery to describe a minimal set of implementation require-
ments. Using DPWS, devices can be discovered, described, and subscribed using WS-
Discovery and WS-Eventing protocols.
2.7.2 Constrained Application Protocol Discovery

The OIC standard protocol stack is using CoAP and CoAP Discovery to find resources in
the network. During CoAP discovery the client must seek the server to discover which
services are available. Clients can either use a URI or they can also use multicast CoAP as
described in RFC 7252 (Shelby et al., 2014).
Figure 2.12: WS-Discovery operation in ad hoc mode (OASIS Web Services Discovery and Web
Services Devices Profile (WS-DD) TC, 2009)
Figure 2.13: Finding a device by resource type (rt) (IoTivity, 2016)
2.7.3 Zeroconf
The IETF Zeroconf working group has been created in 1999 in order to address the local
discovery of devices in a standardised way. The task was threefold: dynamic allocation
of IP addresses without using DHCP, resolving IP addresses without using Domain Name
Service (DNS) and provide service discovery without a directory server. By 2003, IPv4
Link-Local Addresses has been created and its implementations have been shipped in ma-
jor operating systems (Cheshire, 2003). Zeroconf is having two other cornerstones: mDNS
(multicast DNS to use textual host identifiers without real DNS servers) and mDNS-SD
(service discovery in the local network). UPnP is sometimes confused with Zeroconf but
it is rather the name of a protocol collection than a single protocol. Zeroconf only overlaps
with it in the service discovery layer (mDNS-SD and SSDP) so a comparison between the
two must be done carefully, explicitly focusing on this aspect (Cheshire, 2006).
Zeroconf has multiple open source implementations, such as Avahi, Bonjour and Pas-
try. A comparison done with more than three hundred nodes shown that Bonjour is the
most reliable of these three, achieving simultaneous discovery under one second with no
lost request as in the case of Avahi and considerably faster than Pastry (Abbes and Dubacq,
2008).
2.7.4 Simple Service Discovery Protocol (SSDP)

SSDP is a protocol to discover services over the network and retrieve presence information.
It constitutes the basis of Universal Plug and Play (UPnP) and it is intended to use in home
or small office environments. SSDP is using a multicast mechanism to discover endpoints
without the need of any preexisting configuration. Similarly to other UDP-based protocols,
SSDP is vulnerable for DDOS attacks (US-CERT, 2014). This should be kept in mind
when designing publicly available service interfaces.
Chapter 3
Research Methodology
In this Master thesis, the design science approach (Hevner, A. R., March, S. T., Park,
J., & Ram, S., 2004) was combined with qualitative research to explore the connection
between the speed of standardisation and other factors. Based on the available literature,
questionnaires and interviews can be designed to capture vital aspects of the life science
domain. The collected input is used for answering the three research questions and to map
user requirements, as precisely as possible. The creation of an IT artefact is an iterative
process, in which the system design is refined until the possible fit is achieved to integrate
the currently fragmented tools of the standardisation process.
The IT artefact in the current case is an instantiation following the terminology of
design science, which is a concrete software system to aid collaboration throughout the
standardisation process. The usefulness can be derived from user feedback that will be
gathered from baseline data and post-implementation surveys. As the final step, the find-
ings will be clearly documented, indicating the amount of utility achieved compared to
existing systems.
Standardisation groups are regularly formed by multiple companies to create industry-
specific standards, and to jointly represent their interests towards other industries and
policy-makers. Similar to firms performance, organisational structures, policies (guide-
lines), and procedures (the commonly agreed mode of working) are expected to affect the
speed of standardisation. Five hypotheses are tested using questionnaires with a 7-point
Likert scale (seven options from strongly disagree to strongly agree are available for re-
spondents to choose from). The middle of the scale (score 4) denotes a neutral standpoint.
The research model
Standardisation groups include one leader and usually 4-7 members who either take
individual tasks or work together on a more complex problem. The work group leader is
ultimately responsible for integrating the work and submit it to the Technical Leadership
Team (TLT) for review.
31
Chapter 3. Research Methodology 32
Figure 3.1: Information Systems Research Framework (Hevner, A. R., March, S. T., Park, J., &
Ram, S., 2004)
3.1 Detailing Research Questions

The speed of a standards development process (shortly just speed of standardisation) is
defined as the duration between:
Receiving a proposal from a device vendor or application developer first

submitted to the SiLA consortium and
In case of acceptance, publication in the SiLA standard (under the same
version if backward compatibility is not affected or in a new version oth-
erwise).
1. How does a standard-making consortiums organisational structures, proce-

dures and rules affect the speed of standardisation?
Organisations and individuals have a wide range of motivations to join a standardisa-
tion consortium. Some of these are to reduce costs and increase market share. Some firms
want to shape the future of an industry. By getting timely information of the direction of an
industry it is also possible to avoid costs and securing a time advantage over other firms.
Another reason is to get reputation by participation, building new contact networks and
enabling new business opportunities. Because companies have different strategies, their
motivations also differ. This will also result in different amounts of resources allocated
to contributing to a standard. Because participants strategies and resource allocation are
critical for a high-quality and timely work, it needs to be observed what reasons play a
more important role than others.
2. How does efficiency of collaboration tools affect the speed of the standardisa-
tion work?
To separate the impact of enabling factors (e.g. structural conditions) from determining
effects (affecting standardisation speed for real), the extent of the influence of perception
of efficient working conditions on attaining practical results must be investigated. By this
approach, the efficiency gains presented by a specialised collaboration tool and the impact
of the other factors on the speed of standardisation can be tested separately.
3. How do firms motivation to participate in the SiLA consortium affect the
speed of the standards development process?
It is an often overlooked aspect of standards-building processes how the usability of
collaboration tools affect their speed. Work groups often use a mixed set of tools consisting
of e-mail, forums, various instant messaging and file sharing platforms. However, such
fragmentation can lead to inefficiencies, including difficulties in tracking issues or the
latest versions of draft documents. Furthermore, if no systematic way of archiving files
exist (such when a group of people is just sending e-mails), it is difficult to reconstruct the
sequence of events later or to govern the collaboration. In addition, it can be challenging
for the contributors to join later and understand the context. Because a standard-making
process is often realised as voluntary work, participation fluctuates in practice.
4. How do a standard-making consortiums organisational structures, proce-
dures, rules and efficiency of collaboration tools together affect the ease of collab-
oration?
Following the principles of design science, an initial solution is created on the basis
of literature, experience in collaborative governance, and personal experience. Next, gap
analysis and surveys are used to elaborate and potentially reconstruct the initial model.
The refinement phase can start after the best apparent solution is found for the specific
problem.
5. What values can a faster standardisation process bring to organisations?
Four major anticipated effects are included and investigated in the research model:
speed of innovation, speed of development, cost of development and business growth.
The strength of the relationship with the speed of standardisation is measured through
questionnaires similar to the other linkages between the research concepts.
6. How to design and implement a web-based tool that successfully can speed up
collaboration within Work Groups and the standardisation process?
Finally, results should be analysed. Ideally, every aspect of the IT artefact should be
validated. However, measuring certain attributes, such as strategic fit, can only be seen
after the designed system has been in use for a longer period.
7. How to validate the web collaboration tool to measure its success to achieve the
research goal outlined in the previous section?
Validation is performed by conducting post-implementation user surveys that probe the

level of satisfaction of the users with the system on an absolute scale and also compared
to the previous workflows. This helps in determining whether the desired positive shift in
usability and efficiency is achieved or not along with the significance of the benefits.
Table 3.1: Research question linkage
Question topic Construct Affecting Indirect effect

Speed of standardisation supports innovation Speed of Standardisation Speed of Innovation Business growth
Organisational structures are efficient Structural elements of consortium Ease of collaboration Speed of Standardisation
Technical oversight is high-quality Structural elements of consortium SiLA value and benefits
Current speed is a bottleneck in development Speed of Standardisation Speed of development SiLA value and benefits
SiLA is strategically important Motivation of Organisation Priorities Speed of Standardisation
Explicit amount of time to work on SiLA Motivation of Organisation Speed of Standardisation SiLA value and benefits
Make and keep commitments Motivation of Organisation Speed of Standardisation SiLA value and benefits
SiLA governance, voting, by-laws efficiency Structural elements of consortium Speed of Standardisation SiLA value and benefits
Accelerate innovation Speed of Standardisation Speed of Innovation SiLA value and benefits
Enable new market opportunities Speed of Standardisation Business growth SiLA value and benefits
Enable new business models Speed of Standardisation Business growth SiLA value and benefits
Reduce development costs Speed of Standardisation Reduced costs SiLA value and benefits
Reduce testing costs Speed of Standardisation Reduced costs SiLA value and benefits
Reduce maintenance costs Speed of Standardisation Reduced costs SiLA value and benefits
Most important to advance SiLA Speed of Standardisation SiLA value and benefits
Make SiLA more appealing to invest in Speed of Standardisation SiLA value and benefits
Make SiLA more valuable as a standard Speed of Standardisation SiLA value and benefits
Satisfaction with current collaboration tool Collaboration tool efficiency Ease of collaboration Speed of Standardisation
Difficulty of finding latest document versions Collaboration tool efficiency Ease of collaboration Speed of Standardisation
Easiness of finding related documents Collaboration tool efficiency Ease of collaboration Speed of Standardisation
A web-based tool for faster standardisation Collaboration tool efficiency Ease of collaboration Speed of Standardisation
3.2 Research Across the Value Chain

The SiLA consortium targets four main type of participants (See Appendix for a full list
of participating organisations). These includes:
Life science vendors and developers

Pharmaceutical companies
Independent laboratories
Academic institutions
As any other life science-related service network, the SiLA consortium also work in a
highly regulated environment. Laws and guidelines provide a context regarding the man-
ner in which firms can cooperate and requirements that standards must comply with. As of
April 2016, no government agencies or public healthcare participants are directly involved
in the SiLA consortium. However, their participation would be beneficial to promote SiLA
also in the primary healthcare. In this area, numerous small-sized laboratories analyse
samples from patients to assist diagnosis. The most obvious benefits of participation are
the increased usability of existing assets and reduced costs.
Figure 3.2: SiLA value chain

Chapter 4
SiLA Analysis and Future
Improvements for SiLA 2.0
In this chapter, the current SiLA structures, processes and technical architecture are anal-
ysed. Following proposals for improvements, the SiLA 2.0 concepts are presented at the
end of this chapter.
4.1 Speed of Standardisation and Organisational Effects

Work groups are organised in a hierarchical way, while meritocratic elements are also
present, i.e. the reelection of a work group leader will largely depend on the perception
of the work produced. Similarly to the Apache Foundation and other standardisation com-
mittees, work groups use a technique called lazy consensus. This means that people
who contribute have a say how things proceed. If the collaboration process is transparent
(including well-defined processes), not forming counterarguments to a proposal is equal
to silent agreement. This way non-participating members dont hinder progress by their
absences.
In the SiLA consortium, leaders act not only as an information conduit but as the
integrator of the groups output. If this task can be simplified or omitted, by using a col-
laboration tool that generates this output, then this further accelerates the standardisation
process.
36
Chapter 4. SiLA Analysis and Future Improvements for SiLA 2.0 37
Figure 4.1: SiLA standardisation process
In April and May 2016 a survey has been sent to SiLA members and some participants
of the Paperless Lab Academy Conference. Members of the Allotrope Foundation also
contributed with some responses. The surveys were designed to test the research model
outlined in Chapter 3. Eight questions were asked, all of them used a 7-point Likert scale.
Due to the low number of responses and a relatively low Cronbachs Alpha value (0,61)
these results should be considered only as informative.
The first two question asked if the structural elements of a standardisation consortium
have significant impacts on the Ease of Collaboration between participants.
Figure 4.2: Factors affecting ease of collaboration
The third and fourth question asked if Organisational Motivation (the strategic impor-
tance attached to participation) and Ease of Collaboration have significant impacts on the
Speed of Standardisation.
Figure 4.3: Factors affecting speed of standardisation

The last four questions investigated how common organisation factors are believed
to be affected by the Speed of Standardisation. The speed of development and cost of
developments seems to have the strongest correlation. These factors are also easier to
measure than abstract (innovation) or very complex (business growth) concepts.
Figure 4.4: Investigate generalised business-related effects of speed of standardisation
In February 2016 the SiLA Board of Directors initiated a survey (described later in
more details), where 36 respondents also gave their opinions about the perceived impor-
tance of Speed of Standardisation. This data set has more responses and more internal
consistency (Cronbachs Alpha value 0,87). The answers show no strong opinions re-
garding the different factors, the averages fall mainly between slightly agree and the
natural standpoint. The results suggest that the strongest correlation is identified with the
overall value of the SiLA standards and accelerated innovation.
Figure 4.5: Investigate factors that speed of standardisation affects

4.2 Analysis of current SiLA Processes and Architecture

4.2.1 Process deadlines
Using the SiLA by-laws and procedures (SiLA, 2013) it is possible to calculate the min-
imum theoretical time needed to complete the standardisation process. The calculation
excludes the time needed for technical discussions and focuses only on the time required
if only a single participant would create a specification. This extra time can be considered
the cost of creating a high-quality standard that solves a well-defined problem for not
just one organisation, but for the entire life science industry.
Discussions on technical content can usually take from a few weeks to several months.
The process-related steps are as follows if the theoretically fastest case is considered:
Table 4.1: Process deadlines per stages
Stage Time period

Technical leadership team discussion 10 days
Technical leadership team voting 10 days
User / Supplier review committee review 15-30 days (if needed)
Vote on a motion submitted by a SiLA member 15 days (if needed)
General assembly voting 15 days
Since there is no central tool for tracking vendor requirements it was not possible to
determine a cycle time. The planned collaboration tool will help reach Level 3 Defined
according to the Capability Maturity Model by tracking proposals end-to-end.
4.2.2 Surveys and Interviews

SiLA questionnaire 2016
The SiLA Management Committee and the Board of Directors have published and dis-
tributed a questionnaire among all SiLA members to prioritise the planning of SiLA activ-
ities for 2016. The questionnaire required about 15-20 minutes to answer and the result of
this questionnaire was presented at the III. SiLA Tech Day on 5 April 2016, in Biberach,
Germany.
Responses gathered: 29 Feb 31 March 2016

36 respondents
21 members from organisations (paying SiLA members)
10 personal members
5 non-members
Structure of the questionnaire:
Section 1 - Overall Strategy for 2016
Section 2 - Contributing to SiLA

Section 3 - SiLA 1.3 Implementations
Section 4 - Research About SiLA (questions can be found in the Ap-
pendix)
Table 4.2: Organisational members priorities (core, supportive, start-up, academic)
Rank Aspect
1 Add examples
2 Improve concepts
3 Provide possibilities to self-certify SiLA implementations
4 Simplify / clarify state engine
Organisational members found that adding examples are the top priority that clarify
uncertainties around implementations. Extra contextual information helps developers to
code software functions in the same way, resulting in better interoperability between dif-
ferent vendors systems. The second priority is to improve SiLA concepts. From this need
arose the SiLA 2.0 initiative to address some much-needed changes that is underpinned
by SiLA members experiences. Self-certification and simplification of the state engine is
also considered highly important, the issues are detailed later in this chapter.
Table 4.3: Personal and non-member priorities
Rank Aspect
1 Support of new instrument types / device classes
2 Improve concepts
3 Easiness to bring new features into the standard
4 Simplify / clarify state engine
It is interesting to observe the different opinions between organisational and more ex-
ternal respondents. Two items have changed and both ask for a simpler way to get new
devices and features into the standard. The SiLA 2.0 initiative and the new web-based
collaboration tool aims to significantly improve this situation.
Feedback from life science vendors

Feedback from 10-10 vendors has been gathered at the Swiss Symposium on Lab Au-
tomation Lab 4.0 held in Rapperswil 17 March 2016 and the Paperless Academy held in
Barcelona 19-20 April 2016. Interviews were between 5-10 minutes in duration, focusing
on the following questions:
Has SiLA been already known and evaluated in the organisation whether
joining to the consortium would be beneficial?
Figure 4.6: Priorities by the SiLA 2016 Questionnaire
What are the results of such an overview?

Are there any obstacles or white spots identified in SiLA that would need
to be addressed?
Arguments and opinions from these interviews have been integrated with feedback
received from SiLA management and work group members.
4.2.3 Process-related Findings

SiLA needs momentum
SiLA is addressing a real need because laboratory integration projects still need a lot of ex-
perts and resources. To gain widespread industry acceptance and strengthen work groups,
additional participants needed to join the SiLA consortium. Focus on simplicity, fast ap-
plicability, communicating tangible business benefits, engaging more experts and showing
greater responsiveness can convince companies to join SiLA and devote resources to speed
up the realisation of a shared vision.
To encourage additional participation, the design of the voting rights system could
be revised. The current approach determine voting privileges depending on the member-
ship level, i.e. the financial possibilities of the company. However, including academic
members more in decision-making could inspire the involvement of additional innovation
capacity by granting a sense of ownership.
In addition to relying on more industry and academic partners, the Lab 4.0 initiative
and the Horizon 2020 programme chartered by the European Union support innovation in
the area of life sciences. This should be utilised for expanded collaboration and achieving
increased social, environmental and economic benefits.
Volunteering contributors
The management of volunteer contributors requires a different approach than managing
employees. In such a case, it is especially important to have a clear shared vision that is
communicated on a regular basis, as it is the strongest factor in team performance (Derue

et al., 2011). The success of agile methodologies is based on short but frequent commu-
nication. It is vital for providing transparency and also contributes to both the sense of
progress and peer pressure to adhere to self-made commitments. If these undertakings
are public and evaluated publicly, it also increases the intrinsic motivation. Moreover, IT
systems can generate aggregated data from each process step and create an advanced vi-
sualisation for additional insights. Making high-level statistics publicly available is also
highly beneficial for transparency on the project level. It also provides a sense of appre-
ciation to remarkable work and is practised in many online portals (e.g. the knowledge
sharing Stack Exchange portal).
It has been a commonly returning theme in interviews that contributors are not always
living up to their promises. Personalities matter a lot whether quick enthusiasm is really
turned into action or not. Lacking the required time management skills in an environment
where time is not explicitly reserved to standards development leads to conflicting prior-
ities and failure of delivery. This is a similar situation to change management projects
where top management commitment (and the resulting adequate amount of allocated re-
sources) is key for successful outcomes (FuiHoon Nah et al., 2001).
Respondents of the SiLA questionnaire found SiLA strategically important (5,43 av-
erage, between slightly to moderately agree) for their organisations. In contrast, it was
found that the majority of contributors dont have explicit time allocated to participate in
work groups. This circumstance often leads to the priority conflicts in day-to-day work
as outlined above. The situation could be helped by seeking more top-level commitments.
Alternatively, hiring independent part-time or full-time technical writers who have expe-
rience in the life science industry, creating specifications and taxonomies would make a
difference in this area.
Figure 4.7: Strategic importance vs. ability to contribute

Improvement of collaboration tools

Most work groups still use e-mails for collaboration. However, a web-based tool would
offer a lot more features to increase efficiency while preserving the advantages of e-mail
communication. Chapter 4 details the survey results and the design of a web-based collab-
oration tool.
Since multiple factors affect the speed of standardisation, an effective solution must
address multiple factors at the same time:
Aligning structures and procedures: A tool should be aligned with struc-

tural characteristics and support existing processes by integrating regular
tasks into the same tool according to best practices
Agility: A tool should promote agile development practices.
Transparency: A tool should provide high transparency with regard to the

quantity and quality of contributions. Participants should be able to see
statistics of other contributors, thereby fostering peer pressure and moti-
vation. Because of the voluntary nature of the contributions, its impor-
tant to be able to track individual efforts. Participants who do not deliver
on their commitments can jeopardise deadlines and collective progress.
Ease of use: A tool should make standards development and collabora-

tion easier through integration of all the necessary information, discus-
sion and decision-making features that are needed.
Analysis of the current organisational structures

The need for change is emphasised how SiLA is perceived in a business context. It is
believed to slightly more as a bottleneck and hindrance to innovation than an enabling
factor. Respondents were not able to form an opinion about the enabling factors of SiLA
structures which indicates that there is also room for improvement in that area.
Self-certification
Self-certification is the ability to test the compliance of a device with the SiLA specifica-
tions. This is important because the development cycle is accelerated if errors are detected
early. Furthermore, early error detection reduces cost. Reliable self-certification is a much
needed feature, ranked as the third priority in the SiLA survey among organisational mem-
bers.
Versioning
Versioning is unclear across some of the specifications and different groups. The DCDIS
document contains versioning-related texts (e.g. ID:SI 21; Rev: 16) that should not be
stored in the final document. More advanced version control systems, such as GIT, store
metadata in a separate folder, providing a clear and concise method.
Figure 4.8: Perceived maturity of SiLA and impact on businesses
4.2.4 Technical-related Findings

The latest version of the DCDIS document (1.3.08) has been published in November 2013.
This document, available at the SiLA website, will be used as a basis for the following
analysis (SiLA, 2013). Despite many merits, the current specification also has shortcom-
ings. The analysis will focus on the latter, exploring different technical areas. Where
improvement seems necessary or feasible, a proposal is made for further development.
Numerous mandatory commands and complex state machine

Currently there are nine mandatory commands in the SiLA DCDIS that all Device Classes
must implement:
Initialize
Reset
GetStatus
Abort
LockDevice
UnlockDevice
GetDeviceIdentification
DoContinue
Pause
Mandatory implementation of all these commands is irrelevant for many devices, par-
ticularly simple ones. This leads to either implementation overhead or disregarding the
specification - leaving an empty command logic (as a stub) and immediately returning
after the call of the command. Manufacturers create a large number of devices ranging
from simple to very complex. A good standard must contain the right level of abstraction
for both types of usage. A static allocation of features (as in a device class) should not
be enforced because that hinders the flexibility to combine different features together. A
behaviour-oriented transition promises many benefits. By defining smaller building blocks
it is possible to combine them in the way a research task needs it. Also by covering and en-
abling advanced use cases, manufacturers are able to differentiate themselves with highly
specialised products.
State machines are used to describe the permitted states of a system being modelled for
an improved understanding or as a prescriptive set of requirements to ensure predictable
operation. State machines that are defined as overly complex (with excessive states or
commands) unnecessarily burden developers who want to implement the standard. Agile
development is analogous because it favours iterations over creating monolithic blocks.
Creating a slimmer state machine by dividing it into atomic blocks could increase the flex-
ibility and ensure that there is no overhead introduced into implementation. This concept
appears in the transition from device classes to behaviours where the latter provide finer
granularity and offer the possibility of simpler state machines.
Choosing the level of abstraction is crucial for a standard. Being too general will lead
to incompatible implementations that interpret the standard in different ways, whereas
being too specific makes implementation cumbersome and technological progress can
quickly make the standard outdated a scenario that should be avoided by finding the
correct balance.
From a graphical perspective it turned out that the SiLA state machine diagram (see in
the Appendix) is confusing most subject matter experts or developers. For example, it is
not obvious for many people how to get out of the InError state. Because the area marked
with yellow is taking so much space the arrows on the top get little focus. It is advised
to leave more space inside the UML diagram frame and rearrange this graphic to show
clearly the relations between states.
Overusing optional parameters undermine interoperability

With the current specification, all optional parameters of a request need to be sent by using
the SetParameters command. This approach hinders replaceability and is unreliable in case
more vendor devices or Process Management Systems are involved, hindering the goal of
standardisation.
Constraints on network transport media

The DCDIS document restricts the usable OSI Level 1 transports to IEEE 802.3 10BASE-
T, IEEE 802.3u 100BASE-TX and IEEE 802.3ab 1000BASE-T. This restriction can be
an unnecessary limitation in certain laboratory or ad hoc setups (e.g. for demonstration
purposes) where WiFi would be a natural and convenient choice.
Weak security model

DCDIS states that By using the protocol HTTPS it is possible to set up an advanced
security environment.. However, this statement overrates the security level that Secure
Socket Layer (SSL) or Transport Layer Security (TLS) can provide. There are use cases
where research and development is performed across organisational boundaries and real
end-to-end encryption would be beneficial. This level of protection could be provided
by WS-Security using Security Assertion Markup Language (SAML), Kerberos or the
X.509 protocol, using public key cryptography. HTTPS can be considered a basic level of
protection and implementing HTTPS by default is a good security practice.
Network outage not covered

In case of a network outage, the loss of data packets (commands) are accepted. This
situation may be addressed using a message-oriented middleware (MOM) solution, such
as AMQP to queue requests and proceed with execution when an error has been resolved.
On the other hand, the MOM solution increases complexity. End users should be provided
with a simple means to flush their own message queues when continuation is not desired.
Figure 4.9: Current connection and potential future architecture using MOM
Service discovery not supported by default

An important aspect of SiLA is to make laboratory device setups dynamically reconfig-
urable. Currently this is a major and time-consuming task for each installation. WS-
Discovery is present in the specification but the implementation is optional and only a
fraction of vendors (3 out of 25 offerings) implemented it so far. Due to this low adoption
rate of WS-Discovery protocol, this is a suitable moment to revisit if there are any better
service discovery techniques are available. To make an informed decision, at least WS-
Discovery and Bonjour should be compared against each other, similarly as other Zeroconf
implementations (Abbes and Dubacq, 2008). While embedded systems are increasingly
based on GNU/Linux systems, desktop workstations where PMS run are usually Windows-
based, therefore interoperability needs to be tested as well.
WSDL generation
If a PMS wants to know what steps can be made next, introspection is used to determine
the capabilities of a device at a specific moment. Laboratory devices need to track their
internal states because not all commands are permitted in all situations. If the standard
would want to solve this, one way is to dynamically recreate WSDL file upon request to
contain the valid commands at that time. However, this adds much complexity and also
disallow code generation based on a WSDL contract. Therefore a static WSDL approach
is preferred, with the potential combination with WS-MetadataExchange (Davis et al.,
2011).
XmlDocument without XSD

XML Schema Definition (XSD) is used to describe the structure of XML documents. Cer-
tain commands specify return values as XML. However, without an XSD (Object Man-
agement Group, Inc., 2003; W3C, 2012), it is not possible to validate whether or not the
return values conform to the prescribed format and content. A well-defined XML schema
is also part of a holistic laboratory informatics approach, as shown below.
Figure 4.10: An adaptable, modular laboratory architecture (Roberts et al., 2011)

Event handling and Locking

Currently it is not defined in the specification of how the event receiver and the service
consumer should handle their interaction. In addition, collisions are possible since there is
no coordination regarding supposedly unique lock identifiers. A more thorough analysis
has been provided by Erick Bastidas, author of the SiLA-compliant Open-source Fast
Intelligent Application (SOFIA), from an implementation perspective (Bastidas, 2015).
Table 4.4: Summary of current major SiLA 1.3 issues
Issue Effect Area

Different error handling implementations Incompatibility SiLA SPECIF
SiLA is not supporting workflows
Missing feature SiLA SPECIF
(parallelism, shared resources, handoffs, spatial info)
Network outage scenario is not covered Missing feature SiLA SPECIF
Complex state machine model Implementation overhead SiLA SPECIF
Device class concept is rigid Implementation overhead SiLA SPECIF
Non-transparent work group operation Demotivation, less contribution SiLA PROC
No supporting tool for standards development Loss of efficiency and transparency SiLA PROC
No self-certification available Incompatibility SiLA PROC
Architectural issues, slow progress Small amount of supported devices SiLA ECOSYS
4.3 SiLA 2.0 Concepts

The work on the new architecture was started in September 2015 by work group members
from Hamilton Bonaduz AG, Xavo Systems AG and Wega Informatik AG. Their intention
was to address the issues that have been described in the previous SiLA analysis section.
Important note: the SiLA 2.0 terminology used in this thesis is not finalised and
subject to change.
4.3.1 New Concepts

Behaviours or features
In SiLA 1.3 device classes (such as Dispenser, Pipettor, Washer) represent discrete sets
of functionalities. However, this approach is not sufficiently flexible because it is forces a
certain device design, fixing the purpose. For example, a washer device may only perform
washing as a primary function as the name implies. But a vendor may want to focus
on a special use case and heat the washing liquid or the containers. In this case, a new
device class would be needed, but if only atomic capabilities are defined in the standard,
they can be freely combined and the device can easily advertise what features it supports.
Therefore, to make multifunctional devices and cover them in the standard more easily
than before, device classes must be broken to smaller capabilities called behaviours or
features. By combining atomic blocks, faster integration of more complex designs is
possible.
Global Command List

The idea underlying a global list of commands is to create one exhaustive collection and
associate them on-demand with the behaviours that require such functionality. This is a
many-to-many connection where commands and behaviours must have unique names.
A standard naming convention needs to be found for commands. Get-Set prefixes are
popular in Java and C#, for example. This method is advantageous because it is neatly
pairing idempotent, read-only get methods with other methods that cause a device state
change. Particularly for situations where more than two states are available. The architec-
tural decision here is to have more commands with simple functionality or less commands
with more parameters.
Another solution would be to name command precisely according to the performed
action. So instead of SetOpenStatus 1 or 0, the command Open() or Close() could be used.
This approach would result in more command words, more explicit and distinct actions.
For developers on the other hand, unique naming would mean more lookups for the right
terms during implementation.
Lastly, a hybrid system where Get-Set methods and explicit command words coexist
can be created.
Assumption: Pareto 80/20 principle applies to the usage of commands, most used com-
mands can be easily identified, having explicit entries for frequently used commands adds
value.
To differentiate between major or minor commands - put the first as a separate command
and add the latter as a parameter respectively. This would depend on subject matter ex-
perts judgement of relative importance and the predicted number of uses of a command.
Assumption: Design failure mode and effect analysis is applicable to the logical struc-
turing of commands (implicitly also parameters) and it is feasible by experts to perform
risk assessment of commands.
Another criterion would be to differentiate commands based on their predicted potential
risks. By using a simple risk prediction matrix with two variables (occurrence and sever-
ity) it may be possible to separate high- and low-impact commands.
Global Parameter List

Parameters are a distinct set of attributes that can be used to specify intended command
results in greater details. They are used by commands in a many-to-many relation and sim-
ilarly to behaviours and commands parameters must have a unique name. This can be done
either using namespaces or ensuring strictly different names everywhere. It is proposed
that parameters should have a name, detailed description and defined units for quantities.
For the web tool (detailed in Chapter 5) some extra attributes have been also defined that
help life cycle management. AnIML defines parameters and units already from where
conventions and best practices should adopted for increased consistency (AnIML, 2014a).
Figure 4.11: SI base and derived units (US Department of Commerce, 2014)
Universally defined (metric) units have three main types:
Base units (mass, length, etc.)

Derived units without special names (volume, area, etc.)
Derived units with special names (energy, frequency, etc.)
As an example, parameters for the Dispense command is shown below. The global
parameter list would extract and contain all the parameters found in existing commands.
In addition, it is essential to attached a precise unit to all parameters, define XSD schemas
for validation purposes.
Figure 4.12: Parameters for the Dispense command
Namespaces
Mandating unique command and parameter names is not the only option. If these items
ever need to change, that is likely, two possibilities remain: one is to choose another name
for the command or parameter. The second is to change the item while keeping the name.
However, if items have many-to-many connections, this can lead to unpredictable and
potentially unwanted effects. From a change management perspective, it would be better to
only suggest the selection of command / parameter names to vendors while keeping them
rather isolated so revisions dont cause a chain reaction. This can be done via namespaces.
Table 4.5: Namespace proposal for SiLA 2.0
New Behaviour Group New Command Namespace

CanMeasureTemperature GetCurrentTemperature Temperature.Value
SetTargetTemperature Temperature.Setpoint.Set(30)
GetTargetTemperature Temperature.Setpoint.Value
CanControlTemperature StartTemperatureControl Temperature.Actor.Start
StopTemperatureControl Temperature.Actor.Stop
4.3.2 Taxonomy Proposal
Table 4.6: Taxonomy proposal version 1
Behaviour Command Parameter

Adjective VerbInCamelCase nounInLowerCamelCase
Lockable Lock id
Unlock timeout
GetLockStatus
Openable Open speed
Close latency
GetOpenStatus
Heatable GetTemperature temperature
SetTemperature rampupTime
Naming of concepts should be consistent to make implementation straightforward and

consistent. Consistency in languages can be defined as agreement, harmony, or com-
patibility, especially correspondence or uniformity among the parts of a complex thing
(Dictionary.com). When something is consistent, an underlying organising principle helps
to reduce complexity. Having consistent specifications enable contributors to understand
them faster and developers to provide more coherent implementations with less possibili-
ties of errors. To help people who would like to submit new items to the standard, as well
as work groups who need to work on the proposed items, establishing a common criterion
in a grammatical sense is helpful. For example, behaviours could be defined as adjectives
in Camel Case (e.g. GetTemperature) and finally parameters as nouns, written in Lower
Camel Case (e.g. rampupTime).
Table 4.7: Taxonomy proposal version 2
Behaviour Command Parameter

CanVerb VerbInCamelCase nounInLowerCamelCase
CanLock Lock id
Unlock timeout
GetLockStatus
CanOpen Open speed
Close latency
GetOpenStatus
4.4 Conclusion of Analysis

Process-related considerations
To encourage participation a clear shared vision is essential. It is also necessary to give
ongoing positive reinforcement for the most active contributors. Removing or at least
make bottlenecks highly visible is beneficial for the overall speed. The concept of lazy
consensus combined with clear process and deadlines could be used more in work groups
to strengthen self-organising principles and to alleviate some workload from work group
leaders. If it is determined that technical capacities are missing, hiring technical writers,
who have expertise in the life science industry and creating specifications and taxonomies,
could be an option.
Technical-related considerations
The SiLA 2.0 concept decreases the number of mandatory commands to one or zero, de-
pending on the applicability of Web Services Metadata Exchange (WS-MetadataExchange).
This makes implementations easier for simple devices. DeviceClasses need to be mapped
to smaller set of building blocks called behaviors. To make connections more robust,
adopting a message oriented middleware would be beneficial. A discovery mechanism
should be made mandatory to support one of the core goal of SiLA, easy addition of new
devices. A global list of parameters was created with mandatory units attached to them
increase the quality of the standard. Finally, for the new concepts a style guide has been
proposed to increase consistency.
Table 4.8: Mapping SiLA 1.3 and 2.0 concepts
Concept SiLA Current SiLA 2.0

Parameter Defined for each command Global Parameter List
Command Fix defined with fix set of parameter Global Command List
DeviceClass Predetermined set of commands for each -
DeviceClass along with many manda-
tory and required commands
Behaviour - Small set of mandatory commands
StateMachine Mandatory implementation Simplified by breaking to smaller
optional blocks
Chapter 5
Flexible Agile Standardisation Tool
(FAST)
5.1 Design Context

The trend of recent years is to shift software applications from desktops to browsers. This
change has also triggered a paradigm shift because the Internet enables extensive world-
wide collaboration and promotes a synergistic connections. Intense competition among
browsers serves innovation well and pushing for desktop-like performance is still an on-
going process. Communication protocols and development frameworks are increasingly
mature and ready to deliver a complete desktop experience. For example, Websockets pro-
vide a low latency connection for real-time applications), while high-end graphics tech-
nologies, such as Web GL, is also increasingly present. However advanced and useful
these web tools may have become in the past few years, changing workflows and adoption
does not occur overnight. Communication tools that are being used for decades still have
a massive inertia even though their limitations are well known (Whittaker et al., 1996).
The popularity of electronic mails, since its introduction in the 1960s, is persistent.
According to an analysis of The Radicati Group, there are over 4.5 billion e-mail accounts
worldwide as of 2016 (THE RADICATI GROUP, INC.). E-mail has often been criticised
but its compatibility and widespread availability have not yet been surpassed by newer
solutions. Although e-mails are forwarded on a best-effort basis, the reliability of the
transmission can be considered very high in practice. Given the large volume of e-mails, it
is easy to overlook even important messages in a busy inbox. Moreover, tracking e-mails
and the resulting decisions is a fairly difficult task that specialised web-based tools can
solve much more efficiently.
Numerous general-purpose tools are available for collaboration, such as forums for
discussions and wikis to create structured content. Requirement trackers, version control
systems and issue trackers enable dealing with a with large number of tasks, deadlines and
priorities. Enterprise-level offerings and collaboration platforms combine these aspects to
56
Chapter 5. Flexible Agile Standardisation Tool (FAST) 57
Figure 5.1: Core concepts of standards development
provide a type of end-to-end solution to support software and service delivery processes.
In addition to the previously mentioned tools, collaborative decision-making systems
have started appearing in the past few years. Similar to vertical industry standards, they
serve a niche market and centred on engaging a large number of participants using Web
2.0 concepts. However, no tool that can efficiently assist a standardisation workflow is
available yet in the open-source community.
5.2 Pre-Implementation Questionnaire

Along with the SiLA 2016 questionnaire, the work group members were asked to deter-
mine which tools they primarily use to collaborate with other members for developing
the standard. E-mail has been named as the most used tool, nearly three-quarters of the
respondents marked it.
After identifying the used communication tools, four questions were asked to assess
the satisfaction and common aspects of collaboration systems. Respondents were slightly
unsatisfied with the current systems (3,79), confirming the assumption that there is much
room for improvement. Document management is not perceived as easy (3,32), sharing
documents are usually done in e-mail, despite issues such as the prohibition of co-editing
and merge conflicts. This was confirmed by the next question regarding version control
problems (4,68). As the last question, it was asked whether a web-based tool would be use-
ful for work group members. Work group members showed a high willingness to change
existing ways of collaboration (5,7), thereby confirming the need for a new solution.
Before starting the design phase it important to research if there are already existing
solutions available. Designing a new system should not be a default answer to a particular
problem given there are so many tools already exist. In addition, existing open-source
systems would provide a good starting point if there is no major gap between features and
requirements. Therefore a thorough evaluation phase is critical to provide the maximum
Figure 5.2: Proportions of primary collaboration tools used in SiLA work groups
Figure 5.3: Feedback about the currently used collaboration tool

utility, given the resource constraints.
5.3 Tool Development Methodology

The tool development follows the process outlined in Chapter 2 (depicted in the research
model). Key stakeholders were identified to ensure that all the important aspects were
covered during the tool design phase. They are as follows:
SiLA organisational members: companies and institutions that joined the

SiLA consortium can influence the manner in which the standard evolves
and also make proposals to be considered for adding to the standard
SiLA work group members and leaders: employees of member compa-
nies or academic contributors
Third-party experts were consulted from life science vendors at the SLAS conference
in Rapperswil, the Paperless Academy in Barcelona, the Apache Foundation and the Al-
lotrope Foundation.
Create baseline questionnaire (discussed in Chapter 4)

Interview users (discussed in Chapter 4)
Create user stories
Create requirements matrix
Analyse and decide whether to build new or adapt an existing solution
Design the tool in details
Seek feedback and iteratively improve design
Determine scope and implement
Seek final feedback and evaluate results
5.4 User Stories

User stories are frequently used in agile development practices to capture feature requests
in addition to the context and motivation underlying them. Six primary types of users have
been identified, these are listed in the <who> column in the table below. The <what>
column describes a specific action to be performed by the user. The <why> column
records the value of this interaction which is also helping with prioritising this functional-
ity. The PRI column denotes a simple prioritisation on a scale from 1 to 5, where 1 marks
the lowest priority (nice to have feature) and 5 marks the highest (essential feature).
Table 5.1: User stories
As a (who) I want (what) because (why) PRI Paying SiLA

members
Creator of SiLA providers
and consumers
(vendor, SME, integrator, Add behaviours, commands and parame- Benefit from the values of standardisation 5 Yes
developer, etc.) ters
SiLA member See the standardisation work (read-only) Transparency, value of SiLA membership 5 Yes
WG leader Setup WG members and support collabo- Ensure efficient collaboration 5 Yes
ration
WG member (domain ex- Discuss and decide on proposals and Contribute to SiLA 5 Yes
pert, developer) other items
SiLA Technical Leadership An overall look on the progress of SiLA Improve processes 3 Yes
Team standardisation process
Personal member (potential
future partners and
other users after free regis- Look at released behaviours, commands, Evaluate / Read the standard. Trans- 4 No
tration) parameters and creation history parency how the standard evolved over
time.
5.5 Requirements Matrix and Prioritisation

Seven work group members have been interviewed in April 2016 to gather and prioritise
the features that are essential for supporting the standards development workflow. The
availability of these features have been checked in other existing tools. A Forum soft-
ware on the SiLA website is providing basic discussions and file sharing. Some work
group also use codeBeamer provided by Intland Software. It is an advanced application
life cycle management platform encompassing requirements analysis, development, qual-
ity assurance, demand management, IT operations and tools. On the other hand, having
such a vast range of features adds complexity and results in a longer learning curve for
the system. Finally, Loomio was found as an interesting open-source offering during the
research phase. It was designed primarily to support collaborative decision-making.
The development team of Loomio has created an assessment comparing different col-
laboration tools. They have found that Loomios key strengths are ease of use, adaptability,
transforming collaboration culture and decision-making support (Bartlett, 2015).
Figure 5.4: Success factors for collaboration tools (Bartlett, 2015)
User priorities rating have been collected and an average priority score is shown in
the last column. The following features have been sorted according to the average user
priority in a decreasing order:
Table 5.2: Top priorities according to the requirements analysis
Feature Forum Codebeamer Loomio User priority

Commenting YES YES YES 8,86
Assign owner to proposal NO YES NO 8,57
User access control YES YES YES 8,57
New command/parameter/behaviour NO NO NO 8,43
Vote on new behaviour/command/parameter NO NO YES 8,33
Proposal status/life cycle NO YES NO 8,14
Version control of uploads NO YES NO 8,00
Backtrack-Linkback to existing items NO YES NO 7,86
Emphasize critical tasks NO YES NO 7,71
Configurable E-mail notifications Partial YES YES 7,71
5.5.1 Conclusion and development goals

Following this analysis it has been concluded that Loomio would provide a sound base for
the required collaboration tool. The contribution of the thesis work has been determined
as the following:
Create an automated installer to setup the development environment on GNU/Linux

Perform a gap analysis between the current and the desired user interface and modify
the page layouts based on feedback
Map SiLA 2.0 requirements to the concepts already available in Loomio (groups,
subgroups and threads)
5.6 Architecture
Loomio is using typical web application architecture. On the frontend, AngularJS is used
to create a rich web experience. It has its own persistence layer using the browser, therefore
the data models need to be described here and also at the backend. At the server side,
Ruby on Rails is used to define data models, REST APIs and controllers among other
Ruby-specific tasks.
Figure 5.5: Architecture diagram of FAST
Ruby on Rails
Ruby on Rails is a web development framework based on the popular Ruby program-
ming language. Ruby was created in 1995 by Yukishiro Matzumoto as a dynamically
typed, fully object-oriented, general-purpose scripting language. Ruby on Rails uses the
Model-View-Controller (MVC) architectural pattern that provides an elegant separation of
business logic and its presentation.
Figure 5.6: Ruby on Rails architecture (Niwatori, 2007)
AngularJS
AngularJS is an open-source web application framework, maintained by Google and com-
munity members, aimed to simplify the development of rich, one-page web applications.
Loomio is using AngularJS for its frontend to deliver a rich client-side experience.
CoffeeScript
The CoffeeScript programming language was created to address some of the shortcom-
ings of Javascript. It enables developers to write less code with the help of modern pro-
gramming language constructs while the output is still compiled to Javascript, ensuring
compatibility across browsers.
HTML and HTML abstraction markup language (Haml)

In addition to standard HTML, Haml is used to describe page templates. Haml can be re-
garded as simplified HTML where brackets and other syntactical elements can be omitted
or replaced with shorter notations. This saves time and creates a more readable markup
language.
Figure 5.7: Breakdown of Loomio source code by programming languages
5.7 Development Environment

The development environment contains the following major components:
Ubuntu GNU/Linux 14.04 x64 LTS

PostgreSQL 9.4
Ruby 2.3
To setup the development environment, the following shell scripts were created. The
time needed to complete the installation process is about 15-30 minutes, depending on the
available Internet connection. The setup has been tested using VirtualBox 5.0.16 and a
fresh Ubuntu installation.
cd;wget https://raw.githubusercontent.com/sicambria/
sh/master/deploy/loomio1404-dev1.sh; chmod +x loomio1404-
dev1.sh;./loomio1404-dev1.sh
cd;wget https://raw.githubusercontent.com/sicambria/
sh/master/deploy/loomio1404-dev2.sh; chmod +x loomio1404-
dev2.sh;./loomio1404-dev2.sh
In case a purge and reset is needed for all installed resources (Loomio, Ruby, NPM,
PostgreSQL and other dependencies), an automated script helps in that too.
The Thin Web Server should be started with the following command to be accessible
in an internal network (at IP ADDRESS:8000):
cd projects/loomio
rails server -b 0.0.0.0 -p 8000
5.8 Data Model Design

Due to the adoption nature of the development work much has been already done for the
base software. Therefore only the domain-specific data had to be modelled and inserted
into the existing system.
Relationships between behaviours, commands and parameters had to be defined first
on a taxonomical level. To reuse concepts from Loomio, the thread and subgroup concept
were used to record items and their hierarchy.
Figure 5.8: Hierarchy between user interface elements
Some additional field were added to maintain life cycle information, such as the name
of submitter, submission date, etc. These data models were later used to assist storing new
items as well as to assist change management in the future.
Figure 5.9: Data model for SiLA 2.0 concepts
5.9 Plugin Development Process

In this section a high-level overview is given on the process how to develop new plugins for
Loomio. Code samples can be also found on the projects GitHub page (Guthrie, 2016).
1. Setting up a GIT repository
It is a best practice to start with creating a GIT repository for many reasons. The
most obvious reason is to have version controlling with all its benefits. In addition to this,
uploading the code to either a private or public remote GIT server enables a faster and
easier installation independently from the location.
2. Enable plugin
The plugin code is not executed by default. By inserting a plugin.enabled = true
directive to the plugin.rb file, the plugin code get executed.
3. Setup database tables and relations
The way how data is stored in the database needs to be defined in this step. This
includes definition of the required database tables, their relations and attributes with their
data types.
4. Create data model
The model part of the MVC pattern needs to be defined in this step. Objects and
conceptual relations are described between the models (belongs to relations). In addition,
other modules need to be also modified to use the new concepts described in the plugin to
be added (has many relations).
5. Add API endpoint
First and endpoint needs to chosen that will route request to a Controller.
Example route: /api/v1/plugin example.json
Note: Semantic Versioning should be used for APIs (Preston-Werner, 2013) to define
compatibility levels according to current best practices.
As the next step a controller needs to be created. Here the database query is defined
with accessible records that control what data a user has access to. Then those records can
be passed along as a collection.
Finally a serialiser needs to be created that will define how objects will appear in the
API response.
6. Create frontend code
Similarly to the backend, frontend data models also need to be defined. These are
stored in a data store named RecordsInterface. Then an outlet must be created to define
the location on the website where the component interface will be positioned. Having that,
the component code itself needs to be written. All the resources that the components uses
(Coffeescript, Haml, etc.) needs to be placed in a folder named the same as the files the
plugins/plugin name/components directory:
plugins/
base.rb
loomio-tags
components
thread_tags
thread_tags.coffee
thread_tags.haml
thread_tags.scss
As the last step in this section, a coffeescript will retrieve data from the server when
the API is called.
7. Testing
To finalize the development, a unit test should be written to ensure proper operation.
This is highly specific to the feature that was developed. In general it is recommended to
make at least one positive (observing expected behaviour) and one negative test (making
sure that a new feature only applies to e.g. data models that is should and not others).
5.10 Interface Design

The interface design is a highly iterative process where feedback is gathered in multi-
ple rounds. Simple wireframe models were created using a free online tool available at
(Wireframe.cc, 2016). Skype interviews were used along with screencasting to gather first
impression from work group members and record their feedback and recommendations
how to improve the user experience. A good interface is intuitive from the start, ideally
require no special skills or lengthy reading sessions of the documentation.
The landing page is the first view that users see right after they log in to the system.
Members may participate in multiple work groups therefore it was considered essential to
have a quick overview of the current efforts. This view has been designed in a way that it
should be immediately clear which items need urgent attention (if any).
There is static part of all screens which is the top menu bar. This contains the most
important links for visiting Recent (from all work groups where the user is a member) and
Unread items (from all discussions where the user has made at least one comment). The
WG list or Groups entry shows the users current memberships. The Standard Documents
link provide easy access to the SiLA specifications and the Dashboard leads to the page
with high-level overview and statistics. To the right a search field and the profile settings
can be also found.
Figure 5.10: Welcome screen

The second main screen is the group page. Here the SiLA 2.0 items (behaviours,
commands, parameters) are listed. The sort and filtering criteria can be easily configured
just below the top menu bar. The proposed items include basic details such as name,
submitter, the item status and a short excerpt from the description. To the right side some
optional modules can be seen such as the list of online members, the top requested items
and latest activities from current and potentially other work groups. If a user clicks on the
name of an item, the system redirects to the details that is shown in the next screen.
Figure 5.11: Group main page
The detailed item proposal page shows a behaviour in the example below. After the de-
scription and the reason for submission a dynamically created list can be seen. This serves
as a quick way to identify uses and used by relations between behaviours, commands and
parameters.
Figure 5.12: Discussion page

Chapter 6
Validation
Following the principles of design science, one of the last steps is to measure the utility
of the IT artifact that has been designed. Because it is a web application, an experimental
evaluation method has been chosen (Hevner, A. R., March, S. T., Park, J., & Ram, S.,
2004).
6.1 Descriptive Analysis

There are three types of users of the FAST system: vendors who would like to submit an
item into the standard, work group members who discuss the requests and decide on the
technical details, finally the work group leaders or SiLA management who would like to
see high-level statistics.
6.1.1 Benefits
General benefits
A single common platform for standardisation
Much higher transparency as the status of all items can be easily tracked
Existing functionality already benefits the workflow
Benefits for vendors

A single point of contact with SiLA
Direct engagement in the standardisation leads to decreased cycle times
and less hindrance for development efforts
Benefits for work group members

Immediate summary of changes since last visit (Recent activities)
72
Chapter 6. Validation 73
Highly configurable e-mail notifications (event-based or digest mails)
Benefits for management

Management can see the bottlenecks, get information about velocity and
if there is a need for additional help in certain domains
6.1.2 Limitations
Many required features are still not yet developed
Deployment and testing cycles must be defined when to update the base
source code from upstream repositories. Before an upgrade process, plu-
gin compatibility must be carefully verified.
6.1.3 Cost-benefit analysis

As an alternative to custom software development, the costs are calculated if all work
group members would use the codeBeamer tool and the SiLA consortium would need to
pay the regular licensing fees. According to the vendors website, 60 perpetual named
licence would cost 54.000 EUR for only the requirements management module, not in-
cluding the mandatory support contract fees. Another option would be to rent the software
for 32.400 EUR per year, this price includes support as well. However, it must be noted
that codeBeamer is a general solution and would not include specific tailoring to the SiLA
2.0 workflows.
On the other hand, it has been estimated that the developing the most-requested 10
features (including functional requirements and integration with a version control system)
would fall between 800015000 EUR. Support must be also taken care of either using
in-house specialists or contractors. Premium support could be purchased from Enspiral,
the parent company of Loomio, for 1790 USD/year. It must be noted, that the quality
assurance of custom-built modules is not included in this price that would be a recurring
expense. The cost of this additional testing could be lowered by defining update cycles,
such as 13 times a year, when new upstream features can be merged into the system in a
controlled manner.
6.2 Process Analysis

6.2.1 Number of activities metric
The following diagram is showing the current standardisation process between vendors,
work groups, Technical Leadership Team, review committees and the General Assembly.
The number of activities (NOA) metric is a simple way to assess process complexity.
It is often compared to line of code (LOC) based metrics. These metrics should be never
used alone and it is important to only compare processes in the same domain, using the
same abstraction levels. Currently every change has to go through the full-blown process,
whether it is a minor or major adjustment.
Taking a simplistic view, it takes
N OAworkf low1 = 4 + 2 + 3 + 2 = 11
steps to go through the full standardisation process.
Figure 6.1: Current workflow between vendors, work groups, TLT, URC, SRC and GA
However, with SiLA 2.0, the goal is to separate the core standard from high-level
items. The core standard should contain the communication protocols and a well-defined
structure of taxonomy. On the other hand, the taxonomy itself should be developed inde-
pendently at a much higher pace. If terms are isolated and the minimum required oversight
is provided, then it is possible to accelerate taxonomy creation by nearly an order of mag-
nitude. The new process would include therefore
N OAworkf low2 = 4 + 4 = 8
steps. It is also beneficial that instead of six participants only two will be able to make
the necessary decisions through proper delegation. To make these changes the by-laws
needs to be changed and GA needs to vote on it as the supreme governing body of SiLA.
Figure 6.2: To-be taxonomy workflow between vendors and work groups
Figure 6.3: FAST effects on collaboration

6.3 User Survey

6.3.1 Setup and Participants
Sixty SiLA work group members were asked to take part in a controlled experiment, eval-
uating the tool. The test system was deployed in a virtualised environment and made
accessible over the Internet. Instructions about access and evaluation details were sent out
in two e-mails containing a short description. Then participants filled out a survey with 22
questions, focusing on usability aspects. The duration for accepting responses (30 May
10 June 2016) was twelve days. Users were presented with three main screens, that were
slightly modified based on interviews, as shown below.
Figure 6.4: Start screen

Figure 6.5: Work group main page
Figure 6.6: Discussion page

6.3.2 System Usability Metric (SUS)

Combining multiple usability aspects into a single value is one widespread method of
system validation. Although a relatively simple construct and called quick and dirty by
its author, System Usability Metric (Brooke et al., 1996) still captures a more balanced
result than a single user satisfaction metric.
Figure 6.7: SUS scores and acceptability ranges
SUS is using ten questions, alternating positive and negative statements to provide a
balanced evaluation. For odd-numbered questions, the score will be the scale position
minus 1. For the even-numbered questions, the score will be 5 minus the scale position.
Finally, to get the SUS score, the sum of scores needs to be multiplied by 2,5. The resulting
number will be between 0 and 100.
There are multiple ranges for acceptability that are often described with adverbs. As
a rough guideline, scores between 040 denote a not acceptable, 4050 a poor, 5060 an
acceptable, 6075 a good and 85100 an excellent score, respectively. The average score
of the FAST prototype is 60,4 that indicates a low, but already acceptable maturity. It must
be noted that users were asked to perform the evaluation without any prior knowledge
or training regarding the tool. In addition to scores, textual feedback was asked from
respondents. Some users recommended further changes in the user interface to make it
more intuitive and increase ease of use.
Figure 6.8: SUS scores for FAST
6.3.3 User Interface Metrics

Ten questions were asked from respondents regarding certain aspects of user experience
using a 7-point Likert scale. These included questions on navigation, consistency, acces-
sible help and other design elements. The majority of responses fell into the range from
slightly agree to moderately agree with the listed benefits. The two exceptions were
fast navigation and well-organised navigation. For the first, the Loomio base code is
providing almost instantaneous page loads which provides and excellent user experience.
The placement of menus, however, scored the lowest and should be improved further.
Figure 6.9: FAST usability survey

Overall satisfaction
The survey contained an additional question regarding overall satisfaction, on a scale from
1 to 10. The average score of 14 respondents was 6,9. Although it can not be directly
compared to the SUS result, they are relatively in the same range if it is roughly mapped
to the 1 to 100 scale (60,4 and 69).
Figure 6.10: Overall satisfaction rate with FAST

Chapter 7
Conclusions and Future Work
7.1 Conclusion
The SiLA 2016 questionnaire has shown that change is not only theorethically inevitable
but desired in practice. Furthermore, a faster standardisation process and a more trans-
parent, web-based collaboration tool would serve well the SiLA ecosystem and all of
the stakeholders. Additional interviews and surveys were used to analyse in details the
challenges, opportunities and which changes in processes and technical architecture could
take SiLA forward. Transparency and clear process deadlines increase predictability and
are key for convincing hesitant organisations that SiLA is ready to support development
efforts. This needs to be realised without inserting a significant delay while providing ad-
ditional business benefits. Finding, quantifying and communicating more of these gains is
imperative to increase organisational motivation to support SiLA. It is also beneficial for
volunteering experts who get recognition from the visibility of the work done.
Considerable efforts were put into exploring taxonomies and designing the related tool-
ing. These two domains, like a language and the collaboration platform to develop the
language, are co-dependent. Their success together will be able to bring a new momentum
for the SiLA standardisation work.
7.2 Future Work

Creating the final SiLA 2.0 taxonomies is a challenging effort. To avoid philosophical de-
bates, well-sized agile teams with an interdisciplinary composition are best suited to find
the optimal trade-offs between simplicity, consistency, easy implementation and maintain-
ability. Finalising the terminology is critical before any further progress can be made.
Following this, the separation of the core standard from the taxonomies will be able to
satisfy one of the fundamental goals of the SiLA 2.0 initiative.
From a technical point of view, benchmarks between WS-Discovery and Bonjour ser-
vice discovery protocols would help to make a decision if there is any significant techno-
82
Chapter 7. Conclusions and Future Work 83
logical benefit for the latter, looking also at the Lab 4.0 (Lab as a Service) scenarios. This
is also true for the base communication protocol where AMQP is a strong candidate to
provide a robust communication infrastructure. Benchmarking different implementations
fell out of scope of this thesis. However, small computing platforms, such as the SolidRun
CuBox-i device, can be effectively used to test low-resource optimised AMQP offerings.
Lastly, the development of additional plugins according to the prioritised feature list
needs to continue. Further investigations should focus on improving navigation, making it
more straightforward to both work group members and vendors. High-level statistics and
additional motivational techniques for the collaboration tool, such as top contributors and
leaderboards would provide a further underpinning to the transparency-increasing efforts.
Figure 7.1: SiLA Provider Implementation Community Equipment (SPICE) running on CuBox-i
Bibliography
H. Abbes and J.-C. Dubacq. Analysis of Peer-to-Peer protocols performance for establish-
ing a decentralized desktop grid middleware, Aug. 2008.
AnIML. Core schema - AnIML. https://www.animl.org/core-schema,
2014a. Accessed: 2016-5-17.
AnIML. Overview - AnIML. https://www.animl.org/overview, 2014b. Ac-

cessed: 2016-5-2.
Apache Foundation. Apache licenses. http://www.apache.org/licenses/, Jan.
2004. Accessed: 2016-5-11.
ASTM. ASTM international - about ASTM international. http://www.astm.org/

ABOUT/overview.html, 2016. Accessed: 2016-5-3.
ASTM International. ASTM E1989 - 98(2004) standard specification for laboratory equip-
ment control interface (LECIS) (withdrawn 2009). http://www.astm.org/
Standards/E1989.htm, 2009. Accessed: 2016-5-2.
R. D. Bartlett. Crafting strategy in a collaborative organisation

enspiral tales. https://medium.com/enspiral-tales/
crafting-strategy-in-a-collaborative-organisation-989fa34e6e24,
13 Sept. 2015. Accessed: 2016-4-28.
E. Bastidas. SOFIA: an open source laboratory automation and integration SiLA frame-
work. Masters thesis, Master Thesis for the International Master in Service Engi-
neering (IMSE), 2015.
J. L. Berg and H. Schumny. An Analysis of the Information Technology Standardization
Process. Elsevier, 1990.
K. Blind. An economic analysis of standards competition: The example of the ISO ODF
and OOXML standards. Telecommunications Policy, 35(4):373381, May 2011.
84
K. Blind, B. Knut, and M. Axel. Motives to standardize: Empirical evidence from ger-
many. Technovation, 48-49:1324, 2016.
Bluetooth. Member directory. https://www.bluetooth.com/
membership-working-groups/member-directory, Mar. 2016. Ac-
cessed: 2016-5-4.
C. Bormann and P. Hoffman. Concise binary object representation (CBOR). Oct. 2013.
C. Bormann, S. Lemay, Z. Technologies, and H. Tschofenig. A TCP and TLS transport for
the constrained application protocol (CoAP). https://datatracker.ietf.
org/doc/draft-tschofenig-core-coap-tcp-tls/, Sept. 2014. Ac-
cessed: 2016-5-19.
J. Brooke et al. Sus-a quick and dirty usability scale. Usability evaluation in industry, 189
(194):47, 1996.
S. Cheshire. Zero configuration networking (zeroconf). http://www.zeroconf.
org/, 2003. Accessed: 2016-5-4.
S. Cheshire. How does zeroconf compare with Viiv/DLNA/DHWG/UPnP? http://

www.zeroconf.org/ZeroconfAndUPnP.html, 2006. Accessed: 2016-5-4.
CiA. CAN in automation (CiA): CANopen internal device architecture. http://www.
can-cia.org/can-knowledge/canopen/device-architecture/,
2016. Accessed: 2016-5-16.
U. Consulting. GMP drug warning letters issued in calendar year 2015 - data integrity
deficiencies. http://ungerconsulting.net/wp-content/uploads/
2016/01/WL-TOTAL-SUMMARY-ANALYSIS.pdf, 2016. Accessed: 2016-5-3.
D. Davis, A. Malhotra, K. Warr, and W. Chou. Web services metadata
exchange (WS-MetadataExchange). https://www.w3.org/TR/
ws-metadata-exchange/, 13 Dec. 2011. Accessed: 2016-5-30.
H. J. de Vries. Standardization: A Business Approach to the Role of National Standard-
ization Organizations. Springer Science & Business Media, 29 June 2013.
D. S. Derue, D. Scott Derue, J. D. Nahrgang, W. Ned, and S. E. Humphrey. TRAIT AND

BEHAVIORAL THEORIES OF LEADERSHIP: AN INTEGRATION AND META-
ANALYTIC TEST OF THEIR RELATIVE VALIDITY. Pers. Psychol., 64(1):752,
2011.
Dictionary.com. The definition of consistency. http://www.dictionary.com/
browse/consistency. Accessed: 2016-5-16.
S. L. Dyson. THE ROADS OF ITALY r. laurence: The roads of roman italy. mobility and
cultural change . pp. xiii 221, ills. london and new york: Routledge, 1999. cased, 50.
ISBN: 0-415-16616-0. Classical Rev., 53(02):412, 2003.
85
ELIXIR. ELIXIR structure about ELIXIR ELIXIR. https://www.
elixir-europe.org/about/elixir-structure, 2014a. Accessed:
2016-5-2.
ELIXIR. ELIXIR programme 2014-2018 about ELIXIR ELIXIR. https://www.
elixir-europe.org/about/elixir-programme-2014-2018, 2014b.
Accessed: 2016-5-2.
European Commission. Standardisation policy - european commission. http:
//ec.europa.eu/growth/single-market/european-standards/
policy/index_en.htm, 2016. Accessed: 2016-5-23.
L. A. Fernando. Python-ws-discovery. https://code.google.com/archive/

p/python-ws-discovery/, 2009. Accessed: 2016-4-28.
F. FuiHoon Nah, F. F. Nah, J. L. Lau, and K. Jinghua. Critical factors for successful
implementation of enterprise systems. Business Process Management Journal, 7(3):
285296, 2001.
Granzer, W., Kastner, W. and Furtak, P. KNX and OPC UA. In Konnex Scientific Confer-
ence (Vol. 18), Nov. 2010.
R. Guthrie. Loomio plugin tutorial. https://github.com/loomio/loomio,
2016. Accessed: 2016-5-20.
Hevner, A. R., March, S. T., Park, J., & Ram, S. Design science research in information
systems. MIS Quarterly, 28(1):75105, 2004.
IANA. IANA port numbers. http://www.iana.org/assignments/
service-names-port-numbers/service-names-port-numbers.
txt, 3 May 2016. Accessed: 2016-5-4.
Idea Group Pub. Advanced Topics in Information Technology Standards and Standardiza-
tion Research, volume 1. Idea Group Pub., 2006.
D. Ince. The duke university scandal what can be done? Significance, 8(3):113115,
25 Aug. 2011.
IoTivity. Finding a resource IoTivity. https://www.iotivity.org/

documentation/linux/programmers-guide/finding-resource,
2016. Accessed: 2016-5-15.
K. Jakobs. Advanced Topics in Information Technology Standards and Standardization
Research. Idea Group Pub, 2006.
Kaazing. HTML5 WebSocket - a quantum leap in scalability for the web. http://www.
websocket.org/quantum.html. Accessed: 2016-5-5.
A. Keranen, M. Ersue, and C. Bormann. Terminology for Constrained-Node networks.
May 2014.
86
B. LLC. scinote open source electronic lab notebook. http://scinote.net/,
2016. Accessed: 2016-5-27.
Marc de Graauw. Nobody needs reliable messaging. http://www.infoq.com/
articles/no-reliable-messaging, June 2010. Accessed: 2016-5-13.
M. L. Markus, A. Majchrzak, and L. Gasser. Design theory for systems that support
emergent knowledge processe. MIS Quarterly, 26(3):179212, Sept. 2002.
Markus, M. L., Steinfield, C. W., Wigand, R. T., & Minton, G. Industry-Wide informa-
tion systems standardization as collective action: The case of the U.S. residential
mortgage industry. MIS Quarterly, 30:439465, 2006.
G. Moritz, M. Guido, G. Frank, and T. Dirk. A lightweight SOAP over CoAP transport
binding for resource constraint networks. In 2011 IEEE Eighth International Confer-
ence on Mobile Ad-Hoc and Sensor Systems, 2011.
G. Nagarjuna. Why ecma OOXML cannot be regarded as a free/open document standard?
Note submitted to the Working Committee, Board of Indian Standards on Wordpro-
cessingXML, a component of OOXML, 16 May 2007.
Niwatori. Ruby architecture. https://picasaweb.google.com/Dikiwinky/
Ruby#5116531304417868130, 2007. Accessed: 2016-5-20.
OASIS. OASIS web services dynamic discovery (WS-Discovery) version 1.1.
http://docs.oasis-open.org/ws-dd/discovery/1.1/os/
wsdd-discovery-1.1-spec-os.html, 1 July 2009. Accessed: 2016-
5-4.
OASIS. SOAP binding to advanced message queuing protocol (AMQP) transport
version 1.0. https://www.oasis-open.org/committees/download.
php/51565/amqp-soap-v1.0-wd03.doc, 09 Sept. 2013. Accessed: 2016-
5-19.
OASIS Web Services Discovery and Web Services Devices Profile (WS-DD)
TC. OASIS web services dynamic discovery (WS-Discovery) version
1.1. http://docs.oasis-open.org/ws-dd/discovery/1.1/os/
wsdd-discovery-1.1-spec-os.html, 1 July 2009. Accessed: 2016-5-18.
Object Management Group, Inc. Laboratory equipment control interface specification.

http://www.omg.org/spec/LECIS/1.0/, Mar. 2003. Accessed: 2016-5-4.
OCF. OPEN CONNECTIVITY FOUNDATION (OCF). http://
openconnectivity.org/, 2016. Accessed: 2016-5-11.
OIC. OIC specification overview. http://openconnectivity.org/

wp-content/uploads/2016/01/OIC_Specification_Overview_
201501131.pdf, Jan. 2016. Accessed: 2016-5-11.
87
OPC. OPC foundation specifications agreement of use. https://opcfoundation.
org/license/specifications/1.13/index.html, 2016. Accessed:
2016-5-9.
H. Pashler and E.-j. Wagenmakers. Editors introduction to the special section on replica-
bility in psychological science. Perspect. Psychol. Sci., 7(6):528530, 1 Nov. 2012.
Pautasso, Zimmermann & Leymann. RESTful web services vs. big web services: Mak-
ing the right architectural decision, 17th international world wide web conference
(WWW2008. In SOA4All, Enabling the SOA Revolution on a World Wide Scale.
Proceedings of the 2nd IEEE International Conference on Semantic Computing IC-
SCIEEE Computer Society, 2008.
T. Preston-Werner. Semantic versioning 2.0.0. http://semver.org/, June 2013.

Accessed: 2016-5-20.
RedHat. Red hat 2015 earnings report. https://investors.redhat.
com//media/Files/R/Red-Hat-IR/documents/events/
rht-reports-fourth-quarter-results-for-fiscal-year-2016.
pdf, 22 Mar. 2016. Accessed: 2016-5-4.
E. Rescorla and N. Modadugu. Datagram transport layer security version 1.2. Jan. 2012.
J. M. Roberts, M. F. Bean, C. Bizon, J. C. Hollerton, and W. K. Young. The
adaptable laboratory: A holistic informatics architecture. http://www.
americanpharmaceuticalreview.com/Featured-Articles/
37098-The-Adaptable-Laboratory-A-Holistic-Informatics-Architecture/,
1 Jan. 2011. Accessed: 2016-5-16.
J. H. Saltzer, D. P. Reed, and D. D. Clark. End-to-end arguments in system design. ACM
Trans. Comput. Syst., 2(4):277288, 1984.
Z. Shelby, K. Hartke, and C. Bormann. The constrained application protocol (CoAP). June
2014.
SiLA. Downloads SiLA rapid integration. http://www.sila-standard.org/
downloads/, Nov. 2013. Accessed: 2016-5-5.
SiLA. About SiLA SiLA rapid integration. http://www.sila-standard.org/

about-sila/, 2016a. Accessed: 2016-5-17.
SiLA. Membership SiLA rapid integration. http://www.sila-standard.
org/corporate-members/, 2016b. Accessed: 2016-5-15.
SiLA. SiLA organigram SiLA rapid integration. http://www.sila-standard.
org/about-sila/sila-organigram/, 2016c. Accessed: 2016-5-3.
M. Skjegstad. Google code archive. https://code.google.com/archive/p/
java-ws-discovery/, 2011. Accessed: 2016-4-28.
88
D. Skvorc, M. Horvat, and S. Srbljic. Performance evaluation of websocket protocol for
implementation of full-duplex web streams. In 2014 37th International Convention
on Information and Communication Technology, Electronics and Microelectronics
(MIPRO), 2014.
THE RADICATI GROUP, INC. Email statistics report 2013-2017. http:
//www.radicati.com/wp/wp-content/uploads/2013/04/
Email-Statistics-Report-2013-2017-Executive-Summary.pdf.
Accessed: 2016-5-2.
US-CERT. UDP-Based amplification attacks. https://www.us-cert.gov/ncas/
alerts/TA14-017A, Jan. 2014. Accessed: 2016-5-5.
N. US Department of Commerce. Redefining the kilogram in focus: History. http://

www.nist.gov/pml/si-redef/kg_focus_history.cfm, 7 Oct. 2014.
Accessed: 2016-5-17.
D. Vries. Standards for business: How companies benefit from international standard
setting. Technical Report 128141., IEC, 2006.
W3C. W3C XML schema definition language (XSD) 1.1 part 1: Structures. https:
//www.w3.org/TR/xmlschema11-1/, 5 Apr. 2012. Accessed: 2016-5-4.
P. Walsh. Reengineering the standards preparation process, ASTM. Standardization News,
25(10):1415, 1997.
Web of Things Interest Group. Discovery categories and tech landscape - web of
things interest group. https://www.w3.org/WoT/IG/wiki/Discovery_
Categories_and_Tech_Landscape, Feb. 2016. Accessed: 2016-5-20.
S. Whittaker, W. Steve, and S. Candace. Email overload. In Proceedings of the SIGCHI
conference on Human factors in computing systems common ground - CHI 96, 1996.
WHO. WHO zika virus. http://www.who.int/mediacentre/
factsheets/zika/en/, 15 Apr. 2016. Accessed: 2016-5-27.
Wireframe.cc. Wireframe.cc - minimal wireframing tool. https://wireframe.cc/,
2016. Accessed: 2016-5-20.
K. Zajaczkowski. The bluetooth protocol stack. https://en.wikipedia.org/

wiki/File:Bluetooth_protokoly.svg, Aug. 2010. Accessed: 2016-5-9.
89
Appendix
Questions of the SiLA 2016 Questionnaire (7-point Likert scale)

1. The current speed of SiLA standardisation supports well the innovation
efforts of my organisation/team.
2. The current (organisational) structure of SiLA standardisation work groups
promote an efficient collaboration process.
3. Technical oversight provided by SiLA work group leaders ensure a high-
quality standard in general.
4. The current speed of SiLA standardisation introduces a large bottleneck/overhead
into development compared to business requirements.
5. Participating in SiLA is regarded strategically important in my organisa-
tion.
6. I have an explicit amount of time allocated to work on SiLA.
7. I can make and keep commitments to contribute to SiLA without many
collisions from other tasks in my day-to-day job.
8. SiLA governance, voting procedures and by-laws are promoting an effi-
cient and relatively fast way of standardisation.
9. A faster SiLA standardisation process would: [Accelerate innovation]
10. A faster SiLA standardisation process would: [Enable new market op-
portunities]
11. A faster SiLA standardisation process would: [Enable new business mod-
els]
12. A faster SiLA standardisation process would: [Reduce development costs]
13. A faster SiLA standardisation process would: [Reduce testing costs]
14. A faster SiLA standardisation process would: [Reduce maintenance costs]
15. A faster SiLA standardisation process would: [Be the most important
aspect to improve to advance SiLA as a whole]
16. A faster SiLA standardisation process would: [Make SiLA more appeal-
ing to invest in]
17. A faster SiLA standardisation process would: [Make SiLA more valuable
as a standard]
18. How satisfied are you with the collaboration efficiency of your primary
way of communication (reliability, ability to track issues, etc.)?
App. 1
19. Sometimes it is hard to find the latest version of a document that is a
work in progress (version control).
20. It is easy to find related documents that are needed to understand and join
a specific SiLA work group discussion.
21. A web-based tool (issue threads, voting, document management, etc.)
would be helpful in speeding up the standardisation.
Questions of the System Usability Study (SUS) (5-point Likert scale)
1. I think that I would like to use this system frequently

2. I found the system unnecessarily complex
3. I thought the system was easy to use
4. I think that I would need the support of a technical person to be able to use this
system
5. I found the various functions in this system were well integrated
6. I thought there was too much inconsistency in this system
7. I would imagine that most people would learn to use this system very quickly
8. I found the system very cumbersome to use
9. I felt very confident using the system
10. I needed to learn a lot of things before I could get going with this system
Further questions on FAST user experience (7-point Likert scale)
1. Navigation is well organized.

2. The application uses intuitive words and language.
3. If I make a mistake, is easy for me to correct it.
4. It is easy to see the status of submitted items (e.g. a command).
5. The application uses consistent words and actions to represent the same concepts.
6. The application prevents me from making mistakes.
7. The application doesnt require me to remember where various settings are located,
they are easy to find and placed intuitively.
8. The application is aesthetically pleasing and uses the right amount of design.
9. Navigation is fast across the website.
10. Tips/help links are easy to access and useful.
App. 2
Figure 7.2: SiLA v1.3 State Machine Model Diagram
App. 3
Table A.1: Corporate members of the SiLA consortium (Feb 2016)
Company Membership Joined HQ Founded Country

4titude Ltd Startup 2013 Surrey 2005 UK
Actelion Pharma Schweiz AG Core 2009 Baden 1996 Switzerland
Agilent Technologies Inc. Supporting 2011 Santa Clara, CA 1999 USA
Analytik Jena AG Supporting 2009 Jena 1990 Germany
apartis Information Management Supporting 2015 Bingen on the Rhine 1997 Germany
Beckman Coulter Inc. Core 2014 Pasadena, CA 1935 USA
Brooks Automation Inc. Supporting 2009 Chelmsford, MA 1978 USA
BSSN Software Startup 2015 Darmstadt 2003 Germany
Credimex AG Supporting 2014 Alpnach 1949 Switzerland
Eppendorf AG Core 2012 Hamburg 1945 Germany
EQUIcon Software GmbH Jena Supporting 2008 Jena 1992 Germany
F. Hoffmann-La Roche Core 2009 Basel 1896 Switzerland
Fraunhofer IPA Academic 2012 Stuttgart 1949 Germany
Fritz Gyger AG Supporting 2013 Heimberg 1959 Switzerland
GlaxoSmithKline plc Core 2015 Brentford 2000 UK
Hamilton Company Core 2008 Whittier, CA 1947 USA
HSR Hochschule fur Technik Rapperswil Academic 2014 Rapperswil 1972 Switzerland
Infoteam Software AG Supporting 2009 Bubenreuth 1983 Germany
Inheco GmbH Startup 2012 Planegg 2000 Germany
Lab Services Startup 2016 Breda 1996 Netherlands
Liconic AG Supporting 2013 Liechtenstein 1990 Liechtenstein
Mettler-Toledo AG Core 2014 Greifensee 1992 Switzerland
Molecular Devices LLC Core 2014 Silicon Valley, CA 1983 USA
Novartis Pharma AG Core 2009 Basel 1996 Switzerland
Perkin Elmer Inc. Core 2014 Waltham, MA 1937 USA
Promega Corp. Supporting 2014 Madison, WI 1978 USA
Seyonic SA Supporting 2014 Neuchatel 1998 Switzerland
Tecan Schweiz AG Core 2009 Hombrechtikon 1980 Switzerland
Thermo Fisher Scientific Inc. Core 2009 Waltham, MA 1902 USA
Wega Informatik AG Supporting 2014 Basel 1993 Switzerland
Xavo Systems AG Supporting 2009 Reinach 2000 Switzerland
Table A.2: Comparison of communication protocols (1.)
REST SOAPjr JSON-WSP SOAP WebSockets

Main Simple RPC-like SOAP-like sepa- Adding service de- Platform and lan- Full-duplex TCP con-
concept mechanism, scal- ration of data and scriptor to JSON- guage independent, nection through HTTP
able, building on metadata, using RPC QoS, Encryption, Upgrade, goes through
existing web infras- JSON instead of Error handling, firewalls
tructure (caching) XML Extendable with
WS-* standards
Usage Public APIs, direct Lightweight alterna- Lightweight alterna- Within and across For event-oriented
point-to-point com- tive to SOAP tive to SOAP-WSDL enterprises apps, alternative to
munication AJAX
Inter- op- Architectural style, Open specification Open specification SOAP v1.2 - W3C IETF as RFC 6455
erability using HTTP, URI, recommendation
JSON, and XML
OSI 5 6 6 6 4
Layer
Transport HTTP HTTP HTTP Any TCP
Security TLS, Depends on E2E (payload) en-
developer to avoid cryption
cross-site and other
attacks
Table A.3: Comparison of communication protocols (2.)
AMQP CoAP MQTT XMPP OPC-UA

Main concept Open standard ap- Designed specifically to be Lightweight Extensible Messag- The Interoperability
plication layer pro- an IoT protocol, Built-in pub-sub proto- ing and Presence Standard for Indus-
tocol, Message ori- discovery, multicast sup- col Protocol, decentral- trial AutomationTM
ented middleware port and asynchronous ized architecture
message exchanges.
Usage Pub-sub, flexible Design principles: low M2M/IoT Multi-party chat, Collaboration be-
for internal net- overhead, work in very connectivity, voice and video tween devices and
works, enterprise constrained environments, Amazon WS calls, collaboration, Industry applica-
originated low energy consumption, generalized routing tions
adequate security of XML data
Inter- oper- OASIS standard IETF RFC 7252 ISO/IEC PRF RFC 6120,6121 Proprietary stan-
ability 20922 dard
OSI Layer 7 5-7 7 7 5-7
Transport TCP TCP/UDP, TCP, MQTT-SN TCP/HTTP, XML TCP, HTTP(S),
CBOR/JSON/EXI/XML for non TCP/IP Binary/XML-SOAP
networks (e.g.
ZigBee)
Security TLS, SASL, Ker- DTLS ( 3072-bit RSA) TLS, no stan- TLS, SASL SOAP-HTTPS,
beros dard payload OpenSSL certifi-
encryption cates, User ACL,
custom views,
Auditing
Table A.4: Comparison of discovery protocols
WS-Discovery SSDP DNS-SD mDNS Argo CoAP discovery

Version 2009, Oasis 1999, DRAFT 2013, RFC 2013, RFC 2016, v0.4.1 2014, IETF RFC
Standard 6763 6762 7252
Discover Services Device service Named list Services via Long-range dy- Resource discov-
/ Goal advertisement of service multicast namic discovery ery, REST model
instances (WAN) for small devices
Used in Printers (e.g UPNP, DLNA Avahi (Linux), Bonjour (Apple), AllJoyn, QBlab Special cases, Open Interconnect
HP, Brother), Cyber- defense Consortium (OIC
media devices and OCF
Use mul- Yes Yes Can Yes Yes Can
ticast
Use DNS No No Yes Yes No Can
Security Not secure None, DDoS Vulnerable MITM, Strong DTLS ( 3072-bit
without WS- vulnerability to Man in DDOS if re- (SSL/2-way- RSA), vulnerable
Security, WS- the mid- ply to outside SSL/Payload to cross-protocol
SecureConversation dle attacks multicast encryption attacks (DNS)
and WS-Trust (MITM) requests possible)
Library Java, Python, C, GObject, Avahi C library, Bonjour SDK, .NET, Ruby Java C, Java, JS,Ruby,
Ruby, C#, WSD Windows Python, C#, Go
and WPDS Provider, .NET
IoT focus No No No No Partial Yes (RFC 7228)
Transport TCP/UDP, UDP UDP UDP UDP TCP/UDP
SOAP
Table A.5: Requested features by category and priority (1.)
Category Feature Feature description USER AVG PRI
Comments Commenting Discuss specifications, new items 8,86

Comments Upvote comments Like, +1, can be used for priority 5,57
Content New com- Add new command / parameter / behaviour by SiLA member, mandate reason why 8,43
mand/parameter/behaviour existing is not sufficient
Content Proposal status/life cycle Workflow engine statuses - Draft - Under discussion - Voting - Decided (+ other 8,14
statuses like Waiting for review, Accepted, Element-basis status tracking)
Content Version control of uploads History of uploaded documents 8,00
Content Backtrack-Linkback to ex- Tracking linkbacks to an existing items - describe whats missing 7,86
isting items
Content Audit trail Track changes in proposals and comments 7,67
Content Document management Upload/download documents - DOC, XLS, PPT, PDF, XML, ZIP, TXT 7,57
Content Follow up with item later Mark an item to be considered in a later version 7,50
Content Search Full-text search 7,43
Content Full-text version control of Full-text version control of documents (text based files) - track changes 7,29
docs
Content Link schemas with items in Use a version control system e.g. GitHub repositories to link code and content 7,17
the standard together, using API - https://developer.github.com/v3/issues/assignees/
Content Ensure unique names Avoid command/parameter/behaviour name collisions 7,14
Content Add image Add graphics (JPG, PNG) and display in the discussion (thumbnail - large image) 7,00
Content Naming conventions Ensure naming conventions are followed - promote consistency across the stan- 6,71
dards
Content Generate the SiLA standard LaTex could be used? 6,43
output from the tool
Content Tagging Tag proposals and new items for easier searchability 5,43
Content Real-time saving Without hitting the save button 3,50
Customize Sort items Predefined/user-defined sorting criteria (Last updated, Level of activity) 6,86
Table A.6: Requested features by category and priority (2.)
Category Feature Feature description USER AVG PRI
Customise Redirect after login After LOGIN, get to the last view that the user saved 3,71
Customise Change the arrangement of e.g. if someone wants to see online user list 2,71
windows, customise views
Design Emphasise critical tasks Put important task to the TOP - clear responsibilities - blocking work to the TOP 7,71
Design Hierarchy of elements Collapsing parameters and commands to behaviour elements on main list screen 7,57
Design Internal deadline tracking Can be used for sorting purposes - soft deadline 7,29
Design Responsive design Tablet-mobile friendly GUI 5,29
Manage Roadmap Plan milestones and releases - read-only function by members 7,57
Manage Work group management Create WGs and add members to work groups on admin GUI 7,00
Manage Dashboard Overview of SiLA - Show statistics, most active contributors and topics 5,57
Manage Roadmap Plan milestones and releases - plan on GUI, advanced visualisation (charts) 3,43
Notification Configurable E-mail notifi- Configure scope and frequency of e-mail notifications 7,71
cations
Notification Auto-subscribe on editing If you comment to a topic, then the system will send notifications onwards 5,50
Notification Opt-in e-mail event-based Get digest mail by default + on login display the latest changes i.e. digest that 4,86
notifications would have been sent in e-mail (if user completely turn off e-mail)
Notification Number of unread mes- Show number of unread messages on TOP ribbon 4,50
sages
Notification Push notifications Display events on mobile phones 3,57
Process Assign owner to proposal Assign a person by the work group leader - name someone who has to process this 8,57
item
Process Assign proposals to right Identify target WG and route proposal accordingly (MULTIPLE WG CAN BE 7,00
WG INTERESTED - help the users by choosing category)
System User access control Registration, username - password authentication 8,57
Voting Vote on motions Motion (Supplier Review Committee - SRC,URC) - Yes/No vote with reasoning N/A
Voting Vote on new be- SiLA paying member submit new item proposal, Yes/No vote with reasoning 8,33
haviour/command/parameter

Standardization in Lab Automation (Sila) 2.0 Making The Standard Fit For The Future and Adapting An Open-Source Collaboration Platform For Standards Development

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Standardization in Lab Automation (Sila) 2.0 Making The Standard Fit For The Future and Adapting An Open-Source Collaboration Platform For Standards Development

Загружено:

Авторское право:

Доступные форматы

S TANDARDIZATION IN L AB AUTOMATION (S I LA) 2.

IMSE M ASTER S T HESIS

Standards in Laboratory Automation (SiLA) is a vertical industry standard that promotes

List of Figures viii

4 SiLA Analysis and Future Improvements for SiLA 2.0 36

5 Flexible Agile Standardisation Tool (FAST) 56

7 Conclusions and Future Work 82

2.1 CANopen address ranges (CiA, 2016) . . . . . . . . . . . . . . . . . . . 23

3.1 Research question linkage . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1 Process deadlines per stages . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1 User stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

A.1 Corporate members of the SiLA consortium (Feb 2016) . . . . . . . . . . App. 4

1.1 Research process of the Masters thesis . . . . . . . . . . . . . . . . . . . 6

2.1 SiLA organisational diagram (SiLA, 2016c) . . . . . . . . . . . . . . . . 15

3.1 Information Systems Research Framework (Hevner, A. R., March, S. T.,

4.1 SiLA standardisation process . . . . . . . . . . . . . . . . . . . . . . . 37

5.1 Core concepts of standards development . . . . . . . . . . . . . . . . . . 57

7.1 SiLA Provider Implementation Community Equipment (SPICE) running

If you think of standardization as the

1.2 Research Topic

buses, it is getting increasingly feasible to build robust communication infrastructures.

1.3 Research Problem

1.4 Research Goal

1.5 Research Questions

1.6 Research Overview

Figure 1.1: Research process of the Masters thesis

1.7 Document Structure

Chapter 2 Literature Review

Chapter 3 Research Methodology

Chapter 4 SiLA Analysis and Future Improvements for SiLA 2.0

Chapter 5 Collaboration Tool Design

Chapter 7 Conclusions and Future Work

1.8 Common Abbreviations

2.1 Worldwide Standards

2.2 Vertical IS Standards

2.2.2 Mortgage Industry Standards Maintenance Organization (MISMO)

2.3 Key Reasons for Standardisation

Driving business results in unexpected ways

Participation increases market share

Avoiding costs by being informed early

through their involvement in standardisation. After the widespread Bovine spongiform

Savings on product testing

Lessons from the cases

Additional reasons for standardisation

2.4 Collaboration Initiatives in the Life Science Industry

Device Control & Data Interface Specification for communication be-

Figure 2.1: SiLA organisational diagram (SiLA, 2016c)

Core: suppliers and users above 50 million EUR

2.4.2 Analytical Information Markup Language (AnIML)

Figure 2.2: SiLA membership level comparison matrix (SiLA, 2016b)

different measurement techniques, independent of data sources and provide compatibility

2.4.3 Allotrope Foundation

dress pressing issues regarding laboratory integration challenges. Allotrope Foundation

Data descriptors (metadata) in a Resource Description Framework (RDF)

2.4.4 Laboratory Equipment Control Interface Specification (LECIS)

Figure 2.4: Elixir Scientific Program (ELIXIR, 2014b)

2.5 Connectivity Protocol Stacks

Support resource-constrained environments (e.g. with less than 10KB

Figure 2.5: OIC standard protocol stack (OIC, 2016)

Figure 2.6: The Bluetooth Protocol Stack (Zajaczkowski, 2010)

2.5.3 Open Platform Communications Unified Architecture

Figure 2.7: (CiA, 2016)

2.5.5 Licensing and patenting issues