SOFIA: Opening embedded information for smart applications

Petri Liuha(1, Juha-Pekka Soininen(2, Raul Otaolea(3 1)

petri.liuha@nokia.com Nokia Research Center, Finland

2)

juha-pekka.soininen@vtt.fi VTT Technical Research Centre, Oulu, Finland

3)

raul.otaolea@esi.es European Software Institute, Spain

Abstract— In this paper we will present the principle of an Open Innovation Platform for smart environment applications. The enabling technologies for both computing and communication have matured to a level where cost efficient use of embedded, ubiquitous technologies makes sense. Thus, it is feasible to start realizing the concept of Smart spaces that has been widely studied in ubiquitous computing, ambient intelligence, and future Internet research.

From the user aspect, continually evolving information and communication technologies (ICT) touch nearly every aspect of our contemporary life. Introduction of new applications or services must address the human dimension of technology. In the ambient services that use ubiquitous technologies, this human technology interaction will in nearest future extend to much more complex field of everyday life that it has been so far.

In Artemis programme, the SOFIA project is addressing the challenge of creating smart environments. The project target is to make information in the physical world available for smart services in embedded and ubiquitous systems.

As core element we will present a software platform called Smart-M3 as cross-domain and cross-platform interoperability and information exchange platform between multi-domain embedded systems. Secondly, we will present the application development framework for applications that use information from different embedded systems.

Keywords- smart enviroments; information interoperability; ontology driven application development

I. INTRODUCTION Users today have electronic devices dedicated to perform a

limited number of functions defined by the manufacturer of a device. These devices often have data and functions that can be useful if made available to other devices in the user's environment. By doing so, they can enable more smart use cases than the manufacturer of a device could have foreseen. Although this would add value to the user and could also e.g. help energy efficient solutions, it is not feasible today because

the manufacturers of electronic devices do not have platforms and standards for such open devices.

Service oriented architectures do provide some solutions but leave much to be desired for low resource devices, which in some cases also have to cope with changing context such as a physical movement between home, city or personal environment and still provide the user with trusted functions in a uniform and predictable manner. It is very important for a user to be able to understand and operate devices and functions in his environment. Presently many users are not even aware of all the functionality that is embedded in a device, mostly because it is too complicated to access it. Furthermore, a user must not be obliged to interface and control his devices differently while at home, on the move in a city or in his office. It is very important that a platform enables evolution inherently so that more and more functionality can be provided by devices and by the environment incrementally. Also there would be resistance to an abrupt change that would require users to replace their present day devices with new or better ones from one day to another. Any new way of making and using electronic devices must not only evolve in the future but also take into account the existing devices and work with them seamlessly and ensure backward compatibility.

The SOFIA project is concentrated around the notion of smart space. A smart space is an ecosystem of interacting objects. Physically a smart space is formed by sensors, devices, and appliances that populate this space and it has the capability to self-organize itself, and to provide services and complex data to, for example, a person who physically traverses this space or a service that, queries remotely about the state of the entire space or part of it. This notion of immersion in the computing environment and at the same time the disappearance of computers is shared with the pervasive computing vision [Wei91]. Moreover, a smart space has to be able to elaborate on basic services and raw data to provide orchestrated services or mash-up data to be used by the external world. These smart spaces thus poses many new challenges to embedded systems technologies, in terms of dynamicity (smart spaces are intrinsically dynamic as they need to continuously adapt on the basis of the context, habits, etc., by

SmartWorld

ServiceWorld

DeviceWorld

KP

KP

KP

KP

KPKP

SNSN

SNANSN

Smart Spaces

Service Domain

Device Network

Serv ServClient

ServServ Client

Srv

Srv

Srv

Srv SrvClient

Client

Srv Srv

Srv

Client ClientClient

Dev

DevDev

SOI

SOI

SOI

SOI service ontologyinterpreter

Dev

Dev

Dev

Dev

Dev

DevGW

GW

GW Gateway betweennetworks

SIBKP

SIB

Figure 1. Separation of different levels of interoperability is needed in

creating smart environments.

adding/removing/composing on-the-fly basic elements), scalability (smart spaces can span from a small to a very large the number of sensors/devices/appliances), trust (some smart spaces needs to be organized around a number of trusted entities), and privacy (some smart spaces built around a house for example should pay specific attention to privacy preservation).

