1 (127)
RESEARCH REPORT
Interoperability Environment
for Smart Cities (InterCity)
Report of Phase 1 –
Current State
Authors:
Thomas Casey, Ville Valovirta, Immo Heino
2 (127)
Report’s title
Interoperability Environment for Smart Cities (InterCity) - Report of Phase 1 - Current State
Project name
Short name
Interoperability Environment for Smart Cities (InterCity)
InterCity
Author(s)
Pages
Thomas Casey, Ville Valovirta, Immo Heino
127
Keywords
Report identification code
Smart city, Interoperability
VTT-R-00582-16
Summary
The smart city has become an established way to depict the evolution towards more real-time
and intelligent ways of providing services with a strong public interest. However, smart city
solutions seem to be fragmented across cities and sectors (e.g. mobility, built environment,
energy), with, for example, vendor lock-in being a common problem, leading to a situation
where innovations do not diffuse widely and reach their full potential. To address the problem
of smart city fragmentation and vendor lock-in, the goal of the Smart City Interoperability
Environment (InterCity) project is to examine how the market structure could shift from a
closed and vertical model, where dedicated solutions are implemented for each city and
sector, to an open and horizontal interoperability environment across cities and smart city
sectors.
This report acts as a deliverable for Phase 1 of the project, which focuses on examining the
current state of smart city interoperability. The report examines key interoperability and smart
city concepts, and looks into how the different smart city sectors are structured in Finland and
what their current state is in terms of the application of ICT and interoperability. Furthermore,
the report studies what kinds of actors exist around smart city evolution, and what
international developments are ongoing, and also analyses a few case examples of existing
and possible domestic activities that are evolving towards a multi-actor environment.
The overall goal of this report is also to gain an understanding of what kinds of interoperability
elements are needed in the different smart city sectors, and what would qualify as good use
cases and pilots for which the first horizontal processes could be created and deployed in the
next phases of the project. The general conclusion is that the current smart city solutions, at
least in Finland, are in fact, to a large degree, fragmented and that there is a need for
horizontal processes such as common procurement practices and interoperability testing and
certification.
Confidentiality
Public
Espoo 5.2.2016
Written by
Thomas Casey, Ville Valovirta,
Immo Heino
3 (127)
Raportin nimi
Smart City –yhteentoimivuusympäristö – 1. Vaiheen raportti - Nykytila
Projektin nimi
Projektin numero/lyhytnimi
Smart City –yhteentoimivuusympäristö
InterCity
Raportin laatijat
Sivujen/liitesivujen lukumäärä
Thomas Casey, Ville Valovirta, Immo Heino
127
Avainsanat
Raportin numero
Smart city, yhteentoimivuus
VTT-R-00582-16
Tiivistelmä
Tieto- ja viestintäteknologioiden soveltaminen kaupunkiympäristön eri osa-alueilla, nk. smart
city -ratkaisut, tarjoavat kaupungeille ja kunnille mahdollisuuden luoda uusia palveluja,
sujuvoittaa prosesseja, säästää kustannuksissa, aktivoida kaupunkilaisia ja edistää
yritystoiminnan kehittymistä sekä kestävää kehitystä. Käytännössä kuitenkin smart city ratkaisut ovat tällä hetkellä paljolti sirpaloituneita ja kaupungit sekä toimialasektorit (esim.
liikenne, rakennettu ympäristö ja energia) toimivat erillään. Tämä on johtanut tilanteeseen,
jossa innovaatiot eivät leviä kaupunkien ja sektorien välillä eivätkä markkinat pääse
kasvamaan.
Smart City –yhteentoimivuusympäristö projektin tavoitteena on vastata tähän haasteeseen ja
selvittää sekä konseptoida sitä, miten eri smart city -aihealueen sektoreiden sekä kaupunkien
välille voitaisiin synnyttää kansallisen tason yhteentoimivuusympäristö ja markkina. Tässä
raportissa esitellään tulokset projektin ensimmäisestä vaiheesta, jossa on tehty
taustakartoitus yhteentoimivuuteen sekä smart city-aihealueeseen sekä selvitetty smart city
sektoreiden nykytilaa suomessa ICT:n soveltamisen ja yhteentoimivuuden suhteen. Lisäksi
raportissa tarkastellaan smart city-teemaan liittyvää toimijajoukkoa, kansainvälistä kehitystä
sekä muutamaa kotimaista esimerkkitapausta, jossa on nähtävissä kehitys kohti modulaarista
monen toimijan yhteentoimivuusympäristöä.
Raportin tavoitteena on parantaa ymmärrystä sen suhteen, mitä yhteentoimivuusympäristön
elementtejä tarvittaisiin eri sektoreilla ja mihin smart city-kehityshankkeisiin olisi järkevää
tuoda yhteentoimivuutta tukevia toimintatapoja, joita kehitetään projektin myöhemmässä
vaiheessa. Selvityksen lopputuloksena voidaan todeta, että nykyiset smart city-palvelut ovat
sirpaloituneita ja että yhteentoimivuutta edistäville toimintamalleille, kuten esim. yhteisille
hankintaperiaatteille sekä yhteentoimivuuden testaukselle ja sertifioinnille, on selkeä tarve.
Luottamuksellisuus
Julkinen
Espoo 5.2.2016
Laatijat
Thomas Casey, Ville Valovirta,
Immo Heino
4 (127)
Contents
Contents ................................................................................................................................. 4
1. Introduction ....................................................................................................................... 7
2. Background to interoperability and other relevant concepts ............................................ 14
2.1 Key concepts .......................................................................................................... 14
2.1.1 Interoperability ............................................................................................ 14
2.1.2 Standards ................................................................................................... 17
2.1.3 Interface and API ........................................................................................ 19
2.1.4 Interoperability certification ......................................................................... 20
2.2 Interoperability in practice ....................................................................................... 24
2.2.1 Health care systems ................................................................................... 24
2.2.2 Internet ....................................................................................................... 31
2.2.3 Mobile networks .......................................................................................... 36
3. Smart city background .................................................................................................... 39
4. Overall view of smart city sectors in Finland.................................................................... 46
4.1 Mobility ................................................................................................................... 47
4.2 Built environment .................................................................................................... 49
4.3 Energy and cleantech ............................................................................................. 51
4.4 Safety and security ................................................................................................. 54
4.5 Education ............................................................................................................... 54
4.6 Health care ............................................................................................................. 54
4.7 Municipal ICT .......................................................................................................... 56
5. Perspectives on interoperability - three horizontal theme areas ...................................... 56
5.1 Cities and the public sector ..................................................................................... 56
5 (127)
5.1.1 The current state ......................................................................................... 58
5.1.2 Means to promote interoperability ............................................................... 59
5.1.3 Conclusions ................................................................................................ 62
5.2 Business environment ............................................................................................ 63
5.2.1 Generic description of the current state....................................................... 63
5.2.2 Key actors ................................................................................................... 67
5.3 ICT systems............................................................................................................ 71
5.3.1 ICT interoperability ...................................................................................... 73
5.3.2 Generic description of the current state....................................................... 77
6. Example cases of existing and possible national activities evolving towards a multi-actor
environment .................................................................................................................... 88
6.1 Mobility ................................................................................................................... 89
6.1.1 Real-time traffic information ........................................................................ 89
6.1.2 Mobility-as-a-Service (MaaS) ...................................................................... 91
6.2 Built environment .................................................................................................... 92
6.2.1 Digital urban environment ........................................................................... 92
6.2.2 Building automation .................................................................................... 94
6.3 Energy and cleantech ............................................................................................. 97
6.3.1 Energy case: Datahub ................................................................................ 97
6.3.2 Water management .................................................................................... 98
6.3.3 Waste management .................................................................................... 99
6.3.4 Air quality monitoring ................................................................................ 100
6.4 Horizontal ............................................................................................................. 101
6 (127)
6.4.1 MyData ..................................................................................................... 101
6.4.2 X-Road ..................................................................................................... 104
7. Overview of international smart city interoperability activities ........................................ 106
7.1 International collaboration activities ...................................................................... 106
7.1.1 City Protocol Society ................................................................................. 106
7.1.2 FIWARE .................................................................................................... 107
7.1.3 EIP SCC ................................................................................................... 109
7.1.4 Open and Agile Smart Cities ..................................................................... 109
7.1.5 Alliance for Internet of Things Innovation .................................................. 110
7.1.6 Smart City council ..................................................................................... 110
7.1.7 Japan Smart Community Alliance ............................................................. 111
7.2 Activities by cities and countries ........................................................................... 112
7.2.1 Barcelona ................................................................................................. 112
7.2.2 Estonia...................................................................................................... 113
7.2.3 Stockholm and Sweden ............................................................................ 116
8. Conclusions .................................................................................................................. 118
References ......................................................................................................................... 120
7 (127)
1. Introduction
Cities are increasingly being empowered with information and communications technologies
(ICT). The application of ICT in a city environment has the potential to significantly reduce
costs, to increase productivity, sustainability, and wellbeing, and to have a fundamental
impact throughout society and business. As city core infrastructure and systems become
instrumented with sensors and as these systems are interconnected to other systems, new
levels of intelligence and services can be reached (Dirks & Keeling, 2009).
Recently, the term smart city has become an established way to depict the evolution towards
these kinds of more real-time and intelligent ways of providing public services and operating
critical infrastructures. The European parliament (2014), for example, defines a smart city as
follows:
A smart city is a city seeking to address public issues via ICT-based solutions on the
basis of a multi-stakeholder, municipally based partnership.
The smart city theme involves a wide range of sectors such as mobility, built environment,
energy, and waste and water management. While ICT is a core enabler, a smart city is not
just a technological issue. It also requires new and innovative business and operating models
(Webb et al., 2011) by different actors, ranging from cities and other public actors to large
corporations, small and medium enterprises, individual software developers, and citizens.
By taking a multi-stakeholder approach, new kinds of interdisciplinary services can be
created. For example, recently in Finland in the field of mobility, Helsinki Region Transport
has been piloting a service called kutsuplus1, a form of demand-responsive public
transportation, in which mobile and positioning technologies and intelligent routing algorithms
are used to provide a flexible transportation service according to passengers’ needs.
Another notable example is smart waste management, for which a company called Enevo2
has developed a solution in which garbage bins are instrumented with sensors that measure
how full the garbage bins are, based on which the routes of garbage trucks can be optimised,
1
th
https://kutsuplus.fi/tour (All web links in the footnotes have been accessed on 15 of October 2015) (The
pilot has now ended.)
2
http://www.enevo.com/
8 (127)
leading to reduced costs and environmental impact. Furthermore, in the field of built
environment, for example, a company called Solita has created a common platform for
Finnish cities and municipalities that provides a more flexible way to apply for building
permits3.
Smart city market
Overall, the smart city has become a major global development trend. Many cities and
technology vendors are currently taking notable steps and investing heavily in smart city
solutions. The smart city market is expected to grow considerably in the next few years. Pike
Research forecasts that investment in smart city technology infrastructure will total $108
billion during the decade from 2010 to 2020. Frost and Sullivan (2013) estimate that the
smart city market will be worth a cumulative $1.565 trillion by 2020.
Although estimates vary depending on which technologies are included under the smart city
"umbrella," they all agree that it is a significant and rapidly growing market4. This also makes
it a lucrative export possibility for Finnish companies.
Fragmentation and vendor lock-in a key problem
Although the smart city theme has received much positive attention, roughly put, it can be
stated that the current smart city solutions are heavily fragmented. Artificial silos exist
between sectors, and there is very limited co-operation across cities (Anon, 2013).
Furthermore, cities and other important stakeholders often outsource ICT. Smart city projects
are often developed in a manner by which a city partners with a company that then operates
and manages the smart city services on the city’s behalf (Frost & Sullivan, 2013). This
vertical and closed model (Figure 1), in turn, leads to the city becoming a rather passive
entity, which in turn often leads to a vendor lock-in situation.
3
https://www.lupapiste.fi/
4
http://smartcitiescouncil.com/article/our-sector
9 (127)
Figure 1. Current closed and vertical model leading to vendor lock-in.
When the actors running the physical services (e.g. operating public transportation or an
energy network) are locked into a vendor, the cost of switching becomes high, systems
cannot be easily interconnected to other systems, such as those in other cities or sectors,
extensive integration is needed, and new innovations are not created or they remain local.
Furthermore, economies of scale are not attained and thus a multi-buyer, multi-vendor
market does not emerge in a similar way as, for example, in the evolution of the Internet or
mobile networks.
Overall, smart city solutions seem to be currently fragmented across cities and sectors (e.g.
mobility, built environment, energy), leading to a situation where innovations do not diffuse
widely and reach their full potential.
Towards an open and modular multi-stakeholder smart city approach
Thus, all in all, there seems to be a clear need for an open and modular interoperability
environment for smart city solutions that spans across cities and sectors. To address the
problem of smart city fragmentation and vendor lock-in,
10 (127)
the goal of the smart city Interoperability Environment (InterCity) project is to examine
how the market structure could shift from a closed and vertical model (Figure 1),
where dedicated solutions are implemented for each city and sector, to an open and
horizontal interoperability environment across cities and smart city sectors (Figure 2),
where cities and other actors can build multi-vendor solutions, interconnect their
systems, and develop them in a modular and flexible way.
Figure 2. Open and horizontal model enabling modular multi-vendor solutions.
In order to move from the vertical model to a horizontal model, actors operating and
supplying smart city systems need to change their operating and business models
accordingly. Common ways to conduct public procurement, new more modular business
architectures, and new horizontal actors (e.g. ensuring the interoperability of the different
smart city solutions through joint testing and certifications) are needed.
An overall vision of the interoperability environment is depicted in Figure 3. It consists of
demand side and supply side actors that are all part of a smart city interoperability
environment where horizontal intermediary actors facilitate, for example, common
procurement practices and interoperability testing and certification.
11 (127)
The demand side consists of the actors running the physical services in the city environment,
such as cities and other public actors5 responsible for public services and infrastructure in the
city area. Demand-side actors also include private enterprises operating public services
contracted out by the public sector6. Furthermore, the demand side includes private
enterprises operating their business in the city area (e.g. taxi companies and construction
and maintenance companies for buildings), especially as it relates to activities where the city
or some other public authority plays a key role, for example, through regulation (e.g. taxi or
building permits) or by providing key resources for value creation (e.g. open data). The
demand side also includes individual households and end-users, especially as it relates to
activities in which the city or some other public authority is in an important role (e.g. endusers using a journey planner for public transportation).
Figure 3. Vision of a smart city interoperability environment.
5
In addition to cities, other important public actors procuring and operating smart city systems include, for
example, joint municipal organisations (kuntayhtymät) (e.g. in the field of Mobility Helsinki Region Transport
(HRT)), and government-level actors (e.g. Finnish Transport Agency)).
6
For example, bus operators like Helsingin Bussiliikenne Oy, operating buses on behalf of Helsinki Region
Transport.
12 (127)
The supply side consists of actors supplying and operating ICT-based smart city solutions
and services. Overall, it can be grouped into, for example, smart city technology vendors
providing sensors and controllers related to infrastructure, communications equipment
vendors and operators, back-end IT-system vendors and integrators, service providers
managing the smart city services, and application developers (Frost & Sullivan, 2013).
Scope and structure of the project and this report
Due to the large scope of the smart city topic area, the Smart City Interoperability
Environment project focuses especially on the operation and business models of the smart
city actors and will try to find new ways of working that enable a horizontal market structure.
Therefore, the goal of the project is not to define a new technical-level architecture but to
conceptualise a business and operational-level architecture and focus especially on what
kind of new horizontal process and corresponding actors are needed that could give rise to a
common technical-level architecture.
Furthermore, the focus of the project is primarily on the domestic smart city market in
Finland, namely how to establish an advanced home market as a testbed for international
business, but some international aspects are also considered.
The project is divided into three phases

Phase 1: An overview of the state of smart city interoperability (which is
the focus of this report),

Phase 2: Creation of the smart city interoperability concept (e.g. in terms
of horizontal processes, procurement practices, business architecture, testing
and certification mechanisms), and

Phase 3: Marketing and dissemination of the concept to ongoing and new
smart city pilots and projects.
13 (127)
The project is structured around three horizontal theme areas where modular and open
processes need to be created:

Theme 1 focuses on common practices for cities and other public actors as it
relates, for example, to procurement, regulation, and the opening of common
resources (e.g. data) for citizens’ use.

Theme 2 focuses on the creation of a multi-actor business ecosystem with multiple
buyers, and multiple vendors and service providers all delivering their solutions over a
modular ICT architecture.

Theme 3 focuses on the technical processes (requirement specification, testing and
certification) that enable a functional modular ICT architecture with commonly
agreed open interfaces.
In order to narrow the scope of the work, the project focuses on the following three key smart
city sectors: mobility, built environment, and energy (including cleantech). However, the goal
is to create the smart city interoperability concept in a way that it can be further developed
and deployed to other smart city sectors.
The purpose of this report is to act as a deliverable for phase 1 of the project. The goal is to
examine how the different smart city sectors are structured in Finland and what their current
state is in terms of application of ICT and interoperability7. Furthermore, the aim is to study
what kinds of actors exist on both the demand and supply sides, and also to take a closer
look at a few case examples of existing and possible national activities that are evolving
towards a multi-actor environment.
The method used to conduct the research is a combination of desktop research (i.e. using
public sources such as reports, web sites, and other sources) and semi-constructed expert
interviews of key stakeholders, for both the demand and supply sides (i.e. city
representatives, other public organisations, large companies, SMEs, developers, etc.).
The overall goal of phase 1 and this report is also to gain an understanding of what kinds of
interoperability elements are needed in the different smart city sectors, and what would
7
It should also be noted that since the Smart City is such a broad theme, some relevant issues that the authors
are not aware of are possibly left out of this study. Additionally, the statements made do not represent the
official views of VTT or the related cities, companies, or other stakeholders, but are the interpretations of the
researchers.
14 (127)
qualify as good use cases and pilots for which the first horizontal processes could be created
and deployed in phases 2 and 3.
The report is structured as follows. Section 2 presents an overall review of key concepts
related to interoperability and also how it has been implemented in practice in other
industries. In section 3, we give an introduction to the smart city theme, review some
definitions, and introduce a framework used to structure the work. In section 4, we briefly
present the smart city sectors in Finland on a general level. Section 5 then goes on to
examine more closely the current state of smart city solutions from the view point of the three
horizontal theme areas, namely cities and the public sector, the business environment, and
ICT systems. In section 6, we present case examples of existing and possible national
activities that have the potential to evolve towards a multi-actor environment. In section 7, we
present an overview of international smart city activities, focusing especially on
interoperability. Finally, in section 8, we draw conclusions.
2. Background to interoperability and other relevant concepts
To gain a better understanding of interoperability, in the following we present an overall
review of key concepts such as standards, interfaces, APIs, and interoperability certification,
and we also discuss how interoperability has been implemented in practice, for example, in
healthcare systems, mobile networks, and the Internet.
2.1
Key concepts
2.1.1
Interoperability
The term Interoperability does not have an established definition and there are several
different views of what this concept should cover. Before a more analytical study of
interoperability is introduced, some definition examples could be given:

According to ISO/IEC 2382-01, Information Technology Vocabulary, Fundamental
Terms, (ISO 2015) interoperability is defined as follows: "The capability to
communicate, execute programs, or transfer data among various functional units in a
manner that requires the user to have little or no knowledge of the unique
characteristics of those units".

The EU Commission has defined interoperability as: "Interoperability means the
capacity with which two programmes (a client and a server, for example) are able to
exchange and interpret their data properly."
15 (127)

The UK Government’s Interoperability Glossary (UKGIG 2013) defines it as: “At its
most basic level, interoperability is the ability of a system or a product to work with
other systems or products without special effort on the part of the customer.
Interoperability is made possible by the implementation of standards.”

Jeff Rotenberg from RAND Europe (whose team has defined recommendations for
the Dutch Interoperability Framework) defines it as (Rotenberg 2008): “Interoperability
is the ability to distinct systems to share semantically compatible information and to
process and manage that information in semantically compatible ways, to enable their
users to perform desired tasks”. The system referred in the definition can be either a
computer system or an institution or organization, or a combination of all.
Clearly the first two definitions are technically oriented, whereas the latter two have much
broader coverage. In the InterCity project, the latter (broader) interpretation of interoperability
is adopted and the problem is studied from an “enterprise interoperability” viewpoint.
Although the public sector (including communities) cannot be counted as enterprises, the
future operational challenges for those are equal to those of commercial companies. These
challenges, like increasing cost structure due to an aging population and decreasing incomes
via collected taxes due to economic recession, shape/force governance processes to be
more efficient, and thus the same enterprise-oriented principles of operation management
should be applied to the public sector. The European Commission’s Informatics DirectorateGeneral director has put it as (EIF 2011):
“Public administrations are obligated to do more with less. Interoperability, reuse and sharing
are beneficial, they will produce savings, but at the same time they require initial investment.”
The term enterprise interoperability (EI) is defined both by the IEEE and the EU commission
in a similar fashion:

The IEEE definition for EI is (IEEE 2010): the ability of an enterprise to interact with
other organisations, to exchange information and to use the information that has been
exchanged. It should be noted that interoperability is not only a property of ICT
systems, but also concerns the business processes and the business context of an
enterprise.

Enterprise interoperability is defined in the EU Interoperability roadmap (Li 2006) as a
field of activity with the aim to improve the manner in which enterprises, by means of
Information and Communications Technologies (ICT), interoperate with other
enterprises, organisations, or business units of the same enterprise, in order to
16 (127)
conduct their business. This enables enterprises to, for instance, build partnerships,
deliver new products and services, and/or become more cost-efficient.
According to the United Nations Development Programme’s guide and European
Interoperability Frameworks (EIF) representations, multiple levels of interoperability can be
distinguished: legal, organisational, semantic, and technical interoperability (Figure 4).
Figure 4. European Interoperability framework (Gotze 2010, EIF 2010).
Legal interoperability covers the broader environment of laws, policies, procedures, and cooperation agreements needed to enable the seamless exchange of information between
different organisations, regions, and countries. This ensures that “exchanged data is
according to legal weight”.
Organisational interoperability refers to organisational co-operation, such as effective cooperative task performance, and exchange of information and services. The EIF defines this
as “the ability of disparate and diverse organizations to interact towards mutually beneficial
and agreed common goals”.
17 (127)
Semantic interoperability refers to the ability to ensure that the precise meaning of
exchanged information is unambiguously interpretable by any other system, service or user,
so that, for example, the meaning of information is correctly communicated, received, and
understood, and expected actions are performed. If algorithms and information processing
are not semantically compatible, results may be meaningless or even misleading, which
might have catastrophic consequences in mission-critical applications (for example
healthcare, transportation). Semantic interoperability means that information senders and
receivers can exchange information in a meaningful and comprehensive manner.
Technical interoperability means the ability of two or more information and communication
technology applications to reliably exchange data with each other, and to perform a given
task in an appropriate and satisfactory manner without the need for extra operator
intervention. In practice, this means standardisation by using well-defined interfaces, a
common syntax of data, and standardised protocols.
2.1.2
Standards
Standards are documents that provide rules or guidelines to achieve order in a given context.
The basic idea of standardisation is to decrease coordination costs; for example, the aim is
to reach a situation where all stakeholders mutually benefit from acting according to a joint
agreement. Thus, standards are created according to common consensus and do not always
represent the functionally or technically best possible solutions. Despite these shortcomings,
standards offers several benefits:

Safety and reliability – Adherence to standards helps ensure safety, reliability, and
environmental care. Users perceive standardised products and services as more
trustworthy, raising user confidence, speeding up the adoption of new
technologies, and increasing sales. Mass production based on standards provides
a greater variety of accessible products and services to consumers. Standards
enable competition and delivery reliability, customers are not dependent on a
single provider, and they can also estimate the quality of products and services
beforehand.

Interoperability – the ability of things to work together relies on products and
services complying with standards. Standards address especially the needs for
interconnection and interoperability. In open markets based on standards, users
can ‘mix and match’ equipment and services, and suppliers can benefit from
economies of scale. Standards play a central role in the European Union's policy
for a Single Market.
18 (127)

Business benefits – for companies, standardisation provides a solid foundation
upon which to develop new offerings. Standards open up markets, give scale
benefits, and sometimes increase innovation (but also sometimes hinder those).

They are also frequently referenced by regulators and legislators for protecting
user and business interests, and in support of government policies.
Two types of standards can be distinguished:

De jure (”concerning law”) standards are legally binding contracts, laws, and acts that
are endorsed by formal organisations like governments or official standardisation
organisations. The organisation ratifies each standard through its official procedures
and gives the standard its stamp of approval.

De facto standards, or standards in actuality, are contracts, policies, products, or
systems that have achieved a dominant position without a formal standardisation
procedure. Solutions used are based on developers’ best choices and are adopted
widely by industry and its customers. These market-driven standards arise when a
critical mass simply likes them well enough to collectively use them. Market-driven
standards can become de jure standards if they are approved through a formal
standards organisation. De facto standards can be open or closed.
Technical standards define norms (standards) for technical systems as documents that
describe technical requirements, methods, processes, and practices for the object to be
standardised.
Standards are issued by official standardisation organizations like ISO and IEC (in Finland
SFS), professional organisations like IEEE, and less officially organised consortiums and
forums like W3C (especially web technology-related standards) and IETF (Internet
standards). There are also associations, like ETSI related to telecommunications and SAE
related to automotive industries, that are important standardisation organisations. Due to this
variety of organisations, the naming of standards issued might also vary accordingly: ISO
standards, DIN norms, IEEE recommendations, or IEFT requests for comments.
An open standard is a standard that is publicly available. There is no single universal
definition of an open standard and the definition may vary according to the usage context.
Different organisations emphasise different properties when trying to describe the essence of
an open standard.
19 (127)
The most common requirement is public availability; for example, the standard must be
subject to full public assessment (be freely and publicly available from, for example, a web
site) under royalty-free terms at reasonable and non-discriminatory cost for use without
constraints in a manner equally available to all parties. Another common requirement is
related to IPRs (Intellectual Property Rights), such as all patents or like NDAs, grants, and so
on, which are essential to implementation if the standard must be licensed under royalty-free
terms for unrestricted use. On the other hand, certification of compliance from the standards
organisation may involve a fee.
The ITU-T also describes properties for the open standardisation process. According to the
ITU, the process is collaborative and voluntary. Approval is a transparent consensus-driven
process that is open to all interested parties and that should be reasonably balanced in such
a way that it is not dominated by a single interest group.
2.1.3
Interface and API
Interface is an overloaded term that is used in various contexts. The Business Dictionary (BD
2015) defines it as: “Common boundary where direct contact between two different cultures,
devices, entities, environments, systems, etc., occurs, and where energy, information, and/or
material is exchanged”. Another attempt to specify it is with a citation from the Free
Dictionary (FD 2015): “A surface forming a common boundary between adjacent regions,
bodies, substances, or phases”. In summary, an interface seems to refer to a boundary
between two independent systems.
In computing especially, an interface is a boundary across which two separate components
communicate. This information exchange across a boundary can be between software,
computer hardware, peripheral devices, humans, and combinations of these (IEEE 2010):

A hardware interface is described by the mechanical, electrical, and logical signals at
the interface and the protocol for sequencing them. Hardware interfaces can be
parallel with several electrical connections carrying data simultaneously, or serially
where data is sent sequentially.

A software interface enables access only through well-defined entry points to
computer resources of the underlying hardware system via operating systems or to
applications.

A user interface enables a user to communicate with an operating system and related
applications.
20 (127)
An application programming interface (API) enables a programmer to interact with an
application using a set of callable functions (inputs) and returning certain results (outputs).
APIs enables the principle of information hiding, meaning that interfaces hide the
implementation details of the software components so that users of these building blocks
need not understand the complexities inside these modules.
An API abstracts the implementation of the functions of a software component in such a way
that the interface remains the same if the underlying software is upgraded. An API should be
consistent with other APIs already in use in the system, so the details of API design are
somewhat language- and system-dependent. Open or public API is a term referring to
application programming interfaces that are published on the Internet and shared freely
(freely available for anyone to use).
2.1.4
Interoperability certification
Certification refers to an activity that ensures that certain characteristics of an object, person,
or organization are according to some predefined properties. Certification programmes are
often supervised by some certifying agencies, such as professional associations. For
example, American National Standards Institute ANSI Standard 1100 defines two basic
requirements for certifying organisations:

Delivers an assessment based on industry knowledge, independent from training
courses or course providers.

