1 INTRODUCTION

The TAHI Open Architecture (TOA) defines a methodology of service delivery and operation between the Service Provider and the Residential (and Commercial) premise and of services and applications within it.
The TOA analyses the ‘person to machine’, or ‘machine to machine’ elements of a service by:

• “deconstructing” it into its supply chain entities,
• creating unambiguous description of all the elements,
• linking up all the objects,
• making the objects work together,
• creating an application model
  

TOA describes all the entities in the Service Supply Chain and the relationships between them that are involved in the delivery and operation of a service. It allows the Service Provider to model and match a service to the customers' needs and the physical requirements and constraints of the service, the systems and equipment in the service supply chain and the requirements and user interfaces of the consumer.

The TOA is a methodology rather than a prescriptive set of requirements, it can accommodate any technology, protocol, standard or specification that may be encountered within the Service Supply Chain. The methodology, however, provides a consistent way of handling services and their applications that allows the application, understanding and interaction of many different technologies, protocols, standards, or specifications within any particular service.

Arising from this work and parallel work in ISO, CENELEC and the SmartHouse Code of Practice TAHI has changed the emphasis of the TAHI Open Architecture towards an Interoprabiity Framework. and has changed the group name to the Interoperability Group.

2 PREAMBLE

In any service or application whether provided remotely or existing solely within the home environment there are a set of entities that relate to the creation of information or data, its processing, aggregation, understanding, delivery, actions based on information received and display to some user or operator.

For any service or application it is necessary to describe the properties of any device, user interface, system, protocol or network and its requirements and also the requirements of any service or consumer using a service.

For any service it is necessary to ensure that the requirements of the service and its delivery and use are met at all relevant stages of the service supply chain.

That some services require quite different delivery characteristics for control and delivery.

CONSIDERATIONS FOR INTEROPERABILITY

In considering the General Requirements for an Interoperability Framework a number of items need to be specified. These are:

1. How things are described - It is important that any taxonomy or set of descriptions follow a replicable methodology. The TOA work on Remote Service Objects provides an outline for this and there is work in progress in ISO/IEC JTC1 SC25 WG1.

2. How actions and applications are controlled and initiated.

3. How the specifications of applications and services are validated - The TOA work on Pervasive Service Agents provides an outline on how this can be done.

4. What the data flows are and how the actions applications can be documented - work from the Home Equipment section of the CENELEC SmartHouse Code of Practice provides a useful insight to a variety of Use Cases.

INTEROPERABILITY FOR SPECIFIC CASES

For the specific cases, it is important that the general requirments translate to specific requirements. A draft document describes some of the general requirements and can be downloaded by clicking here. Work is progressing in the Energy Management and Sustainability Industry Sector Group to define the requirments for Energy management and specifically the interoperability of Smart metering.

OUTLINE OF THE TOA

• an eleven layer set of entities to define the stages through which a service or application may be set up and delivered
  
• Remote Service Objects to describe the properties of objects (of any sort) that are in the environment of the service.
  
• Pervasive Service Agents that ensure that for any particular service or application all the requirements of the delivery and provision of the service or application are met.
  

The various stages in a transaction can be split up into parts representing stages in the service supply chain. Usually these stages accord with specific entities (organisation types, systems or devices) in the service supply chain.

Figure 1. The TOA Service Supply Chain

Each Service Supply Chain Entity (or Functional Bock) in the TAHI model (see Figure A1 above) has a relationship with the next/previous entity in the chain that may be defined in a Service Level Specifications and may be:

• Technical or physical and be described in terms of information interchange standards and specifications between the entities
• Commercial and legal and described in terms of service level agreements for a certain level of service, rate of information interchange, integrity and reliability and at agreed terms and pricing
  Legal in terms of the ownership of the information passing between the entities and the rights of the owners of the information.
• Trusted and secure in terms of there being an end to end and trusted channel of information that each entity in the Service Supply Chain must support
• There are also requirements in terms of safety, radio frequency emissions and all the legal and standards requirements that apply to any entity in the Chain