SOFIA project targets to define and open a completely new domain for technology and service innovation in a global scale. The main mission of the project is to make "information" in the physical world available for smart services in embedded and ubiquitous systems. As concrete results, the project targets to develop Open Innovation Platform (OIP) architecture and Application Development Kit (ADK). The key challenge is the interoperability between devices and embedded systems originating from different domains.

The paper is constructed so that Section II descries the principles and technical solutions for the information interoperability, and the Section III describes the Application Development principles and tools. Section IV gives some examples of applications..

II. SMART-M3 OPEN INNOVATION PLATFORM The Smart-M3 open innovation platform is an information-

level interoperability solution that enables multi device, multi vendor, and multi domain interoperability. It opens the embedded data in the devices and objects in our current physically accessible environment to applications so that they can create better and more cost, energy, and resource optimized services to users. The vision is that Smart-M3 opens the local information and together with Web services and Semantic web concepts revolutionizes the application development and application possibilities. Smart-M3 will be an open solution meaning that is freely available and modifiable, easy to integrate and to adapt into various products and systems.

The device interoperability can be divided into three separate levels in order to clarify the different needs of them as in Fig. 1. We need to have a capability to transfer bits between the devices shown at the bottom. The applications must be able to use the services also across device boundaries as shown in the middle. Finally, the information has to have the same meaning in different devices in order to be used correctly. In smart environment all the three levels must exist. From the practical ecosystem point of view the problem is the world is extremely heterogeneous. The variety of solutions is enormous and it is impossible to support them all or even small subset of them economically feasible way. On the other hand, the variety of technologies is needed in order to be able to create feasible solutions in all possible domains.

In smart-M3 we focus on highest level (information level) and rely on existing solutions for solving the service and device level solutions. The core concept is a common shared memory or information broker existing in the physical space, presentation of information using ontology models, and providing interfaces for legacy service and communication solutions. The information broker is exposed as a service in different service level solutions and accessed using the communication channels supported by devices.

The key benefits of our approach are that it is completely domain independent information sharing solution for objects and devices in the space. It is also possible to reuse and share the capabilities and information of devices and appliances that have different original purposes and uses in different domains. It is a use case and application independent. It is easy to build up complete user services step by step as the Internet. It also respects the device integrity, because the final choice for what information to share and how to use the shared information depends on the user or device manufacturer. It is an open solution. The information sharing is offered as a service for devices and applications. Openness makes it easy to include the idea even into simple devices and appliances. It is also open platform where information interoperability is based on common ontology. This enables the possibility to create mash-ups and other type of information, service and application collections in a completely new and yet unknown way.

A. Principles The main principle of Smart-M3 is that it focuses on

opening and sharing of information only. The interoperability agreement is done at the information level only. Common use case specific or domain specific ontology model as a basis of information and common Smart-M3 specific data format in the sharing are issues that need to agree with companies that develop products that participate in smart environment.

In SOFIA project several vertical use cases were analyzed and the main principles were defined. Most important ones were the open information, simplicity, providing information sharing as a service, extensibility, and being agnostic with respect to anything principles. In addition the typical principles related to creating usable platform were recognised. Examples are security, trust, privacy, scalability, quality management, ability to evolve, and support for legacy technologies.

B. Smart-M3 concept The information level view of Smart-M3 concept is

presented in Fig. 2. The basic information level elements are: 1) semantic information broker (SIB) is information world entity for storing, sharing and governing the information of one smart space. 2) Knowledge processor (KP) is an information world entity that processes information and contributes to

Semantic information

broker

Knowledge processor

Knowledge processor

Knowledge processor

Local information storage with RDF-store

and information governance functionality

Access protocol (SSAP), with basic operations, e.g. join, leave, insert, remove, subscribe. Etc.