Grants a time-limited credential to anyone who meet the assessment standards.
In a formal certification procedure, an accredited or authorised agency or person assesses
and verifies that characteristics of the certified target conform to established requirements or
standards. These third-party conformity assessment activities can be regulatory or voluntary.
Some certifications must be renewed periodically, or may be valid for a specific period of
time; some are long lasting like life-time certifications.
The most common type of certification is a professional certification indicating that a person
is qualified to perform a job or a task. Such personal certifications are usually given by
educational institutes or professional societies, and can be required by law for a person to be
allowed to perform professional jobs (e.g. doctor of medicine). There are also several levels
of
professional
certifications,
like
corporate
internal
certifications, and industry/profession-wide certifications.
certifications,
product-specific
21 (127)
Product certification (or product qualification) is the process of certifying that a certain
product has passed performance tests and quality assurance tests, and meets qualification
criteria stipulated in contracts, regulations, or specifications. Regulatory assessment is
typically performed to prove adherence to safety codes.
In passing the certification process, written assurance could be given in the form of a
certification mark or labelling applied to a product, or to its documentation, and/or a listing in
a publicly accessible registry. In a formal certification, the brand and associated trademarks
are of extreme importance. For example, safety code certification marks provide the basis for
legal enforcement of requirements and sanctions against participants.
Interoperability certification is a specific form of certification that is of particular interest here.
The US Department of Defence (DoD) defines interoperability certification as a process “of
ensuring that a system meets the joint interoperability requirements of its users. It includes
the collection of the data (test) necessary to determine (evaluation) whether or not the
system conforms to applicable interoperability standards and can effectively exchange all
required information with all pertinent systems” (Tran 2005).
A certification testing process ensures that the entity (a person or a product) to be certified
adheres to the predefined rules and properties defined by the specification. Generally, two
testing activities are common (NIST 1999):

Conformance testing, where a single object (typically a device or an interface) is
tested with respect to the relevant specifications. Conformance testing increases the
likelihood that systems are interoperable.

Interoperability testing, where two or more implementations of entities (usually
interfaces) are tested together against each other to check whether they
interoperate, meaning that they are able to exchange information or work together as
intended.
These activities are not substitutive – passing a conformance test does not necessarily mean
that systems interoperate, nor do interoperable systems necessarily imply that entities
conform to given specifications. These inconsistent results could be due to specifications that
might not be strict enough, containing plenty of optional or recommended features, or some
interfaces could be “underspecified”, leaving room for various implementation interpretations
(Rings 2014). Generating exhaustive tests, as in going through all possible use-cases in
tests, might also be impossible. The ITU emphases that conformance with a specification (or
22 (127)
a standard) should be achieved first and should not be compromised during interoperability
testing (Monkewitch 2006).
ISO/IEC has defined terms related to conformance and conformity testing:

"conformity - fulfilment of a product, process or service of specified requirements."

"conformity assessment - any activity concerned with determining directly or
indirectly that relevant requirements are fulfilled." Conformity assessment is a
neutral mechanism to judge a product against the criteria and does not give any
preferences as to whether a product is better than another if both meet same
requirements.

"conformity testing - conformity evaluation by means of testing." A way to
determine directly or indirectly that relevant requirements are fulfilled.
According to NIST (US National Institute of Standards and Technology), if there are no
conformation clauses or commonly agreed testing methods for conformity assessment, these
is no definition of conformance for a specification. Developing a test suite and procedures on
how to perform repeatable tests and testing tools is also an essential part of the conformity
assessment process. Repeatable refers to the fact that same results should be obtainable
with different testers following the same testing procedures. A common and repeatable
testing methodology enables the entity to be tested only once without the need for retesting
for different markets.
Testing has a cost–benefit ratio, and several types of testing procedures could be identified
(NIST 1999):

Exhaustive testing, which attempts to verify every aspects of an entity, is seldom
possible, since the possible test cases and combinations of those could expand
exponentially.

Thorough testing attempts to verify the behaviour of every aspect of an entity, but
does not include all possible permutations.

Identification testing consists of a cursory examination of the entity, verifying its
minimal function.
In addition to a testing procedure, there should be some criteria on how to measure the
factors for the success of testing.
23 (127)
In the telecommunication sector, where interoperability is a key issue for reaching end-to-end
connectivity, well-defined procedures have been established to achieve that goal. According
to ETSI definitions, interoperability testing is the activity of proving that end-to-end
functioning between (at least) two communicating systems is as required by those systems'
base standards. ETSI’s interoperability framework includes:

An abstract testing architecture that provides a framework for test arrangements.

An Interoperable Functions Statement (IFS) that identifies those functions that
equipment to be tested must support, those that are optional, and those that are
conditional.

The Test Suite Structure is a logical division of the test suite into test groups. The
Test Suite Structure provides the categories into which both test purposes and test
cases are placed. The test purpose is a full description of the objective of each test
case, and the test case is the detailed set of instructions (or steps) on how to perform
the test. In turn, an interoperability test suite is a collection of test cases designed to
prove the ability of two (or more) systems to interoperate.
To be practical and efficient, conformance and interoperability testing should be automated
as much as possible. In the software industry, automated conformance test sets have been
used for a long time as a standard practice. Special types of software (separate from the
software being tested) are used to control the execution of repetitive tests cases and perform
comparisons of actual outcomes with predicted results. Test cases could be targeted to API
level or software component level. For example, there are several testing tools like vREST
and JetPack for Postman to automate REST-based API testing. Software component testing
frameworks like jUnit for Java language are used to verify that the program runs as expected.
Test-driven development is one of the key features of agile software development.
Automated interoperability testing is more time-consuming and resource-intensive than
simple automated conformance testing (Bergengruen 2008). The need for interoperability
testing has significantly increased, because the end-user services are provided by distributed
systems based on products from various origins. The problem of interoperability testing is
that it is not transitive, so that if product A works with B and C, there is no guarantee of
interoperability between B and C (Rings 2014). To alleviate problems with automated
interoperability testing, ETSI has developed a generic methodology of how to perform these
activities (ETSI Guide 202 810). ETSI has also announced an interoperability testing
framework to guide successful automated interoperability tests (Bergengruen 2008, Rings
2014).
24 (127)
Sometimes automated testing is not enough. A PlugFest (or PlugTest or Connectathon) is an
event where the designers and manufacturers of electronic equipment or software
components gather physically to test the interoperability of their products related to certain
standards or specifications. These sessions have two aims: to check compliance with the
standard, and to test the effectiveness of the standard when the standard definition might be
ambiguous. PlugFests are common in the ICT hardware industry, as with USB device
manufacturing, hard disk drive (SCSI interface) manufacturing, and so on. For example,
ETSI alone hosts 15 PlugFests a year.
2.2
Interoperability in practice
Next, we give some examples from other industries in terms of enabling interoperable
solutions and evolution towards a multi-actor market. The following three theme areas are
covered: healthcare, mobile networks, and the Internet.
2.2.1
Health care systems
One of the key expenses of the public sector is arranging health care. The aging of people,
bringing a decrease in mortality rate, lower fertility, and a higher life expectancy among
citizens, is a problem not only peculiar to the western world. For example, the Chinese
population is rapidly aging, due to a lower mortality rate and the one child policy. This
tendency is global - according to a UN report in 2013, the number of older persons (aged 60
years or over) is expected to more than double, from 841 million people in 2013 to more than
2 billion in 2050. This trend sets new challenges for health care services, since the oldest
age groups will have a major impact on future health care costs (Schneider 1990).
Forbes’s article (Conover 2012) gives an example of how the cost of health care has
quadrupled in about 50 years (1958 vs. 2012) in the US, considering the hours of work
required to cover expenses. Naturally, the current health care is vastly improved compared to
what was available 50 years ago. The trends are the same in Europe - during the last few
decades, health expenditure has been growing faster than national income (Medeiros 2015).
The increase in costs is not sustainable, and more efficient procedures for arranging health
care should be found. The main problems, according to the US Institute of Medicine (IOM), of
inefficiencies in the US health care system (the country loses some $750 billion annually) are
unnecessary services ($210 billion annually), inefficient delivery of care ($130 billion), and
excess administrative costs ($190 billion) (Fung 2012). Most likely, the situation is similar in
European countries, including in Finland.
25 (127)
A solution for inefficient delivery of services and excess administrative costs in other sectors
is usually to apply information technology. An EU report (OECD 2012) states that health care
is one of the most information-intensive sectors of European economies and can greatly
profit from recent advances in ICT. The so-called eHealth market (e.g. applying ICT in health
care) is currently only some 2% of total health care expenditure in Europe, but demand is
increasing rapidly and, for example, in the US alone the health care ICT market is estimated
to be about $80 billion currently (Laflamme et al. 2010).
To keep the public health care ICT expenses reasonable and to create efficient health care
ICT markets (e.g. preventing health care system vendor lock-ins, which increase public
expenditure in the long term), some clever strategies are need. One of the best examples of
a successful approach is Danish MedCom, Denmark’s coordinating organisation for
healthcare IT. Other organisations for promoting health care system interoperability and
advancing open markets are IHE and Continua.
MedCom
The problem with Danish health care in the 1990s was that 20 - 30% of administrative
expenditure in the Danish health care system was estimated to be spent on handling paper,
causing errors, wasted time, and poor service. The MedCom initiative was established in
1994 as a publicly funded, non-profit co-operation among the Danish Ministry of Health (50%
of funding), Danish regions, and local government in Denmark, with the objective to
“contribute to the development, testing, dissemination and quality assurance of electronic
communication and information in the healthcare sector with a view to supporting good
patient progression, with a focus to support efficient performance and a gradual expansion of
the national eHealth infrastructure, which is necessary for a safe and coherent access to
relevant data and communication across regions, municipalities, and general practitioners"
(MedCom 2014).
Since its establishment, MedCom has worked in time-constricted project periods of 2 – 4
years. In the first years, MedCom worked as projects (MedCom 2001):

MedCom 1 (1994 to 1996) concentrated on the development of communication
standards for the communication flows between medical practices, hospitals, and
pharmacies.

MedCom 2 (1997 to 1999) continued the work of MedCom 1 on communication
standards and carried out pilot projects in the areas of the Internet, telemedicine, and
dentistry.
26 (127)
Since the results of these projects were encouraging, in 1999 it was decided that MedCom
should be continued as a permanent organisation, performing its work in the form of projects
over limited periods. MedCom has, since 2002 (Gartner 2006, MedCom 2014):

Developed standards for hospital-to-hospital discharge letters, patient referrals,
correspondence messages, and clinical biochemistry laboratory results. MedCom
paid vendors to modify their applications to incorporate these standards.

Established a health data network by linking health care-related organisations to a
central hub via a virtual private network (VPN). The VPN is used for transferring
messages, as well as for videoconferencing, conducting tele-dermatology, accessing
digital images, and accessing the Standardised Extracts of Patient Data (SUP)
system and the national portal.

Developed messages for GPs (General Practitioners) and hospitals to communicate
with local authorities and home care providers.
As an organisation, MedCom is responsible for:

Cross-sectoral dissemination and expertise

Standards, testing, and certification

Operation and further development of the Danish Healthcare Data Network and
national data sources

International activities
The MedCom technical approach was to support interoperability by defining standardised
messages and adopting open technical standards like EDIFAC (currently, 90 per cent of
communications use the EDIFACT standard), HL7 (Health Level-7, or HL7, refers to a set of
international standards for transfer of clinical and administrative data between software
applications used by various health care providers), and XML for the medical content of data
exchange, enabling integration over 50 different IT systems used in Danish health care.
MedCom created standard EDI forms for the six principal information flows in primary care
for lab orders and results; prescriptions ordered by GPs; referrals from GPs to specialists;
radiology orders and results; community (home care) messages; and insurance claims
submissions and reimbursements. To encourage standards adoption, MedCom published on
its website the progress of vendors in modifying their applications to become compliant with
the standards.
27 (127)
Since 2000, MedCom has tested and certified all supplied health care ICT systems in
Denmark. MedCom tests and approves computer systems in the healthcare sector for the
reception and dispatch of EDIFACT and XML documents, as well as XML WebService
solutions. To become certified, suppliers must meet all messaging standards, presentation
formats, and functions. Testing was done previously by the individual supplier sending in files
to MedCom, which tested them using an internal test tool. Certification completion took about
a week and included a visit to supplier offices to run test protocols This process was timeconsuming and demanding, and nowadays a test tool is offered for suppliers free of charge,
directly on the Internet. Suppliers themselves can perform tests continuously in the
development process. Currently, suppliers do not have to pay to have their systems certified
(Protti 2010).
The results of the MedCom approach are convincing (Edwards 2006). Though there is little
hard data available, some Danish physicians have noted that the MedCom-based
infrastructure saves one hour per day of staff time. A Danish study found that 50 minutes is
saved per day in each primary care physician practice, telephone calls to hospitals are
reduced by 66 per cent, and US$3.30 is saved per message, of which there are 60 million
per year (e.g. cost savings are nearly US $200 million annually). From a customer
perspective, among all the countries in the EU, Denmark has the highest public satisfaction
with its health care system.
IHE
Another example of improving interoperability in the health care sector is Integrating the
Healthcare Enterprise (IHE). IHE is a non-profit organisation based in the US, established in
1998 by a consortium of radiologists and information technology experts. IHE’s mission is to
improve health care by providing specifications, tools, and services for interoperability, by
sponsoring initiatives to improve the way computer systems share information. IHE is
sponsored by associations of health care professionals around the world and has welcomed
the participation of many of the leading manufacturers of health care imaging and information
systems.
IHE emphasises that it does not develop its own standards, but instead uses standards like
HL7, DICOM, and so on, defined elsewhere for clinical and administrative needs. It aims to
complement the standardisation organisations and has established formal relationships with
organisations like HL7, ISO, DICOM, and NCCLS (National Committee for Clinical
Laboratory Standards). DICOM is a global standard used in virtually all hospitals worldwide
for interoperability of systems used to process medical images and derived structured
documents. In addition, the health care sector is informed of the IHE implementation of
28 (127)
solutions, and IHE encourages the health care sector to support IHE profiles for invitations to
tender.
IHE also tries to fill the gap between standards and systems integration by providing a
process and a framework for supporting the implementation of standards. The process is
divided into four phases (IHE 2015):

Problem identification: Clinicians and IT experts identify common integration
problems.

Integration profile specification: Stakeholders select standards that address each
identified integration need.

Implementation and testing: Vendors implement profiles and test their systems using
software tools and at a face-to-face Connectathon, where they test interoperability
with other vendors' systems.

Integration statements and RFPs (requests for proposals): Vendors publish IHE
integration statements to document the integration profiles supported by their
products. Customers can reference integration profiles in requests for proposals,
simplifying the systems acquisition process.
IHE USA and ICSA Labs have created a certification programme and framework for IHE
profiles. Certification of selected IHE profiles gives purchasers of health IT products
independent, third-party assurance that certified products exhibit the robust capabilities for
optimal data exchange. Certification also includes industry-standard system surveillance
activities that ensure that certified products continue to perform as tested, over time. In
addition, ICSA Labs maintains a directory of certified products.
IHE also arranges a yearly week-long interoperability event on-site in Cleveland, USA, for
vendors to test their HL7 (ANSI-accredited standards for the exchange, integration, sharing,
and retrieval of electronic clinical practice health information) specification-conforming
products (Bergengruen 2008). The IHE Connectathon is a cross-vendor, live, supervised,
and structured testing event with more than 100 participating vendors and 550+ engineers
and IT architects. Participants test their products against multiple vendors using real-world
clinical scenarios contained in IHE's integration profiles.
IHE HL7-related conformance and interoperability testing activities are also supported in
Finland as a part of the national electronic health care services architecture Kanta. The
29 (127)
certification process concerns any system that connects to Kanta services, and includes
three parts:

Operational requirements verified by the supplier before common testing

Interoperability, which is verified through Kela's (the Social Insurance Institution of
Finland) common testing

Data security, which is verified by an assessment body approved by the Finnish
Communications Regulatory Authority FICORA
As a part of the certification testing, Kela has arranged testing opportunities for system
suppliers to test the implementation of the electronic prescription and Patient Records
Repository in their systems against the Prescription Centre and Patient Records Repository.
Kela is also offering a simple-to-use browser-based validation service for HL7 CDA R2
documents.
Continua
Continua is an international not-for-profit industry group convening global technology industry
standards to develop end-to-end, plug-and-play connectivity for personal connected health,
including smartphones, sensors, remote monitoring devices, tablets, and gateways, as well
as networked and cloud solutions. Continua's board of directors features several technology,
medical device, and health care industry and service providers like GE Healthcare, Partners
HealthCare Center for Connected Health, Fujitsu, Intel, Oracle, Philips, Roche Diagnostics,
Samsung Electronics, Sharp, and UnitedHealth Group etc.
Continua’s objectives are (Continuaa 2015):

Developing design guidelines enabling providers to build interoperable sensors, home
networks, telehealth platforms, and health and wellness services.

Establishing a product certification programme (Figure 5) of interoperability and
promoting customers’ adherence to certification by using the Continua logo. Continua
certification requires that manufacturers submit products to rigorous testing by
independent test organisations, using interoperability guidelines and reference
systems.

Collaborating with government regulatory agencies to provide methods for safe and
effective management of diverse vendor solutions and working with health care
30 (127)
industries to develop new ways to address the costs of providing personal telehealth
systems.
Figure 5. Continua’s certification process (PCHA 2015).
Continua is not a standards body – instead, Continua has selected a set of connectivity
standards and is working to identify and resolve gaps in some standards bodies so that
personal telehealth solutions are interoperable. Continua is providing guidelines (PCHA
2015) specifically on how to use the standards to achieve interoperability across many
companies and many devices. These design guidelines define an overall architecture (Figure
6) and utilised standards include:

IEEE 11073 Personal Health Device family of standards for data format and
exchange between the sensor and the gateway and finally the electronic health
record system. This family of standards ensures that the user of the data knows
exactly what was measured, where, and how, and that this critical information is not
lost (e.g. targeting integrity and authentication).

The Services Interface (WAN Interface) standardises around the IHE PCD-01
Transaction to move data between a personal health gateway and health and fitness
services (e.g. telehealth services). The Services Interface provides for uploading
device
observations,
exchange
of
questionnaires
and
responses,
consent
management, capabilities exchange, and authenticated persistent sessions over a
wide area network.
31 (127)

The Health Information Service Interface (HRN Interface) standardises around the
HL7-based PHMR to move information between a health and fitness service and a
health care information service provider (e.g. EHR).
Figure 6. Continua’s Personal Connected Health Alliance architecture (PCHA 2015).
Currently, Continua’s guidelines are specifically written for device manufacturers that intend
to go through the Continua certification process, and the guidelines for non-members are
publicly available only by request, on Continua’s website.
Continua has a test and certification programme that tries to ensure interoperability.
Certification of sensor devices ensures that IEEE 11073 conformant data is securely
received at the gateway. Other certification means ensure that WAN interface PCD-01
messages contain valid values and HRN interfaces follow the syntax and semantics of XML
messages.
2.2.2
Internet
The Internet, is officially defined as “a loosely-organized international collaboration of
autonomous, interconnected networks, supports host-to-host communication through
32 (127)
voluntary adherence to open protocols and procedures defined by Internet Standards” (RFC
2206). The Internet is a worldwide system of computer networks based on the Advanced
Research Projects Agency (ARPA) of the U.S. government in 1969. In 1983, the U.S.
Defense Department spun-off MILNET* (which was part of Arpanet), which enabled
unclassified military communications. Arpanet was renamed the Internet in 1984, when it
also included university and corporate labs. Since then, the Internet has evolved into its
current form, containing more than 440 million computers directly and countless other
computers, tablets, and smartphones.
The Internet is still based on the same ARPANet principles: packet network switching
utilising a set of agreed-upon protocols like TCP (Transmission Control Protocol) and IP
(Internet Protocol) and an addressing scheme (IP addresses including DNS, Domain Name
Service). Internet messages, called datagrams, are broken into packets, which are
transmitted independently across it, based on a process called Internet routing. IP is
concerned with routing, meaning that IP attaches the address of the destination of each
packet. IP ensures that packets get to the right place. TCP, on the other hand, provides retransmission of lost packets and ensures delivery of data in the correct order. Several other
protocols are needed to maintain the routing functions of the Internet, like OSFP (Open
Shortest Path First) and RIP (Routing Information Protocol). Based on this communication
background, several different services, including popular web applications, are enabled.
Currently, the further development work, such as defining new or improved versions of
Internet protocols needed to maintain the Internet and the applications utilising it, is devoted
to open organisations like IETF (Internet Engineering Task Force) and W3C (World wide
Web consortium). Both follow the open standard principle.8
IETF – Internet Engineering Task Force
The Internet Engineering Task Force (IETF) is an open international community of network
designers, operators, vendors, and researchers concerned with the evolution of the Internet
architecture and the smooth operation of the Internet. The IETF’s work is based on the
following principles (Alvestrand 2004):
8
See more: https://open-stand.org/about-us/principles/
33 (127)

Open process and volunteer core - any interested person that furthers the IETF's
mission of "making the Internet work better” can participate in the work, know what is
being decided, and make their voice heard on the issue.

Technical competence - IETF output is expected to be designed to sound network
engineering principles - this is also often referred to as "engineering quality".

Rough consensus and running code – the IETF makes standards based on the
combined engineering judgement of its participants and real-world experience in
implementing and deploying specifications.

Protocol ownership - when the IETF takes ownership of a protocol or function, it
accepts responsibility for all aspects of the protocol. Conversely, when the IETF is not
responsible for a protocol or function, it does not attempt to exert control over it.
From an organisational perspective, all participants in IETF’s work, including managers, are
volunteers, though their work is usually supported by their employers or sponsors. The actual
IETF work is performed in working groups, which are organised by topic into several areas,
like routing, transport, and security, and managed by Area Directors (ADs). The ADs are
members of the Internet Engineering Steering Group (IESG). Working groups produce RFCs
(Requests For Comments), or enumerated “proposals” for a standard. RFCs are a collection
of documents describing suggested best practices relevant to the Internet. The name
“request for comments” is quite misleading, because after a document has been published
as an RFC, there is no way to change it. If modifications should be made to an RFC (e.g., if
one RFC supersedes another), a new RFC is announced with a new number.
Most RFCs concerns technical arrangements and conventions of the Internet, mostly
protocols enabling interoperability of systems. Not all RFCs are or become Internet
standards or even de-facto standards, in fact only a small number of proposals get wider
acceptance among practical implementers. On the other hand, some Internet standards have
the status "required", which means that they shall be applied everywhere on the Internet;
other RFCs are "recommended" or just "elective". These “official Internet standard” RFCs
form the 'STD’ subseries of the RFC series. When a specification has been adopted as an
Internet standard, it is given the additional label "STDxxx", but it keeps its RFC number and
its place in the RFC series.
The “standardization process” starts by releasing an unofficial Internet-Draft (I-D) as a “work
in progress”. An Internet-Draft can be the product of extensive co-operation among
interested parties in a working group. An Internet Draft is only valid for six months, unless it is
34 (127)
replaced by an updated version or unless it is under official review by the IESG (i.e., a
request to publish it as an RFC has been submitted). Internet-Drafts have no formal status,
and are subject to change or removal at any time. Internet-Drafts are later (usually after
several revisions) accepted and published by the RFC editor as an RFC, and labelled a
Proposed Standard. Usually, reaching Proposed Standard level requires neither practical
implementation nor operational experience.
Practical usability of a Proposed Standard is confirmed by developing reference
implementations. A specification from which at least two independent and interoperable
implementations from different code bases have been developed, and for which sufficient
successful operational experience has been obtained, may be elevated to the "Draft
Standard" level. For a Draft Standard, not only must two implementations interoperate, but a
report must also be provided to the IETF. The working group chair is responsible for
documenting the specific implementations. A Draft Standard is normally considered to be a
final specification, and changes are likely to be made only to solve specific problems. A
specification for which significant implementation and successful operational experience has
been obtained may be elevated from the Draft-Standard level to the Internet Standard level.
Currently, there are no official procedures or services provided by the IETF to ensure that a
given implementation strictly conforms with Internet standards. An implementer (e.g. a
system provider) usually only promotes adherence to these Internet standards without any
confirmed certainty that products really provide what they promise. Despite that, the IETF’s
“rough consensus and running code” approach works extremely well.
World Wide Web Consortium
When IETF is more oriented to standardising and developing protocols and practices
enabling the basic functions of Internet internetworking, the World Wide Web Consortium
(W3C) is targeting application-level standards utilising the Internet as an enabling
technology. W3C standards define an Open Web Platform for application development that
has enabled developers to build rich, interactive applications on any device backed up with
data stores.
Contrary to the IETF, W3C as an organisation is more traditional, directly funded by more
than 390 member organisations, enabling the W3C to maintain a full-time staff. W3C is
administered via a joint agreement among MIT (Massachusetts Institute of Technology,
USA), ERCIM (European Research Consortium for Informatics and Mathematics), Keio
University from Japan, and Beihang University from China. The W3C staff mostly work
35 (127)
physically at one of these institutions and are led by a director and a CEO. The W3C’s main
objective is the development of standards for the World Wide Web (WWW), including
education and promotion, development software, and services for support goals like “Web for
all” and “Web on Everything”. The W3C Process Document, Member Agreement, Patent
Policy, and a few others documents, establish the roles and responsibilities of the parties
involved in the making of W3C standards.
The W3C Standard Formation Process has been influenced by the IETF’s process and
defined within the W3C Process Document. A new standard or recommendation must
progress through (W3C 2015):

A working draft (WD) is published for review by the community when enough initial
discussion is done. Commentary by virtually anyone is accepted, though no promises
are made to modify it, and the standard document may likely have significant
changes.

A candidate recommendation (CR) is a version of the standard that is more mature,
and the purpose of the CR is to collect feedback from the development community on
how implementable the standard is. At this point, the standard document may still
change but no major changes are to be expected, and features can still change due
to feedback from implementers.

A proposed recommendation (PR) is the version of a standard that has passed the
prior two levels. This step usually does not make any significant changes to a
standard, as the document has been submitted to the W3C Advisory Council for final
approval.

