Control

Some objects are active. By active we mean they perform some operation on the physical world. For example, an oven heats, a refrigerator cools, a lamp lights and a saw cuts. All of these objects perform some operation on other objects.

Active objects are, for the most part, controlled by humans - either directly through manual interaction (such as a hand drill) or indirectly through simple programming (such as a microwave oven).

A unique capability of the intelligent infrastructure, is the ability of objects to communicate with each other. A bottle, for example, can "talk to" a refrigerator to tell it that its there and what it contains. Food can inform the oven to tell it how it to cook. In short, objects can control machines instead of the other way around.

A classic example is the bowl of fetticini (a passive object) that "communicates" its cooking instructions to a microwave (an active object) - all without human intervention.

We can use our infrastructure to communication, but what gets communicated? We need some control language that active objects understand and that passive objects can store and communicate.

We generally refer to this type of language as a task-level control language, in that it executes tasks - that is discrete, high-level functions - and control in that it actively regulates and response to objects and their environment.

In the following sections, we outline the design and specification of a task-level control language. We begin by using the planning and scheduling definition of the previous chapter as a starting point in the design of this specification.

Task

We begin with a fundamental element called a task .

The task includes an administrative information, which records general management information, such as author, owner and manager. The task element includes a list of states that describe the fundamental parameters of the task.

The task also contains a set of functions that determine its operation. These functions include a context function that ensures appropriate execution, an update function that recalculates the state parameters, an action function that sends commands directly to actuators (such as motors, switches, relays, solenoids, etc.) and a goal function that determines the successful completion of a task.

Name

Each task has a name specified as an argument to a label attributed.

This name is importance. It is used to identify the task to the task interpretation and management software.

Administration

The first element is an administrative element that includes information about authorship, management, ownership, etc. Task management may be distributed across the network, so that even simple administration, such as `who wrote this code' and `whom do I call when the code fails,' becomes difficult. The administration or admin element facilitates software management. The admin element includes one or more entity elements that contain this information.

<task>

<admin>

. . .

</admin>

</task>

We may also want to include general descriptions of a task and how it performs. Therefore, we also include one or more present elements within the admin element to describe and explain the particular task.

<task>

<admin>

. . .

. . .

</admin>

</task>

States

There are certain fundamental parameters that describe an object, such as the temperature of a refrigerator, the current in a heating coil or position of the washer door. We call these fundamental parameters states .

Some states, such as the temperature, cannot be controlled, they are simply measured. Others are under direct control, such as current in a heating coil or switch in a relay. We bundle these in an element called states .

The states element includes one or more measurement or msr elements, each signifying a parameter, name, offset, units and accuracy.

<msr label= string > offset </msr> State 1

<msr label= string > offset </msr> State 2

. . .

<msr label= string > offset </msr> State n

</states>

The label attribute is used to identify the state within the task, the value of the measurement provides the offset, the attributes ( m, kg, s, a, K, cd, mol, q, rad and p ) define the units and the min and max attributes define the accuracy or tolerance.

Implicit states

In addition to the state list given above, we also include a set of implicit states.

We include a global date specified, in accordance with the PML date definition, in milliseconds from Midnight Janurary 1 1970 GMT . This time may be accessed within the functions that make up the task function definition. It is refered to simply as date .

A second implicit state is the total execution time of a task. The execution time state records the total length of time a task has been running. This state is given the name time. The variable time is measured in milliseconds (in accordance with the PML specification) and may be reset at the discretion of control code.

Finally, every task has access to the activity of every other task using a state value nameActive, where name is the name of the task. The variable nameActive holds a boolean value that is true when the task is active and false otherwise.

All of the implicit states ( date, time and nameActive ) are automatically available within any function.

Subtasks

Many tasks can be broken up into subtasks - or "steps" in a process. Mowing the lawn, for example, involves opening the garage door, removing the mower, starting the motor, pushing the mower, etc. When the bag fills, stopping the motor, removing the bag and emptying the contents.

We wish to reflect this observation in the task definition by allowing one or more subtasks - or simply tasks - within the task element.

<task>

. . .

. . .

</task>

Since the task element can contain another task element, we define a hierarchical structure of tasks and subtasks, as shown in .

Function