Application logic and interface supporting the

use of common use case ontology and access to

information broker

Figure 2. Information level view on Smart-M3.

and/or consumes information content from SIB according to ontology relevant to its defined functionality. 3) Smart space access protocol (SSAP) is used by knowledge processors when accessing SIB. One or more SIBs create a smart space (SS) that is a named search extent of information. The simple operation principle of Smart-M3 is following:

1. Knowledge processors discover the SIB service (or Smart Space) using discovery and communication mechanisms offered by the device hosting the SIB.

2. KPs join the smart space using SSAP join message.

3. KPs access the SIB using SSAP insert, remove, update messages or react to changes of information they subscribed with respective message. The information is stored into the SIB.

4. Environment interacts with KPs in the way how it is design in applications that are in KPs (so, the smartness of the environment is actually programmed in the KPs)

5. The KPs leave the smart space using SSAP leave messages.

The Smart-M3 is meant for opening the information. It does not guarantee the performance and it is not meant for sending commands between devices (or KPs). That kind of interoperability should be implemented using service level capabilities.

Implementations of Smart-M3 provide a uniform, use case independent service API for sharing information in a Smart Space. The possibility to expose Smart Space service APIs concurrently through multiple domains and transport technologies makes the information currently isolated in multiple heterogeneous embedded domains available (i.e. to be monetized) by using web programming tools and methods without compromising power, safety and performance requirements of the embedded domains. As an example this would allow an application programmer who programs for a mobile platform to access contextual information in a car, home, office, football stadium etc in a uniform way and improve the user experience, without compromising real-time requirements of the embedded system.

SIB stores information in RDF (Resource Description Language) format, which is a W3C standard. RDF gives ability to join data from vocabularies from different business domains, without having to negotiate structural differences between them. It also makes the vast reasoning and ontology theory, practice and tools developed by the semantic web community available for Smart Space application developers.

The focus in the information level in Smart-M3 addresses value in application development by abolishing the need for a priori use case standardization familiar in service level solutions such as DLNA and Bluetooth. Furthermore, Smart-M3 shall abolish design time freezing of the address of the

used service API, as is the case of WebServices. We propose an ontology governance process as the alternative to use case specific service API standardization. In simple cases this would mean agreeing on common ontology models. In more advanced cases the ontology governance process would agree and adopt new vocabularies using RDF and RDFS (RDF schema) defined constraints. Additionally the vocabularies could be further constrained by domain specific ontologies. Finally, Knowledge Processors (KP) can actively monitor and update the information in the RDF store based on other kinds of reasoning rules.

C. Logical architecture of Smart-M3 based smart environment The logical architecture of smart environment (SE) based

on Smart-M3 IOP is presented in Fig. 3. The practical smart environment consists of one or more SIBs and two or more KPs. The participating SIBs have to share service and communication level solutions with each other and at least one solution (at service and communication level) with each KP in the smart environment. The KPs do not necessarily have to share any communication of service technologies.

Smart space application (which is something that interacts with physical world or user) is a logical collection of a set of KPs functionality (all KPs in smart environment do not have to participate). The requirement is that KPs either produce or exploit the information stored by one of the SIBs in the SE.

The requirement for having smart space applications is that the KPs and SIBs involved have common ontology model, data format, and information access solutions. Ontology model is a specified model of the information that defines the meaning of it. It can be either use case or domain specific also. Data format is RDF triplets (predicate, subject, and object) as explained in previous chapter. Information access solution is SSAP protocol. SSAP is basically a simple protocol that defines the basic messages (or service operations of SIB) between KP and SIB communication. SSAP is defined in more detail in Table 1.

The logical structure of the SIB consists of RDF storage and ontology interpreter and governance functions in addition to common parts. RDF storage is a memory (or database) for keeping the RDF triplets. The ontology interpreter and governance part can be divided into main three parts: the support for multiple SIBs, support for SSAP operations, and interfaces to service level.

TABLE I. SSAP OPERATIONS.