A W3C recommendation (REC) indicates that it is ready for wide deployment within
its problem domain.
Similar to the IETF and contrary to ISOC and other international standards bodies, the W3C
does not have any certification programme. The W3C has explained that starting such a
certification programme has a risk of creating more drawbacks for the community than
benefits.
There are, however, some tools provided by the W3C to test conformity with W3C standards.
One such tool-based service is the W3C Markup Validation Service (http://validator.w3.org/)
which provides help in checking the validity of web documents (e.g. checking HTML and
XML syntax). According to the W3C, validation is not strictly equivalent to checking for
conformance with the specification, as validation is only a part of conformance.
36 (127)
Ficix
Another form of interoperability and organising functions related to the Internet is FICIX
(www.fixic.fi), the Finnish Communication and Internet Exchange (IX) association. FICIX is
the biggest Internet exchange point (IXP) in Finland, and most of the Internet traffic between
Internet service operator (ISP) in Finland is transferred via FICIX. An IXP enables networks
to interconnect directly rather than via third-party networks. The primary advantages of direct
interconnections are lower cost, lower latency, and increased data transmission bandwidth.
Non-profit FICIX is a registered association and provides neutral and reliable IP peering
facilities for its members (currently 28). These members include several Finnish
telecommunications operators, ISPs, some ICT-related companies like Nokia and Microsoft,
and research institutes and universities via FUNET (Finnish University and Research
Network).
FICIX operates as an association governed by Finnish association law. Administrative tasks
are led by annually elected trustees, and practical operations like technical maintenance and
accounting are outsourced to service providers.
2.2.3
Mobile networks
Mobile and smartphones have become an important part of our every activities, and they
currently form an infrastructure that is critical to our society as a whole. Interoperability has
been a vital part of the development and deployment of both mobile phones and networks,
both nationally and on a global level. For example, a concrete benefit of this modular
approach is that an end-user can rather easily switch between mobile operators using the
same handset just by replacing the SIM card, and can also roam to other countries and use
mobile services because the mobile networks are built using the same technical interfaces.
Overall, the ecosystem around mobile networks based on the GSM family of technologies is
a good example of a globally harmonised multi-actor interoperability environment where
modular products and services are deployed, enabling large economies of scale and
international roaming (Casey, 2013)9.
9
This approach can be characterised as the formation of tightly coupled interfaces and standardisation, which
works well especially as it relates to basic utility services, where the needs are very similar for all end-users. In
the case of services where end-user needs differ considerably, it is better to use a more loosely coupled form of
37 (127)
From a historical perspective, before the harmonised GSM, the situation was in many ways
similar to that of smart cities today. Dedicated vertically integrated solutions were developed
and deployed, and there was very limited interoperability between solutions. The Nordic
countries were an exception, where the national mobile operators started to develop a panNordic first generation mobile network that would ensure interoperability and roaming
between national networks. Standardisation of open interfaces enabled a more modular
architecture, which meant that operators could demand that network vendors (i.e. Ericsson,
Nokia, and Siemens), build their product offering in a modular manner using these open
interface specifications, and thus procure multi-vendor solutions10 that also enabled roaming
across Nordic countries (Casey, 2013).
Later on, this Nordic model became the basis for a pan-European mobile network and, with
its established processes and market, provided good grounds for the specification and
deployment of GSM open interfaces for second-generation mobile networks. This in turn
enabled interoperability, and multi-vendor and multi-operator solutions on an even larger
scale (Casey, 2013).
An important part of the success of GSM has also been the active harmonisation of
frequency spectrum band regulation by governments across Europe and elsewhere, which in
turn makes it an interesting example from the smart city point of view, where the public
sector continues to regulate many of the activities. In the evolution of GSM, an important
milestone was reached on 7th September 1987, when 15 operators from 13 countries signed
the GSM Memorandum of Understanding (MoU) stating that they would all deploy GSM. The
GSM MoU later on evolved into the GSM Association (GSMA)11, a group of GSM operators
and their suppliers and other partners supporting the deployment and promotion of GSM,
which to this day serves as one of the core pillars of the GSM mobile technology track, and
represents the interests of mobile operators worldwide, uniting nearly 800 operators.
In addition to GSMA (which represents the procurement side of mobile networks), several
other associations play an important role in enabling the horizontal model. Specification and
standardisation of the equipment is currently conducted by the 3rd Generation Partnership
interfaces, where just the lowest common denominator is identified and specified (similar to the working
model on the Internet).
10
Some claim that this model on multiple operators procuring modular interoperable multi-vendor systems
originated from Finland, which had a large group of small local operators.
11
http://www.gsma.com/
38 (127)
Project (3GPP)12 (formerly held by the European Telecommunications Standards Institute
(ETSI)13). Other important organisations are the Global Mobile Suppliers Association (GSA)14
(i.e. the supplying vendors of mobile network equipment), which promotes the GSM family of
technologies and facilitates networking and dialogue between member companies for
information sharing, business development opportunities, and access to the global market;
and the Global Certification Forum (GCF), which provides a globally-recognised industry
certification process ensuring compliance of products with agreed standards, and which
ensures their interoperability.
National-level interoperability activities
It is good to note that on a national level, too, mobile operators, who are direct competitors,
also collaborate, for example in terms of interoperability. One notable example of
interoperability (and also of a simple form of MyData) is mobile number portability, which
enables end-users to switch between operators without losing their original phone numbers.
Number portability in Finland is technically arranged by a company called Numpac15, which
runs the technical infrastructure that maintains the number linkages. The shareholders of
Numpac are the largest three operators, DNA, Elisa, and TeliaSonera, all with equal shares
of the capital stock.
Another good example of collaboration is the creation of a harmonised mobile identity and
authentication solution16 used by the three largest operators. The mobile ID service is the
result of a Finnish consortium made up of government and public services authorities, mobile
operators, and the Finnish Federation for Communications and Teleinformatics (FiCom)17.
Overall, in many cases the government, which in the case of Finland means the Ministry of
Transport and Communications and the Finnish Communications Regulatory Authority
12
http://www.3gpp.org/
13
http://www.etsi.org/
14
http://www.gsacom.com/
15
http://www.numpac.fi/index.php?site=127
16
http://www.gsma.com/personaldata/wp-content/uploads/2013/03/GSMA_Mobile-
Identity_Finnish_Case_Study.pdf,
http://www.gsma.com/personaldata/wp-content/uploads/2013/07/SC_GSM_288_Finland-Mobile-IDexecutive-summary-100713-v4.pdf,
http://www.mobiilivarmenne.fi/
17
http://www.ficom.fi/inbrief/index.html
39 (127)
(FICORA)18, has played an important role in enabling a regulatory environment for the
operators, which has led to a fruitful combination of both competition and collaboration.
3. Smart city background
Smart city is a broad theme involving many different sectors, use cases, and stakeholders.
Currently, no established definition exists of a smart city, and it can be understood in many
ways and approached from multiple perspectives. To gain a better understanding of the
fundamental nature of the topic area, in the following we present a rough depiction of key
smart city technical layers, review different smart city definitions, and introduce a framework
used to structure the smart city theme and our work.
Smart city technical layers
A smart city can essentially be seen as the application of ICT technologies to sense, analyse,
and integrate the key information of core systems running in cities. In a smart city, the digital
infrastructure improves the efficient use of the physical infrastructure, providing better and
more convenient services for inhabitants. The urban environment has been enriched with
sensors, processors, actuators, and other devices interconnected by a network to enhance
city-related services. The aim is to create a distributed network of intelligent sensor and
actuator nodes, which can measure and affect many parameters to enable more efficient
operations in and management of the city.
On a technical level, the smart city architecture includes the following layers (Figure 7) (Suo
2012):

A perception layer, where the components of the city (bridges, roads, vehicles, and
end-users) are instrumented with sensors, actuators, tags, and readers.

A network layer, which enables data transmission between sensors and actuators
and the application support layer, using either wired or increasingly often wireless
connections.

An application support layer, which provides massive data processing capabilities
using cloud computing.
18
https://www.viestintavirasto.fi/en/index.html
40 (127)

An application layer, which analyses and processes data related, for example, to
environmental monitoring and intelligent transportation
Figure 7. Smart city layers.
The smart city ICT infrastructure is dependent on energy-efficient sensing and processing
technologies. Technical advances decrease the cost of sensors, actuators, and processors,
enabling them to be utilised in nearly any real-world object. Internet of Things (IoT) refers to
everyday objects that are readable, recognisable, locatable, addressable, and/or controllable
via the Internet (via RFID, a network, or other means). The perception layer technologies
consist of these smart sensors, machine to machine (M2M) communications, and the
Internet of Things (IoT). More advanced sensors could also be used to collect information,
such as LIDARs (Laser Illuminated Detection And Ranging) for building 3D city models and
so on.
The next layer, namely the network layer, enables data transmission between sensors and
actuators and upper layers, using either wired or increasingly often wireless connections.
Since the wired infrastructure is expensive to set up and maintain, and mobile traffic profiles
of these IoT/M2M applications usually consist of short messages, wireless network
infrastructures are used. IoT and M2M applications have a large range of quality of service
(QoS) requirements. Some applications require real-time connections, others are suited for
delay tolerant networks (DTN). Generally, although infrastructure networks like LTE (GSM
Long Term Evolution) are often suitable for the majority of services, special solutions in
certain areas might also be needed.
Cloud computing is expected to provide the support needed to address the dynamic,
exponentially growing demands for real-time, reliable data processing peculiar to smart city
applications. Cloud computing is a paradigm in which data and services reside in massively
scalable data centres and can be ubiquitously accessed from any connected device over the
Internet (Armbrust, 2010). Cloud computing refers to both the applications delivered as
services over the Internet and the hardware and system software in the data centres that
provide those services (Armbrust, 2009). The advantages of cloud computing are efficiency
through lower hardware and IT costs, the ability to dynamically scale up capacity, and
41 (127)
payment flexibility (pay what you need) (Armbrust, 2010). A cloud service maintains the
collected sensor data, enables its processing to produce services, and distributes the result
for either human or machine use.
A major concern for people confronted with the idea of a smart city is their privacy.
Technologies of ubiquitous computing can provide the means for total monitoring of an
individual’s behaviour. In order to overcome these concerns, potential users have to gain
trust in the systems. Therefore, transparency-enabling technologies should be part of the
infrastructure. From a security perspective, the vulnerabilities of smart city environments are
similar to all ICT environments, but appended with ones more specific to (wireless) sensor
networks. The growing number of networked devices – the Internet of Things – adds less
capable devices to the network. These devices are restricted by their processing capability
and energy, which makes them hard to secure.
Smart city definitions
Overall, smart city has become a commonly used term for referring to the application of ICT
to public services and critical infrastructure in a city environment19. It is typically used very
broadly to cover a wide scale of applications, which has also made it difficult to use it in a
disciplined manner. Smart city definitions often emphasise a multi-sectoral approach,
involving creating linkages across the sectoral siloes. Smart city also often refers to a new,
more bottom-up, distributed, and networked way of working that gives more power to smaller
actors and end-user innovation.
Table 2 present a collection of general definitions of smart city20. As can be seen, some
definitions are very broad and generic and describe how a city could become more intelligent
on a general level, while some are more focused on the application of ICT. Some of the
definitions focus on interoperability and the interdisciplinary nature of smart cities, while other
definitions are based on specific areas of a smart city (e.g. governance, economy, mobility,
environment, people, and living) or the participation of citizens and human capital.
19
There is also overlap of the Smart City concept with related city concepts such as: Intelligent City, Knowledge
City, Sustainable City, Wired City, Digital City, Eco-City, Learning City, and Connected City. There is also some
overlap with broad ICT concepts such machine-to-machine (M2M) communications, Internet of Things, and
Industrial Internet.
20
This collection is partly based on the one presented by the European Parliament (2014).
42 (127)
Table 1. Smart city definitions (1).
Definition
Definition
group
Broad and
A city striving to make itself “smarter” (more efficient, sustainable, equitable, and
generic
liveable) (Natural Resources Defense Council 2014).
Cities [should be seen as] systems of systems, and that there are emerging
opportunities to introduce digital nervous systems, intelligent responsiveness, and
optimization at every level of system integration (MIT 2013).
“Smartness” of a city is its ability to bring together all its resources to achieve goals
and purposes it has set itself (ISO-IEC).
Focused on
A Smart City is a city seeking to address public issues via ICT-based solutions on the
the application
basis of a multi-stakeholder, municipally based partnership (European Parliament
of ICT
2014).
Smart cities should be regarded as systems of people interacting with and using flows
of energy, materials, services and financing to catalyse sustainable economic
development, resilience, and high quality of life; these flows and interactions become
smart through making strategic use of information and communication infrastructure
and services in a process of transparent urban planning and management that is
responsive to the social and economic needs of society (EIP SCC 2013).
A city “connecting the physical infrastructure, the IT infrastructure, the social
infrastructure, and the business infrastructure to leverage the collective intelligence of
the city” (Harrison et al. 2010)
A city “combining ICT and Web 2.0 technology with other organizational, design and
planning efforts to dematerialize and speed up bureaucratic processes and help to
identify new, innovative solutions to city management complexity, in order to improve
sustainability and liveability” (Toppeta 2010).
A Smart City gathers data from smart devices and sensors embedded in its
roadways, power grids, buildings and other assets. It shares that data via a smart
communications system that is typically a combination of wired and wireless. It then
uses smart software to create valuable information and digitally enhanced services.
(http://smartcitiescouncil.com/article/our-vision)
43 (127)
Table 2. Smart city definitions (2).
Definition group
Definition
Focused on
[Smart Cities are about] leveraging interoperability within and across policy
interoperability and
domains of the city (e.g. transportation, public safety, energy, education,
the interdisciplinary
healthcare, and development). Smart City strategies require innovative ways of
nature of smart
interacting with stakeholders, managing resources, and providing services
cities
(Nam and Pardo 2011).
Smart Cities combine diverse technologies to reduce their environmental
impact and offer citizens better lives. This is not, however, simply a technical
challenge. Organisational change in governments – and indeed society at large
– is just as essential. Making a city smart is therefore a very multi-disciplinary
challenge, bringing together city officials, innovative suppliers, national and EU
policymakers, academics and civil society (http://eu-smartcities.eu/faqs).
Based on specific
A city well performing in a forward-looking way in economy, people,
areas of a smart city
governance, mobility, environment, and living, built on the smart combination of
endowments and activities of self-decisive, independent and aware citizens
(Giffinger et al. 2007).
A city that monitors and integrates conditions of all of its critical infrastructures,
including
roads,
bridges,
tunnels,
rails,
subways,
airports,
seaports,
communications, water, power, even major buildings, can better optimize its
resources, plan its preventive maintenance activities, and monitor security
aspects while maximizing services to its citizens (Hall 2000).
Focused on the
A city is smart when investments in human and social capital and traditional
participation of
and modern communication infrastructure fuel sustainable economic growth
citizens and human
and a high quality of life, with a wise management of natural resources, through
capital
participatory governance (Caragliu, Del Bo and Nijkamp 2009).
Any adequate model for the Smart City must therefore also focus on the
Smartness of its citizens and communities and on their well-being and quality of
life, as well as encourage the processes that make cities important to people
and which might well sustain very different – sometimes conflicting – activities
(Haque 2012).
A [smart] city is where the ICT strengthens freedom of speech and the
accessibility to public information and services (Anthopoulos and Fitsilis 2010).
44 (127)
For our purposes we use the definition by the European Parliament (2014), since it seems to
strike a good balance between the different viewpoints and summarises the essential
elements of a smart city. The European Parliament (2014) also gives a detailed definition in
which a smart city consists of six key components: smart governance, smart people, smart
living, smart mobility, smart economy, and smart environment (Table 3 and Table 4).
Table 3. Six key smart city components (1).
Smart city
Definition
component
Smart
Smart governance refers to joined up intra-city and inter-city governance, including
Governance
services and interactions that link relevant public, private, civil, and European Community
organisations so the city can function efficiently and effectively as one organism. The
main enabling tool to achieve this is ICT (infrastructures, hardware, and software),
enabled by smart processes and interoperability and fuelled by data. International,
national, and hinterland links are also important (beyond the city), given that a smart city
could be described as quintessentially a globally networked hub. This entails public,
private, and civil partnerships and collaboration with different stakeholders working
together in pursuing smart objectives at city level. Smart objectives include transparency
and open data by using ICT and e-government in participatory decision-making and cocreated e-services, such as apps. Smart governance can also orchestrate and integrate
some or all of the other smart characteristics.
Smart
Smart economy refers to e-business and e-commerce, increased productivity, ICT-
economy
enabled and advanced manufacturing and delivery of services, ICT-enabled innovation,
and new products, services, and business models. It also establishes smart clusters and
eco-systems (e.g. digital business and entrepreneurship). Smart economy also entails
local and global inter-connectedness and international embeddedness with physical and
virtual flows of goods, services, and knowledge.
Smart
Smart mobility refers to ICT-supported and integrated transport and logistics systems.
mobility
For example, sustainable, safe and interconnected transportation systems can
encompass trams, buses, trains, metros, cars, bicycles, and pedestrians in situations
using one or more modes of transport. Smart mobility prioritises clean and often nonmotorised options. Relevant and real-time information can be accessed by the public in
order to save time and improve commuting efficiency, save costs, and reduce CO2
emissions, as well as by network transport managers to improve services and provide
feedback to citizens. Mobility system users might also provide their own real-time data or
contribute to long-term planning.
45 (127)
Table 4. Six key smart city components (2).
Smart city
Definition
component
Smart
Smart environment refers to smart energy, including renewables, ICT-enabled energy
environment
grids, metering, pollution control and monitoring, renovation of buildings and amenities,
green buildings, green urban planning, and resource use efficiency, re-use, and
substitution, which serve the above goals. Urban services such as street lighting, waste
management, drainage systems, and water resource systems that are monitored to
evaluate the system, reduce pollution, and improve water quality are also good
examples.
Smart
Smart people refers to e-skills, working in an ICT-enabled working environment, having
people
access to education and training, human resources, and capacity management within an
inclusive society that improves creativity and fosters innovation. As a characteristic, it
can also enable people and communities to input, use, manipulate, and personalise data,
for example through appropriate data analytic tools and dashboards, to make decisions
and create products and services.
Smart living
Smart living refers to ICT-enabled lifestyles, behaviour, and consumption. Smart living is
also healthy and safe living in a culturally vibrant city with diverse cultural facilities, and
incorporates good quality housing and accommodation. Smart living is also linked to high
levels of social cohesion and social capital.
Framework for the smart city themes
Next, as a synthesis, we map the six components to horizontal and vertical themes where
smart mobility, smart environment (which can be seen as including the built environment,
energy, and cleantech sectors), smart living (including safety and security, and healthcare),
and smart people (including the educational sector) correspond to vertical themes, and
where smart governance and smart economy correspond to horizontal themes. ICT can also
be seen as a horizontal theme, as it encompasses all of the components.
46 (127)
Common practices for cities and
other public actors
Mobility
Multi-actor business environment
Built
environment
Energy &
cleantech
Safety
and
security
Health &
welbeing
Education,
culture
Modular ICT-architecture
Focus of the project
Figure 8. Alignment of smart city components to horizontal and vertical themes.
As depicted in Figure 8, the horizontal themes of this project correspond largely to these
three horizontal themes: smart governance to common practices for cities and other public
actors, and smart economy to the multi-actor business environment (and also a modular ICTarchitecture as a key enabler). The three selected focus sectors (i.e. mobility, built
environment, and energy and cleantech) correspond to the vertical themes. We use this
vertical and horizontal division to structure the work and focus especially on interoperability
and the creation of a multi-buyer and multi-vendor market in this context.
4. Overall view of smart city sectors in Finland
Next, we move on to describe on a general level how the smart city sectors depicted in
Figure 8 are structured in Finland. Although the project focuses on mobility, built
environment, and energy (including cleantech), which we analyse in more detail in the
following sections, here we give a brief overview of all the vertical smart city sectors (a
summary depicted in Figure 9). We also give a short description of municipal ICT. The review
here is not meant to be an exhaustive one, but aims to highlight the overall structure, some
key actors (in accordance with the demand, supply21 and horizontal actors in Figure 3), and
developments in each sector.
21
In our analysis, demand side actors refer to the organisations procuring, and supply side actors to the
organisations supplying the ICT systems.
47 (127)
Mobility
Built
environment
Energy
Cleantech
Safety and
security
Education
Healthcare
ICT
application
maturity
Medium
Medium
Medium
Low
Medium
Medium
High
Level of
interoperability
Low
Medium
Medium
Low
Low
Low
Low/Medium
Public and
private
transport
City & land
use planners,
building and
infrastructure
owners,
design,
construction,
maintenance
Energy
operators,
building
owners, micro
energy
producers
Water and
waste
management,
environmental
monitoring
Police, fire
department,
building
owners,
private
security
Basic
comprehensive and
secondary
education,
private
education
Hospital
districts,
municipal and
private health
care providers
ITS Finland,
ITS Factory
BuildingSMART
Finland,
RAKLI, FLIC,
Kuntaliitto
Finnish
Energy,
Fingrid,
Lähienergialiitto
FIWA, FWF,
FSWA, JHY
EduCloud
Alliance,
Kuntien Tiera
HL7 Finland
UNA, Kanta
ITS vendors
and service
providers
GIS and BIM
software,
building
automation
vendors
Smart grid
vendors,
energy
service
companies
Smart water
and waste
management,
environmental
monitoring
system
vendors
Educational
system
vendors
Medical
equipment
and IT-system
vendors and
service
providers
Demand side
actors
Example
horizontal
actors &
activities
Supply side
actors
Security
system
vendors and
service
providers
Figure 9. Overview of Smart City sectors in Finland.
4.1
Mobility
Over the years, there have been major advances in the utilisation of ICT in the mobility
sector in Finland. A major part of road infrastructure is instrumented with cameras and other
sensors that follow the flow of traffic. In addition, a large number of public transportation
vehicles (buses and trams) have location and other sensors. End-user applications such as
journey planners and real-time traffic data are widely available to different end-user devices.
Private vehicles, especially new ones, also often include broadband connectivity and access
to vehicle sensors, which enables different services, such as automatic emergency calls,
remote diagnostics maintenance, and real-time navigation.
The overall mobility market in Finland has been estimated at roughly 50 billion euros22. Out of
this, an estimated 2.9 billion goes to infrastructure investments by the government and
municipalities, with the rest being spent on different mobility services (i.e. operating the
vehicles) by government, municipalities, enterprises, and households.
22
http://its-
finland.fi/images/itsfinland/tapahtumat/heureka08122014/Trafficlab_08122014_Marko_Forsblom_LVM.pdf
48 (127)
Overall, the state of interoperability in the mobility sector can be described as being still quite
elementary. Some common standards and open interfaces are in use, such as Kalkati.net,
SIRI and GTFS for public transportation, Datex II for the exchange of traffic information, and
the SUTI interface for taxi dispatch systems. Important horizontal actors that facilitate the
interaction of demand and supply side actors include ITS Finland, ITS Factory, and TVV
lippu- ja maksujärjestelmä Oy, which is developing a nationwide public transportation
ticketing system, Waltti23. Some ongoing programmes also work as horizontal mediators,
such as the Traffic Lab initiative headed by the Ministry of Transport and Communications.
Recently, a concept called Mobility-as-a-Service, promoted heavily by Tekes, among others,
has emerged, which envisions a seamless door-to-door service across different transport
modes that, if successful, will likely drive the market towards more horizontal co-operation
across transport modes and municipalities.
Overall, the mobility sector can be roughly divided into public transportation and the private
mobility of enterprises (including both logistics and personnel mobility) and households.
Public transportation is regulated by the Centres for Economic Development, Transport and
the Environment (ELY Centres) and the local public transportation authorities (e.g. Helsinki
Region Transport), under the guidance of the Ministry of Transport and Communications,
and includes public buses, trams, and trains that operate within and across cities. Public
transportation also consists of taxis and their permits. Furthermore, the transport of patients
(i.e. health care and social sector) and students (education sector), when subsidised by
central government or municipalities, is also considered public transportation. The
government and municipalities spend about 1 billion euros annually on subsidies related to
public transportation.
Key actors for public transportation on the demand side are, for example, the local public
transportation authorities responsible for organising public transportation (e.g. Helsinki
Region Transport (HRT) in the Helsinki region area and Tampereen joukkoliikenne in the
Tampere region area) and the organisations operating the actual services, which are typically
private companies (e.g. for HRT, Helsingin seudun bussiliikenne, Nobina, Veolia, and
Pohjolan matka). Long distance buses and taxis and their central associations, Linja-autoliitto
and the Finnish Taxi Owners Federation and their related organisations, are also key
demand-side actors. On the supply side, vendors and IT-system providers for ticketing
systems (e.g. Tieto, Fara) and journey planners (e.g. CGI) are in an important role. Individual
developers have also become active, for instance in building mobile applications for HRT
23
http://www.lmj.fi/en/
49 (127)
journey planners using the APIs that HRT has made available. Taxi switching-centre systems
and equipment providers, such as Mobisoft and Semel, are active players on the supply side.
As it relates to private mobility, the Finnish Transport Safety Agency (Trafi) is responsible for
the regulation of private vehicles under the guidance of the Ministry of Transport and
Communications. For private mobility, on the demand side, companies spend roughly 33
billion euros on personnel mobility and logistics, and private households roughly 16 billion
euros on their mobility needs. On the supply side, some smart mobility solutions exist, such
as driving diaries that help company book-keeping and enable driver coaching for individual
drivers (solutions provided e.g. by companies such as Helpten, EC-Tools, and Abax).
Furthermore, services related to real-time traffic information, for example in terms of traffic
jams and road weather (provided by V-traffic and HERE), are commonly used. On-board
units for vehicles are provided by companies such as Aplicom and Indagon.
4.2
Built environment
Different ICT technologies are already applied in many parts of the built environment, such
as in geographic information systems (GIS), infrastructure modelling, building information
modelling (BIM), and building automation, which enables real time-applications. The state of
interoperability for these solutions varies when, for example, promising development towards
interoperable models has been made for information modelling (e.g. for geographic
information systems) but when, for example, building automation remains rather fragmented
although standards are also emerging. A recent strong development trend has been for cities
to build 3D city models of the urban environment. The leading standard has been CityGML,
for which information can be gathered from different sources, possibly in real time. It is
envisioned that this information would become a key enabler for new services and business.
Important standards and interfaces are information models such as Web Map Service (WMS)
and Web Feature Service (WFS), specified by the Open Geospatial Consortium (OGC),
Inframodel3 on the infrastructure level, and IFC (Industry Foundation Classes) on the
building information modelling (BIM) level. For building automation, open communications
protocols exist such as BACnet, KNX, and LonWorks, and for facility management XML
structures such as E-ehyt24 have been defined. Product certification is also provided on an
international level by, for example, buildingSMART, and model checker solutions exist (e.g.
by Solibri) for validation and compliance control. Horizontal platforms that facilitate the
24
http://www.rakli.fi/toimitilat/kiinteistopalvelut.html
50 (127)
exchange of information related to public actors (e.g. building permits, city planning), such as
Lupapiste.fi, Tarkkailija, and Liiteri25, also exist. The connectivity of real-estate data has also
been improved by introducing a permanent building or real estate code26.
There are also many actors that facilitate horizontal interaction, such as the Association of
Finnish Local and Regional Authorities (Kuntaliitto) (where KuntaGML has been a notable
effort), National Land Survey of Finland (Maanmittauslaitos), FLIC (Finnish Location
Information Cluster), buildingSMART Finland, and the Finnish Association of Building
Owners and Construction Clients (Rakli). Some companies such as Solita and FCG can also
be seen as taking a more horizontal approach.
Overall, the construction market can be roughly divided into two segments: infrastructure and
building construction (in some cases, the construction product industry can be considered as
a separate segment). The total Finnish construction market was 29.5 billion euros in 201127.
City planning and regulation that govern these activities is mainly conducted by cities and
municipalities under the supervision of the Ministry of the Environment.
As it relates to the potential demand on the demand side, key actors are the owners of the
facilities, meaning the government (e.g. Senaatti Properties, The Finnish Transport Agency),
cities and municipalities, real estate companies (such as Citycon, Technopolis, Sponda), and
individual private companies and private households. Furthermore, on the demand side,
three key activities are:
1. Design (e.g. architectural, structural engineering, heating, piping and air conditioning
(HPAC; LVI); and companies like WSP, Ramboll, Pöyry)
2. Construction (e.g. YIT, NCC, Lemminkäinen, Skanska)
3. Maintenance and facility management (e.g. ISS, Caverion).
25
Driven largely by the Ministry Of Environment and the SADe programme. https://www.lupapiste.fi/,
https://www.etarkkailija.fi/,
http://www.ymparisto.fi/fi-
fi/Elinymparisto_ja_kaavoitus/Rakennetun_ympariston_tietojarjestelmat/Elinympariston_tietopalvelu_Liiteri
26
Vesala S and Oinonen K, ”Pysyvä rakennustunnus - Rakennustiedot tehokkaaseen käyttöön”, Suomen
ympäristökeskuksen raportteja, 2014.
27
http://www.rakennusteollisuus.fi/Documents/Suhdanteet%20ja%20tilastot/Rakentamisen%20yhteiskunnallise
t%20vaikutukset%202012.pdf
51 (127)
On the supply side, smart city solutions can, for example, be seen as being related to the
different modelling software solutions (e.g. SITO, Bentley, Vianova, and Tekla), building
automation systems (KONE, Schneider Electric, Fidelix, Siemens), construction products
especially when they are equipped with sensors, and new applications such as participatory
design, issue reporting28, and gamification techniques (e.g. Adminotech).
4.3
Energy and cleantech
Energy
Many advances have also been made relating to ICT systems for energy networks. Simple
real-time messages can already, for example, be sent between energy networks. Smart
meter penetration and the ability to provide real-time information related to energy
consumption are also already at a rather good level. Decentralised energy systems are
gradually being introduced with local demand management and distributed energy solutions,
but the interoperability between these solutions is not very advanced yet.
Interoperability between the large energy operators, for example in terms of messaging, is
already rather advanced. Common message formats based on the Ediel standard, and
specified by the Nordic Ediel Group, are used on a domestic but also on a Nordic level (for
the Nordic energy market Nordpool). An interoperability testing and certification service29 is
also provided to ensure the message formats are correctly implemented.
Other notable interoperability efforts include the EnergiaIT 2020 project (led by Finnish
Energy), where a central goal is to enhance the interoperability of IT procurements by energy
operators; and Datahub (led by Fingrid), a new platform being created to enhance the
information exchange of energy networks. Datahub is a notable investment that seeks to
provide new business opportunities for stakeholders and to enhance the intelligence of the
electricity networks in the Finnish market.
Overall, the energy sector can be roughly divided into electricity markets and district heating
(kaukolämpö) (e.g. the total market size of district heating in Finland was 2.3 Billion euros in
201330). Regulation is conducted on a national level by the Energy Authority (Energiavirasto)
28
For example the City of Helsinki has opened an API based on the Open311 specification for sending service
requests. http://dev.hel.fi/apis/issuereporting
29
The
service
is
hosted
by
Fingrid
and
operated
by
Empower
IM
http://www.fingrid.fi/fi/asiakkaat/Tiedonvaihtopalvelut/Testaus-ja-sertifiointipalvelu/Sivut/default.aspx
30
http://energia.fi/kalvosarjat/energiavuosi-2013-kaukolampo.
.
52 (127)
under the guidance of the Ministry of Employment and the Economy (Työ- ja
elinkeinoministeriö). Cities and municipalities also take part in regulation through urban
planning (e.g. related to the construction of energy systems, for example solar panels
installed on individual buildings).
On the demand side, for example, actors in the electricity network can be divided into
production, transmission, and consumption. A core actor in the electricity network is Fingrid,
the transmission grid operator of the Finnish national electricity grid. The energy operators
can be categorised into three groups: international operators (such as Fortum and
Vattenfall), operators active in large cities (e.g. Helsingin Energia (Helen), Vantaan energia,
Tampereen sähkölaitos, and Oulun energia), and operators active in smaller local
municipalities. Many of the operators are still tightly coupled through ownership to their host
cities and municipalities. On the supply side, actors like Tieto, CGI, and Enoro are large
players.
In the future, as energy management and production is expected to become increasingly
decentralised, the number of operators and other mediators could increase significantly as
new forms of distributed technologies, like more advanced demand management, are
deployed, paving the way to so-called smart grids. On the supply side, companies such as
ABB, SEAM, and There Corporation are driving these solutions. Many companies in the
building automation sector (such as Schneider Electric, Siemens) have also been active in
the energy sector and act as so-called energy service companies (ESCO) for facility owners,
optimising their energy consumption, which leads to savings in energy costs. A key
horizontal actor promoting decentralised energy solutions is the Finnish Local Renewable
Energy Association31.
Cleantech
As for cleantech, three areas where ICT solutions are deployed can be identified: water
management, waste management, and environmental monitoring systems. The smart water
and waste management systems are still in their early stages of development and not that
advanced in the application of ICT solutions. Environmental monitoring, on the other hand,
has a long history, especially related to weather information, and there are already some
practices for interoperability. Important regulatory entities are the municipalities and the
Ministry of the Environment.
31
http://www.lahienergia.org/lahienergia/energian-alykas-kaytto/
53 (127)
As it relates to water management, on the demand side municipal actors such as Helsinki
Region Environmental Services Authority (HSY) are in an important role, and in sparsely
populated areas voluntary water co-operative societies (vesiosuuskunta). In terms of supply
of smart city solutions, the landscape is not very evolved at this point. Some horizontal actors
exist, such as the Finnish Water Utilities Association (FIWA)32, a co-operation and member
association of the Finnish water and wastewater utilities and Finnish Water Forum (FWF)33,
which represents a variety of different actors in the Finnish water sector.
As it relates to municipal waste management, the demand side consists of municipal actors
such as HSY, Oulun Jätehuolto Liikelaitos, and Turun Seudun Jätehuolto Oy. Furthermore,
private service companies such as Lassila & Tikanoja and Sita are often involved in
operating the actual waste collection. On the supply side, innovative smart city solutions are
emerging, such as the waste sorting system by ZenRobotics and smart waste collection
solutions by Enevo, CGI, Ecomond, and Tietomitta. In terms of waste management, existing
horizontal actors are the Finnish Solid Waste Association (FSWA)34, which represents
Finnish regional and municipal waste management companies, and the Waste Management
Association JHY35.
Environmental monitoring has a long history, especially related to weather information, with
co-operation between municipalities, the Ministry of the Environment, and the Finnish
Meteorological Institute. This has also provided good grounds for interoperability between
networks and systems. The Finnish Environment Institute (SYKE) is another important
horizontal actor, providing services like Liiteri.
Interoperability has also been identified as a central development need in the Finnish MMEA
research programme, involving several companies related to air quality and other
environmental monitoring. The backbone of the programme is the MMEA Testbed, which
connects to various data sources, visualises near real-time data on-screen, and delivers
environmental data to a wider range of applications.
32
http://www.vvy.fi/jasenet/jasenet
33
http://www.finnishwaterforum.fi/en/members/
34
http://www.jly.fi/index.php
35
http://www.jatehuoltoyhdistys.fi/jhy-in-english/
54 (127)
4.4
Safety and security
Security services such as the police, fire department, border control, and private security
services are increasingly deploying ICT systems and can be seen as an important part of
smart cities. The regulation for this sector falls under the jurisdiction of the Ministry of the
Interior (Sisäministeriö) and the related agencies. On the demand side, there are different
governmental and operational units, such as the Helsinki Police Department, Western
Uusimaa Police Department, Helsinki City Rescue Department, and the Finnish Border
Guard. On the supply side, different technology providers exist, such as traffic enforcement
camera (Nopeusvalvontakamera) vendors. Safety and security solutions are also common in
buildings offered by private operators.
4.5
Education
Education is the second largest sector in cities and municipalities and is regulated by the
Ministry of Education and Culture (Opetus- ja kulttuuriministeriö) and its related agencies.
Although ICT has been utilised to some degree in the sector, including in libraries, a lot of
potential still remains. On the demand side, there are, for example, the schooling units giving
basic comprehensive education and upper secondary education. On the supply side,
educational systems vendors exist, such as Fronter and Dreamschool.
One important horizontal nation-level activity is library networks such as HelMet in the
Helsinki area, which have common operating rules, procedures, and services and where, for
example, the same library card can be used at any library in the network. Another notable
example of horizontal collaboration is the EduCloud Alliance, which aims to facilitate the
harmonised development, deployment, and use of educational technology and materials on a
national level.
4.6
Health care
The application of ICT in the health care sector is already quite advanced, with a wide
degree of monitoring and information systems deployed in hospitals and health care centres.
The application of ICT in the health care sector has also been very challenging in terms of
the interoperability of the systems. Overall, the health care and social sector is by far the
largest source of costs for cities and municipalities, at an average of 23 billion euros36. It is
36
http://www.yrittajat.fi/fi-FI/suomenyrittajat/a/tiedotteet/suomen-yrittajat-sote-uudistuksesta-lakiin-
kirjattava-vastuu-sote-alan-kehittamisesta-kyse-23-miljardista-eurosta.
55 (127)
regulated by the Ministry of Social Affairs and Health (Sosiaali- ja terveysministeriö) and its
related agencies.
On the demand side, important actors are the social service providers and the community
health centres (terveyskeskus) operated by cities and municipalities. A notable ongoing
activity is the Apotti co-operative project, where the goal is to purchase and adopt a client
and patient data system for participants, which include Helsinki, Vantaa, Kirkkonummi,
Kauniainen, and HUS (the Hospital District of Helsinki and Uusimaa). The rest of the HUS
district’s local governments can also participate in the project via the joint procurement
company for the Finnish municipalities, KL-Kuntahankinnat Oy.
Also on the demand side at a national level, the Social Insurance Institution of Finland
(KELA) is an important actor. Special health services are operated by hospital districts
(sairaanhoitopiiri, e.g. Helsingin ja Uudenmaan sairaanhoitopiiri (HUS)). On the demand
side, there are also private health providers (such as Terveystalo, Diacor, and Mehiläinen)
that provide services especially for companies in terms of occupational health.
On the supply side, a wide range of medical equipment vendors (e.g. GE) and IT system
providers (e.g. Tieto and CGI) exist. Smaller well-being technology providers, such as
Wellmo, are also emerging, which can be seen as complementing the official health care
services.
In terms of horizontal actors, Sitra in particular has been active in the health space and has
spearheaded the development of a national health account service, Taltioni. Another notable
horizontal effort is the HL7 Finland Association, an open association for organisations that
are interested in systems integration issues and solutions in health care and social services.
In addition to this, an interesting development is the National Archive of Health Information
(Kanta), where the goal is to provide national data system services for health care services,
pharmacies, and citizens, and which offers a testing and certification service for vendors37.
Yet another significant effort is the UNA project, where fifteen hospital districts and the
related municipalities are going to agree on common requirements for the health information
systems that they will procure in the future, and aim to catalyse a multi-vendor market that
would include smaller SMEs.
37
http://www.kanta.fi/en/web/ammattilaisille/testaus
56 (127)
4.7
Municipal ICT
Overall, the market around ICT systems in municipalities has been estimated at 823 million
euros, corresponding to roughly 1.1% of the budgets of municipalities38. On the demand side,
the procurement of city IT departments, including those of the largest six cities (Helsinki,
Espoo, Vantaa, Tampere, Turku, and Oulu), plays an important role. Joint procurement
companies such as Kuntien Tiera and KL-kuntahankinnat are also major players. On the
supply side, strong actors are, for example, Tieto, CGI, and IBM. In terms of regulations, the
Ministry of Transport and Communications, the Ministry of Finance (for which JulkICT and
JulkICT lab are important activities) and the related agencies are of relevance. Existing
horizontal actors with an ICT focus include COSS, ITE WIKI, and JUHTA. For individual
cities, important actors are development companies such as Forum Virium for the city of
Helsinki. Forum Virium has been active in promoting open data, open APIs, and developer
relations, and has also been active on an international level with the CitySDK project.
5. Perspectives on interoperability - three horizontal theme areas
5.1
Cities and the public sector
The purpose of this section is to analyse how city strategies support the evolution of
interoperability in smart services and solutions, and what actions cities have taken to
contribute to this development. Some pioneering cities have set ambitious targets for being
at the forefront of smart city development both nationally and internationally. For instance, in
its most recent strategy in 2013, the city of Helsinki declared an intention to become an
environmentally smart, green economy that creates partnerships with the business
community in order to create new innovative business in smart technologies, resource
efficiency, and carbon-neutral products. In a similar manner, the six largest cities of Finland Helsinki, Espoo, Vantaa, Turku, Tampere, and Oulu - have teamed up to promote the
development of smart services and solutions through the 6AIKA programme. The most
visible activities to advance these ambitions have been the designation of particular city
district development projects as demonstration sites for smart city solutions. Among these,
the best known are large urban development projects such as the Kalasatama district in
38
http://coss.fi/2014/06/05/avoin-kunta-pois-siiloista-ja-teknologialoukuista-kohti-yhteensopivia-jarjestelmia-
ja-prosesseja/
57 (127)
Helsinki, the railway station area (asemanseutu) in Tampere, the Hiukkavaara district in
Oulu, and the Sundom area in Vaasa.
Why should cities care about interoperability? Several arguments can be found for the
promotion of interoperable smart systems. First, cities should be capable of seamless service
provision across administrative borders. This should take place inside city administration,
across service sectors (e.g. health and education), and across administrative units and levels
(e.g. between two cities, or between a municipality and central government). The data
concerning one customer should be able to travel across interoperable systems from one
point to another.
Second, the efficient transfer of data across interoperable systems can improve productivity
in service production. Automatisation of digital information transfer across administrative
units has the potential to reduce the amount of manual work and the number of errors in
service provision.
Third, cities have a general interest in avoiding getting locked in to information technology
vendors. A vendor lock-in occurs when the city as a user is dependent on a particular
supplier and cannot use other suppliers without significant switching costs. An important
source of such costs is the transfer of data from an old system to a new one when changing
vendors. Another source of high costs is the integration of information systems, when
suppliers can charge a fee for each integration job separately for each city, even if cities’
basic needs and systems are very similar. The creation of interoperability by deploying open
standards can avoid vendor lock-in.
Fourth, information systems with open interfaces would allow the extension of a system with
complementary components at little additional cost. Closed systems supplied through
proprietary contracts are currently found to create significant additional costs for developing,
piloting, and deploying new functions in the future. For instance, a typical need emerges
when trying out new mobile technology solutions, which, in order to operate efficiently,
should communicate with city administration data systems. By setting requirements for open
interfaces in the tendering stage, cities can set up contracts that enable the introduction of
new functions in the course of changing user needs, technological evolution, and gradual
improvement of service quality levels.
Fifth, interoperability holds potential in the promotion of local economic development, which
is of great concern for cities. Open interfaces enable innovation by a multitude of players
(e.g. SMEs, start-ups, student communities, research organisations), and the creation of
scalable smart solutions. It can also enable the development of hybrid solutions that are
58 (127)
based on a combination of public and private data, as well as utilisation of the same data for
several applications and users, public and private.
5.1.1
The current state
The Finnish municipalities, comprising both cities and smaller communities, enjoy a large
degree of autonomy with regard to the central state government, by international
comparison. The relationship between the central government and municipalities has
evolved in recent decades from more rigid normative steering towards governance by
information and resources (state reimbursements). In earlier decades, the central
government set more strict requirements for service provision activities and budgeting.
Starting in the 1980s, a wave of deregulation transformed the relationship towards more
autonomy and governance mechanisms based on common performance targets and
information sharing. In the 2000s, the pendulum shifted a few steps back towards more
central coordination to deal with the resulting fragmentation, uneven development of public
service quality, and budgetary challenges among municipalities.
The relative autonomy of cities and other municipalities has resulted in a great degree of
variation in terms of information system and service deployment. As the supplier base for the
public sector in information technology has traditionally been dominated by a few large
vendors and contractors, and there have been very few concerted efforts to create
interoperability between organisations and systems, the landscape has become very
fragmented. Many municipalities perceive being trapped by a few large IT vendors. The costs
of this fragmentation have been estimated to be high. In addition, it is a widely shared
perception that many small municipalities are sub-optimal units for long-term strategic
development and provision of public services with sufficient quality. The capability for
information technology procurement is often insufficient in smaller municipal units.
For these reasons, there has been a clear movement towards more coordinated governance
of information systems in the public sector. New legislation was enforced in 2011, requiring
public authorities to plan and describe their information governance systems in compliance
with a common architecture and associated interoperability specifications. These
specifications cover not only the technical compatibility, but should also ensure semantic
interoperability in order to preserve the meaning of the electronic information exchanged.
The benefits of interoperability are clearly recognised in the strategies of the major cities. For
instance, the city of Helsinki information technology programme 2012-2014 states that
59 (127)
interoperability of information systems will be promoted by deployment of open standards
that define conformity of information content and technical interfaces. Interoperability will also
be advanced by developing and applying a uniform enterprise architecture. Open interfaces
will be developed with existing systems and by requiring open and documented interfaces in
systems procured.
5.1.2
Means to promote interoperability
Against the backdrop of the diverse smart city objectives, how can cities then promote the
emergence of interoperability? In this study, multiple roles have been identified through
which cities can influence the development of interoperable smart urban solutions.
An important activity is joint standardisation by multiple cities, to enable the creation of
interoperable solutions and service models that are easy to diffuse. The most advanced
example is the development of KuntaGML, which is a Finnish standard for semantic
representation of town plans and base maps, based on the international GML standard. On
the basis of this standard, municipalities have jointly produced interfaces for electronic
services in the technical and environmental domain. Through these interface applications,
permits and feedback can be submitted electronically. Information delivered in standard
formats enables retrieval of the submitted data by central government agencies and
authorised companies directly from the interface service. This improves the productivity of
public administration services. It also permits flexible utilisation of that data in various
complementary services. For instance, electronic submission of construction permits
produces data that can be directly entered in 3D city information models and thus provide a
building block for a range of new value-added services.
A city can have a direct influence on the markets when it is itself the user of smart solutions.
In these cases, the city administration procures an information system or service based on
ICT. As a buyer, the city government has the authority to set requirements for the purchased
solution. Interoperability can be one particular requirement that is specified in tendering.
However, cities do not currently have established definitions and procedures in place for
setting clear requirements for interoperability.
At the central government level, there are efforts to implement a common architecture, which
lays down the key principles to be applied. While the deployment of the common architecture
has been stipulated by the law on information management39, it is not yet obligatory for
39
The Act on Information Management Governance in Public Administration (634/2011).
60 (127)
municipalities. According to the law, every public administration agency must plan and
specify its enterprise architecture to comply with the common architecture. This common
architecture contains lists of recommended standards, interoperability specifications, and
architecture principles that promote openness. These materials should all be uploaded and
made available for users in a national portal for open data40.
In some specific application areas, there are regulations in place that oblige cities and other
municipalities to follow particular European standards. The most influential is location-based
services, which must follow the scheme laid down in European law41. In most cases, making
reference to international or European standards is voluntary and based on local discretion.
This has resulted in a very fragmented landscape of requirements implemented in various
procurements made by cities and other municipalities.
In many cases, it is not necessary for cities to actively seek the development of municipalityspecific standards, but rather to deploy available open standards. For instance, the
government of the United States has set a priority that the government should always aim to
deploy industry standards based on voluntary agreement, not government-specific
standards, in order to promote the development of private product markets (Guijarro 2009).
Another closely related but more indirect manner in which a city can influence the emergence
of interoperable solutions is through service and work contracts. These are procurements in
which the city does not acquire any IT as such, but contracts out service work. In Finland,
cities contract out an increasing number of services, including a variety of technical
maintenance work for city infrastructure, administrative support services, and increasingly
also welfare services such as social and health care. As service productivity is, to a large
degree, driven by effective deployment of information and communication technology, the
city has an interest in promoting the adoption of digitalisation in contracted out services. Very
often, services provided by a private service vendor are linked with a larger service provision
system whose effective operation requires seamless exchange of information between
distinct organisations. The city information systems, and data maintained by central
government and other companies in the value chain must communicate effectively. The city
thus has an interest in promoting interoperability of the information solutions used in the
service provision system. For instance, waste collection contracts may include requirements
40
www.opendata.fi
41
INSPIRE Directive.
61 (127)
for the deployment of solutions for data collection and transmission by means of interfaces
that enable interoperability.
While city governments are likely to account for a significant proportion of total demand for
smart solutions, it is evident that there are lots of smart urban solutions for which the user is
a consumer or a private corporation. In the case of private demand, the role of city
governments is to act as a catalyser and enabler, rather than as a user itself. A very
promising way for cities to act as catalysts for private sector innovation – both commercial as
well as civic innovation – is to provide open public data. With rather modest additional costs,
data can be made available for various actors, to be exploited. In economic terms, this
enables extensive exploitation of the common good character of information and the creation
of positive externalities (David & Greenstein 1990). In other words, information can be used
multiple times with no or very little additional cost. This makes it very different from most
tangible goods, whose use by one person limits its availability for others to use. Several cities
in Finland have taken a progressive role in opening public data. The city of Helsinki has
received international recognition for being at the forefront. Other major cities, such as
Tampere and Oulu, are following suit.
The experiences so far indicate that while open public data receives a lot of public attention,
it has not been very easy to make a viable business from simply exploiting public data.
Rather, the commercial value might often be found only when public data is combined with
various types of other data, such as customer-specific data. Various kinds of legal issues
then emerge related to privacy, intellectual property, and data security. Nevertheless, the
deployment of open standards and the provision of data through specified interfaces are
needed to build scalable business models.
One particularly interesting activity related to open public data has been the active
engagement of the city of Helsinki in the CitySDK project.42 The CitySDK has defined a
harmonised approach between several European cities to creating open data and
programming interfaces for urban data. The CitySDK approach is currently being deployed in
other major cities in Finland through the 6AIKA programme.
Another manner in which cities can influence the evolution of smart services towards
interoperability is through facilitation of piloting, testing, and demonstration environments. In
addition to providing the physical environments for innovation, cities can contribute by
encouraging the creation of digital testing environments. By designating a specific municipal
42
www.citysdk.eu
62 (127)
service production process or site (e.g. street maintenance, elderly care service house) as a
testbed for piloting, it can build preconditions for interoperability. The preference should be to
provide an open playing field for various firms and to encourage deployment of open
standards. In practice, the current funding arrangements do not specifically promote
interoperability. The companies are the preferred direct recipients of innovation funding,
which creates incentives for the development of closed proprietary solutions. Without an
external actor setting interoperability requirements, companies have little incentive to aim for
interoperability for other than internal purposes. An example could be to set requirements in
land use contracts and urban planning. For instance, the city of Helsinki has set
requirements for installing energy metering solutions in new constructions in the Kalasatama
district. As, in this case, the land is originally owned by the city, it allows it to set binding
contract requirements for real-estate development in the district.
Finally, there is the traditional role for the cities in promoting innovation activities in urban
areas. This can involve the identification and articulation of user needs, mobilisation of
financing, spearheading collaborative R&D projects, mobilising users for testing, facilitating
collection of user feedback, and contributing to marketing and liaison with international
partners. Various sources of funding are currently available from national innovation funding
(e.g. Tekes Witty City programme, Smart Procurement Programme), European innovation
funding (H2020 smart city calls, EIP Smart Cities and Communities), and European regional
funding (e.g. 6AIKA programme earmarked for the six largest cities in Finland).
5.1.3
Conclusions
To conclude the analysis presented above, it was observed that cities do have significant
potential leverage in influencing the interoperability of smart city services. The opportunities
are probably highest in areas where a city can use its purchasing power to set requirements
for the supplier markets. Combined with collaborative activities aimed at agreeing and
deploying open standards and the provision of data through machine-readable formats and
functional programming interfaces, the procurement mechanism can have an impact. At the
strategic level, several cities have a pronounced target of favouring solutions based on open
interfaces and multi-vendor solutions. However, these goals have not been implemented in
practice. So far, systematic methods of promoting the emergence of multi-vendor solutions
through procurement were not identified.
The hurdles are partly related to the perceived rigidity of the public procurement framework.
On the other hand, this originates from a lack of examples, legally tested best practices, and
the novelty of the idea that procurement can play a major role in promoting interoperability.
63 (127)
The tender evaluation stage is particularly problematic: the procurement law requires that
proposals are assessed in a manner that is based on transparent criteria and relies on
documented evidence. These criteria are currently missing. There is a lack of widely
accepted definitions of interoperability that would be robust enough to be used in the tender
evaluation. Without accepted definitions, it is challenging to use interoperability as a
procurement requirement because proposals must be unequivocally assessed on the basis
of it. The novelty of the issue is also reflected in the current lack of understanding about how
various procurement approaches can drive or hinder the emergence of interoperable smart
city solutions.
5.2
Business environment
The domestic smart city business environment contains a wide range of actors supplying
what can be considered as early generation smart city solutions. The business environment
ranges from companies that have roots in the public sector (such as Tieto and CGI) to large
international businesses that have, in many cases, expanded into the Finnish market by
acquiring local businesses, and from small SMEs to individual developers. The smart city
business environment also spans many sectors, with some companies dedicated to serving
a single sector and others taking a more horizontal perspective and serving many sectors.
Furthermore, on the demand side, many organisations procuring smart city solutions are in
fact companies, for example operating services that were formerly run by the public sector,
such as operating public transportation buses. Private entities such as associations or cooperative societies (osuuskunta), individual households, and end-users are also an important
element of smart cities.
The degree to which ICT is utilised varies. Companies in some sectors are rather advanced
in the utilisation of ICT (e.g. they have deployed a large base of sensors and use real-time
information to provide services), while others are still in very early stages (e.g. the relevant
information is manually collected and stored, and rarely shared with other organisations). In
the following, we make some general observations related to the smart city business
environment in Finland, and then go on to describe key actor groups.
5.2.1
Generic description of the current state
Roughly put, the general observation is that the current business environment around smart
cities is, in fact, fragmented. In particular, large companies supplying the systems, which
have had an incumbent position in the market for a long time, tend to pursue a strategy that
increases customer lock-in and to provide vertically integrated solutions. As it relates to more
64 (127)
open strategies, usually the challengers, meaning companies that are new entrants to the
market and growing (e.g. SMEs) or companies that are entering the market from another
sector, are more open to competition and to using open standards.
A common problem from the supplier perspective is that even though the needs (e.g. from
the cities) are essentially very similar, supplying companies have to build tailored solutions
for different cities and organisations procuring the systems. This leads to limited replicability
and economies of scale and to a situation where larger markets with modular product
offerings do not emerge. When it is difficult for businesses to scale solutions across cities,
and when a larger market potential does not exist, willingness to invest in new products
becomes low and the business models are reduced to providing tailored solutions directly
funded by the procuring organisation. In these cases, the pricing of solution delivery is likely
to be based on the suppliers’ work costs related to developing and implementing the solution.
In contrast, in a market with scalable solutions based on open standards, the pricing can
more dynamically reflect the expected value of future business opportunities, giving an
incentive for the firm to consider development costs partly as investments in innovation.
The vendor lock-in problem is also caused, in many cases, by the fact that the organisations
procuring the systems have very different processes (although the basic service that they
provide is very similar) and do not co-ordinate much. Thus, the fragmented market structure
is not caused purely by the supplying organisations but also by the fact that procurement is
conducted in an isolated manner. Local suppliers are often favoured, and the entities
procuring the systems do not generally collaborate with each other. The related processes,
operation, and business models need to be harmonised at least to some degree in order for
a larger market to emerge. System life-cycles and development cycles are also different.
Although, in principle, harmonisation and the use of common standards is also beneficial for
supplying companies, the perceived costs of harmonisation and interoperability can seem
higher than the benefits attained, because large investments are required to implement the
standards and undergo compliance and certification testing. Thus, a critical mass of actors
(both buyers and suppliers) is needed, who commit to using the same interfaces in order for
the market to start growing and for these investments to become profitable from a business
perspective. Many companies have indicated that some external resources (e.g. from the
cities or public funding agencies like Tekes) would be needed to share the risk related to
these investments.
65 (127)
Current approaches
Overall, currently, the following four ways to increase interoperability and tackle
fragmentation of systems can be identified:
1. Joint procurement of a common closed solution (e.g. Waltti, Apotti),
2. Development of fully open source solutions (e.g. HRT Open navigator),
3. Platform strategy and opening of APIs for external parties (e.g. Solita Lupapiste), and
4. The creation of a multi-vendor environment (e.g. Medcom, mobile networks)
When cities and other public actors start to collaborate, it can often lead to joint procurement.
The advantage of joint procurement is that the implementation of the system can be
centralised to one actor and that economies of scale can be utilised. For example, the new
national ticketing system, Waltti, is implemented as joint procurement. However, when
looking at the broader group of companies that could contribute, it heavily favours the larger
companies, and naturally the one that gets to provide the system, and is challenging in terms
of market creation, especially for smaller actors. It can also lead to an even heavier vendor
lock-in than local solutions.
One way to tackle fragmentation and vendor lock-in that is gaining popularity is for the
procurement organisations to develop the systems using open source solutions, meaning
that they buy the workforce to develop the solution but maintain control of the source code
and, in many cases, release it openly for others to use. For example, Helsinki Region
Transport (HRT) has decided to utilise a fully open source approach in building the next
version of its official journey planner, and plans to share the source code publicly so that
other actors can use it and tailor services for specific needs43. Although this increases the
openness of the solutions and provides new business opportunities, especially for companies
providing the workforce44, it is challenging for companies that are pursuing a proprietary
product strategy with open interfaces and reduces their willingness to invest in new product
development. There has been much debate about the degree to which these kinds of open
source solutions should be used by the public sector, and whether both approaches could be
used in parallel, so that final systems could be a combination of open source solutions and
proprietary products with open and standardized interfaces.
43
http://liikennelabra.fi/avoin-reittiopas-ottaa-askeleen-eteenpain/
44
Companies such as Codento and Vincent.
66 (127)
Instead of the traditional approach of vertical integration, some companies are pursuing a
more horizontal approach with a so-called platform strategy (Gawer and Cusumano 2008;
Eisenmann et al. 2006), where they mediate the interaction between different actor groups
and try to become a gatekeeper actor at that specific point of the value chain45. Solita is, for
example, pursuing this strategy with its Lupapiste.fi service and connects municipalities and
citizens that want to apply for building permits. The platform business model strategy is often
complemented with APIs that the platform provider can open for different actors around the
platform (e.g. developers) to create complementary and tailored services. The platform
business model strategy typically utilises the open internet and is thus highly scalable. The
challenge is that the platforms themselves are usually closed and cannot be interconnected
to other platforms, thus in many cases leading to a winner-takes-it-all phenomenon in which
one platform can gain market dominance (even on a global level). When platform providers
operating in the same sector open APIs they also tend to do it in an ad-hoc non-harmonised
manner, meaning that a given developer needs to make a tailored version of the application
for each platform.
In some sectors, the business environment has evolved into a multi-vendor environment that
features a mix of companies all providing a horizontal product offering with open and
standardised interfaces in which product compliance is also ensured with testing and
certification. Evolution towards such a multi-vendor environment requires collaboration on the
buyer side but also on the supplier side. Examples of established multi-vendor environments
are the market around health care systems in Denmark, which features a group of buyers
(i.e. hospital districts) and software vendors, and also the global ecosystem around mobile
networks, in which national mobile operators procure and mobile network vendors supply the
systems in a modular manner. A multi-vendor environment can be seen as a combination of
closed and open approaches, meaning that it is beneficial both for the buyer, since they are
not locked into one vendor but have a large selection of interoperable products, and for the
vendors, which are able to pursue a scalable strategy and compete with proprietary offerings.
Even though multi-vendor environments on this scale do not exist in the Finnish smart city
market, there are some examples of similar evolution paths. For example, the KuntaGML
development activity46 driven by the Association of Finnish Local and Regional Authorities
(Kuntaliitto) has had these elements. An important ingredient when establishing a multi-
45
For example, the highly popular Uber, which connects users in need of transportation with drivers of vehicles.
46
http://www.kunnat.net/fi/asiantuntijapalvelut/mal/verkko-oppaat/paikkatiedon-opas/hankkeet/kunta-
gml/Sivut/default.aspx
67 (127)
vendor environment is to create mechanisms for the vendors to ensure the interoperability of
their solutions. Commonly, companies use open standardised interfaces but interpret and
implement them differently. When products do not work as “plug-and-play”, separate
integration and testing is needed. In the Finnish smart city sector, interoperability certification
testing and certification procedures do not exist.
5.2.2
Key actors
When looking at the different smart city business actors, one way to categorise them is to
use a simplified smart city value chain similar to the smart city layer model described earlier,
in section 3, where four steps can be defined: 1) sensors and controllers, instrumented to the
physical objects in the city environment; 2) connectivity, used to transmit information from the
sensors to back-end IT-systems; 3) IT systems, which process the information; and 4)
services, meaning the service providers. Figure 10 presents some key actors in the Finnish
smart space mapped to these four steps47.
Figure 10. Simplified smart city value chain with some example actors.
47
Although here depicted in particular steps, many of these actors (e.g. Siemens) are vertically integrated and
provide products, solutions, and services that go across the different steps.
68 (127)
In the following, we give an overview of key actor groups in the smart city business
environment and discuss especially the companies that have a horizontal business model
and serve many sectors. Actors dedicated to different sectors (e.g. mobility, built
environment, and energy and cleantech) are discussed in more detail in the example cases
in 6.
5.2.2.1
Companies and other entities running physical services and procuring smart city
systems
When looking at the different smart city sectors, an observation can be made that, on the
demand side, many of the organisations running the physical services and procuring the ICT
systems are in fact private companies and not part of the public sector48. Many services that
have been formerly organised solely by the city are now often operated by private companies
on behalf of the city. Many services in a city environment (such as taxis, construction etc.)
that have a strong public interest, are also provided by companies but are regulated by the
city (e.g. with building permits or city planning) or another public actor (e.g. taxi permits are
given by Centres for Economic Development, Transport and the Environment).
A recent example of private companies gaining a larger role in providing public services in
Finland is the growing trend of utilisation of private bus operators in local public
transportation. When these bus operators procure, for example, fleet management systems,
they are typically not compatible with one another. The same applies in principle to building
facility management systems, which are typically vertically integrated. Thus, the public
organisations responsible for organising or regulating the service could impose some
guidelines in order to enhance the interoperability of the systems.
5.2.2.2
Supplier companies with governmental and other local roots
Today, public organisations rarely develop solutions themselves, but largely procure them
from businesses. Two companies that have some background in being key public “in-house”
organisations are Tieto49 and CGI50 (formerly Logica). The roots of Tieto can be traced back
to the former State Computer Centre (Valtion tietokonekeskus), a government in-house
organisation that developed and operated government-level data systems. The roots of CGI
go back to companies such as Kunnallistieto Oy and KT-Tietokeskus, which served the
48
The degree to which smart city sectors are privatised varies considerably between countries and also
between Finnish cities.
49
http://www.tieto.fi/
50
http://www.cgi.fi/
69 (127)
Finnish municipalities in terms of their data systems. Partly due to legacy technology lock-in,
but also due to their large size, to this day, in many smart city sectors, these two actors are
still the market leaders.
Another key group in the smart city business environment are the mobile and
telecommunication operators providing connectivity. Of these, especially the three large
mobile operators - Sonera, Elisa, and DNA - have an important role. Sonera has evolved
from the government monopoly operator for long-distance fixed calls. Elisa (formerly
Radiolinja) has its roots in the local phone company Helsingin Puhelinyhdistys (HPY). The
roots of DNA come from the other local phone companies. The three operators already today
form a modular and horizontal market structure in which common technologies are used and
new services such as the common mobile ID solution (mobiilivarmenne) are introduced. The
operators also have a central association, the Finnish Federation for Communications and
Teleinformatics (FiCom).
5.2.2.3
Large international companies
Large international companies active in the smart city field also have some presence in
Finland. Many of these have a very wide scope in their offering and can provide cities with
complete smart city solutions and platforms that span the smart city sectors.
In terms of IT system providers, IBM51 is one of the most notable actors and has global smart
city leader status with offerings for several sectors. In addition, especially in terms of the
physical infrastructure, Siemens52 is also a large player (in Finland, Siemens has
collaborated closely e.g. with the City of Turku).
In general, local offices are often tightly controlled by their parent companies, which can limit
their ability to participate in open initiatives. Companies such as Fujitsu, HP, Oracle53,
Microsoft (CityNext)54, and Accenture have also shown interest in some domestic smart city
activities. Apple, Google, and Microsoft dominate the end-user services. In terms of
connectivity, the suppliers of mobile infrastructure are in a key role, especially Ericsson,
which has invested in the mobility and energy sector, but also Nokia Networks, because it is
51
52
http://www.ibm.com/smarterplanet/us/en/smarter_cities/overview/
http://www.siemens.com/innovation/en/home/pictures-of-the-future/digitalization-and-software/from-big-
data-to-smart-data-city-intelligence-platform.html
53
http://www.oracle.com/us/industries/public-sector/oracle-manage-smart-city-185081.pdf
54
http://www.microsoft.com/en-us/government/blogs/five-steps-to-developing-a-smart-city-
platform/default.aspx#fbid=kdc4li2ZFHw
70 (127)
a key domestic company. Cisco also has some activities in Finland. Vaisala is a strong
player, especially in terms of sensoring equipment in many of the smart city sectors. On an
international level, strong players that are not active in Finland include Hitachi and NEC.
5.2.2.4
SMEs
SMEs have usually been subcontractors to large organisations responsible for providing the
end solution to the city. In general, it has been difficult for the SMEs to enter new markets in
the public sector and to scale their business. Despite this, many growth-seeking domestic
SMEs exist. In terms of IT systems and system integration, notable companies that are
active in many smart city sectors are Solita, Comptel, Futurice, and SITO.
5.2.2.5
Developer communities
Open data, interfaces, and APIs (the so called API economy) have recently gained
popularity, with many companies successfully building scalable platform business models by
opening their system to third-party developers. Similarly, in the public sector, organisations
have started to open their systems. For example, Helsinki Loves Developers55 is a
community of developers writing apps for many smart city sectors in the Helsinki area. In
Finland, developers have been especially active in the mobility sector, such as in Helsinki
with the HRT developer community56 and in Tampere with ITS Factory57. Incentives for the
developers to write new applications have been provided, for example, through competitions
such as Apps4Finland58.
The strength of such an open approach is that it is very easy for developers to enter the
market and create new applications. It also provides the possibility for the emergence of new
and radical innovations that the slow and rigid large companies and public organisations
would not necessarily think of. The challenge for this approach is that it has been rather
difficult to generate viable business using open data. Another challenge is that, since APIs
are not opened in a harmonised manner, developers need to tailor services for each
city/organisation. Projects such as CitySDK59 have tried create harmonised APIs. So-called
55
http://dev.hel.fi/
56
http://dev.hsl.fi/
57
http://wiki.itsfactory.fi/index.php/ITS_Factory_Developer_Wiki
58
http://www.apps4finland.fi/apps4finland-competition/
59
http://www.citysdk.eu/
71 (127)
“Platform as a Service” (PaaS) offerings (e.g. Bluemix60 from IBM) could also collect API
catalogues for developers.
5.3
ICT systems
Several definitions of smart city concepts emphasise the use of information and
communication technologies (ICT) to enhance the quality and performance of urban
services, to reduce costs and resource consumption, and to enhance the flow of ideas
among people and between citizens and decision-makers. Investments in these ICT systems
supporting smarter city services are pretty long term - the lifetime of an organisational ICT
system has been estimated to be about 10 years, but this count is decreasing due to fast
changes in technologies and the operational environment.
The life-cycle of an ICT system contains several phases, from design to deployment
(operation and maintenance), and finally the system is abandoned and replaced with a new
one. The cost structure of a normal ICT investment is hard to estimate exactly, but the
following numbers are expressed (Figure 11):