In the context of a service, this relationship has the responsibility of ensuring that the Service Level Requirements (SLRs) of the service are maintained in terms of:

• Quality of Service (QoS)
• Security,
• Integrity
• Priority of service
• Rights
• Value and Income from the transaction

In some services or applications some entities may be omitted or adjacent entities may be amalgamated.

However, the usage of the Service Supply Chain model is not necessarily confined to organisational trandactions and requirements. The model can equally be applied to the stages in an application where there may be some form of information source (Content Creator/Provider), various ways on which the information is delivered and acted on (Service Creator/Aggregator/Operator, Network Operator and Subscriber/End User).

A service may either be “end to end”, such as the delivery of audio/visual content to an end user. Alternatively, it may consist of an application where continuous loops of transactions continue and only break out of the loop if some specific event triggers an external transaction. This second case might be where a sensor is being monitored by an application, which itself creates new content for an alarm which in turn triggers a new application.

There is no reason why a service might contain sub-services or applications which in turn have their own service supply chains. In many cased there will be multiple autonomous processes being carried out in parts of the Service Supply Chain and because of the inherent communicability of the system there will be aspects of the systems that equate to GRID computing technologies.

In both cases, there is a supply chain for an application or service that has Service Level Requirements applied to it and is about the functional blocks necessary to create a business ecosystem. These relate to the interconnection of human or system competences between one or many people or systems in the service supply chain. It is possible to augment the Functional Blocks/Entities in the supply chain by subdividing them where this is considered necessary for a better understanding of the service (or even to amalgamate two or more of them). (For instance, the EU project TEAHA defines 14 Entities in its Service Supply Chain).

However it is important to note that relationships between blocks are not defined in terms of interface protocols, but rather in terms of Service Level Agreements/Requirements.

Some of the service level requirements relate to the transmission and interconnection of data between networked applications and in this case, the OSI model, which is about the functional stages which are necessary when creating and using a data connection, is used. At the top of the OSI model (stack) are the applications [i.e. the software the user sees] themselves, and at the bottom is the physical medium used to make the connection - copper, fibre, radio or whatever. Information travels down the stack from the source application, then across the physical medium before being passed up the stack to the receiving application at the other end. The OSI model relates to the interconnection of technological competencies between two locations. The OSI Model may be used wherever in the service supply chain a data communication has to set up and maintained.

The OSI Model is not comparable with the TAHI Service Supply Chain but is likely to be used by entities within it. See Figure 2.

Figure 2. OSI Model (From Wikipedia)

One similarity between the two models is that in order to have a complete and functioning system, it is necessary to provide the functionality of each and every stage. However, it is possible to define some of the stages as not doing anything (for example, the Content Provider function may just be a direct link between Content Creator and Content Aggregator.) Nonetheless, the function exists, even in this minimal form. (A similar example from the OSI model would be a "null" Presentation layer, which passed data unchanged between the Session and Application layers.).

Where confusion arises is that the implementation of a TAHI ecosystem will use protocols which use, or relate to, the OSI model. For example, TAHI Remote Service Objects communicate using TCP/IP, which is an OSI Transport-layer protocol. A typical implementation of the TAHI/TEAHA stack might involve many applications of the OSI model to effect the necessary data connections. Unlike the OSI model, the TAHI/TEAHA service supply chain could be equally well implemented with pieces of paper passed from one participant to the next provided this implementation met the Service Level Requirements agreed by all the commercial and technical entities in the supply chain

Remote Service Objects

Remote Service Objects describe the physical and logical parameters of Services, Networks, Protocols, Hardware, Software and the requirements of the End User and the User Interface in the deliver of a service or application. Thus, as shown in Diagram 1., RSOs may be present anywhere in the domain of any service or application. This section defines how RSOs execute this description.

Figure 3 shows how RSOs may be abstracted;

Table 1. RSO Descriptor Table Showing a possible way of representing all the information required for the RSO of an object.