Name Description Join Begins a session between KP and SIB Leave Terminates the session Insert Inserts information into the smart space Remove Removes information from the smart space Update Combination of remove and insert operations Query Queries information within the smart space Subscribe Sets up a persistent query Unsubscribe Terminates a persistent query Results indication

Updates the result set of a persistent query

Unsubscribe indication

Notifies a knowledge processor of a smart space initiated termination of its subscription

Leave indication

Notifies a knowledge processor of a smart space initiated termination of the session

The idea in supporting multiples SIBs is that each Smart-M3 smart space can be constructed by physically distributed RDF stores. This allows implementations where the personal information of a family is stored at home but it is augmented by non-personal information in, for example, a weather service

and there may be copyright and privacy reasons not to merge the information. In order to enable these types of business models we are developing the concept of deductive closure towards distributed deductive closure. This work is currently in early phase.

The support for SSAP operations means the implementations of defined in SIB interface specification. The basic functionality is defined, but there are open issues related security, authentication, and query languages, for example. In query languages, the template query and Wilbur query are currently supported in reference implementation.

Interface to service level is needed for implementing the SOA specific functionality that is needed for communication.

The current status of Smart-M3 OIP is that the core functionality has been developed and published in open source at www.sourecforge.org in smart-m3 project. The idea has been tested in some examples and there are on-going work related improving of the performance and scalability. In addition, the usability of Smart-M3 as a solution in smart environments is being improved by developing solutions that increase the security and privacy features, allow run-time quality adaptations, and context awareness support.

III. APPLICATION DEVELOPMENT FRAMEWORK

One of the key points related with the success of a technology is the existence of a development life cycle and a SDK (Software Development Kit) that allow companies develop solutions based on this technology. This is the reason why the

Communication level

Service level

Information level

Existing communication solutions (protocols, physical layers, etc.)

Existing service solutions (service discovery, service registry, resource manager)

Ontology (use) support

Ontologyinterpreter and

governance

SIB1 KP1

Information storage

use case logic

KP2

KPI

SIB2-N KP3-N

Smart space applicationlogic

Smart space

Ontology model

Data format

Information access

Optional Optional

Common solution

Common solution

Figure 3. Logical architecture of smart environment.

development of an ADK (Application Development Kit) were scheduled from the start of the project. Thus, the community will have not only the Smart-M3 solution definition but also all the necessary tools to start programming smart application based on it.

As described in the previous section, the Smart-M3 open innovation platform is an information-level interoperability solution that enables multi device, multi vendor, and multi domain interoperability. This heterogeneity means that the ADK must include the possibility of programming in several languages and therefore different editors, compilers, debuggers, etc. Hence, the IDE (Integrated Development Environment) must have a great flexibility to include different needs and be extensible to fulfill any future requirements. Moreover, it should be also very intuitive and easy to use.

A. Smart Application Development Approach

The goals of the ADK are twofold. First, provide tools and APIs (Application Programming Interface) to develop Smart Applications. And second, hide as much as possible semantic technologies complexity and Smart-M3 to the programmers.

Even though semantic technologies are becoming more and more familiar due to semantic web, the reality is that their use are still more concentrated in academia world rather than in the industry. Because of this, we find that the community of developers is very skilled in programming languages but not in semantics. Hence, the ADK must provide some kind of solution that allows developers work directly with classes and not with ontologies. So bearing in mind this fact and also the goal of spreading the use of Smart-M3 to as much people as possible, the ADK includes the necessary tools and APIs to fulfill this important requirement.

One of the main problems to face during smart application development is how to model the ontology in order to have a lightweight class structure representing the concepts to be used in runtime. In our approach, we have divided the smart application in four layers (represented in figure 4) responsible for dealing with the semantic information stored in the SIB. The layer called Model is a class representation of the concepts defined in the ontology. To generate it, we are developing a tool called OWL2Classes based on templates. This tool is capable of translating from OWL to several programming languages and generates an API that interacts with below layers.

In the figure 6 the smart application layers are presented. The parts representing the KP are automatically generated, so the developer only has to add the logic layer to create a smart application.

Figure 4. Smart Application layers.