Purchasing of the ICT system is only 5-10% of the total life-cycle costs.

Development of the system takes about 20-40% of the total costs.

The rest (50-75%) are operational costs (maintenance etc.).
This cost distribution seems to be in line with studies concerning complicated military
systems, where operations and maintenance take about 65-75% of total expenses.
60
http://www.ibm.com/cloud-computing/bluemix/
72 (127)
Figure 11. Distribution of software system life-cycle costs (Source: Schach 2002).
Systems supporting public organisations and e-governance are often very challenging to
build due to the wide variation of operational needs and a large user base. The risks of
development in such a system are well known. A study of 5,400 large-scale IT projects
(projects with initial budgets greater than $15M) found that (Bloch 2012):

17% of these projects went so badly that they could threaten the very existence of the
company.

On average, large IT projects run 45% over budget and 7% over time, while
delivering 56% less value than predicted.

The biggest barriers to success are listed as people factors: changing mind-sets and
attitudes (58% of responses) and corporate culture (49%).
Another interview with 600 people involved in software development projects indicated that
even at the start of a project, many people expect their projects to fail. “Due to a lack of
business objectives, out-of-sync stakeholders, and excessive rework”, 75% of project
participants lack the confidence that their projects will succeed.
A recent example of a poorly managed ICT project was the Finnish Government’s Vitjasystem (Viranomaistietojärjestelmä), which aimed to integrate and replace several existing
systems in the police, the Finnish Boarder Guard, customs, the Ministry of Justice, and
defence force operations. System development was started in 2009 and cancelled in 2014
due to a lack of progress. The provider of Vitja (Tieto Oy) was forced to pay €7.5m in
73 (127)
sanctions when the contract was cancelled. The Finnish deputy ombudsman criticised the
project for being “too broad and multi-dimensional for one time execution”, commenting that
“the project should have been spilt in several smaller pieces from the beginning, which as of
now has been done”.
The additional costs caused by weak-performing system are not included in the estimation of
ICT investment operational costs. A recent study (THL 2014) (sample N=2400), by the
Finnish Institute of Occupational Health and the Aalto University, among Finnish workers
using ICT in daily activities indicated that 65% of them lost, on average, 4 hours a week (over
10%) of their working hours due to inefficiencies in ICT systems. These usability issues alone
cause 12 million euro losses yearly for these 2400 workers. When extending this calculation
to concern all government employees using ICT systems (78 000 employees, 70% of which
have a university degrees and most probably use ICT every working day), the annual losses
might be 250 million euros or even more.
These facts and examples show that most of the decisions related to ICT investments that
later turn out to be the most costly ones are made in the early phases of system
development, such as during the procurement process. In the next chapters, we analyse the
problems related to these public ICT procurements and how system-level interoperability
might help to tackle some of the identified issues.
5.3.1
ICT interoperability
ICT interoperability in the context of smart cities and public procurement of ICT systems is
associated with the technical interoperability of computerised systems, such as
hardware/software components, systems, and platforms to enable machine-to-machine
communication. Technical interoperability, according to the EIF, also covers the technical
issues of linking computer systems and services, and includes aspects such as open
interfaces, interconnection services, data integration and middleware, data presentation and
exchange, accessibility, and security services
In addition to technical interoperability centred on infrastructure and protocols, ETSI has
proposed the term “syntactical interoperability” associated with data formats, such as
messages transferred by communication protocols that need to have well-defined syntax and
encoding. Protocols carrying data or content can be represented using high-level transfer
syntaxes such as HTML, XML, or ASN.1.
74 (127)
The basic problem with ICT interoperability is that systems are often designed and
implemented before there is a recognised need for them to interoperate. Planned
interoperability is more cost-effective than ad-hoc interoperability, since retrofitting
interoperability is both difficult and time consuming. Unfortunately, taking interoperability into
account beforehand is often seen as an extra cost for ICT investments, due to the nature of
“local optimization”, which means solely focusing on solving “current problems” without taking
into account needs for the future. Of course, such future needs are hard to predict, but
usually investments based on (de facto) standards technologies have far more longevity than
proprietary solutions. Another obstacle for ICT interoperability is not a technology per se, but
strategic, organisational, and human challenges are usually more difficult to master than
technical aspects.
ICT interoperability in general has several benefits, like:

Increased flexibility, by enabling systems to be “mixed and matched”. This ability to
“mix and match”, usually based on standardisation, enables users to perform
unforeseen tasks that require new combinations of existing functions.

Interoperability facilitates the creation of new capabilities, by composing new
functions out of existing ones; interoperability can reduce the cost of creating new
capabilities by enabling existing systems to be reused in multiple ways for new
purposes.

Reuse increases cost-effectiveness, by enabling the reuse of existing systems and
capabilities; also by combining interoperable components in different ways, system
providers can produce multiple products, each of which can be sold separately. For
example, the services in SOA are typically designed as reusable, interoperable
components rather than as stand-alone systems in their own right.

Interoperability creates loosely coupled systems that are easier to use. Today’s ICT
systems (take, for example, cloud-based web applications) are provided by a mix of
solutions blending open source and proprietary software and hardware from multiple
vendors.
The term technical ‘interoperability’ refers to the combination of systems that are not fully
integrated. Interoperability is more flexible and potentially more scalable than integration,
even though it rarely achieves the same degree of seamlessness.
The drawbacks are that interoperability may compromise privacy and security, and it
inevitably increases establishment costs by adding technical complexity to system design.
75 (127)
Personal information previously kept in separate silos makes it more challenging to collect
and combine data from different sources for profiling, whereas interoperable systems ease
this interlinking task considerably. This enhanced linking opportunity might be an advantage
for purposes of commerce, the authorities, and law enforcement, but poses an increased
threat to privacy. Interoperability may also compromise security, making the whole system
only as secure as its least secure interoperating component. The same applies to reliability,
as interoperability adds technical complexity to system, since it imposes new requirements
on a system design and chains several systems, making the whole system reliability
dependent on each separate subsystem.
Considering physical system architectures, the interoperability of a collection of interoperable
systems depends on the architecture of each individual system. The interoperable Service
Oriented Architecture (SOA) paradigm relies on an open-ended set of discoverable,
autonomous, and interoperable services, each of which performs a distinct function, and
which can be combined and invoked to perform a wide range of business processes. The
services provided by SOA are relatively coarse-grained in the sense that they provide fairly
significant packages of capabilities, as opposed to fine-grained individual functions peculiar
to fully integrated systems.
Switching costs
As stated, designing interoperability into a system is generally more effective, since
interoperability must be implemented pervasively throughout a system in order to be
effective. The obstacle of reaching this goal is dependence on existing systems and the
tendency to cause future ICT procurements to be based on the restrictions of these legacy
systems. One aim of the InterCity project is to increase the power of buyers and to decrease
the interdependence of buyer-seller relationships by promoting interoperability and the use of
standards. The goal is to avoid the tendency towards vendor locking partially caused by high
switching costs.
Switching costs can be defined as costs associated with the process of switching from one
supplier to another. These costs can be, for example, search costs for a new provider,
learning costs for a new purchase, cognitive effort, emotional costs, equipment costs,
installation and start-up costs, financial risk, psychological risk, and social risk.
From the supplier viewpoint, switching costs are incremental expenditures, inconveniences,
and risks incurred when a customer changes from one supplier to another. These costs exist
to various degrees when an organisation switches suppliers. For example, when the
76 (127)
organisation switches from using an existing computer equipment provider to a new one, the
change can introduce many time-consuming and costly activities, as well as personal strain.
At the highest level, two types of switching costs can be distinguished (Harris, 2010):

Inherent switching costs are due to the nature of the product(s) or the market.

Strategic switching costs reflect choices made by firms designed to create switching
costs or to increase them above their inherent level.
From the suppliers’ perspective, two different approaches could be selected, either
increasing switching costs or decreasing them. Increasing switching cost enables a supplier
to raise prices (and profits) to a certain point without a fear of losing customers. On the other
hand, decreasing switching costs can expand markets by attracting customers that (for
example, via standardization) can “mix and match” various providers’ supplies.
From the customer viewpoint, common types of switching costs are:

Procedural — the new system requires users to learn new routines, to reconfigure the
system, and to re-establish communication networks with other users. This causes a
loss of time and requires effort for training, might cause service interruptions
(disruptions risks), and needs troubleshooting.

Financial — there is the cost of moving parts or changing tools from the incumbent
supplier to the new supplier. This might cause a loss of money, but often the new
supplier tries to compensate for this by offering a discount or by providing some free
support, like training.

Relational — because people tend to resist change, there will also be reluctance to
adapting to new routines. This is an unquantifiable cost that requires the estimator’s
best judgment.

Compatibility – in some cases, the decision to purchase one product locks buyers into
follow-on situations where the first decision limits the second related alternatives.
Chen and Hitt (Chen 2005), who have studied ICT and switching costs, note that informationintensive markets have several unique features. One of the remarks was that informationintensive products have significant compatibility issues causing high switching costs, but
these interoperability issues have also led to strong trends towards standardisation that
enables customers to mix and match products from different vendors (reducing switching
costs). In the following chapters, the current state of ICT procurement in the public sector,
77 (127)
related switching costs, and efforts towards interoperability by adhering to common
standards are more closely examined.
5.3.2
Generic description of the current state
5.3.2.1
Standard and interoperability ICT solutions at EU state level
Based on an EU Commission-funded study in 2011 (EU 2011), it is estimated that the total
value of ICT public procurement contracts in the 29 member countries was about €50.3
billion in 2011. The United Kingdom is leading with 26% of the total expenditure (€13.2
billion), followed by France (19%) and Germany (10%). The total value of ICT contracts is
lower than €1 billion in the vast majority of the other countries. The Finnish government’s
total ICT expenditure was 907.6 million euros in 2010 (Ministry of Finance, 2011).
Considering the whole of Europe, services contracts represent 60% of the ICT total contract
value, while 25% is spent on supplies. In Figure 12, the rough annual ICT procurement for
each member state is given.
78 (127)
Figure 12. ICT procurement in EU member states in 2011 (Source: EU 2011).
In 2012, the EU Commission funded a survey among European procuring authorities and
suppliers in all member countries to gain some understanding of how standards are taken
into account in public procurement tenders. The most active respondents in this study were
from Italy, the UK, Finland, and Spain. Based on 244 received responses from authorities
and 172 from suppliers, some relevant observations for our study could be highlighted (EU
2012).
The most important objectives for the majority of procuring authorities in every member state
are securing the project outcome and achieving value for money for ICT acquisitions.
Another extremely important goal is to maximise competition. Procurers whose aim is
competition were more likely to write open tenders using technology-neutral language than
procurers who did not consider competition as an important factor.
One obstacle to fair competition is that nearly 60% of suppliers consider that tenders either
always or often refer to very specific technology that only a few suppliers are able to provide,
and just over 50% of respondents reported that tenders either always or often refer to
proprietary technical specifications. Whether or not this is intentional, to exclude unwanted
suppliers’ offers, is not explained. There could be a way to restrict competition by:
79 (127)

Using brand names and proprietary technical specifications to identify products and
systems that only certain vendors or suppliers can provide.

Requirements for the new ICT purchase to be compatible with previously purchased
products or systems, which can favour the original suppliers and thus restrict
competition, while increasing the risk of a vendor lock-in.
A vendor lock-in is not considered to be an important issue among all public procurers. A
lock-in could be defined as a situation in which switching costs related to changing a provider
are high enough that buyers favour a current provider rather than switch to a new one whose
product is considered preferable. Some 35% of the study’s sample set complain that they
have had experience of being locked in to their existing ICT solutions and suppliers. The
main reasons for a lock-in are financial: it would be too costly to change supplier, as other
systems would also need to be adapted and change-related training among staff would also
be too costly. When a lock-in was admitted, the causes were (among those respondents who
noticed it as a problem):

Software (~30%): inability to transfer information to other types of software

Database systems (~22%): integration problems with systems developed by other
vendors

Customised bespoke solutions (~15%): transferring the specific technical knowledge
to other suppliers
When asking the same lock-in-related question among suppliers, more than 25% of
respondents were aware of evidence of a lock-in emerging in public sector ICT tenders, or
they felt that the tenders would serve to perpetuate an existing lock-in.
Lowering barriers to entry for SMEs as suppliers was not considered important by the
majority of public authorities. This is quite alarming, since aa European Parliament resolution
on public procurement emphasises the importance of SME access (so called Small …) to
public procurement and suggests several of ways in which access can be enabled by public
procurers and the European Commission. Some suppliers (18/172) consider that tendering
processes make participation by SMEs or new market entrants difficult, particularly the
inclusion of experience-related requirements (years in business, long delivery records,
trading volumes, etc.). Another strange finding among public authorities was that innovation
was not considered to be an important factor when purchasing ICT solutions.
80 (127)
5.3.2.2
Co-operation and ICT interoperability in the Finnish public sector
In addition to the Finnish government’s ICT expenditure (over 900 million euros in 2010),
municipalities are estimated to spend over 800 million euros on ICT-related investments
yearly. Expenses targeted at development are a modest 10%, whereas the rest (90%) is
caused by daily operations. The municipalities’ ICT employee count was around 5000
people, and payroll costs for them were over 210 million euros (in 2010). Municipalities are
currently using over 300 different information systems, which are nearly always provided by
commercial companies, although some efforts to use open source community-based
development around open data initiatives have emerged. The Finnish public sector ICT
markets are highly concentrated; the ten biggest ICT service providers dominate two thirds of
the market, and four of them produce nearly 50% of the services in use.
According to Finnish law, both ministries and communities have great independence and
autonomy on how to arrange ICT practices. There are three major laws that guide how ICTrelated procurements and services should be organised:

The law on public procurement (Public Contracts 348/2007) encourages joint
procurement but does not enforce that. Unfortunately, the lack of joint procurement
and co-operation in acquisition has usually led to purchasing non-interoperable
systems.

The Local Government Act 365/1995 (Kuntalaki 365/1995) regulates that a
municipality always has the responsibility for arranging certain services. Data
administration, for example, is an activity that a community cannot outsource.

