You are here: Resources > FIDIS Deliverables > Interoperability > D4.1: Structured account of approaches on interoperability > 
Case study: eID projects, from capability to use  Foreword
CASE STUDY: THE INTEROPERABLE FUTURE OF AMI ENVIRONMENTS
 Conclusion

 

Case study: the interoperable future of AmI Environments

Mark Gasson, Reading; Wim Schreurs, VUB; Sabine Delaitre, JRC 

 

The scenarios described thus far have been limited to IMS technologies that are already established, in essence where issues of interoperability within the identity context have already been addressed, or are now causing problems because of a lack of co-operation in this area. However, in order to explore more fully the importance of interoperability, in this section we shall extrapolate existing technologies and consider a further scenario in which emerging technologies are prevalent. 

 

 

Ambient Intelligence environments 

 

The emergence of both the internet and wireless network technology, and with them the possibilities of distributed computing, i.e. using several computing devices that are not necessarily located in the same geographic location for a specific task, has had a profound effect on our way of life. Building on these advancements, Ubiquitous Computing (Weiser, 1991) is the next wave of technology, a paradigm shift from our current relationship with technology, whereby many thousands of wireless computing devices are distributed in the environment in everyday objects around us. Ubiquitous Communication will allow robust, ad-hoc networks to be formed by this broad range of mobile and static devices, forming a ubiquitous system of large-scale distributed networks of interconnected computing devices. By adding intelligent user interfaces and integrating sensing devices, it is possible to identify and model user activities, preferences and behaviours, and create individualised profiles. These key aspects are all required to achieve the idealised Ambient Intelligence (AmI) Environment, a concept which has been formalised by the European ISTAG.

 

The aim of the AmI environment is to provide a context aware system, using unobtrusive computing devices that will improve the quality of people’s lives by acknowledging their needs, requirements and preferences and thus acting in some way on their behalf. To achieve this, the ‘intelligent’ environment, or rather an intelligent agent within the environment, needs to build up a profile of each individual, and be able subsequently to link the profile with the correct individual. In essence, the environment has become the interface to the distributed, seamless and invisible AmI. In a world where computing is truly ubiquitous, the environment will monitor direct interaction of people with objects and profiles will seamlessly follow the individual to whom they are linked.

 

The concept of AmI provides a wide-ranging vision of how the Information Society will develop. Certainly the emphasis of AmI is on greater user-friendliness, more efficient services support, user-empowerment, and support for human interactions. However, to achieve this, the differing facets of the AmI system need to be interoperable. 

 

 Interoperability issues

 

The issues relating to interoperability in AmIs have three key dimensions: Political/social (informal), formal and technical. 

 

The AmI infrastructure is built on the notion that ad-hoc, complex, heterogeneous networks can function and communicate in a seamless and interoperable way. Only in this way can the broad range of services envisaged be offered to the individual. Essentially, the AmI is expected to embrace the heterogeneity arising from the different network technologies such that it appears homogeneous to the user. The vision is to allow for co-operation between networks on demand and without the need for offline negotiation between network operators.

 

The importance of this was underlined by the ISTAG, who identified three key breakpoints for AmI development . Notably, the first of these is:

 

“… under the requirement that AmI calls for a very flexible and seamless interoperation of many different devices on many different networks, it is a key requirement that there is a set of common platforms or de facto standards to permit this interoperation to take place.”

 

The group felt that this would either be achieved through a deliberate effort to develop such open platforms or would arise from proprietary pacts between industrial suppliers. 

 


Figure : The MultiSphere Reference Model [showing various layers of interaction desirable in the AmI scenario

 

The scale of this issue is highlighted by examining the levels of interaction that may occur between the user and technology within this AmI context. The ‘MultiSphere Reference Model’ is shown in .

 

Although this model is aimed primarily at putting issues and ideas of wireless communication in context, from it, and similar models, the following interaction levels can be identified: 

 

 

  1. Body area network (BAN) connecting sensors, chips or devices attached to the 

body/clothes or implanted in the body (distance: <1 meter) 

 

  1. Personal area network (PAN) consisting of personal and/or shared devices or 

peripherals (distance: <10 meters) 

 

  1. Local area network (LAN) for the nomadic access to fixed and mobile networks, and to the Internet  (distance: <100 meters)

 

  1. Wide area network (WAN) for the access and routing with full mobility (worldwide access) 

 

  1. The “Cyberworld” where users and intelligent agents interact (virtual) 

 

 

Within an AmI environment, a seamless interoperability between these different network levels, by proprietary devices from varying manufacturers, needs to be realised. This is only possible if the network technology used is able to support systems integration (i.e. through standard protocols). Already a number of standards for open communication in sensor networks have been proposed. Efforts to make buildings smarter are focusing on cutting costs by streamlining building operations, such as lighting and air conditioning. The most common networks are the BACnet and LonWorks standards, developed for building automation. These standards are geared towards well-defined application areas, and are built on top of well defined network structures. The net result of being so application specific is that many of the visions for AmI cannot be implemented on such systems. In practice, from the technical viewpoint, this may indicate that the AmI scenario is already running into issues of interoperability. 

 

To fulfil the full AmI vision, it is proposed that the AmI acts according to the user’s preferences, needs and expectations, thus profiling is the key stone of this scenario (see FIDIS deliverable 7.3 for more information on this area). From an implementation perspective, the agent is the embodiment of the profiling aspect which attempts to build a comprehensive profile of the user by monitoring their interactions, behaviour, preferences, and essentially ‘learning’ by interpretation of these events in their context. From a purely pragmatic viewpoint, the agent needs to interact with or ‘read’ from the environment to retrieve data and with services to provide the user with the desired level of support. The key to successful development is the ability to offer interoperable systems such that the agent can ‘data link’ independent events or stored information with a specific profile. It is reasonable to note here that ultimately the price for such increased interoperability is likely to be borne by a decrease in potential user privacy as personal information becomes readily and widely linkable. In addition, a standardised and interoperable agent that is abstracted from the underlying hardware such that it operates irrespective of the medium it is running on is required. Finally, the actual services the agent may need to access have to be useable by the agent with the data that it can acquire. 

 

Whether people ultimately find this level of ‘surveillance’ acceptable is an interesting social question. Either way, it will only be possible provided legal and other interoperability agreements can be constructed. From a legal point of view, an important distinction exists between the notions of ‘technical regulations’ and ‘technical standards’. Technical regulations are created by authorised public authorities and are in principle binding. Most problems of interoperability are however not solved via technical regulations, but via technical standards. Technical standards are prepared by all interested parties (companies, consumers, workers, public authorities) on the basis of a number of principles (e.g. consensus, openness and transparency). Although they can be very important to solve problems of interoperability, they are in principle not binding. To make these standards legally binding, they have to be included in legal acts. To this end, the most important EU legislative act is Directive 98/34 on technical standards and technical regulations in information society services. This directive imposes a detailed information procedure for technical standards and regulations. However, to date the only related EU standard is laid down in the Directive 1999/5/EC on radio equipment and telecommunications terminal equipment and the mutual recognition of their conformity. Such standards directly relating to AmIs are still yet to be realised.

 

 

 

Case study: eID projects, from capability to use  fidis-wp4-del4.1.account_interoperability_02.sxw  Conclusion
11 / 15