The four layers forming Smart Applications have different responsibilities:

• Logic. The developer is only responsible for this layer. The other ones are generated automatically by the ADK. Once the developer has chosen the programming language, the ontologies to be used and the communication protocols (this is done using a wizard), they only have to concentrate in developing the logic dealing with the API provided by the model layer.

• Model. This layer provides the mapping of the ontologies into classes. The programmers not familiar with ontologies or Smart-M3 translate all the ontology concepts (selected with other tools of the ADK) into classes in order to facilitate their use. The generated classes know how to map method calls to SIB calls. So from the point of view of the programmer they only see an API representing concepts (e.g. devices, sensors, actuators, capacities, services, etc.) and do not know anything about communication, SIB protocols or semantic issues.

• SSAP. This layer is an API with a set of classes to deal with the SIB. It sends and receives all the SSAP protocol messages to/from the SIB, and makes appropriate changes in the upper model layer. This layer does not know anything about the communication protocols (TCP/IP, Bluetooth, Zigbee, etc.) used to connect with a SIB.

• Connectors. This layer abstracts the communication protocols. The three main responsibilities are implementing the input/output operations in a given protocol, the discovery of the SIB and the management of a communication inherent errors like interruptions, timeouts, etc.

Although the layers are designed to cooperate among themselves, each one is completely independent from the upper ones. Therefore, a programmer can add abstraction as needed. For example, if they want to use only connection facilities they have to add connectors layer. If they do not want to deal with SSAP protocol, they can add SSAP layer. If they prefer work with classes instead of ontologies then they add model layer and so on. Anyway, the default and recommended way of development is to use all layers.

Let’s see an example. Suppose we have defined the following class definition and hierarchy in the ontology: <owl:Class rdf:about="#Event"> <rdfs:subClassOf rdf:resource="&owl;Thing"/> </owl:Class> <owl:Class rdf:about="#RawEvent"> <rdfs:subClassOf rdf:resource="#Event"/> </owl:Class> <owl:Class rdf:about="#SmokeEvent"> <rdfs:subClassOf rdf:resource="#RawEvent"/> </owl:Class> <owl:Class rdf:about="#Location"> <rdfs:subClassOf rdf:resource="&owl;Thing"/> </owl:Class>

<owl:DatatypeProperty rdf:ID="eventId"> <rdf:type rdf:resource="&owl;FunctionalProperty"/>

<rdfs:domain rdf:resource="#Event"/> <rdfs:range rdf:resource="&xsd;string"/> </owl:DatatypeProperty>

<owl:ObjectProperty rdf:ID="isLocatedIn"> <rdfs:range rdf:resource="#Location"/> <rdfs:domain rdf:resource="#RawEvent"/> </owl:ObjectProperty>

<owl:DatatypeProperty rdf:ID="value"> <rdf:type rdf:resource="&owl;FunctionalProperty"/> <rdfs:domain rdf:resource="#SmokeEvent"/> <rdfs:range rdf:resource="&xsd;boolean"/> </owl:DatatypeProperty>

<owl:DatatypeProperty rdf:ID="#reliabilityIndex"> <rdf:type rdf:resource="&owl;FunctionalProperty"/> <rdfs:domain rdf:resource="#SmokeEvent"/> <rdfs:range rdf:resource="&xsd;int"/> </owl:DatatypeProperty>

A class mapping from the OWL to Java KP Classes can be expressed as: public class SmokeEvent extends AbstractKP implements ISmokeEvent, KPProducer, KPConsumer { private String eventId; private Location location; private boolean value; public SmokeEvent() { } @Override public Location getIsLocatedIn() { return location; }

…

@Override public void setValue(boolean newValue) { Triplet removedTriplet = new Triplet

("SmokeEvent", "value", value); Triplet addedTriplet =

new Triplet

("SmokeEvent", "value", newValue); SSAPMessageParameter parameter =

new SSAPMessageParameter parameter.addInsertTriplets(addedTriplet);

();

parameter.addRemoveTriplets(removedTriplet); sib.update(this, parameter); } ... }