The act on public sector IT management guidance (Information Technology Act
624/2011) enforces that a contracting entity is obligated to take interoperability of
information systems into account when arranging ICT services.
Information Technology Act
According to the Information Technology Act, interoperability means “interoperability in
technical and data content level when systems are handling information in common with
other public administration authorities’ data”. The interoperability model is based on open
interfaces (APIs) and requires both syntactic and semantic interoperability. The Finnish
Information Management Act, enacted in 2011, also requires that the public administration
must design and describe their “common architecture” to ensure interoperability of the
information services.
81 (127)
The goal of a common architecture is to identify the core functions in the organisation, and to
describe how the elements, organisation units, knowledge, stakeholders, processes, data
systems, and technology are connected and function as a whole. The aims are customer
orientation, sustainable development, and to make services more effective by offering
citizen-targeted electronic services. These electronic services are expected to increase
efficiency and provide economic benefits and convenience by offering easier access to
municipal services.
The common architecture is subdivided into four parts: business architecture, data
architecture, application architecture, and technical architecture. Business architecture
describes offered services, stakeholders, and processes. Data architecture describes the key
glossaries being used, the central information resources, and the relationship between
information categories and systems. Application architecture describes the content of the
information system portfolio. Technical architecture describes the technology portfolio,
reference architectures, and interfaces. In addition to these areas, data security and
integration are common elements for all those parts. The common architecture should also
support design methods for how to describe the public sector’s current ICT practices and set
up future objectives.
JHS recommendations
Despite the Information Technology Act and efforts towards ICT system interoperability,
neither the current law nor the requirement to produce a common architecture enforce any
practical procedures. The Finnish Council of State has an Advisory Committee on
Information Management in Public Administration (JUHTA) that has already announced
nearly 50 Public Administration Recommendations (JHS recommendations, information
management guidelines) in the form of a uniform procedure, definition, or instruction to be
used in public administration (both governmental and municipal). The JHS system aims to
improve the interoperability of information systems and the (semantic level) data compatibility
to facilitate cross-sector process development and to make use of existing data more
efficiently. The recommendations also try to minimise overlapping development work, guide
the development of information systems, and facilitate good common practices in public
administration. The Information Technology Act has an option to convert these JHS
recommendations to JHS standards that are legally more binding, but still today this
opportunity is not being used actively.
82 (127)
5.3.2.3
Common ICT problems in Finnish municipalities
The disintegration of ICT practices and the lack of co-operation is notable in the Finnish
public sector. Public ICT services can be arranged fairly autonomously despite the fact that
the regulation-based commitments are equal for all cities and municipalities, meaning that
co-operation and system interoperability are still mainly voluntary.
Recent studies
In 2013, the Helsinki metropolitan area audit office published a report that examined the
interoperability of ICT systems in the Finnish capital area. The conclusion of this study was
that the goal of regional interoperability is mostly set from the normative steering from the
national ICT (Information Technology Act 624/2011) and health care (Health Care Act)
regulations. Participatory co-operation and strategic planning among capital cities are
diminished: ICT interoperability was set as a goal in mid-2000, but since then references for
it in official documents have vanished. The lamentable conclusion is that the Finnish capital
area (Helsinki, Espoo, Vantaa, and Kauniainen) has no common objective for ICT cooperation, nor plans for system-level interoperability.
Since 2007, goals like service interoperability and commonly shared information systems
have been realised only occasionally, and procurements of such joint systems have been
very rare. Strategic co-operation has decreased and ICT interoperability has increased
slowly due to the fact that service joint operations have not been realised to the planned
extent. The reason behind these tendencies has been that the cities have not reached a
common view of administration accountabilities, and current contracts with ICT providers
have prohibited extending the use of ICT systems. For example, in education, several cities
use the same ICT system but different versions of it. Another explanation for these trends is
that city-level co-operation is devoted to specialist organisations like HRT (Helsinki Region
Transport, responsible for transportation), HSY (Helsinki Region Environmental Services
Authority, taking care of waste management and water), and HUS (the Hospital District of
Helsinki and Uusimaa, specialising in health care), which take care of procurements of joint
ICT investments.
The auditors concluded that avoiding overlapping expenses requires more active cooperation among cities so that the funding for investments can be used more efficiently and
system-level interoperability can be secured in the future. One special note was that in ICT
procurement processes, special attention should be given to open interfaces.
One of the key questions of the audit was how well ICT investment during recent years has
advanced system-level interoperability. This aim has not been the key focus recently, as the
83 (127)
biggest ICT investments are more targeted at supporting cities’ own service production and
not so much regional or national interoperability. The positive observation was that the whole
architecture model (e.g. the use of suggested JHS standards and open interfaces) is well
adopted in cities, and in that way the future capability for interoperability is likely ensured.
There is also successful co-operation in the capital area in fundamental services like basic
registries and location information use, and also voluntary co-operation in the form of open
data and open APIs around the Helsinki Region Infoshare, which has been nationally
remarkable and has also been noticed internationally.
A similar kind of auditing study concerning ICT service arrangement around the Turku area
was conducted in 2014. According to the final report, the lack of financial and human
resources is considered a very significant challenge in Turku area municipalities. Especially
smaller communities in that area do not have the abilities to invest in information
management nor participate in municipalities’ ICT co-operation planning. Resource
limitations cause skills deficiencies; the resources are not sufficient to maintain current skills
nor to develop the new capabilities needed to support adoption of the whole architecture
concept. Retirements also threaten to erode existing knowledge, since the hiring of new staff
is impossible. When resources are scarce, daily operations take the majority of working time,
and co-operation with others and development activities, including interoperability, are
neglected. Due to this, the benefits of ICT exploitation at municipal level are not fully realised.
The Turku region study also exposed that the whole ICT procurement field is unorganised
and a lack of co-operation leads to overlapping purchases. More than 50 different ICT
vendors are providing systems for this area’s municipalities. Especially in the health care and
education service areas, overlapping and non-interoperable systems dominate, and charging
for these systems is usually municipality based, making it a very profitable business for
system providers. This is a serious issue more generally, since arranging these services is
the biggest expense for municipalities in Finland, taking about 75% of the annual budget, on
average. From this 75%, service purchasing and investments (including ICT services and
system purchases) take about 35%.
Joint procurements
When a shortage of the necessary skills for acquisitions and a shortage of knowledge of the
whole architecture are evident, ICT system procurements are locally optimised, often with
highly customised proprietary solutions that lead to a risk of vendor lock-in. In addition, when
co-operation among municipalities’ procurement processes is faint, small communities have
very weak negotiation power and economies of scale are not realised. Even when co-
84 (127)
operation exists, the reason for that is not due to strategic planning, but rather the lack of
resources is more likely to force procurement co-operation.
On the other hand, when co-operation emerges, often the result is joint procurement, in
which the result could also be undesirable from the point of view of the open market,
interoperability, and avoiding vendor a lock-in. One of the representative examples of such
debatable outcomes is the Apotti program (a Finnish acronym from ”client and patient data
system services"), targeting improvement of the level of service for social welfare and health
care services in the HUS (the Hospital District of Helsinki and Uusimaa) operational area.
Another example used here is the public transportation system called Waltti.
The social welfare and health care services overlap in several areas, and the medical
records for clients and patients currently in use do not offer the necessary level of support for
these services. Currently in HUS, there are more than 200 different systems in use; ten of
those are more widely used, but they do not support daily practices as intended, and there is
an increasing need for real-time patient information due to the forthcoming patient
opportunity to freely select a health care unit within the HUS operational area.
One of the most important parts of the Apotti initiative is to purchase and adopt a client and
patient data system of high international quality. In addition to local governments, including
Helsinki, Vantaa, Kirkkonummi, and Kauniainen, a
municipally owned procurement
company, KL-Kuntahankinnat Oy, is responsible for the purchasing programme of the Apotti
initiative. For support for the actual acquisition process, a special Apotti procurement office
has been established, collecting specialist expertise from different sectors, including ICT, but
most of the employees are from the health care sector, without adequate ICT knowledge.
The estimated cost of the Apotti system is 585 million euros, and the whole Apotti
programme is valued to be worth 1.8 billion euros for the next 10 years. The system
procurement process is based on multi-stage negotiations, and in the summer of 2015, from
an initial dozen companies in 2013, only two companies finally submitted tenders: CGI Suomi
Oy and Epic Systems Corporation. One municipality, namely Espoo, also dropped out of the
purchasing programme.
It is notable that the Apotti system is going to be a monolithic, single-provider system that will
lock HUS into the system provided for the next decade (or more likely the next decades). The
parties responsible for the procurement of the Apotti system insist that the problem of
acquisition is that experts from the health care sectors are too over-employed to participate
in the system definition and design process, if a publicly proposed more open solution like
the development of a system from scratch, using Finnish ICT knowledge, is used instead.
85 (127)
Due to this lack of resources with health care expertise, it is more practical to purchase a
single proven system that only requires modest adaptation for local practices.
The second pretext for this monolithic acquisition is that the Apotti system is more like a
platform that opens up smaller ICT companies’ opportunities to offer system add-ons and
extensions for international markets. This latter claim becomes true only if the system
purchased has open interfaces for application developers. The openness of the health care
information system is questionable in general, according to a recent study (ONC 2015) by
the Office of the National Coordinator for Health Information Technology (ONC).
The ONC report, called the Report on Health Information Blocking, prepared for the US
Congress, concluded that “current economic and market conditions create business
incentives for some persons and entities to exercise control over electronic health
information in ways that unreasonably limit its availability and use. Most complaints of
information blocking are directed at health IT developers” (ONC 2015). By coincidence, the
most prominent candidate to be the Apotti system provider was the US-based Epic, which
was also selected to be the final provider despite the fact that the tender (384 million euros)
was more expensive than GCI’s (319 million euros). The provider selection was justified on
the grounds that the quality of Epic’s system was better than GCI’s, and the cost was only of
40% significance in the tender. The details of the purchase are beyond of scope of this study,
and the future interoperability and vendor-locking risks (for example, providing new
necessary open interfaces) are still impossible to estimate. At least in the requirements
sections, the Apotti system contains some documents for Apotti Open Service Interfaces for
third-party (so called AAP) development opportunities, in the form of short use cases (Apotti
Appendix B13).
Another example of a fairly similar outcome in municipality co-operation is a new
multiregional public transportation ticketing and payment system called Waltti. The aim of this
system is to enable an integrated public transport system in the more than 20 urban regions
outside the Finnish capital area, Helsinki. As a co-operative effort, a new procurement
company called TVV lippu- ja maksujärjestelmä (TVV ticket and payments system) was
established and jointly owned by the municipalities and the state. The aim of this company is
to procure, develop, and maintain the public transport competent authorities’ integrated
ticketing and payment system, in co-operation with both system suppliers and users. TVV
announced competitive bidding for the ICT system to support bus-based public transportation
ticketing and payment, and the winner of this bidding (Tieto Oy) was selected to provide a
monolithic system causing an evident risk of a vendor lock-in.
86 (127)
There have also been initial discussions about interoperation between the Helsinki capital
area public transportation ticketing system (HSL), the Turku regional ticketing system (Föli),
and Waltti, but as investment for each of these systems is long-term, interoperability issues
are not actual until the next decade (in the mid-2020s). Tieto is also providing a payment and
ticketing system for HSL (Helsinki Region Transport), so the possible interoperability issues
might be easily resolved, but the risk of forming a national monopoly in providing ticketing
and payment systems is extremely evident and might cause a serious vendor lock-in problem
in the future.
The observation given above of the joint procurement of ICT systems like Apotti and Waltti
does not try to underrate those achievements; both systems are or might be very successful
from the end-user’s point of view and will help their daily lives considerably. However, for
cities and municipalities, these investments may cause costly additional expenses later,
when systems need some (inevitable) modifications and only one possible provider is able to
perform those in a monopolistic market setting.
Despite these recent debatable results from municipal co-operation, there are also more
open market-oriented and interoperability-based examples that are studied more closely in
later chapters. Before examining those, some summary remarks related to current practices
are given.
5.3.2.4
Small conclusions
It seems, in general, that the role of procuring authorities in ICT system and service
procurement processes is representative; they act as intermediaries that try to mix and
match end-users’ (real customers’) needs and suppliers’ offerings. This is not always the
case, but larger organisations usually have some units or at least key persons whose
responsibilities are acquisition processes. These intermediaries could not completely
communicate user requirements in invitations to tender, and later systems acquired based on
these definitions might turn out to not respond to organisations’ and users’ real needs.
As already noted, procuring authorities try to minimise procurement risks by requiring
supplier references, years in business, long delivery records, and so on. This approach is not
selected solely to mitigate the end-users’ organisational risk, but also to minimise the
intermediary’s risks as well, in case the acquisition later turns out to be unsuccessful. It is a
known truth that no-one has been fired due to the use of big national or international
suppliers in procurement processes, even when the result of the acquisition process is far
from optimal. The lack of emphasis on innovation can also be explained by a reluctance to
take risks.
87 (127)
Based on the shallow study of Finnish public procurement registers’ invitations to tender, it
seems that procuring authorities often try to outsource some customer roles and
responsibilities to suppliers – the purchasing organisation does not exactly know their own
needs, real processes, and so on, that the ICT system to be acquired is expected to support.
The supplier is often assumed to provide mechanisms and knowledge for requirement
analysis, and also to take care of these instead of the customer. The reason for this is fairly
evident: the lack of financial and human resources devoted to procurement processes. This
is especially the case in smaller municipalities that already struggle with difficult financial
preconditions and decreasing staff. Even when the financial conditions are adequate, a
shortage of suitable expertise might hinder the ability to act according to the best possible
practices.
Public ICT procurement processes are also rigid; the use of more agile and stepwise
processes that require close co-operation with system providers are not well enabled by
current tender processes. The customer should be able to define extensive system
requirements in a very early phase of the acquisition process, using an old-fashioned
waterfall model, where nearly all import decisions are made during a request for tender
phase. When inevitable modifications to systems emerge, those might be costly to
implement. In some cases, the result might be totally unusable and not even deployable, as
in the case of the Vitja system (Viranomaistietojärjestelmä) explained in the introduction.
Recently, there have been some movements towards more explorative procurement
processes using stepwise approaches like utilising small-scale testbed projects before final
acquisition decisions.
Interoperability is not always considered to be a serious issue, since the long-term effects of
non-interoperability can be neither understood nor estimated correctly beforehand. Financial
losses for the coming years due to non-interoperable solutions are very hard to determine,
since changes in the operational environment are hard to predict. As already mentioned,
interoperability issues encountered later might not cause only costly technical changes, and
semantic and organisational interoperability problems in the form of information outages and
other inefficiencies are far more expensive.
There is no “silver bullet” to solve all these problems. To get real benefits from ICT,
organisational processes should be reconsidered (e.g. business process re-engineering) and
customer organisations should be fully committed to them. Even when agile, modular, and
interoperability-based approaches to ICT procurement processes are taken, system
integration might cause issues. Co-operation, exchanging and distributing experiences and
so on, can alleviate emerging issues considerably.
88 (127)
6. Example cases of existing and possible national activities
evolving towards a multi-actor environment
Next, we present examples from the three chosen key sectors where a shift from a vertically
integrated fragmented market to a horizontal and multi-actor market has happened, is
ongoing, or could be envisioned. Although modular multi-actor markets in the smart city
sectors do not really exist, many actors have shown strong willingness to move towards
more open interfaces and create a market with many buyers and many suppliers. In this
section, we give a short overview of the different example cases61. An overview of the
example cases is depicted in Figure 13 and they are described in more detail in a separate
report.
Built environment
Mobility
Common practices
for cities and other
public actors
Multi-actor
business
ecosystem
Modular
ICT-architecture
Real time traffic information
• Pre-commercial procurement
of real time traffic information
services in the cities of
Tampere and Helsinki
Mobility-as-a-service
• Seamless door-todoor service for
end-users
combining several
modes of
transportation
Digital urban environment
• Representation of land
use, infrastructure and
building information in a
common city model
Energy & Cleantech
Cleantech
• Smart water
management
• Smart waste
management
• Air quality monitoring
Building automation
• Control of buildings’
HVAC, lighting,
security and other
subsystems
Datahub
• Platform for
information
exchange of
energy
networks
MyData
• Framework for individuals and companies to be in control of their own data
X-road
• A national architecture facilitating information transfer between organisations and services
Figure 13. Example cases of existing and possible national activities evolving towards a
multi-actor environment.
In the field of mobility, we first examine the current state and evolution towards modular
multi-city, multi-vendor, real-time traffic information solutions. For mobility, we also examine
the emergence of Mobility-as-a-Service (MaaS), a multi-actor environment that provides
seamless door-to-door services for end-users by combining several modes of transportation.
61
Johanna Kallio, Janne Porkka, Tapani Ryynänen and Magnus Simons from VTT have also contributed to this
section.
89 (127)
As it relates to the built environment, we examine the current state of digital modelling of the
urban environment (i.e. geographic information systems (GIS), infrastructures, and buildings)
and the evolution towards a city model, which aims to aggregate all this information. For the
built environment, we also study the current state and evolution of building automation
systems.
As it relates to energy networks, we conduct a case study of a new platform called Datahub,
which is being created to enhance the information exchange of energy networks and create
new business opportunities for stakeholders, and to enable the emergence of a smart grid in
the Finnish market. For cleantech, the evolution towards smart water and waste
management systems is studied, and also the emergence of environmental measurement
platforms e.g. related to air quality. For horizontally enabling ICT platforms, we focus on
MyData, a new framework for individuals to be in control of their own data, and X-Road, a
national Data Exchange Layer that will be used to connect separate national-level systems.
To narrow the scope of the work, the case studies are conducted from different points of view
(with a focus e.g. on public procurement, business environment, or the technical level). The
examined cases also vary in terms of their maturity, meaning that some example cases and
sectors overall are more advanced in the utilisation of ICT (e.g. mobility and built
environment), whereas others are in the very early stages (e.g. water and waste
management). Furthermore, the cases differ in terms of scope, as in some a very specific
activity is analysed (e.g. Datahub in the energy sector), but in others the examination is
broader in scope (e.g. water and waste management).
6.1
Mobility
6.1.1
Real-time traffic information
In the traffic domain, there has been a movement towards collection of various types of
traffic-related data and utilisation of this information in decision-making. The latest trend is
provision of traffic data through standard interfaces in order to enable the production of
diverse types of services. Currently, there are parallel efforts taking place to promote the
creation of real-time traffic information to improve the situational awareness of transport
users and traffic managers.
The Finnish Transport Agency has thus far been the key actor providing real-time information
on road traffic, but recently large cities have also started corresponding development
activities for real-time traffic situational awareness services. The current vision is to create a
distributed situational awareness capability to provide diverse inputs for transport users. This
90 (127)
capability should emerge over time through the development of various interlinked services
utilising diverse sources of data, exploiting different technologies, and provided to a variety of
transport users and operators, both public and private. This will require collaboration and
interoperability to enable the transmission of data between various players.
The city of Tampere has, in June 2015, initiated a public procurement in which research and
development services are purchased from multiple vendors. The services to be developed
can relate to various types of traffic information, such as road transport, pedestrians and
cycling, weather and air quality, selection of traffic mode, traffic management, or forecasting.
In this tendering, the pre-commercial procurement (PCP) approach is used, in which multiple
firms are selected to undertake simultaneous product development in two consecutive
stages.
The city of Helsinki is undertaking similar activities. At the end of 2015, it is planning to carry
out the first pilots by launching a public procurement of innovative solutions. Plenty of traffic
data has also been opened for exploitation by the city as part of regional efforts within the
Helsinki Region Infoshare initiative (HRI), co-ordinating open data activities in the Helsinki
metropolitan region62. These developments link with another initiative, extending beyond the
transport domain into various city activities, which aims to create an open innovation
ecosystem for the development of urban digital services. This Open Helsinki Sandbox aims
to activate more actors to share their data in machine-readable formats, to mobilise
developers to exploit these data, and provide pilot environments for user testing. The
sandbox is also envisioned to provide the context for the development of traffic situation
awareness services.
In the aforementioned initiatives, interoperability is an explicitly stated goal. It is promoted by
the provision of open public data in standard formats. It is also pushed forward by the vision
of a marketplace of data, tools, and applications that are produced by a variety of firms and
public sector actors. The availability of traffic data standards (e.g. Datex II, SIRI) is an
enabling factor for the development of interoperable services, which also have the potential
to scale up to international markets. However, at this stage of the rather early development of
real-time traffic information services, alignment of national and regional developments has
only been started.
62
www.hri.fi
91 (127)
6.1.2
Mobility-as-a-Service (MaaS)
One flagship example of smart city development in the mobility sector is the evolution
towards the so-called Mobility-as-a-Service concept (MaaS) in Finland. The basic idea of
MaaS is to provide a seamless door-to-door service for end-users, combining several modes
of transportation (e.g. local and long-distance buses, trams, taxis, demand-responsive public
transportation, and shared private vehicles), and to serve it as one simple package for the
end-user63. In principle, this would mean that the end-user would, for example, not need to
have separate accounts and tools for each mode of transportation when planning their trips
and paying.
The evolution towards such a new paradigm is driven by many trends, such as urbanisation,
and by the fact that young people are not acquiring driving licences as often as before,
meaning that they do not necessarily want to own a vehicle but would instead like to have
access to a better supply of transport services. Another underlying factor is the accelerating
development and application of ICT technologies in the field of mobility. Vehicles are
increasingly being instrumented with positioning systems and mobile broadband connectivity
and linked to cloud services. Furthermore, end-users are more and more equipped with
smartphones and applications that provide access to different transport modes.
Over the years, there have been major advances in the utilisation of ICT by different
transportation providers. Journey planners have become commonly used tools for end-users
to organise their trips. Vehicles are also increasingly instrumented with locations sensors.
For example, in Tampere all buses and in Helsinki all trams and many of the buses are
equipped with a location tracker that, in principle, makes it possible for end-users to
dynamically alter their routes. Demand-responsive public transportation concepts have also
been developed, where the leading pilot at the moment is HRT’s Kutsuplus.
However, if one looks at the current systems deployed, it can be stated that the related ICT
solutions, which are the building blocks for MaaS, are heavily fragmented and tailored for
different transport modes and providers. Vertically integrated solutions with limited
interoperability are built for local public transportation, long-distance public transportation,
63
Heikkilä, Sonja, 2014. Mobility as a Service – A Proposal for Action for the Public Administration
Case Helsinki, Master’s Thesis, Aalto University.
https://aaltodoc.aalto.fi/bitstream/handle/123456789/13133/master_Heikkil%C3%A4_Sonja_2014.pdf?seque
nce=1
92 (127)
taxis, ride and vehicle sharing, and private vehicles. Most are also tailored to specific regions
and are not interoperable across cities.
The potential market for MaaS consists of a large group of stakeholders, ranging from actors
in the public sector responsible for legislation, regulation, and organising public services (e.g.
public transportation) to actors in the private sector such as transportation operators (e.g.
bus and taxi companies). A wide group of ICT solution providers also exists, ranging from
large IT companies (such as Tieto, CGI, and Accenture) that provide large IT systems, to
transport operators (e.g. related to ticketing), to SMEs providing systems, to taxi switching
centres (e.g. Semel and Mobisoft), and to individual software developers developing, for
example, mobile journey planner applications.
In order for the market to emerge, actors around MaaS need to introduce harmonised
interfaces to the systems currently tailored for different transport providers and working in
isolation. It is also essential that the business models (tariffs, charging models, etc.) of
different mobility providers are gradually harmonised.
Tekes, together with the Ministry of Transport and Communications, has taken a lead role in
enabling such a harmonised ecosystem. Tekes has launched a programme for developing
and piloting MaaS services offered to users by companies acting as personal ‘mobility
operators’64, and states that these solutions require open and harmonised interfaces to the
timetables, real-time location information, and payment systems of existing transport service
providers.
6.2
Built environment
6.2.1
Digital urban environment
Information about the urban environment, with different structures and infrastructures, can be
considered as a foundation of a smart city. Different kinds of data exist, such as geographic
information describing, for example, land use and city planning-related information, and
knowledge about constructed assets used by citizens in the community, including data on
buildings and other infrastructure, like streets, roads, and common areas such as parks.
Currently, the industry is in the middle of a digital revolution. There are applications used in
defining data in three main segments (land use, buildings, and infrastructure) to capture
various life-cycle phases. Altogether, plans are increasingly represented using model-based
64
https://www.tekes.fi/en/programmes-and-services/tekes-programmes/mobility-as-a-service/
93 (127)
tools that are capable of presenting data in 3D. For example, in the building industry, the
Building Information Model (BIM) has been progressively used by participants. A similar
interest in such models is apparent in land use and infrastructure design. In terms of
interoperability, the challenge lies in the communication between these three segments.
Inside the segments, interoperability has recently been developing towards the use of
commonly agreed open data exchange formats.
During last few decades, the rapid development of information technology has strongly
reformed city planning, the design of buildings, and the engineering of infrastructure. Major
development projects within the industry usually take a long time to proceed, even up to 25
years or more (Porkka et al. 2012). Currently, the industry is constantly struggling to unite
fragmented land use, building, and infrastructure data sources and databases. During recent
years, model-based applications, such as Building Information Modelling (BIM) and modelbased infrastructure planning tools, have been increasingly used in ICT systems for building
design, by architects, engineers, and planners, to escalate productivity.
Altogether, the current state of interoperability is challenging. First, the data in all three
segments, namely land use, buildings, and infrastructure, varies. This means that the ICT
systems in each segment are very different from each other, and therefore, information is not
shared between each segment. Second, the individual disciplines inside each segment also
have different ICT systems. For example, in building planning, disciplines like architectural
design, structural design, HVAC, and maintenance have separate ICT systems.
Each segment and discipline inside the segment has many products from different software
vendors, which usually have their own native data structure. Interoperability is usually
possible inside application families from the same vendor, but if you try to use software from
two vendors for exchanging information, it is currently likely that not all business-related data
can be exchanged. With open formats inside the segment, part of the data is, however,
transferable. Interoperability development in Finland has, over the past few years, been
promoting open formats. With open formats, the basic exchange of data works well, but not
all planning data is included in interaction with native formats.
For a long time, a hot topic in many Central European cities, and more recently also in
Finland, has been the city model. A city model means a digital representation of a built
environment, expressing terrain, sites, buildings, vegetation, infrastructure, and other
planned objects in the region. The model is suitable for virtual model representation, which
also includes parametric data about the content. It expresses spatial and geo-referenced
94 (127)
data about the current status. The data is normally expressed three-dimensionally, but for
certain purposes two-dimensional data is appropriate.
A key feature in the city model is a semantic data model, where the objects also contain
additional information. The usefulness of semantic models in many different industries makes
their preparation economically justified. The models can be used to create a wide range of
city-level analyses and simulations, like energy use planning and other environmental and
urban characteristics. It is possible to calculate noise and make air pollution forecasts,
shading reviews and lighting design, as well visibility analyses. The models are also available
for various safety analyses, such as analysis of flooding.
The recent development of open formats is also leading to standards that combine building
construction with cities and infrastructure. At the moment, CityGML, maintained by OGC, is
the format with the most potential as a city model. Large countries in Europe, such as
Germany and the Netherlands, have already been digitising their cities. Currently, the
challenge in Finland is a lack of supporting software, because only a few buildings and infra
sector planning applications encourage the use of CityGML. However, since the standard
has a similar data representation to major IFC clients, building owners have already started
to support it. For smart cities, CityGML is currently the most promising exchange format to
share city information and provide opportunities to make analyses and simulations.
One potentially interesting information source for the city model is electronic building permits.
Recently, for example, a service called Lupapiste.fi has been developed by Solita Ltd, in
cooperation with the Ministry of the Environment, to act as common platform for Finnish cities
and municipalities and provides a more flexible way to apply for electronic building permits.
6.2.2
Building automation
Building automation (BA) is the automatic centralised control of a building’s heating,
ventilation, and air-conditioning (HVAC) systems, lighting, security, and other subsystems,
through a single building control point. In the broadest sense, the concept of building
automation is similar to the concept of smart or intelligent buildings, which refers to fully
automated “digital” buildings targeting the demands of users while maintaining energy and
cost efficiency (Wong, Li, and Wang, 2005). Energy aspects are an especially important part
of building automation and will be a major driver in terms of related regulations and
legislation. Buildings consume approximately 40% of Finland's total energy consumption. A
95 (127)
building’s good energy efficiency reduces usage costs, and restrains the rise of housing
costs when energy prices are increasing.
Interoperability in building automation means that building automation components from
different manufacturers can seamlessly operate together. The interoperability between
different systems can only happen if they understand each other, which means sharing
information in a standardised way.
The building automation market is rather mature in Finland, as well as in Europe (Frost and
Sullivan, 2015). There are few actors that dominate the market, and it is not easy for new
actors to break through. On the supplier side, Fidelix, Siemens, and Schneider Electric
dominate the business for large buildings, as Ouman does for stand-alone small buildings.
The biggest demand-side actors are real-estate/housing companies, construction and office
management service companies, and different investors, such as pension insurance
companies or other venture capital investors.
Previously, building owners have been forced to choose between one of several proprietary
building automation manufacturers. The purchase of a new proprietary system was the
beginning of a long vendor–customer relationship, because the life-cycle of a typical building
automation system is around 15 years, and in Finland around 20 years. There are three open
communications protocols - BACnet, KNX, and LonWorks - but none of them has won the
market.
A typical building automation system can be broken into three levels: the field level, where
environmental data are collected and parameters for the environment are physically
controlled via sensors and actuators; the automation level, which encompasses the
automatic building control and monitoring functions; and the management level, where all the
information is gathered and decisions regarding management and monitoring are taken
either at local level (inside the building) or central level, in which multi-property control has
been centralised (cities, municipalities, service companies).
Generally, at field or automation level, there is no interoperability between different
manufacturers’ devices, except for the simplest valves. At management level, interoperability
is more common, and different building automation players have expressed their interest in
co-operation at this level. There are already solutions that can combine information from
several building automation systems at management level. It is quite common to use remote
control and monitoring via a web-based interface and cloud server to collect information from
different building automation (sub-)systems.
96 (127)
In a general case, gateways are used at all levels to handle the interconnection between
different building automation (sub-)systems or networks. There are commercial gateways
available, but in most cases the gateway must be tailored, and mapping different protocols
is extremely hard. For vendors, this kind of work is remarkably expensive. Technically, it is
not a problem to realise interoperability on the application layer of some software system.
The main challenge is in the integration effort that is required to support the different systems
and legacy protocols. There is no plug-and-play operation of systems made by different
manufacturers.
In Finland, procurement of a bigger building automation system typically happens via
tenders. An invitation for tenders might include only requirements, not specifications of the
system. Sometimes different vendors are used to supply the building automation systems for
different wings of a building or different buildings in a complex. This is particularly common if
the systems are installed at different times and under different contracts. From the
customer’s point of view, the easiest way is to purchase the entire system from one vendor
with no concern for interoperability. This is common when the old system needs only some
updates. Practically, changing the entire system rarely happens, because the life-cycle of
building automation systems is long, at approximately 15-20 years.
There is no co-operation between customers regarding the actual procurement of a building
automation system, but some of the biggest property owners and cities are co-operating in
pre-competitive joint projects. In addition, Senaatti properties and the City of Helsinki have
opened discussions aimed at an agreement to use one of the open communication protocols
(BACnet).
There are several associations that are working towards stakeholder co-operation and
interoperable building automation, such as Sähkö- ja teleurakoitsijoiden liitto STUL ry65,
Avoin automaatio, KNX Finland, Building Automation Forum in Finland (BAFF)
Asunto-, toimitila- ja rakennuttajaliitto RAKLI
67
66
, and
ry, which has developed data transfer
recommendations and a real-estate service data transfer standard called e-EHYT, enabling
interoperability of electronic service book applications (RAKLI, 2004).36
65
www.stul.fi/Home.aspx
66
www.automaatioseura.com/jaostot/rakennusautomaatio/esittely
67
www.automaatioseura.com/jaostot/rakennusautomaatio/esittely
97 (127)
6.3
Energy and cleantech
6.3.1
Energy case: Datahub
The energy industry is undergoing significant changes driven by the application of ICT
technologies. Renewables and sustainability have also had a strong impact both on
technology and business ecosystems, either directly or via political mechanisms. This
evolution requires the development of dynamic systems that are able to react and adjust to
changing energy demands. Currently, a new platform, called Datahub, is being created to
enhance the information exchange of energy networks, create new business opportunities for
stakeholders, and enable the emergence of a smart grid in the Finnish market. The
development is driven by Fingrid and the goal is to make information exchange in the
industry more effective, as well as to improve its quality and create new business
opportunities around Datahub's data content (Fingrid).
The Ministry of Employment and the Economy has stated that Datahub will promote retail
market competition and new service development. Datahub will also advance renewable
energy production and e-vehicle charging service provider business. Datahub will enable the
development of third-party services like energy efficiency services for those end-users willing
to provide access to their power consumption data.
Overall, data is of growing importance in the power market. It is valuable as a source of both
business intelligence and business in itself. Thus, the number of data-related solutions and
services is expected to increase when Datahub and similar systems provide the necessary
reliable data and channels of communication.
The Datahub project is also closely linked to similar evolution steps taken in other Nordic
countries (and Baltic countries), and can be seen as a continuation of the Nordic power
ecosystem and marketplace (NordPool). For the Nordic market, the interoperability of
national systems is vital, and common datahubs could be key enablers in the common
Nordic retail market.
Datahub is providing a platform that acts as a central standardised access point for all other
actors. Although the current datahub approach is not pushing industry into a more modular
approach, Datahub can have a big impact on services and service development by providing
one standard door for third-party service providers to access the market and connect with
customers and data.
98 (127)
6.3.2
Water management
Smart water management is an important part of the smart city concept. According to the
International Telecommunication Union (ITU), it can help cities to achieve three main goals:
1) coordinated water resource management and distribution, 2) enhanced environmental
protection, and 3) sustainable provision of public service and economic efforts. Smart water
management (SWM) stands for a set of water intelligence tools that use ICTs in optimising
the efficiency, effectiveness, and flexibility of water and wastewater infrastructure assets
(ITU-T 2014).
On a national level, water management is a complex task of managing water resources,
clean water supply, waste water, and drainage water. The main users of water are private
consumers and industry. Central actors supplying water are the municipal water utility
organisations, of which there are about 300 in Finland. The industry also has its own facilities
for water management. The water network consists of thousands of kilometres of water pipes
and hundreds of water plants and water purification plants, divided into local water networks
supporting local users. All this activity is supervised by the Centres for Economic
Development, Transport and the Environment, and by the health and environmental
protection authorities in the municipalities68. The Ministry of Agriculture and Forestry is
responsible for the execution of the public control and monitoring of water management in
Finland. A growing use of smart meters makes information collection increasingly efficient,
but so far the use of this information has not spread beyond the basic functions of water
supply management.
Although the application of ICT is still in the early stages, some development projects are
ongoing, and leading Finnish municipalities have been somewhat active in the smart water
area. Key actors are also aware of the need for interoperability and are, for example,
participating in some Nordic initiatives to find solutions.
One example is the Helsinki Region Environmental Services, HSY, Smart Water project.
HSY’s Smart Water (Älykäs Vesi) project aims at improving the resource efficiency of water
management in the region. New and innovative smart solutions are developed and tested in
the water supply and sewage disposal systems. An objective is to build tools for managing
the increasing amount of data in a modern water management system. The HSY project acts
as a platform for companies to test and demonstrate innovative solutions in pilot schemes69.
68
http://www.finlex.fi/fi/laki/alkup/2014/20140681
69
https://www.hsy.fi/repa/alykasvesi/Sivut/default.aspx
99 (127)
This enables HSY to learn about new technology and its benefits in practice. Integration of
information systems is a major concern in the HSY project, where a central objective is to
develop a generic data transfer system for communication between IT systems used in water
management. In this area, HSY is co-operating with the Danish DANVA programme. The
main objective is to create a multi-software architecture, where the end-user can use the
software tools most suitable for their specific needs70.
6.3.3
Waste management
Smart waste is part of the smart city concept. Focusing on municipal solid waste, Navigant
Research defines smart waste technology as the integration of advanced technologies into a
strategic solution that enhances sustainability, resource efficiency, and economic benefits.
The use of these technologies results in more integrated waste management offerings that
move beyond the traditional use of labour, diesel trucks, and open pits to discard waste.
According to Finnish waste legislation, municipalities are responsible for management of
domestic waste; for the urban waste produced by public administration, services, and the
education sector; and for the recovery and treatment of hazardous agricultural waste and
domestic waste. In addition, they also distribute information and offer guidance on waste
management71.
Waste
management
includes
monitoring,
collection,
transportation,
processing, and disposal or recycling of waste material. Although these are the responsibility
of the municipality, several public and commercial actors are involved in this activity. In
practice, many municipalities assign their waste management duties to local companies,
which purchase the requested services by putting them out to tender among individual waste
management enterprises. The use of software tools is common in waste management,
especially in larger cities, but integrated sensor systems are still rare. Some cities, like
Helsinki, are piloting new smart waste systems, but few have, to date, installed large-scale
systems.
In addition to the Ministry of the Environment, there are several other public actors involved
in monitoring and supervising waste management72, including Regional State Administrative
70
71
https://www.hsy.fi/repa/alykasvesi/Sivut/default.aspx
http://www.ymparisto.fi/en-
US/Consumption_and_production/Waste_and_waste_management/Organisation_and_responsibilities_of_waste_management
72
http://www.ymparisto.fi/en-
US/Consumption_and_production/Waste_and_waste_management/Waste_management_authorities_and_duties
100 (127)
Agencies, Centres for Economic Development, Transport and the Environment, and the
Finnish Environment Institute.
Waste management is getting smarter as new technology is implemented in different areas
of the country. New incineration or composting plants are directing waste streams away from
landfill to higher levels or smarter waste management. Here, however, we will focus on
applications of smart waste making use of IoT technology.
Early experiments with Internet of Things (IoT) type solutions in the Finnish waste
management industry involved a scale for measuring the mass of waste in a garbage truck
before emptying the load at the waste station. Today, a few smaller companies, mainly startups, are providing smart waste solutions for container fill-level monitoring and waste sorting.
Enevo is, at the moment, receiving a lot of publicity, but companies like MariMatic Ltd and
ZenRobotics Ltd have also presented innovative solutions for waste management. Overall,
the number of companies involved in the smart waste area in Finland is limited, and since the
use of monitoring technology is only at an early stage, there has been, as yet, little need for
integration or interoperability.
The waste management system in Finland is seeing rapid changes. The change from landfill
to incineration is shaping the structure of the system from municipal into larger areal
networks. This will have an effect on how waste management is organised, what technology
is used, and how business is done. Today there is, however, limited evidence of new IoTbased solutions being developed and implemented. Future needs to increase the recycling
of products, parts, and materials can become the incentive to implement more smart waste
solutions. Recent discussions on the circular economy stress the fact that raw materials are
becoming scarce and that all material needs to be re-used and recycled over several
iterations. This will probably also create a need for close monitoring of material in society and
industry, thus increasing the need for information from a wide range of information sources.
6.3.4
Air quality monitoring
Air monitoring is often mentioned as a key part of the smart city theme, and many cities
report that they are testing new means for monitoring and improving outdoor air quality. Air
quality monitoring has a relatively long history in Finland. Monitoring has been going on since
the 1970s. Today, the national network includes 126 stations in 38 local networks
(Ilmanlaatu.fi). Air quality is monitored for several purposes. Municipalities are responsible for
monitoring and for informing citizens if air quality is deteriorating. Actors in industry and the
energy sector are also obliged to monitor their emissions and their consequences. To some
extent, this can be done in co-operation with local municipalities. The Finnish Meteorological
101 (127)
Institute is responsible for collecting the national air quality information yearly, and for
reporting this information nationally and to the European Union.
The municipalities are responsible for establishing and maintaining measuring stations
suitable for local air quality monitoring. In many cases, neighbouring municipalities join forces
and local industry can also participate in the financing of local monitoring activities. Industry
also has monitoring capacity of its own.
In the area of air quality monitoring, industry is focused mainly on the production of sensors,
the integration of monitoring networks, geographical information systems (GIS), and
simulation modelling. There are some larger companies, such as Vaisala, active in this area
in Finland, but there is also a set of small companies operating in this industry (Arnold et al.,
2009).
Interoperability has been identified as a central development need in the Finnish MMEA
research programme managed by CLEEN Ltd – the Cluster for Energy and the Environment.
The backbone of the programme is the MMEA Testbed, which connects to various data
sources, visualises near real-time data on-screen, and delivers environmental data to a wider
range of applications. The MMEA programme involves several companies related to air
quality monitoring: Vaisala Ltd, Pegasor Ltd, Dekati Ltd, A-Lab Ltd, and HSY73.
Environmental monitoring is a wide area, in which new monitoring needs and opportunities
can be found.
6.4
Horizontal
6.4.1
MyData
Recently in Finland, there has been an ongoing discussion regarding the right of individuals
to access the data collected about them. This discussion has led to the introduction of a
framework called MyData, where the core idea is that individuals should be in control of their
own data. The MyData approach aims to strengthen digital human rights while opening new
opportunities for businesses to develop innovative personal data-based services built on
mutual trust. 74 It is also highly relevant in terms of many of the smart city services related, for
73
http://mmea.fi/mmea-program
74
Poikola A., Kuikkaniemi K., Honko H., 2015. A Nordic Model for human-centered personal data management
and
processing.
http://www.lvm.fi/c/document_library/get_file?folderId=3759139&name=DLFE-
27119.pdf&title=MyData-nordic-model
102 (127)
example, to mobility, the built environment, and energy, and also requires some degree of
interoperable data structures.
One of the basic assumptions behind this MyData thinking is that there is an emerging
market for personal information management services (PIMS). A “personal data inventory” a sort of a secure website - has been suggested to give consumers information about data
that companies and other organisations have collected and maintain about them. The
inventory would contain personal details, existing contracts with companies, payment
methods, and a history of purchases and services used.
Advocates of MyData have envisioned significant opportunities for businesses based on this
PIMS concept (CntrlShift, 2014; Poikola, 2015):

