Gear up for change

Forget the semantic web, the real future of the Internet is all about control.

Our current approach to problem solving in engineering is flawed.

When asked to describe the Internet in two words, many might say 'sharing knowledge'. But 'sharing information' is a more accurate description. All the principal ways in which we use the Internet - Web, email and media streaming - happen to be examples where information is knowledge.

But IT has another side where information means software and the control of how things work. The Internet is the driving force in the IT industry, so why isn't it also known for sharing control?

There are examples of specialised, one-off software applications interfacing with each other via the Internet, but there has yet to be any systematic and universal attempt to exploit the potential of the Internet for managing control in the way we have seen it for knowledge.

Half of the Internet story is still going missing - a dynamic, parallel world to the Web that we'll call 'The Mesh', since the term is apt both in the network and meshing gear wheel sense.

A universal tool

There are a number of research areas working on the control issue, but each one is limited by a narrowing focus. Think of universal usability (user focus: customisation, personalisation); ubiquitous computing (hardware focus: interoperation of disparate devices); and grid computing (software focus: processing distributed across networks).

So what would it take to create a tool that would provide a global means of control, encompassing and integrating the needs of users, hardware and software represented by all these research areas?

Given that these research areas are finding it tough to make headway, such a vision seems impossibly challenging. But herein lies the clue to the way forward: our approach to problem solving in engineering is flawed.

We treat issues such as customisation, interoperation and distributed processing as separate problems, only solvable through the creation of special mechanisms.

But invest the underpinning programming language with the inherent capability to resolve issues like these, and the subsequent need for band-aid solutions disappears.

Emulating the web

In control engineering, the creation of a universal tool boils down to the design and deployment of a new type of programming language. The key to everything is simplicity.

We follow the successful role model of the Web: a universal application and a common language for information exchange. The Web browser installed in every computer for displaying HTML files becomes the Mesh engine installed in every device for running files in our new language.

Nowhere is the slow rate of progress more apparent than in universal usability. A one-size fits all approach in user interface design can never be the answer, since everyone has different needs. Flexibility is the key, but this goal is impossible once a user interface is coded as a conventional, monolithic program.

The answer is to make the user interface modular so that the pieces can be assembled in different ways to complete the final picture. Current efforts focus on a top-half operated by the user and a bottom-half running the device, the top-half customising device operation for a particular user situation, modality or platform.

The Lego principle

To achieve maximum flexibility, we need our language to be structurally very simply, so that modularity can extend down to the smallest block of code. It's the Lego principle, with a twist.

We make all code bricks syntactically identical, enabling a program to be built up by the robust and easily implemented method of arranging bricks next to or within others.

Each brick, however, remains functionally unique. It is able to represent anything from a single variable assignment to the entire program definition, its intended role known from its position in the program in a DNA-type of approach that maintains flexibility by not hard-coding such information. This makes for extreme scalability.

We could build up a user interface from a DIY kit of parts representing various user features. We are free to choose between a simple or sophisticated operation - even for something as simple as a domestic fan (bricks for speed control, panning control, sleep mode timeout, overuse protection, child safety keylock...).

By controlling scope within a program, code bricks could have far reaching effects on program execution. Imagine a brick containing all the necessary logic for implementing Nokia's profile feature in mobile phones.

To enable profiles, it would be enough to add this solitary brick to a phone's user interface despite the fact that profiles need to be closely interwoven with features already programmed into the phone such as menu structure and calling procedures.

Despite advances in microelectronics and network technology, ubiquitous computing is still languishing for want of a coherent method that allows disparate devices to interact.

To meet this challenge, our language needs a way of abstracting the hardware capabilities of any device and making these abstractions readily accessible in a program.

We achieve this by creating an abstract hardware layer in which each hardware/firmware feature is represented by a simple programming variable. For example, our fan might have the string-type variable Key with Up and Down states, and the decimal-type variable Motor in the range 0 (fan off) to 1 (maximum speed).

With their semantics handled by the abstract hardware layer, such variables are free to be used like ordinary variables anywhere in the code making up the control logic of the program. Hardware is thus able to be controlled without any knowledge of how it physically works.

Exploiting device capability

The abstract hardware layer acts as a great leveller, facilitating ubiquitous computing by standardising how device hardware is viewed from within a program. Motor, for example, could meaningfully represent any type of motor, regardless of differing physical or electrical characteristics.

Programs could even be written to anticipate the future by integrating the control of non-existent hardware into device operation. Should the hardware subsequently be installed, it would instantly work as intended without software modification (our fan gets an LED indicator in a model upgrade, for example).