A task definition requires of a set of functions. These functions are algorithms that control and monitor a task. Since these functions required generic control instructions, we need a software control language or access to a server running a software control language.

We will address these issues with a function element.

<function> . . . </function>

The function element contains either (1) in-line source code, (2) a reference source code, (3) a reference a class (i.e. compiled source code) or (4) a reference to a server process.

In-line source code

Since we require general, unrestricted control instructions, we defer to a well-established programming language - JAVA [ref]. Therefore we allow the function element to contain in-line JAVA source code.

<function> source code </function>

The source code here contains a single function that returns a boolean value

<function>

source code ;

return boolean ;

</function>

This source code may access any state value of the task using a Hashtable variable called states. To reference a particular state, we supply the states variable with the text string containing the name of the state and then apply the predefined value function and cast the returned Object to the appropriate date type - floating point number (Float), integer (Integer) or boolean (Boolean).

( type ) states.get( name ).value();

The actual code or control instruction is left to the discretion of the programmer.

Reference

In addition to in-line source code, the function also accepts a Universal Resource Locator reference to the source code. The form of this source code is identical to that presented above.

<function>

URL

</function>

Server

We wish to encourage networked control and distributed processing, therefore we allow the definition of a server process. Specifically, we include optional host and port elements, which define the host identification and port number of a server that accepts the task's state vector and returns the state vector and a boolean value.

<function>

<host> string </host>

<port> integer </host>

</function>

Rate

Each function element includes a manatory rate element, which specifies the update period in seconds. This is the "tick" rate that the function is executed.

<function>

<rate> float </rate>

. . .

</function>

The function element defined here has its use in the various functions of a task definition. We outline these task functions in the next sections.

Task Control Functions

The task includes four function: a mandatory context function that ensures appropriate execution, a mandatory update function that recalculates the state parameters, an optional action function that sends commands directly to actuators (such as motors, switches, relays, solenoids, etc.) and a mandatory goal function that determines the successful completion of a task.

Context Function

Not all tasks are appropriate at all times. A microwave oven, for example, should not operate if there is nothing in it, nor should a washer wash if the door is open.

A task should not execuite if it is not our desire We don't want the air-conditioner to run in the winter nor the heater in the summer.

Finally, a task should not execute if it is already complete. We don't need the oven to cook the food if it is already cooked.

The proper conditions for task execution we will simply call the context . If the context is right; that is if the user wants it and the conditions are acceptable, the task will execute.

We define a context element that contains a function the operates on the set of states defined by the state element.

source code ;

return boolean ;

</function>

</contex>

If the context function returns true , the task executes and if not the task (and all subordinate tasks) suspend immediately.

In this sense, a subtask is "never on its own." Tasks are never allowed to operate unless they have been explicitly permitted to do so by their superiors.

Within every active task, the context function operates continuously . In other words, even if a task spawns a series of subtask (and these subtask and so on), the original task does not stop running the context function.

If the context function of any task returns false , all subordiante tasks suspend, as shown in Figure 1, If the context function of any function returns false all subordinate tasks suspend execution.. In this way, the task system never operates inappropriately.

The purpose of the context function is to ensure reliable operation and to gaurantee failure detection, fault tolerance and recovery functions are embedded into the task hierarchy.

Update Function

The next function is a mandatory update function. This function simply updates the state vector according to the rate specified by the rate element.

Goal Function

The mandatory goal function returns true when all the conditions for successful task execution have been satisfied.

Action Function

At some point it is necessary to actually control a device. The optional action function sends control commands to actuators - motors, solenoids, switches, etc. - that actually effect the physical world.

By its definition, tasks that contain an action function are leaf tasks in the task tree; that is, they are the lowest level tasks in the task hierarchy.

Specification: Control

<admin>

. . .

. . .

</admin>

<msr label= string > offset </msr> State 1

<msr label= string > offset </msr> State 2

. . .

<msr label= string > offset </msr> State n

</states>

</task>

<function> <rate> float </rate>

source code ;

return boolean ;

</function>

</contex>

<function> <rate> float </rate>

source code ;

return boolean ;

</function>

</update>

<goal>

<function> <rate> float </rate>

source code ;

return boolean ;

</function>

</goal>

<function> <rate> float </rate>

source code ;

return boolean ;

</function>

</action>

. . .

</task>