Richer and up-to-date customer data improves the relevance and targeting of
marketing

Richer customer insight and individuals’ volunteered information boosts new product
and innovation development

More
efficient
customer
contact
channels
enable
new
opportunities
for
communication and selling to customers, as well as faster reactions to customer
needs. Lower transaction costs for data acquisition.

Compliance risks and costs can be reduced by permissions and trust-based data
sharing, and consumer trust strength engagement.
In the recently published reports (Poikola, 2015) by the Ministry of Traffic and
Communications, Poikola et al. describe the role and benefits of MyData from the different
stakeholders’ (individuals, companies, and societies) perspectives. The report sketches
potential service infrastructure alternatives, and operational models are also discussed.
The proposed MyData architecture is a highly distributed system without a centralised data
storage where personal data is accumulated. The key components of the MyData service
infrastructure are secured and authenticated personal data management brokers (so-called
MyData operators) that enable the flow of information between stakeholders, either with or
(more likely) without intermediate storage of personal information. MyData broker operations
enable authorised access to personal data from different sources via well-defined APIs.
These APIs enable interaction between data sources and data users.
103 (127)
Each participant in the MyData infrastructure has a MyData account registered by a MyData
operator. This MyData account acts as a single hub for personal data management. By using
the MyData consent brokering service offered by MyData operators, a user is able to grant
access to third parties to utilise data stored by another party. The primary function of a
MyData account is to enable consent management, and the user’s MyData account stores
information on how the individual’s personal data can be exchanged among services, along
with the permissions for using the data. This consent management is the primary mechanism
for permitting and enforcing the legal use of data, and these consent management structures
can be developed using the open consent meta-format (like Kantara Initiative) (Poikola,
2015). The actual data itself is not necessarily streamed through the servers where the
MyData account is hosted. In this model, data flows and consent flows granting access are
clearly separated from each other, as depicted in Figure 14.
Figure 14. The Finnish MyData architecture principles (source: Poikola 2015).
MyData-compliant APIs enable the data sources and users to exchange information with the
MyData account in machine-readable format. This enables the construction of a centralised
dashboard, where a user can manage personal data access and grant or cancel permissions
for multiple data sources and services. The aim of the standardised MyData architecture is to
make MyData accounts interoperable and enable individuals to easily switch operators.
Interoperability is the key advantage offered by the MyData approach, and interoperability
within the data management system can be understood as functioning similarly to
interoperability in mobile telephone networks (Poikola, 2015).
104 (127)
6.4.2
X-Road
In 2012, the Finnish government set up a working group called ICT 2015, to find strategies to
alleviate the impact of the structural change experienced in the ICT industry and to increase
its competitiveness in the “post-Nokia” world. Later, the work was expanded to cover the
broad-based application of ICT in all industry sectors and within public administration. As a
result of this work, the ICT 2015 group published a report called “21 Paths to a Friction-free
Finland”, which established a middle-term roadmap to make Finland a leader in information
technology applications over the next 10 years. One of the suggestions in this report was to
building up “a uniform, national service architecture” that should utilise open interfaces.
In this system, all separate systems maintain and manage their own data and other systems
that need it should be able to access the data through a delivery platform in real time and in
the correct format. In late 2013, the Finnish Economic Policy Committee stated that the
national service architecture should be based on Estonian X-Road75, and the work coordination was delegated to the Ministry of Finance and the actual development work was to
be carried out by the Finnish Population Register Centre76. The resulting
National
Architecture for Digital Services will be a compatible infrastructure facilitating information
transfer between organisations and services. The architecture includes a national data
exchange layer; the shared service views required by citizens, companies, and authorities; a
new national e-identification model; and national solutions for the administration of roles and
authorisations for organisations and individuals.
On a technical level, in the X-Road environment, data is directly transferred through secure
servers in an encrypted form. The central server issues certificates to secure servers and
provides a list of trusted certificates to systems connected to X-Road. Data does not pass
through the X-Road central services and thus cannot be viewed there, and the centre only
maintains statistical information about data transfer between parties. The central server could
actually be disconnected from the network for hours without any impact on X-Road service
availability. Parties involved in transmissions log the data traffic between them and send a
hash to the central server.
75
The Estonia X-road development is discussed in more detail in section 7.2.2.
76
https://esuomi.fi/ , https://confluence.csc.fi/pages/viewpage.action?pageId=37816865
105 (127)
Figure 15. Estonian X-Road system architecture (source: Anthes 2015).
Despite the term ”service bus” (usually applied in Finnish public discussion), X-Road is not
an ESB system in its usual meaning - so this often-used term is a bit misleading. The official
name, National Data Exchange Layer, depicts the essence of the system more clearly:

X-Road offers a standardised way to provide a secure public service interface. It
consists of a distributed server environment in which organisations can attach their
own X-Road servers by applying X-Road service interfaces. Communication takes
place securely over the public Internet.