B. Life cycle development Once the architecture and all the stakeholders involved in the Smart-M3 solution are defined (e.g. SIB, KP and SSAP), a software engineering definition is needed to develop smart applications. The objetives to fulfill are:

• define the life-cycle development of Sofia Smart Applications.

• develop a cross-domain ADK.

• develop/integrate needed tools to cover each development phase.

All the solutions are based on the ODD (Ontology Driven Development) represented in figure 4. In this approach ontologies are used to model the context, devices, capabilities and services. This ontology is already defined by the ontology governance and developers use it to develop the smart applications. The ontology governance is responsible for defining, changing and evolving the ontologies that model the different domains. In order to manage them efficiently, four hierarchical layers have been defined:

• Foundational ontologies. This is the most abstract one. The goal is to include all the existing ontologies that can be useful to model the domains and use cases.

• Core ontology. Responsible for gathering all common concepts along the domain ontologies preventing overlapping.

• Domain ontologies. These ontologies define all the concepts, relationships and individuals of each domain.

• Application ontologies. This is the most concrete layer and defines the use case of a domain or inter-domain.

Once the ontology is defined, we use the ODD approach to create smart applications. It is formed by four main phases:

• Design. The start point is the ontologies. The developer designs the smart application in the smart modeler editor. The smart modeler is a visual editor to design the application using graphs, connectors, rules, guards and other elements of the tool. Once the design is done, the developer must concrete the target platform, the programming language (Java, Python, C or C++) to translate the ontologies to classes and the communication

protocols. After this stage, the KP is generated (the bottom three layers of the smart application). The model layer is created by the OWL2Classes tool that is transparent for the developer. After this stage, the appropriate editor, compiler and debugger are activated so that the developer can finish the logic.

• Implementation. In the implantation phase, the developer focuses in the logic of the smart application using the appropriate editor.

• Testing. To test the application a SIB simulator is needed. The SIB simulator is a tool included in the ADK so that programmers can check in real time the status of the SIB. Hence, they can see the correctness of the SSAP operations. This simulator is visual, so it is very easy and intuitive check the information stored in the SIB. As the only requirement to connect a SIB is follow SSAP protocol, it is guaranteed that the smart application will run correctly with other SIB implementations.

• Exploitation. Depending on the target platform, programming language and communication protocols defined in the design phase, the final executable to be deployed can differ. In this phase the suitable deployment units are generated.

Figure 5. Ontology Driven Development.

After investigating deeply all the different IDEs present in the market, finally we decided to use Eclipse as the base IDE for the ADK. The main reasons were:

The APIs provided are tested by the cross-industry consortium to ensure code quality portability and performance.

• It delivers the ability to create derivative works, including redistribution of the platform. The Eclipse Platform allows tools developers to focus on core competencies and new models for development technology.

• Timely response to the requests for changes and enhancements in a controlled and organized way through www.eclipse.org.

• It is the facto industrial IDE.

Eclipse is an open source framework that provides many of the underlying services software developers need. This would be the idea we were looking for, a "toolkit for designing toolkits." Not just a set of APIs, the framework consists of real code designed to do real work. In short, Eclipse is a multi-language software development environment comprising an IDE and a plug-in system to extend it.

The Eclipse Platform is the foundation for constructing and running integrated end-to-end software development tools. The platform consists of open source software components that tool vendors use to construct solutions that plug in to integrated software workbenches. The Eclipse Platform incorporates technology expressed through a well-defined design and implementation framework.

The ADK consist on an Eclipse module composed by several plugins that extend the IDE:

• Smart visual modeler. A visual editor to define the relationships between ontology concepts and SIBs.

• OWL2Classes translator. A tool to translate ontologies written on OWL/RDF(S) to several programming languages classes according to the smart application layer composition.

• Java editor. The very well known Eclipse java editor.

• SIB server and viewer. A localhost SIB simulator to test applications. The information stored in the SIB is presented visually in a windows plugged in the IDE.

• Sofia Project wizard. A wizard to gather all the smart application characteristics like ontologies to use, target platform, programming language, communication tools, project paths, etc.