By capturing everything that a device is physically capable of doing, the abstract hardware layer introduces the idea of hardware reuse: hardware features reused so freely that they provide the user with what seems to be a different type of device altogether.

In the mobile phone example, a single code brick could reconfigure the handset to work as a paging device where even the incoming call procedures and keypad worked differently.

We give each code brick an optional name that other code bricks can reference. By basing this name on the Internet address of the device and nested name-spacing within the program, any part of any program becomes globally identifiable.

Code bricks can now act as dedicated Web browsers for downloading and inserting software at specific program locations, giving us the means to automate the process of program creation from a global list of software parts.

We might choose to have a user interface stitch itself together with the latest user features each time the device is switched on. If this self-updating process is allowed to run during program execution - and code bricks at remote locations are subject to change - then an executing program can systematically and purposefully morph into a different program without apparent intervention.

Taking control

Since a code brick is uniquely addressable, so too are its variables. This makes it possible for one program to invite control by another through setting up dependencies in its code, based on the states of variables accessed from the remote program (programs are never allowed to impose control).

The control schemes that can be set up using such logical program linkage are limitless. Our cheaply manufactured fan with no means of detecting the temperature could be made to switch on automatically on hot days by using 'virtual hardware' - a thermometer reading provided by a weather bureau.

A household of fans could be made to operate as one regardless of which keypad was used, or in planned symphony by panning in sequence, or according to some integrated master/subunit scheme.

But devices don't have to be similar in design or function to interoperate in ways like these. A fan could just as easily be linked to the operation of a microwave oven, or indeed to some executing program that had nothing to do with device control at all.

Build concurrency into our highly modular and intrinsically networkable language, and we can use it to parcel out code bricks for execution in other devices - the goal of grid computing.

Conventionally, grid computing only allows limited information sharing between threads. But no such restriction applies here, the approach being more akin to concurrency in a conventional programming language seamlessly extended across a network.

Mesh power

The Mesh would embody all the successful, empowering features of the Web. Everyone would have a say in how things work, mirroring Web 2.0 user-generated content but for software instead of media. Like the Web, the Mesh would become a force for social change, but centring around themes of control rather than knowledge.

The Mesh would change how we go about software design, leading to greater efficiencies for users, programmers and manufacturers alike.

Software would become a tradable commodity. Internet sites offering user interface parts for all types of device would appear. Users would be able to craft their own software designs as if ordering toppings for a pizza - or at least have this done for them. Controlling the electronic gizmos in our lives would become easier because of this extreme ability to personalise.

Globally accessible control information would allow new ways of doing things. Tedious tasks like manually resetting the time in appliances following a power cut would no longer be necessary as they would be performed automatically by referencing the relevant information online.

The connectivity provided by the Internet would open the door to new programming practices, allowing everyone to play their part according to interest and ability. A user might download code bricks of user features from a shareware site that contained embedded references to code bricks at a manufacturer's site for lower-level functions such as device malfunction detection - demonstrating that scalability isn't just a feature of the language but is reflected in the players involved in the programming process too.

API methods wouldn't have to be physically located on the platform where they were called. A single, centralised API resource could serve the whole of the Mesh, effectively raising every device, however basic, to the level of a programming platform.

The threat of malicious and unreliable code would be addressed by emulating the growing number of innovative Web-based techniques for ensuring reliability.

Shareware sites, for example, might follow the eBay model for trader reputation based on peer feedback.

Simple solutions

The Mesh would replace heavily engineered solutions with simpler alternatives.

Consider how a remote control in the fan example is simply achieved by making the motor in one fan dependent on the state of key in another. The conventional solution to the remote control problem is to create a special command language that reflects and overlays device operation - an approach that involves considerable programming effort, inefficiently duplicates information, and creates problems of its own (modifying the device may result in the commands no longer working).

This trend for simpler solutions would extend to the macro level too. For example, the need to write device-specific algorithms for modifying how devices work in adaptive systems would be replaced by a universal search engine for locating ready-made software solutions in the Mesh.

Conclusions

The Mesh is feasible using current technology if we are prepared to think differently.

I have focused on device control and user interface design, but the Mesh would serve any type of software application since it is underpinned by an abstract and general-purpose language.

In the same way that we think of the Web as seamlessly connecting databases of the world to provide a global font of knowledge, the Mesh would connect software of the world to provide a global means of control for all devices, machines and systems.

All examples alluded to are working solutions produced by a concept demonstrator in our research to develop the Mesh. The language was expressed in XML using four XML elements. The Mesh engine was created as a Java application.

Recent articles

Info Message

Our sites use cookies to support some functionality, and to collect anonymous user data.

Learn more about IET cookies and how to control them

Close