X-Road also offers a single public authentication service by using a centralised
certificate authority.
X-Road does not provide any support for service development itself. The system is
essentially a peer-to-peer system, with interoperability enforced by centrally distributed
software rather than standards. Thus, X-Road-based infrastructure only enables technical
interoperability, and higher levels like semantic interoperability should be defined separately.
It should be emphasised that X-Road is only one enabling technology for a path to
interoperability, not a solution for that. Nevertheless, it will provide an essential building block
106 (127)
for providing interoperable services and is, for example, heavily noted in the new government
programme, which states that public funding will be used only for systems that are
interoperable with X-Road77.
7. Overview of international smart city interoperability activities
Next, we conduct an overview of international activities related to smart city developments
and focus especially on examples where interoperability and a multi-actor market approach
play an important role.
Since the smart city theme is so broad and there are many ongoing activities, this overview is
not meant to be exhaustive, but it highlights some important international developments.
7.1
International collaboration activities
7.1.1
City Protocol Society
City Protocol78 is a collaborative innovation framework that creates city-centric solutions with
the aim of benefiting citizens and their quality of life. The goal of City Protocol is to define a
common systems view for cities of any size or type, and then develop protocols that will help
innovators create – and modern cities deploy – cross-sectoral solutions that can connect
and/or break city silos.
On an organisational level, the City Protocol Society is a non-profit organisation formed by a
community of cities or other regional bodies related to a city government and commercial
organisations, and it also includes participants from academic institutions and non-profit
organisations. Member cities include, for example, Amsterdam, Barcelona, and Dublin, and
member corporations include Cisco, Microsoft, and Schneider Electric. The members govern
and lead the society with the purpose of supporting and coordinating those research
activities carried out by so-called work teams in the task force.
City protocol work teams include a Data Interoperability and City Indicators team, which
creates formal measures and formal naming and definitions of the types, properties, and
inter-relationships of all system elements within the city anatomy. The Open Sensors
77
http://valtioneuvosto.fi/documents/10184/1407704/Ty%C3%B6ryhmien+laatima+tausta-aineisto/ebe26c87-
6efe-4a0c-8815-3c28149123f1
78
http://cityprotocol.org/
107 (127)
Platform team develops a platform that enables the integration of all the information collected
by the sensors deployed in a city.
Overall, City Protocol aims to work across diverse cities by interconnecting them and
ultimately creating the “Internet of Cities”, a kind of network of cities learning and evolving
together in competitive and cooperative ways, essentially applying Internet of Things (IoT)
technologies to cities.
7.1.2
FIWARE
The Future Internet Public-Private Partnership (FI-PPP) is a European Union-funded
programme for Internet innovation, aiming to accelerate the development and adoption of
future Internet technologies in Europe. The goal of FI-PPP is to enhance the European
market for smart infrastructure and increase the effectiveness of business processes through
the Internet. The FI-PPP programme has been divided into three phases (Future Internet
PPP 2015):
1. Defining the technological foundation and creating eight use case projects during
2011-2014. This technological core of the FI-PPP is called FIWARE, and the EU has
invested €90m in it.
2. The second phase (2013-2015) aimed to develop the core platform through the XIFI
project, which was intended for the establishment of a common European market for
large-scale trials for future Internet and smart cities. This included setting up
infrastructure to operate a European network of FIWARE nodes, for example by
establishing the FIWARE test infrastructure (FILAB). Large-scale trials tested the
versatility of the FIWARE platform components in specific usage domains. The EU
allocated €80m for these initiatives.
3. The third phase of the FI-PPP (2014-2016) is focused on entrepreneurs, start-ups,
and SMEs adopting FIWARE infrastructure. It is aimed at improving a stable
infrastructure for large-scale trials, and creating a sustainable ecosystem for SMEdriven innovation through the selection of 16 business accelerators (FIWARE
Accelerator Programme). EU funding for this effort is €100m.
Since the EU is not going to fund these initiatives any further, FIWARE should find a viable
business model to continue. In March 2015, a European consortium of Spanish teleoperator
Telefónica, French teleoperator Orange S.A., and Atos S.E., a European IT services
corporation also from France, announced a project to standardise their offerings around
108 (127)
FIWARE. It is expected that this FIWARE open source community will be fully operational at
the end of 2015 (Telefonica 2015).
In summary, FIWARE is a common name for an open and standard platform (FIWARE), a
meeting point (FILAB), and support tools (FIWARE Ops) and support programmes (FIWARE
Accelerate and FIWARE Mundus). By providing these enablers, FIWARE tries to facilitate
the cost-effective creation and delivery of applications and services in a variety of areas,
including smart cities, sustainable transport, logistics, renewable energy, and environmental
sustainability.
FIWARE is a middleware platform for the development and global deployment of applications
for the Internet. The initiative has produced open source, API-enabled tools to enable
developers to create ‘smart city’ apps. The idea is that developers use FIWARE’s sandbox
environment (FILAB) to trial their prototypes and get feedback from smart city experts and
developers that are using the tools. FIWARE Ops is a collection of tools that eases the
deployment, setup, and operation of FIWARE instances. FIWARE Ops is the tool used to
build, operate, and expand FIWARE Lab.
To expand of adoption of these FIWARE tools, the FIWARE Acceleration Programme
promotes the take-up of FIWARE technologies among solution integrators and application
developers, with a special focus on SMEs and start-ups. The FIWARE Mundus programme
is designed to expand deployment of FIWARE globally (e.g. Latin America, Africa, and Asia).
As a part of the FIWARE Mundus programme, Helsinki was among the preselected
candidates for “FIWARE Region”. Getting the FIWARE Region Mundus status offers visibility,
facilitates access to EU funding, helps in networking with other regions and cities, and
enhances support from the FIWARE community.
From an interoperability point of view, a common platform enables easier smart city
application portability among FIWARE adopters. The XIFI project has produced a software
engineering tool particularly for interoperability problems, which supports the development
and
testing
of
FIWARE-based
xifi.eu/Public:Interoperability_Tool).
applications
and
services
(http://wiki.fi-
109 (127)
7.1.3
EIP SCC
The European Innovation Partnership for Smart Cities and Communities (EIP-SCC)79 is a
European Commission-led initiative that brings together cities, industry, and citizens to
improve urban life through more sustainable integrated solutions. It looks to establish
strategic partnerships between industry and European cities, to develop the urban systems
and infrastructure of tomorrow.
EIP-SCC also emphasises the importance of creating interoperable solutions across cities in
Europe. Several organisations have signed a memorandum of understanding80 with the goal
of moving towards more interoperable urban platforms. The aim is to speed up the smart
cities market by focusing on interoperable platforms, enabling cities to freely mix products
from different suppliers, and leaving the traditional approach of custom-built and proprietary
solutions behind.
Overall, the European Commission has developed two parallel approaches to support the
implementation of smart urban technologies: large-scale demonstrations of technology in
cities and communities (‘lighthouse projects') and 'horizontal activities' to address specific
challenges, such as interoperability but also regulatory barriers, standardisation, public
procurement, and performance monitoring. The horizontal activities will be important when
scaling the results of lighthouse projects and creating larger multi-actor markets.
One of the horizontal projects focusing on performance monitoring is CITYkeys, which
features the city of Tampere and VTT as participating partners from Finland. The goal of the
project is to develop and validate key performance indicators and data collection procedures
for the monitoring of smart city solutions across European cities.
7.1.4
Open and Agile Smart Cities
The Open and Agile Smart Cities (OASC) initiative81 aims to kick-start the use of a shared set
of widespread, open standards and principles, enabling the development of smart city
applications and solutions that are interoperable between cities and within a city82. Several
79
http://ec.europa.eu/eip/smartcities/
80
https://eu-
smartcities.eu/system/files/Memorandum%20of%20Understanding%20on%20Urban%20Platforms.pdf
81
82
http://connectedsmartcities.eu/open-agile-smart-cities/
http://connectedsmartcities.eu/wp-content/uploads/2015/03/Open-and-Agile-Smart-Cities-Background-
Document-1st-Wave.pdf
110 (127)
cities from Europe and Latin America have signed a letter of intent83 and are committed to
implementing common standards. This group also includes the cities that have a 6AIKA
strategy in Finland (i.e. Helsinki, Espoo, Vantaa, Turku, Tampere, and Oulu).
The goal of the initiative is to focus on simple, functional, minimal, de facto standard ways of
accessing and exchanging data. For a city, this means that it is possible to implement the
proposed mechanisms on top of and in addition to existing systems or future systems to be
procured, without being intrusive in their internal architecture. Consequently, the cost
associated with the implementation is very limited and the flexibility is high. The first phase of
the initiative deploys interfaces created in the CitySDK project with the FIWARE NGSI API.
CKAN will serve as the initial standard platform.
7.1.5
Alliance for Internet of Things Innovation
The Alliance for Internet of Things Innovation (AIOTI)84 was launched in 2015 by the
European Commission and several relevant stakeholders (mainly industry) in the IoT domain
to create a dynamic European ecosystem that can boost the market in its multiple application
domains. The alliance has also a Smart Cities Working Group which aims to create a city
centric ecosystem of state-of-the-art, viable, technologies which apply the IoT technologies
and integrate it with the concepts of Internet of Energy (IoE), Internet of Vehicles (IoV), and
Internet of Buildings (IoB).
As part of the Horizon 2020 work programme for 2016-2017, there will be a specific call for
Large Scale Pilots one of which will be devoted to smart cities. 85 The Smart Cities Working
Group recommends that the Large Scale Pilots should demonstrate replicability in other
cities and interoperability in the city and emphasizes that interoperability at several degrees
7.1.6
Smart City council
The Smart City council86 describes itself as an adviser and market accelerator that promotes
the move to smart, sustainable cities. It provides advocacy related to smart city deployment,
such as readiness guides, financing templates, policy frameworks, regional networking
83
http://connectedsmartcities.eu/wp-content/uploads/2015/03/Open-and-Agile-Smart-Cities-LoI-1st-
Wave.pdf
84
85
http://www.aioti.eu/
Smart
City
LSP
Recommendations
Report,
AIOTI
http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=11988
86
http://smartcitiescouncil.com/
WG08
–
Smart
Cities,
2015.
,
111 (127)
events, and visibility campaigns. It is mostly an industry-led initiative whose current lead
partners include Cisco, IBM, Microsoft, and Schneider Electric, but it also includes a group of
adviser organisations from standardisation and other non-governmental organisations (e.g.
the City Protocol Task Force). Although the initiative is primarily centred on the United
States, the Smart City council has added an international dimension with the creation of the
Global Alliance of Smart Cities Councils, with India being the first entry.
To form a structure around the smart city theme, the initiative defines a group of so-called
responsibility areas (similar to the vertical smart city sectors) such as transportation, built
environment, energy, waste management, water, and wastewater. As it relates to
interoperability, the Smart City council has dedicated interoperability as one core (horizontal)
technology enabler, refers to interoperability as one of the digital underpinnings of a smart
city87, and gathers resources (articles and white papers) related to the topic. Other enablers
include instrumentation and control, connectivity, and data management.
7.1.7
Japan Smart Community Alliance
The Japan Smart Community Alliance (JSCA)88 was established in 2010 with the aim of
promoting smart city development through collaboration between the public and private
sectors. As of October 2015, the alliance had 288 members, representing a wide variety of
private companies, research organisations, and government agencies. The mission of JSCA
is to promote dissemination of smart community technologies by addressing issues that are
difficult for individual companies or organisations to resolve alone, such as standardisation
and establishment of new social practices related to the smart city. The alliance facilitates
collaboration among a wide range of relevant parties, provides information, and contributes
to the preparation of roadmaps. Active members of the alliance, participating in
demonstration and dissemination activities, include large corporations such as Hitachi,
Toshiba, Panasonic, Toyota Motor Corporation, Fujitsu, Mitsubishi Electric, Tokyo Gas,
Shimizu Corporation, and Kansai Electric Power. The secretariat is operated by the New
Energy and Industrial Technology Development Organization, NEDO, a government agency.
The JSCA focuses its activities on smart energy, infrastructure, information and
communication technologies, and lifestyle issues. In the aftermath of the great earthquake in
87
http://smartcitiescouncil.com/smart-cities-information-center/interoperability
88
https://www.smart-japan.org/english/about/index.html
112 (127)
2011 and the subsequent energy crisis, there has been a strong emphasis on smart grid
technologies. Integrated with energy issues are other domains of urban infrastructure, such
as water and sewage, transportation, and communications.
Practical collaboration within the alliance is carried out in four working groups: international
strategy, international standardisation, roadmap, and the smart house and building working
group. Each group advances discussions and conducts studies for further development. The
standardisation working group has been engaged in formulating priority areas for
international standardisation, together with the Ministry of Economy, Trade and Industry; the
promotion of international standardisation in various solutions (e.g. wide area situational
awareness, energy storage interface, and smart community evaluation indicator);
establishing partnerships with international standardisation organisations (e.g. the Smart Grid
Interoperability Panel SGIP, IEEE); and the development of microgrid use cases.
The international dissemination activities include partnerships with a number of countries,
and execution of demonstration projects. These activities have been taking place in New
Mexico (USA), Lyon (France), Malaga (Spain), Java (Indonesia), and Maui, Hawaii (USA).
7.2
Activities by cities and countries
Next, we describe smart city development activities in selected cities, focusing especially on
interoperability. We study the city of Barcelona, which has been one of the leading smart
cities, and also two neighbouring smart city markets, namely Estonia (with a special focus on
the development of the X-Road data exchange layer) and Sweden (with a special focus on
Stockholm).
7.2.1
Barcelona
Among all cities worldwide claiming to be smart, Barcelona has perhaps developed the most
comprehensive agenda for integrating intelligence in a coordinated manner. Development
and deployment of smart solutions is set in a high position in the city’s strategic framework.
The development has been led by the city mayor, and coordinated by a smart city strategy
team within the mayor’s office. Several large programmes cut across traditional
administrative domains, each comprising a large number of projects, most of which are
carried out in partnership with private firms and research organisations.
Real-time data is collected through a large network of sensors (Sentilo), transmitted through
an extensive communication network infrastructure (fibre-optics and wireless), and
aggregated on an open data platform (City OS). A large variety of public data is made
113 (127)
available as open data. Usage of the information collected is made possible through various
tools for monitoring and decision-making. Smart services and applications are provided, such
as remote-controlled and energy-efficient lighting, energy self-sufficient blocks, smart water
applications for park irrigation, smart parking, intelligent public transportation, and zero
emissions mobility. Local government services are also provided online and through a
network of service kiosks, as developed by an open government initiative.
As the smart city is a great opportunity for economic development, industrial innovation is
promoted through several strategic initiatives. A smart city campus provides a collaborative
space for the development of new technologies, products, services, and applications
between industry and universities. A large cluster of domestic and international companies is
now active in the city. Barcelona provides the city as a testbed for companies to pilot and
demonstrate services. A ‘tested in Barcelona’ label is provided for products and services that
have demonstrated their feasibility and performance in the city. In addition, a former
industrial neighbourhood, dubbed 22@Barcelona, provides a dedicated pilot environment for
testing new solutions. The city administration has also set smart city service as a high priority
goal in their procurement agenda, in order to provide real market demand for innovative
solutions. For instance, the development of the open city operating system was contracted
through a public tender.
The city administration has already been able to measure some tangible effects of
deployment of the smart city solutions. These include significant savings in water services,
increased parking fee revenues, and an estimated 47,000 jobs created through these efforts.
7.2.2
Estonia
In Estonia, the smart city is a topic gaining attention as an approach to boost the
development of digitally powered services and promote economic development. The
activities are mostly concentrated in the two major cities, Tallinn and Tartu. Some minor
activities are also taking place in smaller towns, such as intelligent building development in
Rakvere.
The city of Tallinn is developing its Technopol science park district as a testing site for smart
city solutions. A key feature of the concept is the vibrant start-up ecosystem operating in the
area.
The city of Tartu has created a Smart City Lab, which operates as a hub for development
activities in the city. The city government is currently developing measures to use its public
procurement projects as demand creation mechanisms for intelligent urban services. Open
114 (127)
city GIS data, smart tools for conducting city inspections, a mobile tourism application, a
public transport data application (NFC), and solutions for electric vehicles are among the
solutions developed and piloted so far. The city is also in the process of setting up a smart
city demo centre, where smart solutions are displayed and demonstrated.
An interesting backbone for smart city activities is provided by the national e-governance
service X-Road. X-Road provides interoperability between government agencies and private
organisations. X-Road is a data exchange layer that enables secure Internet-based data
transmission between organisations. The service was launched in 2001 and it first provided
secure exchange of data between government agencies. In the course of its expansion,
some private organisations have also been connected to the system. Over the 14 years of its
operation, the X-Road system has expanded to become one of the most extensive national
electronic data infrastructures worldwide, with associated services such as electronic
identification and electronic voting.
The development of X-Road is an interesting case for understanding the evolution of
interoperability between distinct organisations. The initial impetus for the development was a
need to create a secure method for exchanging data between government agencies. As a
large amount of money was not available to build a dedicated network for the government,
other more flexible approaches were considered. A more nimble approach was suggested by
local data security specialists to use the general Internet network, create a robust security
layer on top of it, and standardise data exchange gateways. Instead of creating a secure
network, the data itself was made secure. This would create a decentralised system with no
single point of failure. The approach does not require changes in the information systems in
the back office, which makes it relatively easy and fast to deploy.
The actual development was kicked off by inviting the chief information officers from fourteen
ministries. Endorsement was created for a project that was financed by the government. A
data security supplier, Cybernetica, was contracted to develop the core technology.
However, the intellectual property ownership of the source code remained with the
government to allow its extensive exploitation within the government. The first stage of the
project was to create an architecture by identifying the main components of the system: the
service catalogue, payments solutions, and so on.
When the system was launched in 2001, the first use cases were associated with the
exchange of population data and passport data. Immediate expansion did not follow. Rather,
several years passed with a modest level of activity taking place within the system. The slow
start led some people to consider that X-Road had failed, and a discussion about its
115 (127)
termination was taking place. However, the potential of the system was recognised and the
government created an obligation to use X-Road by law. The compulsory usage was resisted
by some parts of the administration (e.g. universities). Despite opposition, the requirements
were set by legislative means and system use started to take off on a larger scale. The
government has adopted a strategy to contract out the implementation of the system as
much as possible to private companies. Therefore, complementary services have been
developed in a decentralised manner, by a variety of firms through public tenders.
Currently, there are some 250 databases and 1300 services connected to the X-Road
system. The bulk of the volume of data exchanges is performed by exchanging
administrative data related to tax authorities, customs, border control, and police authorities.
The health service is another large domain. The health service started by exchanging x-ray
images. Since then, a host of health services have been included, such as electronic
prescriptions. A domain-specific community, the Estonian e-Health Foundation, co-ordinates
a highly active developer community taking developments further.
Some private companies are also starting to use the X-Road infrastructure. The most
advanced use case is found in the energy sector. A consortium of energy industry players
has developed a data-sharing platform, Estfeed, which enables energy network companies,
energy producers, and consumers to interact more efficiently and utilise the data collected
during energy consumption. The companies are developing applications on top of the
Estfeed platform to tap into the energy metering data (electricity, gas). The first applications
include a microgeneration service, an evaluator tool to measure the correct ampere level, an
electricity consumption aggregator, a virtual power plant, and a district heating monitoring
application. The data in the applications are exchanged using the secure X-Road service.
The X-Road service is now also being deployed in Finland. In addition to implementing the
core features of the Estonian system, the next-generation version of the system is being
developed in partnership between the Estonian and Finnish developer communities. Estonia
has also promoted X-Road as part of a larger e-governance framework to developing
countries and emerging economies, through development projects, with the help of
international donor agencies. The biggest projects are taking place in Namibia, Moldova, and
Morocco.
As key lessons from the X-Road interoperability framework, it can be concluded that while at
the core of the system there is a robust data security technology solution, the adoption and
upscaling of the system is dependent on a large number of regulatory, organisational, and
management issues. After the technology was made available, its expansion took a decade,
116 (127)
and required a variety of supportive measures. These have included making the X-Road
system obligatory for government agencies by legislation, providing support for deployment,
creating tools and guidelines, and various promotion activities.
Furthermore, in the adoption pattern, there has been a clearly noticeable “tipping point” of 50
databases connected to the system, after which usage started to scale up on an exponential
trajectory. This pattern, which is in line with simulations done with similar networked systems,
warrants having a sufficient level of patience and sustained levels of investment over the first
years of operation, before the network effects start creating self-reinforcing patterns of
expansion. X-Road was, in effect, under a threat of termination after the first years of its
operation, due to the modest visible impact. Understanding of the system dynamics is thus
needed.
One of the interesting features of the X-Road system is that, in itself, the secure data
exchange service does not create semantic interoperability between the information systems
involved. Semantic interoperability – the uniformity of the meanings related to the content
exchanged – remains the responsibility of the parties involved with the data exchange.
However, as usage of X-Road has expanded, semantic interoperability has also started to
evolve through each new connection being created. The operators of the X-Road system
have facilitated the development of semantics by developing standards and libraries.
7.2.3
Stockholm and Sweden
Stockholm Royal Seaport
With regard to smart city activities in the city of Stockholm, one of the flagship initiatives is
the Stockholm Royal Seaport urban development project89, one of the largest urban
development projects in Europe, where the goal is to create a world-class sustainable and
smart city area close to the city centre. The Royal Seaport also hosts an innovation arena, a
group of research and development (R&D) projects carried out by companies, the city's
administration, and academia, for example in the field of urban smart grids, smart waste
collection, and smart ICT, with the overall goal of meeting ambitious environmental and
sustainability targets.
For example, in the Urban Smart Grids project, the energy company Fortum is developing
active apartments that are instrumented with equipment that retrieves information about
prices and CO2 impact, to make it possible for residents to be able to make the best possible
89
http://www.stockholmroyalseaport.com/en/
117 (127)
choices. Ericsson is leading the Smart ICT project, in which the goal is to create a shared
and interoperable ICT infrastructure across different sectors, to enable services such as
transport, logistics, health care, and media to communicate through the same infrastructure.
To follow up on how the environmental and sustainability targets are being met, a real-time
environmental database is also built. This work will be carried out within the remit of a
research and development project to develop an interactive real-time database, and is a
collaboration between the city, academia, developers, technology development companies,
and research institutions.
GrowSmarter - Smart cities and communities EU lighthouse project
Another notable project in which the city of Stockholm is involved is the GrowSmarter Smart
cities and communities EU lighthouse project90, in which Stockholm, together with two other
leading lighthouse cities - Cologne and Barcelona - and industry partners, will integrate and
demonstrate ‘12 smart city solutions’ in the fields of energy, infrastructure, and transport. The
GrowSmarter project was one of three projects chosen from more than 19 submissions to
receive support from the notable European Commission ‘Smart cities and communities’
Horizon 2020 funding call. The additional two successful projects are Remourban91 and
Triangulum92, and the goal is that all three projects will work closely together to maximise the
impact and exchange of experiences.
Common Ticketing and payment solutions
In relation to interoperability and a multi-actor approach, a notable national activity in Sweden
is a project called Common Ticketing and payment solutions93, which is currently led by
Samtrafiken94, a service development company that has the aim of making public transport
easier, more accessible, and more reliable. The Common Ticketing and payment solutions
project is an arena for collaboration related to ticketing and payment systems, which
involves, in addition to Stockholm County, some 30 industry players from entities procuring
the ticketing systems (e.g. public transport authorities and bus operators), and vendors
supplying the ticketing systems.
90
http://www.grow-smarter.eu/lighthouse-cities/stockholm/
91
http://www.remourban.eu/
92
http://www.triangulum-project.eu/
93
http://www.samtrafiken.se/utvecklingssamverkan/projekt/gemensamma-biljett-och-betallosningar/
94
The project was formerly led by an organization called X2AB which was later on merged to Samtrafiken.
118 (127)
The goal is to create interoperability between systems so that a traveller can seamlessly plan
and purchase their travel on public transport, whether they are travelling locally, regionally, or
nationally. The working model consists of three groups: the market group, which includes
public transport authorities and bus operators running the physical services (i.e. the entities
procuring the ticketing systems); a vendor group; and a technical group95. One essential
target is to enforce standard interfaces to ticketing and payment systems, in order to ensure
competition and innovation, and to minimise vendor lock-in.
8. Conclusions
After a review of the current state of smart city development in Finland, it can be concluded
that the current smart city solutions are, in fact, to a large degree fragmented and vertically
integrated, and that there is a need for horizontal processes such as common procurement
practices and interoperability testing and certification. The results described in this report
serve as direct input to the second phase of the InterCity project.
Overall, the key problem for cities and other entities procuring and developing smart city
systems is that even though the needs are essentially the same, dedicated vertically
integrated solutions are built. This is also a problem from the supplier perspective, since
companies have to use significant resources on tailoring and integration, which in turn leads
to limited scalability and economies of scale, and to a situation in which larger markets with
modular product offerings do not emerge. Furthermore, since the procurements are not
conducted in a modular manner, SMEs are not in a position to participate and bring their
offerings to the table. In addition, when larger market potential does not exist, willingness to
invest in new products becomes low and the business models are reduced to providing
tailored solutions directly funded by the procuring organisation. One could characterise the
relationship between buyers and suppliers as one that has asymmetrical interests (buyers
want more choice and to avoid a vendor lock-in, whereas suppliers want better scalability for
their products), but also as one in which both sides would benefit from interoperability.
Thus, the core issue for market creation is similar to the classic chicken-and-egg problem. In
order for a true market to emerge, a critical mass of buyers and suppliers is needed that
commit to using common horizontal processes and to buying and supplying modular
products and services. These processes can be very light and facilitate fast clock-speed
95
What is interesting to note is that these correspond to and are aligned with the work packages of this
project. Thus, the model could be used as a basis for the second phase of the project.
119 (127)
development where life-cycles are short (such as end-user service innovation on the
Internet), but can also facilitate heavier processes in which large capital-intensive
investments are made with long investment cycles. What can also be concluded is that
interoperability is not a technical challenge but an organizational one, and therefore on a
technical level it is important to deploy tools and processes such as common requirement
specifications, and interoperability testing and certification, that enable the emergence and
deployment of common interfaces for use in products and services.
It is good to note that there are some good prior examples of interoperability efforts and also
ongoing activities that support the evolution towards modular smart city systems. In terms of
historical examples, the KuntaGML initiative led by the Association of Finnish Local and
Regional Authorities has been a notable activity promoting a multi-buyer, multi-vendor
market. Another significant effort was the CitySDK project led by Forum Virium Helsinki, in
which the goal was to create harmonised APIs across European cities. In relation to current
activities, flagship examples are 6AIKA - the joint strategy between the six largest Finnish
cities (Helsinki, Espoo, Vantaa, Tampere, Turku and Oulu) - and the creation of a National
Service Channel based on Estonia's Data Exchange Layer, X-Road. Collaboration that exists
at a sectoral level, driven, for example, by buildingSMART Finland and ITS Finland, is also of
high importance.
Furthermore, key international developments for interoperability frameworks should be
followed, such as the development of the memorandum of understanding for the European
Innovation Partnership for Smart Cities and Communities, and the Open and Agile Smart
Cities initiative. It is interesting to note that, when looking at activities by international cities
from the point of view of interoperability, it seems especially important to study activities by a
group of collaborating cities, instead of looking at the activities of a single city.
A good reference point is also to examine ongoing efforts in neighbouring countries, such as
the Common Ticketing and payment solutions project led by Samtrafiken in Sweden, or the
X-Road development in Estonia. As discussed, important lessons can also be learned from
the evolution and best practices in interoperability in other industries. Some important
examples are Integrated Healthcare Enterprise (IHE) for health care information systems, the
evolution of
GSM-based mobile networks, and best
practices
in Internet-based
interoperability (e.g. IETF and W3C).
Overall, it can be concluded that the different smart city sectors vary considerably in terms of
their maturity in deploying ICT solutions, the state of interoperability, and clock-speed (i.e.
investment cycles). For example, it is good to keep in mind that the life-cycle of an IT system
120 (127)
differs considerably from that of a vehicle, a building, a road, an energy network, or a water
or waste system. Therefore, a modular approach that takes into consideration these different
life-cycles is also needed.
When comparing the key sectors studied in this project, it can be noted that especially the
information modelling of the built environment (GIS and building level) is quite advanced and
has a rather good selection of commonly used data formats (although the models are not
currently in real time). Mobility is also quite advanced and many applications exist, although
the interoperability of these is still rather limited. In terms of the energy sector, especially the
large centralised energy networks are, in fact, quite interoperable, whereas the decentralised
solutions are, to a large degree, fragmented and not interconnected. For cleantech, smart
water and waste management are in the very early stages of evolution, whereas
environmental measurement platforms, especially related to weather, are quite advanced.
Based on the analysis of key activities, few of them stand out as promising candidates for the
second phase of the interoperability concept as it relates to the level of maturity of ICT
solutions and stakeholder involvement. Real-time traffic information is a strong case, since it
has many ongoing parallel efforts and preliminary plans for collaboration by cities and other
important actors. The development towards MaaS is also currently a hot topic, with many
stakeholders involved and with a strong need for interoperability. In relation to the built
environment, the development towards a CityGML-based 3D city model is a promising
activity. For energy and cleantech, the environmental monitoring platform developed in the
MMEA programme, in particular, could be a good candidate, since it has a strong basis in
interoperability.
Overall, it can be concluded that interoperability will be a key issue in the evolution of smart
cities. The different stakeholders working with smart city solutions need to be challenged to
come up with new ways to support modularity and interoperability, which is the key goal of
Phase 2 of the project. Now is the right time to move towards a horizontal smart city market
structure, before it gets locked into closed solutions.
References
Alvestrand H. (2004). RFC 3935 - Internet Engineering Task Force [Online] Available:
https://www.ietf.org/rfc/rfc3935.txt. [Accessed: 12.10.2015]
Anon (2013). European Innovation Partnership on Smart Cities and Communities - Strategic
Implementation Plan.
121 (127)
Anthes G. (2015). Estonia: A Model for e-Government. Communications of the ACM, Vol. 58
No.
6,
Pages
18-20
[Online]
http://cacm.acm.org/magazines/2015/6/187320-estonia/fulltext
Available:
[Accessed
20.12.2015]
Anthopoulos, L., & Fitsilis, P. (2010). From digital to ubiquitous cities: Defining a common
architecture for urban development. In Proceedings of the 6th International
Conference on Intelligent Environments, Kuala Lumpur, Malaysia, July 19-21.
Baden-Fuller C, Morgan M.S. (2010) Business Models as Models. Long Range Planning
43(2-3): 156-171.
BD (2015). Business Dictionary. Definition of Interface, (2015). [Online] Available from:
http://www.businessdictionary.com/definition/interface.html- [Accessed: 4.5.2015]
Bloch M., Blumberg S., & Laartz J. (2012).: Delivering large-scale IT projects on time, on
budget, and on value. McKinsey& Company Insight and Publications, 2012. [Online]
Available
from:
http://www.mckinsey.com/insights/business_technology/delivering_largescale_it_projects_on_time_on_budget_and_on_value. [Accessed: 10.11.2015]
Caragliu, A., Del Bo, C. and Nijkamp, P. (2009). 'Smart Cities in Europe', Series Research
Memoranda 0048, VU University Amsterdam, Faculty of Economics, Business
Administration and Econometrics.
Casey, T.R. (2013). Evolution of wireless access provisioning: Understanding and managing
value system structures and dynamics, Aalto University.
Chen P., & Hitt L. (2005). Measuring Switching Costs and the Determinants of Customer
Retention in Internet-Enabled Businesses: A Study of the Online Brokerage Industry.
Information Systems Research, 2002 INFORMS Vol. 13, No. 3, September 2002, pp.
255-274.
Conover C. (2012). The Cost of Health Care: 1958 vs. 2012. Forbes /Pharma & Healthcare
Dec
22,
2012.
[Online]
Available
from:
http://www.forbes.com/sites/chrisconover/2012/12/22/the-cost-of-health-care-1958vs-2012/. [Accessed 7.8.2015]
Continua (2015). [Online] Available: http://www.continuaalliance.org/ [Accessed 12.10.2015]
122 (127)
David, Paul A. & Greenstein, Shane (1990). The economics of compatibility standards: an
introduction to recent research. Economics of Innovation and New Technology 1, pp.
3-41.
Dirks, S. & Keeling, M. (2009). A vision of smarter cities: How cities can lead the way into a
prosperous and sustainable future. IBM Institute for Business Value, June.
Edwards J. (2006). Case Study: Denmark's Achievements With Healthcare Information
Exchange. Gartner Industry Research, 30 May 2006. [Online] Available from:
https://www-304.ibm.com/industries/ca/en/healthcare/files/gartner-case_studydenmarks_achievementswHIE.pdf. [Accessed 11.10.2015]
EIF (2010). Interoperability Framework (EIF) for European public services. EUROPEAN
COMMISSION Bruxelles, le 16.12.2010 COM (2010) 744 final [Online] Available
from:
http://ec.europa.eu/isa/documents/isa_annex_ii_eif_en.pdf.
[Accessed:
11.10.2015]
EIF (2011). European Interoperability Framework (EIF) Towards Interoperability for
European
Public
Services.
[Online]
Available
from:
ec.europa.eu/isa/documents/eif_brochure_2011.pdf. [Accessed: 11.10.2015]
EIP SCC (2013). European Innovation Partnership on Smart Cities and Communities
Strategic - Implementation Plan.
Eisenmann, T., Parker, G. and Van Alstyne, M.W. (2006). Strategies for two-sided markets.
Harvard Business Review, 84(10), 92-101.
EU (2011). Quantifying public procurement of R&D of ICT solutions in Europe SMART
2011/0036.
[Online]
Available:
http://cordis.europa.eu/fp7/ict/ssai/docs/study-
action23/d2-finalreport-29feb2012.pdf. [Accessed 12.10.2015]
European Parliament (2014). Mapping Smart Cities in the EU, Policy department.
FD (2015). Free Dictionary. Definition of Interface, 2015. [Online]: Available from:
http://www.thefreedictionary.com/Interface. [Accessed: 4.5.2015]
Frost & Sullivan (2013). Strategic Opportunity Analysis of the Global Smart City Market.
Fung B. (2012). How the U.S. Health-Care System Wastes $750 Billion Annually. The
Atlantic.
[Online]
Available
from:
http://www.theatlantic.com/health/archive/2012/09/how-the-us-health-care-systemwastes-750-billion-annually/262106/. [Accessed: 10.10.2015]
123 (127)
Future
Internet
PPP
(2015).
[Online]
Available:
https://www.fi-ppp.eu/
[Accessed;
12.10.2015]
Gawer, A. and Cusumano, M.A. (2008). How companies become platform leaders. MIT
Sloan Management Review, 49(2), 28-35.
Giffinger, R., Fertner, C., Kramar, H., Kalasek, R., Pichler-Milanovi, N., & Meijers, E. (2007).
Smart Cities: Ranking of European Medium-Sized Cities. Vienna, Austria: Centre of
Regional Science (SRF), Vienna University of Technology. Available from
http://www.smart-cities.eu/download/smart_cities_final_report.pdf.
Gotze J. European Interoperability Framework 2.0, December 19, 2010. [Online] Available
from:
http://gotze.eu/2010/12/19/european-interoperability-framework-2-
0/ .[Accessed: 11.10.2015]
Guijarro, Luis (2009). ICT standardisation and public procurement in the United States and in
the European Union: influence on egovernment deployment. Telecommunications
Policy 33, pp. 285-295.
Hall, R. E. (2000). The vision of a Smart City. In Proceedings of the 2nd International Life
Extension Technology Workshop, Paris, France, September 28, Available from
http://www.osti.gov/bridge/servlets/purl/773961-oyxp82/webviewable/773961.pdf.
Haque, U. (2012). Surely There's a Smarter Approach to Smart Cities?, Wired, 17 April.
Available at: http://www.wired.co.uk/news/archive/2012-04/17/potential-of-smartercities-beyond-ibm-and-cisco (visited July 2013).
Harrison, C., Eckman, B., Hamilton, R., Hartswick, P., Kalagnanam, J., Paraszczak, J., &
Williams, P. (2010). Foundations for Smarter Cities. IBM Journal of Research and
Development, 54(4).
IEEE 100 (2010) - The Authoritative Dictionary Of IEEE Standards Terms. NYC, NY, USA:
IEEE Press. 2000. pp. 574-575.
IHE (2015). Integrating the Health Enterprise. [Online] Available from: http://www.ihe.net/
[Accessed 11.10.2015]
ISO (2015). SO/IEC 2382:2015 Information technology - Vocabulary.
124 (127)
Laflamme F., Pietraszek, W., & Rajadhyax N. (2010) Reforming hospitals with IT investment.
McKinsey
Insights
&
Publications
2010.
[Online]
Available
from:
http://www.mckinsey.com/insights/health_systems_and_services/reforming_hospitals
_with_it_investment. [Accessed: 2.9.2015]
Li M., Cabral R., Doumeingts G. & Popplewell K. (2006) Enterprise Interoperability Research
Roadmap Final Version (Version 4.0) 31 July 2006. [Online] Available from:
ftp://ftp.cordis.europa.eu/.../ei-roadmap-final_en.pdf. [Accessed 24.5.2015].
Magretta, J. (2002) Why business models matter, Harvard Business Review 80(5).
MedCom (2001) MedCom - the Danish Healthcare Data Network. [Online] Available from:
http://www.medcom.dk/dwn398 [Accessed 10.9.2015]
MedCom (2014) MedCom - in English - MedCom - In brief [Online] Available from:
http://www.medcom.dk/wm109991 [Accessed 12.11.2015]
Medeiros J. & Schewierz C. (2015) Efficiency estimates of health care systems. Economic
Papers
549
|
June
2015
.
[Online]
Available
from:
http://ec.europa.eu/economy_finance/publications/economic_paper/2015/pdf/ecp549
_en.pdf.
MIT
(2013).
'Smart
Cities
Group',
Cambridge,
MA.
Available
at:
http://smartcities.media.mit.edu/frameset.html
Nam, T. and Pardo, T. A. (2011). Conceptualizing Smart City With Dimensions of
Technology, People, and Institutions, from Proceedings of the 12th Annual
International
Innovation
Digital
in
Government
Challenging
Research
Times,
ACM
Conference:
Digital Government
New
NY.
York,
Available
at:
http://smartcitiescouncil.com/system/files/resources/Conceptualizing%20smart%20cit
y.pdf
Natural Resources Defense Council (2014). What are smarter cities?, Available from
http://smartercities.nrdc.org/about.
Navigant Research (2013). Smart City Suppliers Assessment of Strategy and Execution for
15 Smart City Suppliers, Navigant Research Leaderboard Report.
NIST (1999). Overview of Conformance Testing, January 25, 1999. [Online] Available from:
http://www.nist.gov/itl/ssd/is/overview.cfm. [Accessed: 3.5.2015]
125 (127)
OECD (2010) Improving Health Sector Efficiency - The Role of Information and
Communication Technologies. OECD Health Policy Studies 2010. [Online] Available
from: http://ec.europa.eu/health/eu_world/docs/oecd_ict_en.pdf. [Accessed: 5.8.2015]
Olaf Bergengruen O., Fischer, F., Namli T., Rings T., Schulz, S., Serazio, L. & VassiliouGioles, T. (2008) Ensuring Interoperability with Automated Interoperability Testing.
ETSI
2008.
[Online]
Available
from:
https://portal.etsi.org/Portals/0/TBpages/CTI/Docs/Ensuring%20Interoperability%20wi
th%20Automated%20Interoperability%20Testing_rev6a.pdf [Accessed: 10.9.2015]
ONC (2015). Report on Health Information Blocking, Report To Congress April 2015. [Online]
Available:
https://www.healthit.gov/sites/default/files/reports/info_blocking_040915.pdf.
[Accessed: 12.10.2015]
PCHA (2015). Fundamentals of Data Exchange, White Paper, September 2015. [Online]
Available: https://cw.continuaalliance.org/document/dl/13473 [Accessed: 12.10.2015]
Poikola A., Kuikkaniemi K., Honko H., (2015). A Nordic Model for human-centered personal
data
management
and
processing.
[Online]
Available:
http://www.lvm.fi/c/document_library/get_file?folderId=3759139&name=DLFE27119.pdf&title=MyData-nordic-model [Accessed 15.10.2015]
Porkka, J., Jung, N., Päivänen, J., Jäväjä, P. & Suwal, S. (2012), ”Role of social media in the
development of land use and building projects”, eWork and eBusiness in
Architecture, Engineering and Construction, Gudnason G. & Scherer R. (eds.),
ECPPM 2012, Reykjavik, Iceland, July 25-27, 2012, pp. 847-854.
Protti D., & Johansen I. (2010) Widespread Adoption of Information Technology in Primary
Care Physician Offices in Denmark: A Case Study. Issues in International Health
Policy,
March
2010
[Online]
Available
from:
http://new.commonwealthfund.org/~/media/files/publications/issuebrief/2010/mar/1379_protti_widespread_adoption_it_primary_care_denmark_intl_ib.p
df [Accessed 12.10.2015]
Rings T., Poglitsch P., Schulz, S., Serazio, L. & Vassiliou-Gioles, T. (2014) A generic
interoperability testing framework and a systematic development process for
automated interoperability testing. International Journal on Software Tools for
Technology Transfer (STTT) archive Volume 16 Issue 3, June 2014 . pp 295-313.
126 (127)
Rotenberg J. (2008). Towards a Dutch Interoperability Framework Recommendation to the
Forum
Standaardisatie.
Rand
Corporation
2008.
[Online]
Available
from:
http://www.rand.org/pubs/technical_reports/TR552.html. [Accessed: 6.7.2015]
Schach, S. (2002) Object-Oriented and Classical Software Engineering, 5th ed., McGrawHill, 2002.
Schneider, E., Jack M., and Guralnik, J. (1990) The Aging of America Impact on Health Care
Costs. Journal of the American Medical Association. (JAMA) May 2, 1990, Vol 263,
No. 17 .
Senge, P. (1990). The fifth discipline: The art and practice of the learning organization, Doubleday, NY.
Suo H., Wan J., Zou C.
& Liu J.(2012) Security of Internet of Things: A review. 2012
International Conference on Computer Science and Electronics Engineering. P. 648651.[Online]
Available
from:
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6188257[Accessed
28.12.2015]
Telefonica (2015). Telefónica, Orange, Engineering and Atos join forces to push common
standards for Smart Cities based on the Fiware platform. [Online] Available:
http://pressoffice.telefonica.com/jsp/base.jsp?contenido=/jsp/notasdeprensa/notadeta
lle.jsp&id=0&origen=portada&idm=eng&pais=1&elem=21261 [Accessed: 12.10.2015]
THL (2014). Huono tietojärjestelmä on aikasyöppö Tiedote 28/2014 20.5.2014, Helsinki,
[Online]
Available
from.
http://www.ttl.fi/fi/tiedotteet/Sivut/tiedote28_2014.aspx.
[Accessed: 10.11.2015]
Toppeta, D. (2010). The Smart City Vision: How Innovation and ICT Can Build Smart,
"Liveable", Sustainable Cities. The Innovation Knowledge Foundation. Available from
http://www.thinkinnovation.org/file/research/23/en/Toppeta_Report_005_2010.pdf.
Tran P., Douglas G, & Watson C. (2005). Joint Interoperability Certification What the
Program Manager Should Know. Joint Interoperability Test Command, 30 Nov 2005.
[Online] Available from:
3.6.2015]
http:// jitc.fhu.disa.mil/jitc_dri/wtpmsk.pdf. [Accessed
127 (127)
UKGIG (2013). Interoperability Glossary, version 3.0 December 2013. [Online] Available
from:
https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/270600
/glossary.pdf. [Accessed 1.10.2015]
W3C (2015). World Wide Web Consortium Process Document, 1 September 2015 [Online]
Available: http://www.w3.org/2015/Process-20150901/ [Accessed: 10.10.2015]
Webb, M. et al. (2011). Information marketplaces, the new economics of cities. The Climate
Group, Arup, Accenture, Horizon, London.