In the figure 6 the architecture of the ADK is presented.

Figure 6. ADK Architecture.

The ADK architecture is divided in two main parts. The first one is the SIB (the server) which the smart applications

(the clients) can connect to. As Eclipse is based on OSGi, we decided to implement the SIB simulator as an OSGi bundle. Thereby, developers can use the SIB inside and outside the ADK to test their solutions. Eclipse relay on Equinox OSGi to gain dynamicity, so the ADK also exploit this benefit with the ability of plug future services as bundles.

Another great feature of Eclipse is that it is multiplatform. In fact, the development team responsible for building the ADK is programming in different operating systems (Windows, Linux and Mac OS X), so it is guaranteed that the ADK will run at least in these platforms.

IV. APPLICATIONS AREAS During the project real usage will be tested in three different applications contexts: personal spaces, smart indoor spaces and smart city. Each of these addresses specific requirements and constraints arising from their environments yet faces similar challenges in sharing information.

A. Personal smart spaces In personal environments, the use cases are typically dynamic and the area limited. Devices and their services can be developed throughout their lifetime, independent of each other. A “personal space” proactively creates a smart space around a moving person in order to enable this person to access and organize services and data around him. Envisaged services include support for efficient networking and interaction between people involved in mobile social activities (PMSN) and may involve smart storage and context-dependent handling of multimedia content in challenging environments, such as, for example, in cars. This is therefore a highly dynamic environment with on-demand trust and privacy requirements while scalability not necessarily is a primary concern

B. Smart indoor spaces In smart indoor spaces like e.g. smart office, embedded infrastructure equipment as well as appliances and personal devices can share information without being part of an integrated system. A smart indoor space has the target of self-organizing sensors and devices inside buildings to enhance their efficiency at several levels (e.g., energy efficiency, smart maintenance) and to enhance also safety, security, productivity and comfort of the occupants (e.g. residents, operators). Multiple actors with different profiles are involved in this smart space. Here, SOFIA will enable discovery and access to cooperating services tailored to the actors profile and context. This specific space has very strong privacy and trust issues while dynamicity might be a secondary concern.

C. Smart city Smart city is a very large application context, where typically public areas include different embedded systems, some of them critical or closed. Personal devices can access some of this information and the embedded systems further benefit from aggregated data provided to users in the space. A smart city is the capability of creating on-the-fly systems that are able to organize a smart environment around a public place, for example, for surveillance or monitoring purposes. In this case dynamicity and scalability are main concerns while privacy is less important here. Distinct smart spaces can overlap in space and time and challenging services that benefit from information in multiple domains will be supported by SOFIA.

V. CONCLUSIONS We envision an environment, where Embedded Systems (ESs) are able to connect, discover and enjoy personalized and cooperating services operating on interoperable, heterogeneous data. Connection at the lower level will occur through a SOFIA general overlay based on legacy connectivity and communication protocols that can be seen as the basic communication layer of the architecture. Logically this overlay can be formed by several islands of interconnected ESs. At a higher level of abstraction, each ES can participate to one or more smart spaces. ESs participating to the same smart are connected through a second level overlay. From an application viewpoint, ESs participating to a smart space overlay may provide services/data to another smart space. Also in this case the smart space specific overlay can be seen as several islands formed by interconnected ESs. SOFIA Open Innovation reference Platform will support the interworking of smart embedded services for creating and managing different smart spaces, through the use of composability and semantic techniques, in order to guarantee dynamicity, trust and scalability, while preserving privacy if needed. Moreover, the generality of the SOFIA architecture will be ensured through the identification of ontology for each of the smart space under investigation and by deriving a common ontology for all of them. This common ontology will lead to the layered architecture of the SOFIA platform and to the identification and specification of both, the core middleware and the smart-space specific services.

ACKNOWLEDGMENTS This project has been funded by the ARTEMIS Joint

Undertaking under Project contract 100017, and national EU member states part of the SOFIA consortium (Finland, Italy, Netherlands, Spain).