Looking further into RSO Identities, the identities may be subdivided into classes by sector or function or by the source of the underlying forum or standard specification to which the object complies. Such Taxonomies might look like Figure 4:

Figure 4: Possible taxonomy based on classes of objects

or in the case where the underlying standard, protocol or spefifying forum/consortium provides the bulk of the descriptor like:

Figure 5: Possible taxonomy based on underlying specification.

Note that in Figures 4 and 5 any one of each column of types can have sub identifiers and attributes and that each of the these sub-identifiers will have "standardised" descriptions and profiles. Note also that an RSO can specify and describe the service itself (perhaps in an XML schema) but that any other element in the service supply chain may also be described as an RSO.

Pervasive Service Agents

Pervasive Service Agents regulate the provision of the service according to the parameters, attributes and requirements of the Service RSO. (Alternatively there may be a Service Operator or Service Provider RSO for specific services).

A PSA has to ensure that overall the parameters, attributes and requirements are satisfied, but also associated PSAs will ensure the SSC entity to SSC entity relationships and associations between RSOs for local system objects are also satisfied to ensure the integrity of the passage of the service or operation of the application.

A PSA therefore has to be able to inspect and check the relevant parameters, attributes and actions. Diagram 4 shows how PSAs may be abstracted and Diagrams 5 and 6 show how this can allow an application to be described, managed and diagnosed in abstraction remotely as well as locally.

Figure 4 PSAs

PSAs might form part of a Multi Agent System that support any service or application and activate, monitor and terminate any service or application. A service or application will be defined in a profile (XML Schema) that will identify the Service Supply Chain Entities required, the underlying RSOs (objects) and their necessary attributes (QoS) and launch PSAs to intitiate, monitor, control and ultimately terminate the service or application.

RSOs and PSAs provide an abstract view of the object it describes and may be represented:

• remotely in the service operator system that controls the service or application
• by proxy in the Residential Gateway
• or, as addressing reaches further into the home, by the actual device directly.

Essential data for an RSO are:

• An unique ID
• A recognisable name
• A description method that complies with the RSO application domain

One option for representing the RSO is shown in figure 2 below.

Figure 5a. Basic abstraction

Figure 5b. The whole picture

In this "whole" picture as shown in Figure 5b, there is some form of application or service active in a domestic premise. This is represented by the 4 linked objects. Because they can be described and identified, they can be represented remotely (or in abstract from the actual application) in a Service Provider's Management System.

This in turn means that the active application can be observed by an operator at the Service Provider's Offices (a). In normal operation the application is monitored by the Management System (b). and this only takes action if some exceptional event takes place.

Because of data traffic considerations inherent with any application working typically in several thousands of homes, it makes sense to Proxy the activities of the monitoring systems back to a device in the premises. In this case it is proxied back to a Residential Gateway (c), however, the application could be autonomous in which case the monitoring would be proxied back into the application itself (d).

BENEFITS OF TOA APPROACH

The TOA allows a service provider to manage and maintain applications within the home remotely. This is a great benefit for Energy Management and Smart Metering and is of use to any prospective application or service that may be delivered into the home. With the home based user's permission, for instance if a new service is being considered, the service provider can "look at" the available devices in the home and may be able to offer a more efficient service by utilising devices that are already installed rather than the alternative of simply supplying a duplicate set of devices.

The TOA approach also provides the basis of an Interoperability Framework since:

• it enables understanding of the supply chain
• it ensures that all devices and systems in the home and the networks to the home are identified and can be modelled remotely
• it has in its PSA a method of ensuring that Service Level Agreements are followed and ensure the service is always delivered the required specification. If it is allowable, the PSA can also negotiate graceful degradation of a service in the case of partial or total component failure.

USE CASE FLOWS

Another useful methodology is the Use Case information Flow diagram developed for the Home Equipment Section (3.7) of the CENELEC SmartHouse Code of Practice, This provides a matrix of object to object flows and identifies switches and linkages.

Figure 6. Use Case Flow Diagram.