Taking the view that pervasive systems are more about mobile communicating devices than internet connected computers, we are using the notion of Device for addressing equipment. For a user the identity of the actual piece of equipment is almost always essential. "I want to take a photo with my camera", "monitor the pulse from that sensor (attached to Mr X)", or "print on the printer on third floor", as opposed to the view that any service would do. Using a unique id for the device for addressing is in contrast to using interface addresses (such as IP-numbers) since there might be several of these maybe using different technologies. This allows us to identify a Device irrespectively of the way it have been contacted, and change dynamically as networks come and go, which is typical in a mobile network.

Palcom uses a discovery protocol to find Palcom devices on a network. As a result each node builds up  table of the devices it has found on each network it is connected to, translating between DeviceID and the address of the device on the particular network. Palcom is thus self-configuring and detect devices as they become available and become unavailable. The communication between devices can thus use the different networks as they are available from message to message.

Each Palcom device can provide a set of Services that other devices can connect to.  A service comes with a description of its interface, what messages it can send or receive, parameters etc. It is up to the user of a service to adjust to its interface. There is thus no standard for services, but new services can be invented as needed.

A service can be used in two ways. The description of a service interface can be used to render a user interface which allows a human to directly interact with a service using a browser. This is useful for finding out how a service works, make sure that a service still works, and sometimes services are just what you need.

A service can also be used as a programmatic interface. Connections to services are collected in an abstraction called Assemblies. An assembly can connect to several services and each connection from the assembly is adjusted to the service in question. The actions of an assembly are defined by a script in the assembly. It has the form of actions specified as reactions to incoming messages. Reactions can be of the form of sending new messages to connected services or storing/loading local variables. Assemblies can also provide new services, which other assemblies can connect to, thus providing a hierarchical structuring mechanism.

The discovery mechanism is limited to local networks (e. g. the part of an IP network available with broadcast, a BlueTooth network etc.). Such local networks can be bridged by devices with more than one interface which can act as routers between the networks. There is also a Palcom tunnel mechanism that can connect local Palcom networks and forward discovery and communication between them in a transparent way. The communication in a tunnel can be encrypted when desired.

Palcom is implemented in Java and is fairly portable. It runs on popular computers (Mac, Linux, Windows) and equipment such as Android phones and (some) AXIS cameras. It has also been integrated with dlna (making TV-sets etc available as Palcom devices) and 1-wire (making a variety of small and cheap sensors available as Palcom services).

Services are written in Java, while Assemblies are created with an Eclipse based Palcom browser and Assembly editor. Services and Assemblies can be installed in an execution environment (called theThing). Together these tools provide a fairly comprehensive development environment.

Design Principles

1. •Human in the loop to explore service functionality before automating behavior through assemblies.
   

2. •Explicit devices because device identity is fundamental in pervasive systems where the user interacts directly with physical devices.
   

3. •Peer-to-peer discovery to allow devices to dynamically enter and exit a local network.
   

4. •Self-describing services to allow combining unrelated services and to avoid dependence on out-of-date standards.
   

5. •Separating configuration from service implementation to make service configurations visible to users and to allow reorganization without changing individual services.
   

6. •Network independent addressing to allow users to build compositions based on logical interconnection of devices independent on physical networking technology.
   

7. •Local networks and tunnels to take advantage of the locality of the physical devices while at the same time open- ing the possibility to interconnect different such localities.
   

8. •Supporting a service interaction protocol to allow tunnel routing, remote interaction, and assembly mediation.
   

9. •Peer-to-peer asynchronous events as the basic communication mode, allowing both push and pull interaction, and to avoid the common performance problems of RPC.